progress startup error : : This process terminated with Exit code 1

amandeep.sandhu

New Member
Hi ! ,

I m getting this error while starting Database from Progress Explorer tool. I checked The Log file & shows the following log.

Thu Mar 24 03:30:23 2011
03:30:23 BROKER 0: Last open date mismatch. (9215)
03:30:23 BROKER 0: Extent C:\rem\DB\pantloon.b1 has a different last opened date Wed Mar 23 21:08:21 2011, (9213)
03:30:23 BROKER 0: Control Area has a last open date of Thu Mar 24 03:23:47 2011. (9217)
03:30:23 BROKER 0: Probable backup/restore error. (605)
03:30:23 BROKER 0: Database is damaged, see documentation. (1486)

Worst of this is i don't have latest backup.Could anybody tel the solution of this.

Thx in advance.
 

TomBascom

Curmudgeon
Restore and roll forward from a not quite "latest" backup. Then pat yourself on the back for having the wisdom to have enabled after-imaging.

You don't have backups and after-imaging enabled? Then consider this a very valuable lesson learned.
 

RealHeavyDude

Well-Known Member
There is no remedy apart from restoring the database from some backup. Depending on your strategy this backup may be long out of date or more recent. If you don't have any backup you are pretty much hosed ...

Heavy Regards, RealHeavyDude.
 

TomBascom

Curmudgeon
The mismatch between bi open date and control area open date suggests that you are using something other than "probkup" to backup and restore.

When you use 3rd party tools (or OS utilities) to backup a Progress database it is very easy to do it wrong. Some of the things that might go wrong:

1) You might make a backup with the db up and running. This may appear to "work" but when restored the parts of the db will not be in sync and you will get errors such as you report here. There is no recovery from this. Probkup has an "online" option which knows how to properly make a backup of an active db.

2) You may not backup all of the pieces of the db -- it is often the case that different parts of the db are stored in different directories. The "bi" and "ai" portions, for instance, are very often kept separately. Unless you carefully script 3rd party tools to know about these locations (and keep those scripts maintained) you will not get the full db. And when you restore, you will get messages such as those you report. Probkup knows where every piece of the database lives and will always backup and restore all of the correct bits.
 

cj_brandt

Active Member
If you don't have a backup, you'll need to force access into the db, try to run an index rebuild and then go to an ASCII dump and load. This isn't a good option, but I guess it is better than losing everything. The Progress knowledge base has some articles and warnings about this process.
The kb also has information about how to use probkup and rfutil, which I'm sure you'll be eager to learn more about.
 

amandeep.sandhu

New Member
Yes it is true that we r not using Probkup. There is an exe given by vendor to use for backup. Is there any query or databas repair options like Sql-Server DBCC commands?
 

TomBascom

Curmudgeon
What vendor?

What exe?

What version of Progress? (From the .lg file extract it looks like some ancient, obsolete and unsupported flavor of v9...)

As CJ points out you can, potentially, force your way into the db and possibly recover some data. As he also points out this is not a very good option -- you will very probably lose data and you won't have any way of knowing which parts are correct and which are not. Corruption may surface months down the road after going through such a process. Although, I suppose, it's better than losing *everything* because you have no backups.
 

tamhas

ProgressTalk.com Sponsor
You should look at the script. Have you ever restored a backup successfully or is this the first try?

My first guess would have been that you were merrily backing up the *.d* extents and not backing up the *.b* extents, but the dates in your error message suggest that the b1 extent is *older* than the *.db extent which is peculiar. So, your first step here is probably to look at the backup script and some of the dates on your backup media to see what it is that you have actually been doing that led to this mismatch. It *could* be that your backup scripts are "OK" (for OS ones, anyway) but the problem is with the restore. Investigate before doing anything drastic or you are likely to lose any chance you have.
 

amandeep.sandhu

New Member
Actually we supports ur internal retail software + Progress DB. earlier we supported sql-server in all aspects like recovery, backup, queries etc. I m new to Progress. We r using a retail software that is developed on progress. So they (ur vendor - a sister concern IT Company) provided an exe file that takes backup of all files. When we starts that exe it takes backup of all db files in rar file & save it on another drive. when we extract rar file all *b* & *d* files r shown. If We copy & paste it in Database folder then Database is restored depends upon backup date. ur database files r in c:\REM\DB folder. If we paste any old backup files to this folder ur database restored to that particular date.

Also is there any autbckup like scheduler in progress that takes automatic backup after a specific interval of time eg after 2 hours?

So finally i have to restore the old backup i have & no choice is there ?

I m very thankful to all of u for ur kind help.
 

amandeep.sandhu

New Member
Yes i already restored databases earlier that was backed up by this script on other locations. It just copy all files of ur database to another drive like drive D. Actually problem arises in the middle of working. When we started our server after sudden shutdown this error start showing. we r unable to start billing thru our software. when analysed & checked log file the above said message was written in log file & our database was not starting even we re-installed Open Edge 10.
 

tamhas

ProgressTalk.com Sponsor
First, restore one of your backups to another location. Look at the date time stamps of the files that are restored. Do you have a complete set and are the dates consistent? If not, try an earlier backup. If you don't find one with consistent dates you are hosed.

When this is all done, however awful it turns out, find out what their backup utility is doing. If it is not probkup, which it sounds like it isn't, then junk it in favor of probkup. Probkup to disk and OS backup to archive is reasonable. OS backup of a database is a recipe for exactly the kind of trouble you are having here. Bad enough and you may lose everything or at least have a mess that could take months to clean up. You might want some help from a pro.
 

TomBascom

Curmudgeon
You need training. Badly. Trying to administer a complex system with no training is a recipe for disaster. You can find out lots more about all of this stuff by attending PUG Challenge Americas ;)

Yes, you can schedule a backup.

Yes, you can do multiple backups throughout the day.

You should also implement "after-imaging" (these are called "redo logs" in the Oracle world). This allows you to recover work from the period between backups by restoring and then "rolling forward" (replaying the transactions). It is an absolutely essential part of any Progress implementation. Especially one that is being run in an unmanaged and difficult to control environment (like retail).
 

cj_brandt

Active Member
It sure looks like you have a ver 9 log, are you sure you are using OE 10 ?
Progress online knowledge base - Go to the website http://progress.atgnow.com/esprogress/categoryBrowse.do
search for truncate bi -F
If you have space, I would HIGHLY recommend making an OS backup of the db files before starting this.

There are a few commands that may need to be run depending on the issue - I don't remember what was available in ver 9. Put the error numbers you are getting into the online kb and see what it spits out.

Everyone should consider the PUG Challenge Americas - silly crazy cheap.
 
Top