Shulou(Shulou.com)06/01 Report--

The downtime required to migrate data using cross-platform transport tablespaces is proportional to the amount of data being migrated. However, when using incremental backup for cross-platform migration, the downtime required to migrate data can be significantly reduced.

The main steps of traditional cross-platform transfer tablespaces:

1. Set the transferred tablespace in the source database to read only

two。 Transfer the data files related to the transmitted tablespace to the target host

3. Convert the data file to the byte order used by the target host

4. Use data pump to export metadata for objects stored in the transferred tablespace from the source database

5. Use data pump to import metadata for objects stored in the transferred tablespace in the target database

6. Use the transferred tablespace in the target database to set to read write

Because the tablespace must be read only during data transfer, the data owned by the application cannot be used by the user during transmission. Because the operation is serial, downtime depends on the amount of data. If the amount of data is large, the data file transfer and conversion time will be very long, so the downtime will be very long.

Use cross-platform incremental backups to reduce downtime

To reduce downtime, you need to use XTTS,Oracle to enhance RMAN's ability for cross-platform transfers to roll forward copies of data files using incremental backups. By using a series of incremental backups, each incremental backup is smaller than the previous one, and the data in the target system can almost be obtained from the source system before downtime is required. The downtime required for data file transfer and conversion is determined by the amount of data in the source system that has been changed after the last incremental backup.

Cross-platform incremental backups do not affect the time taken by XTTS to perform other operations, such as the export and import of metadata. Therefore, when the database has a large amount of metadata, you will see that the benefits of using cross-platform incremental backups to perform the migration are affected, because the time required for the migration is usually determined by the metadata operation. it is not determined by data file transfer and conversion operations.

Only table spaces that physically store migrated database objects need to be transferred to the target system. If other objects that need to be migrated are stored in different tablespaces (for example, pl/sql objects, sequences, etc., stored in system tablespaces), you can use data pump to copy these objects to the target system.

The main steps for using cross-platform incremental backup to transfer tablespaces are as follows:

1. Preparation phase (source data remains in online state)

. Transfer the data files related to the migrated tablespace to the target system

. If necessary, convert the data file to the byte order used by the target system

two。 Roll forward phase (source data remains in online state-can be repeated as many times as needed to match the source database file with the target data file)

. Create an incremental backup in the source system

. Transfer incremental backup to the target system

. Convert the incremental backup to the byte order used by the target system and apply the backup to the target data file copy

Note that for a script with version 3, if a data file is added to the table space or a new table space name is added to the xtt.properties file, an alarm message and additional instructions need to be executed.

3. Transfer phase (source data is read only)

. Set the tablespace in the source database that needs to be transferred to read only

. Perform the roll forward phase for the last time, which ensures that the copy of the target data file is consistent with the data file in the source database. This step takes less time than traditional XTTS methods because incremental backups are used.

. Use data pump to log out the metadata of objects stored in related tablespaces from the source database

. Use data pump to export metadata for objects stored in tablespaces in the target system

. Set the related tablespaces in the target database to read write

This article provides an example of how to use cross-platform incremental backups to reduce downtime for transport tablespaces.

The source system can be any platform referenced by the prerequisites and satisfied by the platform and database. If you are migrating from a small byte order platform to Oracle Linux, the most important way to consider is to use Data Guard, which can be found in Note 413484.1 on the heterogeneous platforms supported by Data Guard between the current small byte order platform and Oracle Linux. For Oracle 12c, use Note 2005729.1 12C-Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup. Or NOTE: Neither method supports 12c multitenant databases. Enhancement bug 22570430 addresses this limitation.

This article describes how to migrate tablespaces cdzj,ldjc from the Redhat Linux platform to the Aix platform using the transport tablespace method of cross-platform incremental backup. After the initialization phase, perform the following three phases to perform the data migration operation:

Preparation stage

In the preparation phase, the data files in the table space to be transferred are transferred to the target system and converted to the byte order used by the target system. The application can fully access the source data during the preparation phase. RMAN backup or dbms_file_transfer is used in the preparation phase, and how to select the method to be used in the preparation phase will be described in detail later.

Roll forward phase

In the roll forward phase, the data files converted in the preparation phase will be rolled forward using an incremental backup from the source database. By performing this phase of operation many times, each successful incremental backup will be applied to the data file copy smaller and faster, allowing the data in the target system to come from the source system. The application has full access to the source data during the roll forward phase.

Transmission stage

During the transfer phase, the tablespace to be transferred in the source database is set to the read only state, and the last incremental backup is performed on the source platform and transferred to the target platform and applied to the data file copy, using the data file copy in the target system is consistent with the data file protection in the source database. Once the state of the data file is consistent, the metadata of the objects stored in the transferred tablespace is exported from the source database and imported on the target platform. Finally, the transferred tablespace is set to read write state in the target database. The application cannot update the source data during the transfer phase.

Scripts supported by cross-platform incremental backups

The core function of cross-platform incremental backup is based on Oracle 11.2.0.4 and later. Please check the conditions and recommendations section for more information. Another set of supporting scripts is stored in rman-xttconvert_2.0.zip. There are two main supported scripts:

Perl script xttdriver.pl this script is used to perform the main steps of cross-platform incremental backup transfer tablespaces.

. Parameter file xtt.properties this file contains your own platform-specific configuration

Conditions and suggestions for performing cross-platform incremental backup to transfer tablespaces

Conditions for performing cross-platform incremental backup transfer tablespaces

Before performing a cross-platform incremental backup transfer tablespace, you need to check that the following conditions are met:

. Restrictions on transport tablespace

. Other conditions that must be met

Windows is not supported in the current version

The compatible parameter of the source database must be set to 10.2.0 or later

The compatible parameter of the source database must not be larger than the compatible parameter of the target database

The source database must have archivelog schema enabled

Although the preferred target system is the Linux operating system (which can be a 64-bit Oracle Linux or a certified Redhat Linux), this process can also be performed in other Unix operating systems. However, the version of the database must be 11.2.0.4 for any non-Linux operating system

The version of the source database must be less than or equal to the version of the target database

The default device type for RMAN should be configured as DISK

The RMAN of the source database cannot be configured with COMPRESSED for DEVICE TYPE DISK. If you use COMPRESSED configuration, you may return: ORA-19994: cross-platform backup of compressed backups different endianess.

The tablespace to be migrated in the source database must be online and cannot contain offline data files. The tablespace must be in the read write state. If the tablespace is read only, then you can use the normal XTTS method for migration.

. The user performing actions in all steps must be an Oracle user and a member of the OSDBA group. Operating system audits are used to connect the source database to the target database.

. If the prepare method selects dbms_file_transfer, the target database version must be at least 11.2.0.4.

. If the preparation method selects RMAN, then a provisioning area is created in both the source and target systems.

. This operation is not supported for backup or snapshot backup.

. If the target database version is 11.2.0.3 or earlier, you need to have an 11.2.0.4 database home directory on the target system to run an instance of 11.2.0.4 to perform incremental backup conversion operations. If the target database version is 11.2.0.3 or earlier, a separate incremental conversion of the Home directory and instance with version 11.2.0.4 is required. If ASM uses the translation Home of 11.2.0.4, then the version of ASM must also be 11.2.0.4, otherwise ORA-15295 will be triggered (ORA-15295: ASM instance software version 11.2.0.3.0 less than client version 11.2.0.4.0).

Entire database migration

If the cross-platform incremental backup transfer tablespace is used to reduce the migration time of the entire database, please refer to the XTTS guide Platform Migration UsingTransportable Tablespaces (maa-wp-11g-platformmigrationtts-129269.pdf) provided by MAA. This migration method can also be used for Oracle 12c, but there is an alternative method for 12c to refer to Note 2005729.1 12C-Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup.

Select the preparation phase method

In the preparation phase, the data files in the table space to be transferred are transferred to the target system and converted by executing the xttdriver.pl script. There are two methods available:

1. Using dbms_file_transfer (DFT) transport (using xttdriver.pl-S and-G options)

two。 Use RMAN backup (using the xttdriver.pl-p and-c options)

The dbms_file_transfer method uses the dbms_file_transfer.get_file () procedure to transfer data files from the source system to the target system through dblink. The dbms_file_transfer method has the following advantages over the RMAN method:

1. There is no need to create a provisioned directory on the source or target system

two。 The conversion of the data file is performed automatically when the data file is transferred-there is no need to perform the conversion operation here.

The dbms_file_transfer method can only be used if the following conditions are met:

. The target database must be version 11.2.0.4. Note that incremental conversion of Home directories or instances does not participate in the file transfer operation of dbms_file_transfer.

. There is a database directory object in the source database that points to the data file to be copied.

. There is a database directory object in the original target database that points to the data file to be stored.

. There is a dblink connection to the source database in the target database

The RMAN backup method executes RMAN on the source system to generate a backup of the data files to be transferred. The generated backup files must be manually transferred across the network to the target system. The data files are converted by performing RMAN on the target system, and if necessary, the RMAN conversion operation stores the output data files in the directory where the target database finally stores the data files. In the original version of xttdriver.pl, only this method is supported. The RMAN backup method must meet the following conditions:

. Prepare directories need to be created for copies of the data files created by RMAN on both the source and target systems. The prepared directory points to the parameters dfcopydir and stageondest in the xtt.properties file, respectively. The final storage directory of the converted data file points to the parameter storageondest in the xtt.properties file.

Details on the instructions provided by these methods are described later, and the dbms_file_transfer method is recommended.

The target database version 11.2.0.3 or earlier requires the installation of a separate incremental conversion home and the core functionality of the instance cross-platform incremental backup (for example, incremental backup conversion) is based on Oracle 11.2.0.4 and later. If the target database version is 11.2.0.4 or later, the target database can perform this function. However, if the target database version is 11.2.0.3 or earlier, in order to perform the incremental backup conversion, a separate software home directory called the incremental conversion home directory needs to be installed, and an incremental conversion instance must be created and the nomount state must be started. Incremental conversion home directories and incremental conversion instances are used temporarily and only during the migration operation.

Because the dbms_file_transfer prepare-phase method requires the target database to be version 11.2.0.4, it can be used to perform incremental backup conversion functions (as described above), incremental conversion of home directories and incremental conversion instances are usually used only when using the RMAN backup method. Refer to stage 1 for how to set up a temporary incremental conversion instance.

Diagnosis

To enable diagnostic mode, you can use the-d parameter to execute the xttdriver.pl script, or set the environment variable XTTDEBUG=1 before executing the xttdriver.pl script. Debug mode enables additional screen output and causes all RMAN operations to use the debug command line option.

Known problem

1. If the source database contains nested IOTs tables that use key compression, a patch that fixes Bug 14835322 must be installed in the target database home

two。 If you want to use block change tracking on the source database when creating incremental backups, you need to install a patch that fixes Bug 16850197 in the source database home

3. If the roll forward phase (xttdriver.pl-r) fails with the following error message, the DEVICE TYPE DISK for verifying RMAN cannot be configured with COMPRESSED

Entering RollForwardAfter applySetDataFileDone: applyDataFileToDone: RestoreSetPieceDECLARE*ERROR at line 1:ORA-19624: operation failed, retry possibleORA-19870: error while restoring backuppiece / dbfs_direct/FS1/xtts/incrementals/xtts_incr_backupORA-19608: / dbfs_direct/FS1/xtts/incrementals/xtts_incr_backup is not a backuppieceORA-19837: invalid blocksize 0 in backuppiece headerORA-06512: at "SYS.X$DBMS_BACKUP_RESTORE", line 2338ORA-06512: at line 40

Use cross-platform incremental backup to transfer tablespaces to reduce downtime

There are four main stages of cross-platform incremental backup transfer tablespaces:

1. Initialization setup phase

two。 Preparation stage

3. Roll forward phase

4. Transmission stage

Source system is Redhat Linux,Oracle 11.2.0.4, target system is AIX,Oracle 11.2.0.4

1. Initialization setup phase

To complete the configuration of the operating environment, do the following to use the cross-platform incremental backup transport tablespace:

1.1 install the target database software and create the target database

Install the required version of the database software on the target system to run the target database. Oracle 11.2.0.4 or later is strongly recommended. Note that the dbms_file_transfer method requires the target database to be 11.2.0.4. Identify or create a database in the target system and create tablespaces and user schemes that need to be transferred. My target database here is 11.2.0.4, the user scheme to be transferred is cdzj,ldjc, and the tablespace is cdzj,ldjc.

1.2 configure incremental conversion between home and instance if necessary

If the target database is 11.2.0.3 or earlier, you need to install a separate incremental conversion home with the instance. If the target database is 11.2.0.4 or later, you can skip this step. Note that the dbms_file_transfer method requires the target database to be version 11.2.0.4. If the target database is 11.2.0.3 or earlier, you must configure a separate instance of incremental transformation by doing the following:

. Install a new 11.2.0.4 database home on the target system. This is the incremental conversion home.

. Use the incremental transition home to start an instance to the nomount state, which is the incremental transition instance. For an incremental transformation instance, you do not need to create a corresponding database, you only need to run an incremental transformation instance.

The following operations can be used to create an incremental conversion instance called xtt, which converts home to / oracle11/app/oracle/product/11.2.0/db:

IBMP740-2:/oracle11/app/oracle/product/11.2.0/db/dbs$export ORACLE_HOME=/oracle11/app/oracle/product/11.2.0/dbIBMP740-2:/oracle11/app/oracle/product/11.2.0/db/dbs$export ORACLE_SID=xttIBMP740-2:/oracle11/app/oracle/product/11.2.0/db/dbs$cat

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.