DBA Story (dba on unix/linux) - Oracle 11g新特性—

作者：piner (转载请注明本文出处：Ixdba.com)

我们先看一个具体的例子

会话1，创建一个简单表，并在上面创建一个存储过程：

11gR1 Piner>create table test (a int);
Table created.
11gR1 Piner>create or replace procedure sp_test
2 as
3 num number;
4 begin
5 select count(*) into num from test;
6 end;
7 /
11gR1 Piner>select object_name,status from user_objects where object_name='SP_TEST';
OBJECT_NAME STATUS
------------------------------ -------
SP_TEST VALID

同样的会话，我们插入一条记录，查看锁状态：

可以看到，这里对比以前的版本，多了一个类型为AE的锁。

然后，我们在另外一个会话做另外的操作

会话2：增加列

SQL> alter table test add b int;
Table altered.
SQL> alter table test drop column b;
alter table test drop column b
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired
11gR1 Piner>select object_name,status from user_objects where object_name='SP_TEST';
OBJECT_NAME STATUS
------------------------------ -------
SP_TEST VALID

可以看到，列增加成功，并没有任何阻塞，但是，drop列是阻塞的。是因为add新列并不影响正在执行的dml，但是drop老列却是可能影响到正在执行的DML的。

也可以看到，增加列的过程完成以后，存储过程并不失效。这个是很好的一个特性，只要不让存储过程错误，就不会使得存储过程INVALID，减少了DDL引发的library cache pin可能导致的系统异常。

我们另外看看oracle 11g的一个ddl timeout参数，在会话2上修改此参数，并重新执行刚才的drop列的命令。

这里的ddl_lock_timeout表示ddl会等待设置的值（单位为秒），这个是很有用的，比如在一个更新很频繁的表上面，适当的等待可以让ddl执行成功，以前dcba专门写了一个循环来模拟这个等待，现在，终于有这个参数了。

可以看到，正好等待10s左右

现在，会话1，我们提交该事务

会话2，drop终于可以成功了

我们再查看存储过程的状态

11gR1 Piner>select object_name,status from user_objects where object_name='SP_TEST';
OBJECT_NAME STATUS
------------------------------ -------
SP_TEST VALID

整个简单测试到此完成，大家看到了几处跟以前10g不一样的地方？可以看到的是，oracle在一些细节的地方，处理的越来越好了。