第一次遇到在awr top 5 event中出现enq:SS-contention 和enq:TS-contention

开发人员跟我说有台测试环境数据库有问题，很卡，应用程序启动起来就卡住，根本无法使用。但没有报任何ora-相关的错误，让我瞧瞧T

我用plsql developer登录下，发现还好，看了下最近的alert日志，也没有异常。下意识的觉得不应该是数据库问题，可能是开发那边网络之类导致出现卡顿的情况。恰巧到饭点，无心恋战，开发人员就让我将数据库重启下，我内心不深处觉得重启是解决不了问题的，但开发给我的回复是重启后好了。

心里一直挂着这事，午休后上班就再次登录上去仔细查验一番。首先看了下最近几天awr DB Time耗时，果然，有问题。从昨天下午5点多开始，awr中每小时db time竟然高达2000多分钟，这肯定是不正常的。于是生成了一个时段的awr，迎面而来的就是标题的两个等待事件：enq:SS-contention,enq:TS-contention

其中enq:SS-contention是第一次遇到，在mos上找到了这样一段描述：

We get disk sort space from sort segment. There is one sort segment for

one instance, and it is created if we don't find sort segment.

To create sort segment, we send message to SMON to do it.

When SMON require sort segment, it goes same path like other process,

except SMON don't message to itself basically.

However, SMON try to acquire SS message enqueue to post smon.

As a result, if some FG want sort segment at the same timing,

FG can get SS enqueue faster than SMON and SMON can goes into wait,

then SMON cannot respond message and goes into deadlock situation.

The problem could be understood as due to a race condition between SMON and

the Foreground processes.

读起来感觉有点绕，于是我又看了下昨天5点后的alert日志，发现存在将表空间直接rename的动作，结合这个事件，再和上面的描述相推断，我理解成:

开发人员将应用正在使用的临时表空间直接命名了，但前台应用进程应该还在持有这相关temp信息，后台进程smon呢又要做表空间名字变化后的相关处理操作，但由于前台应用进程的一直持有，导致smon进程一直处理不成功，僵持在那里了。后来数据库重启，前台应用连接全部释放，smon进程瞬间完成工作，一切恢复正常，大家美滋滋

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

这个问题也是第一次遇到，不常见。一般我们更换临时表空间，都是新建一个新的，然后改下用户默认临时表空间，倒是很少直接rename表空间名称的。

至于说希望自己下次处理问题要仔细点的话，哈，左耳进右耳出咯。