Old Database startup Error

hooichia82

New Member
Hi,

I have an old database in Progress 7.3E version (currently I'm using Progress 9.1B), which cannot be startup. Startup error as below:

14:03:14 SRV 0: Extent /disc6/bi/livestd.b1 has a different last opened date. (606)
14:03:14 SRV 0: Probable backup/restore error. (605)
14:03:14 SRV 0: Database is damaged, see documentation. (1486)
14:03:14 SERVER: ** The server terminated with exit code 2. (800)
14:03:14 SERVER: ** The database /disc3/live/livecust is in use in multi-user mode. (276)
14:03:14 SERVER: ** The server terminated with exit code 2. (800)
14:03:14 SERVER: ** The database /disc3/mfgpro/pss/mfghelp is in use in multi-user mode. (276)
14:03:14 SERVER: ** The server terminated with exit code 2. (800)




Can anyone help me on this? I need to retrieve some old data from this database. Please help.


My OS is AIX 4.3.3.


Thanks in advance.
 

TomBascom

Curmudgeon
If it was a v7 database you would get errors about a version mismatch rather than about the .b1 file data having the wrong date.

The sort of error that you are showing usually occurs as a result of using OS utilities to backup and restore rather than using probkup. Is that what you do?

If you are sure that you have the correct bi file you should be able to cure the problem with prostrct unlock.
 

TomBascom

Curmudgeon
By the way... AIX 4.3 is really, really old. And Progress 9.1B is ancient, unsupported and not a very good release to be running on. You should upgrade both your OS and your Progress. You'd be amazed at how much better things will run.
 

hooichia82

New Member
Hi,

What is the bi file for? What do you mean by "If you are sure that you have the correct bi file you should be able to cure the problem with prostrct unlock."?

For your information, I just joined my current company 6 months ago. So, I'm not sure whether the database is backup & restore using OS utilities or using probckup. However, the database is all the while stored in the server and it's stored in the different partition.

As what my colleagues told me, this database can be started up 1 years ago. So, I think it shouldn't be a version mismatch problem. So, if based on the error message that I get, how can I solve this problem? Or, how can I check to find out the error root cause?

Thanks in advance.
 

hooichia82

New Member
By the way... AIX 4.3 is really, really old. And Progress 9.1B is ancient, unsupported and not a very good release to be running on. You should upgrade both your OS and your Progress. You'd be amazed at how much better things will run.


I hope to upgrade too...... Unfortunately, I'm not the decision maker :(
 

TomBascom

Curmudgeon
You need a DBA training class if you're going to be acting as a DBA...

The bi file is what Oracle would call "the undo log".

A progress database has many parts. Data extents, before-image extents ("bi file" or undo log), and after-image extents ("ai file" or redo log). They must be handled in a coordinated manner or the database will be corrupted. The safest way to backup and restore is with probkup. Likewise the safest way to copy a database is with procopy. These utilities know where all of the parts of a given database are and they are aware of restrictions such as the database needing to be shutdown before a copy is made. Using OS commands (like "copy" or "tar") is possible but you have to go to extra effort to get it right and there is always the chance that you mess something up.

In this case it seems that someone messed up the bi file. Ideally you would figure out how that happened and find the right one somewhere (maybe somebody just forgot to restore it or put it in the wrong directory). if you cannot find it then you are stuck with an incomplete and corrupt database. The corruption may be minor and unimportant or it may be major and pervasive. There is no way to tell.
 

hooichia82

New Member
"There is no way to tell. " makes me so upset.:(
Anyway, thanks for your replies and I will try to find out the root cause.
Thanks again.;)
 

hooichia82

New Member
Hi,

I have check the database log file (livestd.lg) and below is my findings:

1. The last successful startup date is on 2/10/2006.

2. On 9/10/2006, the database cannot be started up with the error "cannot find or open file /disc6/bi/livestd.b1, error = 0. (43)".

3. Then, on 18/10/2006, the startup error become "Extent /disc6/bi/livestd.b1 has a different last opened date. (606)".

4. The last access date for livestd.db is 2/10/2006 while the last access date for livestd.b1 is 18/10/2006.


So, I assume that someone has deleted the livestd.b1 from the /disc6/bi within 3/10/2006 to 9/10/2006 and restore back the file on 18/10/2006.

If this is the case, what can I do to solve this problem? Can I just change the livestd.b1 file's date from 18/10/2006 to 2/10/2006 in order to solve this problem? If yes, what is the Unix command to change the file access date?

Thank you.
 

TomBascom

Curmudgeon
Your analysis seems valid -- someone deleted the bi file and replaced it with another.

You can force the db to ignore the bi file with the -F startup parameter. But, like I said, you have no way to know how much data has been lost. It might be none. Or it might be a lot. (You cannot know because you have lost the file which contains the data...) DO NOT MAKE A HABIT OF USING -F. Even if you "get away with it" this time. It will come back to bite you.

If you were running with after-imaging you would restore from backup and roll-forward your archived transactions. Then you would lose no data. But since you don't seem to be able to restore a backup it seems unlikely that after-imaging is in use.

I suspect that your environment needs a lot of attention and improvement.
 

hooichia82

New Member
I have tried to startup the database using parameter -F, but I still get the same error message:

14:03:14 SRV 0: Extent /disc6/bi/livestd.b1 has a different last opened date. (606)
14:03:14 SRV 0: Probable backup/restore error. (605)
14:03:14 SRV 0: Database is damaged, see documentation. (1486)
14:03:14 SERVER: ** The server terminated with exit code 2. (800)


Why? How come? :confused:
Or, I issue the wrong command?
Command that I use to force database startup: proserve /disc3/live/livestd -F
Please correct me if I was wrong.
Thank you.
 

TomBascom

Curmudgeon
Start a single user session with pro -F. And don't make a habit of using -F. It is a very bad thing. You are admitting that your database has been damaged and is corrupt and this is a last resort to try to recover some data. It is not a standard operation.
 

Casper

ProgressTalk.com Moderator
Staff member
Tom meant: proutil truncate bi with the -F option

and remember (Tom's quote):
say again... using -F is dangerous. DO NOT MAKE A HABIT OF IT. This is a measure of last resort used to recover data from a database that is damaged and corrupt. It is not standard practice.

Casper.
 

TomBascom

Curmudgeon
Providing correct command lines that use -F should be a crime :eek:

I say again... using -F is dangerous. DO NOT MAKE A HABIT OF IT. This is a measure of last resort used to recover data from a database that is damaged and corrupt. It is not standard practice.

Throwing away the .bi file (which is what -F does) is throwing away data. It is not much different than throwing away a data extent.
 

Casper

ProgressTalk.com Moderator
Staff member
Providing correct command lines that use -F should be a crime :eek:

I say again... using -F is dangerous. DO NOT MAKE A HABIT OF IT. This is a measure of last resort used to recover data from a database that is damaged and corrupt. It is not standard practice.

Throwing away the .bi file (which is what -F does) is throwing away data. It is not much different than throwing away a data extent.

Ok, I'm caught!
I was hoping that its was clear within the context of the thread why not to use it... :cool:

Anyway prorest is more a friend of mine then any command with -F. I luckily never had to use it...

Casper
 

TomBascom

Curmudgeon
We might have enough caveats and dire warnings. Hopefully anyone considering it based on this thread will take the hint.
 
Top