MaxDB killed by Power Outage - PART II !

[Former Member]

Hi friends,

My server was halted as power to the server was cut (no UPS in place).

This has happened before ( ), but this time we got a new error:

20028,Initialization of log for 'restart' failed with 'InconsistentLogInfoPage'

It clear that MaxDB dont like to get the legs swiped away, but then again ... who does

I hope some of you have a good idea. A restore from backup is not a posibility. The latest backup is way to old

How do I tell MaxDB, to simply startup and ignore the inconsistent logfile ?

cheers

Jan

dbmcli -d MD1 -u superdba,xxyyzz show state

OK

SERVERDB: MD1

The SERVERDB state is STOPPED

• Post Mortem Analysis for ServerDB MD1 using kernel ***

Console command finished (2011-06-01 18:21:48).

dbmcli -d MD1 -u superdba,xxyyzz db_stop

OK

dbmcli -d MD1 -u superdba,xxyyzz db_admin

OK

dbmcli -d MD1 -u superdba,xxyyzz db_online

ERR

-24988,ERR_SQL: SQL error

-9407,System error: unexpected error

3,Database state: OFFLINE

Internal errorcode, Error code 6433 "system_error"

40,The last known LogIOSequence 10346130 on partition 1, position 2154155 could not be found

33,The log-iosequencenumber 10346130 could not be found at the expected position 2154155 on partition 1

20028,Initialization of log for 'restart' failed with 'InconsistentLogInfoPage'

dbmcli -d MD1 -u superdba,xxyyzz db_enum

OK

MD1 /sapdb/MD1/db 7.7.06.07 fast offline

MD1 /sapdb/MD1/db 7.7.06.07 quick offline

MD1 /sapdb/MD1/db 7.7.06.07 slow offline

MD1 /sapdb/MD1/db 7.7.06.07 test offline

dbmcli -d MD1 -u superdba,xxyyzz inst_enum

OK

7.7.06.07 /sapdb/MD1/db

sdbregview -l

DB Analyzer /sapdb/programs 7.7.06.07 64 bit valid

Server Utilities /sapdb/programs 7.7.06.07 64 bit valid

PCR 7300 /sapdb/programs 7.3.00.60 valid

PCR 7301 /sapdb/programs 7.3.01.22 valid

PCR 7500 /sapdb/programs 7.5.00.50 64 bit valid

SAP Utilities /sapdb/programs 7.7.06.07 64 bit valid

Base /sapdb/programs 7.7.06.07 64 bit valid

Redist Python /sapdb/programs 7.7.06.07 64 bit valid

JDBC /sapdb/programs 7.6.06.00 valid

Messages /sapdb/programs MSG 0.7732 valid

ODBC /sapdb/programs 7.7.06.07 64 bit valid

Database Kernel /sapdb/MD1/db 7.7.06.07 64 bit valid

SQLDBC 77 /sapdb/programs 7.7.06.07 64 bit valid

Loader /sapdb/programs 7.7.06.07 64 bit valid

SQLDBC /sapdb/programs 7.7.06.07 64 bit valid

SQLDBC 76 /sapdb/programs 7.6.05.11 64 bit valid

Fastload API /sapdb/programs 7.7.06.07 64 bit valid

xinstinfo MD1

IndepData : /sapdb/data

IndepPrograms : /sapdb/programs

InstallationPath : /sapdb/MD1/db

Kernelversion : KERNEL 7.7.06 BUILD 007-123-197-046

Rundirectory : /sapdb/data/wrk/MD1

[former_member229109 · Accepted solution]

Hello,

1. Are you SAP customer?

If yes => create the SAP message and get SAP support.

2. If you would like to solve the case by yourself =>

• Bring the the database in admin status and create the complete database backup;

• Run the following commands:

dbmcli -d MD1 -u superdba,xxyyzz

<enter>

dbmcli on MD1> db_state

< database in admin. If not => "db_admin" >

dbmcli on MD1> db_execute clear log

< After you run this command the logarea will be clear and you will be able to restart until the latest written safepoint.

See document:

http://maxdb.sap.com/doc/7_7/44/d8ebaedaba5705e10000000a1553f6/content.htm

>

If the result is OK =>

dbmcli on MD1>db_online

dbmcli on MD1>exit

The unfinished transactions need to be repeated. Some data could be lost.

And you have to create the complete databackup after crearing the logarea to be able to create the logbackups or switch the autolog on.

3. I recommend to use the "db_offline" to stop the database.

See the difference at

http://maxdb.sap.com/doc/7_7/45/056e8937750484e10000000a155369/content.htm

4. There is HA solutions for "disaster" situations.

Review the document "Replication and High Availability":

http://maxdb.sap.com/doc/7_7/44/c5e3ccb64760eee10000000a155369/content.htm

Regards, Natalia Khlopina

[Former Member · Accepted solution]

Hi Natalia and Lars,

Thanks a lot for your feedback

The database is online again.

>>Besides that: the "my backup is too old"-excuse actually isn't one. It's a bug. Your's

ha ha ha ... your are totally right ... and I am not proud of my self here

Good points about the write-caching. Did actually disable that on the SAN, but not on the Linux OS. That last one was a bug. Mine

Thanks again

cheers

Jan

[lbreddemann]

Hello Jan,

the problem here is not so much that MaxDB is more sensible to power outages than other DBMS.

The point is, that your storage system obviously reports write I/Os as done, before they are actually on the disk.

Caching write I/O without permanent memory or UPS will always inherently lead to problems like this.

So, to prevent this in the future, make sure to avoid 'lost writes' and turn off the write caching!

However, MaxDB actually allows you to ignore the last log entries and to startup and open the database based on the last written savepoint.

Before you do this, be very clear about that this means, that you're loosing data!

To startup the database without the log information, you've clear the log area.

How this is done, can be found in the forum threads or - way better option - you open a support message at SAP and have the whole situation analyzed thoroughly.

Besides that: the "my backup is too old"-excuse actually isn't one. It's a bug. Your's.

regards,

Lars