一块来分析temp表空间不能被释放的问题！

szbestway

并发用户有几百是再高峰期，同时在线一般都有2000－3000 多人，用户浏览页面的造成的并发应该有100人左右，我问过了oracle 公司，强烈建议用65k-256k对并发数太大的，65k可以。
我查询：
SQL> select count(*) from sys.v_$sort_usage;
return        0

我们就一台数据库服务器！

snowhite2000

Web base application 不需要MTS 吧。
我觉得应该查 application coding. database setup adjustment 帮不了多大的忙的。

szbestway

这是昨天temp表空间已经剩余100M左右，并且不变化是做的查询！

select * from sys.v_$sort_segment;
---
ABLESPACE_NAME                 SEGMENT_FILE SEGMENT_BLOCK EXTENT_SIZE
------------------------------ ------------ ------------- -----------
URRENT_USERS TOTAL_EXTENTS TOTAL_BLOCKS USED_EXTENTS USED_BLOCKS FREE_EXTENTS
------------ ------------- ------------ ------------ ----------- ------------
REE_BLOCKS ADDED_EXTENTS EXTENT_HITS FREED_EXTENTS FREE_REQUESTS   MAX_SIZE
---------- ------------- ----------- ------------- ------------- ----------
AX_BLOCKS MAX_USED_SIZE MAX_USED_BLOCKS MAX_SORT_SIZE MAX_SORT_BLOCKS
--------- ------------- --------------- ------------- ---------------
ELATIVE_FNO

TEMP                                       8        244977        1024
          374           448       459140          374      383308           74
      75832           448         976             0             0        448
    459140           448          459140             1            1029
           8

ArthurXu

alter tablespace temp temporary;
alter tablespace temp default storage(next 4M);

白鹭

每次排序结束后，临时段即使空间没有释放，也可供其他排序使用，因此没有释放也没有关系，难道你的空间非常紧张?否则数据库应用的变化，temp,rbs表空间增长比较大是正常的，你不一定非要让它很小，有的temp表空间甚至增长超过10G也是正常的,另外你也确实要考察一下耗费临时段的SQL语句有没有问题。

szbestway

对于这一点，由于此系统是在原有的应用系统的升级!
主要是由ASP ->JSP ，并增加几个新的应用模块，但新的模块使用的人数较少，并由数据库的脚本重新创建！

而原有的还没有此类的问题出现！

szbestway

我们空间没有问题，但不能无限制的开放，昨天我增加了1G的TEMP表空间，很快就满了！
如果我继续增加，还会将空间充满的！
因为老的ASP就不需要这么多的TEMP空间！ 大于3－4 G就够了！


此外，我们由大约1000个存储过程，如和去找考察一下耗费临时段的SQL语句有没有问题？？

白鹭

select * from sys.v_$sort_segment;
---
ABLESPACE_NAME SEGMENT_FILE SEGMENT_BLOCK EXTENT_SIZE
------------------------------ ------------ ------------- -----------
URRENT_USERS TOTAL_EXTENTS TOTAL_BLOCKS USED_EXTENTS USED_BLOCKS FREE_EXTENTS
------------ ------------- ------------ ------------ ----------- ------------
REE_BLOCKS ADDED_EXTENTS EXTENT_HITS FREED_EXTENTS FREE_REQUESTS MAX_SIZE
---------- ------------- ----------- ------------- ------------- ----------
AX_BLOCKS MAX_USED_SIZE MAX_USED_BLOCKS MAX_SORT_SIZE MAX_SORT_BLOCKS
--------- ------------- --------------- ------------- ---------------
ELATIVE_FNO

TEMP 8 244977 1024
374 448 459140 374 383308 74
75832 448 976 0 0 448
459140 448 459140 1 1029
8

我详细看了你的输出，你的db_block_size是多少?现在先假设你的db_Block_size=8k
你要注意到临时段使用的一个特点，多个排序不能共享一个extent,但可以共享一个排序段，
因此可以考虑稍微减小extent大小，提高空间利用率,
从你的查询中可以看到高峰期有373个使用排序段的并发用户，最大排序块1029说明最大的排序
也不是很大,特点就是小而多，因此你不想增大temp表空间的前提下，应该提高利用率,
推荐
1.sort_area_size调大到256k,假如你内存足够，256K*400用户也不过100MB内存，更大的sort_area_size意味着更多的排序再内存中进行。
2. extent大小可以改为256k*4+1db_block_size=1032k,因为要放下header block
3.表空间改为我推荐的local managerment and temp file
4.调整后在高峰期用我给你提供的语句查询，再补充查询
SELECT * FROM V$SYSSTAT
WHERE NAME LIKE '%sort%';

szbestway

很感谢白鹭！

我们现在的db_block_size＝4k,数据库的内存由2G
我可以将sort_area_size调大到256k
和使用local managerment

但我现在不太清楚extent的修改是在那个参数！
而且现在对数据库的修改，必需由客户来做！ 可能需要时间来观测！

白鹭

就是你重建表空间时
...
extent management local
uniform size 1028k;