| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 1 (10.1) Part Number B10734-01 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 1 (10.1) Part Number B10734-01 |
|
|
View PDF |
This chapter describes how to migrate a database into and out of an ASM disk group using Recovery Manager. It covers the following topics:
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, or you can back the database up to tape and then from tape backups move it into ASM. Moving the database to tape backup and then into ASM is recommended if your database is so large that you cannot have copies of the database on non-ASM disk storage and ASM disk storage simultaneously. You can back the database up to tape, convert your non-ASM disk storage into an ASM disk group, and then restore from tape to the ASM disk group.
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.
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.
If you are not using a recovery catalog, you may need to know your DBID. You must restore your control file from autobackup during the migration process, and you will need to set your DBID before you restore the control file.
Your DBID should be part of the permanent records you keep about your database. If you do not have it in your records, the easiest way to find out your DBID is to connect the RMAN client to the database to be migrated. RMAN displays the DBID whenever it starts up. For example:
% rman TARGET / Recovery Manager: Release 10.1.0.2.0 - Production Copyright (c) 1995, 2003, Oracle. All rights reserved. connected to target database: RDBMS (DBID=774627068) RMAN> exit
Make a note of this value.
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, and the control file names can be found in the CONTROL_FILES initialization parameter.
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 will generate the necessary RMAN commands for you. Run this script and save the output as part of the permanent records you keep for your database.
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.
Once you have completed the preparations in "Preparing to Migrate a Database to ASM", begin the migration procedure.
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.
To perform the migration, carry out the following steps:
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> SHUTDOWN IMMEDIATE
DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_LOG_DEST_n (where n=1-4) to refer to the desired ASM disk groups.CONTROL_FILES parameter that specifies locations of the control file. The control file will be moved to the DB_CREATE_* destination and the server parameter file will be automatically updated. If you are using a client-side parameter file (PFILE), then set the CONTROL_FILES parameter to the ASM alias for the control file name (for example, CONTROL_FILES=+disk_group/cf1 ).RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM 'filename_of_old_control_file';
RMAN> ALTER DATABASE MOUNT;
RMAN> BACKUP AS COPY DATABASE FORMAT '+disk_group';
You may be able to speed up the copy process by increasing RMAN parallelism. For example:
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 4; RMAN> BACKUP AS COPY DATABASE FORMAT '+disk_group';
RMAN> SWITCH DATABASE TO COPY;
All datafiles are now in ASM.
If this database a standby database, then do not open the database or start managed recovery at this time.
If this is a primary database (that is, not a standby database), then you can open the database.
RMAN> ALTER DATABASE OPEN;
Note that there is no need to perform an OPEN RESETLOGS.
If this is a standby database, then online logs do not exist (only standby online logs exist) and therefore cannot be renamed at this point. However, you must delete any online log files that might have been created if the database was used as a primary database in the past. Delete these files using the operating system delete command.
When the standby database is activated, online logs will automatically be added as ASM files. For each standby online redo log file, create a new one in ASM, and delete an old one from the non-ASM storage. For a PL/SQL script that can perform this task for you, see "Migrating Standby Online Redo Log Files to ASM Storage".
At this point the migration is complete. The original datafiles, still in non-ASM storage, are cataloged as datafile copies in the RMAN repository. You can use them as backups, or reclaim the disk space by deleting them.
If you were using change tracking for incremental backups, you can re-enable it now. For example:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
If you decide to migrate back to old storage, you can switch back to the original datafiles, using the script created in "Preparing to Migrate a Database to ASM". If you have not yet deleted your original datafiles, you can also use the SWITCH DATABASE TO COPY command to switch back rather than going through the whole migration process.
You can delete the old database files to free disk space. The RMAN repository has records of the old datafiles, so you can delete these with an RMAN command. The old control files and online redo logs, however, are not in the repository and must be deleted with host operating system commands. This example shows how to perform this under Unix, using the rm command for the online redo logs and control files:
# delete datafiles RMAN> DELETE COPY OF DATABASE; RMAN> HOST 'rm old_online_redo_logs'; RMAN> HOST 'rmold_control_files';
This alternative procedure is useful when you do not have enough disk space to hold both the non-ASM version of your database and the ASM disk group that will hold your database after the migration. The database is backed up from non-ASM storage to tape using RMAN, then restored from tape into ASM storage.
Once you have completed the preparations in "Preparing to Migrate a Database to ASM", begin the migration procedure.
To migrate your non-ASM database into ASM storage using a tape backup, use the following procedure:
RMAN> BACKUP DEVICE TYPE SBT DATABASE;
After backup is done, disable change tracking. For example:
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
If this is standby database, stop managed recovery mode.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Shut down the database consistently. For example:
SQL> SHUTDOWN IMMEDIATE
At this point you can delete the old database files and create your ASM disk groups.
DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_LOG_DEST_n (where n=1-4) to refer to the desired ASM disk groups.CONTROL_FILES parameter that specifies locations of the control file. The control file will be moved to the DB_CREATE_* destination and the server parameter file will be automatically updated.
If you are using a client-side parameter file (PFILE), then set the CONTROL_FILES parameter to the ASM alias for the control file name (for example, CONTROL_FILES=+disk_group/cf1 ).
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE;
If you are not using a recovery catalog, then you will need to set your DBID and allocate channels to perform the restore of your control file. For example:
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN> ALTER DATABASE MOUNT;
RMAN> RUN {
2> SET NEWNAME FOR DATAFILE 1 TO NEW; 3> SET NEWNAME FOR DATAFILE 2 TO NEW; 4> ...add one line for each datafile 5> RESTORE DATABASE; 6> SWITCH ALL; 6> }
Be sure to include a SET NEWNAME FOR DATAFILE filenumber TO NEW statement for each datafile in the database.
The RESTORE DATABASE command instructs RMAN to restore into location DB_CREATE_FILE_DEST, which has now been updated to refer to the ASM disk group. New names are generated for each datafile automatically.
If the database has a large number of datafiles, it is more convenient to use the following PL/SQL script to generate the required RMAN commands for the RESTORE operation:
set serveroutput on; declare cursor df is select file# 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 new;'); end loop; dbms_output.put_line('restore database;'); dbms_output.put_line('switch all;'); dbms_output.put_line('}'); end;
Running this PL/SQL code causes the SQL*Plus client to display an RMAN script which you can save to a file and run as a command file in the RMAN client.
After this operation all datafiles are in ASM.
Now you must create new tempfiles for the temporary tablespaces. For each temporary tablespace, execute the following command:
RMAN> SQL "ALTER TABLESPACE tablespacename ADD TEMPFILE;"
If this a primary database, then recover the database and perform an OPEN RESETLOGS on the database.
RMAN> RECOVER DATABASE; RMAN> ALTER DATABASE OPEN RESETLOGS;
Note that you must use the RESETLOGS option because the control file is restored from backup.
If you were using change tracking for incremental backups, you can re-enable it now. For example:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
If you are migrating a standby database, do not open the database at this time. If your standby database has standby online logs stored in the flash recovery area, then you must move standby online log files into ASM storage. For each standby online redo log file, you must create a new one in ASM, and delete an old one from the non-ASM storage. For a PL/SQL script that can perform this task for you, see "PL/SQL Scripts Used in Migrating to ASM Storage".
The following procedure assumes that you have a flash recovery area in non-ASM disk storage and you need to move it to an ASM disk group, possibly preserving its contents.
SQL> ALTER DATABASE FLASHBACK OFF;
SQL> SHUTDOWN IMMEDIATE
If this database is a standby database and your standby online logs, controlfile, or archive logs are in recovery area, then stop managed recovery mode and shutdown database.
RMAN> STARTUP NOMOUNT
If the old recovery area has copy of the current controlfile, then restore controlfile from the old DB_RECOVERY_FILE_DEST and mount the database again.
RMAN> RESTORE CONTROLFILE FROM 'filename_of_old_control_file'; RMAN> ALTER DATABASE MOUNT;
RMAN> BACKUP RECOVERY AREA;
You can also use the DELETE INPUT option when backing up the flash recovery area to tape, if you want to immediately free the non-ASM space previously used to store flash recovery area files:
RMAN> BACKUP RECOVERY AREA DELETE INPUT;
Note: If you do not have tape, you should not delete the flash recovery area storage.
SQL> ALTER DATABASE FLASHBACK ON;
Now, optionally, you can move your backups from old recovery area to the new location. To move the existing backupsets and archived redo log files, use these two commands:
RMAN> BACKUP AS COPY ARCHIVELOG ALL DELETE INPUT; RMAN> BACKUP DEVICE TYPE DISK BACKUPSET ALL DELETE INPUT;
Then you must move your datafile copies. For each datafile copy in the old recovery area, use this command:
RMAN> BACKUP AS COPY DATAFILECOPY "name" DELETE INPUT;
where name is the path to the datafile copy in the old recovery area location.
If the old recovery area location contains a large number of files, you can use the following PL/SQL script to generate the RMAN commands required to relocate the files:
set serveroutput on; declare cursor dfc is select name from v$datafile_copy where status = 'A' and is_recovery_dest_file = 'YES'; begin dbms_output.put_line('run'); dbms_output.put_line('{'); dbms_output.put_line('backup as copy archivelog all delete input;'); dbms_output.put_line('backup device type disk backupset all delete input;'); for dfcrec in dfc loop dbms_output.put_line('backup as copy datafilecopy ''' || dfcrec.name || '''delete input;'); end loop; dbms_output.put_line('}'); end;
If this is a primary database (that is, not a standby database), then open the database:
RMAN> alter database open;
If this is a primary database and you had online redo log files in the flash recovery area, then you should set up your database to store the online redo logs in the ASM disk group. For each online redo log group, you must create a new online redo log in the ASM disk group, archive the current logs, and delete the old log member. For a PL/SQL script that can perform this task for you, see "Migrating Online Redo Logs to ASM Storage".
At this point the migration of the flash recovery area is complete.
Migrating a database back from ASM storage to non-ASM storage is similar to the original migration to ASM. The process described here assumes that you can perform the migration through tape. It is very similar to the process described in "Using Tape Backups to Migrate a Database to ASM". You can also migrate from ASM to non-ASM storage using only disk, using a process similar to the one used to migrate into ASM storage using only disk.
RMAN> BACKUP DEVICE TYPE SBT DATABASE;
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
SQL> SHUTDOWN IMMEDIATE
RMAN> STARTUP NOMOUNT;
If you are not using a recovery catalog, then you must use a control file autobackup. Set your DBID and restore the control file, as follows:
RMAN> SET DBID 320066378; RMAN> RUN { ALLOCATE CHANNEL ctape DEVICE TYPE SBT PARMS='...'; ALLOCATE CHANNEL cdisk DEVICE TYPE DISK; RESTORE CONTROLFILE FROM AUTOBACKUP; }
If you use a recovery catalog, then you do not need to use a control file autobackup, because the recovery catalog contains a record of the control file backup location. Restore the control file, as follows:
RMAN> RUN { ALLOCATE CHANNEL ctape DEVICE TYPE SBT PARMS='...'; ALLOCATE CHANNEL cdisk DEVICE TYPE DISK; RESTORE CONTROLFILE; }
RMAN> ALTER DATABASE MOUNT;
RMAN> SQL "ALTER TABLESPACE tablespacename ADD TEMPFILE tempfilename;"
If this is a primary database, then recover and open the database. Note that you must perform an OPEN RESETLOGS because the control file is restored from backup.
RMAN> RECOVER DATABASE; RMAN> ALTER DATABASE OPEN RESETLOGS;
ALTER DATABASE ADD LOGFILE SIZE BYTES FILENAME new_name; ALTER DATABASE ARCHIVE LOG CURRENT; ALTER DATABASE DROP LOGFILE old_name;
If this is a standby database, then you should move standby online logs back to the old location. For each standby online log, execute the following commands in SQL*Plus:
ALTER DATABASE ADD STANDBY LOGFILE SIZE BYTES FILENAME new_name; ALTER DATABASE DROP STANDBY LOGFILE old_name;
At this point, the migration from ASM to non-ASM storage is complete. You may want to enable change tracking for incremental backups, if you were using it before the migration. For example:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
The following PL/SQL scripts perform tasks which arise in more than one of the migration scenarios described in this chapter.
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;
Running this PL/SQL code causes the SQL*Plus client to display 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.
The script queries V$DATAFILE to find out the filenames for your datafiles before they are moved to ASM. Running this script later will restore the same set of datafiles to their pre-ASM locations. If you decide to store the files in a different disk location when moving them out of ASM, update the generated RMAN commands to use different destination filenames. If you add datafiles to your database, edit the script to include SET NEWNAME commands to specify locations for the new datafiles. If you delete datafiles, remove the corresponding commands from the migration script.
The following PL/SQL script can be used to migrate your 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.
Save this script into a file and run it from within SQL*Plus to migrate the online logs.
declare cursor orlc is select lf.member, l.bytes from v$log l, v$logfile lf where l.group# = lf.group# and lf.type = 'ONLINE' order by l.thread#, l.sequence#; type numTab_t is table of number index by binary_integer; type charTab_t is table of varchar2(1024) index by binary_integer; byteslist numTab_t; namelist charTab_t; procedure migrateorlfile(name IN varchar2, bytes IN number) is retry number; stmt varchar2(1024); als varchar2(1024) := 'alter system switch logfile'; begin select count(*) into retry from v$logfile; stmt := 'alter database add logfile size ' || bytes; execute immediate stmt; stmt := 'alter database drop logfile ''' || name || ''''; for i in 1..retry loop begin execute immediate stmt; exit; exception when others then if i > retry then raise; end if; execute immediate als; end; end loop; end; begin open orlc; fetch orlc bulk collect into namelist, byteslist; close orlc; for i in 1..namelist.count loop migrateorlfile(namelist(i), byteslist(i)); end loop; end;
The following PL/SQL script can be used to migrate your standby online redo log files into ASM, as part of migrating your whole database into ASM.
Save this script into a file and run it from within SQL*Plus to migrate the standby online logs.
declare cursor srlc is select lf.member, l.bytes from v$standby_log l, v$logfile lf where l.group# = lf.group# and lf.type = 'STANDBY'; type numTab_t is table of number index by binary_integer; type charTab_t is table of varchar2(1024) index by binary_integer; byteslist numTab_t; namelist charTab_t; procedure migratesrl(name IN varchar2, bytes IN number) is stmt varchar2(1024); begin stmt := 'alter database add standby logfile size ' || bytes; execute immediate stmt; stmt := 'alter database drop standby logfile ''' || name || ''''; execute immediate stmt; end; begin open srlc; fetch srlc bulk collect into namelist, byteslist; close srlc; for i in 1..namelist.count loop migratesrl(namelist(i), byteslist(i)); end loop; end;
|
 Copyright © 2003 Oracle Corporation All Rights Reserved. |
|