在本地的环境中测试外部表的性能，由于空间有限，不一会儿归档的空间就爆了。然后文件貌似出现了系统级的问题，刚刚rm掉的归档日志文件。隔了几秒钟再ls，就出现了。怎么删都删不掉。尝试了多次之后，无奈尝试shutdown immediate结果等了好半天还是没反应，然后采用shutdown abort后重启，库直接起不来了。报了ora错误，然后库就起不来了。

查看日志显示，和之前碰到的归档空间不足导致的问题一致。清除有问题的归档之后，重启库就起来了。可以参见日志：http://blog.itpub.net/23718752/viewspace-1167163/

SMON: enabling cache recovery ORACLE Instance TEST01 - Archival Error ORA-16038: log 3 sequence# 339 cannot be archived Error message: Linux-x86_64 Error: 28: No space left on device

然而这仅仅是个开始。我检查文件的使用情况，马上发现有一个目录下空间只剩下几百k了，排查空间的使用情况，最后定为是Undo的自增长造成的，本来500M左右的Undo现在涨到了900多M。

因为库是刚起来的，也没什么其他的操作，于是就做了Undo文件的resize,结果让我大跌眼镜。

SQL> alter database datafile '/u03/ora11g/oradata/TEST01/undotbs01.dbf' resize 500M; ORA-03297: file contains used data beyond requested RESIZE value

resize不行，再也没有其他的多余空间，而且目前遇到的情况更奇怪，归档生成的极为频繁。本来空间就紧张的虚拟机几乎不能做任何操作。

我最后尝试更改归档路径，把归档指到空间稍大的一个分区。然后再查查看到底是什么在后台消耗了这么多的资源，这个库自启动以来没做任何其他的操作。

先更改了归档路径，然后shutdown immediate还是没反应，尝试shutdown abort重启。这次重启没有其他的问题。库起来了，

但是在短时间内生成了相当多的归档文件。有很多已经被自己手工删除了。

rw-r----- 1 ora11g dba 99933184 Jun 8 01:04 1_358_837590339.dbf

查看系统级的进程。里面有好几个并行相关的进程，目前没有其他的操作，是在做后台的回滚吗？

我记得重启之前做数据加载测试的时候是用了并行。

top - 01:10:00 up 1:06, 3 users, load average: 3.52, 3.27, 2.99

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3176 ora11g 20 0 530m 76m 74m D 10.9 3.9 2:16.24 ora_p003_TEST01 3158 ora11g 20 0 531m 79m 77m D 9.6 4.0 2:11.00 ora_p001_TEST01 3174 ora11g 20 0 530m 73m 71m S 5.3 3.7 2:13.23 ora_p002_TEST01 3128 ora11g 20 0 549m 91m 71m D 3.6 4.6 0:50.43 ora_dbw0_TEST01

查看当前是否有session在操作

SELECT s.USERNAME,s.SID,s.SERIAL#,t.UBAFIL "UBA filenum", t.UBABLK

no rows selected

查看undo的使用情况

SELECT

Tablespace Name TS Size(MB) UNDO Stat Used Extents Used Size(MB) Used Rate(%) UNDOTBS 933.125 ACTIVE 283 929.88 99.65

使用ash来查看一些到底在那几分钟里发生了什么。

Sid,Srl# (Inst) % Activity SQL ID Event % Event 243, 1(1) 75.35 wait for a undo record 21.62

db file sequential read 18.32

wait for stopper event to be 16.08

-------------------------------------------------------------

Top DB Objects DB/Inst: TEST01/TEST01 (Jun 08 01:04 to 01:09)

Object ID % Activity Event % Event 15390 7.00 db file sequential read 6.83 N1.T (TABLE) POOL_DATA

15391 3.92 db file sequential read 2.86 N1.SYS_C005621 (INDEX) POOL_DATA

buffer busy waits 1.06

-------------------------------------------------------------

Top DB Files DB/Inst: TEST01/TEST01 (Jun 08 01:04 to 01:09)

File ID % Activity Event % Event

10 2.13 db file sequential read 2.02

8 1.46 db file sequential read 1.46

11 1.40 db file sequential read 1.40

7 1.34 db file sequential read 1.34

-------------------------------------------------------------

Top Latches DB/Inst: TEST01/TEST01 (Jun 08 01:04 to 01:09)

No data exists for this section of the report.

Activity Over Time DB/Inst: TEST01/TEST01 (Jun 08 01:04 to 01:09)

Slot Event 01:04:00 (0 secs) 7 write complete waits 3 0.17 db file async I/O submit 1 0.06 free buffer waits 1 0.06 01:04:00 (1.0 min) 343 wait for a undo record 81 4.54 db file sequential read 67 3.75 wait for stopper event to be i 59 3.31 01:05:00 (1.0 min) 330 wait for a undo record 69 3.87 db file async I/O submit 58 3.25 wait for stopper event to be i 55 3.08 01:06:00 (1.0 min) 363 wait for a undo record 97 5.43 db file async I/O submit 59 3.31 wait for stopper event to be i 52 2.91 01:07:00 (1.0 min) 377 db file sequential read 87 4.87 wait for a undo record 77 4.31 wait for stopper event to be i 61 3.42 01:08:00 (1.0 min) 365 db file sequential read 80 4.48 wait for a undo record 61 3.42 db file async I/O submit 59 3.31

这样看果然一目了然，全部的问题都指向了一个表t和对应的索引。

这个表是做数据加载测试使用的表，加载的数据量有千万。会产生很多的redo。

查看n1.t这个表的情况，看表里面，目前是没有数据，但是查询会持续相当长的时间。简单验证一下。

SQL> select count(*)from t where rownum<2;

COUNT(*)

然后查看表t的统计信息。还是现实千万的数据条数。

*******************************************

TABLE_NAME PAR TABLESPACE STATUS NUM_ROWS BLOCKS EMPTY_BLOCKS LOG MON ROW_MOVE LAST_ANAL 13240320 74364 0 NO YES DISABLED 07-JUN-14

********** TABLE STORAGE INFO *****************

INITEXT NXTEXT MINEXT MAXEXT FREELISTS AVG_SPACE CHAIN_CNT AVG_ROW_LEN CACHE T DEPENDEN COMPRES

在我查完问题之后，问题也好像自动解决了，归档也不在生成了。查看alert文件，确实是在做事务的并行回滚，不过刚刚做完。

Thread 1 advanced to log sequence 360 (LGWR switch) SMON: Parallel transaction recovery tried

我现在要做的就是把表t的高水位线放下来。

SQL> truncate table t;

SQL> set timing on

COUNT(*)

Elapsed: 00:00:00.00