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 cachelatch ：比CPU_COUNT 高的一个素数。 这篇文章遇到的了在pin 和unpin 上的等待，于是老白考虑到了 是由于 latch 数目过少而导致的ｌａｔｃｈ 争用。
同时老白考虑还有一个关于如果提升了ｌａｔｃｈ 数目会提升shared pool的处理能力 导致增加shared pool负载的问题， 于是增加了1G的sharedpool。
gcs drm freeze
在RAC 中 block的master 是一个range的形式，比如block 1-block 128 node1129-256 node 2.
分配的形式是通过hash 算过去的，而range的话 在10G上一般是128block，oracle support 建议你Unsetdb_file_multiblock_read_count 这样机会自动调整到128 ，于是每次整个block range 都可以通过少量的GCmessage 进行读取。
10G中通过HASH 分配NODE的算法已经改良 ，当一个NODE OFFLINE 的时候只会remaster offline的NODE。
下面的SQL 可以得到objectblock 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 queueTransfer pkey 6589904 to node 2
dbms_stat
我们都试过dbms_stat.gather_table_statscascade=>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;
[ 本帖最后由 flying_warrior 于 2011-5-4 11:21 编辑 ] |
