今天看到一个容灾系统，一个节点宕机了，想起来，直接报db_name不对，靠，这可是写在spfile中的。检查另外一个节点show parameter spfile，值是对的，用了一个裸设备。从vspparameter中看值，也有的。
既然说db_name不对，那就生成pfile检查下。做create pfile from spfile，然后cat pfile，居然，既然是空白的。
然后就是一堆的检查，这事情有点邪门了，最后的结果居然是 ，这个裸设备被人当数据文件加到数据库中去了，靠，搞的我现在都不敢重启另外一个节点了。
唉，怪事年年有，今天特别多。
对了，只要明年，哦，明天就是明年了，希望从明天开始没怪事就好。
早上一大早，整在做梦列，梦里好多漂亮mm，突然电话响了，是lori那小子给我的电话，一般在休息天看到这种电话我都很郁闷的，肯定是出事了。
果然出事了，某个系统应用出现了严重的等待，数据库都快不行了。只能起来，连上网络，然后vpn，看看系统性能，我靠，1号节点严重的row cache lock等待，2号节点严重的us contention等待，玩大了。
后台查询下，等待锁的进程接近8000个，靠，这样的系统还能用才奇怪。
立刻检查系统，发现系统一直在等一个select sequence.nextvalue from dual.很明显，这个sequence肯定有问题，检查这个sequence，发现cache size=0，靠，不等待才奇怪，立刻修改这个sequence的cache size为200，等待了大约300s，才执行成功，期间一堆的sahred pool wait，好了以后，这个row cache lock总算好了
不到10分钟，us contention等待超过。莫非是undo出问题了？
检查系统undo，undo表空间一共68GB，两个节点，每个节点也有34GB，继续检查，发现active和unexpired的一共有67G多，靠，undo严重不够了，怪不得争用。
继续检查，发现系统中居然有两个imp的进程，最大的一个已经active了33G多的undo，这鸟玩意应该不是应用自动发起的呀。
和应用确认，然后kill这些imp进程，然后增加14G的undo，先让应用跑起来再说。
剩下的，是去和应用扯淡分析问题产生的原因。
为什么一个没有移交到维护的系统问题就这么多列，为什么出问题是周末列，唉，看来这个星期的周末又没得睡了。
这两天忙的焦头烂额的，马上元旦了，数据库中很多东西还没有完成列。
一方面，有N多的系统要从9i升级到10g，要忙着装rac，打patchset，另外一个很重要的工作，就是分区扩展了。
数据库中很多表是用了分区，而且是时间分区，年底到了，很多表的分区只扩展到了08年12月份，也就是下个月的数据都会丢到pmax这个区中去了。
写了个简单的语句来获取那些表没有2009年的分区
SELECT table_owner,TABLE_NAME
FROM DBA_TAB_PARTITIONS
WHERE TABLE_NAME IN (SELECT A.NAME
FROM DBA_PART_KEY_COLUMNS A, DBA_TAB_COLUMNS B
WHERE A.OBJECT_TYPE = ‘TABLE’
AND A.COLUMN_NAME = B.COLUMN_NAME
AND A.NAME = B.TABLE_NAME
AND A.OWNER = B.OWNER
AND B.DATA_TYPE = ‘DATE’)
AND TABLE_NAME NOT IN
(SELECT TABLE_NAME
FROM DBA_TAB_PARTITIONS
WHERE TABLE_NAME IN
(SELECT A.NAME
FROM DBA_PART_KEY_COLUMNS A, DBA_TAB_COLUMNS B
WHERE A.OBJECT_TYPE = ‘TABLE’
AND A.COLUMN_NAME = B.COLUMN_NAME
AND A.NAME = B.TABLE_NAME
AND A.OWNER = B.OWNER
AND B.DATA_TYPE = ‘DATE’)
AND PARTITION_NAME LIKE ‘%200902%’)
GROUP BY table_owner,table_name
ORDER BY table_owner,TABLE_NAME
这样其实不一定全，因为我找的是按照时间分区，且没有200902这个分区的。
这么一找，我的系统中居然一大堆的表没有扩展分区，这不这两天忙着写脚本去分裂分区。
脚本完成后，还得先在备份测试系统上测试是否通过，另外，需要多久时间，然后申请停机时间，在生产系统实施。
俺这总算还有N多人记得这事，你列，你的数据库，分区扩展好了吗？还有不到15天的时间，加紧吧，呵呵。
PS：如果你是看了我的这个文章才想起来你也要分区扩展了，可记得请我吃饭，呵呵，因为我帮你避免了数据库隐患吗。
因为要在生产系统上清理一个表空间，100g大，用了不到10g，准备用oracle提供的从tablespace中drop datafile的方式，如是在测试系统上进行了测试，得到如下的结果。
SQL> create tablespace guoyue datafile ‘/data01/restore/zjcs/guoyue01.dbf’ size 100M;
Tablespace created.
SQL> alter tablespace guoyue add datafile ‘/data01/restore/zjcs/guoyue02.dbf’ size 100M;
Tablespace altered.
SQL> create table guoyue (a number) tablespace guoyue storage (initial 150M);
Table created.
SQL> alter tablesapce guoyue add datafile ‘/data01/restore/zjcs/guoyue03.dbf’ size 100M;
alter tablesapce guoyue add datafile ‘/data01/restore/zjcs/guoyue03.dbf’ size 100M
*
ERROR at line 1:
ORA-00940: invalid ALTER command
SQL> alter tablespace guoyue add datafile ‘/data01/restore/zjcs/guoyue03.dbf’ size 100M;
Tablespace altered.
SQL> alter tablespace guoyue drop datafile ‘/data01/restore/zjcs/guoyue03.dbf’;
alter tablespace guoyue drop datafile ‘/data01/restore/zjcs/guoyue03.dbf’
*
ERROR at line 1:
ORA-03262: the file is non-empty
到底啥问题列，持续关注下。
现在问题越来越好玩了
对drop datafile操作做10046 发现
select count(*) counter
from
seg$ where file# = :1 and type# != 3
call count cpu elapsed disk query current rows———-————————————————————————————————Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.01 0.00 0 86 0 1———-————————————————————————————————total 3 0.01 0.00 0 86 0 1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 1)
Rows Row Source Operation———-—————————————————————————-
1 SORT AGGREGATE (cr=86 pr=0 pw=0 time=1576 us)
1 TABLE ACCESS CLUSTER SEG$ (cr=86 pr=0 pw=0 time=1549 us)
1 INDEX SKIP SCAN I_FILE#_BLOCK# (cr=85 pr=0 pw=0 time=1516 us)(object id 9)
然后，
SQL> select file#,block#,type#,ts#,blocks from seg$ where file# =698 and type# != 3;
FILE# BLOCK# TYPE# TS# BLOCKS—————————————————————————698 13187 6 127 5888
SQL> select owner,segment_name,segment_type from dba_extents where file_id=698 and block_id=13187;
no rows selected
反正现在oracle大连支持中心的mm已经给我搞昏了，不知道啥意思了，继续关注中。
update ：2008-12-11
经过和oracle国外的工程师无数次蹩脚英语的交流以后，确认改问题为bug，bug号码为7022905，总算有了一个结论。