ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 深入浅出Oracle学习笔记(1)

深入浅出Oracle学习笔记(1)

原创 Linux操作系统 作者:gvora 时间:2009-04-27 17:47:25 0 删除 编辑

第一章 数据库的启动和关闭
一、数据库启动
1、启动数据库到nomount状态:
Oracle首先寻找参数文件(pfile/spfile),然后根据参数文件中的设置,创建实例,分配内存,启动后台进程。
Alert_.log中可以看到这一阶段的启动过程,读取参数文件,应用参数启动实例,所有在参数文件中定义的非缺省参数都会记录在警报日志文件中,然后后天进程依次启动。
在参数文件中,通常需要最少的参数是db_name,设置了这个参数之后,数据库实例就可以启动。
2、启动数据库到mount状态:
启动到nomount状态以后,Oracle就可以从参数文件中获得控制文件的位置信息,在mount数据库的过程中,Oracle需要找到控制文件并锁定控制文件。
启动到mount状态,数据库必须具备的另一个重要文件是口令文件,该文件位于$ORACLE_HOME/dbs目录下,缺省的名称为orapw
口令文件中存放sysdba/sysoper用户的用户名和口令。在数据库没有启动之前,数据库内建用户是无法通过数据库本身来验证身份的,通过口令文件,Oracle可以实现对用户的身份认证,在数据库未启动之前登陆,进而启动数据库。
如果丢失了口令文件,在mount阶段就会出现错误。
3、启动数据库到open阶段:
Oracle主要进行的检查包括以下两项:
--检查数据文件头中的检查点计数(Checkpoint Cnt)是否和控制文件中的检查点计数一致。此步骤检查用以确认数据文件是来自同一版本,而不是从备份中恢复而来(因为Checkpoint Cnt不会被冻结,会一直被修改)。
执行Begin Backup之后,Checkpoint Cnt增加1,对表空间Begin Backup会触发一次表空间检查点,故检查点计数随之增加;
在表空间热备份模式下,手工执行检查点后,Checkpoint Cnt增加,但是SCN不再改变,这是因为表空间处于热备份模式,数据文件检查点被冻结。
End Backup后,数据文件头的冻结被取消,SCN开始变化。
--如果检查点计数检查通过,则数据库进行第二次检查:数据文件头的开始SCN和控制文件中记录的该文件的结束SCN是否一致,如果控制文件中记录的结束SCN等于数据文件头的开始SCN,则不需要对那个文件进行恢复。
对每个数据文件都完成检查后,打开数据库,锁定数据文件,同时将每个数据文件的结束SCN设置为无穷大。

二、SCN
SCN(System Change Number)系统改变号,用以标识数据库在某个确切时刻提交的版本。在事务提交时,它被赋予一个唯一的标识事务的SCN。
SCN是Oracle内部的时钟机制,Oracle通过SCN来维护数据库的一致性,并通过SCN实施Oracle至关重要的恢复机制。
SCN在数据库中是无处不在的,常见的事务表、控制文件、数据文件头、日志文件、数据块头等都记录有SCN值。
可以通过如下两种方式获得数据库的当前或近似SCN:
从Oracle 9i开始,可以使用dbms_flashback.get_system_change_number来获得:
SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                 5111496
Oracle 9i前,可以通过查询x$ktuxe获得系统最接近当前值的SCN:
SQL> select max(ktuxescnw*power(2,32)+ktuxescnb) from x$ktuxe;

MAX(KTUXESCNW*POWER(2,32)+KTUXESCNB)
------------------------------------
                             5112238
系统当前的SCN并不是在任何的数据库操作发生时都会改变,SCN通常在事务提交或回滚时改变。在控制文件、数据文件头、数据块、日志文件头、日志文件change vector中都有SCN,但其作用各不相同。
1、数据文件头中包含了该数据文件的Checkpoint SCN,表示该数据文件最近一次执行检查点操作时的SCN。
从控制文件的dump文件中,可以得到以下内容:
SQL> alter session set events 'immediate trace name CONTROLF level 10';
会话已更改。

DATA FILE #1:
  (name #8) D:\ORACLE\ORADATA\GVORA\SYSTEM01.DBF
creation size=0 block size=8192 status=0xe head=8 tail=8 dup=1
 tablespace 0, index=6 krfil=1 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:293 scn: 0x0000.004d2eb9 04/26/2009 12:35:55
 Stop scn: 0xffff.ffffffff 04/26/2009 01:20:25
……………..
对于每一个数据文件都包含一个这样的条目,记录该文件的检查点SCN的值以及检查点发生的时间。
可以通过命令转储数据文件头,观察其具体信息及检查点记录:
SQL> alter session set events 'immediate trace name file_hdrs level 10';
会话已更改。

2、日志文件头中包含了Low SCN和Next SCN
Low SCN和Next SCN这两个SCN表示了该日志文件包含有介于Low SCN到Next SCN的重做信息,对于Current的日志文件(当前正在被使用的Redo Logfile),其最终SCN不可知,所以Next SCN被置为无穷大,也就是ffffffff。
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ----------
         1          1        116  104857600          1 NO  INACTIVE
      5005169 25-4月 -09

         2          1        117  104857600          1 NO  CURRENT
      5058232 26-4月 -09

         3          1        115  104857600          1 NO  INACTIVE
      4861140 25-4月 -09

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                 5117682
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ----------
         1          1        116  104857600          1 NO  INACTIVE
      5005169 25-4月 -09

         2          1        117  104857600          1 NO  ACTIVE
      5058232 26-4月 -09

         3          1        118  104857600          1 NO  CURRENT
      5118009 26-4月 -09

SQL> alter session set events 'immediate trace name CONTROLF level 10';

会话已更改。

可以看到,SCN 5117682显然位于Log Group#为2的日志文件中,该日志文件包含了SCN自5058232至5118009的Redo信息。Oracle在进行恢复时就需要根据低SCN和高SCN来确定需要的恢复信息位于哪一个日志或归档文件中。
通过控制文件转储,可以在控制文件中找到关于日志文件的信息:
LOG FILE #1:
  (name #3) D:\ORACLE\ORADATA\GVORA\REDO01.LOG
 Thread 1 redo log links: forward: 2 backward: 0
 siz: 0x32000 seq: 0x00000074 hws: 0x5 bsz: 512 nab: 0x5913 flg: 0x0 dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.004a2cd4
 Low scn: 0x0000.004c5f71 04/25/2009 22:36:21
 Next scn: 0x0000.004d2eb8 04/26/2009 12:35:55
LOG FILE #2:
  (name #2) D:\ORACLE\ORADATA\GVORA\REDO02.LOG
 Thread 1 redo log links: forward: 3 backward: 1
 siz: 0x32000 seq: 0x00000075 hws: 0x2 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.004c5f71
 Low scn: 0x0000.004d2eb8 04/26/2009 12:35:55
 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
LOG FILE #3:
  (name #1) D:\ORACLE\ORADATA\GVORA\REDO03.LOG
 Thread 1 redo log links: forward: 0 backward: 2
 siz: 0x32000 seq: 0x00000073 hws: 0x6 bsz: 512 nab: 0x148fb flg: 0x0 dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.004942e9
 Low scn: 0x0000.004a2cd4 04/25/2009 11:52:43
 Next scn: 0x0000.004c5f71 04/25/2009 22:36:21
可以注意到,Log File2是当前的日志文件,该文件拥有的Next SCN为无穷大。
同样,可以通过直接dump日志文件的方式来进行转储:
SQL> select * from v$logfile;

    GROUP# STATUS  TYPE    MEMBER
---------- ------- ------- ---------------------------------------------
         3         ONLINE  D:\ORACLE\ORADATA\GVORA\REDO03.LOG
         2         ONLINE  D:\ORACLE\ORADATA\GVORA\REDO02.LOG
         1         ONLINE  D:\ORACLE\ORADATA\GVORA\REDO01.LOG

SQL> alter system dump logfile 'D:\ORACLE\ORADATA\GVORA\REDO03.LOG';
系统已更改。

三、检查点
1、检查点的本质
检查点只是一个数据库事件,它存在的根本意义在于减少崩溃恢复(Crash Recovery)时间。
当检查点发生时(此时的SCN被称为Checkpoint SCN),Oracle会通知DBWR进程把修改过的数据,也就是此Checkpoint SCN之前的脏数据从Buffer Cache写入磁盘,当写入完成之后,CKPT进程更新控制文件和数据文件头,记录检查点信息,标示变更。
Checkpoint SCN可以从数据库中查询得到:
SQL> select file#,checkpoint_change#,to_char(checkpoint_time,'yyyy-mm-dd hh24:mi
:ss') cpt from v$datafile;

     FILE# CHECKPOINT_CHANGE# CPT
---------- ------------------ -------------------
         1            5118009 2009-04-26 18:03:00
         2            5118009 2009-04-26 18:03:00
         3            5118009 2009-04-26 18:03:00

SQL> select dbid,checkpoint_change# from v$database;

      DBID CHECKPOINT_CHANGE#
---------- ------------------
 389716958            5118009

检查点的频度对于数据库的恢复事件具有极大的影响。
2、常规检查点和增量检查点
在Oracle 8i之前,Oracle实施的检查点通常被称为常规检查点(Conventional Checkpoint),这类检查点按一定的条件触发(log_checkpoint_interval、log_checkpoint_timeout参数设置及log switch等条件触发)。从Oracle 8i开始,Oracle引入了增量检查点(Incremental Checkpoint)的概念。主要引入了检查点队列机制,在数据库内部,每一个脏数据块都会被移动到检查点队列,按照Low RBA的顺序(第一次对此数据块修改对应得Redo Byte Address)来排列,如果一个数据块进行过多次修改,该数据块在检查点队列上的顺序并不会发生变化。
当执行检查点时,DBWR从检查点队列按照Low RBA的顺序写出,实例检查点因此可以不断增进,CKPT进程使用非常轻量级的控制文件更新协议将当前的最低RBA写入控制文件。因为增量检查点可以连续地进行,因此检查点RBA可以比常规检查点更接近数据库的最后状态,从而在数据库的实例恢复中可以极大地减少恢复时间。而且,通过增量检查点,DBWR可以持续进行写出,从而避免了常规检查点触发的峰值写入对于I/O的过度征用。
在数据库中,增量检查点是通过Fast-Start Checkpointing特性来实现的,从Oracle 8i开始,这一特性包含在Oracle企业版的Fast-Start Fault Recovery组件中,可以查询v$option:
SQL> select * from v$option where parameter='Fast-Start Fault Recovery';

PARAMETER                           VALUE
----------------------------------- ------------------------------
Fast-Start Fault Recovery           TRUE
该组件包含3个主要特性,可以加快系统在故障后的恢复,提高系统的可用性:
Fast-Start Checkpointing
Fast-Start On-Demand Rollback
Fast-Start Parallel Rollback

3、FAST_START_MTTR_TARGET
FAST_START_MTTR_TARGET参数从Oracle 9i开始被引入,该参数定义数据库进行Crash恢复的时间。
SQL> select MTTR_TARGET_FOR_ESTIMATE mttrest,
  2  ADVICE_STATUS ad,
  3  DIRTY_LIMIT dl,
  4  ESTD_CACHE_WRITES estcw,
  5  ESTD_CACHE_WRITE_FACTOR estcwf,
  6  ESTD_TOTAL_WRITES estw,
  7  ESTD_TOTAL_WRITE_FACTOR estwf,
  8  ESTD_TOTAL_IOS estio
  9  from v$mttr_target_advice;

   MTTREST   AD     DL   ESTCW  ESTCWF    ESTW  ESTWF     ESTIO
---------- ----- ---------- ---------- ---------- ----------  ----------   ----------
        71    ON     1000    849       1        869       1         2652
        93    ON     3000    849       1        869       1         2652

该视图评估在不同FAST_ START_MTTR_TARGET设置下,系统需要执行的I/O次数等操作。这个建议信息的收集受到Oracle 9i新引入的初始化参数statistics_level的控制,当该参数设置为Typical或ALL时MTTR建议信息被收集。
SQL> show parameter statistics_level
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
statistics_level                     string      TYPICAL
也可以通过v$statistics_level视图来查询MTTR Advice的当前设置。
SQL> select * from v$statistics_level
  2  where statistics_name='MTTR Advice';
STATISTICS_NAME
----------------------------------------------------------------
DESCRIPTION
--------------------------------------------------------------------------------
SESSION_ SYSTEM_S ACTIVAT
-------- -------- -------
STATISTICS_VIEW_NAME                                             SES
---------------------------------------------------------------- ---
MTTR Advice
Predicts the impact of different MTTR settings on number of physical I/Os
ENABLED  ENABLED  TYPICAL
V$MTTR_TARGET_ADVICE                                             NO
数据库的当前实例恢复状态可以通过视图v$instance_recovery得到:
SQL> select * from v$instance_recovery;
RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_REDO_BLKS LOG_FILE_SIZE_REDO_BLKS
---------------------- ---------------- ---------------- -----------------------
LOG_CHKPT_TIMEOUT_REDO_BLKS LOG_CHKPT_INTERVAL_REDO_BLKS
--------------------------- ----------------------------
FAST_START_IO_TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR CKPT_BLOCK_WRITES
------------------------------ ----------- -------------- -----------------
                    64             3845             4054                  184320
                       4054
                                        93             42               179
从v$instance_recovery视图可以看到数据库估计的平均恢复时间参数:ESTIMATED_MTTR。ESTIMATED_MTTR的估计值是基于Dirty Buffer的数量和日志块数量得出的,这个参数值告诉我们如果此时数据库崩溃,那么进行实例恢复将会需要的时间。
在v$instance_recovery视图中,TARGET_MTTR代表的是期望的平均恢复时间,通常该参数应该等于FAST_START_MTTR_TARGET参数设置值。
当ESTIMATED_MTTR接近或超过TARGET_MTTR时,系统就会触发检查点,系统恢复信息将会重新计算。通过CKPT_BLOCK_WRITES字段可以看出检查点已经写出的数据块的数量,增量检查点的触发以及DBWR的持续写出,都会促使该值增加。
在繁忙的系统中,可能会观察到ESTIMATED_MTTR>TARGET_MTTR,这可能是因为DBWR正忙于写出,甚或出现Checkpoint不能及时完成的情况。
4、Oracle 10g自动检查点调整
使用自动调整的检查点,Oracle数据库可以利用系统的低I/O负载时段写出内存中的脏数据,从而提高数据库的效率。当FAST_START_MTTR_TARGET参数未设置时,自动检查点调整生效。
通常,如果必须严格控制实例或节点恢复时间,那么可以设置FAST_START_MTTR_TARGET为期望时间值;如果恢复时间不需要严格控制,那么可以不设置FAST_START_MTTR_TARGET参数,从而启用Oracle 10g的自动检查点调整特性。
10g在v$instance_recovery视图中,WRITES_AUTOTUNE字段值指由于自动调整检查点执行的写出次数,而CKPT_BLOCK_WRITES指的则是由于检查点写出的Block的数量。
5、从控制文件获取检查点信息
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
 (blkno = 0x4, size = 104, max = 1, in-use = 1, last-recid= 0)
THREAD #1 - status:0x2 flags:0x0 dirty:69
low cache rba:(0x75.7e9e.0) on disk rba:(0x75.8f57.0)
on disk scn: 0x0000.004e062f 04/26/2009 17:39:38
resetlogs scn: 0x0000.0002e872 04/04/2009 16:43:12
heartbeat: 685205139 mount id: 391608798
MTTR statistics status: 3
Init time: Avg: 35121550, Times measured: 3
File open time: Avg: 533711, Times measured: 29
Log block read time: Avg: 96, Times measured: 54758
Data block handling time: Avg: 10865, Times measured: 1109
这里low cache rba(Recovery block adress)指在Cache中最低的RBA地址,在实例恢复或者崩溃恢复中,需要从这里开始恢复。on disk rba是磁盘上的最高的重做值,在进行恢复时应用重做至少要达到这个值。

四、数据库是怎样根据SCN和Checkpoint来进行一致性判断及恢复控制的?
在控制文件和数据文件头上,对于每个数据文件都有一个“Checkpoint SCN”和“Stop SCN”。Oracle通过比较这些SCN值来确定数据库是否需要恢复。
因为在数据库正常关闭之前会执行完全检查点,所以线程检查点SCN和所有数据文件检查点SCN和数据文件Stop SCN都一致。
当数据库进行异常关闭的时候,各部分的Checkpoint SCN都一致,由于数据库是异常关闭,数据库没有完成最后的检查点,数据文件的Stop SCN仍然为无穷大,因此数据文件的Stop SCN不等于Checkpoint SCN,此时启动数据库需要进行恢复。

SQL> startup mount
ORACLE 例程已经启动。

Total System Global Area  135338868 bytes
Fixed Size                   453492 bytes
Variable Size             109051904 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
SQL> alter session set sql_trace=true;

会话已更改。

SQL> alter database open;

数据库已更改。

SQL> alter session set sql_trace=false;

会话已更改。

SQL> select segment_name,file_id,block_id from dba_extents
  2  where block_id=377 and file_id=1;

SEGMENT_NAME            FILE_ID   BLOCK_ID
-------------------- ---------- ----------
BOOTSTRAP$                    1        377

SQL> select * from bootstrap$ where line#<5;

     LINE#       OBJ#
---------- ----------
SQL_TEXT
--------------------------------------------------------------------------------

        -1         -1
8.0.0.0.0

         0          0
CREATE ROLLBACK SEGMENT SYSTEM STORAGE (  INITIAL 112K NEXT 1024K MINEXTENTS 1 M

AXEXTENTS 32765 OBJNO 0 EXTENTS (FILE 1 BLOCK 9))

从上面可以看出,bootstrap$中实际上是记录了一些数据库系统基本对象的创建语句。Oracle通过bootstrap$进行引导,进一步创建相关的重要对象,从而启动了数据库。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15203236/viewspace-591980/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-12-30

  • 博文量
    62
  • 访问量
    288174