Re: Refreshing a multi TB database

Ram,

you can also consider the following scenario if you're on 10G. There is some restrictions evolved but I think it's worth considering.

1. create a physical standby from production box. We will use it as a future test ground DB.
2. enable flashback on this newly created standby.
3. activate it and open in a read write mode.

Now you have fully workable clone from production DB.

At the end of the day when you need a fresh copy:

1. close the test DB.
2. mount and flash it back to before activation point.
3. convert back to physical standby and rollforward using archivelogs from prod.
4. activate and open it in read write again.

This can (or can not!) be significantly faster than doing a full db restore depending on situation. Say your prod DB doesn't generate huge amount of logs between the refresh points and test DB doesn't generate too many flashback logs (so to roll the whole thing back and then forward takes less time than full restore+recover). You would also consider running prod in a force logging mode perhaps - again this can impact your choice.

HTH. On 3/17/07, Ram Raman <veeeraman_at_gmail.com> wrote:
> Hi all,
>
> We have a huge production database that is currently 2TB and expected to
> grow to 3TB soon. We have the corresponding test database that is only a
> third of its size and was refreshed a while ago. I would like to see
> refreshed data so we can test things more accurately in test DB. I am
> pressing for more space and better refresh methods, but I want to come up
> with some suggestions. Can you please share your opinions on this. Thanks.
>
> Some things I can think of: We have to consider the network bandwidth
> between the two servers, the space, the activity in the test DB. Is there
> anything else.
>
> Ram.
>

-- 
Alexander Fatkulin
--
http://www.freelists.org/webpage/oracle-l