/** Resending, as I fat-fingered the previous one :( **/ Rich,
There are two big issues with backup of an OLTP VLDB such as an ERP database: Backup window, and redo generation during hot backup mode. Disk I/O and network degradation during backup are also issues, albeit to a lesser extent. While RMAN would obviate the redo generation part, your backup window when using RMAN can still stretch out quite a bit depending on the backup architecture and capacity (dedicated backup server, tape libraries, drive speed and streaming, network segregation, disk staging capability, etc.) One of the best ways of performing backup of an OLTP VLDB is by the use of mirroring technologies - Hitachi ShadowImage, EMC BCV, IBMs whatever-it-is - and breaking off a mirror copy when the *whole* database is in Hot backup mode. The backup can then be read off the mirror copy using a path that is different from the production path in the network fabric. Another option is presenting this copy to the server that performs the backup so the production box never suffers. This implies of course that you have a large enough SAN, and have configured the mirrors, _and_ the backup server is connected to the same SAN as the ERP and is thus able to mount the now-broken mirror in the latter option. The issue with this approach is the resync that takes place when the mirror is brought back for resilvering. If the mirror copy is placed in the same server (i.e. not broken out) then resync takes much lesser time - and hour or two depending on the amount of writes as well as the efficiency of the SAN software. Some of the SANs are also able to perform a lazy catch-up where busy disks are left for later catchup, etc. We have used this technique successfully [ not on IBM or EMC though, although there is no reason why this cannot be done ], but it costs $$. And I have an _all_ RAID 1 volumes on the ERP SAN, after having successfully fought off a RAID5 'initiative' when we moved from a previous box :) [Mogens - Does this qualify me for an elevated status in the BAARF party?] John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 Great, positive uplifting Christian music - http://www.klove.com ** The opinions and statements above are entirely my own and not those of my employer or clients ** > -----Original Message----- > From: Jesse, Rich [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 17, 2003 11:30 AM > To: Multiple recipients of list ORACLE-L > Subject: Anyone using IBM's FastT900 SAN for Oracle DBs? > > > We're testing a FastT900 > (http://www.storage.ibm.com/disk/fastt/fast900/index.html) to > see how it > will handle our IO thruput, but we've got one question as to > how we're going > to do our daily "snapshot" of our production DB. > > With our current RAID set (HP's AutoRAID -- that's why we're > looking for a > new solution. BAARF -- Battle Against Auto Raid > Filesystems?), we do a > simple hot backup and copy the production DB's datafiles > tablespace-by-tablespace to a JBOD. Once that JBOD copy is > put to tape, we > recover it as a new database for our users to do what-if ERP > scenarios. > We're wondering how to accomplish this with the FastT900. > Yes, we could do > it the same way, but that seems to be a waste of Big SAN > Power, doesn't it? > > The big difference between our current layout and the > FastT900 layout is > that the former-JBOD copy of the production DB will now reside on the > FastT900 along with the production DB. I guess what I was > thinking was to > put all TSs into hot backup mode, perform some FastT900 magic > in less than > "X" minutes to copy the DB, then end backup mode on the TSs. > No, I don't > know what the "X" threshold is yet -- for the sake of > argument, let's say > "10". > > So, does anyone with experience on the FastTs have any ideas? > Some of the > terms thrown out are Business Continuous Volumes and Third > Mirrors, although > it doesn't seem like the FastT900 supports a third mirror, > and I'm a bit > skeptical (a DBA trait?) about the time it would take to > resync the mirrors > before we could do our snapshot. I'm contacting the Sales > guys, too, but > thought I'd see if anyone from an SA/DBA standpoint (hey, > some of us do > BOTH, OK?) would have any pertinent thoughts. > > Thanks! > > Rich > > Rich Jesse System/Database Administrator > [EMAIL PROTECTED] Quad/Tech Inc, Sussex, WI USA > > p.s. No disks were subjected to RAIDs outside of 10 and/or > 0+1 in these > tests. > -- > 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). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: John Kanagaraj 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).
