HELP!!! database down out of synch data extent

[tdi]

HELP!!! HELP HELP database down out of synch data extent

Hi there.

This is really a urgent matter!!! Help please.

I have this database, and won't boot because of (9215) (9213) (9217)(605) (1486), and the kb and all the stuff sent me to see the PROSTRCT UNLOCK, but it wont run, because of the same errors!!! and then they point me to "Possible work around if PROSTRCT UNLOCK doesn't work" (kb 19263), but this kb doesn't exist, at least the downloadable kb, and the only kb, doesn't show it!!

really would apprecite any help on the subject!!!!
the database is down and tomorrow morning is espected to be runnig!!!

(that's why i told them to keep current the support contract!!)

Help, please.

 

[toby.Harman]

How did the database get this way? This may point to a method of recovery which you haven't explored yet!

 

[tdi]

Thanks for getting interested.

The trouble come from the fact (now i know) that the way the server was shoot down was incorrect.

I didn't make a database shutdown before doing winnt shut down, so the database received a shut_down-event console event every time we shut down the server.

Now i got this, but it's a little late, don't you think?

thanks for answering this fast!

i'll be here (all day and night) until i come to an answer thanks.

 

[toby.Harman]

What Progress Version -

There is an option which allows you to rebuild the .db from a schema - attaching to the existing extents but it is only available on 9.1 I think.

That may help. Prostrct repair is a good option, though it may not get you out of this one!

Just shutting down the O/S without shutting down Progress should not cause this. You may have to look further.

Try KBASE 19908 since this seems to cover what may have happened! If you cannot find the Kbase do a search on Date Mismatch and see if it comes up in the list.

 

[tdi]

i'm trying it out, but...

I'm freaking out here!

I'm trying that KB, but i have to tell my db is 2 extents, 1=50megs the other is not fixed, so i'll tell you what i got, when finished...

 

[tdi]

IT DIDN'T WORK, HELP HELP HELP please

i tryed KB 19908, but it doesn't work!!!
my database has

data.d1 (1280kb)
data_7.d1 (51200kb)
data_7.d2 (1600kb so far)

and did the whole process using the first one, and then with the second two (_7's) in step 9,

but in each case (in step 10) it says that

...d1 has a creation date Wed Aug 21 04:06:12 2002, (9212)
control area has a creation date Mon May 19 23:26:45 2003. (9216)
error en back.. (605)
error in bkOpenControlArea. (7104)


any clue ?

 

[tdi]

more info on the subject

if i try Prostrct unlock,

i get (9215) (9213) (9217) (605) (1486) (7104)
which mainly are related to the LAST OPEN dates, but when trying the above kb (19908), and having "substitued" the d's files (d1 and d2) the errors are related to the CREATION date (9214) (9212) (9216) (605) (1486) (7104).

any clue on this? i'm really over the edge.

help.

 

[tdi]

more on what i've done

help.

another thing i've done:

i deleted the .db file, and then ran prostrct builddb, but it ended with a (6754) "database <dbname> is not properly closed, command ignored" that i think is a message generated by some backstage utility ran by the "prostrct builddb" command itself.

anyway, ignoring this message, i went on to prostrct unlock but it gives (210) System Error: attempt to read block 0 wich does not exist. But the WORST is, that after this message, it fires a GPF on _dbutil (exception e0000003H on _DBUTIL.EXE in 017f:004adae5).

So, i recovered the original .db file, If i ran proutil -C dbanalys, i get into (4229) (1124). The thing is yesterday i could get the full analysis, and now it even gpfs on _proutil!!!!

i've found the difference: if i run :
proutil <db> -C dbrpr -F
and on option 1, run all but 5), it fixes the error, so the next time i do a
proutil <db> -C dbanalys, it will be no (4229) (1124), but THERE WILL BE (3871) (not properlly closed database)

help please.

 

[tdi]

i think i go it , dumping

i think i go it .


dumping 53 megs of data....


wait

 

[tdi]

not quite yet....

not been able to recover yet,
i guess is due to an estrange thing:

after creating new1 db (acording to kb 12994, by the way is so old, that it uses new.db, no longer allowed ;p )
and procopy empty4 new1, then loading original.df, it won't show tables on data dict, (no privileges).

i found this: http://www.peg.com/lists/dba/history/200211/msg00165.html

I guess is related....

i'm trying hard.... see you later...

 

[toby.Harman]

So where exactly are you up to?

Have you managed to get into the database?

Have you managed to dump the data out?

You have built a new database but cannot see the data dictionary because you have no privileges? Did you load a Data Dictionary from the old database?

 

[tdi]

thanks for being interested in helpnig..

So where exactly are you up to?

Have you managed to get into the database?

Have you managed to dump the data out?

You have built a new database but cannot see the data dictionary because you have no privileges? Did you load a Data Dictionary from the old database?

No, i'm not able to conect to db. i can see statistics with -F, but cannot connect, cause of the (92xx) errors.

i was able to dump the RM , using "prostrct dbrpr option 7", but cannot load on a new database (using the same tool) (according to kb 12994).

the other kb's i´ve tryed, doesn't work because the database has more than 1 extent.

i´m really under pressure...

HELP!!!!

 

[toby.Harman]

1. Where is your last backup? I am running out of ideas!
2. This database is never coming back in this structure.... You will need to D&L to get a consistent DB back.
2. Copy the database somewhere else and see if you can get in in single user mode using proutil TRUNCATE -F and then pro dbname. If this gets you in then Dump and Load
3. Binary Dump & Load?
4. Still wondering how this happened - shutting a windows server down will not do this.

 

[tdi]

The answer is the source

Hi there.
Sorry I dind't come back soon to describe the solution to the problem.

First of all, the maintenance was available. It was a communication problem between accounting and systems departments.

Second, <b>prostrct unlock</b> sholud have work from the beginning, but there was a bug on 9.1a throug 9.1c (the one we use is 9.1b) wich can't repair the db, and it appears to be fixed by 9.1d.

i sent the db to progress, and support fixed it for me.

thanks to all interested in this.

Se'ya next time.