开博了。其实之前有的，只是不在pub上，最近实在忍受不了msn共享空间了。

热点块处理是首先应该处理对象呢？还是优化sql。

上一篇 / 下一篇  2008-07-29 16:34:03 / 个人分类：Oracle资料与实践

查看( 292 ) / 评论( 22 )
查到系统里面cache buffers chains 挺严重，按照biti_rainy的一篇文章
http://blog.csdn.net/biti_rainy/archive/2004/07/06/35188.aspx
查看了一下，找到了一些sql以及对应的对象(主要是表和索引).
这些表、索引有一些很久没有分析了。
我应该是先做一下分析。然后再处理语句呢？还是直接进行语句的优化。
补充：数据库版本oracle 9206
        os ：redhat as 4

[ 本帖最后由 foxmile 于 2008-7-29 17:30 编辑 ]

论坛模式 推荐 收藏 分享给好友 推荐到圈子 管理

TAG:

花好月不圆的个人空间 花好月不圆 发布于2008-07-29 16:35:48
先分析看看 ,说不定 sql 立即就优化了
蚊子窝 foxmile 发布于2008-07-29 16:39:56
确实有些sql优化余地太小，很短，该走索引的走的都是索引。打算和领导确认一下，先把这几个对象分析下。
rollingpig的个人空间 rollingpig 发布于2008-07-29 16:43:33
建议先备份statistics
蚊子窝 foxmile 发布于2008-07-29 16:45:29

QUOTE:

原帖由 rollingpig 于 2008-7-29 16:43 发表
建议先备份statistics
恩，版主提醒的是。上次我分析另外两个对象的时候就把statistics的信息备份做了一下测试。比较熟悉了。
如果统计信息出了问题，挺麻烦的。
棉花糖ONE发布于2008-07-29 16:51:07

QUOTE:

原帖由 foxmile 于 2008-7-29 16:39 发表
确实有些sql优化余地太小，很短，该走索引的走的都是索引。打算和领导确认一下，先把这几个对象分析下。
有可能就是走错了索引
蚊子窝 foxmile 发布于2008-07-29 16:54:02

QUOTE:

原帖由 棉花糖ONE 于 2008-7-29 16:51 发表


有可能就是走错了索引
恩，这个可能性有，不过，这个库的索引建的都不多。如果走错了。那应该就是不该走索引的走了索引。。。。。
pulf的个人空间 pulf 发布于2008-07-29 16:59:18
先收下来慢慢研究
蚊子窝 foxmile 发布于2008-07-29 17:01:49
cache buffers chains
除了热点块引起之外，还有没有可能是其他原因引起的？
oracle_man发布于2008-07-29 17:03:26
表的数据量大不大如果是大表的话，分析可能就得花点时间了
蚊子窝 foxmile 发布于2008-07-29 17:07:05

QUOTE:

原帖由 oracle_man 于 2008-7-29 17:03 发表
表的数据量大不大如果是大表的话，分析可能就得花点时间了
这几个对象没有省油的，都不小
估计 ESTIMATE 20的话，每个都得十分钟以上。最大的估计半个小时
蚊子窝 foxmile 发布于2008-07-29 17:10:43

QUOTE:

原帖由 foxmile 于 2008-7-29 17:01 发表
cache buffers chains
除了热点块引起之外，还有没有可能是其他原因引起的？
哪位对这个比较熟悉
在水中燃烧发布于2008-07-29 17:20:10
首先你应该做一个statspack的报告看看，确定是否真的SQL没有问题。

另外，可以考虑增加你的表的pctfree  
spreading them many  more  blocks
蚊子窝 foxmile 发布于2008-07-29 17:29:47

QUOTE:

原帖由 在水中燃烧 于 2008-7-29 17:20 发表
首先你应该做一个statspack的报告看看，确定是否真的SQL没有问题。

另外，可以考虑增加你的表的pctfree  
spreading them many  more  blocks
其实就是从statspack报告里面看出来的。
在水中燃烧发布于2008-07-29 17:35:31

QUOTE:

原帖由 foxmile 于 2008-7-29 17:29 发表


其实就是从statspack报告里面看出来的。
贴出来看看了。
ZALBB的个人空间 ZALBB 发布于2008-07-29 17:36:17
优化语句，包括分析统计信息。
蚊子窝 foxmile 发布于2008-07-29 17:43:53

QUOTE:

原帖由 在水中燃烧 于 2008-7-29 17:35 发表

贴出来看看了。
明天把statspack报告贴上来。
hanjs发布于2008-07-29 18:20:54
>> cache buffers chains锁存器的争用原因一：低效率的SQL语甸

在某些环境中，应用程序打开执行相同的低效率SQL语句的多个并发会话，这些SQL语句都设法得到相同的数据集。较小的逻辑读意味着较少的latch get操作，从而减少锁存器争用并改善性能。

每次执行都带有高 BUFFER_GETS(逻辑读取)的SQL语句是主要的原因。

>> cache buffers chains锁存器的争用原因二：热块

当多个会话重复访问一个或多个由同一个子cache buffers chains锁存器保护的块时，热块就会产生。当多个会话争用cache buffers chains锁存器时，找出是否有热块的最好的方法是检查latch free等待事件的P1RAW参数值。

SELECT s.EVENT, s.sid, s.p1raw, s.p2, s.p3, s.seconds_in_wait, s.wait_time, s.state
  FROM v$session_wait s
WHERE s.event = 'latch free'

如果P1RAW是相同的锁存器地址，则表明有热块出现。用以下语句查出热块所属数据库对象。

SELECT a.hladdr, a.file#, a.dbablk, a.tch, a.obj, b.object_name
  FROM x$bh a, dba_objects b
WHERE (a.obj = b.object_id OR a.obj = b.data_object_id)
   AND a.hladdr = '锁存器地址(P1RAW)'

union

select hladdr, file#

热块通常具有高TCH(touch count：接触次数)，但需注意的是，块从LRU列表的冷端移到到热端时，值TCH就被重新设置为0，所以TCH值为0的块并不一定是冷块。

解决方法：

尽可能地展开块，即，让块包含的记录少一点。这样产生热点块的机率就低一些。

>> cache buffers chains锁存器的争用原因三：长散列链
蚊子窝 foxmile 发布于2008-07-29 18:26:35

QUOTE:

原帖由 hanjs 于 2008-7-29 18:20 发表
>> cache buffers chains锁存器的争用原因一：低效率的SQL语甸

在某些环境中，应用程序打开执行相同的低效率SQL语句的多个并发会话，这些SQL语句都设法得到相同的数据集。较小的逻辑读意味着较少的latch get操作，从而减少锁存器争用并改善性能。

每次执行都带有高 BUFFER_GETS(逻辑读取)的SQL语句是主要的原因。

>> cache buffers chains锁存器的争用原因二：热块

当多个会话重复访问一个或多个由同一个子cache buffers chains锁存器保护的块时，热块就会产生。当多个会话争用cache buffers chains锁存器时，找出是否有热块的最好的方法是检查latch free等待事件的P1RAW参数值。

SELECT s.EVENT, s.sid, s.p1raw, s.p2, s.p3, s.seconds_in_wait, s.wait_time, s.state
  FROM v$session_wait s
WHERE s.event = 'latch free'

如果P1RAW是相同的锁存器地址，则表明有热块出现。用以下语句查出热块所属数据库对象。

SELECT a.hladdr, a.file#, a.dbablk, a.tch, a.obj, b.object_name
  FROM x$bh a, dba_objects b
WHERE (a.obj = b.object_id OR a.obj = b.data_object_id)
   AND a.hladdr = '锁存器地址(P1RAW)'

union

select hladdr, file#

热块通常具有高TCH(touch count：接触次数)，但需注意的是，块从LRU列表的冷端移到到热端时，值TCH就被重新设置为0，所以TCH值为0的块并不一定是冷块。

解决方法：

尽可能地展开块，即，让块包含的记录少一点。这样产生热点块的机率就低一些。

>> cache buffers chains锁存器的争用原因三：长散列链
兄弟，怎么感觉文章没完啊。
sdusun的个人空间 sdusun 发布于2008-07-29 18:30:42
可以参考 OWI，呵呵
蚊子窝 foxmile 发布于2008-07-29 18:32:29

QUOTE:

原帖由 sdusun 于 2008-7-29 18:30 发表
可以参考 OWI，呵呵
兄弟，详细一点？
blue_or_white发布于2008-07-29 18:33:39

QUOTE:

原帖由 foxmile 于 2008-7-29 17:10 发表


哪位对这个比较熟悉
(1)hot blocks, you can use the following query to determine
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
select * from v$waitstat where class in ('data block','undo block','segment header','undo header')
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(2)long hash chain,you can use the following query to determine if the problem is caused by the long hash chain
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
select hladdr, count(*) from   x$bh group by hladdr order by 2;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(3)insufficient SQL(lots of logical read)

So my suggestion is that, use the given sql to determine the cause of the cache buffer chain,
at the same time, tuning the sql that causes a lot of logical read.
hanjs发布于2008-07-29 18:40:51

QUOTE:

原帖由 foxmile 于 2008-7-29 18:26 发表

兄弟，怎么感觉文章没完啊。
没有办法，人家没有整理完。就是 非空闲等待事件.chm 的那个文档里面的，也是在论坛下载的！
我来说两句

(可选)

日历

« 2008-10-13  
日 一 二 三 四 五 六
   1234
567891011
12131415161718
19202122232425
262728293031 

数据统计

  • 访问量: 5459
  • 日志数: 147
  • 图片数: 1
  • 建立时间: 2007-12-10
  • 更新时间: 2008-09-12

RSS订阅

Open Toolbar