Yes, seems I have not been the only one having this specific problem :)
If theres one thing SAPDB has very little experience with than its a large userbase 
testing and fiddling around with it in rather non-productive "play" environments with 
old or no backups :)

I tried x_diagnose today myself....and it has this awful old adabas console interface.
I also haven't figured out how to save any values I've changed yet.

Now since we have this shiny new dbm client/server interface why not migrate useful 
tools like that into i.e. DBM Studio with a painless editor?

----- Original Message ----- 
From: "Toni Epple" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 09, 2002 4:37 PM
Subject: RE: successful -9212 kernel hack to get db up warm again


> Hi Uwe,
> 
> 
> > With this you can patch the flag (rstConfigPhase_kb00 to none=0) 
> > located in the restartrecord page on the system devspace.
> >
> Today I had a power outage, and one of my databases produced a -9212 
> (db_stop, which helps sometimes didn't help in that case). I've uploaded 
> tons of data over the weekend, and didn't get to perform a backup.
> I'm trying to use x-diagnose online diagnosis to force the database into 
> a "consistent state"; when I'm trying 'edit restart record' (instance is 
> in cold mode), I can use INSERT to change the values, but I cannot save 
> the changes. How do I achieve this?
> 
> rescue my data!!! pleeze! ;)
> 
> regards
> 
> Toni
> 
> 
> >
> >  
> >
> >> -----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
> >
> >
> >  
> >
> 
> 
> -- 
> 
> Anton Epple
> Genomatix Software GmbH
> Landsberger Strasse 6
> D-80339 Muenchen
> 
> http://www.genomatix.de
> 
> 
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general

Reply via email to