ITPub博客

首页 > 数据库 > Oracle > 关于SCN及HEARTBEAT的跟踪

关于SCN及HEARTBEAT的跟踪

原创 Oracle 作者:sqysl 时间:2009-01-28 21:36:21 0 删除 编辑

关机重启SCN及HEARTBEAT变化情况:
Mount状态:
1.       SCN:MOUNT状态不能获取;控制文件中SCN可取。
2.       Heartbeat增量(MOUNT状态):47265à-38221à37202à1544à-35521à68235(第二天)à22209à-45953
RBA及ON DISK RBA:MOUNT状态均未发生变化;MOUNT状态下,HEARTBEAT3秒递增一次,而且每3秒写一次控制文件。

3.       STARTUP MOUNT过程中,进行了10046-12跟踪,在CKPT后台进程文件里发现control file parallel write时间,时隔3秒;SMON进程文件里发现smon timer事件,PMON进程文件里发现pmon timer事件,时隔似乎都为300cs,即3秒。

4.       SCN(OPEN状态): 1564545à1565321(变化776*3/60=38.8分钟,不太可能)
                 1565347à1565842(变化495*3/60=24.75分钟,不太可能)
1565918à1566381(变化463*3/60=23.15分钟,不太可能)
每次都比上次关闭时有所增长,怀疑和系统内跟踪等工作有关。
RBA及ON DISK RBA: OPEN状态每次重启会变化;HEARTBEAT3秒递增一次,而且每3秒写一次控制文件。
结论:
1.       ORACLE系统自启动开始,就有了heartbeat,每3秒增长一次,每3秒CHKT进程写一次控制文件,每3秒SMON和PMON发生一次smon timer,pmon timer;
2.       ORACLE系统每次重新启动,heartbeat都会发生变化,每次变化幅度都不完全相同,而且有时增有时减;
3.       ORACLE系统每次启动,SCN都增长,而且和控制文件内的SCN不连续,可能是系统内部进展工作的问题,怀疑和跟踪有关;
4.           ORACLE的SCN和heartbeat虽然都是每3秒增长一次,但它们并不是一回事;但可以知道,SCN每3秒增长一次是在HEARTBEAT的基础上实现的;
5.       可以肯定这个3秒,命名问heartbeat可谓名副其实,在系统内部应该起着很重要的作用;但是否象和网友说的那样:系统用它来进行健康检查和RAC锁管理,没有证据;
6.       疑问:为何每次系统重启heartbeat和SCN都和以前不连续,而且heartbeat有增有减。

资料:
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 11, section in-use = 0,
  last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 11)
THREAD #1 - status:0x1 flags:0x0 dirty:0
low cache rba:(0xffffffff.ffffffff.ffff) on disk rba:(0x2e.7c6.0)
on disk scn: 0x0000.0017da9c 01/27/2009 21:46:52
resetlogs scn: 0x0000.000d8624 10/19/2008 10:09:18
heartbeat: 677260916 mount id: 4073502756

THREAD #1 - status:0x1 flags:0x0 dirty:0
low cache rba:(0xffffffff.ffffffff.ffff) on disk rba:(0x2e.7c6.0)
on disk scn: 0x0000.0017da9c 01/27/2009 21:46:52
resetlogs scn: 0x0000.000d8624 10/19/2008 10:09:18
heartbeat: 677308181 mount id: 4073466064

THREAD #1 - status:0x1 flags:0x0 dirty:0
low cache rba:(0xffffffff.ffffffff.ffff) on disk rba:(0x2e.7c6.0)
on disk scn: 0x0000.0017da9c 01/27/2009 21:46:52
resetlogs scn: 0x0000.000d8624 10/19/2008 10:09:18
heartbeat: 677269960 mount id: 4073493122

THREAD #1 - status:0x1 flags:0x0 dirty:0
low cache rba:(0xffffffff.ffffffff.ffff) on disk rba:(0x2e.7c6.0)
on disk scn: 0x0000.0017da9c 01/27/2009 21:46:52
resetlogs scn: 0x0000.000d8624 10/19/2008 10:09:18
heartbeat: 677307162 mount id: 4073465301

THREAD #1 - status:0x1 flags:0x0 dirty:0
low cache rba:(0xffffffff.ffffffff.ffff) on disk rba:(0x2e.7c6.0)
on disk scn: 0x0000.0017da9c 01/27/2009 21:46:52
resetlogs scn: 0x0000.000d8624 10/19/2008 10:09:18
heartbeat: 677308706 mount id: 4073467357

THREAD #1 - status:0x1 flags:0x0 dirty:0
low cache rba:(0xffffffff.ffffffff.ffff) on disk rba:(0x2e.7c6.0)
on disk scn: 0x0000.0017da9c 01/27/2009 21:46:52
resetlogs scn: 0x0000.000d8624 10/19/2008 10:09:18
heartbeat: 677273185 mount id: 4073495835

THREAD #1 - status:0x1 flags:0x0 dirty:0
low cache rba:(0xffffffff.ffffffff.ffff) on disk rba:(0x2e.96a.0)
on disk scn: 0x0000.0017dc87 01/28/2009 15:09:57
resetlogs scn: 0x0000.000d8624 10/19/2008 10:09:18
heartbeat: 677341420 mount id: 4073522339

THREAD #1 - status:0x1 flags:0x0 dirty:0
low cache rba:(0xffffffff.ffffffff.ffff) on disk rba:(0x2e.17b6.0)
on disk scn: 0x0000.0017ea8d 01/28/2009 16:11:10
resetlogs scn: 0x0000.000d8624 10/19/2008 10:09:18
heartbeat: 677363629 mount id: 4073571688

THREAD #1 - status:0x2 flags:0x0 dirty:39
low cache rba:(0x2e.1a60.0) on disk rba:(0x2e.1ac6.0)
on disk scn: 0x0000.0017ee35 01/28/2009 18:11:21
resetlogs scn: 0x0000.000d8624 10/19/2008 10:09:18
heartbeat: 677317676 mount id: 4073543895




Process Monitor Process (PMON)
The process monitor (PMON) performs process recovery when a user process fails.
PMON is responsible for cleaning up the database buffer cache and freeing resources
that the user process was using. For example, it resets the status of the active
transaction table, releases locks, and removes the process ID from the list of active
processes.
PMON periodically checks the status of dispatcher and server processes, and restarts
any that have stopped running (but not any that Oracle Database has terminated
intentionally). PMON also registers information about the instance and dispatcher
processes with the network listener.
Like SMON, PMON checks regularly to see whether it is needed and can be called if
another process detects the need for it.

The system monitor process (SMON) performs recovery, if necessary, at instance
startup. SMON is also responsible for cleaning up temporary segments that are no
longer in use and for coalescing contiguous free extents within dictionary managed
tablespaces. If any terminated transactions were skipped during instance recovery
because of file-read or offline errors, SMON recovers them when the tablespace or file
is brought back online. SMON checks regularly to see whether it is needed. Other
processes can call SMON if they detect a need for it.
With Real Application Clusters, the SMON process of one instance can perform.
instance recovery for a failed CPU or instance.

Checkpoint Process (CKPT)
When a checkpoint occurs, Oracle Database must update the headers of all datafiles to
record the details of the checkpoint. This is done by the CKPT process. The CKPT
process does not write blocks to disk; DBW n always performs that work.
The statistic DBWR checkpoints displayed by the System_Statistics monitor in
Oracle Enterprise Manager indicates the number of checkpoint requests completed.

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

上一篇: ASCII编码表
请登录后发表评论 登录
全部评论
上世纪90年代初至今,一直默默深耕于数据库领域,擅长数据库优化、数据库分析诊断、数据库规划设计等。曾供职于能源、金融、电信等行业,任多家知名大型企业首席DBA及数据库架构师等职位。

注册时间:2008-06-27

  • 博文量
    321
  • 访问量
    540074