I *knew* I should have explained that more. I had some verbage that I just deleted for the sake of simplicity. And it sounded much more impressive by leaving things hanging... :)
After talking with the contractor that I worked with in setting this up, I was wrong about our physical layout. I was thinking it was a 6-wide mirrored stripe for the 6GB of datafiles. That would be silly. It's 11-wide. Yes. That's 22 total disks for just the datafiles. A full Photon (11 drives on the front, 11 on back). The redos and archives and their respective mirrors are spread across another 10 on a D1000. 32 disks in all. Da-roo-ul, da-roo-ul. Our hotbacks are nothing special. We use a home-grown, partially plagarized, simple shell/SQL script combo that serially puts each tablespace into backup mode, copies the underlying datafiles *to another disk*, then ends the backup. Pretty generic stuff. The key is that our hotbacks are disk-to-disk. Why disk-to-disk instead of disk-to-tape for us? 1) Cost. We currently use OmniBack and a custom program for tape backups across HP/UX and Solaris, and we may be moving towards Tivoli. OmniBack and Tivoli charge at least 5 figures for their Oracle, and the custom tape backup we have would have to use a script similar to the one we use for disk-to-disk. If we throw even 4 figures at systems for more disks, we're still ahead of the game dollar-wise. I won't get back into the SAN argument for the sake of brevity. I should add that our DBs are relatively small in the Oracle World. Our largest is our 28GB ERP system. 2) Reliability. To subvert to the Old Milwaukee commericals: Boys, it don't get no better than this. There's no worry about whether or not the latest patch on the backup software will work with this version or that version of Oracle. 3) Simplicity. Set TS for backup, copy files, end TS backup. K.I.S.S. (no, not the Gene Simmons kind) See "Reliability". 4) Control. For each platform and each system, we have complete control over how and when the hotbacks work. 5) Potential speed of recovery. I'd consider this a by-product advantage of disk-to-disk rather than a selling point because for us the disks are on the same system as the database, giving less weight to this point. I've been writing too long on this -- need to get back to work! Hopefully, this will explain my previous message a little better. :) Rich Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA -----Original Message----- Sent: Thursday, March 27, 2003 3:44 PM To: Multiple recipients of list ORACLE-L Rich, How did you manage to take hot backups in 90 seconds for 6 GB db size? If you could shed light on the technique, it would be helpful to us. We might also consider your approach, if feasible on our systems. TIA, Rao -----Original Message----- Sent: Thursday, March 27, 2003 4:19 PM To: Multiple recipients of list ORACLE-L FWIW, we've got an 8.1.7 system set up on Solaris8. The whole whopping 6GB of datafiles are spread across a 6-wide RAID 0+1, with redos and archives on their own 0+1s. Our hotbacks take 90 seconds. OTOH, our 28GB ERP system on an HP AutoRAID 12H takes over 2.5 hours. I'd like to be done with that in 7 minutes, extrapolating from our other system, not to mention the performance increase for our users (system-wide waits average in the 100s during the day due to physical I/O, but that's a whole other kettle of worms). :) Rich -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jesse, Rich INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
