中山大学数据库系统与技术（1）课件事务处理调优.pptVIP

数 据 库 锁 优 化 汤 娜 中山大学计算机科学系 isstn@mail.sysu.edu.cn . 一般考虑事务性能时有几点： 锁的类型 读锁对性能更有利 事务使用锁的个数 在所有相同条件下，锁个数越少，性能越好 事务持有锁的时间长短 持有的时间越短，性能越好 锁的粒度 降低死锁和阻塞带来的锁超时 锁调优的一些建议（锁的类型） 使用特殊的系统程序来处理长的读操作 某些关系数据库，如oracle，sql server2005可以对只读的事务不持有任何锁，却可以和一些较小的事务并行处理。 锁调优的一些建议（锁的个数） 消除不必要的锁 能够减少系统开销（包括管理锁的内存开销和执行锁的处理器开销） 有两种情况，锁不是必要的 只有一个事务执行时，如加载数据库时 所有事务都是只读事务，如在归档数据库上执行决策支持查询 在事务中尽量使访问的数据量最小。这样可以减少锁定的行数，从而减少事务之间的争夺。也可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。 生成查询时对通配符进行控制，强制某些输入字段，不允许特殊查询，以及使用 TOP、PERCENT 等 Transact-SQL 语句限制查询返回的行数。 灵活地使用更低的游标并发选项，如乐观并发选项。在很少有可能并发更新的系统中，处理某个偶然的“别人在您读取数据后更改了该数据”错误的开销，要比在读取数据时始终锁定行的开销小得多。 锁调优的一些建议（锁的时间） 事务的长度对性能的影响： 要求的锁越多，则需要等待其他事务释放某个锁的可能性越大 事务T执行的时间越长，被T阻塞的的事务等待的时间可能就越长 事务尽量短。 根据事务的内容，将事务切分成更小的事务,并且每个事务在一个批处理中。 事务要求的锁越多，他需要等待其他事务释放某个锁的可能性就越大 事务执行的时间越长，被此事务阻塞的事务等待的时间就可能越长 对于insert,update,delete语句，尽量在靠近事务结束的位置提交这些语句。 预定飞机票的例子 避免事务中的用户交互 航空公司的订票例子 1.返回某个指定航班未售出的座位列表 2.选择顾客需要的座位 3.售出这个座位的机票 在浏览数据时，尽量不要打开事务。 在所有预备的数据分析完成之前，不应启动事务。 在应用程序允许的情况下，适当降低隔离级别 讨论：银行目前的业务只有转帐和不断统计所有帐户的余额，统计过程中要做验证，请问适合什么隔离级别 锁调优的一些建议（锁的粒度） 选择适当的封锁粒度 默认情况是记录级封锁，一般记录级封锁好 并不是所有情况下行级封锁比表级封锁好 长事务（访问表内几乎所有页面的事务）应该尽量采用表级封锁来防止死锁和阻塞。 在没有并发时候能够减少封锁开销 许多DBMs产品都提供了一条LOCK TABLE工命令。可以通过提交该命令在一个单一的执行过程中覆盖数据库对象的当前锁粒度。 DBA必须对每一数据库对象分析应用程序的处理需求从而确定最优的锁粒度 通过索引来帮助找到必要的数据（当出现blocking时，需要检查索引是否需要够用，有效性-是否过时，索引是否需要重建） 锁升级 sql server /DB2系统提供自动锁升级 oracle不提供：因为升级的时候容易造成死锁的现象 如果锁的个数超过了某个阀值，系统自动会将行级封锁升级为表级封锁，所以一般采用默认的就可以了，通常情况下应该将值设得够高 如果锁表太小，即使全部是短事务，系统也有可能会被迫锁升级 三种调优手段 显式地控制封锁粒度 事务内部:（oracle，db2，sql server） 跨事务:（sql server）给表定义封锁粒度 设置锁升级的参数（锁数量的阀值） 锁表的大小 锁调优的一些建议（死锁和锁超时） DBMS的加锁机制通过超时机制避免了进程为等待某个锁被释放而永远等待下去（代码中没有关闭事务）。每一种DBMS都提供一个参数用于设置锁超时的值。取决于具体的DBMS，锁超时的值既可以在DBMS级进行设置，也可以在进程级或连接级进行设置。 通常对于程序来说，在接收到一个锁超时错误后再重新尝试某操作是个很好的办法。而如果在相同的操作过程中出现了多次锁超时，程序就应该记录这些问题并通知用户不能再继续进行操作了。 锁调优的一些建议（死锁和锁超时） 死锁监测周期的调优 如锁超时一样，对于程序来说，在接受到一个死锁错误后再重新尝试某操作是个很好的办法。而如果在相同的操作过程中出现了多次死锁，程序就应该记录这些问题并通知用户不能冉继续进行操作，而且可能需要对应用程序或数据体设计进行某些修收。 可以指定死锁后回滚的牺牲者，让不重要的事务放弃。 锁调优的一些建议（死锁和锁超时） 可供选择的技术： 修改应用程序，可能要重写程序以便在事务的开始时就对所需的