Re: Getting a consistent copy
From: joel garry <joel-garry_at_home.com>
Date: Mon, 20 Jul 2009 11:22:03 -0700 (PDT)
Message-ID: <1630493d-610c-464f-a271-57d8b71a1cd1_at_i8g2000pro.googlegroups.com>
On Jul 20, 10:09 am, Pat <pat.ca..._at_service-now.com> wrote:
> We're running Oracle 10.2.0.4 on RedHat.
> We're supporting an application that requires completely consistent
> copies when it sets up what you can think of as additional cluster
> nodes.
>
> Our current process is:
> 1) Stop the source application
> 2) expdp the database (about 100G)
> 3) restart the source application
> 4) load the dump into the target server and let the app "catch up" on
> that node until it can come online
>
> This has a rather significant problem in that it requires we stop the
> source application (which is no-bueno).
>
> We tried using exp with the consistent flag, which dumped ok, but when
> we times the loads back into the system they taking > 1 day (whereas
> the data pump import takes about 2 hours).
>
> One thing we're considering trying here to achieve the same thing
> though is to use SAN snapshotting, something like this:
>
> 1) Leave the source running
> 2) SNAP /u01 on the san
> 3) Mount the SNAP on a different database server in read/write mode
> 4) Restart Oracle over there
> 5) Let it go through a recovery (since we did just crash it)
> 6) Run a data pump export out of there.
>
> Is anybody doing something like this? Does anybody know of any
> subtleties that I should be aware of? In theory the above should work
> fine, but as one of my colleagues is fond of pointing out, in theory
> you shouldn't need practise.
Date: Mon, 20 Jul 2009 11:22:03 -0700 (PDT)
Message-ID: <1630493d-610c-464f-a271-57d8b71a1cd1_at_i8g2000pro.googlegroups.com>
On Jul 20, 10:09 am, Pat <pat.ca..._at_service-now.com> wrote:
> We're running Oracle 10.2.0.4 on RedHat.
> We're supporting an application that requires completely consistent
> copies when it sets up what you can think of as additional cluster
> nodes.
>
> Our current process is:
> 1) Stop the source application
> 2) expdp the database (about 100G)
> 3) restart the source application
> 4) load the dump into the target server and let the app "catch up" on
> that node until it can come online
>
> This has a rather significant problem in that it requires we stop the
> source application (which is no-bueno).
>
> We tried using exp with the consistent flag, which dumped ok, but when
> we times the loads back into the system they taking > 1 day (whereas
> the data pump import takes about 2 hours).
>
> One thing we're considering trying here to achieve the same thing
> though is to use SAN snapshotting, something like this:
>
> 1) Leave the source running
> 2) SNAP /u01 on the san
> 3) Mount the SNAP on a different database server in read/write mode
> 4) Restart Oracle over there
> 5) Let it go through a recovery (since we did just crash it)
> 6) Run a data pump export out of there.
>
> Is anybody doing something like this? Does anybody know of any
> subtleties that I should be aware of? In theory the above should work
> fine, but as one of my colleagues is fond of pointing out, in theory
> you shouldn't need practise.
Someone on this group not long ago mentioned they would get corrupted blocks doing this. I would guess it is a block write timing issue, since the san doesn't know about Oracle blocks. You might look into the suspend operation. How many seconds frozen until "no bueno?"
Sounds like a job for a standby db, though I don't quite get what you mean by a consistent copy on additional cluster nodes. Are you intent on applying transactions? If you just need consistent read-only copies, maybe use transportable tablespaces? If you can't stop the database for putting into read-only mode, perhaps run a standby then use it as the transportable source?
jg
-- _at_home.com is bogus. http://www3.signonsandiego.com/stories/2009/jul/19/1b19madoff004933-calif-man-leads-push-recoup-taxes/?uniontribReceived on Mon Jul 20 2009 - 13:22:03 CDT