Oracle Life: April 2007 Archives

April 3, 2007

CSDN英雄会与《深入浅出Oracle》

作者:eygle

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

这周五，CSDN将举办“技术英雄会”，这个活动据说已经邀请到了众多成名人物，届时将前往学习。

人民邮电出版社顺便会在当前搞一个签名送书活动，注意，是送书活动：），《深入浅出Oracle》这本书，现场将会送出60本。

同时邹建、孟宪会也会分别送出60本《中文版SQL Server 2000开发与管理应用实例》与《ASP.NET 2.0 应用开发技术》，不知道我能不能领两本回来，嘿嘿。

有朋友去参加这个活动么？

-The End-

Posted by eygle at 10:59 AM | Comments (9)

April 2, 2007

EMC-我的硬盘可以继续坏

作者:eygle

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

今早一打开信箱，又收到了EMC的报警邮件：

Time Stamp 04/02/07 09:32:00 Event Number 803
Severity Warning Host cx500spa
Storage Array CK200041200044 SPA Device Enclosure 2 Disk 10
Description Recommend Disk Replacement

再次推荐更换硬盘，好吧，我算怕了EMC，再打电话，再换硬盘。

Time Stamp 04/02/07 12:28:37 Event Number 2580
Severity Error Host cx500spb
Storage Array CK200041200044 SP N/A Device N/A
Description Storage Array Faulted Bus 0 Enclosure 2 : Faulted Bus 0 Enclosure 2 Disk 10 : Removed

我要看看下一次还坏哪一块?

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

library cache pin与PROCEDURE的重建

作者:eygle

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

前面提到，Oracle10g重建Procedure的处理有所增强，最初看到这个增强的时候，我想这个增强是否可以减少困扰已久的Library Cache的竞争呢？

我们看一下以下测试，首先在第一个session执行操作：

SQL> create or replace PROCEDURE pining
2 IS
3 BEGIN
4 NULL;
5 END;
6 /

Procedure created.

SQL>
SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

Session altered.

SQL> create or replace procedure calling
2 is
3 begin
4 pining;
5 dbms_lock.sleep(60);
6 end;
7 /

Procedure created.

SQL>
SQL> col object_name for a30
SQL> select object_name,last_ddl_time from dba_objects where object_name in ('PINING','CALLING');

OBJECT_NAME LAST_DDL_TIME
------------------------------ -------------------
CALLING 2007-04-02 09:12:57
PINING 2007-04-02 09:12:57

SQL>
SQL> exec calling;

此时Calling对于Pining的引用将会在Pining的Body上获得共享Pin，此时在另外一个Session执行重建Procedure的操作：

SQL> create or replace PROCEDURE pining
2 IS
3 BEGIN
4 NULL;
5 END;
6 /

这个操作将一直挂起，直到第一个session的操作完成，此时在第三个session可以观察到Library Cache Pin的竞争：

SQL> select sid,event from v$session where username='EYGLE'
2 /

SID EVENT
---------- ----------------------------------------------------------------
137 library cache pin
139 PL/SQL lock timer
157 SQL*Net message to client

当第一个session执行完成之后，第二个session的操作随之完成，我们可以看到LAST_DDL_TIME并未改变：

SQL> exec calling;
PL/SQL procedure successfully completed.

SQL>
SQL> select object_name,last_ddl_time from dba_objects where object_name in ('PINING','CALLING');

OBJECT_NAME LAST_DDL_TIME
------------------------------ -------------------
CALLING 2007-04-02 09:12:57
PINING 2007-04-02 09:12:57

实际上session 2执行了一次无谓的Library Cache Pin，理想的方式应该是，Oracle能够判断之前的Library Cache Pin的模式，如果是共享模式，则可以跳过Pin请求，如果是排他模式，则必须等待，目前的处理并不能从实质上改变竞争。

不过并非全无益处，我们发现，对于另一类DDL操作，Oracle完全可以跳过Library Cache Pin的请求，这类操作是Grant，在以前版本中的行为可以参考：
http://www.eygle.com/archives/2004/10/shared_pool-5.html

在Oracle10g中，Grant授权操作无需再获得Library Cache Pin的排他锁，我们看以下测试：
在Session 1中执行：

09:40:18 SQL> drop procedure calling;

Procedure dropped.

09:40:18 SQL>
09:40:18 SQL> drop procedure pining;

Procedure dropped.

09:40:18 SQL>
09:40:18 SQL> create or replace PROCEDURE pining
09:40:18 2 IS
09:40:18 3 BEGIN
09:40:18 4 NULL;
09:40:18 5 END;
09:40:18 6 /

Procedure created.

09:40:18 SQL>
09:40:18 SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

Session altered.

09:40:18 SQL> create or replace procedure calling
09:40:18 2 is
09:40:18 3 begin
09:40:18 4 pining;
09:40:18 5 dbms_lock.sleep(60);
09:40:18 6 end;
09:40:18 7 /

Procedure created.

09:40:18 SQL>
09:40:18 SQL> col object_name for a30
09:40:18 SQL> select object_name,last_ddl_time from dba_objects where object_name in ('PINING','CALLING');

OBJECT_NAME LAST_DDL_TIME
------------------------------ -------------------
CALLING 2007-04-02 09:40:18
PINING 2007-04-02 09:40:18

09:40:18 SQL>
09:40:18 SQL> exec calling;

在Session 2执行授权：

SQL> set time on
09:40:22 SQL> grant execute on pining to sys;

Grant succeeded.

09:40:22 SQL>

我们看到Session 2的授权顺利通过，再转到Session 1：

09:40:18 SQL> exec calling;

PL/SQL procedure successfully completed.

09:41:18 SQL>
09:41:18 SQL> select object_name,last_ddl_time from dba_objects where object_name in ('PINING','CALLING');

OBJECT_NAME LAST_DDL_TIME
------------------------------ -------------------
CALLING 2007-04-02 09:40:18
PINING 2007-04-02 09:40:22

我们看到对象PINING的LAST_DDL_TIME已经变化。
看来Grant已经能够绕过了Library Cache Pin的竞争，这是Oracle10g的增强。

这个问题最早由网友dqpylf在阅读我的新书《深入浅出Oracle》，在不同版本中测试案例时发现，今天才有时间做一点探究，感谢dqpylf。

-The End-

Posted by eygle at 9:42 AM | Comments (6)

Oracle10g中过程(PROCEDURE )重建的增强

作者:eygle

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

dcba上周有了一个新的发现，在Oracle10g中，当重建一个存储过程时，Oracle的行为和以前有所不同。

在Oracle9i中，即使一个完全相同的过程的重建，Oracle也需要重新编译过程，这个可以从LAST_DDL_TIME看出：

[oracle@jumper oracle]$ sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Sat Mar 31 17:52:55 2007

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> create or replace PROCEDURE pining
2 IS
3 BEGIN
4 NULL;
5 END;
6 /

Procedure created.

SQL> select object_name,last_ddl_time from dba_objects where object_name='PINING';

OBJECT_NAME LAST_DDL_TIME
------------------------------ -------------------
PINING 2007-03-31 17:52:58

SQL> create or replace PROCEDURE pining
2 IS
3 BEGIN
4 NULL;
5 END;
6 /

Procedure created.

SQL> select object_name,last_ddl_time from dba_objects where object_name='PINING';

OBJECT_NAME LAST_DDL_TIME
------------------------------ -------------------
PINING 2007-03-31 17:54:35

在Oracle10g中，这个LAST_DDL_TIME不再变化，这说明在10g中，当我们执行create or replace PROCEDURE 时，Oracle现在先尝试进行过程检查，如果内容没有变化，则不需要对过程进行重新编译，这可以减少Cache中的Invalidation，从而可以减少竞争：

$ sqlplus eygle/eygle

SQL*Plus: Release 10.2.0.1.0 - Production on Sat Mar 31 17:44:46 2007

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> create or replace PROCEDURE pining
2 IS
3 BEGIN
4 NULL;
5 END;
6 /

Procedure created.

SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

Session altered.

SQL> col object_name for a30
SQL> select object_name,last_ddl_time from dba_objects where object_name='PINING';

OBJECT_NAME LAST_DDL_TIME
------------------------------ -------------------
PINING 2007-03-31 17:45:25

SQL> create or replace PROCEDURE pining
2 IS
3 BEGIN
4 NULL;
5 END;
6 /

Procedure created.

SQL> select object_name,last_ddl_time from dba_objects where object_name='PINING';

OBJECT_NAME LAST_DDL_TIME
------------------------------ -------------------
PINING 2007-03-31 17:45:25

然而这个变化是否有效呢？请看我接下来的另外一个测试...

-to be continued ....

Posted by eygle at 9:23 AM | Comments (4)

April 1, 2007

进京四周年记

作者:eygle

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

今天，是我到北京的四周年纪念日，一年，两年，时间从未停息。

四年前那个料峭春寒的日子，我从昆明飞抵北京，开始了在北京的漂泊生涯；四年之后的今天，北京是樱花开放的季节，天气转暖，风沙初起....渐渐的已经熟悉和适应了北京的生活。
现在有了自己的家庭，不再是一个人，生活开始不同，慢慢的开始体验家的感觉，感谢Julia给我带来的改变。

昨天给以前的一个朋友电话，很久没有联系，问了一堆的别后人生，才发现昨日好友现在已经散落天涯，也许相聚不再容易，然而那深厚情谊从未改变，彼此话语依然熟悉。

期待一种可以随意走动的生活，可以经常和朋友相聚，和家人分享，希望离那一天可以越来越近。

今天，挂出了一章收藏的牡丹图，庆祝一下这个改变的日子：

....

Posted by eygle at 7:55 PM | Comments (11)

EMC-有多少硬盘可以再坏?

作者:eygle

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

昨晚，在具体故障尚未定位的情况下，EMC的硬盘坏了2块。

首先是一块RAID 5的硬盘坏了一块，然后一块Hot Spare硬盘顶上。

# navicli -h 172.16.9.5 getdisk 0_0_14
Bus 0 Enclosure 0 Disk 14
Vendor Id: SEAGATE
Product Id: ST373307 CLAR72
Product Revision: 7A10
Lun: 101
Type: 101: Hot Spare
State: Enabled
Hot Spare: 101: YES
Hot Spare Replacing: 0_1_8
Prct Rebuilt: 101: 100
Prct Bound: 101: 100
Serial Number: 3HZ9E674
Sectors: 139681792 (68204)
Capacity: 68238
Private: 101: 69704
Bind Signature: 0x80bd, 0, 14
Hard Read Errors: 0
Hard Write Errors: 0
Soft Read Errors: 6
Soft Write Errors: 6
Read Retries: N/A
Write Retries: N/A
Remapped Sectors: N/A
Number of Reads: 20816685
Number of Writes: 4047067
Number of Luns: 1
Raid Group ID: 101
Clariion Part Number: DG118032459
Request Service Time: N/A
Read Requests: 20816685
Write Requests: 4047067
Kbytes Read: 970975457
Kbytes Written: 105995802
Stripe Boundary Crossing: 0

未几，Hot Spare盘又挂掉了，然后数据开始向原来坏掉的硬盘Equalizing。
这个Equalizing能否正确完成显然是个未知数:

bash-2.03# navicli -h 172.16.9.5 getdisk 0_1_8
Bus 0 Enclosure 1 Disk 8
Vendor Id: SEAGATE
Product Id: ST314680 CLAR72
Product Revision: 7A0A
Lun: 14 15
Type: 14: RAID5 15: RAID5
State: Equalizing
Hot Spare: 14: NO 15: NO
Prct Rebuilt: 14: 100 15: 100
Prct Bound: 14: 100 15: 100
Serial Number: 3HY6RV4L
Sectors: 104857600 (51200)
Capacity: 68238
Private: 14: 69704 15: 104927304
Bind Signature: 0xc3de, 1, 8
Hard Read Errors: 0
Hard Write Errors: 0
Soft Read Errors: 0
Soft Write Errors: 0
Read Retries: N/A
Write Retries: N/A
Remapped Sectors: N/A
Number of Reads: 3922772
Number of Writes: 6092245
Number of Luns: 2
Raid Group ID: 9
Clariion Part Number: DG118032458
Request Service Time: N/A
Read Requests: 3922772
Write Requests: 6092245
Kbytes Read: 472965617
Kbytes Written: 403726059
Stripe Boundary Crossing: 392467

马上Call EMC，喊人连夜换掉了两块硬盘。

坏掉的硬盘和并不属于前几日故障LUN，但是同在一个Storage Group之中，与先前的故障应该没有直接的关联。
目前发现一台主机的PowerPath存在问题，这个问题导致一路光纤通道出现问题，这个故障导致部分LUN的Trespass。

-The End-

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