关于library cache lock/pin原理，eygle老大的文章已经讲得很深入了，详见：
关于shared pool的深入探讨(五)

我这里借一次批量授权的机会，通过dba_ddl_locks视图观察library cache lock/pin等待对象的变化。(对数据库名、用户名、表名做了更改)

从10G开始引入了FAST DUAL的概念，一些通过dual表计算，如select 1 from dual; select sysdate from dual; 已经不再需要访问data block了：

打CPU补丁6394981时遇到了以下错误：

Is the local system ready for patching? [y|n]
y
User Responded with: Y
正在备份受补丁程序 ‘NApply’ 影响的文件以用于恢复。此操作将需要一些时间…

This version of OPatch is obsolete. Please go to metalink.oracle.com
and use bug 6880880 to get latest version of OPatch.

UtilSession failed:

This version of OPatch is obsolete. Please go to metalink.oracle.com
and use bug 6880880 to get latest version of OPatch.

OPatch failed with error code 73

如何查询一张表被锁住的是哪一行？也就是说会话是在哪条记录上产生了等待呢?
其实主要就是通过查询v$session,再结合dbms_rowid.ROWID_CREATE获得所等待的OBJECT及其ROWID：

select row_wait_obj#,row_wait_file#,row_wait_block#,row_wait_row# from v$session;
 
select 
 owner||'.'||object_name object,object_type 
from dba_objects where object_id=row_wait_obj#;
 
select 
 dbms_rowid.ROWID_CREATE
 (1,:row_wait_obj#,:row_wait_file#,:row_wait_block#,:row_wait_row#) 
from dual;

SQL*PLUS中new_value的作用还是挺大的,多次在写脚本时用到它。使用new_value,可以方便的保存从Oracle表中选择出的数据，存为变量使用。

小结了三种使用方法，只是用到的地方不同，调用new_value的方法还是相同的：

日常维护中，我们通常会通过各种命令获得一些trace，这里总结了一下，获取TRACE文件存放的路径的两种方法：

有些数据库，TEMP数据文件设置成了自动扩展，渐渐导致了TEMP表空间太大，甚至撑爆了整个文件系统，最终不得不重建一个较小的TEMP表空间进行切换。切换过程比较简单，大致如下：

UNDO表空间切换，属于日常维护的常用的操作，比如进行数据加载时，常会切换一个更大的UNDO表空间。简单测试一把：

从10G开始，若采用dbms_stats进行schema或table的分析，则会自动保存统计信息于dba_tab_stats_history。默认保存31天。且可用DBMS_STATS.RESTORE….相关的过程来恢复以前的统计信息。

今天在做insert时，报了个
ORA-00997: illegal use of LONG datatype

原来是表上有个LONG类型的字段。oracle在使用long类型时，还是有比较多限制的。
简单做了个实验来实现数据间的迁移：

数据库中，常有一些状态为Killed的会话，直接查询V$PROCESS，其SPID已经查询不到。