DB SHUTDOWN - Savepoint/illegal_page_appr

[Former Member]

Dear All Experts,

I've a MaxDB running Database Manager 7.6 which occassional shutdown on its own during the backup.

Error message from knldiag.err

2010-04-25 22:30:01 0x10D4 ERR 55012 FBM invalid devno(0) or offset(0)

2010-04-25 22:30:01 0x10D4 ERR 52050 SHUTDOWN savepoint/illegal_page_addr

2010-04-25 22:30:03 0x10D4 ERR 52050 SHUTDOWN *** EMERGENCY ***: 9170

I'm running a daily complete backup at 2230.

I couldn't find any useful information for errors "savepoint/illegal_page_addr" in the SDN as well as google.

I studied the history of this errors, which occured quite frequently and most of the time, it only happened on Sat or Sun, started last year Nov 09 till Jan 10 but it stopped until yesterday where it happened again.

The error message is exactly the same.

If there is a problem with the backup or even the backup script, the issue would have happened everyday right?

There is no specific backup jobs that we are running on the weekend to cause the random crashed.

Any ideas / suggestions?

Thanks alot in-advance!

[lbreddemann]

> I've a MaxDB running Database Manager 7.6 which occassional shutdown on its own during the backup.

>

> Error message from knldiag.err

>

> 2010-04-25 22:30:01 0x10D4 ERR 55012 FBM invalid devno(0) or offset(0)

> 2010-04-25 22:30:01 0x10D4 ERR 52050 SHUTDOWN savepoint/illegal_page_addr

> 2010-04-25 22:30:03 0x10D4 ERR 52050 SHUTDOWN *** EMERGENCY ***: 9170

Hi there,

looks like the list of pages to be backed up in the free block management got corrupted somehow.

I'd try to run a CHECK DATA WITH UPDATE to rebuild the converter and the free block management lists.

Afterwards the backup should run through without problems.

regards,

Lars

[Former Member]

Dear Lars,

Thanks for your promptly response!

Do you mean this is some kind unknown bug that you will try to fix now?

Thanks again!

[lbreddemann]

> Do you mean this is some kind unknown bug that you will try to fix now?

No - of course not (I'm not even in development support, let alone development where bugs are fixed).

What I meant is: YOU should run a CHECK DATA WITH UPDATE in ADMIN state to fix this.

I assume that this is just the effect of some corruption that occured a while ago on your system.

Don't see any hint that indicates a bug here.

regards,

Lars

[Former Member]

Dear Lars,

Okay, got you!

I will try that out and keep you updated on the results.

But before that, I will need to do some study about that checking function before I run it on our DB production server.

Thanks again!!

[Former Member]

Dear Lars,

Just another simple question.

Can you roughly explain the mechanism of the backup running?

Because I noticed that it usually shutdown the database between 1 to 2 seconds after the backup was scheduled to run.

OS Event log doesn't show any application errors or warnings which could contribute to the shutdown.

Thanks in advance!

[lbreddemann]

> Just another simple question.

> Can you roughly explain the mechanism of the backup running?

Sure - but I won't, since it has already been done quite fine:

http://maxdb.sap.com/training/

-> Internals Course

-> [No-Reorganization Principle; Data Storage Without I/O Bottlenecks|http://maxdb.sap.com/training/internals_7.6/reorgfree_EN_76.pdf]

-> Chapter "Backup Phases"

regards,

Lars

[Former Member]

TERRIFIC!

Thanks Lars!!

[Former Member]

Dear Lars,

With regards to the error, I've read about the trace file called knltrace.

I did a search and found 2 of the trace files which was logged for 2 shutdown incidents but the file has not been converted to ASCII file yet.

My question is, if I were to use the production database to convert these files (about 11MB each) into ASCII version, will it overloaded my production server in online mode?

Will it be more recommended to run it during off-peak hour?

Will it has any consequences by any means if it failed to convert?

Thanks in-advance!

[lbreddemann]

> I did a search and found 2 of the trace files which was logged for 2 shutdown incidents but the file has not been converted to ASCII file yet.

>

> My question is, if I were to use the production database to convert these files (about 11MB each) into ASCII version, will it overloaded my production server in online mode?

>

> Will it be more recommended to run it during off-peak hour?

>

> Will it has any consequences by any means if it failed to convert?

When your sever is capable of actually starting the database, then converting the log files to ASCII won't put any notiicable load to it.

You can run it whenever you want to - it won't affect your users.

regards,

Lars

[Former Member]

Thanks for the info, Lars!

Can we choose which knltrace to convert?

This is because the 2 knltrace files which I would like to convert has been moved to DIAGHIST folder.

There is an existing knltrace file under the main rundirectory, which I think DBM will convert if I just run the conversion from DBM GUI.

[lbreddemann]

> Can we choose which knltrace to convert?

>

> This is because the 2 knltrace files which I would like to convert has been moved to DIAGHIST folder.

>

> There is an existing knltrace file under the main rundirectory, which I think DBM will convert if I just run the conversion from DBM GUI.

Hello again.

Just a question: why do you want to convert the knltrace?

There's nothing in it that would allow you (or any other non-MaxDB-Kernel-Developer) to understand what happened.

If you want to solve the issue, I highly propose to run the CHECK DATA to fix your FBM-lists.

regards,

Lars