Progress 9.1A database abnormal shutdown

A

Adrian GURIA

New Member
Hi all,

I'm in very deep trouble. I have a progress 9.1A05 database running on Solaris 9. The application we use connects to the database by remote client.
Friday one user stop responding so I forced to stop; then I disconnected all other users normally and tried to shut down the database. After a long time it did shutdown, but when I tried to restart the database it was taking very very long, the bi file started grow a huge size and I killed the process proserve. right now I don't know what to do. Is the database corrupted? Shoud I try to restart the database and let progress do the recovery?
Anyone please help...

Here is the last entries in .lg file:

Code: 
                Fri Jul 10 06:51:46 2009
[...]
10:01:01 SRV     2: Login usernum 23, userid Administrator, on . (742)
[...]
11:47:36 SRV     2: Usernum 23 terminated abnormally. (794)
11:47:36 SRV     2: Begin transaction backout. (2252)
11:51:58 SRV     2: Transaction backout completed. (2253)
11:51:58 SRV     2: Logout usernum 23, userid Administrator, on . (739)
[...]
13:56:12 SRV     1: Login usernum 22, userid Administrator, on . (742)
[...]
14:47:01 SRV     1: Usernum 22 terminated abnormally. (794)
14:47:01 SRV     1: Begin transaction backout. (2252)
[...]
15:10:30 SHUT    5: Server shutdown started by root on /dev/pts/2. (542)
15:10:30 BROKER  0: Begin normal shutdown (2248)
15:10:30 SRV     4: Stopped. (2520)
15:10:30 SRV     3: Stopped. (2520)
15:10:30 SRV     2: Stopped. (2520)
15:11:00 BROKER  0: Sending signal 14 to 1 connected user(s). (2261)
15:11:30 BROKER  0: Sending signal 2 to 1 connected user(s). (2261)
15:12:00 BROKER  0: Resending shutdown request to 1 user(s). (2263)
15:15:19 SHUT    5: KILL signal received. (298)
15:15:30 BROKER  0: Sending signal 14 to 1 connected user(s). (2261)
15:16:00 BROKER  0: Sending signal 2 to 1 connected user(s). (2261)
15:16:30 BROKER  0: Sending signal 15 to 1 connected user(s). (2261)
15:16:30 SHUT    2: KILL signal received. (298)
15:16:30 SRV     1: SIGTERM received. (3694)
15:17:31 BROKER  0: Destroyed user 1 pid 2687. (2251)
15:17:32 BROKER  0: Disconnecting dead server -1. (2525)
15:17:32 BROKER   : Removed shared memory with segment_id: 128
15:17:32 BROKER   : Removed shared memory with segment_id: 129
15:17:32 BROKER   : Removed shared memory with segment_id: 130
15:17:32 BROKER   : Removed shared memory with segment_id: 131
15:17:32 BROKER   : Multi-user session end. (334)

                Fri Jul 10 15:19:44 2009
15:19:44 BROKER  0: Multi-user session begin. (333)
15:19:48 BROKER  0: Begin Physical Redo Phase at 79232 . (5326)
15:19:49 BROKER  0: Physical Redo Phase Completed at blk 80373 off 981 upd 0. (7161)
15:19:49 BROKER  0: Begin Physical Undo 1 transactions at block 80373 offset 1005 (7163)
15:29:56 BROKER  0: Physical Undo Phase Completed at 66759 . (5331)
15:29:56 BROKER  0: Begin Logical Undo Phase, 1 incomplete transactions are being backed out. (7162)

I forgot to mention that I have no current backup. Last backup is 1 month old.
 
It sounds like the user that started all of this probably had a large transaction in process. That transaction must be rolled back as part of the database restart. (That's why the bi file is growing.) If you're lucky you just have to wait for it to finish.

If you are unlucky you will run out of space for the bi file. If that happens you may have an unrecoverable crash.

Do not kill the db server. That will only make it worse and may lead to an unrecoverable situation.

BTW Progress 9.1A is ancient, obsolete and unsupported. You should upgrade.

While you're at it you might want to reconsider your backup schedule. And, of course, you should be running after-imaging so that you can recover from fiascoes like this.
 
Thank you Tom for reply.

Indeed our Progress is very old but the application we use is also an old app with no upgrade since 2001.

I have restarted the server and after logical undo phase the .bi file was 1.6 GB for a database of 1.9 GB but.

Right now I dump the database and send the data to our app producer so they figure out what was wrong.

I have one more question: now that the undo was successfully can I truncate the .bi file? It takes a while to start the database and I think that is because of the size of .bi file.
 
There are a great many good reasons to upgrade that have nothing to do with whether or not the application itself has changed. (Progress) bug fixes, performance enhancements, security, platform support, 3rd party interfaces (like ODBC) and just simple basic support are all good enough reasons by themselves. If you have been paying Progress maintenance you should upgrade. It's what you are paying for.

Yes, now that you have successfully restarted you should shutdown cleanly and truncate the bi file.
 
You must log in or register to reply here.
Back
Top