When converting a database from one operating system to another one (to phase out your Itanium infrastructure for example) you may be tempted to play with parallelism parameter when converting your tablespaces (having one datafile in our example). This RMAN convert phase is obviously needed when your destination platform endian format is not he same:
SQL> SET lines 130 SQL> col PLATFORM_NAME FOR a40 SQL> SELECT platform_name, endian_format FROM v$transportable_platform ORDER BY 1; PLATFORM_NAME ENDIAN_FORMAT ---------------------------------------- -------------- AIX-Based Systems (64-bit) Big Apple Mac OS Big HP IA OPEN VMS Little HP OPEN VMS Little HP Tru64 UNIX Little HP-UX (64-bit) Big HP-UX IA (64-bit) Big IBM POWER Based Linux Big IBM zSeries Based Linux Big Linux 64-bit FOR AMD Little Linux IA (32-bit) Little Linux IA (64-bit) Little Microsoft Windows 64-bit FOR AMD Little Microsoft Windows IA (32-bit) Little Microsoft Windows IA (64-bit) Little Solaris Operating SYSTEM (AMD64) Little Solaris Operating SYSTEM (x86) Little Solaris[tm] OE (32-bit) Big Solaris[tm] OE (64-bit) Big 19 ROWS selected. |
You see in below example that a datafile conversion is sequential and parallelism is not apply at all (testing has been done with Oracle 10.2.0.3.0 on HPUX IA 11.23):
server1{oracle}# rman Recovery Manager: RELEASE 10.2.0.3.0 - Production ON Thu Apr 7 17:35:28 2011 Copyright (c) 1982, 2005, Oracle. ALL rights reserved. RMAN> CONNECT target / connected TO target DATABASE: DB1 (DBID=329576362) RMAN> show ALL; USING target DATABASE control FILE instead OF recovery catalog RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # DEFAULT CONFIGURE BACKUP OPTIMIZATION OFF; # DEFAULT CONFIGURE DEFAULT DEVICE TYPE TO DISK; # DEFAULT CONFIGURE CONTROLFILE AUTOBACKUP OFF; # DEFAULT CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # DEFAULT CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # DEFAULT CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # DEFAULT CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # DEFAULT CONFIGURE MAXSETSIZE TO UNLIMITED; # DEFAULT CONFIGURE ENCRYPTION FOR DATABASE OFF; # DEFAULT CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # DEFAULT CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # DEFAULT CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/ora_db1/software/dbs/snapcf_db1.f'; # DEFAULT RMAN> SQL 'alter tablespace DMDATA3 read only'; SQL statement: ALTER TABLESPACE DMDATA3 read only RMAN> CONVERT TABLESPACE DMDATA3 TO platform 'Linux 64-bit for AMD' format '/backup/%U'; Starting backup AT 07-APR-11 USING channel ORA_DISK_1 channel ORA_DISK_1: starting datafile conversion input datafile fno=00007 name=/ora_db1/data01/db1/dmdata3_01.dbf converted datafile=/backup/data_D-DB1_I-329576362_TS-DMDATA3_FNO-7_01m96nr6 channel ORA_DISK_1: datafile conversion complete, elapsed TIME: 00:05:06 Finished backup AT 07-APR-11 RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET; NEW RMAN configuration parameters: CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET; NEW RMAN configuration parameters are successfully stored released channel: ORA_DISK_1 RMAN> CONVERT TABLESPACE DMDATA3 TO platform 'Linux 64-bit for AMD' format '/backup/%U'; Starting backup AT 07-APR-11 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=402 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=433 devtype=DISK channel ORA_DISK_1: starting datafile conversion input datafile fno=00007 name=/ora_db1/data01/db1/dmdata3_01.dbf converted datafile=/backup/data_D-DB1_I-329576362_TS-DMDATA3_FNO-7_02m96o7p channel ORA_DISK_1: datafile conversion complete, elapsed TIME: 00:05:45 Finished backup AT 07-APR-11 |
This last example of conversion clearly demonstrate that main bottleneck is I/O and that figures are quite erratic if other processes are using same disk:
RMAN> CONVERT TABLESPACE DMDATA3 TO platform 'Linux 64-bit for AMD' format '/backup/%U' parallelism=6; Starting backup AT 07-APR-11 USING channel ORA_DISK_1 USING channel ORA_DISK_2 USING channel ORA_DISK_3 USING channel ORA_DISK_4 allocated channel: ORA_DISK_5 channel ORA_DISK_5: sid=423 devtype=DISK allocated channel: ORA_DISK_6 channel ORA_DISK_6: sid=418 devtype=DISK channel ORA_DISK_1: starting datafile conversion input datafile fno=00007 name=/ora_db1/data01/db1/dmdata3_01.dbf converted datafile=/backup/data_D-DB1_I-329576362_TS-DMDATA3_FNO-7_04m96otf channel ORA_DISK_1: datafile conversion complete, elapsed TIME: 00:03:25 Finished backup AT 07-APR-11 RMAN> CONVERT TABLESPACE DMDATA3 TO platform 'Linux 64-bit for AMD' format '/backup/%U' parallelism=1; Starting backup AT 07-APR-11 USING channel ORA_DISK_1 channel ORA_DISK_1: starting datafile conversion input datafile fno=00007 name=/ora_db1/data01/db1/dmdata3_01.dbf converted datafile=/backup/data_D-DB1_I-329576362_TS-DMDATA3_FNO-7_05m96p9m channel ORA_DISK_1: datafile conversion complete, elapsed TIME: 00:03:25 Finished backup AT 07-APR-11 |
But parallelism parameter do have an interest when converting, one shot, a whole database and/or tablespaces with many datafiles (more common configuration). In this case each channel will handle a datafile and will parallelize the job, having fast disk for target directory is, in this case, mandatory…
About Post Author
