Migrating Databases To and From ASM with Recovery Manager

This chapter describes how to migrate part or all of your database into and out of ASM storage using Recovery Manager. It includes the following topics:

• Migrating a Database into ASM

• Migrating the Flash Recovery Area to ASM

• Migrating a Database from ASM to Non-ASM Storage

• PL/SQL Scripts Used in Migrating to ASM Storage

Migrating a Database into ASM

To take advantage of Automatic Storage Management with an existing database you must migrate that database into ASM. This migration is performed using Recovery Manager (RMAN) even if you are not using RMAN for your primary backup and recovery strategy.

A database can be moved from non-ASM disk storage directly into ASM, assuming you have enough disk space to hold the entire database both in non-ASM storage and in ASM storage. If you do not have enough disk space to have a complete copy of your database in ASM and another in non-ASM storage simultaneously, you can modify the procedure described here to back the database up to tape, create an ASM disk group that uses the old disk space, and then restore the database from tape into ASM.

Note:

Enterprise Manager provides a GUI-based option for migration of a database to ASM storage. See Oracle Database 2 Day DBA for details.

Limitation on ASM Migration with Transportable Tablespaces

The procedure described here does not work for transportable (foreign) tablespaces. Such tablespaces needs to be made read-write and imported into the database, before they can be migrated into ASM using this procedure.

Preparing to Migrate a Database to ASM

There are several steps required to prepare your database for migration and collect useful information you will need later, before you start the actual migration process.

Determine Names of Database Files

Obtain the filenames of the control files, datafiles, and online redo logs for your database. This information will useful if you decide to migrate back to old (non-ASM) storage later. Information about datafiles is available by querying V$DATAFILE, online log file names in V$LOGFILE, and the control file names can be found in the CONTROL_FILES initialization parameter.

Generate RMAN Command File to Undo ASM Migration

If you need to migrate your database back to non-ASM storage later, this process will be simplified if you generate an RMAN command file now with the necessary commands to perform. this migration. Even if you make changes to your database later, such as adding datafiles, the command file you create now will serve as a useful starting point.

There is a PL/SQL script. described in "Generating ASM-to-Non-ASM Storage Migration Script" which generates the necessary RMAN commands for you. Run this script. and save the output as part of the permanent records you keep for your database.

Disk-Based Migration of a Database to ASM

If you have enough disk space that you can have both your entire non-ASM database and your ASM disk group on disk at the same time, you can do the migration directly without using tapes.

The procedure differs slightly between primary and standby databases. A number of the steps described in this procedure apply only in one or the other case. There are also a few steps where the procedure is different depending upon whether you are using a recovery catalog. The steps that vary are identified as necessary in the description of the process.

The process described in this section is intended to minimize downtime for your database. The example assumes that the destination ASM disk group for database files is +DISK, and a separate ASM disk group +FRA will be used to store the flash recovery area.

Note:

During the migration process all flashback logs are discarded. As a result, any guaranteed restore points in the database become unusable. You should drop all guaranteed restore points before performing the migration.

To perform. the migration, carry out the following steps:

Back up your database files as copies to the ASM disk group.

BACKUP AS COPY INCREMENTAL LEVEL 0  DATABASE 
     FORMAT '+DISK'  TAG 'ORA_ASM_MIGRATION';

You can perform. this backup with multiple channels to improve performance, depending upon your hardware configuration. For example:

run {
     allocate channel dev1 type disk;
     allocate channel dev2 type disk;
     allocate channel dev3 type disk;
     allocate channel dev4 type disk;
     BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE
           FORMAT '+DISK'  TAG 'ORA_ASM_MIGRATION;
}

To ensure that the backup can also be made consistent, archive the current redo log after the backup:

RMAN> sql 'alter system archive log current';

Note:

This backup may take a long time, depending upon the size of your database. If there has been a lot of activity on the database during the time the backup was created, you may wish to use the following procedure to create an incremental backup of the database afterwards, to refresh the copy with changes since the migration process started. If so, use the following script.

RMAN>  backup  incremental level 1 for recover of copy 
              with tag 'ORA_ASM_MIGRATION' database ;
RMAN> recover copy of database with tag 'ORA_ASM_MIGRATION';

This minimizes the time required for the media recovery performed just before the copy of the database in ASM is opened at the end of the migration process. You may also want to perform. this step using multiple channels, if using them improves performance in your environment.

Create a copy of the SPFILE in the ASM disk group. In this example, the SPFILE for the migrated database will be stored as +DISK/spfile.

If the database is using an SPFILE already, then run these commands:

run {
   BACKUP AS BACKUPSET SPFILE;
   RESTORE SPFILE TO "+DISK/spfile";
}

If you are not using an SPFILE, then use CREATE SPFILE from SQL*Plus to create the new SPFILE in ASM. For example, if your parameter file is called /private/init.ora, use the following command:

SQL> create spfile='+DISK/spfile' from pfile='/private/init.ora9;

If this is standby database, stop managed recovery mode.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Perform. a consistent shutdown of the database.

RMAN> SHUTDOWN IMMEDIATE;

At this point, if you want the option of easily returning the database to non-ASM storage later, make copies of your current control file and all online logs. This command backs up the current control file to a non-ASM location:

RMAN> STARTUP MOUNT;
RMAN> BACKUP AS COPY CURRENT CONTROLFILE FORMAT 9/disk1/pre-ASM-controfile.cf9; 

Note:

RMAN cannot be used to backup your online logs. You must use operating-system commands to copy them.

Now create an init.ora specifying the location of the new SPFILE, and start the instance with it. For example, create /tmp/pfile.ora with the following contents:

SPFILE=+DISK/spfile

Now start the database in NOMOUNT:

SQL> startup nomount PFILE="/tmp/pfile.ora";

The next step is to migrate the control file to ASM.

In SQL*Plus, change the CONTROL_FILES initialization parameter using the following command:

SQL> alter system set control_files='+DISK/ct1.f','+FRA/ct2.f' scope=spfile sid='*';

Now specify the location of the flash recovery area by setting DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE. Assuming that the desired size of the flash recovery area is 100 gigabytes, enter the following commands in SQL*Plus to set the parameters:

SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=100G SID=9*9;
SQL> alter system set DB_RECOVERY_FILE_DEST=9+FRA9 SID=9*9;

Shut down and startup in NOMOUNT again, so that the changed parameters take effect. (The CONTROL_FILES parameter change only takes effect upon a restart because it is a static parameter.)

Then, use RMAN to actually create the new control files in ASM. For example, assuming that one of your original control file locations was /private/ct1.f, use the following command:

RMAN> shutdown immediate;
RMAN> startup nomount PFILE=9/tmp/pfile.ora9; #using ASM SPFILE now
RMAN> restore controlfile from '/private/ct1.f';
RMAN> alter database mount;
RMAN> switch database to copy;
RMAN> recover database;

The next step is to migrate your tempfiles to ASM. You must use a SET NEWNAME command for each tempfile to direct it to ASM, then a SWITCH to make the new names take effect.

RMAN > run {
            set newname for tempfile 1 to '+DISK'
            set newname for tempfile 2 to '+DISK';
             ...
            switch tempfile all;
           }

The new tempfiles are created when you open the database.

Disable logging for Flashback Database, and then re-enable it again to start creating flashback logs in the new ASM flash recovery area. For example:

SQL> ALTER DATABASE FLASHBACK OFF;
SQL> ALTER DATABASE FLASHBACK ON;

Note:

Flashback logs cannot be migrated. All data in the flashback logs is lost.

The change tracking file cannot be migrated. You can only disable change tracking, then re-enable it, specifying an ASM disk location for the change tracking file:

SQL> alter database disable block change tracking;
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '+DISK';

At this point, if the database is a primary database, then open the database.

SQL> ALTER DATABASE OPEN;

For a standby database, resume managed recovery mode:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

For a primary database, migrating the online logs is performed by adding new log group members in ASM, and then dropping the old members. The easiest way to perform. this step is to use the PL/SQL script. in "Migrating Online Logs of Primary Database to ASM".

For a standby database, you can follow similar steps to the script. to drop the old standby redo logs and add new ones in the +DISK disk group, but the online redo logs cannot be migrated until the database is opened as a primary.

At this point the migration is complete. Your database and flash recovery area are stored in ASM. You may wish to move your existing flash recovery area backups using the process described in "Migrating Existing Backups to ASM Flash Recovery Area".

Migrating the Flash Recovery Area to ASM

This section describes procedures to use if you already have backups on disk in non-ASM disk storage and you want to start using ASM to store your flash recovery area. You must set the initialization parameters related to the flash recovery area to refer to the ASM disk location. Then you can migrate existing backups, online logs, to the new ASM flash recovery area

• Setting Initialization Parameters for Flash Recovery Area in ASM

• Migrating the Control File to an ASM Flash Recovery Area

• Migrating Existing Backups to ASM Flash Recovery Area

Setting Initialization Parameters for Flash Recovery Area in ASM

The following process moves the flash recovery area from non-ASM disk storage to an ASM disk group named +FRA.

Note:

• If you have already migrated all of these files to ASM storage using the procedure in "Disk-Based Migration of a Database to ASM" you do not need to perform. this step.

• Before changing the location of the flash recovery area, you should drop any guaranteed restore points. Flashback logs used to support guaranteed restore points are stored in the flash recovery area.

Specify the location of the flash recovery area by setting DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE. (For this example, assume the intended size of the flash recovery area is 100 gigabytes.) If you are using an SPFILE then in SQL*Plus enter the following commands:

SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=100G SID=9*9;
SQL> alter system set DB_RECOVERY_FILE_DEST=9+FRA9 SID=9*9;

If you are using a PFILE, then shut down the database, edit the above parameters in the PFILE with the new values for DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE and restart the instance.

Migrating the Control File to an ASM Flash Recovery Area

Note:

If you have already migrated all of these files to ASM storage using the procedure in "Disk-Based Migration of a Database to ASM" you do not need to perform. this step.

In this example, it is assumed that you have already set the initialization parameters for a flash recovery area in ASM storage, using the process in "Setting Initialization Parameters for Flash Recovery Area in ASM". It is also assumed that one control file is already stored in +DISK/ct1.f, the other in non-ASM storage. The goal is to move the non-ASM control file to the flash recovery area and store it as +FRA/ct2.f.

• In SQL*Plus, bring the database to NOMOUNT:

  SQL> SHUTDOWN IMMEDIATE;
  SQL> STARTUP NOMOUNT;
  

  Change the CONTROL_FILES initialization parameter to refer to the new location. If you are using an SPFILE, use the following command:

  SQL> alter system set control_files='+DISK/ct1.f','+FRA/ct2.f' scope=spfile sid='*';
  

  If using a PFILE, edit the PFILE with the new for the CONTROL_FILES initialization parameter.

  Shut down and startup in NOMOUNT again, so that the changed CONTROL_FILES parameter takes effect.

• Then, use RMAN to actually create the new control files in ASM.

  RMAN> restore controlfile from '+DISK/ct1.f';
  RMAN> alter database mount;
  

• If you were using flashback logging before to support flashback database, you can re-enable it now. For example:

  SQL> ALTER DATABASE FLASHBACK ON;
  

Note:

If you have already migrated all of these files to ASM storage using the procedure in "Disk-Based Migration of a Database to ASM" you do not need to perform. this step.

Changing Flashback Log Location to ASM Flash Recovery Area

Note:

If you have already migrated all of these files to ASM storage using the procedure in "Disk-Based Migration of a Database to ASM" you do not need to perform. this step.

In this example, it is assumed that you have already set the initialization parameters for a flash recovery area in ASM storage, using the process in "Setting Initialization Parameters for Flash Recovery Area in ASM".

Because the actual flashback logs cannot be migrated, the only step required to move the location of flashback logs to the new ASM flash recovery area is to disable and then enable flashback logging. After a clean shutdown, mount the database and run the following commands in SQL*Plus:

SQL> ALTER DATABASE FLASHBACK OFF;
SQL> ALTER DATABASE FLASHBACK ON;

Future flashback logs will be created in the new flash recovery area. The old flashback logs are automatically deleted from non-ASM storage.

Migrating Online Logs to ASM Flash Recovery Area

Note:

If you have already migrated all of these files to ASM storage using the procedure in "Disk-Based Migration of a Database to ASM" you do not need to perform. this step.

In this example, it is assumed that you have already set the initialization parameters for a flash recovery area in ASM storage, using the process in "Setting Initialization Parameters for Flash Recovery Area in ASM".

For a primary database, migrating the online logs is performed by adding new log group members in ASM, and then dropping the old members. The database must be open to perform. this task.

The easiest way to perform. this step is to use a PL/SQL script. based upon the one in "Migrating Online Logs of Primary Database to ASM". However, change the script. so that it does not specify the disk group name.

For example, change the code that creates the online logs from:

stmt := 'alter database add logfile thread ' ||
                 rlcRec.thr || ' ''+DISK'' size ' || 
                 rlcRec.bytes_k || 'K';

to:

stmt := 'alter database add  logfile thread ' ||
                 rlcRec.thr || ' size ' || 
                 rlcRec.bytes_k || 'K';

Also change the code that creates the standby logs from:

stmt := 'alter database add standby logfile thread ' ||
                 rlcRec.thr || ' ''+DISK'' size ' || 
                 rlcRec.bytes_k || 'K';

to the following code:

stmt := 'alter database add standby logfile thread ' ||
                 rlcRec.thr || ' size ' || 
                 rlcRec.bytes_k || 'K';

For a standby database, you can follow similar steps to the script. to drop the old standby redo logs and add new ones in the +FRA disk group, but the online redo logs cannot be migrated until the database is opened as a primary.

Once you have run your script, the migration of online logs is complete.

Migrating Existing Backups to ASM Flash Recovery Area

In this example, it is assumed that you have already set the initialization parameters for a flash recovery area in ASM storage, using the process in "Setting Initialization Parameters for Flash Recovery Area in ASM".

Note:

After you configure the database to change the location of the flash recovery area, backups created in the old flash recovery area location remain in their old location, still count against the total disk quota of the flash recovery area, are deleted from the old flash recovery area as space is required for other files, and can still be managed by RMAN and used in RMAN recovery operations. There is no need to move existing backups to the new ASM flash recovery area, unless you need the disk space used by those files for other purposes.

If you do need to free the space taken up by leftover non-ASM flash recovery area files, your options include backing them up to tape (for example, by using BACKUP RECOVERY AREA DELETE INPUT) or moving the backups from the old flash recovery area location to the new one, as described in this section.

To back up the existing archived redo log files to the new flash recovery area, use this command:

RMAN> BACKUP AS COPY ARCHIVELOG ALL DELETE INPUT;

To move backup sets to the new flash recovery area, use this command:

RMAN> BACKUP DEVICE TYPE DISK BACKUPSET ALL DELETE INPUT;

To move all datafile copies to the new flash recovery area location, use this command:

RMAN> BACKUP AS COPY DATAFILECOPY ALL DELETE INPUT;

At this point, all backups have been moved from the old flash recovery area to the new one.

Migrating a Database from ASM to Non-ASM Storage

Migrating a database back from ASM storage to non-ASM storage is similar to the original migration to ASM. The general outline of the process can be based on the steps in"Disk-Based Migration of a Database to ASM". The primary changes to these steps are to modify each step to reference file locations in non-ASM storage. For example, the command that initially created the datafile backups in ASM that become the live datafiles for the migrated database was:

BACKUP AS COPY INCREMENTAL LEVEL 0  DATABASE 
     FORMAT '+DISK'  TAG 'ORA_ASM_MIGRATION';

You could use the following command to move them back:

BACKUP AS COPY INCREMENTAL LEVEL 0  DATABASE 
     FORMAT '/non-asm/df/%U9  TAG 'ORA_NON_ASM_MIGRATION';

Similar modifications can be applied to the other steps in the migration process and to the PL/SQL scripts used during migration.

PL/SQL Scripts Used in Migrating to ASM Storage

The following PL/SQL scripts perform. tasks which arise in the migration scenarios described in this chapter.

Generating ASM-to-Non-ASM Storage Migration Script

You can use the following PL/SQL script. to generate a series of RMAN commands that you can use to migrate your database back from ASM to non-ASM disk storage.

set serveroutput on;
declare
    cursor df is select file#, name from v$datafile;
begin
    dbms_output.put_line('run');
    dbms_output.put_line('{');
    for dfrec in df loop
        dbms_output.put_line('set newname for datafile ' ||
            dfrec.file# || ' to ''' || dfrec.name ||''' ;');
    end loop;
    dbms_output.put_line('restore database;');
    dbms_output.put_line('switch all;');
    dbms_output.put_line('}');
end;

Run this PL/SQL script. and save the output into a file. The result is an RMAN script. which you can save to a file and later run as a command file in the RMAN client to migrate your datafiles back out of ASM storage to their original non-ASM locations. Even if you later add or delete datafiles, this script. provides a useful starting point for a migration script. that will work for the new database.

Migrating Online Logs of Primary Database to ASM

The following PL/SQL script. can be used to migrate the online redo log groups into ASM, as part of migrating a database or a flash recovery area into ASM. For each online redo log group, the script. adds a log file stored in ASM, archives the current redo logs, and then drops the non-ASM log file.

declare
   cursor rlc is
      select group# grp, thread# thr, bytes/1024 bytes_k, 'NO' srl
        from v$log
      union
      select group# grp, thread# thr, bytes/1024 bytes_k, 'YES' srl
        from v$standby_log
      order by 1;
   stmt     varchar2(2048);
   swtstmt  varchar2(1024) := 'alter system switch logfile';
   ckpstmt  varchar2(1024) := 'alter system checkpoint global';
begin
   for rlcRec in rlc loop
      if (rlcRec.srl = 'YES') then
         stmt := 'alter database add standby logfile thread ' ||
                 rlcRec.thr || ' ''+DISK'' size ' || 
                 rlcRec.bytes_k || 'K';
         execute immediate stmt;
         stmt := 'alter database drop standby logfile group ' || rlcRec.grp;
         execute immediate stmt;
      else
         stmt := 'alter database add logfile thread ' ||
                 rlcRec.thr || ' ''+DISK'' size ' ||  
                 rlcRec.bytes_k || 'K';
         execute immediate stmt;
         begin
            stmt := 'alter database drop logfile group ' || rlcRec.grp;
            dbms_output.put_line(stmt);
            execute immediate stmt;
         exception
            when others then
               execute immediate swtstmt;
               execute immediate ckpstmt;
               execute immediate stmt;
         end;
      end if;
   end loop;
end;

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/38267/viewspace-704485/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/38267/viewspace-704485/