关于ORACLE9i RAC双机的临时表空间问题

Question

大家好，我想提问一个关于临时表空间的问题。
我的oracle9i安装在aix5.3 上面，是rac 双机
我的双机中为某一个用户指定了一个临时表空间。 现在我发现其中一个节点的临时表空间占用了22G 另外一个节点占用了278G 我的临时表空间总共是300个G，我知道临时表空间总是显示的是占满的，但是我现在的问题是，我感觉到我那个22G的节点，临时表空间总是容易溢出，似乎已到22G就不能正常运行了，会产生错误，及时另外一个节点的278G并没有全部用掉。似乎两个节点之间并不是真正共享而是先占先得的一种状态，我想向大家求证一下，是否RAC中就是这样的分配临时表空间。那么我的22G节点临时表空间实在太小了。
有没有办法让他们充分共享，或者每个节点指定自己的临时表空间呢？请教 谢谢。

Answer 1

Any DW, OLTP or mixed workload application that uses a lot of temp space for temporary tables, sort segments etc, when running low on temp space, lots of sessions would start waiting on ‘SS enqueue’ and ‘DFS lock handle’ waits. This would cause some severe performance issues. This best practice note for temporary tablespace, explains how this works in RAC environment and offer recommendations.
Space allocated to one instance is managed in the SGA of that instance, and it is not visible to other instances.Instances do not normally return temp space to the ‘common pool’. If all the temp space is allocated to instances, and there is no more temp space within an instance, user requests for temp space will cause a request for temp space to be sent to the other instances. The session requesting the space will get the ‘SS enqueue’ for the temporary tablespace and issue a cross instance call (using a CI enqueue) to the other instances (waiting for ‘DFS lock handle’). All inter instance temp space requests will serialize on this ‘CI enqueue, and this can be very expensive. A heavy query executing in one instance and using lots of temp space might cause all or most of the temp space to be allocated to this instance. This kind of imbalance will lead to increased contention for temp space.As users on each instance request temp space, space will be allocated to the various instances. During this phase it is possible to get contention on the file space header blocks, and it is recommended to have at least as many temp files as there are instances in the RAC cluster. This normally shows up as ‘buffer busy’ waits and it is different from the ‘SS enqueue’/’DFS lock handle’ wait issue. Temporary tablespace groups are designed to accommodate very large temp space requirements, beyond the current limits for a single temporary tablespace: 8TB (2k block size) to 128TB (32k block size).One possible advantage of temporary tablespace groups is that it provides multiple SS enqueues (one per tablespace), but this only shifts the contention to the CI enqueue (only one system wide)It is easier to share space within a single temporary tablespace, rather than within a temporary tablespace group. If a session starts allocating temp space from a temporary tablespace within a temporary tablespace group, additional space cannot be allocated from another temporary tablespace within the group. With a single temporary tablespace, a session can allocate space across tempfiles.