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

Search Discussions

  • Jesse, Rich at Jun 17, 2003 at 9:46 pm
    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).
  • John Kanagaraj at Jun 18, 2003 at 9:58 pm
    Rich,
    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?
    We are pure RAID 1 for the whole DB (along with the Apps). It was a long
    fight, but worth it,and I had a savvy SA on my side early on.

    John

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedJun 17, '03 at 7:44p
activeJun 18, '03 at 9:58p
posts3
users2
websiteoracle.com

2 users in discussion

John Kanagaraj: 2 posts Jesse, Rich: 1 post

People

Translate

site design / logo © 2022 Grokbase