Came across this today, and thought that I would share it just in case other people struggle
version 11.0, Windows 7
scenario:
Restore db from backup
prorest mydb c:\temp\mydb.bak -verbose This is a full backup of C:\somedb\mydb.db. (6759) This backup was taken Wed Mar 21 11:38:59 2012. (6760) The blocksize is 4096. (6994) It will require a minimum of 37405 blocks to restore. (6763) Start of restoring the target DB... (9433) Read 26112 db blocks in 00:00:01
tried to start a server process
proserve mydb
OpenEdge Release 11.0 as of Fri Dec 2 19:01:49 EST 2011
21:16:37 BROKER This broker will terminate when session ends. (5405)
21:16:37 BROKER The startup of this database requires 17Mb of shared memory.
Maximum segment size is 128Mb.
21:16:37 BROKER 0: Multi-user session begin. (333)
21:16:37 BROKER 0: Before Image Log Initialisation at block 9229 offset 2185.
(15321)
21:16:37 BROKER 0: omGetObjectRecord: recGet call failed. (7138)
21:16:37 BROKER 0: omGetObjectRecord failed to get record rc = -1. (7141)
21:16:37 BROKER 0: error -1215 reading record 1075 (3839)
21:16:37 BROKER 0: Login by julian on CON:. (452)
21:16:37 BROKER 0: Error reading _Db record, error -1215
21:16:37 BROKER 0: The normal shutdown of the database will continue for 10 Min
0 Sec if required. (15193)
21:16:37 BROKER 0: Begin normal shutdown (2248)
21:16:38 BROKER 0: Resending shutdown request to 0 user(s). (2263)
21:16:42 BROKER 0: At Database close the number of live transactions is 0. (151
09)
21:16:42 BROKER 0: Before Image Log Completion at Block 9229 Offset 2185. (1574
3)
21:16:42 BROKER 0: Logout by julian on CON:. (453)
21:16:42 BROKER : Multi-user session end. (334)
21:16:42 BROKER ** This process terminated with exit code 1. (8619)
ouch. restore completed ok, so surely the backup couldn't be corrupt ? Spent a couple of hours trying to figure out what happened.
Final analysis ?
the mydb.bak backup file was from version 10.2 ....
so, version 11 restores a v10.2 backup, but has problems ....
let's do it right ...
set DLC=C:\Progress\OpenEdge\bin\102dbutils
c:\Progress\OpenEdge\bin\102dbutils\102b05_dbutil prorest mydb c:\temp\mydb.bak -verbose
This is a full backup of C:\somedb\mydb.db (6759)
This backup was taken Wed Mar 21 11:38:59 2012. (6760)
The blocksize is 4096. (6994)
It will require a minimum of 37405 blocks to restore. (6763)
Start of restoring the target DB... (9433)
Read 26112 db blocks in 00:00:01
c:\Progress\OpenEdge\bin\102dbutils\102b05_dbutil mydb -C truncate bi
set dlc=
proutil mydb -C conv1011
OpenEdge Release 11.0 as of Fri Dec 2 19:01:49 EST 2011
You must have your database backed up before running the conversion. (1024)
Have you done this (y/n) ?
y
VST Table Deletion has begun. Please standby. (6876)
VST Table Deletion has completed successfully. (6885)
Conversion completed, database is now in 11 format.
PLEASE IMMEDIATELY BACK UP YOUR NEWLY CONVERTED Progress OpenEdge Release 11 DATABASE !!! (11115)
proserve mydb
OpenEdge Release 11.0 as of Fri Dec 2 19:01:49 EST 2011
21:34:12 BROKER This broker will terminate when session ends. (5405)
21:34:12 BROKER The startup of this database requires 17Mb of shared memory. Maximum segment size is 128Mb.
21:34:12 BROKER 0: Multi-user session begin. (333)
21:34:12 BROKER 0: Before Image Log Initialisation at block 0 offset 1277. (15321)
21:34:12 BROKER 0: Login by julian on CON:. (452)
so, just to recap - be very careful of what you restore in 11
Hasn't it always been true that one needed to use the restore corresponding to the version of the backup?
Admittedly, a error message would have been nice!
the "no warning / error message" was kinda the moral of the story
so, just to recap - be very careful of what you restore in 11
I'd report it as a bug to the ETSC. No admin utility should leave you with a corrupted DB. With or without a warning message.
The nearest fix would be that the 11 restore cancels because it recognizes it's a backup from another version.
The optimum solution would be that the 11 restore would restore in 10.2 file format and then offers to do conv1011 automatically.
I may even have reported this in beta.
I agree, at the very least this should not be allowed to proceed.
It truly would be a "cool thing" if the restore utility recognised the backup as a 10.2 and used the 10b05util.exe to restore the database, truncate the bi and then perform a conv1011