RMAN笔记2



2.7 使用增量备份时，如何缩短RMAN 备份时间？
2.7.1 Block Change Tracking
Block ChangeTracking 是Oracle 10g里推出的特性。 Block change tracking 会记录data file里每个block的update 信息，这些tracking信息保存在tracking 文件里。 当启动block change tracking 后，RMAN 使用trackingfile里的信息，只读取改变的block信息，而不用在对整个data file进行扫描，从而提高了RMAN 备份的性能。
block change tracking file 是bitmap file。
默认是禁用Block change tracking的，如果使用增量备份，可以开启block change tracking。 启用BCT后，不需要其他的维护操作。

在备份期间，change tracking会维护已经标记为change 的block 的bitmap 信息。Oracle 会自动管理change tracking file的大小，只保留最近8次block change 的信息。 超过8次， 那么最前面的block bitmap 信息会被current change 覆盖。
第一个0级的增量备份扫描整个datafile。 随后的增量备份使用block change tracking file的信息，只扫描自上次备份以来被标记为change 的block。
如果是RAC 环境，change tracking file 必须放在共享设备上。
RMAN 不支持对change tracking file 的备份与恢复。当数据检测到change tracking file 无效时，就会reset change tracking file。
如果我们还原了数据库，那么数据库也会reset block change tracking，并从新进行tracking。
block change tracking file的大小和数据库的大小及 enabled threads of redo 的数量有关系，tracking file 的大小会根据数据库大小的变化和变化。 和更新频率没有关系。
典型的，单实例下大约DB的1/30000的block 会把track。 如果是RAC 环境，在乘以threads。
以下因素会导致file 超过估计值：
（1）为了避免tracking file 占用太多的空间， 初始值是10M，然后每次增加10M，如果数据库接近300G，那么trackingfile 不能小于10M，如果接近600G，不能小于20M。
（2）每个datafile，在tracking file里最少需要分配320k的空间，所以如果有大量的小data file， change tracking file 也会相对较大。

2.7.2 启用和禁用Block Change Tracking
2.7.2.1 启用Block Change Tracking
2.7.2.2.1 检查DB_CREATE_FILE_DEST参数配置
DB_CREATE_FILE_DEST 参数用来指定默认的Oracle Managed datafiles 的位置。 在没有指定DB_CREATE_ONLINE_LOG_DEST_n参数的情况下，这个参数也可以用来作为Oracle-managed control files和online redo logs的默认位置。
alter system set db_create_file_dest = '/s01/oracle/oradata/study' scope=both sid='*';

2.7.2.1.2 启用Block change tracking
alter database enable block change tracking;
可以使用v$block_change_tracking 视图查看tracking 启动情况。
select status, filename from v$block_change_tracking;

这里使用的是默认的目录。就是我们上面创建db_create_file_dest的目录，也可以在启动BCT时指定文件存放位置。

SQL>alter database enable block change tracking using file '/u01/app/oracle/oradata/dave/block_change_tracking.f' reuse;

2.7.2.2 禁用Block Change Tracking
alter database disable block change tracking;

2.7.2.3 改变Block Change Tracking File位置
可以使用alter database rename 语句来修改change tracking file 文件的位置，该命令会更新控制文件里的信息，命令必须在mount 下执行，如果DB 不能shutdown，那么可以先disable，然后指定新的位置在启动，但是这样会丢失以前在tracking file里的数据。
--不能关闭数据库的情况
SQL> alter database disable block changetracking;
SQL> alter database enable block changetracking using file 'new_location';

--能关闭数据库的情况
1. 查看当前文件的位置
SQL> select status, filename from v$block_change_tracking;
2.如果可能，关闭数据库
SQL> shutdown immediate
3.在操作系统级别移动change tracking file文件到新的位置。 这个是在关闭数据库的前提下进行。
[oracle@dave ~]$ mv /u01/app/oracle/oradata/dave/block_change_tracking.f /u01/backup/block_change_tracking.f
4. 启动数据库到mount状态，移动change tracking 文件位置。
SQL> startup mount;
alter database rename file '/u01/app/oracle/oradata/dave/block_change_tracking.f' to   '/u01/backup/block_change_tracking.f';
5.打开数据库
SQL> alter database open;
select status, filename from v$block_change_tracking;

2.7.3 监控Block Change Tracking
  select file#,
         avg(datafile_blocks),
         avg(blocks_read),
         avg(blocks_read/datafile_blocks) * 100 as PCT_READ_FOR_BACKUP,
         avg(blocks)
  from v$backup_datafile
  where used_change_tracking = 'YES'
        and incremental_level > 0
  group by file#;
该SQL 会显示自上次备份以来数据文件中block的变化情况。 当PCT_READ_FOR_BACKUP的值小于50%时，可以使用1级备份，当超过50%，建议使用0级备份。

2.8 RMAN RESTORE 和 RECOVER 准备工作
RECOVERY 和 RECOVER 区别？
RECOVERY 指的是个概念，就是RMAN 的恢复。
RECOVER 是一个具体的动作。

2.8.1 Restoring 和 Recovering
提问: RMAN 备份的时候最主要的2种类型的文件是什么？数据文件 和 归档文件
RMAN 恢复的时候，分2个步骤：
1. restore
2. recover
Restoring: 把数据文件从备份集中还原到数据库的对应位置。这时候的数据文件是备份时候的状态，是不一致的，也就是说，restoring 之后，是无法正常把数据库拉起来的，数据库要拉起来，必须是一致的状态，所以我们还需要进行recovering操作。
Recovering: recovering 的操作是应用归档文件和online redo log的过程。
Recover操作的本质就是保证数据的一致性，因为我们的RMAN 是不一致的备份，所以我们的这个一致性就要通过归档日志来操作。
因此在进行recover 的时候，会先将备份的归档文件还原到归档目录，然后从这个目录应用归档文件，完成恢复的过程。

2.8.2 Log Group 的状态
提问:怎么查询online redo log group的状态?
Log Group 4种状态：
（1）UNUSED: 还未使用的online redo log
（2）CURRENT: 正在使用，即LGWR 进程正在往里面写redo data。
（3）ACTIVE: 该状态没有写入操作，正在进行归档，此状不能被覆盖或者清楚，因为instance recovery的时候还需要该log group的内容。
（4）INACTIVE: 已经完成归档操作，并且instance recovery的时候也不需要。
提问： CURRENT online redo group 挂了，数据库会怎么样？

2.8.3 Redo log group 出现问题的恢复流程
(图)

2.8.4 完全恢复和不完全恢复
Complete recovery: 可以恢复到数据库出现故障的时间点，这种恢复可以恢复所有的已经提交的数据。
Incomplete recovery：不完全恢复也叫point-in-time 恢复，这种方法可以恢复到指定的时间，不完全恢复会导致数据出现丢失。
--完全恢复处理流程图：
(图)
--不完全恢复流程图：
(图)

2.8.5 Oracle 11g UNDO表空间备份增强
由于UNDO表空间在恢复时不可缺少，所以在进行备份时必须备份该表空间，但是一旦事务提交，修改被确认，则该事务的前镜像被标记为INACTIVE，其中的信息在恢复时也就不会被用到，如果在备份时能够跳过这些数据，则备份UNDO表空间的效率就可以大大提高。
在Oracle Database 11g中，Oracle引入了一个新的特性RMAN UNDO备份优化。在RMAN备份UNDO表空间时，提交事务的UNDO信息将不备份，这个特性随RMAN强制启用。
select file#,name,ceil(bytes/1024/1024) MB,status from v$datafile;  
--单独备份UNDO
backup datafile 3 format '/s01/backup/undotbs_%d_%T_%s_%p_%c.bak';
list backup;

2.9 如何用RMAN 进行RESTORE和RECOVER
2.9.1 通过Image Copy 进行恢复
2.9.1.1 对datafile 创建image copy 备份
backup as copy datafile '/s01/oracle/oradata/study/users01.dbf' format '/s01/backup//users01.dbf';

2.9.1.2 用dd命令破坏这个数据文件
[oracle@ ]$ dd if=/dev/null of='/s01/oracle/oradata/study/users01.dbf';
[oracle@ ]$ ll /s01/oracle/oradata/study/users01.dbf

2.9.1.3 使用recovery copy 进行恢复
恢复流程如下：
（1）将数据文件offline。
（2）使用switch to copy命令将数据文件切换到image copy上。
（3）recover 数据文件。
（4）将数据文件online。
select file#,status,name from v$datafile;
alter database datafile 4 offline;
--RMAN中切换：
RMAN>  switch datafile 4 to copy; 
recover datafile 4;
alter database datafile 4 online;

2.9.2 使用set newname 对数据文件进行switch
2.9.2.1 使用RMAN备份数据文件
backup datafile 4;
2.9.2.2 移动数据文件位置
run{
allocate channel c1 type disk;
allocate channel c2 type disk;
SQL "alter database datafile 4 offline";
set newname for datafile '/s01/backup//users01.dbf' to '/s01/oracle/oradata/study/users01.dbf';
restore datafile 4;
switch datafile 4;
recover datafile 4;
SQL "alter database datafile 4 online";
}
2.9.2.3 验证
SQL> select file#,status,name from v$datafile;

2.9.3 使用restore point来实现恢复
2.9.3.1 restore points 概述
restore points可以提供一个基于时间点的回滚,是Oracle 10g的 Flashback 中引入的一个功能，restore points 可以为Flashback database 提供基础。
Restore Points 分两种：Normal 和 Guarranteed。
2.9.3.1.1 Normal Restore Points
对于Normal Restore Points， point的名称和SCN 保存在控制文件里。
Normal restore points 信息保存在控制文件中，属轻量级别，即使我们没有手工的删除这些points 信息，控制文件也会有删除这些信息，所以对于Normal restore points，我们不要其他的维护操作。
Restore Point 同Flashback Database 一样，也会产生image 文件，在没有启用Flashback Database的情况下，只在开始时创建一次image，并保存在FRA中。
2.9.3.1.2 Guaranteed Restore Points
Guaranteed restore points 的信息也是保存在控制文件里的，本质的不同是Guaranteed restore points 不会自动的删除，必须手工的清除这些信息。

2.9.3.2  RestorePoints 示例
2.9.3.2.1 先创建restore point
show parameter db_recovery_file_dest
select flashback_on from v$database;
shutdown immediate
startup mount
--创建restore point
create restore point upgrade_point guarantee flashback database;
--查看我们创建的restore point
--使用rman：
RMAN>  list restore point all;

2.9.3.2.2 执行操作 --举例不做
如果是升级，这里就执行升级的脚本
SQL>startup upgrade
SQL>@?/rdbms/admin/catupgrd.sql
 
SQL>shutdown immediate
SQL>startup
SQL>@?/rdbms/admin/utlrp.sql

--实际操作
alter database open;
create table dave as select * from dba_objects;
select count(1) from dave;

2.9.3.2.3 如果失败，就进行回滚
SQL> shutdown immediate
SQL> startup mount;
SQL> select open_mode from v$database;

flashback database to restore point upgrade_point;

alter database open; --出错
alter database open resetlogs; --成功
select count(1) from dave;  --验证对象被删除

2.9.3.2.4 如果升级成功，我们直接删除restore point即可
SQL> drop restore point upgrade_point;
list restore point all;

2.9.4 Point-in-time recovery基于时间的恢复
--设置RMAN的时间格式

[oracle@dave ~]$ export NLS_DATE_FORMAT="YYYY-MM-DD HH24:MI:SS"
[oracle@dave ~]$ rman target /

执行恢复：
run{
set until time '2014-1-24 00:56:00';
restore database;
recover database;
}

2.10 RMAN 不同故障场景恢复示例
2.10.1 SPFILE丢失
思考： 怎么查询dbid？
 select dbid from v$database;
set dbid= 854240218
list backup

startup nomount;
--方法1：自动恢复
RMAN>restore spfile from autobackup;
RMAN>restore spfile to '/u01/spfile1.ora' from autobackup;

--方法二：通过某个文件
RMAN> restore spfile to '/u01/dave2.ora' from '/u01/backup/dave_spfile_1mo65679_1_1_20130403';

2.10.2 Controlfile全部丢失
show parameter control_files ;

--自动备份中恢复：
RMAN>startup nomount;
RMAN> set dbid= 854240218
RMAN>restore controlfile from autobackup;
--nocatalog模式并且控制文件丢失时才需要DBID

--从文件恢复
RMAN>list backup of controlfile;
RMAN> restore controlfile from '/u01/backup/ctl_file_1lo65676_1_1_20130403';
RMAN>alter database mount;
RMAN>recover database;
RMAN>alter database open resetlogs;

另外重建控制文件也是一种方式

2.10.3 数据文件损坏
恢复可以在 数据库处于 open 或 mount 状态下进行，只需4个步骤
1.        将该数据文件置于 offline 状态
2.        修复数据文件（指定数据文件编号）
3.        恢复数据文件
4.        将数据文件 online
rman> sql 'alter database datafile 11 offline';
rman>restore datafile 11;
rman>RECOVER DATAFILE 11;
rman>sql 'alter database datafile 11 online';

2.10.4 非系统表空间损坏
若出现介质故障导致某表空间不可用，恢复可以在数据库处于 open 或 mount 状态下进行，步骤如下：
1.        将该表空间置于offline状态
2.        修复表空间数据
3.        恢复表空间并处于一致性
4.        将表空间online
rman> sql 'alter tablespace dave offline';
如果文件不存在，就加immediate参数
rman> sql 'alter tablespace dave offline immediate';
rman>restore tablespace dave;
rman>recover tablespace dave;
rman>sql 'alter tablespace dave online';

2.10.5 基于时间点/SCN/日志序列的不完全恢复
smon_scn_time --视图可以查询SCN与时间的关系
2.10.5.1 基于时间点
方法一： 在RMAN中执行
run{
  set until time "to_date('2013-4-6 00:00:00','yyyy-mm-dd hh24:mi:ss')";
  restore database;
  recover database;
  alter database open resetlogs;
}
方法二：在SQLplus中执行
SQL>STARTUP NOMOUNT;
SQL>alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';
SQL> recover database until time '2013-4-6 00:00:00';
SQL>ALTER DATABASE OPEN RESETLOGS;
 
ALTER SESSION SET NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS';
SQL>startup mount;
SQL>restore database until time "to_date('2013-4-6 00:00:00','YYYY-MM-DD HH24:MI:SS')";
SQL>recover database until time "to_date('2013-4-6 00:00:00','YYYY-MM-DD HH24:MI:SS')";
SQL>alter database open resetlogs;
2.10.5.2 基于 SCN:
SQL>startup mount;
SQL>restore database until scn 10000;
SQL>recover database until scn 10000;
SQL>alter database open resetlogs;
2.10.2.3 基于日志序列
SQL>startup mount;
SQL>restore database until SEQUENCE 100 thread 1; //100是日志序列
SQL>recover database until SEQUENCE 100 thread 1;
SQL>alter database open resetlogs;

2.10.6 Redo Log File损坏
Redo log的恢复分为两种：CURRENT 和 非CURRENT
2.10.3.1  CURRENT 情况
造成redo 损坏，很多情况是与突然断电有关。这种情况下是比较麻烦的。

（1）如果有归档和备份，可以用不完全恢复。
SQL>startup mount;
SQL>recover database until cancel; 先选择auto，尽量恢复可以利用的归档日志，然后重新执行：
SQL>recover database until cancel; 这次输入cancel，完成不完全恢复,
用resetlogs打开数据：
SQL>alter database open resetlogs； 打开数据库

（2）强制恢复， 这种方法可能会导致数据不一致
sql>startup mount;
sql>alter system set "_allow_resetlogs_corruption"=true scope=spfile;
sql>recover database until cancel;
sql>alter database open resetlogs;
在Oracle 10g以后，要加这2个参数：
*._allow_resetlogs_corruption=true
*._allow_error_simulation=true
运气好的话，数据库能正常打开，但是由于使用_allow_resetlogs_corruption方式打开，会造成数据的丢失，且数据库的状态不一致。因此，这种情况下Oracle建议通过EXPDP/IMPDP方式导出数据库。重建新数据库后，再导入。
redo 的损坏，一般还容易伴随以下2种错误：ORA-600[2662]（SCN有关）和 ORA-600[4000]（回滚段有关）。

2.10.6.2 非CURRENT 情况
（1）如果STATUS是INACTIVE,则表示已经完成了归档，直接清除掉这个redo log即可。
SQL>startup mount;
SQL> alter database clear logfile group 3 ;
SQL>alter database open;
（2）如果STATUS 是ACTIVE ，表示正在归档， 此时需要使用如下语句：
SQL>startup mount;
SQL> alter database clear unarchived logfile group 3 ;
SQL>alter database open;
注意这种情况做完之后，要全备数据库。

2.10.7. 非catalog下完全恢复示例
2.10.7.1 完全备份数据库
list backup summary

2.10.7.2 rm掉所有相关的文件（保留online redo log）
rm -rf *

2.10.7.3 检查实例状态
select count(1) from dba_objects;

2.10.7.4 检查alert log
ps -ef|grep ora_

2.10.7.5 restore 数据库
[oracle@dave dave]$ rman target /   --此时链接RMAN出错
shutdown abort;
startup nomount;
rman target /
--恢复
RMAN>restore controlfile from autobackup;
--如果自动回复控制文件不行，就指定文件路径恢复：
RMAN> restore controlfile from '/s01/backup/c-2857578426-20140416-04';
alter database mount;
RMAN> restore database;
RMAN> restore database;
2.10.7.6 recover 数据库
RMAN> recover database;
2.10.7.7 打开数据库
alter database open;--如果还原了控制文件，必须resetlogs

--注意:如果删除了online redo 就会报如下错误，只能alter database open resetlogs;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 04/17/2014 12:54:35
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 1 and starting SCN of 1876673

2.10.7.8 重新备份数据库
Open resetlogs之后，就需要重新备份一下数据库的。

2.11 有RMAN备份，并不代表万物一失，如何保证备份的有效性？
2.11.1 查看备份情况
RMAN> list backup summary;
2.11.2 使用Validate 效验
可以使用validate 命令手工的检查数据文件物理和逻辑上的坏块。 也可以使用validate datafile …block 效验某个block的情况。
当我们效验整个数据文件时，RMAN会效验输入文件的每个block。 如果验证发现之前没有被标记为坏块的block，那么RMAN 会更新V$DATABASE_BLOCK_CORRUPTION视图已记录这些坏块。
当我们怀疑我们的备份集中一个或者多个backup pieces丢失或者有损坏，我们可以使用validate backupset 命令来进行效验。 这个命令会效验备份集中的每一个block，已确保这些block可以被用来进行恢复操作。
如果RMAN 在验证时发现了坏块，会提示具体的信息或者中断验证操作。
Validate backupset 命令允许我们选择哪个备份块去效验.
RMAN> VALIDATE DATABASE;
V$DATABASE_BLOCK_CORRUPTION
这个命令会效验所有的数据文件和控制文件，如果使用spfile 文件，也会效验。
RMAN> validate backupset 8;
-- validate 某一个数据块
RMAN> VALIDATE DATAFILE 1 BLOCK 10;

2.11.3  使用BACKUP ... VALIDATE 效验
我们可以使用backup…validate 命令做如下的效验：
（1） 检查数据文件是否存在物理或者逻辑的坏块
（2） 检查所有的数据文件是否都存在，并且存在正确的位置。
RMAN>backup validate database archivelog all;
效验所有的数据文件和归档日志
注意，在使用backup validate时，RMAN 不会产生任何的backup sets 和 image copy。
注意，上面的效验只会效验物理的损坏，不会效验逻辑的坏块，如果我们想效验一下逻辑坏块，那么可以使用如下SQL:
RMAN>backup validate check logical database archivelog all;

2.11.4 使用RESTORE ... VALIDATE 效验
2.11.4.1 语法说明
RESTORE…VALIDATE命令可以效验备份集中的某个特殊的datafile 或者backupset 能否用来进行restore操作。
必须在数据库mounted 状态或者open状态才可以使用该命令。 当我们效验数据文件时，不需要将datafiles offline。 因为我们效验数据文件时，仅仅从备份集中读取，不会影响生产环境中的数据文件。
restore database validate;
restore archivelog all validate;
restore controlfile validate;
restore spfile validate;

crosscheck backup;

2.12 RMAN 常用命令说明
2.12.1 delete 命令
备份需要占用存储空间，所以我们前面讲使用保存策略标记备份有效性和生存期的结束。但是，备份策略的实施不会从RMAN目录中删除备份，而只是将这些备份标记为丢弃状态。 我们还是需要通过命令来删除，这个命令就是delete。
Delete expired;
Delete obsolete;
obsolete:与retention policy相关，当备份或者副本根据保存策略而被丢弃的时候，就会被标记为该状态。比如你设置恢复窗口为7天，今天10号，那2号之前（包括2号）的都被认为是“过期的”。

expired:使用crosscheck对备份进行校验，当备份或者副本被存储在rman目录中，但是并没有物理存在于备份介质上时，就会被标记为该状态；在操作系统层删除备份集后，用crosscheck 检测后就标志为X（expired）。通常指丢失（被删除）的备份。
执行delete命令时，RMAN会请求用户确认这个删除命令，如果确认了这个删除命令，RMAN 就会完成delete操作。

2.12.2 List 命令
2.12.2.1 列出incarnation
Incarnation 是什么意思？
Incarnation 可以理解是一个版本的意思。 每次resetlogs之后，都会重新生成一个incarnation号。并且RMAN的备份集和incarnation是一致的。 就是当我们恢复过数据库，重新生产了一个incarnation，在使用之前的备份来恢复，就会提示incarnation 不一致。
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time
RMAN> list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       STUDY    2857578426       PARENT  1          17-SEP-11
2       2       STUDY    2857578426       PARENT  995548     19-FEB-14
3       3       STUDY    2857578426       PARENT  1876673    16-APR-14
4       4       STUDY    2857578426       CURRENT 1876674    17-APR-14

Status 列：该列列出的是incarnation的状态
Parent：表明对应物是非当前的incarnation
Current:当前的incarnation
ORPHAN：孤立的incarnation, 即在resetlogs命令之后进行恢复

2.12.2.2 列出备份
2.12.2.2.1 查看备份的sumary
RMAN> list backup summary;
List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
29      B  0  A DISK        17-APR-14       1       2       NO         DAVE_LEV0
30      B  0  A DISK        17-APR-14       1       2       NO         DAVE_LEV0
31      B  0  A DISK        17-APR-14       1       2       NO         DAVE_LEV0
32      B  0  A DISK        17-APR-14       1       2       NO         DAVE_LEV0
34      B  A  A DISK        17-APR-14       1       3       NO         ARC_BAK
39      B  F  A DISK        17-APR-14       1       1       NO         TAG20140417T131809

KEY(关键字)： 表示备份集序列号
TY（类型）和LV列表示列的备份类型：
  B[Backup] 表示备份
  F[Full] 表示完全备份
  A[Archivelog]
  0和1 表示增量备份[Incremental backup]
S 列说明备份的状态： A 表示Available，X 表示Expired.
Device Type:  说明备份的设备是磁带还是磁盘
大多数list命令都可以在末尾使用summary参数，如：
List backup of database summary;
List expired backup of archivelog all summary;
List backup of tablespace users summary;

2.12.2.2.2 按备份类型列出备份
RMAN> list backup by file;

2.12.2.3 其他备份信息
list backup命令可以查看RMAN 更多的信息。包括备份集，归档的重做日志备份，控制文件备份以及服务器参数文件备份
RMAN> list backup;

2.12.2.4 列出适合恢复的备份
RMAN> list recoverable backup of database;
List 命令提供了状态为Available的，可用于还原数据库的所有备份列表（该列表值用于当前的incarnation），其中包括备份，映像副本和增量备份。

2.12.2.5 列出到期的备份
list expired backup命令可以列出到期的备份：
RMAN> list expired backup;
该命令也可以获得到期的表空间和数据文件的备份列表：
RMAN> list expired backup of datafile 3;
RMAN> list expired backup of archivelog all;

2.12.2.6 按表空间名和数据文件号列出备份
RMAN> list backup of tablespace users;
RMAN> list backup of datafile 3;

2.12.2.7 列出归档日志备份
RMAN> list archivelog all;

2.12.2.8 列出控制文件和服务器参数文件备份
RMAN> list backup of controlfile;
RMAN> list backup of spfile;

2.12.3 Report 命令
2.12.3.1 指定最近没有备份的数据文件
查询3天内没有备份过的表空间，可以用如下命令：
RMAN> report need backup days=3;

2.12.3.2 报告备份冗余或恢复窗口
RMAN> report need backup redundancy =4;
文件冗余备份少于4个,小于4份冗余的数据文件都会列出来。
RMAN> report need backup recovery window of 2 days;

2.12.3.3 报告数据文件的不可用恢复操作
RMAN> report unrecoverable;

2.12.3.4 报告数据库模式（Schema）
Schema指的是数据库的物理结构，包括数据文件名，数据文件号，为这些数据文件指派的表空间，数据文件的大小，以及数据文件是否含有回滚段。
RMAN> report schema;

2.12.3.5 报告丢失的备份
如果使用了保存策略，备份有可能被标记为丢失状态（obsolete），可以执行report obsolete命令查看这些信息。
RMAN> report obsolete;

2.12.4 crosscheck交叉效验备份
在RMAN目录(或者使用控制文件)和物理备份目的地不同步的情况下，我们可以使用crosscheck命令来效验控制文件或恢复目录中的RMAN信息是否与备份介质上的实际物理备份集片相同。
crosscheck backupset命令是检查备份集和实际的文件。
备份集有两种状态：
A(Available,RMAN认为该项存在于备份介质上)，
X(Expired，备份存在于控制文件或恢复目录中，但是并没有物理存在于备份介质上）
crosscheck 的目的是检查RMAN 的目录以及物理文件：
如果物理文件不存在于介质上，将标记为Expired。
如果物理文件存在，将维持Available。
如果原先标记为Expired的备份集再次存在于备份介质上（如恢复了损坏的磁盘驱动器后），crosscheck将把状态重新从Expired标记回Available。

--重点，一定要记住。
交叉验证备份片：
RMAN> crosscheck backup;
交叉验证归档日志示例：
RMAN> crosscheck archivelog all;

2.12.5 Crosscheck 和 Delete 关系
2.12.5.1 归档日志问题
假如我们在oracle数据库在迁移当中不小心丢失了一个归档文件， 此时RMAN 会因为缺少归档日志而不能完成备份，
解决方法,执行下面2条命令即可：
RMAN>crosscheck archivelog all;
RMAN>delete expired archivelog all;
crosscheck archivelog all； 的作用就是检查控制文件和实际物理文件的差别。
delete expired archivelog all; 同步控制文件的信息和实际物理文件的信息。

2.12.5.2 备份片问题
--使用list 找到备份片：
RMAN> list backup;
有时候我们在执行delete obsolete时，可能遇到如下错误：

RMAN> delete obsolete;
RMAN-06207: WARNING: 2 objects could not be deleted for DISK channel(s) due
RMAN-06208: to mismatched status.  Use CROSSCHECK command to fix status
RMAN> crosscheck backup;

可以通过CROSSCHECK BACKUPPIECE的方式对问题备份进行单独的检查：
RMAN> crosscheck backuppiece '/u01/backup/dave_lev0_0so64ljn_1_1_20130403';

2.12.6 change 命令
Change 命令允许用户修改备份集的状态。
RMAN> list backup summary;
注意：不能改变存放在FRA里的backupset。
RMAN> Change backupset 29 unavailable;
将备份集改成可用：
RMAN> Change backupset 29 available;

2.13 INCARNATION 与 RESETLOG 区别说明
2.13.1 RESETLOGS 和 NORESETLOGS
在我们做完RMAN 恢复以后，都会提示我们必须使用RESETLOGS或者NORESETLOGS来打开数据库。
当数据库进行了不完全恢复之后，我们就必须使用RESETLOGS来打开数据库。 不完全恢复也就意味着有部分的归档没有应用。
RESETLOGS 会重新初始化online redo log，清除掉以前的信息，并且重置日志的sequence号，最后重新开始一个incarnation。

2.11.2 INCARNATION 说明
RMAN> list incarnation;
RMAN> reset database to incarnation 3;  --切换数据库的化身

--查错误的命令
[oracle@asm ~]$ oerr ora 19910
19910, 00000, "can not change recovery target incarnation in control file"
// *Cause: The RESET DATABASE TO INCARNATION command was used while the
//         database is open.  This is not allowed.
// *Action: Close the database then re-issue the command.

2.14 如何监控和优化RMAN？
2.14.1 监控RMAN session 信息
可以结合v$process 和 v$session 视图来查询RMAN session的信息。
SELECT s.SID, p.SPID, s.CLIENT_INFO
FROM V$PROCESS p, V$SESSION s
WHERE p.ADDR = s.PADDR
AND CLIENT_INFO LIKE 'rman%'

2.14.2 监控RMAN job的信息  看备份进度
SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,
       ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE"
FROM V$SESSION_LONGOPS
WHERE OPNAME LIKE 'RMAN%'
  AND OPNAME NOT LIKE '%aggregate%'
  AND TOTALWORK != 0
  AND SOFAR <> TOTALWORK

2.14.3 RMAN 的multiplexing（多路复用）
RMAN 会在内存中构建一些缓冲区，然后通过这些缓冲区将数据块写入到备份中。 内存缓冲区分为输入缓冲区和输出缓冲区。
输入缓冲区（input buffer）：填充从备份文件中读取的数据块；
输出缓冲区（output buffer）：在执行内存对内存的写操作时填充需要备份的数据块，一旦输出缓冲区被填满，输出缓冲区的内容就会被写到备份位置。
2.14.3.1 输入内存缓冲区
备份数据库时，输入内存缓冲区的大小和数据取决于实际执行的备份命令，事实上它主要取决于在一个备份中多路复用（multiplexing）的文件数。
多路复用 指的是在同一个备份片中备份某数据块的文件数。多路复用的深度，即并行度受2个参数影响：FILESPERSET 和 MAXOPENFILES。
注意：为了保证RMAN 恢复的性能，FILESPERSET 的值不建议超过8.
为了保持多路复用合理范围的内存分配，根据一起备份的文件数，分配内存缓冲大小需要应用下面的规则。
1）如果备份集内的文件数小于或者等于4个，RMAN 会为每个文件分配4个大小为1MB的缓冲区。缓冲区总和小于或者等于16MB。
2）如果备份集内文件数多余4个但少于等于8个，RMAN 会为每个文件分配4个大小为512KB的缓冲区。缓冲区总和确保少于或者等于16MB。
3）如果多路复用的文件数多余8个，RMAN 会为每个文件分配4个大小为128KB的缓冲区。这就确保每个要备份的文件占用512KB的缓冲区内存。

2.14.3.2 备份到磁盘时的输出内存缓冲区
除了输入缓冲区之外，RMAN还会根据输出设备分配输出缓冲区。如果备份到磁盘，则RMAN 将分配输出缓冲区以在数据溢出到备份片之前接收来自输入缓冲区的数据块。此时，每个通道有4个输出缓冲区，每个输出缓冲区大小为1MB，因此每个通道的内存区域通常为4MB。
2.14.3.3 备份到磁带时的输出内存缓冲区
备份到磁带时的内存分配是不同的，这是由于磁带设备的I/0速率较慢。在磁带上备份或从磁带上恢复时，RMAN会为每个通道进程分配4个输出缓冲区，每个缓冲区的大小为256KB，因此每个通道的内存区域通常为1MB。

2.14.4 RMAN还原时的内存缓冲区说明
（1）还原磁盘备份时：输入缓冲区的大小为1MB，同时RMAN 会为每个通道分配4个缓冲区。
（2）还原磁带备份时：RMAN会分配4个输入缓冲区，每个缓冲区的大小等于blksize参数的值（默认值为256kb）。

2.14.5 RMAN内存 （PGA 和 SGA） 与 LARGE_POOL_SIZE
在磁盘上的备份会使用PGA内存空间作为备份缓冲区，PGA 内存空间从用于通道进程的内存空间中分配。
如果操作系统没有配置本地异步I/O，可以利用DBWR_IO_SLAVES参数使用I/O从属来填充内存中的输入缓冲区。
如果设置DBWR_IO_SLAVES 参数为任意的非零值，RMAN 会自动分配4个I/O 从属协调输入缓冲区内存中的数据块加载。为了实现这一功能，RMAN 必须利用一个共享内存区域。因此，用于磁盘备份的内存区会被推入共享池，如果存在large池，则被推入large池。
如果没有使用磁带I/O从属，会在PGA中分配用于磁带输出缓冲区的内存。

如果配置了任一种I/O从属选项并且没有配置large 池，则会在SGA的共享池中分配内存。如果没有配置large pool又要使用I/O从属，建议最好创建一个large池。
Large pool size 的计算公式如下：
#_of_allocated_channels*(16MB+(4*size_of_tape_buffer))
如果备份到disk，那么tape buffer 是0，那么设置LARGE_POOL_SIZE 为16MB。
如果备份到tape，tape buffer 由RMAN 通道参数BLKSIZE 决定，默认值是256kb。

2.14.5 优化BACKUP 命令
（1）设置MAXPIECESIZE 参数
该参数可以控制每个备份片的最大大小。
（2）设置FILESPERSET 参数
该参数控制每个备份片中数据文件的数量。 如果只分配了一个通道，那么可以通过设置这个参数来创建多个备份片。
（3）设置MAXOPENFILES 参数
（4）设置BACKUP DURATION 参数

2.14.6 优化BACKUP 性能
（1） 删除CHANNEL中关于RATE的限制
（2）如果使用同步IO，则设置DBWR_IO_SLAVES 启动IO从属。
（3）设置LARGE_POOL_SIZE
（4）优化tape 的性能
（5）查询相关的v$视图，确定瓶颈问题。

2.14.7 优化Channel 性能
（1）限制backup pieces的大小。
（2）预防RMAN 占用太多的磁盘带宽，从而影响系统性能。
（3）对每个通道配置合理的multiplexing(多路复用)
（4）如果使用disk，配置多个disk来保存备份片。
（5）如果使用磁带，则配置多个通道对应多个SBT 设备。

2.15 RMAN 应用场景概述
1. 搭建测试环境
2. 数据迁移
3. duplicate 数据库

2.16 RMAN 备份 卡住不动或者备份很慢怎么办？
SELECT SID,
       SERIAL#,
       CONTEXT,
       SOFAR,
       TOTALWORK,
       ROUND (SOFAR / TOTALWORK * 100, 2) "%_COMPLETE"
  FROM V$SESSION_LONGOPS
 WHERE     OPNAME LIKE 'RMAN%'
       AND OPNAME NOT LIKE '%aggregate%'
       AND TOTALWORK != 0
       AND SOFAR <> TOTALWORK;
2.13.1 方法一：使用10046 事件跟踪
--使用debug 模式启动RMAN:
[oracle@dave scripts]$ rman target / debug trace=/s01/rman.trc log=/s01/rman.log
--启用10046 跟踪：
RMAN> set echo on;
RMAN> sql "alter system set max_dump_file_size=UNLIMITED";
RMAN> sql "alter session set events ''10046 trace name context forever, level 12''";
--执行备份操作：
RMAN> backup current controlfile tag='bak_ctlfile' format='/s01/backup/ctl_file_%U_%T';

2.13.2 方法二：使用RMAN debug
--使用debug 启动RMAN:
[oracle@dave scripts]$ rman target / debug trace /s01/dave.trc
--使用debug 收集数据：
run
{
debug on
backup current controlfile tag='bak_ctlfile' format='/u01/backup/ctl_file_%U_%T';
debug off;
}

2.17 使用RMAN  blockrecover 直接修复坏块内容
1. 坏块的一般处理思路(如果没做RMAN备份只能跳过该块)
[oracle@dave ~]$ rman target /
RMAN> blockrecover datafile 1 block 128585;
Starting recover at 30-APR-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=57 device type=DISK

channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00001
channel ORA_DISK_1: reading from backup piece /u01/backup/dave_lev0_09o8c31v_1_1_20130430
channel ORA_DISK_1: piece handle=/u01/backup/dave_lev0_09o8c31v_1_1_20130430 tag=DAVE_LEV0
channel ORA_DISK_1: restored block(s) from backup piece 1
channel ORA_DISK_1: block restore complete, elapsed time: 00:00:16

starting media recovery
media recovery complete, elapsed time: 00:00:03

Finished recover at 30-APR-13
--其实就是RMAN针对一个块去做restored和recover。

2.18 如何将 RMAN备份集 重新 注册到控制文件中？
2.18.1 说明
2.18.2 备份集位置发生改变
2.18.2.2 查看备份信息
2.18.2.3 将整个备份集目录进行修改
[oracle@dave u01]$ mv backup bak

2.18.2.4 用RMAN 效验
RMAN> crosscheck backup;
RMAN> list backupset summary;
RMAN> list expired backup;
--删除这些过期的信息：
RMAN> delete noprompt expired backup;

2.18.2.5 将备份集重新注册到控制文件
2.18.2.5.1 方法一：注册单个备份片
RMAN> CATALOG BACKUPPIECE '/s01/bak/c-2857578426-20140416-04', '/s01/bak/c-2857578426-20140417-02';

2.18.2.5.2 方法二：注册整个目录
RMAN> catalog start with '/s01/bak/'; 

2.18.2.5.3 方法三：catalog db_recovery_file_dest

2.18.3 注册归档
catalog archivelog '/s01/backup/thread_1_seq_73.373.920686977';