关于sybase数据库的锁

核心提示：数据页和数据行加锁只对数据加锁机制支持两种方式：数据页加锁和数据行加锁，这些与它们的工作方式和所提供的功能相类似，关于sybase数据库的锁(2)，这两种方式仅在对数据访问产生阻碍作用时，在加锁的尺度上有所区别，通过将sp_configure number of pre-allocated extents设置为16也将

数据页和数据行加锁

只对数据加锁机制支持两种方式：数据页加锁和数据行加锁。这些与它们的工作方式和所提供的功能相类似。这两种方式仅在对数据访问产生阻碍作用时，在加锁的尺度上有所区别。在数据页加锁方式下再采用数据行加锁方式具有两种作用（一种起正向作用，另一种起反向作用）。首先，较小尺度加锁机制的使用可能导致减少争用与冲突，然而当大量数据发生变化时，就有可能对加锁产生大量阻碍的情况发生。

特定使用的加锁类型

除非对配置参数加以特定，对所有的表都予置了隐含的全页面加锁机制。

sp_configure ‘lock scheme’, [allpages | datapages | datarows]

当数据库从原先版本的服务器中转储出来重新加载时，所有的表都被定义为全页面加锁的表。当建立一个新表时，可以不使用这个缺省值，可采用如下的句法格式：

create table <tablename>… lock [allpages | datapages | datarows]

为了在使用的一个表中改变加锁类型，可以采用如下的句法格式：

alter table <tablename> lock [allpages | datapages | datarows]

在一个现存的表中改变加锁方式，将引起下列三种行动后果发生：

首先，如果一张表从全页加锁转变为仅对数据加锁，或者从仅对数据加锁转变为全页加锁，在这两种类型之间就要对表进行选择以允许进行存贮格式改变。如果这是一个分区表，就要同时假定必要的并行级别和工作线程已经配置好的情况下，才能执行。

其次, 对表中的群聚性索引必须重新创建。因为我们能保证数据，所以如果从全页加锁方式转换为只对数据加锁时，这种重新创建可以通过"with sorted_data"来完成。然而，当从仅对数据加锁机制转换为全页加锁方式时，就要进行并行的索引创建操作。（请注意：如果这是一个分区表时，那么并行等级和工作线程的数目必须加以配置才能允许进行这种改变，否则这种迁移将会失败）

最后，非群聚性的索引将被重建，如果服务器已经为并行处理所加以配置，当进行本步骤时将加以采用。

由于这些活动同潜在的工作量有关，从全页加锁机制改变为仅对数据加锁或从仅对数据加锁改变为全页加锁机制都可能是耗费时间的活动。为了标注这一点，有以下一些选择：

如果可能的话，应该配置使用并行方式。这至少对执行非群聚性索引的哈斯（杂凑，即hashed）创建方法是必须的，但是如果可能的话，采用分区表和分区扫描将使系统得到更大的改进。

在选择进入和创建群聚性的索引之后，该任务将被设置检查点（checkpointed ）所以，如果有充分的硬件资源，通过允许在任何一个时间点上，检查点任务可以具有多于10个（系统缺省值）的异步I/O请求，利用dbcc进行调谐将能够带来有益的效果。(‘maxwritedes’, number)

进一步作为降低使用检查点成本的一种方法，在相关的高速缓冲池（cache pool）、大数据量的I/O操作中，采用对高淘汰程度进行标记的方法，并允许清洁程序（好象家庭主妇一样）保持特别活跃的状态，将为那些检查点需要从高速缓冲池中刷新较“脏”的页面的而增加的I/O操作次数，并因此花费了在检查点上的时间，都能够大大减少作出贡献。

如果预先进行了配置，则可以对并行的选择进入可以使用预先分配的盘区。所以，通过将sp_configure number of pre-allocated extents设置为16也将对系统性能有明显的积极的效果。

备注：在仅对数据加锁类型之间进行改变不需要对数据进行备份， 而且执行起来只需很短的一段时间。