January 24, 2006
作者:eygle
X$KCCCP--[K]ernel [C]ache [C]ontrolfile management [c]heckpoint [p]rogress
其命名规则可以参考:X$ Tables and how the names are derived .
SQL> desc X$KCCCP
Name Null? Type
---------------- -------- ------------------------
ADDR RAW(4)
INDX NUMBER
INST_ID NUMBER
CPTNO NUMBER
CPSTA NUMBER
CPFLG NUMBER
CPDRT NUMBER
CPRDB NUMBER
CPLRBA_SEQ NUMBER
CPLRBA_BNO NUMBER
CPLRBA_BOF NUMBER
CPODR_SEQ NUMBER
CPODR_BNO NUMBER
CPODR_BOF NUMBER
CPODS VARCHAR2(16)
CPODT VARCHAR2(20)
CPODT_I NUMBER
CPHBT NUMBER
CPRLS VARCHAR2(16)
CPRLC NUMBER
CPMID NUMBER
CPSDR_SEQ NUMBER
CPSDR_BNO NUMBER
CPSDR_ADB NUMBER
|
在此视图中,CPHBT字段代表checkpoint heartbeat,每三秒更新一次,并写入控制文件的heartbeat部分.
我们可以简单的通过如下方式查看CPHBT:
SQL> select cphbt from X$KCCCP;
CPHBT
----------
580567934
|
Posted by eygle at 2:52 PM
| Comments (0)
作者:eygle
在网上看到一个有趣的图片,是Learn French的广告.碰巧前几天读过一篇文章才懂得这幅图的意思.
你知道么?如果不知道,请参考:What is mean Frenchletter? 嘿嘿!
Posted by eygle at 10:42 AM
| Comments (2)
January 23, 2006
作者:eygle
留言版上的第2330号问题是:
在oralce中给自建函数创建索引，结果不成功。
source:Create Index IDX_T_SP_TWOTYPESTAT_0_f On T_SP_TWOTYPESTAT_0(f_dateadd(yearmonth,12,2));
err:the function is not deterministic.
我们看一下这是为什么?
随便一个测试可以再现这个问题,我门创建一个函数(本范例函数用于进行16进制向10进制转换):
CREATE OR REPLACE FUNCTION h2ten (
p_str IN VARCHAR2,
p_from_base IN NUMBER DEFAULT 16
)
RETURN NUMBER
IS
l_num NUMBER DEFAULT 0;
l_hex VARCHAR2 (16) DEFAULT '0123456789ABCDEF';
BEGIN
FOR i IN 1 .. LENGTH (p_str)
LOOP
l_num :=
l_num * p_from_base + INSTR (l_hex, UPPER (SUBSTR (p_str, i, 1)))
- 1;
END LOOP;
RETURN l_num;
END h2ten;
|
此时创建索引,获得如下错误信息:
SQL> create table t as select username,'a' hex from dba_users;
Table created
SQL> create index i_t on t (h2ten(hex));
create index i_t on t (h2ten(hex))
ORA-30553: The function is not deterministic
|
如果需要创建基于自定义函数的索引,那么我们需要指定deterministic参数:
CREATE OR REPLACE FUNCTION h2ten (
p_str IN VARCHAR2,
p_from_base IN NUMBER DEFAULT 16
)
RETURN NUMBER DETERMINISTIC
IS
l_num NUMBER DEFAULT 0;
l_hex VARCHAR2 (16) DEFAULT '0123456789ABCDEF';
BEGIN
FOR i IN 1 .. LENGTH (p_str)
LOOP
l_num :=
l_num * p_from_base + INSTR (l_hex, UPPER (SUBSTR (p_str, i, 1)))
- 1;
END LOOP;
RETURN l_num;
END h2ten;
|
此时创建索引即可:
SQL> create index i_t on t (h2ten(hex));
Index created
|
Oracle这样解释这个参数:
The hint DETERMINISTIC helps the optimizer avoid redundant function calls. If a stored function was called previously with the same arguments, the optimizer can elect to use the previous result. The function result should not depend on the state of session variables or schema objects. Otherwise, results might vary across calls. Only DETERMINISTIC functions can be called from a function-based index or a materialized view that has query-rewrite enabled.
Posted by eygle at 10:59 AM
| Comments (2)
January 22, 2006
作者:eygle
据多日观测,临近年终,国内各行业数据库已经进入了数据库事故多发期,主要重大事故有:
误删表空间
System损坏
又一个System损坏
再加上今日,dcba又报道了一例redo损坏的重大事故:
在open时删除了所有的联机log后能起来吗?
在这里我不想就具体技术细节进行评论,我只想说说我对这些问题的看法.在我反复面试我的DBA们时,经常我会谈到:
在我们这里,你不会遇到太复杂的恢复情况,一个管理良好的数据库始终能够从容的从事故或灾难中恢复出来,所以比较起来,在复杂的技术和严谨的态度之间,我们更需要你的严谨.
这也是我对DBA的一个基本要求,如果你足够严谨,以上的情况你可能都不需要面对,最严重的情况,你还有有效的备份可以恢复.在我主讲的DBA课程中,我曾经提到的DBA四大守则里,第一守则就是:
备份重于一切
系统总是要崩溃的，没有有效的备份只是等哪一天死！
然而可惜的是大多数人都在运行无备份的数据库系统,这是DBA的悲哀.
顺便说一句的是DCBA的这个案例:在open时删除了所有的联机log后能起来吗?.
我认为是可以恢复的,ORA-00600的4194错误并非无解,只是不同情况要区别对待就是了.
Posted by eygle at 2:48 PM
| Comments (3)
January 21, 2006
作者:eygle
Julia曾经发过一则短信给我,要我猜:"2b?nt2b????" 是什么意思.
还好我猜到了答案,这是莎士比亚作品「哈姆雷特」的名句:To Be Or Not To Be, That Is The Question.
今天来个词语造句:回家还是不回,这是一个问题.
是否可以这样写 "gh?ntgh????" 呢?
图中是19日北京西客站的一幕,据说当时整个西客站已经没有落足之地了,滞留旅客高达十数万.当然,还好,这一次是因为大雪.
可是如果不下雪呢?如果你在新年期间坐过火车,我想大家都经历过火车上类似的局面.总之我经历过多次,一点都不夸张,如果你提起脚,那就再也找不到放下去的地方.
而且这还不算,你也许还可以看到这样的新闻:
本报讯(1月21日 记者刘洋) 从今天开始，全国铁路的火车票价格开始上浮，其中硬座上浮15%，其他席别上浮20%.受到车票价格上浮的影响，北京铁路的客流昨天又创新高，其中北京西站的客流达到了14万。
这个消息让我想起了一部我非常钟爱的影片《教父》，片中老教父维托·唐·科莱昂曾经有一句经典名言：
我会给他一个他不能拒绝的条件。
同样的，这个条件我们也无法拒绝。
Julia昨天对我说,她曾经和公司里的清洁工人闲聊,问她们春节回家的事情,那些工人叹息着说:其实这一往返,两个月的工资就用完了. 而且前提还是能买到票,票价不要涨的更高.
Julia继续说，附近的公路交通也在涨价，平时30元的票价现在涨到35元，随后要涨到45元，涨幅是50%. 可是你知道这15元对那些艰辛的打工人以为着什么么？那可能是一家人好久的生活开支啊。
Julia说，我无法再说下去了，再说要流泪了。我想起了艾青的两句诗：
为什么我的眼中常含泪水? 因为我对这土地爱得深沉……
我想每个善良的人都是那么容易被打动，因为懂得，所以慈悲。
也许我们只能默默祝愿，每一个归家的人都能旅途平安。也让我们向坚强的女导游致敬。
Posted by eygle at 10:36 PM
| Comments (3)
作者:eygle
今早在访问Metalink时收到如图信息,Metalink暂时不可访问,Oracle声名在进行维护和系统升级.
自从Metalink改版以来,一直有很多关于使用上的抱怨,但是显然Oracle推动HTML DB的决心不会改变.
这次升级是因为HTML DB的稳定性问题还是其他呢?
Oracle有可能受到攻击么?Oracle可以被攻破么?也许这是一个更有意思的话题.
最近,Oracle发布了Critical的安全公告,所有用户被建议升级,也许Oracle自己也在开始升级吧.
不管怎样,还是第一次见到Metalink上To All Metalink users 的公告,立此存照.
顺便让我们观察一下,Oracle的一次维护Down机时间会有多久?
Posted by eygle at 1:18 PM
| Comments (0)
January 20, 2006
作者:eygle
早晨在车上的时候，听到收音机里说，2006年，也就是在即将来临的狗年，将会出现闰七月，而且还将是闰年中最长的一年，共有385天。
在元旦的时候，我们已经多了一秒，现在新的一年，我们又将多出一月，也就是说，我们有更多的时间可以浪费了。Sunny说，时间的浪费是正常的，否则这个世界就不得了了。那么，多一点总是好的吧。
而且据说，这种情况从公元前221年至公元2100年的2321年里，一共只有12次，上一次发生在1944年。那么这也是大多数人第一次经历385天的一年吧。
别以为闰一个月无关紧要，明年的新年可就要迟来一个月喽。而且在2006年内，我们将会经历2个"立春"的节气哦，这也是很奇特的经历吧。
再提示一下,据说这个"双春兼闰月"的2006年对于属蛇的人是12年来最好的一年.
科普知识:
我国农历，俗称阴历，其实它并非真正的阴历，而是兼备阴历与阳历之长的阴阳合历。
地球绕太阳一周为一回归年，其周期为365.2422天。回归年的长度带有小数部分，不便于实际纪年，故阳历将一年的总天数定为365天或366天（闰年）。24节气等分其中，节气与节气之间的间隔约半月，每个节气所在的日期也基本固定，如“立春”多在2月4日等。
农历以月亮绕地球一周为一个月，月的周期为29.5306天。为使月历不带小数，又能准确反映月亮绕地球运行的周期，特设“月小”、“月大”两种情况，月小为29天，月大为30天。这样一来，以十二个月为一年，全年就只有354天或355天，比阳历一年的天数少约 11天。
农历为顺应寒暑变化而与阳历保持一致，便采用了“19年7闰月”的方法，使每19年中有7年为13个月，从而使其岁首始终保持在立春前后。13个月包含383天或384天，比阳历1年的天数多约18天。18天已超过了一个节气的长度，故农历闰月年份会包含25个节气，即出现两次立春。2006年中的农历丙戌年，正是属于这种情况。
Posted by eygle at 12:03 PM
| Comments (6)
January 19, 2006
作者:eygle
Oracle10g引入ASM以来,关于ASM的担心就从来没有停止过.因为ASM引入了一个新的ASM Instance,新的实例的稳定性一度成为了关注的焦点.
我们看一下这个新的ASM实例引入的后台进程:
[oracle@danaly bdump]$ ps -ef|grep ASM|grep -v grep
oracle 3720 1 0 14:38 ? 00:00:00 asm_pmon_+ASM
oracle 3722 1 0 14:38 ? 00:00:00 asm_psp0_+ASM
oracle 3724 1 0 14:38 ? 00:00:00 asm_mman_+ASM
oracle 3726 1 0 14:38 ? 00:00:00 asm_dbw0_+ASM
oracle 3728 1 0 14:38 ? 00:00:00 asm_lgwr_+ASM
oracle 3730 1 0 14:38 ? 00:00:00 asm_ckpt_+ASM
oracle 3732 1 0 14:38 ? 00:00:00 asm_smon_+ASM
oracle 3734 1 0 14:38 ? 00:00:00 asm_rbal_+ASM
oracle 3736 1 0 14:38 ? 00:00:00 asm_gmon_+ASM
oracle 3748 1 0 14:38 ? 00:00:00 asm_o000_+ASM
oracle 3781 1 0 14:38 ? 00:00:00 oracle+ASM (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
|
这些进程和数据库的后台进程同样重要(甚至可以说更为重要),如果ASM实例Crash,数据库将会立刻中止.
今天这个10g的数据库就遇到了这样的问题.第一次，Oracle10gR2的ASM挂了。
检查数据库的alert文件，获得如下信息:
Thu Jan 19 13:34:11 2006
WARNING: inbound connection timed out (ORA-3136)
Thu Jan 19 13:52:47 2006
Errors in file /opt/oracle/admin/danaly/bdump/danaly_asmb_4154.trc:
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
Thu Jan 19 13:52:47 2006
ASMB: terminating instance due to error 15064
Instance terminated by ASMB, pid = 4154
|
看来是ASM实例出现问题,导致数据库down掉。
trace文件中记录了如下错误:
*** 2006-01-19 13:52:47.922
*** SERVICE NAME:(SYS$BACKGROUND) 2006-01-19 13:52:47.917
*** SESSION ID:(157.1) 2006-01-19 13:52:47.917
error 15064 detected in background process
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
|
毫无疑问，都是ASM惹的祸。
检查ASM的日志文件记录了如下错误，显示磁盘组故障导致ASM终止:
Thu Jan 19 13:52:47 2006
Errors in file /opt/oracle/admin/+ASM/bdump/+asm_gmon_3948.trc:
ORA-29702: error occurred in Cluster Group Service operation
ORA-29702: error occurred in Cluster Group Service operation
Thu Jan 19 13:52:47 2006
GMON: terminating instance due to error 29702
Instance terminated by GMON, pid = 3948
|
trace文件里记录了如下信息：
*** 2006-01-19 13:52:47.912
2006-01-19 13:52:47.912: [ CSSCLNT]clsssRecvMsg: comm error received,
comrc 11, con (0xcc9fb48), msg (0xbfffe5d8), msgl 144
2006-01-19 13:52:47.912: [ CSSCLNT]clssgsGroupGetStatus: clsssRecvMsg failed 3 -1073748296)
2006-01-19 13:52:47.912: [ CSSCLNT]clssgsGroupGetStatus: returning 8
kgxgnpstat: received ABORT event from CLSS
Group services Error [NM abort event ] @ 28019:719
error 29702 detected in background process
ORA-29702: error occurred in Cluster Group Service operation
ORA-29702: error occurred in Cluster Group Service operation
|
启动数据库，经过恢复，成功加载ASM磁盘组，随之数据库得以正常启动:
Thu Jan 19 14:38:16 2006
SQL> ALTER DISKGROUP ALL MOUNT
Thu Jan 19 14:38:16 2006
NOTE: cache registered group ORADG number=1 incarn=0x728b66fe
Thu Jan 19 14:38:16 2006
Loaded ASM Library - Generic Linux, version 2.0.0 (KABI_V2) library for asmlib interface
Thu Jan 19 14:38:16 2006
NOTE: Hbeat: instance first (grp 1)
Thu Jan 19 14:38:20 2006
NOTE: start heartbeating (grp 1)
NOTE: cache opening disk 0 of grp 1: VOL1 label:VOL1
Thu Jan 19 14:38:20 2006
NOTE: F1X0 found on disk 0 fcn 0.0
NOTE: cache opening disk 1 of grp 1: VOL2 label:VOL2
NOTE: cache opening disk 2 of grp 1: VOL3 label:VOL3
NOTE: cache opening disk 3 of grp 1: VOL4 label:VOL4
NOTE: cache mounting (first) group 1/0x728B66FE (ORADG)
NOTE: starting recovery of thread=1 ckpt=17.8535
NOTE: advancing ckpt for thread=1 ckpt=17.8535
NOTE: cache recovered group 1 to fcn 0.401368
Thu Jan 19 14:38:21 2006
NOTE: opening chunk 1 at fcn 0.401368 ABA
NOTE: seq=18 blk=8536
Thu Jan 19 14:38:21 2006
NOTE: cache mounting group 1/0x728B66FE (ORADG) succeeded
SUCCESS: diskgroup ORADG was mounted
Thu Jan 19 14:38:22 2006
NOTE: recovering COD for group 1/0x728b66fe (ORADG)
SUCCESS: completed COD recovery for group 1/0x728b66fe (ORADG)
Thu Jan 19 14:38:38 2006
Starting background process ASMB
ASMB started with pid=12, OS id=3744
|
我们注意到,日志中几次出现heartbeat字样,原来heartbeat无处不在.
顺便把数据库的恢复信息也记录一下:
Thu Jan 19 14:38:43 2006
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
WARNING: db_recovery_file_dest is same as db_create_file_dest
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.1.0.
System parameters with non-default values:
processes = 150
__shared_pool_size = 75497472
__large_pool_size = 4194304
__java_pool_size = 4194304
__streams_pool_size = 0
spfile = +ORADG/danaly/spfiledanaly.ora
sga_target = 943718400
control_files = +ORADG/danaly/controlfile/current.256.600173845,
+ORADG/danaly/controlfile/current.257.600173845
db_block_checksum = FULL
db_block_size = 8192
__db_cache_size = 851443712
compatible = 10.2.0.1.0
db_file_multiblock_read_count= 16
db_create_file_dest = +ORADG
db_recovery_file_dest = +ORADG
db_recovery_file_dest_size= 2147483648
undo_management = AUTO
undo_tablespace = UNDOTBS2
recyclebin = ON
remote_login_passwordfile= EXCLUSIVE
db_domain =
dispatchers = (PROTOCOL=TCP) (SERVICE=danalyXDB)
job_queue_processes = 10
background_dump_dest = /opt/oracle/admin/danaly/bdump
user_dump_dest = /opt/oracle/admin/danaly/udump
core_dump_dest = /opt/oracle/admin/danaly/cdump
audit_file_dest = /opt/oracle/admin/danaly/adump
db_name = danaly
open_cursors = 300
pga_aggregate_target = 314572800
PMON started with pid=2, OS id=3752
PSP0 started with pid=3, OS id=3754
MMAN started with pid=4, OS id=3756
DBW0 started with pid=5, OS id=3758
LGWR started with pid=6, OS id=3760
CKPT started with pid=7, OS id=3762
SMON started with pid=8, OS id=3764
RECO started with pid=9, OS id=3766
CJQ0 started with pid=10, OS id=3768
MMON started with pid=11, OS id=3770
Thu Jan 19 14:38:44 2006
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=12, OS id=3772
Thu Jan 19 14:38:44 2006
starting up 1 shared server(s) ...
Thu Jan 19 14:38:44 2006
ALTER DATABASE MOUNT
Thu Jan 19 14:38:44 2006
Starting background process ASMB
ASMB started with pid=16, OS id=3779
Starting background process RBAL
RBAL started with pid=17, OS id=3783
Loaded ASM Library - Generic Linux, version 2.0.0 (KABI_V2) library for asmlib interface
Thu Jan 19 14:38:52 2006
SUCCESS: diskgroup ORADG was mounted
Thu Jan 19 14:38:57 2006
Setting recovery target incarnation to 1
Thu Jan 19 14:38:57 2006
Successful mount of redo thread 1, with mount id 3945133236
Thu Jan 19 14:38:57 2006
Database mounted in Exclusive Mode
Completed: ALTER DATABASE MOUNT
Thu Jan 19 14:38:57 2006
ALTER DATABASE OPEN
Thu Jan 19 14:38:57 2006
Beginning crash recovery of 1 threads
parallel recovery started with 3 processes
Thu Jan 19 14:38:58 2006
Started redo scan
Thu Jan 19 14:38:58 2006
Completed redo scan
59 redo blocks read, 14 data blocks need recovery
Thu Jan 19 14:38:58 2006
Started redo application at
Thread 1: logseq 5834, block 72749
Thu Jan 19 14:38:58 2006
Recovery of Online Redo Log: Thread 1 Group 2 Seq 5834 Reading mem 0
Mem# 0 errs 0: +ORADG/danaly/onlinelog/group_2.260.600173851
Mem# 1 errs 0: +ORADG/danaly/onlinelog/group_2.261.600173853
Thu Jan 19 14:38:58 2006
Completed redo application
Thu Jan 19 14:38:59 2006
Completed crash recovery at
Thread 1: logseq 5834, block 72808, scn 16042818137
14 data blocks read, 14 data blocks written, 59 redo blocks read
Thu Jan 19 14:39:00 2006
Thread 1 advanced to log sequence 5835
Thread 1 opened at log sequence 5835
Current log# 3 seq# 5835 mem# 0: +ORADG/danaly/onlinelog/group_3.262.600173855
Current log# 3 seq# 5835 mem# 1: +ORADG/danaly/onlinelog/group_3.263.600173857
Successful open of redo thread 1
Thu Jan 19 14:39:00 2006
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Thu Jan 19 14:39:00 2006
SMON: enabling cache recovery
Thu Jan 19 14:39:01 2006
Successfully onlined Undo Tablespace 15.
Thu Jan 19 14:39:01 2006
SMON: enabling tx recovery
Thu Jan 19 14:39:01 2006
Database Characterset is ZHS16GBK
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=22, OS id=3796
Thu Jan 19 14:39:09 2006
db_recovery_file_dest_size of 2048 MB is 16.75% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Thu Jan 19 14:39:09 2006
Completed: ALTER DATABASE OPEN
|
这样的错误在Metalink上都被当做Bug处理,很难找到真正的原因,如果不能再现,就只能做为一次异常处理了.
Posted by eygle at 6:07 PM
| Comments (0)
作者:eygle
在Oracle中有一个事件叫Heartbeat，这个词在很多地方被提及，并且有着不同的含义(比如RAC中)，我们这里要讨论的是CKPT的Heartbeat机制。
Oracle通过CKPT进程每3秒将Heartbeat写入控制文件，以减少故障时的恢复时间(这个我们后面再详细阐述)。
我们可以通过如下方法验证这个过程。
1.首先在系统级启用10046时间跟踪
并重新启动数据库使之生效
[oracle@jumper oracle]$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.4.0 - Production on Thu Jan 19 09:24:04 2006
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production
SQL> alter system set event='10046 trace name context forever,level 12' scope=spfile;
System altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 114365800 bytes
Fixed Size 451944 bytes
Variable Size 50331648 bytes
Database Buffers 62914560 bytes
Redo Buffers 667648 bytes
Database mounted.
Database opened.
SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production
|
2.检查bdump目录下生成的跟踪文件
目录在$ORACLE_HOME/admin/$ORACLE_SID/bdump目录下，每个后台进程都会生成一个跟踪文件。
[oracle@jumper bdump]$ ls
20050424_alert_conner.log conner_arc0_2569.trc conner_dbw0_2559.trc conner_reco_2567.trc
alert_conner.log conner_arc1_2571.trc conner_lgwr_2561.trc conner_smon_2565.trc
a.sql conner_ckpt_2563.trc conner_pmon_2557.trc
|
3.检查CKPT进程的跟踪文件
我们可以很容易的发现CKPT进程每3秒都对控制文件进行一次写入
[oracle@jumper bdump]$ tail -f conner_ckpt_2563.trc
WAIT #0: nam='rdbms ipc message' ela= 2994710 p1=300 p2=0 p3=0
WAIT #0: nam='control file parallel write' ela= 2442 p1=3 p2=3 p3=3
WAIT #0: nam='rdbms ipc message' ela= 2995171 p1=300 p2=0 p3=0
WAIT #0: nam='control file parallel write' ela= 2586 p1=3 p2=3 p3=3
WAIT #0: nam='rdbms ipc message' ela= 2994962 p1=300 p2=0 p3=0
WAIT #0: nam='control file parallel write' ela= 2582 p1=3 p2=3 p3=3
WAIT #0: nam='rdbms ipc message' ela= 2995020 p1=300 p2=0 p3=0
WAIT #0: nam='control file parallel write' ela= 2455 p1=3 p2=3 p3=3
WAIT #0: nam='rdbms ipc message' ela= 2995188 p1=300 p2=0 p3=0
WAIT #0: nam='control file parallel write' ela= 2412 p1=3 p2=3 p3=3
WAIT #0: nam='rdbms ipc message' ela= 2995187 p1=300 p2=0 p3=0
WAIT #0: nam='control file parallel write' ela= 2463 p1=3 p2=3 p3=3
WAIT #0: nam='rdbms ipc message' ela= 2995095 p1=300 p2=0 p3=0
WAIT #0: nam='control file parallel write' ela= 2448 p1=3 p2=3 p3=3
|
4.检查控制文件的变更
通过2次dump控制文件，比较其trace文件输出可以比较得到不同之处，我们发现，Oracle仅仅更新了Heartbeat这个数值。
[oracle@jumper udump]$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.4.0 - Production on Wed Jan 18 22:44:10 2006
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production
SQL> alter session set events 'immediate trace name CONTROLF level 10';
Session altered.
SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production
[oracle@jumper udump]$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.4.0 - Production on Wed Jan 18 22:44:18 2006
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production
SQL> alter session set events 'immediate trace name CONTROLF level 10' ;
Session altered.
SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production
[oracle@jumper udump]$ ls
conner_ora_21896.trc conner_ora_21898.trc
[oracle@jumper udump]$ diff conner_ora_21896.trc conner_ora_21898.trc
1c1
< /opt/oracle/admin/conner/udump/conner_ora_21896.trc
---
> /opt/oracle/admin/conner/udump/conner_ora_21898.trc
14c14
< Unix process pid: 21896, image: oracle@jumper.hurray.com.cn (TNS V1-V3)
---
> Unix process pid: 21898, image: oracle@jumper.hurray.com.cn (TNS V1-V3)
16c16
< *** SESSION ID9.813) 2006-01-18 22:44:14.314
---
> *** SESSION ID9.815) 2006-01-18 22:44:21.569
63c63
< heartbeat: 579991793 mount id: 3191936000
---
> heartbeat: 579991796 mount id: 3191936000
[oracle@jumper udump]$
|
Steve曾经这样描述CKPT Heartbeat:
In 8.0.5 a heartbeat mechanism was included in CKPT's timeout action (every 3 seconds) to update the checkpoint progress record for the thread in the controlfile.
Posted by eygle at 12:36 PM
| Comments (0)
January 18, 2006
作者:eygle
自从安装了MT Scode 1插件以后，Spam评论基本上被成功遏制了，但是spam trackback仍然不断，有时候每天来自各个站点的垃圾trackback达数百条。
最近在删除的时候,偶尔认真阅读一下这些trackback,即便是作恶者也有值得学习之处吧.
我向spam学习英文，以下是我学习的一些句子，以后可以用来往别人的网站上贴了：）
1.Very nice site. Please keep updating it.
如果是说真的,我应该说谢谢!我会坚持更新的。
2.awesome stuff! thanks for all the information.
从这句学到了awesome这个词。awesome adj.引起敬畏的, 可怕的
3.Very original content. I really like your site.
嘿嘿，我的站点是以原创文章为主哦！
4.You're site is very helpful.
如果我的站点能够帮助别人，我是很开心的。
5.Interesting site, and very organized too. Good work.
Organized,我一直为这个目标而努力的。
6.Your site is exactly the kind of sites which make the net surfing so fun.
这句的语法结构很典型!
[本文英文版]
7.i really appreciate what you're doing here. very interesting site.
8.you have a very talented and skilled writting. i had a great time reading your comments.
9.It's the first time i ran through your site and I found it very informative and interesting.
"Informative and interesting"
10.Hi. Just letting you know that I enjoyed your site.
11.brilliant site! happy to be here.
I'm happy too.
12.It was fun visiting here. Wishing you a great day!
I wish everyone have had a great day.
13.It's been a long time since I so enjoyed reading posts in the net. Two thumbs up!
Two thumbs up!
Posted by eygle at 4:07 PM
| Comments (3)
