Jump to content

Database not saving changes after upgrade


EdTGuy

Recommended Posts

Our 4.1.4 Revive server (AWS EC2 instance) was dormant for an extended period of time. I recently spun it back up, upgraded it to 5.4.1 and switched from an AWS RDS database to a local mariadb MySQL database on the EC2 instance. All data shows in the UI, but none of the changes I attempt to make are saved. I created a new advertiser, the change appeared to be successful, but it didn't appear in the list. When I tried to create the campaign, I received the message below .
Any suggestions?

errormessage.gif PEAR Error

DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY
 



 

errormessage.gif PEAR Error

DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY
 



 

errormessage.gif PEAR Error

DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY
 



 

errormessage.gif PEAR Error

DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY
 



 

errormessage.gif PEAR Error

DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY
 



 

errormessage.gif PEAR Error

DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY
 



 

errormessage.gif PEAR Error

DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY
 



 

errormessage.gif PEAR Error

DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY
 



 

errormessage.gif PEAR Error

DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY
 



 

errormessage.gif PEAR Error

DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY
 



 

errormessage.gif PEAR Error

DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY
 



 

errormessage.gif PEAR Error

DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY
 


 

IQ AdCloud
 

errormessage.gif An error occurred while accessing the database

Due to a problem with the database Revive Adserver couldn't retrieve or store data. If this problem is reproducable it might be caused by a bug in Revive Adserver. Please report the following information to the creators of Revive Adserver. Also try to describe the actions that led to this error as clearly as possible.

Version:    Revive Adserver v5.4.1
PHP/DB: PHP 7.2.24 / MySQL 5.5.68-MariaDB
Page: /www/admin/campaign-modify.php
Error:  
Query:
 
$_POST:
Empty
$_GET:
Array
(
    [token] => 011a57562904eb222acafa62239a0c0a
    [duplicate] => 1
    [clientid] => 1
    [campaignid] => 3
    [returnurl] => campaign-zone.php
)
Link to comment
Share on other sites

More info: It seems like nothing in the database is advancing from the program. I updated the value of account_id for the new row in rv_accounts from 0 to 17, which caused it to appear in the UI and I was able to create a campaign, but again, the campaignid was 0 so I had to manually update it to the next consecutive value. 
I've also noticed that the date_time value in rv_data_summary_ad_hourly is not advancing past '2020-03-20 21:00:00', where it keeps accumulating more rows every hour around ten past the hour, ever since I restarted the server a little over a week ago.

It's as though it's missing some bit of logic that should be advancing primary key values and dates.

The value in the updated column of rv_data_summary_ad_hourly is where I see a block of rows for every hour around ten past the hour.

Link to comment
Share on other sites

More info: This morning I found that the server had crashed. It was out of disk space. I traced it to the var/debug.log file. I replaced this file with a zero byte copy and restarted the mariadb service. The server resumed, but after a few minutes, I noticed that debug.log was blowing up again. I stopped the mariadb service and the debug.log stopped increasing. Looking at the contents of debug.log, it's running a maintenance task, but it thinks it needs to go back to the last day before the previous version was shutdown, over three years ago.

Does anyone know how to reset the starting point? Below is a summary of the log, without all the php trace info.


Running Automatic Maintenance Task
Running Maintenance Engine
OA_Maintenance_Auto::run: Running Maintenance Statistics Engine
OX_Maintenance->run: Task begin: OX_Maintenance_Statistics_Task_SetUpdateRequirements
OX_Maintenance->_runMSE: - Maintenance start run time is 2023-09-08 13:29:20 UTC
OX_Maintenance_Statistics->run: - Getting the details of when maintenance statistics last ran on the basis of the operation interval
OX_Maintenance->_runMSE: - Maintenance statistics last updated intermediate table statistics to 2020-03-20 20:59:59 UTC
OX_Maintenance->_runMSE: - Current time must be after 2020-03-20 21:59:59 UTC for the next intermediate table update to happen
OX_Maintenance_Statistics->run: - Getting the details of when maintenance statistics last ran on the basis of the hour
OX_Maintenance->_runMSE: - Maintenance statistics last updated final table statistics to 2020-03-20 20:59:59 UTC
OX_Maintenance->_runMSE: - Current time must be after 2020-03-20 21:59:59 UTC for the next intermediate table update to happen
OX_Maintenance->_runMSE: - Maintenance statistics will be run
OX_Maintenance->_runMSE: - The intermediate table statistics will be updated
OX_Maintenance->_runMSE: - The final table statistics will be updated
OX_Maintenance->run: Task complete: OX_Maintenance_Statistics_Task_SetUpdateRequirements
OX_Maintenance->run: Task begin: OX_Maintenance_Statistics_Task_MigrateBucketData

This next section repeats for every hour between 2020-03-20 21:00:00 and 2023-09-08 12:00:00

OX_Maintenance->_runMSE: - Migrating raw bucket data from the 'rv_data_bkt_a' bucket table
OX_Maintenance->_runMSE:   to the 'rv_data_intermediate_ad_connection' table, for operation interval range
OX_Maintenance->_runMSE:   2020-03-20 21:00:00 UTC to 2020-03-20 21:59:59 UTC
OX_Maintenance->_runMSE:   - Migrated 0 row(s)
OA_Task_Runner->runTasks:   - Pruning the rv_data_bkt_a table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC
OA_Task_Runner->runTasks:     - The rv_data_bkt_a table is a raw data table. Data logged in real-time, not operation intervals.
OA_Task_Runner->runTasks:     - Accordingly, pruning of the rv_data_bkt_a table will be performed based on data that has a logged date between
OA_Task_Runner->runTasks:       2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC
OX_Maintenance->_runMSE:   - Pruned 0 row(s)

The next section is similar, for the same date range

OX_Maintenance->_runMSE: - Migrating supplementary raw bucket data from the 'rv_data_bkt_a_var' bucket table
OX_Maintenance->_runMSE:   to the 'rv_data_intermediate_ad_variable_value' table, for operation interval range
OX_Maintenance->_runMSE:   2020-03-20 21:00:00 UTC to 2020-03-20 21:59:59 UTC
OX_Maintenance->_runMSE:   - Migrated 0 row(s)
OA_Task_Runner->runTasks:   - Pruning the rv_data_bkt_a_var table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC
OA_Task_Runner->runTasks:     - The rv_data_bkt_a_var table is a raw data table. Data logged in real-time, not operation intervals.
OA_Task_Runner->runTasks:     - Accordingly, pruning of the rv_data_bkt_a_var table will be performed based on data that has a logged date between
OA_Task_Runner->runTasks:       2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC
OX_Maintenance->_runMSE:   - Pruned 0 row(s)

Another similar section for the same date range

OX_Maintenance->_runMSE: - Migrating aggregate bucket data from the 'rv_data_bkt_vast_e' bucket table(s)
OX_Maintenance->_runMSE:   to the 'rv_stats_vast' table, for operation interval range
OX_Maintenance->_runMSE:   2020-03-20 21:00:00 UTC to 2020-03-20 21:59:59 UTC
OX_Maintenance->_runMSE:   - Migrated 0 row(s)
OA_Task_Runner->runTasks:   - Pruning the rv_data_bkt_vast_e table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC
OX_Maintenance->_runMSE:   - Pruned 0 row(s)

The next section is slightly different (pruning 3 tables), but for the same date range

OX_Maintenance->_runMSE: - Migrating aggregate bucket data from the 'rv_data_bkt_c', 'rv_data_bkt_m', 'rv_data_bkt_r' bucket table(s)
OX_Maintenance->_runMSE:   to the 'rv_data_intermediate_ad' table, for operation interval range
OX_Maintenance->_runMSE:   2020-03-20 21:00:00 UTC to 2020-03-20 21:59:59 UTC
OX_Maintenance->_runMSE:   - Migrated 0 row(s)
OA_Task_Runner->runTasks:   - Pruning the rv_data_bkt_c table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC
OX_Maintenance->_runMSE:   - Pruned 0 row(s)
OA_Task_Runner->runTasks:   - Pruning the rv_data_bkt_m table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC
OX_Maintenance->_runMSE:   - Pruned 0 row(s)
OA_Task_Runner->runTasks:   - Pruning the rv_data_bkt_r table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC
OX_Maintenance->_runMSE:   - Pruned 0 row(s)

The debug.log ends in the middle of this process, as this is where I stopped the mariadb service. I'm not sure what else it would have tried to process.

Link to comment
Share on other sites

I may have resolved my issue. I truncated rv_log_maintenance_statistics, which only had rows up to 2020-03-20 from the old 4.1.4 version of Revive. I shutdown the mariadb service truncated the debug.log and restarted the service. Besides info and debug statements, It spit out a bunch of error statements like:

PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_c using class_location value :
PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class  from data_bkt_c :
PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_a using class_location value :
PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class  from data_bkt_a :
PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_m using class_location value :
PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class  from data_bkt_m :
PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_r using class_location value :
PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class  from data_bkt_r :
PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_vast_e using class_location value :
PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class  from data_bkt_vast_e :

It repeated the above sequence a second time. The first time was for

OX_Maintenance_Statistics->run: - Getting the details of when maintenance statistics last ran on the basis of the operation interval

and the second time was for

OX_Maintenance_Statistics->run: - Getting the details of when maintenance statistics last ran on the basis of the hour

After that, there were many info and debug entries, finishing with 

Automatic Maintenance Task Completed

I'll continue to monitor the debug.log file, but so far, it's not blowing up.


:

Link to comment
Share on other sites

The debug file is no longer blowing up, but the hourly maintenance process modifies the priority column value in rv_ad_zone_assoc in a way I don't understand. I have one campaign for one advertiser with nine banners and another campaign for a second advertiser with one banner. Everything has the same weight. The maintenance process sets all the priority values to 0.005. The result is that most requests for a banner return blank. I can manually modify this by running this sql command, update rv_ad_zone_assoc set priority = 0.1; then every request returns a banner, but in the next hour, the maintenance process returns all values to 0.005. I don't see anything in the UI settings that gives me a clue why the maintenance process sets such a low value.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...