A modest proposal

stapleto · ‎2013-05-20

It would be really nice if the OCI development team would consider this proposal:

When creating an OCI database backup, please do not automatically place that backup into a directory that then would be deleted when uninstalling OCI. (In this case, <installation_directory>\backup\db.)

I have almost screwed the pooch twice with a customer by not moving the backup out of that directory prior to the removal of the old version. Placing it in another directory, or configuring the installation package to *not* uninstall that directory, would be really lovely.

Thanks!

moechnig · ‎2013-05-21

You might consider requesting an enhancement.

I am curious, though, how you're making use of the filesystem backup in an upgrade scenario. I tried to do that once in the past when the customer I was working with was unable to download a backup via the HTTP interface because his browser timed out. I ended up discovering the hard way that the upgrade process does not run when restoring from the filesystem using the restore batch file; this led to odd failures after the new version of OCI was installed. We had to roll back to the original version of OCI, make a backup via the HTTP interface on the OCI server, and repeat the process. If we could use non-HTTP backups as a shortcut this might make such scenarios a bit quicker. Any pointers on what I did wrong?

ostiguy · ‎2013-05-21

Jim, it sounded like you were using the ..\sanscreen\backup\backup.cmd file. This generates a .sql dump of the OCI database.This is intended for bare metal restore scenarios for OCI,not for upgrades.

If you have ever looked at the upgrade.log after a restore during an upgrade, you will see all the events from "upgraders" that run after the database was actually restored - these are schema modifications/cleanups/additions. There can also be cleanup upgraders for known bugs. By using the restore.cmd to restore a sql dump, you would not have these upgraders run, meaning you could have OCI 6.x running with a OCI 6.(x-y) database, which can cause havoc as OCI tries to store stuff in tables/columns that do not exist.

I believe if you put the .sql into a zip file, and name it appropriately for the right version, you can then restore that zip through the portal in a newer version.

moechnig · ‎2013-05-21

Matt, that's exactly what I was doing wrong.

I may try the zip-and-rename workaround in a lab sometime.

I'm still curious how Mark was able to make use of the filesystem backup during an upgrade.

stapleto · ‎2013-07-24

I actually wasn't, Jim. What happened is that I had a customer do a manual backup through the web interface, and almost forgot to move the backup file before uninstalling the application in anticipation of an upgrade. After the deinstallation, we found that the ...\backup\db directory was deleted; if we hadn't hastily moved the backup file we would have lost it.