Sql优化(七)：程序的可扩展性----insert进程产生的争用

应用设计不合理导致的session之间的互锁(enqueue)是影响程序可扩展性最常见的原因。此外，一些共享资源的争用，也会导致性能下降。本篇介绍两个由并发insert操作导致的等待事件(wait event)，以及如何通过优化物理设计来进行改善。

普通Insert操作本身产生的是行锁，因此进程相互之间不会锁住(enqueue)，但当很多进程insert同一张表时，会有资源上冲突。以下是两个例子：

[@more@]

1. Buffer busy wait
批量进程insert test_table表，当进程多时（超过100个）速度明显下降。在awr报告中看到（等待事件占了93%,cpu占0.95%。也就是说全都在等了，没人在干活…）

进一步查到等待的object是PK_TEST_TABLE,是test_table表的主键。
Test_table表上建了hash分区（16），而PK_TEST_TABLE却没有建分区，导致修改同一index block，这会导致TX-index contention和buffer busy waits
重建pk_test_table为hash分区索引后buffer busy waits和enq:TX-index contention就不在top events里了。

2. 很多进程insert,报ora-00060 Dead lock错误
insert/update/delete操作时，虽然是行封锁，但进程会在修改的block上占一个slot，当修改同一block的进程数量超过initrans时，可能导致60错误。见下文
Its possible to get an ora-60 deadlock when more than one transaction does DML on a block if INITRANS was set too low. If there are more simultaneous transactions than slots then the transaction layer needs to grow from INITRANS towards MAXTRANS, but it can't if the rest of the block is packed with data. In this case the transaction that could not get a slot will either hang or get an ora-60 depending on the particular circumstances. This is an issue with tables, indexes, and clusters.
以上两种性能问题可以table/index的物理设计优化来解决。有几种方法：
1)建表时将表、索引的initrans值设大
2)将表、索引建成hash分区，降低单个block上的冲突
3)将索引建成反向索引。由于很多主键使用sequence的值，因此insert都是按sequence值排序的，insert时会在索引的同一block上产生冲突。使用反向键索引可以消除这一问题。有兴趣的可以在google上查相关概念。

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

转载于:http://blog.itpub.net/18474/viewspace-1060737/