基础知识补漏-控制文件和引导

控制文件和引导


SCN是唯一的，并随时间增加，但是可能并不连贯。


scn超过合理值意外增长后，将会出现ora－00600［2552］错误。


获取数据库的当前scn号：
select current_scn from v$database;


转储日志文件
SQL> alter system dump logfile '/opt/oracle/oradata/conner/redo01.log';


数据库启动过程中，数据库要经历多久才能打开，就是需要读取多少重做日志才能完成前滚的意思。假定在a检查点数据库完成并记录了最后一次检查点，那只需要重新应用a之后的操作，因此，检查点的频度对于数据库的恢复时间具有极大影响。而过于频繁的检查又会给更新频繁的数据库带来性能问题。最佳的平衡点是性能允许的情况下，scn逐渐逼近redo的最新变更。


心跳每3秒更新一次用于确认实例的存活性。


除了ALTER SYSTEM CHECKPOINT和SHUTDOWN (除 ABORT 方式外)是完全检查点，其余都是增量检查点。


可以设置初始化参数alter system set log_checkpoints_to_alert=true;这样检查点的执行情况也会写入日志文件。


检查点的触发和执行有一定的时间间隔，它会在下一次触发时写出上一次成功完成的检查 点信息。


oracle限制最长的检查点跨度不超过最小日志大小的90%


数据库当前的实例恢复状态可以通过视图 v$instance_recovery 查询得到:
select RECOVERY_ESTIMATED_IOS REIO,ACTUAL_REDO_BLKS ARB,TARGET_REDO_BLKS TRB,LOG_FILE_SIZE_REDO_BLKS LFSRB, LOG_CHKPT_TIMEOUT_REDO_BLKS LCTRB,LOG_CHKPT_INTERVAL_REDO_BLKS LCIRB, FAST_START_IO_TARGET_REDO_BLKS FSIOTRB,TARGET_MTTR TMTTR, ESTIMATED_MTTR EMTTR,CKPT_BLOCK_WRITES CBW from v$instance_recovery;


REIO ARB TRB LFSRB LCTRB LCIRB FSIOTRB TMTTR EMTTR CBW
------ ------- ------ ------- ----- ------- ------- ------ -------- -----
10138 26582 26582 184320 26582 180 108 3725700


平均恢复时间(MTTR），TARGET_MTTR 代表的是期望的平均恢复时间，在繁忙的系统中,很容易观察到 ESTIMATED_MTTR > TARGET_MTTR,这可能是因 为 DBWR 正忙于写出,甚或出现 Checkpoint 不能及时完成的情况。当执行查询时(查询脚本同前)发现 ESTIMATED_MTTR > TARGET_MTTR，继续查询,发现 ESTIMATED_MTTR 继续升高。
此时查询 v$session_wait,我们发现数据库处于 checkpoint incomplete 等待:
select sid,seq#,event from v$session_wait;
查询 V$LOG 视图,发现除了 Current 日志组外,所有日志组都处于 Active 状态：
select * from v$Log;
此时,通过 OS 查看 iostat 状态信息,可以发现系统 swap 已经很严重(si,sw 较高),CPU 等
待 IO(wa)也很高，这意味着系统 IO 存在瓶颈,或者系统有突发的大规模写操作。


Oracle 的回滚无法终止,必须等待回滚 完成,相关的锁定和资源才能释放。shutdown abort无法解决这个问题，一旦重启数据库之后,v$transaction 事务表中的事务 信息将会消失,恢复事务变成了死事务(Dead Transaction)。


判断死事务的恢复进度
判断事务状况：
select distinct KTUXECFL,count(*) from x$ktuxe group by KTUXECFL;
通过观察 KTUXESIZ 字段可以来评估恢复进度:
select ADDR,KTUXEUSN,KTUXESLT,KTUXESQN,KTUXESIZ from x$ktuxe where KTUXEUSN=10 and KTUXESLT=39;
判断时长：
declare
l_start number;
l_end number;
begin
select ktuxesiz into l_start from x$ktuxe where KTUXEUSN=10 and KTUXESLT=39;
dbms_lock.sleep(60);
select ktuxesiz into l_end from x$ktuxe where KTUXEUSN=10 and KTUXESLT=39;
dbms_output.put_line('time est Day:'|| round(l_end/(l_start -l_end)/60/24,2));
end;
/


ORA-00701: object necessary for warmstarting database cannot be altered
这个 示是告诉我们,这些对象是数据库启动所必须的,Oracle 不允许移动或修改。Obj$在 bootstrap$表中存在
有两种方式可以使得这些对象允许被改变:
1.通过 migrate 模式
SQL> shutdown immediate;
SQL> startup migrate;
SQL> alter index I_H_OBJ#_COL# rebuild;
Index altered.
SQL> shutdown immediate;
SQL> startup
2.通过一个内部事件
SQL> alter system set event='38003 trace name context forever, level 10' scope=spfile; System altered.
SQL> shutdown immediate;
SQL> startup
SQL> alter index i_h_obj#_col# rebuild;
Index altered.




找到一个文件最末端的对象:
col segment_name for a30 col owner for a10 SELECT *
FROM (SELECT owner, segment_name,segment_type,block_id, blocks FROM dba_extents
WHERE tablespace_name = 'SYSTEM' and file_id='&fileid' ORDER BY block_id DESC)
WHERE ROWNUM < 11;


直接修复数据文件中的块：
RMAN> backup validate datafile 2;
查询 RMAN 发现的坏块信息
SQL> select * from v$database_block_corruption where file#=2;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO 
---------- ---------- ---------- ------------------ --------- 
2 14 1 0 FRACTURED
使用 RMAN 进行坏块修复可以在 Mount 状态进行:
RMAN> startup mount;
RMAN> blockrecover datafile 2 block 14 from backupset;


数据库启动时将数据字典和控制文件进行交叉检查，如果两部分信息不一致，以数据字典为准。


ORA-01202: wrong incarnation of this file - wrong creation time
这里提示的是文件创建时间错误,这是与控制文件的交互校验,如果不通过,说明控制文件和 数据文件头上记录的信息不符,可以重建控制文件,重新从数据文件上获得正确的时间信息。


当重建控制文件，控制文件中缺失了数据文件信息，交叉校验后添加了MISSING＊这样的信息导致原数据文件无法online：
SQL> alter database rename file '/opt/oracle/10.2.0/dbs/MISSING00006'
2 to '/opt/oracle/oradata/eygle/eygle.dbf'; Database altered.
SQL> alter tablespace eygle online;
alter tablespace eygle online
*
ERROR at line 1:
ORA-01190: control file or data file 8 is from before the last RESETLOGS
ORA-01110: data file 6: '/opt/oracle/oradata/eygle/eygle.dbf'
SQL> recover tablespace eygle;
ORA-00279: change 1623 generated at 01/18/2010 13:20:30 needed for thread 1
ORA-00289: suggestion : /archive/1_29_234595239.dbf
ORA-00280: change 1623 for thread 1 is in sequence #29
Specify log: {=suggested | filename | AUTO | CANCEL}
AUTO
Log applied.
Media recovery complete.
SQL> alter tablespace eygle online;
Tablespace altered.


对于表空间的 DROP 操作,实际上要先将表空间离线,而将表空间离线,会触发表空间检查 点操作,将表空间中的内存脏数据写出到数据文件上。


如果我们重建的表空间与之前删除的同名,则 Oracle 会重用之前的表空间信息。


Mon Aug 09 17:04:30 2010
Errors in file d:\oracle\admin\enmo\bdump\enmo_smon_3808.trc:
ORA-00600: internal error code, arguments: [kccocx_01], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [25015], [8], [6], [5], [], [], [], []
ORACLE Instance enmo (pid = 8) - Error 600 encountered while recovering transaction (6, 42)
数据库中回滚段 6 上 Slot 42 存在
一个死事务,也就是表空间创建失败后的事务无法回滚:
SQL> select ADDR,KTUXEUSN,KTUXESLT,KTUXESQN,KTUXESIZ,KTUXECFL 2 from x$ktuxe where ktuxeusn=6 and ktuxeslt=42;
ADDR KTUXEUSN KTUXESLT KTUXESQN KTUXESIZ KTUXECFL
-------- ---------- ---------- ---------- ---------- ------------------- 094878F0 6 42 332 1 DEAD
SQL> select distinct KTUXECFL,count(*) from x$ktuxe group by KTUXECFL;
KTUXECFL COUNT(*)
  ------------------------ ----------
DEAD 1
NONE 577
将 UNDO Header 转储出来,可以验证这个判断: SQL> select * from v$rollname;
USN NAME
---------- ------------------------------
0 SYSTEM
1 _SYSSMU1$
2 _SYSSMU2$
3 _SYSSMU3$
4 _SYSSMU4$
5 _SYSSMU5$
6 _SYSSMU6$
7 _SYSSMU7$
8 _SYSSMU8$
9 _SYSSMU9$
10 _SYSSMU10$ 
已选择 11 行。
SQL> alter system dump undo header "_SYSSMU6$";
系统已更改。
从跟踪文件中可以找到 6 号回滚段的内容,其中 2a 正是 10 进制的 42,此处的活动事务 不能回退导致数据库实例的挂起和故障,由于我们指定了损坏参数来打开数据库,这个回滚段 头被标记为损坏.
如果此时我们将 6 号回滚段标记为损坏,则可以避免回滚时出现的问题,正常无误的启 动数据库:
SQL> alter system set "_corrupted_rollback_segments"='_SYSSMU6$' scope=spfile;
系统已更改。
SQL> alter system set "_offline_rollback_segments"='_SYSSMU6$' scope=spfile;
系统已更改。
SQL> shutdown immediate;
数据库已经关闭。 
已经卸载数据库。 
ORACLE 例程已经关闭。 
SQL> startup
ORACLE 例程已经启动。
如果此时尝试 DROP 回滚段,则数据库还会出现 600 错误:
SQL> drop rollback segment "_SYSSMU6$";
drop rollback segment "_SYSSMU6$"
*
第 1 行出现错误:
ORA-00607: 当更改数据块时出现内部错误
ORA-00600: 内部错误代码, 参数: [kddummy_blkchk], [2], [89], [38508], [], [], [], []
SQL> drop tablespace enmo;
表空间已删除。
此后通过如下一系列的处理,数据库可以成功被打开,但是根据之前的分析,我们应当 知道,数据库因此被强制放弃了一些事务的一致性,最好通过导出/导入进行数据库重构:
SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;
系统已更改。
SQL> shutdown immediate;
数据库已经关闭。 
已经卸载数据库。 
ORACLE 例程已经关闭。 
SQL> startup mount; 
ORACLE 例程已经启动。
Total System Global Area 612368384 bytes
Fixed Size
Variable Size
Database Buffers
Redo Buffers
数据库装载完毕。
SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 1011115 (在 08/09/2010 17:52:04 生成) 对于线程 1 是必需的 
ORA-00289: 建议: D:\ORACLE\10.2.0\RDBMS\ARC00006_0726573063.001 
ORA-00280: 更改 1011115 (用于线程 1) 在序列 #6 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL} cancel
介质恢复已取消。
SQL> alter database open resetlogs;
数据库已更改。
SQL> create undo tablespace undotbs2 datafile size 10M;
表空间已创建。
SQL> alter system set undo_tablespace=undotbs2;
系统已更改。
SQL> alter tablespace undotbs1 offline;
表空间已更改。
SQL> drop tablespace undotbs1;
表空间已删除。