今天在数据库的v$locked_object视图 里发现一个923号session，用户是SYS，一直持有对 PLAN_TABLE表的锁不释放，PLAN_TABLE是存储SQL执行计划的，很奇怪。

select sid,serial#,paddr,username,server,schemaname,osuser,terminal,program from v$session where sid=923

SID    SERIAL#    PADDR    USERNAME    SERVER    SCHEMANAME    OSUSER    TERMINAL    PROGRAM
923    42779    0700000C8F3D9588    SYS    PSEUDO    SYS    oracle    pts/2    sqlplus@p5b1 (TNS V1-V3)

查看进程信息：

select * from v$process where addr='0700000C8F3D9588'

发现spid的值为234178，这个也就是操作系统的进程id：

DB2@/ora_arch>ps -ef|grep 234178
oracle 413964 807630   0 15:00:19  pts/1  0:00 grep 234178
oracle 234178 623538   [...]

锁是数据库里一个重要的概念，可以自己来模拟一个Oracle中的死锁状态。

首先session A登录到系统，更新一条记录：

[oracle@devdb ~]$ export ORACLE_SID=optm
[oracle@devdb ~]$ sqlplus " / as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Tue May 11 23:14:09 2010

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 [...]

从windows 平台迁移一个简单的Java系统到Linux 平台，应用服务器是Tomcat，在Linux 上安装好JDK后，直接把整个Tomcat复制到了Linux 上，然后启动都正常。但是在软件打开登录的时侯一直提示无法连接到数据库，坚持Tomcat的日志记录的信息如下：

ORA-00604: error occurred at recursive SQL level 1

java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1
ORA-12705: Cannot access NLS data files or invalid environment specified

Google 了很多资料，大多说是NLS_LANG设置的问题：

ORA-12705: "invalid or unknown NLS parameter value specified"

Cause: There are two possible causes:

- An attempt was made to [...]

oracle 提供了在线重定义功能，可以把普通表转化为分区表，记录一下操作过程：

首先扩展必要的表空间，然后查看要操作的表是否可以进行分区：

[oracle@erpdevdb admin]$ sqlplus " / as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Fri Mar 26 18:50:12 2010

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> alter database datafile [...]

有时候会在Oracle alert日志中看到如下信息：

GES: Potential blocker (pid=348868) on resource TX-0013000E-0010D004;

这就是rac中的死锁，一般Oracle会自己处理，有时候需要手工干预。要找到这个引起死锁的session也很简单，通过v$process和v$session视图就能查到：

select * from v$session where paddr= (select addr from v$process where spid='348868')

可以根据这个session的情况来决定如何处理。比如这个session的program是oracle@p5b1 (J000)，这应该 是oracle自身的job，然后检查dba_jobs_running，发现昨晚的一个job没有跑完，而这个job阻塞了其他的session。

可以查看v$session_wait视图查看该session的等待事件：

select * from v$session_wait where event<>'SQL*Net message from client'
and event<>'rdbms ipc message'

发现等待事件在db file sequential read和gc cr request间不断切换，这在rac中是很常见的，说明这个job需要的很多block要从别的节点上作一致读，而state是WAITED KNOWN TIME表示等待已经结束了。

那么如何找到被阻塞的session是什么呢？可以通过v$lock来查看，block=1的是blocker，block=0的是waiter，另外更直观的做法是查看DBA_WAITERS视图，该视图可以通过运行 $ORACLE_HOME/rdbms/admin/catblock.sql这个脚本来创建。DBA_WAITERS里的lock_id1和lock_id2分别对应v$lock中的id1和id2，不同的lock有不同的定义， 比如TM的话，lock1就是object id。

如果严重影响了系统的运行，可以杀死引起死锁的session：

alter system [...]