shared pool 回顾,RAC resource master 原理,dbms_stat 缺陷,ASM 拷贝数据文件

Shared pool subpool

http://www.oraclefans.cn/forum/showtopic_tree.jsp?boardcode=DBA_D&hit=326&rootid=32821

老白的案例分析，虽说最后产生了一些原因定位上的分歧 但是整篇的分析思路还是值得我们学习的，

好久没有回顾当年研究过的SHARED POOL 了 居然忘了shared pool latch 是干嘛的。

回顾一下：是用来负责对shared Pool free list 切分chuck 的时候用的。一般每个pool 只有一个 latch。

Library cache  latch ：比CPU_COUNT 高的一个素数。 这篇文章遇到的了 在pin 和unpin 上的等待，于是老白考虑到了 是由于 latch　数目过少而导致的ｌａｔｃｈ　争用。

同时老白考虑还有一个关于如果提升了ｌａｔｃｈ　数目会提升shared pool的处理能力 导致增加shared pool负载的问题， 于是增加了1G的shared pool。

 

 

gcs drm freeze

在RAC 中 block的master 是一个range的形式，比如block 1-block 128 node1 129-256 node 2.

分配的形式是通过hash 算过去的，而range的话 在10G上一般是128block，oracle support 建议你Unset db_file_multiblock_read_count 这样机会自动调整到128 ，于是每次整个block range 都可以通过少量的GCmessage 进行读取。

 

10G中通过HASH 分配NODE的算法已经改良 ，当一个NODE OFFLINE 的时候只会remaster offline的NODE。

下面的SQL 可以得到object block master NODE 信息。

select kj.*, le.le_Addr from (

select kjblname, kjblname2, kjblowner, kjblmaster, kjbllockp,

substr ( kjblname2,  instr(kjblname2,',')+1,   instr(kjblname2,',',1,2)-instr(kjblname2,',',1,1)-1)/65536 fl,

substr ( kjblname2, 1, instr(kjblname2,',')-1) blk

from x$kjbl

) kj, x$le le

where le.le_kjbl = kj.kjbllockp

order by le.le_addr

/

 

如何判断一个block （或者把这个range 也叫OBJECT把）需要进行remaster？

当一个object 被另一个节点访问过很多次之后 那么就可能需要进行remaster，

_gc_affinity_limit 这个是指一个OBJECT 在另一个instance 被open 多少次。

_gc_affinity_time 代表多久进行一次remaster 检查。

_gc_affinity_minimum 这个是affinity这个动作 每分钟发生多少次才会被考虑进remaster队列。

 

当一个OBJECT 被open 超过_gc_affinity_limit次数后，就会计入 remaster 队列。由LMS 进行remaster 。

[oracle@testdb2 ~]$ ora params _gc_affinity_

 

NAME                                          VALUE                DESCRIPTION

--------------------------------------------- -------------------- ----------------------------------------------------------------------

_gc_affinity_limit                            50                   dynamic affinity limit

_gc_affinity_minimum                          6000                 dynamic affinity minimum activity per minute

_gc_affinity_time                             10                   if non zero, enable dynamic object affinity

 

当进行remaster的时候 GRD 会被freeze 。如果instance 非常繁忙的话 则会造成hang。

为了加快remaster 的速度10G中有个参数叫_rcfg_parallel_replay 默认为true。可以允许进行parallel reconfigure。

而reconfiguration这个是由LMS 进程来控制的。所以LMS 多了可以加快这个速度 但是多了貌似会有问题 推荐是3-5个。

 

下面是LMS0的一段trace 信息。

kjdrchkdrm: found an RM request in the request queue

  Transfer pkey 6589904 to node 2

 

 

dbms_stat

我们都试过 dbms_stat.gather_table_stats  cascade=>ture。

 

当收集统计信息的时候 实际上是收集table的 再收集索引的，这一点 通过数据字典可以看到。

当收集了table 的统计信息之后 由于index 统计信息的错误 可能会导致SQL的执行计划变更 导致严重的系统故障。

这个时候我们可以通过2个办法来避免：

1.使用analyze。当使用analyze 的时候 你会发现 最后信息收集时间 这一列 是全部一致的。而dbms_stat 则不是。

2.收集的时候使用no_invalidate在收集的时候加上这一项参数。这样跟该表相关的SQL就不会失效。当全部收集完毕后 通过grant 或其他DDL 让其他的SQL重新解析。

 

ASM 拷贝数据文件办法：

1.建立XML DB。通过FTP 访问。http://space.itpub.net/34596/viewspace-660853

2.通过DBMS_FILE_TRANSFER.COPY_FILE

BEGIN
DBMS_FILE_TRANSFER.COPY_FILE(
source_directory_object => ’source_dir’,
source_file_name => ‘user01.dbf’,
destination_directory_object => ‘dest_dir’,
destination_file_name => ‘user01.dbf’);
END;

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/21818314/viewspace-694368/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/21818314/viewspace-694368/