标签：file block 进程 崩溃 thread ati red started imm
oracle 11g 数据库恢复技术 ---02 控制文件
SYS@ orcl >show parameter control_file NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ control_file_record_keep_time integer 7 control_files string /u01/app/oracle/oradata/orcl/c ontrol01.ctl, /u01/app/oracle/ oradata/orcl/control02.ctl
多个oracle进程将控制文件做信息注册、交换的中心，健康的控制文件是数据库启动至mount阶段的必要条件
在备份与恢复中，控制文件同样非常重要，db在mount时，该文件本身的信息就足以判断数据库是否需要介质恢复、上一次db是否正常关闭，在db open时，
oracle通过检查其他文件的头与控制文件中的信息进行交叉校验，从而判断当前控制文件是否为旧或从备份中还原而来的控制文件。
控制文件的主要任务信息是管理数据库的状态及描述数据库物理结构
控制文件至少包含以下信息：
--1 数据库名 --2 dbid --3 db创建时间戳 --4 db 字符集 --5 datafile信息 --6 tempfile信息 --7 online redo log --8 近期的归档日志信息 --9 tablespace 信息 --10 rman备份文件信息，即rman资料库 --11 checkpoint信息 --12 损坏的数据块注册表 --13 还原点信息 --14 重设日志SCN --15 脏数据块的数量
数据库实例的启动的3个阶段：
--1 nomount，需要打开参数文件
--2 mount，需要打开控制文件
--3 open，需要打开所有的online redo log和online datafile
控制文件还包含恢复数据库所需要的信息，如rman备份信息、检查点SCN以及从各个在线日志和数据文件头部复制而来的信息（比如用作交叉校验的数据文件头部检查点SCN和RBA）
只要db处于open，会有多个进程进行R/W操作，CKPT,LGWR,ARCn，DBRn，MMON等其他后台进程
每个数据库拥有的一个编号，称为数据库标识符，在创建db时自动生成，除了使用nid命令修改之外，dbid是不会变的。
DBID散布于db的各个文件中：控制文件、数据文件和日志文件头部。在恢复的时候，以自动备份恢复控制文件时，rman提升需要指定dbid
--restore controlfile from autobackup;
--must explicitly specify dbid with set dbid command
获取dbid的方法
--SYS@ orcl >select dbid from v$database; DBID ---------- 1534031567
--查看控制文件自动备份的文件名
--dump或者bbed查看数据文件头部信息
--若启用了recovery catalog，通过查询db
使用rman 自动备份的控制文件名
RMAN> backup tablespace users; RMAN> list backup; Piece Name: /u01/app/oracle/product/11.2.0/db_1/dbs/c-1534031567-20190522-00 --转储文件 SYS@ orcl > alter system dump logfile ‘/u01/app/oracle/arch/1_259_1006250831.dbf‘; SYS@ orcl > select value from v$diag_info where name=‘Default Trace File‘; /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_10017.trc [oracle@DSI arch]$ grep -i ‘db id‘ /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_10017.trc Db ID=1534031567=0x5b6f76cf, Db Name=‘ORCL‘ --bbed alter session set events ‘immediate trace name controlf level 2‘; select * from v$diag_info; BBED> set filename ‘/u01/app/oracle/oradata/orcl/control01.ctl‘; BBED> dump [root@DSI ~]# more /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_16425.trc DUMP OF CONTROL FILES, Seq # 4067 = 0xfe3 V10 STYLE FILE HEADER: Compatibility Vsn = 186647552=0xb200400 Db ID=1534031567=0x5b6f76cf, Db Name=‘ORCL‘ Activation ID=0=0x0 Control Seq=4067=0xfe3, File size=614=0x266 File Number=0, Blksiz=16384, File Type=1 CONTROL SYS@ orcl >select to_number(‘5b6f76cf‘,‘xxxxxxxxxxxxx‘) from dual; TO_NUMBER(‘5B6F76CF‘,‘XXXXXXXXXXXXX‘) ------------------------------------- 1534031567 SYS@ orcl > select to_char(1534031567,‘xxxxxxxxxxxxx‘) from dual; TO_CHAR(153403 -------------- 5b6f76cf BBED> set file 1 block 1 BBED> map /v BBED> p kcvfh Offset 28~31 5b6f76cf 表示DBID
数据库物理结构是在线日志路径、数据文件路径、表空间信息和备份文件信息的汇总。
物理结构可以查询相应的动态视图，在db处于mount状态即可查询
--v$database\v$archived_log\v$datafile\v$tmepfile\v$log\v$logfile\v$recover_file SYS@ orcl >startup mount; ORACLE instance started. Total System Global Area 784998400 bytes Fixed Size 2257352 bytes Variable Size 511708728 bytes Database Buffers 264241152 bytes Redo Buffers 6791168 bytes Database mounted. SYS@ orcl >select * from v$logfile; SYS@ orcl >select * from v$database; SYS@ orcl >select * from v$datafile; SYS@ orcl >select group#,status,thread#,sequence#,archived from v$Log; SYS@ orcl >select name,sequence# from v$archived_log; SYS@ orcl >select file#,name from v$datafile; SYS@ orcl >select file#,name from v$tempfile;
--dbid，数据库标识符不仅保存在控制文件中，在datafile和日志文件的头部也存在，是判断控制文件、日志文件和数据文件是否属于同一个数据库
--数据库名，此信息与dbid作用一致，也保存在数据文件和日志问题头部
--控制文件序列号，是判断控制文件是否过”旧”的要素之一，控制文件更新后就会增加，控制文件更新包括检查点信息更新、创建或删除表空间等。
控制文件序列号在数据文件和重做日志的头部也有，与控制文件的不同，它们是在自身的头部被更新时从当时的控制文件复制的。
分别获得当前控制文件记录的及当前数据文件头部中记录的控制文件序列号
SYS@ orcl >select controlfile_sequence# from v$database; CONTROLFILE_SEQUENCE# --------------------- 8327 SYS@ orcl >select hxfil as file#,fhcsq from x$kcvfh; FILE# FHCSQ ---------- ---------- 1 8269 2 8269 3 8269 4 8269 5 8301
上面结果8327（控制文件中的）大于8301（数据文件中的），这是很正常的。
--控制文件检查点SCN，该scn也是判断控制文件是否是”旧”的要素之一，完全检查点把scn更新到控制文件和数据文件中，而增量检查点仅把scn更新到控制文件中。无论是哪一种检查点，其scn在控制文件中由一个称为控制文件检查点scn的记录表示。
实际上，不管控制文件发生任何形式的更改，该SCN都会上升，在db为open状态，这个SCN一定>=current重做日志的低位SCN(v$log.first_change#)
SYS@ orcl >select controlfile_change# from v$database; CONTROLFILE_CHANGE# ------------------- 9297603
控制文件检查点scn必须>=所有数据文件头部的检查点SCN号，否则，控制文件同样被认为”旧”，实例恢复无法启动。
--数据库检查点SCN，控制文件中保存的数据库检查点scn号实际上是在所有数据文件头部中最小的检查点scn，根据他的值与每个重做日志的高、低位scn比较，oracle可以确定恢复数据文件需要使用的第一个日志文件。
SYS@ orcl >select checkpoint_change#,controlfile_change# from v$database; CHECKPOINT_CHANGE# CONTROLFILE_CHANGE# ------------------ ------------------- 9330966 9333793
--在线日志文件低位scn(first_change#)和高位scn(next_change#),日志文件中的重做记录范围是由这两个scn来表示的，低位scn指日志文件中第一条重做记录的scn，而高位scn是指下一个日志文件中的第一个重做记录的scn。
SYS@ orcl >select group#,first_change#,next_change# from v$log; GROUP# FIRST_CHANGE# NEXT_CHANGE# ---------- ------------- ------------ 1 9330966 2.8147E+14 ---0xfffffffffffff（当前正在写的文件） 2 9311463 9330958 3 9330958 9330966
根据上面数据，如果当前数据库检查点scn是9330967，并且现在实例意外崩溃，显然只需要1号日志文件就可以对数据库完成恢复。
--rman资料库，在默认情况下，控制文件有rman的记录：rman的配置、闪回日志路径、重做日志历史、归档日志路径及属性、rman备份集信息、rman镜像复制信息、rman备份集和rman镜像复制中损坏的数据块信息、数据文件中块数据信息等。
--还原点信息，scn的别名，通过’create restore point’命令创建，主要用于闪回技术。
--重设日志scn，每次使用resetlogs打开db时候的scn，日志文件和数据文件头部也会保存该scn，每次open db，都会检查是否一致。resetlogs一般是不完全恢复的结果。
标签：file block 进程 崩溃 thread ati red started imm
原文地址：https://www.cnblogs.com/yhq1314/p/10912174.html
