Suspend I/O with BRTools

[Former Member]

Hello,

For my backup, I need to suspend all the I/O on my DB (not only on 1 tablespace) so that I am sure that it is consistent.

Is it possible with the BRTools ? I think that when I use BRBACKUP it suspend write only on a tablespace, save it, allow writes and the continues with another tablespace, etc.

Is it right ? or does it suspend write on the full database ?

Can some one explain it to me or have a solution to suspend write ?

Thanks in advance

Thomas Fournaise

[Former Member · Accepted solution]

It's not necessary to quiesce I/O for consistent backups, at least not with Oracle. Don't confuse "quiesce I/O" with hotbackup mode, two different things.

If in fact you're talking about Oracle, then hotbackup mode is fine even if tablespaces are placed into backup mode one-at-a-time. In the event of recovery, restore all datafiles, all archivelogs created during and immediately after the last file was placed in hotbackup mode, and the controlfile after the backup (brrestore can do all this) then roll everything forward. Consistency is ensured by the archivelogs.

[Former Member · Accepted solution]

In fact my problem is that I want to save a volume group on my bay which contain all my tablespaces.

So to have a consistent volume group I need to freeze all my database and only a tablespace. If I quiesce I/O only on a tablespace, I can write on the others and so my volume group isn't consistent....

Thomas

[Former Member]

okay, not to split hairs about quiescing I/O, but putting a file or tablespace in hotbackup mode does not quiesce its I/O. Files are actively written to during hotbackup mode, only file headers are frozen, among a couple other things going on. There are white papers on Metalink that describe this in detail if in fact you're using Oracle.

I think I know what you're talking about now. To paraphrase, you want all tablespaces in hotbackup mode during the "split" (or fracture, whatever your ISV calls it). I never used BRTools for that. I either used a script (with EMC Timefinder) or EMC's Replication Manager (when using Clariion). We just didn't backup these servers using DB13 and brtools. If the capability exists, I never used it.

One word of advice....if you do this manually, then after the 'split', don't forget to switch the logfile and copy the resulting logfile to your backup server, otherwise you won't be able to recover, because you need the archivelog that contains the end backup marker. Replication Manager handles this but when using homemade scripts on a Symmetrix you may need to create this archivelog yourself. One option is to store archivelogs on a separate "volume group", so basically you split datafiles first, then switch the logfile, then split the archivelog volume. that way, the backup server contains all archivelogs needed for recovery.