Re: rman duplication question

On Nov 12, 7:11 am, Chuck <skilover_nos..._at_bluebottle.com> wrote:
> I have a question for the experts about rman duplication.
>
> First let me explain the problem. We do "refreshes" of development
> databases using an rman duplicate of our production database (exp/imp
> would take way too long). But on production the undo tablespace is
> usually huge compared to the dev ones. So huge that sometimes there's
> not enough space to copy it to dev.
>
> Here's my quesiton. Do I really need to copy that huge undo tablespace?
> If it's only going to be used for recovery of the duplicate, can I do
> something like this? Create a relatively small undo tablespace that is
> not active on the production db. It would only be big enough to do the
> recovery on the aux db. It's sits there idle and never gets used in
> production. Then when I am duplicating to aux, on the aux instance set
> up the init parameters to use that small rollback, and SKIP the big undo
> tablespace.
>
> Shouldn't this work? I mean, doesn't the duplicate process only need an
> undo (any undo) to make the aux db transactionally conistent for recovery?

I haven't really thought this through, but see metalink Note: 433992.1. I suspect you'll find that the big one needs to be copied anyways, but maybe you can link some directory to /dev/null and rename the big one to there... worth a try, anyways, we might all learn something. You need the undo for any uncommitted transactions, so the notion of not bringing over the undo duplicating a fuzzy set of data is kind of anathema to hotness... you may need to run full table scans on all tables before duplicating to avoid any deferred block writing issues.

If you have a fast network, you might consider just CTAS everything with the target db in noarchivelog mode. With a bit of thought, "everything" may not need to be all the data.

jg

--
@home.com is bogus.
"When life hands you lemons, squirt your enemies in the eye with lemon
juice." - From a kid's book about bunny philosophy.