on 06-01-2011 3:44 PM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
101 | |
13 | |
13 | |
11 | |
11 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.