Skip to Content

Scope of this blog is only limited to show how we used RMAN for database copy during a SAP system refresh.

Scenario

  • 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 11.2.0.2
  • S1P (Standby) is in recovery mode (mount state with archive log being applied).

Possible Methods:

     (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’

startup nomount

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;

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Josh Fisher

    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?

    Thanks,

    Josh

    (0) 
    1. Muniraju Hanumanthiah Post author

      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).

      Regards,

      Muniraju

      (0) 

Leave a Reply