Kbase P21652: Process an After-Image Roll Forward on a standby database which Date is not the same as the After-Im
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
14/04/2009 |
|
Status: Verified
SYMPTOM(s):
Roll forward fails with errors 931 932 933 1046
Errors 831, 832, 833, 1046 when rolling forward onto standby database
The database was last changed <date>. (831)
** The after-image file expected <date 2>. (832)
** Those dates don't match, so you have the wrong copy of one of them. (833)
Roll forward of file <ai file name> did not complete normally (1046)
Process an After-Image Roll Forward on a standby database which Date is not the same as the After-Image file.
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
CAUSE:
Tried to process an After-Image Roll Forward on a database where the Date is not the same as the After-Image file, due to making schema changes, archiving data and dumping tables on the standby database (DB2 being a copy of DB1, which is live) and hoping to roll forward the ai's of the live database after the necessary maintenance was complete.
FIX:
File last opened date and time needs to be consistent with expected date and time reported in 832 error. If these dates and time do not match, there is no way to force the application of the AI file against that database. It is not possible to force the After-image roll forward when the database date has been changed through 'touching' the standby database. The database date on the standby cannot be changed either.
The reason is, that a recid in DB1will be in a different block to the recid in DB2, so in terms of database integrity, this cannot be allowed and would result in many database corruption errors subsequently.
Refer to online utilities that can be used instead. For example:
TABLEMOVE Table1 to a different Storage Area (if needed, prostrct add can be peformed with minimum downtime if you need to add a new storage area for this purpose). TABLEMOVE will allow users read rights while the operation is taking place, but not writes. It will also achieve the same as a load, by reorganising all the records for a table to be 'grouped' together in the same block. If you don't specify the index associated, it is NOT moved and the indexes are rebuilt automatically.
If you also want to move the indexes, then you should move these at the same time, otherwise the indexes will be rebuilt twice if you move these seperately with the IDXMOVE utility.
Furthermore, the IDXCOMPACT utilty can be performed online. It does not completely rebuild the indexes like a idxbuild will, but it will re-organise the indexes (in a limited way) and compact them at the same time.
If you have afterimaging enabled on this database already, be aware that your ai's will need to be switched more than usual as will the bi file (up to 3x as much) so check your disk space beforehand. Please also note, that Progress recommends undertaking this operation during a time when the system is relatively idle. This is because and EXCLUSIVE lock is on the table when it is actually moved.