是否可以把经常使用的较大的表设为cache存进buffer cache来提高速度?
还有什么东东可以往buffer cache里放来提高响应速度?
还有什么可以用来对并发执行的SQL进行调优?latch的多少会有影响吗?

解决方案 »

  1.   


     用statspack包做一个分析,看看系统的瓶颈具体在什么地方. 个人感觉OLTP系统上, Library Cache Hit Ratio一般不会有
     太多问题,倒是对Share_pool_size的使用可能会有很多问题.
     
      Library cache 的命中率在95%以上基本就没问题. 如果低于90%,
      需要增大DB_BLOCK_BUFFERS(8i), 9i是另外一个参数.
      

  2.   

    用的9i,DB_CACHE_SIZE已经加很大了,但没加sort_area_retained_size,不知道有没有影响。hit ratio也没什么问题。目前程序在单用户的时候用时2秒,多用户(目前是100个)用时90秒左右。不知道有没有多用户并行方面的调优方法,我找了找,没找到。另外我看书上说用存储过程代替普通SQL语句,可以使SQL语句在buffer cache中执行后的结果保留,从而提高速度,哪位知道这个方法到底有没有用?
      

  3.   


      1. 存储过程确实有不少优越性,例如减小网络流量,执行速度快等等.
         也适合写一些较复杂的业务逻辑,但是它也有自己的局限性,例如
         数据库移植时就比较麻烦,不同的数据库得写不同的代码,别指望
         写一个转换程序就可以通吃大多数数据库.
      2. 你说的SQL语句的执行,其实主要是shared_pool的使用,使用绑定
          变量能有效地提高程序运行地效率.因为它是Soft Parse,而不是
          Hard Parse.
      3.  多用户并发时,主要是保证事务能快速完成,尽可能地减小等待时间.
          因此做一个Statspack的分析很有必要,它可以列出系统目前的
          TOP 5 Wait Events, 而从这些wait events 你就能大致看出系统的
          瓶颈.  
      

  4.   


      SORT_AREA_SIZE 主要是排序用的(Order By, Group By 等),
      设置较大的值可以保证少使用TEMPORARY 表空间,在内存中完成排序.