Data backup/migration strategy..
Date: Fri, 8 May 2015 18:08:12 -0400
Message-ID: <BLU181-W15B72AB8A14D5654736B37D8DE0_at_phx.gbl>
Hello Everyone -
I am trying to solve a problem, I am hoping some of the smart minds here could find a solution for this.. Thanks in advance.
Problem: On a regular basis we need to perform schema backups that contain large LOBs.. the schema sizes range 5G to 1.5TB. Each schema has its own tablespace(s). Current method we are following is - stop write activities on that schema and use datapump to backup. Datapump worked good when the schema sizes were small, now they are getting larger and larger. Datapump job takes several hours and in some cases much beyond the backup window. This is painful and not really scalable.
My objective is to reduce the backup window and make it efficient. Trying to perform a backup at the physical level instead of logical..cd tai
Requirement:
We should be able to restore the backup to the same or another database environment like UAT - same version of oracle and same OS etc. Restore possibility is about 40%.
Constraints:
We have databases running on 10g and 11g. This environment has data guard (physical standby) databases. Any solution we identify should integrate with it.
Potential solutions..
1. RMAN backups: Works better and easy. Drawback is I won't be able to restore the backup to another environment. My understanding is that the DBID must be the same for the restore to work.
2. Transportable tablespaces: Probably efficient, haven't worked much with it. Drawback is we'd have to transfer the files back and forth from ASM to file system (if we need to send it to another environment)..
3. RMAN backup from standby: We do have a standby that we could potentially stop the log apply. Not sure if we could perform transportable tablespace operations easily on standby?
4. Open to suggestions..
Thanks much in advance.
-Upendra
--
http://www.freelists.org/webpage/oracle-l
Received on Sat May 09 2015 - 00:08:12 CEST