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

Thanks John, but I already know the generic issues with Oracle DB backup on SAN. That's why I was asking specifically about the FastT900.

After some research, I've found out that there is an option called "FlashCopy", which appears to be different than the third mirror approach, but am having a difficult time relating that to our scenario. Specifically, how long the DB would be in backup mode (for reasons you mentioned), what overhead is involved on the production DB before and after the copy (i.e. if it's a PIT snap, do only changed blocks from the source get copied to the target or what about changes to the target itself, since we're firing that up as a separate DB?), and what does a logical subsystem (LSS) consist of, since the source and target of the FlashCopy must exist on the same LSS?

Perhaps it's time to call a FastT Tech Sales Guru... :)

BTW, are you RAID 0ing along with your RAID 1 or are you relying on the SAN cache for performance? Whole DB or just data?

BAARFingly,
Rich

Rich Jesse                           System/Database Administrator
[EMAIL PROTECTED]                  Quad/Tech Inc, Sussex, WI USA

> -----Original Message-----
> From: John Kanagaraj [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 17, 2003 3:20 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Resend: Anyone using IBM's FastT900 SAN for Oracle DBs?
>
>
> /** 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).