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

控制文件和引导

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;

表空间已删除。