Reduced Backup as tersting instance [message #202122] |
Wed, 08 November 2006 04:42 |
s-bolz
Messages: 10 Registered: September 2006
|
Junior Member |
|
|
Hi,
I would like to know, how I can create a "backup" of a database (10g) which is reduced in size and volume. The cause is, that our test systems don't need all the datasets of our productive database, about 10 % are sufficient. Of course the new instance must provide a consistent view on the data, i.e. all direct and indirect relationships must be preserved.
Does anyone have an idea and can tell me where to look for a solution? Maybe Oracle has a built-in feature, that can help us with that?
Thank you very much,
Sebastian
|
|
|
Re: Reduced Backup as tersting instance [message #202125 is a reply to message #202122] |
Wed, 08 November 2006 05:00 |
n_de_fontenay
Messages: 33 Registered: October 2006 Location: Paris
|
Member |
|
|
Hi,
it is possible to compress the backupsets.
It's a configuration parameter.
Connect to RMAN and type the following:
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET;
The compression rate is pretty good.
One thing you should know is:
Don't use tape compression if you are already using RMAN compression. (as stated in RMAN backup and recovery guide)
hope this helps,
Nicolas
|
|
|
|
|
Re: Reduced Backup as tersting instance [message #202171 is a reply to message #202125] |
Wed, 08 November 2006 08:19 |
s-bolz
Messages: 10 Registered: September 2006
|
Junior Member |
|
|
Hi Nicolas,
thanks for the hint, but we explicitly want to reduce the amount of data sets. Compression of the backup would mean decompression before use and that means performance overhead for our developers.
But thanks for your efforts, anyway.
Sebastian
|
|
|
Re: Reduced Backup as tersting instance [message #202174 is a reply to message #202132] |
Wed, 08 November 2006 08:34 |
s-bolz
Messages: 10 Registered: September 2006
|
Junior Member |
|
|
Hi Mahesh,
we want the smaller database for our Software developers. There are several teams and the team work on different features. That means, we need several databases for them, to code against. The point here is, that we don't need different copies of our productive data that are based on different times in history. Instead we need different copies in terms of the DDL information of the databases. But every copy needs consistent data, of course.
If I understood your reply correctly, you suggest the following:
- Extract the schema information
- Rebuild the schema in an empty database
- Extract a percentage (e.g. with the SAMPLE clause) from the "origin" tables and insert them into the new database
- Extract the data sets from the other tables that reference the extracted data from the origin tables and insert them into the new database as well
Thanks for the link, I have not had the time to look into it right now, but I definitely will. Thanks for the hint on TOAD's built-in feature as well. Maybe this will help, too.
Sebastian
|
|
|