Thanks again all for these tips. I am working with my client in setting up the environment to test everything out.

Regards,
André M. Clark


On July 16, 2020 at 07:21:47, Walfherder (toasters@tson.de) wrote:


On 15 Jul, André M. Clark wrote:
> ...
> Any other tips regarding data protection and replication? I know SnapCenter
> is not an option; is SnapCreator still a possibility? Minimally they are
> looking to do SnapMirrors to a DR system throughout the day and consistent
> Snapshots, while not a requirement, would be a plus. They already have a
> procedure where they shut down the database nightly to perform a cold
> backup but if we can provide any improvements on this it would be a win.

Oracle 8 is quite old, I think it probably pre-dates things like
SnapCreator, SnapCenter ... probably anything other than Snapshots :).

I once did something similar i.e. implemented hot backups of a running
Remedy AR System database on Oracle 8 on ONTAP.

As far as I can recall there was a NetApp Whitepaper or TR describing how to
implement this so that the backup was consistent at the database level and
could be recovered from, but I cannot locate that doc now.

Basically it is pretty simple, you need to script the following:

1. Check that the Oracle instance is running/available

2. Tell Oracle to place all the tablespaces that are to be backed up into
backup or "archive log mode"

3. Tell Oracle to dump the currently "active" contents of its redo logs to
its archives

4. Make a backup of the instance control file

5. Tell Oracle to write a set of instance re-creation statements to its
trace file

6. Connect to the NetApp and create a new Snapshot of the volume(s) where
the Oracle data is stored

7. Tell Oracle to take the tablespace back out of backup mode

8. Log the results

Most of those steps are fairly simple SQL commands. You run the above a
couple of times a day and the NetApp snapshot which get created contain
everything needed to restart/recreate the Oracle instance at the time that
they were created.

You should backup the archived redo logs, but not the live/current redo
logs. It's not a problem to back these up, but it doesn't bring any benefit
and during a restore you might accidentally overwrite the current versions.
Which would be bad.

Cheers,
Robb.