加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

Migrating the Flash Recovery Area to ASM

发布时间:2020-12-15 17:21:43 所属栏目:百科 来源:网络整理
导读: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 initializat

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" on page 16-2 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 settingDB_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=’*’;
SQL> alter system set DB_RECOVERY_FILE_DEST=’+FRA’ SID=’*’;


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"
on page 16-2 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" on page 16-5. 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"
on page 16-2 you do not need to perform this step.

?

The following procedure changes the database configuration so that the flash recovery
area is used for all future backups.


1. The first step is to change the initialization parameters for the database to store the
flash recovery area in ASM,as described in Setting Initialization Parameters for
Flash Recovery Area in ASM on page 16-5.


2. If this database is a primary database and your online logs,control file or archived
redo logs are in the flash recovery area,then perform a consistent shutdown of
your database. For example:


SQL> SHUTDOWN IMMEDIATE


If this database is a standby database and your standby online logs,control file,or
archive logs are in recovery area,then stop managed recovery mode and shut
down the database.


3. Modify the initialization parameter file of the target database as follows:
■ Set DB_RECOVERY_FILE_DEST to the desired ASM disk group.
■ Modify DB_RECOVERY_FILE_DEST_SIZE if you need to change the size of
the flash recovery area.

?

4. If you shut down the database in step 2,then bring the database to a NOMOUNT
state. For example:


RMAN> STARTUP NOMOUNT


If the old flash recovery area has copy of the current control file,then restore
control file 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;


5. The next step is to migrate the control file from the old flash recovery area to the
new flash recovery area. In this example,one control file is stored as
+DISK/ct1.f,the other as +FRA/ct2.f.


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='*';


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


SQL> ALTER DATABASE FLASHBACK ON;

?

At this point,all future files that are directed to the flash recovery area are created in
the new ASM flash recovery area location.

?

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"
on page 16-2 you do not need to perform this step.

?

In this example,using the process in "Setting Initialization
Parameters for Flash Recovery Area in ASM" on page 16-5.

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"
on page 16-2 you do not need to perform this step.

?

In this example,using the process in "Setting Initialization
Parameters for Flash Recovery Area in ASM" on page 16-5.

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" on page 16-10. 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,using the process in "Setting Initialization
Parameters for Flash Recovery Area in ASM" on page 16-5.

?

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.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读