FAQ
/** 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).

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedJun 17, '03 at 8:04p
activeJun 17, '03 at 8:04p
posts1
users1
websiteoracle.com

1 user in discussion

John Kanagaraj: 1 post

People

Translate

site design / logo © 2022 Grokbase