Oh ok, if I knew that way with x_diagnose existed I would never have bothered with hacking the kernel sources :) This should really be part of some troubleshooting FAQ, as I know there have been several cases in the list archives with people that had similar problems. Well, at least now your solution is part of the list archives so people can find it.
Is there a similar flag to overcome the "table is write protected" error after a dataload if you don't really need a full backup (with logmode=DEMO even) ? Regards, Marco > -----Original Message----- > From: Hahn, Uwe [mailto:[EMAIL PROTECTED]] > Sent: Montag, 9. Dezember 2002 11:36 > To: 'Watz'; [EMAIL PROTECTED] > Subject: RE: successful -9212 kernel hack to get db up warm again > > > This incomplete flag should force the normal admin to recover > to a consistent state. For cases like yours (only copy out > whatever can be found) there exists the tool x_diagnose. With > this you can patch the flag (rstConfigPhase_kb00 to none=0) > located in the restartrecord page on the system devspace. So > your hack was ok for you but this is a rare case which can be > handled with x_diagnose and I don't intend to make a command > for that. best regards Uwe > > > -----Original Message----- > > From: Watz [mailto:[EMAIL PROTECTED]] > > Sent: Samstag, 30. November 2002 02:02 > > To: [EMAIL PROTECTED] > > Subject: successful -9212 kernel hack to get db up warm again > > > > > > Hi, > > > > a rather large database on my notebook wouldn't go warm > > anymore with the -9212 error "previous restart incomplete" > > after shutting down Windows without stopping the database > > explicitely (which works 99.9% of the time without > > troubles...I read its a possible rare bug in older SAPDB > > releases somewhere). > > > > Well typically the only advise you get on this error is to > > restore a backup because the database is said to be > > "inconsistent". This doesn't help alot however if you don't > > have a backup at all and just would like to access whatever > > data is left...especially if its the work of several days. > > > > What I did now was upgrading the 7.2.4.3 Database to the > > latest 7.3.0.29 version. > > It still wouldn't start up, it obviously saved some flag > > somewhere so it wouldn't even try to restart again and rather > > fail right away instead. > > > > I managed to hack a few parts of the kernels ugly pascal > > sources so it would ignore the state it saved in the "restart > > page", and it indeed worked ! > > I got my database up and running again, shut it down cleanly > > and exchanged the hacked kernel by the original one again. > > It works fine now, and a "database check" didn't give any > > errors (however I have no idea how reliable that is). Since > > the database is running in logmode DEMO anyway I shouldn't > > have troubles with any bad or not loaded redo log pages as a > > result of the hack I guess. At least I have my data back and > > can copy it over into a safe database. > > > > What about implementing such a "last resort" switch > > officially (come on, you don't have to mention it to R/3 > > customers :-)? I didn't see anything in the code itself, and > > I'm not sure where the "restart page" is actually saved (sys > > devspace?) so it could possibly be accessed from outside. > > > > I mean if theres no backup to restore and the DB cannot go > > warm by any means, what would one have to loose? > > > > So well for any people having the same problem in the > > future....I attached the two hacked files (vkb81/vkb82) that > > can be used to build a 7.3.0.29 recovery kernel like I used > > it. If you have luck it may work for your case, too. > > It may be your last resort if you have no backup and no other > > way to get the db up warm again due to the -9212 error. > > > > I'm just glad that didn't happen with Oracle or other > > closed-source DBs to me. > > I would have had no way to get around this problem and no > > quick and cheap way access my data. > > > > > > > > Watz > > > _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
