RE: Anyone using IBM's FastT900 SAN for Oracle DBs?

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 can still stretch out quite a bit depending on the backup architecture(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 - is by 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.

The issue with this 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

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 _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?]

> -----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).