Need to copy 9.1D Database

[Delo123]

For our Datawarehouse we need multiple copies of our Database each night.
At the Moment we do an online Backup, and restore it multiple times each night, but since the Backup File is locked by the Restore Util we have to each after another. Since our main DB is 58GB we are running out of Time.
My Idea was to let it restore one time, and then copy the folder on our SAN (to gain speed), alter the .ST File to match the altered Folder.
But then when I try to do the Prostrct repair I get an error message that the last Backup was not succesfull. Even when I try the repair on the freshly restored database (before the copyjob) I get this message.
I tried to use -C mark but this doesn't seem to work.
Am I on the right Track or could there be better ways to do this. Procopy is no option (too slow)!

 

[taqvia]

Message indicates that the last progress backup was not successful.
Do you take the online backup through progress commands or by any other way.

Can you try taking a incremental backup on the restored copy and allow it to complete and then run prostrct repair and see if the error pops up.

Also do you have the option for sync/split so that you can keep two servers on sync and split them after doing a proquiet on the source db and then run prostrct repair on the target db and start it.

Arshad

 

[Delo123]

Since it is freshly restored why does it need to be backuped again before I can copy it? But I will try the incremental. For the sync/split do you mean replication? we do not use that at the moment since we have to make changes to the restored databases so i think starting replication each day again would be too much overhead...

 

[TomBascom]

The method that you describe should work. probkup online, restore somewhere, copy at the os level, modify the .st file and prostrct repair. There is no obvious reason why that shouldn't work.

I suspect, therefore, that there is some devilish detail tripping you up and that a very careful walk-through of your process will reveal it. It's probably something silly like not copying all the files (maybe the .st file puts the bi file in another folder?) Or messing up the renaming when you modify the .st file.

As for the file-locking. That doesn't seem right. What if you were restoring from read-only media? At best it's a bug (but you're running an ancient and unsupported release so there is no hope of a bug fix). Maybe you could set the file to read-only and defeat the file-locking that way?

 

[Delo123]

The File Locking wonders me also, but this is the Answer I received from Progress Support:

I get the same behaviour with the prorest. The prorest command does indeed open the file with some exclusive lock. This is done to prevent anything interfering with the restore. There is no workaround for this.


For the Copyjob: Since I cannot do a repair to the original restored Database I guess the Problem in the copy or modify of .st.

Is it enough to just stop the Databases or should I do something more?

Will do some more testing on Monday...

Ps. Restore Somewhere... Maybe I should not start and stop the Database before copying!? Will try that