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. 实用程序指南
    

 

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

使用一致性检查命令的策略 ‌ ‌

以下各部分比较了各个 dbcc 命令的性能，提出了合理安排的建议和 避免遭受严重性能影响的策略，并提供了有关 dbcc 输出的信息。

表 11-2 比较了 dbcc 命令。请注意：dbcc checkdb、dbcc checktable 和 dbcc checkcatalog 执行的完整性检查的类型与 dbcc checkalloc、dbcc tablealloc 和 dbcc indexalloc 不同。dbcc checkstorage 综合执行其它命 令执行的某些检查。 第 230 页的表 11-1 中显示了各种命令执行的 检查。

表 11-2：dbcc 各种命令的性能比较

使用大 I/O 和异步预取

如果为要检查的数据库或对象使用的高速缓存配置了大 I/O 和异步 预取，则某些 dbcc 命令可以使用它们。

当表使用配置了大 I/O 的高速缓存时，dbcc checkdb 和 dbcc checktable 将在对表进行页链检查时使用大 I/O 缓冲池。将使用最大的可用 I/O 大小。检查索引时，dbcc 仅使用 2K 缓冲区。

如果使用中的缓冲池可使用异步预取，则 dbcc checkdb、dbcc checktable 和 dbcc 分配检查命令 checkalloc、tablealloc 和 indexalloc 将 使用异步预取。请参见《性能和调优系列：查询处理和抽象计划》 第 6 章“调优异步预取”中的“为 dbcc 设置限制”。

高速缓存绑定命令和更改缓冲池的大小和异步预取百分比的命令都 是动态命令。在非高峰期间使用这些 dbcc 命令时，如果对用户应用 程序影响甚微，则可以更改这些设置来加速 dbcc 的执行，并在 dbcc 检查完毕时恢复正常设置。请参见 第 4 章“配置数据高速缓存”。

在您的节点安排数据库维护 ‌

有多个因素可确定应该运行 dbcc 命令的频率及要运行哪些命令。

数据库使用

如果主要在星期一到星期五的上午 8:00 到下午 5:00 之间使用 Adaptive Server，则可以在晚上和周末运行 dbcc 检查，这样检查就不会对用 户造成太大影响。如果表不是非常大，则可以经常运行一整套的 dbcc 命令。

dbcc checkstorage 和 dbcc checkcatalog 能够以最低的成本在最大范围 内执行检查，并确保从备份中恢复。不必很频繁地运行用于检查索 引排序顺序和一致性的 dbcc checkdb 或 dbcc checktable。不必在此检 查与任何其它的数据库维护活动之间进行协调。保留对象级的 dbcc 检查和使用 fix 选项的那些检查，以对 dbcc checkstorage 发现的故障 进行进一步诊断和修复。

如果每周 7 天，每天 24 小时地使用 Adaptive Server，则可能需要通 过限制工作进程数或通过使用应用程序队列来限制 dbcc checkstorage 对资源的使用。如果决定不使用 dbcc checkstorage，则可能要调度 使用 dbcc checktable、dbcc tablealloc 和 dbcc indexalloc 对单个表和索 引执行的一整套检查。整套检查结束时，如果所有表都已检查完毕， 则可运行 dbcc checkcatalog ，并备份数据库。请参见《性能和调优 系列：基础知识》中的第 5 章“分配引擎资源”。

某些 24 小时都需运行而且要求高性能的节点通过以下方式运行 dbcc

检查：

• 将数据库转储到磁带

• 将数据库转储装载到单独的 Adaptive Server 中以创建数据库副本

• 在数据库副本上运行 dbcc 命令

• 如果检测到可以使用 fix 选项修复的错误，则在原始数据库中的 相应对象上运行带有 fix 选项的 dbcc 命令。

转储是数据库页的逻辑副本；因此，原始数据库中发现的问题也会 出现在数据库副本中。使用转储创建用于报告或其它目的的数据库 副本时，此策略常有用。

合理安排锁定对象的 dbcc 命令的运行时间，以避免与业务活动冲突。 例如，dbcc checkdb 获取执行数据库检查的每个表的锁，然后在完 成时释放该锁并继续处理下一个表。dbcc checkdb 持有锁期间，这 些表不可访问。不要安排 dbcc checkdb（或其它具有类似副作用的 dbcc 命令）在其它业务活动需要锁定的表时运行。

备份日程表

备份数据库和转储事务日志的次数越频繁，发生故障时可恢复的数 据就越多。必须决定在灾难发生时允许丢失的数据量，并制定一个 转储日程表来支此决定。

调度转储后，应决定如何将 dbcc 命令并入该日程表中。每次转储之 前，不必执行 dbcc 检查；但是，如果转储过程中出现损坏情况，则 可能会丢失其它数据。

转储数据库的理想时间是在使用 dbcc checkstorage 和 dbcc checkcatalog 对该数据库进行彻底检查之后。如果这些命令在数据库中没有发现 错误，即表明备份的是一个清洁的数据库。可以重建索引来改正装 载转储后发生的问题。在单个表和索引上使用 dbcc tablealloc 或 indexalloc 改正 dbcc checkalloc 报告的分配错误。

表大小和数据重要性

回答以下有关数据的问题：

• 有多少个表包含至关重要的数据？

• 数据更改的频率如何？

• 这些表有多大？

dbcc checkstorage 是数据库级别的操作。如果仅有少数几个表包含 关键数据或经常更改的数据，则您可能希望在这些表上更频繁地运 行表和索引级别的 dbcc 命令比在整个数据库上运行 dbcc checkstorage 更有效。

数据库一致性问题导致的错误

执行 dbcc checkstorage 时遇到的数据库一致性问题所生成的错误记 录在 dbcc_types 表中。大多数错误号介于 5010 - 5024 和 100,000 -

100,038 之间。有关特定错误的信息，请参见《参考手册：表》中 的第 2 章“dbccdb 表”。

执行除 dbcc checkstorage 之外的 dbcc 命令时，对于因数据库一致性 问题而生成的错误，其错误号一般在 2500 - 2599 或 7900 - 7999 之间。 这些消息和其它因数据库一致性问题而产生的消息（如错误 605） 可能包含像“Table Corrupt”或“Extent not within segment”这样的 短语。

某些消息指明存在严重的数据库一致性问题；其它消息可能不是如 此急迫。少数故障可能需要 Sybase 技术支持部门的帮助，但大多数 可通过以下方式决：

• 运行使用 fix 选项的 dbcc 命令

• 按照《错误消息和故障排除指南》中的说明操作，其中包含处 理很多 dbcc 数据库错误的分步说明。

无论解决问题需要何种技术，如果在损坏或不一致性发生后很快发 现了问题，则解决方案会简单得多。一致性问题可能存在于不经常 使用的数据页上如每月仅更新一次的表。dbcc 可以发现这些问题， 往往也能修正这些问题。

报告被中止的 checkstorage 和 checkverify 操作‌

当 checkstorage 或 checkverify 操作中止时，就会输出一条消息，其中 包括操作 ID ( opid ) 和操作中止时正在检查的数据库的名称。已中止 的 checkverify 操作还会在消息中提供一个序列号，指示用户与提供 的 dbname、opid 以及该序列号 seq（如果是 checkverify 操作）一起运 行 sp_dbcc_patch_finishtime。在执行 sp_dbcc_patch_finishtime 后， 可以创建有关已中止的操作的故障报告。

因错误 100032 中止

checkstorage 在遇到页链接错误 (100032) 时可能会中止对象检查。

如果页的更新版本消除了页链接错误，或者页链接错误数少于配置 的最大链接错误值，checkstorage 会继续检验对象。

可以使用 sp_dbcc_updateconfig 配置最大链接错误值。下例将

great_big_db 配置为值 8：

sp_dbcc_updateconfig great_big_db, "linkage error abort", "8"

请参见《参考手册：构件块》中的第 4 章“dbcc 存储过程”。

如果出现以下情况，则 checkstorage 可能会在达到此页链接错误值 之前中止检查：

• 对使用 APL 索引的对象的并发更新会破坏页链接，因为

checkstorage 可能无法访问页链的剩余部分

• 在页链接检查期间删除了索引

在无提示状态下运行 checkstorage 时，应减少（或消除）导致索引 检查中止的暂时性错误。为了消除暂时性故障，请在运行 dbcc checkstorage 后立即运行 checkverify。

软故障和硬故障的比较

dbcc checkstorage 发现目标数据库中的故障时，将把故障作为一个软 故障或硬故障记录在 dbcc_faults 表中。

软故障

软故障是 Adaptive Server 中通常不会持久存在的不一致性问题。大 多数软故障均来源于目标数据库中的暂时不一致性，这是在运行 dbcc checkstorage 期间或 dbcc checkstorage 遇到数据定义语言 (DDL) 命令时，由于用户对数据库进行更新所导致的。第二次运行命令时， 这些故障不会重复出现。通过比较两次执行 dbcc checkstorage 的结 果，或在 dbcc checkstorage 发现软故障后，通过运行 dbcc tablealloc 和 dbcc checktable，可以重新分类软故障。

如果在几次连续执行 dbcc checkstorage 时都出现了相同的软故障， 则它们是“持久的”软故障，而且可能表明有损坏。如果以单用户 模式执行 dbcc checkstorage，则报告的软故障是持久性的。通过使用 sp_dbcc_differentialreport 或通过运行 dbcc tablealloc 和 dbcc checktable， 可以解决这些故障。如果使用后面的两个命令，则只需检查出现软 故障的表或索引。

硬故障

硬故障是 Adaptive Server 的持久性损坏，这种损坏无法通过重新启 动 Adaptive Server 得到修复。并非所有硬故障的严重程度都相同。 例如，下面的每种情况都导致了硬故障，但结果并不同：

• 分配给不存在的表的页面最低限度地减少了可用磁盘存储空间。

• 具有不能扫描的行的表可能会返回错误结果。

• 链接到另一表的表导致查询停止。

某些硬故障可通过简单操作（例如截断受影响的表）加以改正。其 它的只能通过从备份恢复数据库才能得到改正。

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