一些测试结果:
1、在我的笔记本上,PIII-1G,512MB RAM,HIST表为普通表
SQL> select count(*) from hist; --查询纪录总数(1.5M)
  COUNT(*)
----------
   1525162
Elapsed: 00:00:12.09SQL> select * from hist --根据索引字段查询纪录
  2  where dmdunit in ('76108185','10018113');
...
869 rows selected.
Elapsed: 00:00:12.972、在服务器上,RS-6000,AIX,24GB RAM,3个INSTANCES,在线用户150人,HIST表为分区表
SQL> select count(*) from hist; --查询纪录总数(96M)
  COUNT(*)
----------
  96202315
Elapsed: 00:02:55.15SQL> select * from hist --根据索引字段查询纪录
  2  where dmdunit in ('76108185','10018113');
...
869 rows selected.
Elapsed: 00:00:05.40看起来效率应该还可以,200万纪录没太大问题。不过我这边没有环境测试300个用户下的情况,你检查一下数据库的连接采用的专用模式还是共享池模式,如果是专用模式,那就要检查INSTANCE的PGA是否占用了太多的内存空间。

解决方案 »

  1.   

    sort_area_size 多大?系统等待事件主要是什么?
      

  2.   

    freelist是多少  ---------最根本的着眼点
    先分析出什么事件造成等待  :)
      

  3.   

    1、检查磁盘争用情况,I/O性能(可以把表空间建在几个盘上,索引要建立一个表空间)2、可以多设几个回滚段,每一个回滚段不一定要太大。3、临时表空间可能要大一些4、SQL语句要优化
      

  4.   

    KingSunSha(弱水三千):
    你提供的数据非常有参考意义!
    但是有没有办法使效率再次提高一倍左右,让客户更加满意一些。
    从网络结构和服务器应用结构上再次提供其他方面的参考意见!!
    十分感谢关注
      

  5.   

    查询的速率和返回的纪录数大有关系,我刚刚测试了一下,如果只要返回300条左右的纪录,那在sqlplus中只用3秒左右,如果只要返回150条左右的纪录那只要1.6秒,这个速度应该可以接受了。如果返回的纪录数很多,那单单通过网上传输这些数据都需要不少时间,反应时间恐怕不会理想。