Skip to Main Content
  • Questions

  • Schema/Table level refresh using RMAN

Breadcrumb

May 4th

Question and Answer

Tom Kyte

Thanks for the question.

Asked: May 29, 2008 - 12:34 pm UTC

Last updated: June 02, 2008 - 5:16 pm UTC

Version: 10.2.0.2.0

Viewed 10K+ times! This question is

You Asked

Tom-

We want to create a process where we refresh the following schema/table level scenarios in the Non-prod environments with a copy from Production.
--Schema level refresh
--Table level refresh. e.g. tables like ABC%
--Point in time refresh using 1 and 2 above

Is it possible to use RMAN to perform this schema/table level refresh from Production? We may also get a request to perform point in time recovery.

Currently we use old exp/imp utilities to refresh schemas from Prod to Non-prod environment. We take exports of all schemas keep it on disk for 2 days before it goes on tape and offsite. If we get a request to refresh it from a particular day in the past then we request operations dept. to get the export dump file from tape to disk and then we perform the refresh.

We're looking to retire our exp/imp process and use a more efficient method like RMAN.

Your input is appreciated.

and Tom said...

RMAN can recover:

a block - only to the current point in time. block level recovery is used for media failures that corrupted a single or small set of blocks.

a file - to the current point in time.

a tablespace - to any point in time - current or past.

a database - to any point in time - current or past.


To accomplish your "schema level refresh", the suggestion would be the data pump likely. A tablespace point in time recovery will not put back in place packages, procedures and the like. Data pump can and will.

Table level refresh - depending on your needs - flashback table might be all you need. You can set an undo retention guarantee to assure you can flashback for at least so many hours. Short of that, you have a tablespace level point in time recovery - and then the ability to data pump out just a single table from that tablespace and then data pump that into the 'real' database OR if the entire tablespace just contains the table of interest - you can stop there and be done.


Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Good info

A reader, June 02, 2008 - 3:57 pm UTC

Does this mean we should continue taking our daily logical backups using emp/imp in addition to physical backups using RMAN?? or replace with data pump, in case, point in time schema refresh or recovery is required? we were thinking to stop taking logical backups completely and rely on transportable tablespace mechanism from back with RMAN. This should recover all the objects in the schema for the given point in time.
Tom Kyte
June 02, 2008 - 5:16 pm UTC

why are you taking a "logical backup", what do you do with it.


...
we were thinking
to stop taking logical backups completely and rely on transportable tablespace
mechanism from back with RMAN. This should recover all the objects in the
schema for the given point in time.
.....

only objects that consume storage, not other things like code, views and the like.
more

Connor and Chris don't just spend all day on AskTOM. You can also catch regular content via Connor's blog and Chris's blog. Or if video is more your thing, check out Connor's latest video and Chris's latest video from their Youtube channels. And of course, keep up to date with AskTOM via the official twitter account.

More to Explore

Data Pump

All of the database utilities including Data Pump are explained in the Utilities guide.