Set ALL tablespaces in "START BACKUP" mode 2

[LKBrwnDBA]

A software vendor of disk-mirroring software is trying to convince management that an Oracle DB can be put in "backup mode" (all tablespaces at the same time, in order to copy the files).

I beleive if you do this, the database will at least stop alltogether.

Has anyone done this? Whats the consequence of doing this?



----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[carp]

The database will not stop. However, if there is much DML activity while the tablespaces are in BACKUP mode, there WILL be a marked increase in REDO activity. And this, in turn will crank up your ARCH activity. So you will potentially be seeing a lot of disc I/O during this time.

 

[SantaMufasa]

Carp is absolutely correct...the database continues working as usual (when one or more tablespaces are in backup mode):

ALTER TABLESPACE <ts_name> BEGIN BACKUP;

The alteration simply means that if any change occurs to a database block (even one bit flip) while the tablespace is in "backup" mode, then instead of writing just the individual change to the on-line redo log file, Oracle writes to the on-line redo log file the pre-changed image of the entire BLOCK in which the changed data reside. If any subsequent change to the same block occurs while the tablespace is in "backup" mode, then there is no need for Oracle to write again the pre-change image of the entire block to redo since the pre-change image already is in the redo log file.

This first-time writing of pre-change-image blocks represents the extra overhead to which Carp refers. Then, when you alter the tablespace to take it out of backup mode, this wholesale pre-change-block-image writing ceases:

ALTER TABLESPACE <ts_name> END BACKUP;

Let us know if this puts your mind at ease about these particular remarks of the software vendor.

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]

 

[carp]

As usual, SantaMufasa provides the superior answer - teaching you to fish instead of just throwing you a mullet!

Many people are under the impression that putting a tablespace into BACKUP mode is equivilent to putting it into READ ONLY mode and any DML is either held in memory until the tablespace comes out of backup mode (in fact, an early version of "Oracle Unleashed" apparently made a statement to this effect) or else no DML is allowed. However, you can easily demonstrate to yourself that this is not the case. Simply put a tablespace into backup mode, perform some DML, and then go observe the timestamps on your datafiles. The timestamps will have changed, indicating that indeed some modification HAS been made to the datafiles, even though their tablespace was in BACKUP mode.
So - bottom line - putting everything into BACKUP mode simultaneously will impose more overhead, and you may even see a discernible drop in performance. But the database should not lock up (unless, of course, the added REDO information causes saturation to your archiving area - in which case, your database will effectively become a read-only database until you free up some filespace for more archive log files. But that is a peripheral issue and will still not cause the DB to lock up.).

 

[LKBrwnDBA]

Great answers, thanks.

This vendor claims his sofware can do a "snapshot" of the entire 12 Terabyte db in under 60 seconds?

Well we will be testing in the next couple of weeks; the only downside is that the measurements will be inacurate because the test will be on a "test" database with NO activity!

Cheers.

----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[LKBrwnDBA]

PS: I assume the snapshot "copy" will be equivalent to a "hot backup" and as such can be easlily restored?

----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[SantaMufasa]

Actually, LK, the fact that there will be no activity should not cause any inaccuracy in the test. Again, the only major effect of database activity during a hot backup is on the on-line redo log files and their transition to archived redo log files. There is virtually no difference in the effects upon the focus of the backups -- the database data files.

So you should see an accurate representation of the software's behaviour even if the test is occurs on a relatively low-activity test database.

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]

 

[LKBrwnDBA]

Thanks again.

Actually the vendor said "less than 60 minutes" (not seconds).

We will see.

----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[Beilstwh]

I am glad you qualified that, I was greatly impressed that the vendor could backup 12 Terabytes in under a minute. LOL

Bill
Oracle DBA/Developer
New York State, USA

 

[carp]

It was a trick I was waiting for, too! That would be some noteworthy programming!

 

[Thargy]

lkbrwndba,

I also suggest a reality check here.
12 Terabytes, (12 to the power 12 bytes) * 8(to convert to bits) = 96 times 10 to the 12 bits backed up in 60 minutes, i.e. 3,600 seconds.

96 exp 12/3600 = 26.6 recurring gigabits per second, continuously for an hour. An ordinary LAN simply won't deliver this kind of throughput. Perhaps the vendor has an optical backplane running at 100 Gigabits per second or something similar? Why don't you ask how they guarantee delivery at that bit rate? This of course assumes that you live in a world of zero errors during transmission, zero overhead for chopping up the bits into packets, (assuming IP based technology) and zero overhead for reassembling it all in the same order at the other end. Oh, and I forgot to mention that their LAN must have zero contention, otherwise packet collisions will further degrade performance...

Clearly this sort of backup would never be on say a RAID 5 or 10 array, because backups are not important, and they would never want to slow things down by adding even more overhead for such redundant systems.

I know, they've got a tape streamer that writes at 26 Gigabits per second. Wow, where do they get that technology, and can I have some please?

Of course, the database doesn't move during the sixty minutes in question, so the snapshot is of course guaranteed to be self-consistent... right?

What I might find credible is that they do what RMAN does, and create a snapshot of the control files, and then backup against the SCN in the snapshot.

I scent the distasteful presence of snake oil salesmen flogging patent nostrums which cure all known ills.

Regards

Tharg

Grinding away at things Oracular

 

[LKBrwnDBA]

Test results:

Actual backup time was 1.2T per minute!!!




----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[SantaMufasa]

LK,

Can you share the contact/referral info for the technology you are considering?

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]

 

[LKBrwnDBA]

EMC^2 Symmetrix Remote Data Facility (SRDF)

The Symmetrix Remote Data Facility (SRDF®) is a business continuance solution that maintains a mirror image of data at the device level in Symmetrix® arrays located in physically separate sites.

----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[LKBrwnDBA]

Check it out here


----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb