cancel
Showing results for 
Search instead for 
Did you mean: 

Backup of MaxDB7.8.02.37 recover to MaxDB 7.9.10.07

0 Kudos

Hello!

Having two systems one with MaxDB 7.8.02.37 and a new one with MaxDB 7.9.10.07.

Made a backup at the 7.8 machine, did also the check backup on this machine all fine.

But if I try to recover this 7.8 backup on the 7.9 machine this error is shown:

-9407 System error: unexpected error 17,Check backup failed 16,The history root page reference in the restart page of the backup (pno = 2147483647, converter version = 4294967295) was not found as page in that backup; instead found page with pno = 1018016 and converter version = 20424 flagged as history root page

If we try to do the backup check on the 7.9 machine this error is shown:

-7900 Different block sizes 6,Data recovery failed 13,Found 1 bad page(s)

I have checked the block sizes on both machines it equals, it is on both machines 8K.

Tried to recover the backup into another 7.8.02.37 MaxDB this was working.

Do I need to set some parameter to be able to recover the 7.8 Backup in a 7.9 DB?

Thanks and BR

Accepted Solutions (0)

Answers (3)

Answers (3)

birgit_malik
Advisor
Advisor
0 Kudos

Hi Hermann,

please create a diagpkg.tgz as described in note 826037 or https://wiki.scn.sap.com/wiki/x/PwErAg.

I have created a container https://sap-my.sharepoint.com/:f:/p/birgit_malik/EjKnKWEan8xCt2EjW8CxCQwBQ6FzgCHHDKteYZVvihhBmw?e=Lf... . Please upload the diagpkg.tgz to this container.

How large is the backup if it is compressed? Depending on the size we have to decide how to get it here.

Thanks Birgit Malik

0 Kudos

Hi Birgit!

Have uploaded the diagpkg.tgz.

Thanks and BR

Hermann

steffen_schildberg
Active Participant
0 Kudos

Hi Hermann

I've taken over from Birgit as I am the responsible developer in the MaxDB development team.

I checked the provided archives and cannot find any hint on the initially described error.

The KnlMsgArchive of the 7.9 database does contain only 3 rows and the last shows that the database was successfully created without recovery:
Thread 0x1A10 Task 110 2022-05-16 07:28:56 AdminMsg 0: 6281E1180007 0000 IC1 RETURNCODE 0;CREATE INSTANCE SYSDBA DBA

The KnlMsg of that same database does not contain any error message that is related to the initial error. The dbm.prt of that database shows that it was created without recovery and immediately afterwards a backup was taken. No recovery attempt here. And I do not see any older KnlMsg or KnlMsgArchive files.

The KnlMsg of the 7.8 database shows indeed a CHECK DATA IN ADMIN followed by a backup. But I cannot see the recovery done with this backup at the 7.9 side.

Are you sure that you provided the correct 7.9 diagpkg.tgz?

Best,
Steffen

0 Kudos

Hello Steffen,

I have installed the 7.8 backup on the 7.9 machine and then created the logs.

Uploaded the another diagpakg.tgz with the name MaxDB7_9_new_diagpkg.tgz.

Please could you take a look at these log files.

Thanks and BG

Hermann

steffen_schildberg
Active Participant
0 Kudos

Hi Hermann,
and again - this is not the error you reported initially. Now there is the error during recovery that the block size is different between the backup and restore and a bad page is reported during recovery. Are the medium/template definitions in 7.8 and 7.9 identical (except the path)? How did you recover your system initially? Why is it not possible to do it again the same way? I don't get it yet.

Are these database belonging to a SAP system? A customer message would ease the processing a lot.

How big is the data backup?

Sorry but at the moment I have no idea how to help here.

Best regards,
Steffen

0 Kudos

Hello Steffen,

I have installed the 7.8 backup on the 7.9 machine and then created new logs, uploaded the another diagpakg.tgz with the name MaxDB7_9_new_diagpkg.tgz.

Please could you take a look at these log files.

Thanks and BR

Hermann

steffen_schildberg
Active Participant
0 Kudos

Hi Hermann,
dunno if it makes any sense to paste comments twice ... My comment was related exactly to the newly uploaded archive MaxDB7_9_new_diagpkg.tgz. There is the following error for the recovery:
Thread 0x3B4 Task 109 2022-05-18 13:04:18 ERR RESTORE 52007: BAD PAGES FOUND #: 1
Thread 0x3B4 Task 109 2022-05-18 13:04:18 ERR RESTORE 52012: error occured, basis_err 5950
Thread 0x3B4 Task 109 2022-05-18 13:04:18 ERR Recovery 6: Data recovery failed,_FILE=Kernel_Administration.cpp,_LINE=2661
2022-05-18 13:04:18 ERR Recovery 13: Found 1 bad page(s),_FILE=vkb38.cpp,_LINE=4158
Thread 0x3B4 Task 109 2022-05-18 13:04:18 ERR Recovery 6: Data recovery failed,_FILE=Kernel_Administration.cpp,_LINE=2661
2022-05-18 13:04:18 ERR Recovery 13: Found 1 bad page(s),_FILE=vkb38.cpp,_LINE=4158

I don't see any relation between the initial error and this newly reported error. There is a bad page in your backup. Check your backup. Make sure the template/medium definitions do not differ in block size.

I can't help if with every new recovery a new error arises. Isn't it possible to simply repeat the initial recovery where the initial error was reported? I really don't get it yet.

And again:

Are these database belonging to a SAP system? A customer message would ease the processing a lot.

How big is the data backup? My guess would be around 10 GB but I would like to get the exact size to check if we could get it here. Supposing the initial error happens again.

Best regards,
Steffen

birgit_malik
Advisor
Advisor
0 Kudos

Hi Hermann,

after check data you should perform a new data backup. This new data backup should be used in 7.9 system.

So my question is: did you create/use the new backup after check data?

In our tests this workaround worked fine.

If it not works we could check the backup (we need y copy).

Or you can ignore the error. In note 3167235 you can find the following information: The created data backup is complete and can be restored despite the occurrence of this error.

So the error is not critical.

Regards Birgit Malik IMS SAP MaxDB

0 Kudos

Hello Birgit,

I have done the check data with update and then made a backup. When I restore the backup, the error occurs again.

I also tried to update the 7.8 DB to 7.9, which meant that the 7.9 DB could not be started. Error: -24994, ERR_RTE: Runtime enviroment error 4, connetion broken

In both cases the DB can no longer be started, it can only be started in admin mode.

Today I did the steps again to be sure, but unfortunately the error is still the same.

I can provide the backup.

Thanks and BRHermann
birgit_malik
Advisor
Advisor
0 Kudos

Hi Hermann,

this is a known issue which is solved with newer database versions.

The workaround for your situation is as follows:

Perform in 7.8 system in operational state ADMIN a CHECK DATA WITH UPDATE
or
Perform in 7.8 system operational state ONLINE a db_check with snapshot

This is described in note 940420.

This check deletes not necessary pages which are "forgotten" in the system from former snapshots.

Perform after this the 7.8 backup again (the data after the checks should be cleaned up). The recovery in 7.9 system should work now fine.

Regards Birgit Malik IMS SAP MaxDB

0 Kudos

Hi Birgit!

Thanks for your hint.
I did at dbmcli "db_execute check data with update" on the 7.8 DB. A few blocks were released.
But unfortunately the error still exists. After Check Backup on the 7.9 DB I getting this error message:

-9407 System error: unexpected error 17,Check backup failed 16,The history root page reference in the restart page of the backup (pno = 2147483647, converter version = 4294967295) was not found as page in that backup; instead found page with pno = 215876 and converter version = 20467 flagged as history root page.

Are there other thing i could do?
Thanks and BR
Hermann