吐血大放送 RAC 性能调优

 

http://space.itpub.net/21818314/viewspace-694369

有了本章就可以跟SG的performance tuning说( ^_^ )/~~拜拜~\(≧▽≦)/~啦啦啦~~~~~

这篇文章一开始只是一个人记录 后来转给了朋友 于是变成了如下 有问有答的混合形式了。格式略乱 请见谅。

 

Gc current block 2-way:

 

1.Sga 1发送请求道SGA2 request block  SGA1产生gc current block request .

2.SGA2检查这个block是否被改变如果已被改变的话LMS  则会要求LGWR写redo log  （这时SGA1会显示busy） 然后传送。
3.SGA2发送NODE并产生Gc current block 2-way等待直到BLOCK发送到SGA1等待终结。
当发送NODE过程中对这个block的请求将会产生GC buffer busy.

 

3 way:就是多一个节点  resource MASTER和cached节点不是同一个节点。
 

Lost block :

可能跟OS和网络配置参数相关比如SIDE message比block先到。 减小multiblock read count到16以下可以避免发生这样的事情。
 

Enqueue Waits :

         Enqueue是序列化的
                 在RAC中是全局资源
                        大多数频繁的等待可能是HW TA SQ TX TM US

这并不是RAC专属但是当应用RAC的时候会出现全局资源锁。
SELECT*FROMgv$enqueue_statisticsWHEREeq_type='TX'这个视图可以检查各种资源争用的程度。
select*FROMgv$instance_cache_transfer可以知道block级的transfer。
 

 

v$segment_statistics是一个十分有效的用来确定哪个object CR争用特别多的视图。
 

--这些都是新知识，暂时先吸收，提不出什么问题，除了笔误，大哥，笔误误人子弟啊（尤其逻辑上，相反的话）
 

RAC相关的统计可以分类为：
全局cache service统计：gc cr blocks received ,gc cr block receive time etc..

全局队列service：global enqueue gets and so on.

Message sent：gcs messages sent我擦……我还不知道这是啥呢……
 

--这些也是新东西，不过，貌似白鳝的RAC书上专门列出了一些RAC统计，说的比较详细，可以参考参考
 

RAC调优Tips：
APPLICATION是最重要的.

重置调整buffer cache的大小（看起来意为缩小这样可以减少cache fusion {想起来还真惭愧当初上RAC的时候我还希望能调大cache size只是为了减少使用裸设备后缺失文件系统的影响}）
 --增加local缓冲区命中率，这样可以减少cache fusion.那不就该加大local buffer cashe?

--首先 如果两个节点数据交互频繁的话加大缓冲区意味着某个table可能在这两个节点中全部被cache住了，那么当对这个table进行操作的时候两个节点之间就会进行频繁的通信，减少buffercache可以减轻inter connect上的负担但是毋庸置疑会增加I/O的负担，（考虑一下吧interconnect上各种锁状态其实是比从硬盘拿数据时开销大的 但是速度快。）
小的block可以减少cache fusion。我啥时候说过小的block可以减少cache fushion了？
--不是我说你说的， 我是说小的block可以减少cache fusion，因为一个块装的数据少，这样就能降低在同一个BLOCK上的操作。
 

 

 

你的意思是要减少block的大小还是减少BUFFER CACHE里的buffer的的大小？？还是减少BUFFER CACHE SIZE?

--当然是buffer cache size了
--那就有问题了，到底加大不加大BUFER CACHE SIZE了？（RAC的BUFFER CACHE SIZE不就是指跟个实例的local buffersize?）
      不加大Local buffer的命中率的话，你就会去别的实例搞块。这样也会cache fusion

     加大local buffer的命中率的话，不就是加大local的BUFER CACHE SIZE？
 

我的意思是这样，如果你加大了命中率那么同时会增加去别的实例取的几率了吧？
如果你缩小了 那么会增大硬盘读的机会。
 

 “当初上RAC的时候我还希望能调大cache size只是为了减少使用裸设备后缺失文件系统的影响”这个是为什么？详细解释一下
n 是这样linux系统本身有自己的文件系统缓存 所以大部分情况下你看到Free  -g命令的返回结果都是free的内存不多（比如我们128G内存的机器SGA只设置了64G可是free往往只有10G左右）
n 这是因为LINUX会缓存你经常使用的文件在内存中。所以有的时候你从ORACLE中看到的physical read实际上是从文件系统的缓存中读取的并不是从物理硬盘中读取的因为linux替你做了缓存（说的有点复杂 能理解吧）
n 但是由于我们的RAC使用的是裸设备 而linux是无法缓存裸设备的 所以这个时候需要增大数据库的buffer cache来弥补缺失文件系统缓存的影响。

n 当然裸设备的I/O要比文件系统快得多
--了然
减少大的全表扫描（OLTP）
--这个对OLAP也有用吧？防止被基础local cache..

使用自动段空间管理（？？？？？）--这个可以理解为减少insert等dml的争用吧？比如INSERT,session会很快的找到合适的block.
如果你使用数据字典管理的段空间的话   数据字典被更新跟block被更新一样需要在两个节点间传递 你丫自己想想吧。
--这个我是在回答你的问题，“使用自动段空间管理（？？？？？）”,我以为你丫在问为什么要用自动段空间管理
自动段空间管理部分当时确实是问号哈没有时间细想今天状态好一想就通了。
 

 

谁给我个解释这句话怎么翻译(我的翻译是  ASSM可以使block尽量的粘黏实例)

ASSM  can provide instance affinity to table blocks.
n 这个我也没想通为什么。。得怎么理解。。
 

 

增加sequence cache

当sequence用作生成主键时，容易造成索引块的竞争。增大sequence的cache值，有利于减少索引块的竞争，提高leaf block的instance affinity

同时sequence在next的时候如果需要再次获取 则会修改数据字典 同时造成row cache lock.

oracle为了管理sequence使用了以下三种锁
*row cache lock：调用sequence.nextval过程中（nocache)
* SQ锁:调用sequence.nextval过程中（cache+noorder)
* SV锁（dfs lock handel)：RAC上节点之间顺序得到保障的的前提下，调用sequence.nextval期间拥有。赋予了cache + order属性的sequence上发生。(cache+order)

创建sequence赋予的cache值较小时，有enq:sq-contention等待增加的趋势。cache的默认缺省值是20.因此创建使用量多 的sequence时，cacheh值应取1000以上的较大值。偶尔一次性同时创建多个会话时，有时发生enq:sq-contention等待事件。 其理由是v$session.audsid列值是利用sequnce创建的，许多会话同时连接时，可以将sys.audses$sequence的cache大小扩大至1000，以此解决enq:sq-contention等待问题。
Rac上创建sequence时，在赋予了cache属性的状态下，若没有赋予order属性，则各节点将会把不同范围的sequence值cache到内存上。
--sequence虽说了解过，但是你说的还是很有新意，先吸收了。有些疑问，一个sequece放在哪？？，每个node用自己的sequece不就得了吗？如果非要争用的话（假设它在shared pool里--还是不明白，每个node不都是有自己的shared pool吗？），单单就影响索引吗？
 

Sequence的管理是在数据字典中的 所以同上道理。
--了然
在此处顺便讲解library cache and row cache

这两个东西是global级的东西 所以 如果过度解析的话 那么会增加interconnect的负担。比如说PL/SQL，AQ，recompile package的时候。
---每个实例都有shared pool吧？？这个东西如何在rac里面影响？？详细点
哥哥share pool里的数据字典内容都是共享的啊 。row cache就是数据字典的cache这个是需要两个节点必须同步的。
--能否举个具体例子来？
比如说你某个package对不两个节点都要用吧 ，pin在shared pool里 这个时候从NODE 2重编译了他，NODE需要同步哇！~

这个时候请顺便考虑 自生成主键（通过一张表记录高低位等方式）的话……这个block就……--这句话再详细点 自生成主键 是依赖于物理table的 频繁的通过更新这个表 来实现序列化
而且这个表很小 往往都是几个block 那你想一下吧……两个节点同时请求获取更新。
--了然
 

使用partition。（Hash partition可能会减少buffer busy并且将block分布的更均匀便于并发访问）
避免不必要的解析
减少锁的使用
 

减少没必要的索引（因为没必要的索引不但会增加block互相传递的负担还有索引leaf or brach block分裂所造成的等待）。
还有索引tree太深的话会对root block

--很新，很好，先记下
 

                                              

为了避免索引分裂，一个统一，不倾斜的索引结构将是很好的解决办法：
Global index partition

增加sequence cache大小。
（打个比方如果拿到的都是low value的话 会导致反复的修改一个索引的block所以……想想吧。）
--这个不明白好好解释解释
这个……我还是当面解释吧 太TM复杂了……你看看我的索引分裂偏你就了了
--待续
这个简单说一句就一句 假设一个索引的block可以放40条记录如果是number类型的可能还放个400来条。
默认的sequence是20个对吧
那么就是说  NODE 1拿到20 插入一个block

NODE 2拿到20-40

NODE 2拿到40-60

NODE 1拿到60-80

 

全部都插入一个block吧？
这个时候就要各种写redo各种传image吧？
了了吧？
 

 

Undo Block的思考：
 

当一个查询视图查看一个active transaction的block的时候恰好这个block中的内容有多个active的transaction比如说一个table的2行记录被2个instance修改了。 那么就会读取两个instance的undo来merge record。通常发生在更新和查询非常频繁的表上。
 

解决思路：
     短事物
     增大sequence来减少索引block的争用（一样的道理）
在RAC中远程undo的维护很痛苦。
--上面的问题解释好了这个我就能懂了吧？（跟sequece XXX，什么一样的道理？）对
HW - contention：
一般都是插入多了然后找空闲空间的时候就发生这个：
Enq :HW – contention

Gc current grant

前面的不用解释了就是扩展段 后面的是就是扩展出来的新块被这个操作需求的时候发生的lock（这个很少会发生争用毕竟2个insert不会需求相同的块）。
 

--什么事扩展出来的新块？解释解释这个现象
这个就是说一旦扩展一个extent里面有8个块 有对这8个新块并发的请求需要 所以产生等待 这个是基本见不到的……
--再详细点,八个新块各用各的怎么就会征用？
这个我也说不好脑袋里有一点点感觉你无视了吧要么你就帮我解释detail了……

 

问题不多了，在这里问。
 

CACHE FUSION优化方面，不谈应用级别的。
 

谈系统级的优化，不修改应用。
 

1如何优化？
 rmem_max and wmem_max should be increased beyond 256kb

net.core.rmem_default=262144
net.core.rmem_max=for 11g: 4194304 ... For 10g: 2097152
net.core.wmem_default=262144
net.core.wmem_max=1048576

 _default 确定 socket 在创建的时候分配多少内存给她

 _max每个socket 最大消耗内存

2就命中率来说，减少data buffer size就一定能减少cache fusion吗？
 这个光就命中率来讲不好说，但是减少 databuffer size 确实可减少网络通信 但增加I/O消耗。

3另外还有一个问题，怎么减少data buffer size?设置较小的sga_target的值？这样一定会减少DATA BUFFER SIZE吗？？其他的POOL不也减少了？
 有cache size.....