Sybase数据库技术,数据库恢复

 

随着Sybase被完全整合到SAP下，Sybase原来的支持网站被SAP Support Portal取代。
只有购买了SAP服务的用户才能使用账号登录SAP Support Portal进行介质下载、补丁升级、报Incident等。
目前，原Sybase所有产品（包括：Adaptive Server Enterprise、Sybase IQ、Replication Server、PowerDesigner等）的官方手册仍然可以从https://infocenter.sybase.com/help/index.jsp进行浏览或下载。暂不清楚该网站https://infocenter.sybase.com/help/index.jsp何时会被完全迁移到SAP Support上！
Sybase官方手册英文版有html和pdf两种格式，而中文版手册只有pdf一种格式。为了国内Sybase用户更方便、快捷地搜索Sybase常见产品的官方手册内容，特将中文版Sybase官方手册转为html格式！
Sybase产品官方手册中文版的html格式所有内容的版权归SAP公司所有！本博客站长是Sybase数据库的铁杆粉丝！

如有Sybase数据库技术问题需要咨询，请联系我！

  QQ :289965371
  Email:

以下官方手册为ASE 15.7 ESD#2中文版：

1. 新增功能公告 适用于 Windows、Linux 和 UNIX 的 Open Server 15.7 和 SDK 15.7
   
2. 新增功能摘要
   
3. 新增功能指南
   
4. ASE 15.7 发行公告
   
5. 配置指南（windows）
   
6. 安装指南（windows）
   
7. 参考手册：构件块
   
8. 参考手册：命令
   
9. 参考手册：过程
   
10. 参考手册：表
    
11. Transact-SQL® 用户指南
    
12. 系统管理指南，卷 1
    
13. 系统管理指南，卷 2
    
14. 性能和调优系列：基础知识
    
15. 性能和调优系列：锁定和并发控制
    
16. 性能和调优系列：监控表
    
17. 性能和调优系列：物理数据库调优
    
18. 性能和调优系列：查询处理和抽象计划
    
19. 性能和调优系列：使用 sp_sysmon 监控 Adaptive Server
    
20. 性能和调优系列：利用统计分析改进性能
    
21. 程序员参考 jConnect for JDBC 7.0.7
    
22. Adaptive Server Enterprise 中的 Java
    
23. 组件集成服务用户指南
    
24. Ribo 用户指南
    
25. 内存数据库用户指南
    
26. Sybase Control Center for Adaptive Server® Enterprise
    
27. 安全性管理指南
    
28. 实用程序指南
    

 

< 上一个 | 内容 | 下一步 >

死锁和并发 ‌ ‌

按规定，当两个用户进程各自拥有单独的数据页锁、索引页锁、行锁或 表锁且都要获取由其它进程锁定的页锁、行锁或表锁时，便发生死锁。 出现此情况时，第一个进程等待第二个进程释放锁，而第二个进程在第 一个进程释放持有的锁之前，不会释放锁。

服务器方与应用程序方死锁 ‌

当 Adaptive Server 中的任务死锁后，死锁检测机制会回退一个事务，并 且向用户和 Adaptive Server 错误日志发送消息。有时，当一个客户端打 开多个连接，并且这些客户端连接等待由同一应用程序中的其它连接持 有的锁时，会引起应用程序方死锁。这些不是真正的服务器方死锁并且 不能由 Adaptive Server 死锁检测机制检测到。

应用程序死锁示例

一些开发人员使用两个或更多来自 DB-Library™ 的连接模拟游标。一个 连接执行 select 操作，另一个连接在同一表上执行更新或删除操作。这 样可产生应用程序死锁。例如：

• 连接 A 持有页的共享锁。只要存在 Adaptive Server 中待执行的行， 共享锁就一直保持在当前页。

• 连接 B 请求同一页的排它锁，然后等待。

• 应用程序在调用撤除共享锁所需的任何逻辑之前，会等待连接 B 的 成功完成。而这永远不会发生。

因为连接 A 从未请求连接 B 持有的锁，所以这不是服务器方死锁。

服务器任务死锁

下面是两个进程间死锁的一个示例。

begin transaction

update savings

set balance = balance - 250 where acct_number = 25

update checking

set balance = balance + 250 where acct_number = 45

commit transaction

T19 和 T20 开始。

T19 获得 savings 的排 它锁而 T20 获得 checking 的排它锁。

T19 等待 T20 释放锁 而 T20 等待 T19 释放 锁；发生死锁。

begin transaction

update checking

set balance = balance - 75 where acct_number = 45

update savings

set balance = balance + 75 where acct_number = 25

commit transaction

如果事务 T19 和 T20 同时执行，且两个事务都使用其初始 update 语句获 取排它锁，则它们发生死锁，等待彼此释放各自的锁，而这是永远不会 实现的。

Adaptive Server 检查是否存在死锁并牺牲事务累计 CPU 时间较少的用户。

Adaptive Server 将回退该用户的事务，以消息号 1205 通知该操作的应用 程序并允许另一个进程继续执行。

上例显示了发生死锁的两个数据修改语句；在一个持有并需要共享锁的 进程和一个持有并需要排它锁的进程之间也会发生死锁。

多用户情况下，如果有任何发生死锁的可能，每个应用程序都应对修改 数据的每项事务进行检查，看是否存在消息 1205。消息 1205 表明用户 事务已被选择为死锁的牺牲品并被回退。应用程序必须重新启动该事务。

死锁和并行查询

工作进程只能获取共享锁，但它们仍可能与要获取排它锁的进程共同陷 入死锁状态。它们持有的锁符合以下条件中的一个或多个：

• 作为并行查询的一部分，协调进程持有一个表锁。 作为事务中先前查询的一部分，协调进程可能持有其它表的排它锁。

• 并行查询以事务隔离级别 3 或使用 holdlock 运行并持有锁。

• 当另一个进程对事务内的同一表执行一系列更新操作时，并行查询 正在连接两个或多个表。

单个工作进程也可能陷入死锁，如两个串行进程间发生的工作进程。例 如，正在执行连接的工作进程可与正在更新同样的两个表的串行进程发 生死锁。

某些情况下，串行进程和系列间还可能发生间接级别的死锁。

例如，如果一个任务持有 tableA 的排它锁并需要 tableB 的一个锁，但一 个工作进程持有 tableB 的系列持续锁，则在涉及工作进程的事务结束前， 该任务必须等待。

如果相同系列的另一个工作进程需要 tableA 的锁，结果发生死锁。 图 3-1

说明了如下死锁情况：

• 由 fid 8 标识的系列正在以事务级别 3 进行并行查询，其中涉及

stock_tbl 和 sales_tbl 的连接。

• 在某事务中，由 spid 17 (T17) 标识的串行任务正在执行对 stock_tbl

和 sales_tbl 的插入操作。

以下是导致死锁的步骤：

• W8 9 （使用 fid 8 和 spid 9 的工作进程）持有 stock_tbl 中页 10862 的 共享锁。

• T17 持有 sales_tbl 中页 634 的排它锁。T17 需要页 10862 的排它锁， 它只能在 W8 9 释放其共享锁后才能获得所需的锁。

• 工作进程 W8 10 需要页 634 的共享锁，而它只能在 T17 释放其排它 锁后才能获得所需的锁。

图 3-1：涉及工作进程系列的死锁

T1 7

排它页锁

stock_tbl

第 10862 页

sales_tbl

第 634 页

共享页锁

（级别 3）

共享意图锁

W8 9

W8 10

工作进程

工作进程

图例：

持有锁方 需要锁方

将死锁信息输出到错误日志中

Adaptive Server 检测到应用程序的服务器方死锁，并将其报告给服务器 的错误日志。发送给应用程序的错误消息是错误 1205。

要获取有关发生死锁的任务的信息，请将 print deadlock information 配置 参数设置为 1。此设置将更加详细的死锁消息发送至日志及服务器启动 的终端会话。

缺省情况下，发送给错误日志的消息仅用于指示已发生死锁。消息号表 明自从服务器上次启动以来的死锁数目。

03:00000:00029:1999/03/15 13:16:38.19 server Deadlock Id 11 detected

在此输出中， fid 0、 spid 29 启动了死锁检测检查，因此它的 fid 和 spid

值用作死锁消息中的第二个和第三个值。（第一个值 03 是引擎号。）

然而，将 print deadlock information 设置为 1 会降低 Adaptive Server 的性 能。因此，仅将它用于确定死锁起因。

禁用 print deadlock information （将其设置为 0）意味着 Adaptive Server 不 向错误日志发送任何有关死锁的信息。

死锁消息包含详细信息，包括：

• 任务涉及的系列和服务器进程 ID

• 死锁涉及的命令和表；如果涉及存储过程，则显示过程名

• 每一任务持有的锁类型及每一任务试图获取的锁类型

• 服务器登录 ID （suid 值）

在如下报告中， spid 29 与并行任务 fid 94、 spid 38 发生死锁。死锁是由 于对 authors 表的排它锁和共享锁请求而引起的。 spid 29 被选择为死锁 的牺牲品：

Deadlock Id 11: detected. 1 deadlock chain(s) involved.

Deadlock Id 11: Process (Familyid 94, 38) (suid 62) was executing a SELECT command at line 1. SQL Text select * from authors where au_id like '172%' Deadlock Id 11: Process (Familyid 29, 29) (suid 56) was executing a INSERT command at line 1

SQL Text: insert authors (au_id, au_fname, au_lname) values (’A999999816’, ’Bill’, ’Dewart’)

Deadlock Id 11: Process (Familyid 0, Spid 29) was waiting for a ’exclusive page’ lock on page 1155 of the ’authors’ table in database 8 but process (Familyid 94, Spid 38) already held a ’shared page’ lock on it.

Deadlock Id 11: Process (Familyid 94, Spid 38) was waiting for a ’shared page’ lock on page 2336 of the ’authors’ table in database 8 but process (Familyid 29, Spid 29) already held a ’exclusive page’ lock on it.

Deadlock Id 11: Process (Familyid 0, 29) was chosen as the victim. End of deadlock information.

避免死锁

同一数据库中许多长时间运行的事务同时执行的情况下可能发生死锁。 当事务之间能减少并发情况的锁争用增加时，死锁会更加频繁地发生。

在 第 2 章 “锁定配置和调优”中描述了降低锁争用的方法，如更改锁 定方案、避免表锁及不持有共享锁。

以相同顺序获取对象锁

设计合理的应用程序能始终以相同的顺序获取锁，从而最大限度避免死 锁。对多个表的更新应始终以相同顺序执行。

例如，在 图 3-1 中描述的事务本可以通过首先在两个事务中更新 savings 或 checking 表来避免死锁。这样，一个事务首先获得排它锁并继续处理， 而另一个事务则等待在第一个事务结束时接收同一表的排它锁。

在使用大量表的应用程序和更新几个表的事务中，应确定一个由所有应 用程序开发人员共享的锁定顺序。

延迟死锁检查

Adaptive Server 会在任何进程等待锁被释放 （休眠）的一段最短时间后， 进行死锁检查。对于等待中但并未发生死锁的应用程序来说，死锁检查 是一项费时的开销。

如果应用程序死锁不频繁， Adaptive Server 可延迟死锁检查并降低开销。 使用 deadlock checking period 配置参数可指定开始死锁检查之前进程必须 等待的最短时间 （以毫秒计）。

有效值为 0 – 2147483。缺省值为 500。 deadlock checking period 是动态配 置值，因此对它的任何更改将立即生效。

如果将该值设为 0，则进程开始等待锁时 Adaptive Server 就开始进行死 锁检查。如果将值设为 600，则 Adaptive Server 至少在 600 毫秒后启动 对等待进程的死锁检查。例如：

sp_configure "deadlock checking period", 600

将 deadlock checking period 设置为较大值会使检测死锁前的延迟时间更 长。但是，因为在这段时间过去之前 Adaptive Server 会同意大多数锁请 求，所以可以避免对这些锁请求进行死锁检查。

Adaptive Server 以固定时间间隔为所有进程执行死锁检查，此间隔由 deadlock checking period 确定。如果 Adaptive Server 在某进程的死锁检查 被延迟时执行死锁检查，则该进程的死锁检查将等待至下一间隔进行。

因此，某个进程可能等待由 deadlock checking period 设置的较长时间 （以 毫秒计），几乎是执行死锁检查前的两倍。 sp_sysmon 有助于调优死锁 检查行为。

请参见 Performance and Tuning Series: Monitoring Adaptive Server with sp_sysmon （《性能和调优系列：使用 sp_sysmon 监控 Adaptive Server》） 中的 “Deadlock detection”（死锁检测）。

< 上一个 | 内容 | 下一步 >