Oracle Life: August 2006 Archives

作者:eygle

出处:http://blog.eygle.com

昨天，在北京，看到了难得一见的彩虹，而且还是两道彩虹。
跑到家，和Julia一起爬上屋顶，拍下了很多美丽的图片，以下是其中之一:

也许在北京的人，也有许多看不到的。

Posted by eygle at 1:53 PM | Comments (10) | TrackBack

August 14, 2006

作者:eygle

出处:http://blog.eygle.com

首届杰出数据库工程师评选活动的终选在上个周末已经完成。活动倒也中规中矩，只不过略显仓促，在规则并未明确之前，各个选手是各自发挥，随意阐述，真不知道评委怎么根据各不相同的发挥来作出评判。

大早出门时给biti打电话，他和汪海两个自费坐火车来北京参赛，据说组委会帮忙安排了一天的住宿，他们先去了住所。

中午组委会还准备了午餐，我私下问了一声：能带家属去么?
组委会说：不行。

于是几个朋友一起小聚了一餐，出席的朋友有:

biti，汪海，冯昕+果果+果果爸爸，牛新庄，我+Julia

大家相谈甚欢，吃了一顿开开心心的午餐，争夺了一番，最后是果果爸爸买了单，感谢冯昕，感谢果果，感谢果果爸爸：）

新庄之前曾经见过一面，感觉颇为投缘，这次又有机会见面，实为不易：）

晚餐在住处附近，出席的朋友有：

biti，汪海，叶梁，Kamus，桔子，Julia+Me

小聚一场。

期待8月23日，最终结果日，Biti和汪海又可以自费来一趟：）

Posted by eygle at 11:38 AM | Comments (8) | TrackBack

August 11, 2006

作者:eygle

出处:http://blog.eygle.com

首届杰出数据库工程师评选终选即将于明后天举行，时间表也已经排出:

面试活动流程：

面试环节流程
环节顺次	内容安排	时间安排
第一环节	工程师依次进行主题发言	3分钟
第二环节	工程师依次回答提问	7分钟
第三环节	就主办方提交话题现场互动讨论	30分钟
第四环节	专家点评	5分钟

专家与工程师时间安排：

面试时间安排
时间	8月12日 8:30-10:00	8月12日 10:10-11:40	8月12日 13:30-15:00	8月12日 15:10-16:40	8月13日 8:30-10:00	8月13日 10:10-11:40
面试工程师	邢海捷	王晓刚	庞恒志（大连）	段云峰	牛新庄	丁思非
	万正勇	冯昕	冯春培（杭州）	王忠海	甘荃	王翔
	胡波	盖国强	张黎敏（上海）	董国兴	王作敬	常红平
	倪泳智	袁春光	汪海（杭州）	朱健彦（苏州）	王明胜	齐红胤
	王涛（加拿大）	王宏志（哈尔滨）	李强（深圳）	胡晶玉（上海）	邹建（成都）	钱彦云（兰州）

评审专家	陈冲	陈冲	施伯乐	施伯乐	王珊	王珊
	周立柱	周立柱	冯玉才	冯玉才	罗晓沛	罗晓沛
	周龙骧	周龙骧	乐嘉锦	乐嘉锦	唐世渭	唐世渭
备注	以上专家、工程师安排可能会因为各种情况做微幅调整，组委会将及时通知。

专家评审团很是鼎盛，期待明天！

Posted by eygle at 3:23 PM | Comments (26) | TrackBack

作者:eygle

出处:http://blog.eygle.com

昨天发现Google的Web Clips终于开始支持自添加Rss了，虽然此前Web Clips已经推出很久，但是除了预设置栏目外，Google不支持自搜索添加的Rss。

现在终于可以了，Gmail的这一功能真正开始变得有用起来:

在搜索栏里搜索出来的Rss就可以添加进入Web Clips。

Posted by eygle at 2:06 PM | Comments (0) | TrackBack

作者:eygle

出处:http://blog.eygle.com

继续上一节的介绍：

我们可以想象，如果控制文件是从备份中恢复的，那么数据库在open过程中又将如何呢?

首先备份控制文件，打开数据库，增进检查点:

[oracle@jumper eygle]$ cp control01.ctl control01.ctl.bak
[oracle@jumper eygle]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Fri Aug 11 10:46:05 2006

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 139531744 bytes
Fixed Size                   452064 bytes
Variable Size             121634816 bytes
Database Buffers           16777216 bytes
Redo Buffers                 667648 bytes
Database mounted.
Database opened.
SQL> alter system checkpoint;

System altered.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
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

然后恢复旧的控制文件，mount数据库，转储数据文件头:

[oracle@jumper eygle]$ mv control01.ctl control01.ctl.n
[oracle@jumper eygle]$ mv control01.ctl.bak control01.ctl
[oracle@jumper eygle]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Fri Aug 11 10:46:50 2006

Connected to an idle instance.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 139531744 bytes
Fixed Size                   452064 bytes
Variable Size             121634816 bytes
Database Buffers           16777216 bytes
Redo Buffers                 667648 bytes
Database mounted.
SQL> alter session set events 'immediate trace name file_hdrs level 10';

Session altered.

SQL> !

我们看控制文件的信息（选择一个文件）:

再看数据文件头信息:

FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=989=0x3dd, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/11/2006 10:11:26
status:0x0 root dba:0x00000000 chkpt cnt: 64 ctl cnt:63
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.002acb98 08/11/2006 10:46:24

我们注意到数据文件的chkpt cnt: 64 要大约控制文件的Checkpoint cnt:61，也就是说控制文件是旧的。

此时尝试打开数据库就会出现如下错误:

[oracle@jumper udump]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Fri Aug 11 10:51:20 2006

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 database open;
alter database open
*
ERROR at line 1:
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/opt/oracle/oradata/eygle/system01.dbf'
ORA-01207: file is more recent than controlfile - old controlfile

Oracle告诉我们，控制文件是旧的。此时我们可以通过重建控制文件或者从旧的数据备份开始恢复。

未完待续...

Posted by eygle at 11:05 AM | Comments (14) | TrackBack

关于控制文件与数据文件头信息的说明

作者:eygle

出处:http://blog.eygle.com

为了回答关于《深入浅出Oracle》中的一些疑问，引出本系列文章，讨论链接参考:

http://www.itpub.net/609499.html

在上一讲中，我们说过：当我们使用file_hdrs事件来转储数据文件头信息时，Oracle会转储两部分信息，一部分来自控制文件，一部分来自数据文件，在数据库启动过程中，这两部分信息要用来进行启动验证。

在数据库open的过程中,Oracle要进行检查中包含以下两个过程:

第一次检查数据文件头中的Checkpoint cnt是否与对应控制文件中的Checkpoint cnt一致.
如果相等,进行第二次检查.

第二次检查数据文件头的开始SCN和对应控制文件中的结束SCN是否一致如果结束SCN等于开始SCN,则不需要对那个文件进行恢复.

对每个数据文件都完成检查后,打开数据库.同时将每个数据文件的结束SCN设置为无穷大.

通过以下过程我们来进一步说明一下这个内容。

我们来看以下来自控制文件部分(选取一个文件测试):

这部分中包含的重要信息有:
检查点计数: Checkpoint cnt:58
检查点SCN: scn: 0x0000.002ac8ee 08/11/2006 09:48:29
数据文件Stop SCN:Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29

我们再看来自数据文件头的信息:

FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=979=0x3d3, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/10/2006 20:57:53
status:0x0 root dba:0x00000000 chkpt cnt: 58 ctl cnt:57
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.002ac8ee 08/11/2006 09:48:29
.......................

这部分中包含的重要信息有:
检查点SCN: Checkpointed at scn: 0x0000.002ac8ee 08/11/2006 09:48:29
检查点计数: chkpt cnt: 58 ctl cnt:57

这两者都和控制文件中所记录的一致。如果这两者一致，数据库启动时就能通过验证，启动数据库。

那么如果不一致呢？
Oracle则请求进行恢复。
我们看，从备份中恢复eygle01.dbf文件.
首先第一部分从控制文件中获得的信息是相同的:

检查点计数: Checkpoint cnt:58
检查点SCN: scn: 0x0000.002ac8ee 08/11/2006 09:48:29
数据文件Stop SCN:Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29

而从文件头中获得的备份文件信息则是：

FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=973=0x3cd, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/10/2006 20:57:53
status:0x0 root dba:0x00000000 chkpt cnt: 53 ctl cnt:52
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.002ac5f9 08/10/2006 20:58:21
...................................

我们看到此时备份文件的信息：
检查点是：Checkpointed at scn: 0x0000.002ac5f9 08/10/2006 20:58:21
检查点计数为:chkpt cnt: 53 ctl cnt:52

这两者不再一致，首先是检查点技术不一致，当前文件的chkpt cnt为53，小于控制文件中记录的58，Oracle可以判断文件是从备份中恢复的，或者文件故障，需要进行介质恢复。

我们看如果此时我们试图打开数据库，则Oracle提示文件需要介质恢复:

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: '/opt/oracle/oradata/eygle/eygle01.dbf'

执行恢复:

SQL> recover datafile 4;
Media recovery complete.

我们看看恢复完成之后，控制文件和数据文件的变化.
首先看控制文件的变化:

检查点计数: Checkpoint cnt:59
执行了恢复之后，检查点计数较前增加了1

检查点SCN: scn: 0x0000.002ac8ee 08/11/2006 09:48:29
数据文件Stop scn: 0x0000.002ac8ed 08/11/2006 09:48:29
数据文件Stop scn和数据文件进行了同步。

数据文件头信息:

FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=983=0x3d7, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/11/2006 10:11:26
status:0x0 root dba:0x00000000 chkpt cnt: 59 ctl cnt:58
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.002ac8ed 08/11/2006 09:48:29
..........................

我们看到此时数据文件的信息：
检查点是：Checkpointed at scn: 0x0000.002ac8ed 08/11/2006 09:48:29
这个检查点和控制文件中记录的stop scn一致，数据库启动可以顺利进行。

检查点计数为:chkpt cnt: 59 ctl cnt:58

我们打开数据库:

SQL> alter database open;

Database altered.

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

Session altered.

此时数据库恢复正常运行。
控制文件信息如下：

此时stop scn被置为无穷大。
数据文件头信息如下:

FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=984=0x3d8, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/11/2006 10:11:26
status:0x4 root dba:0x00000000 chkpt cnt: 60 ctl cnt:59
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.002ac8ef 08/11/2006 10:19:30

未完待续...

Posted by eygle at 10:01 AM | Comments (4) | TrackBack

江湖传闻-Blogspot再次解封

作者:eygle

出处:http://blog.eygle.com

为什么说“再”呢?因为之前blogspot也有过短暂的解封记录，不知道这一次能持续多久呢?

blogspot解封的一个直接收益是，我们可以直接访问Tom的Blog了：）

http://tkyte.blogspot.com/

但愿这一次是真的开放！

Posted by eygle at 9:22 AM | Comments (0) | TrackBack

August 10, 2006

EVENT: FILE_HDRS 的信息来源

作者:eygle

出处:http://blog.eygle.com

准备用几篇稿子来记录一下ITPUB上关于数据库Open的一个问题。
具体问题参考ITPUB链接:
http://www.itpub.net/609499.html

我们知道，可以通过一个内部事件来转储数据文件头信息，这个常用的命令是：

alter session set events 'immediate trace name file_hdrs level 10';

那么我们来看一下这个命令得到的trace文件及内容。
immediate关闭数据库，在mount状态下执行该命令:

SQL> startup mount;
ORACLE instance started.

Session altered.

选取一个文件的信息,这里选择eygle01.dbf文件，我们注意，以下就是trace文件摘录的信息:

DATA FILE #4:
(name #4) /opt/oracle/oradata/eygle/eygle01.dbf
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 4, index=4 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:53 scn: 0x0000.002ac5f9 08/10/2006 20:58:21
Stop scn: 0x0000.002ac5f9 08/10/2006 20:58:21
Creation Checkpointed at scn: 0x0000.0015078d 06/06/2006 09:41:54
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=973=0x3cd, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/10/2006 20:57:53
status:0x0 root dba:0x00000000 chkpt cnt: 53 ctl cnt:52
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.002ac5f9 08/10/2006 20:58:21
thread:1 rba:(0x35.1275.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Backup Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
External cache id: 0x0 0x0 0x0 0x0
Absolute fuzzy scn: 0x0000.00000000
Recovery fuzzy scn: 0x0000.00000000 08/10/2006 10:46:03
Terminal Recovery Stamp scn: 0x0000.00000000 01/01/1988 00:00:00

注意，这其中"FILE HEADER"开始的信息就是来自数据文件头，之前的相关内容来自控制文件。

我们可以在mount状态下将eygle01.dbf文件移除:

[oracle@jumper eygle]$ mv eygle01.dbf eygle01.dbf.n
[oracle@jumper eygle]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Thu Aug 10 21:44:10 2006

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 file_hdrs level 10';

Session altered.

SQL> !

则"FILE HEADER"部分信息将无法获得。

此时报出的错误是，文件无法找到，也就是说当我们执行trace file_hdrs时需要读取数据文件头，获得相关信息。

Posted by eygle at 9:59 PM | Comments (1) | TrackBack

August 9, 2006

《深入浅出Oracle》登上排行榜前三甲

作者:eygle

出处:http://blog.eygle.com

感谢大家的支持，《深入浅出Oracle》一书在China-Pub的计算机类本月销售排行榜上，攀升到第3位，留图为念：

再次感谢大家对于本书的支持。

本书与7.22上市，在上个月的Oracle类中排于第一位，这个月算是进了一步。

Posted by eygle at 9:44 PM | Comments (7) | TrackBack

Oracle的TNS-12502 错误原因及解决

作者:eygle

出处:http://blog.eygle.com

前几天收到一位读者朋友的来信，询问以下问题：

在我的监听日志中出现错误TNS-12502: TNS:listener received no CONNECT_DATA from client
经过查找资料了解到这种错误应该是客户端tnsnames.ora中没有写 CONNECT_DATA的原因，我检查过客户端的机器没有发现问题。
目前的现象：
1、每几分钟出现一次该错误（见附件），即使是在凌晨的时候也是，这段时间我们没有开发人员在凌晨时候使用Oracle。
2、到目前为止也没有发现客户端机器不能正常连接数据库的情况。

今天才有时间研究一下，对于TNS-12502错误，Oracle的解释如下：

Error: ORA-12502 / TNS-12502
Text: TNS:listener received no CONNECT_DATA from client
---------------------------------------------------------------------------
Cause: No CONNECT_DATA was passed to the listener.
Action: Check that the service name resolved from TNSNAMES.ORA has the
CONNECT_DATA component of the connect descriptor.

也就是说只有在TNSNAMES.ORA文件中不包含CONNECT_DATA时会出现此问题。

那么当通过一些网络工具或HA工具等检测监听器端口时，日志中就可能记录如上错误。我们可以简单模拟一下，在客户端通过telnet数据库服务器的1521端口测试连通性：

C:\>telnet 172.16.30.11 1521

此时在日志中就会记录如下信息：

TNS-12502: TNS:listener received no CONNECT_DATA from client
09-AUG-2006 16:21:03 * 12502
TNS-12502: TNS:listener received no CONNECT_DATA from client
09-AUG-2006 16:21:13 * 12502
TNS-12502: TNS:listener received no CONNECT_DATA from client
09-AUG-2006 16:21:22 * 12502
TNS-12502: TNS:listener received no CONNECT_DATA from client

如果客户端都正常的话，此类错误并不会影响应用，当然也可以彻底检查找出根本原因。

Posted by eygle at 4:37 PM | Comments (2) | TrackBack

www.eygle.com

在北京见到彩虹

作者:eygle

出处:http://blog.eygle.com

August 14, 2006

首届杰出数据库工程师评选终选记行

作者:eygle

出处:http://blog.eygle.com

August 11, 2006

首届杰出数据库工程师评选终选时间表

作者:eygle

出处:http://blog.eygle.com

Google的Web Clips终于支持自添加RSS

作者:eygle

出处:http://blog.eygle.com

备份的控制文件和新的数据文件

作者:eygle

出处:http://blog.eygle.com

关于控制文件与数据文件头信息的说明

作者:eygle

出处:http://blog.eygle.com

江湖传闻-Blogspot再次解封

作者:eygle

出处:http://blog.eygle.com

August 10, 2006

EVENT: FILE_HDRS 的信息来源

作者:eygle

出处:http://blog.eygle.com

August 9, 2006

《深入浅出Oracle》登上排行榜前三甲

作者:eygle

出处:http://blog.eygle.com

Oracle的TNS-12502 错误原因及解决

作者:eygle

出处:http://blog.eygle.com