Fast database copy Using RMAN during SAP System refresh
Scope of this blog is only limited to show how we used RMAN for database copy during a SAP system refresh.
- Refresh database S1E – test system from S1P (Standby) production database.
- Database size is 2.4 TB
- Both databases are located in the same host.
- Host is running RHEL 5 X64, Oracle 188.8.131.52
- S1P (Standby) is in recovery mode (mount state with archive log being applied).
(a) A simple filesystem copy. Running multiple cp process to make it faster.
(b) Some other fast copy methods; http://scn.sap.com/people/muniraju.h/blog/2012/02/23/fast-copy-of-filesystem-with-tar
(c) RMAN clone from active database.
Method (a) was slower taking up to 7 hours.
With method (b) we could achieve average copy speed of 12 GB per minute taking up to 3 hours, whereas the tar copy resulted in corrupt blocks. Even though database recovery was successful, it was not fit for operational use with corrupted blocks. It is tiresome to identify and fix corrupt blocks and we ended up doing the copy again.
Method (c) worked brilliant. The copy speed touched 15 GB per minute taking up to 2 hours for copy. It also recovered the database to a consistent state, without any block corruption.
Explaining Method (c) – RMAN to clone database
On target (S1E) database
Make sure the password is same on source and target database. Generate the password file if necessary.
orapwd file=orapwS1E password=pass force=y
Put below parameters for S1E – initS1E.ora file
DB_FILE_NAME_CONVERT = ‘S1P’,’S1E’
LOG_FILE_NAME_CONVERT = ‘S1P’,’S1E’
On source (S1P) database
Configure TNSNAMES to tnsping S1E
Start S1P (standby) in open read only mode
rman target sys/pass@S1PSBY
CONNECT AUXILIARY SYS/pass@S1E
DUPLICATE TARGET DATABASE to S1E from active database NOFILENAMECHECK;
If you want RMAN to use copy multiple files in parallel, you have to set the parallelism before starting the DUPLICATE TARGET command.
For example, below command enables 5 channels. 5 files are copied in parallel.
CONFIGURE DEVICE TYPE DISK PARALLELISM 5 BACKUP TYPE TO BACKUPSET;
Can you provide any details related to how the database filesystems were related from the network and SAN / NAS perspective to help understand how the read and write speeds were achieved outside of using RMAN?
Can you be more specific with your question please?
In this case, both source & target databases are residing on the same host. Therefore linstener/ tnsname were configured to use localhost (127.0.0.1).
There are 11 filesystems (sapdata1 .... sapdata11) each of 200 GB.
I think EMC DMX is the underlining storage provided by our Datacenter (Application hosting provider).
Thanks, that's basically what I was looking for. Nice work on the post!
Both databases are located in the same host.
Does it mean that S1E and S1P are on the same host?
Yes, in my case. Whereas this method can be used even if they are no different hosts.