切换temp表空间引起大量enqueue

下面这个案例告诉我们，在一般的情况下，不要轻易的尝试在生产系统上切换temp表空间。如果真的要切换，还是找一个停机时间，关掉侦听，安安静静的做切换。

事情的起因是这样的，某地的数据库由于业务异常，temp表空间从67G一下子增长到142G，造成在文件系统的空间使用紧张，因此我们决定用切换temp表空间的方式新建一个temp表空间。具体的操作步骤大致为：
（1）新建temp2临时表空间，将系统的默认临时表空间切换到temp2；
（2）等待temp上所有的事务完成；
（3）删除temp表空间及其tempfile，释放文件系统空间
（4）重新再建一个67G的临时表空间temp
（5）将系统默认temp2表空间切换到temp；
（6）待temp2上完成事务后，删除temp2表空间和tempfile。
上述操作在进行到第三步的时候，由于事务太多，temp表空间一直在被使用中，drop tablespace的操作一直无法完成，处于的等待事件一直是smon timer，等了差不多到了晚上，还没完成，于是同事就先中断掉该操作。

第二天观察temp的表空间的使用情况，temp表空间的使用率为0，但是查sort usage中还是有10多个sid在使用temp，其余大部分的session已经在使用temp2.

由于temp2的表空间比较小，因此晚上跑应用的批量作业的时候，报错ora-1652 temp表空间无法扩展了。因此为了能让应用顺利跑完成，我们将临时表空间再次切换回temp。

问题发生了，应用的人来报告不少事务无法完成，很多任务都挂起完成不了，于是赶紧登录数据库检查情况，发现了很多enqueue等待：

先看看这些enqueue的sid：

为了查明enqueue的情况，做一个hanganalyze：

进一步去看trace文件：

从trace 文件可以看到，在Chain 1部分，sid为166和31的session已经被sid为7的session hold住。而166和31的session即为enqueue的等待。

另外我们再挑一个enqueue的sid，看看被什么堵塞，如sid 127的，我们看到sid 127被165行，即sid为166的堵塞，而166是被sid为7的session堵塞。

其他类似的enqueue session我们最终都能归结到sid 为7的堵塞上去。

而sid为7的session是smon进程，等待是smon timer，从smon的功能上去理解，smon进程正在清理temp中的临时数据，我们需要等待smon进程清理干净。

正常情况下，我们可以直接把hang的源头的session杀掉，就可解决enqueue的问题，但是由于源头是smon，直接杀进程将导致数据库crash，而等待smon完全清理完还需要未知的很多时间，会影响到业务的正常操作，为了尽快解决问题，我们在这里选择的处理方式是重启数据库。

重启完数据库后，enqueue消失。