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

 

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

截断日志 ‌ ‌

本节介绍了有关截断日志的问题。

截断不在单独的段上的日志

如果数据库的日志段不在独立于数据段的设备上，则无法先使用

dump transaction 复制日志，然后再将其截断。相反：

1 使用 dump transaction 的特殊的 with truncate_only 选项截断日志， 以便它不会用尽空间。因为它不复制任何数据，所以使用 truncate_only 仅要求数据库的名称。

2 使用 dump database 复制整个数据库（包括日志）。

此示例转储数据库 mydb（该数据库的日志段不在独立于数据段的设 备上），之后会截断日志：

dump database mydb to mydevice

dump transaction mydb with truncate_only

在开发环境的早期截断日志 ‌

在早期开发环境中，通过创建、删除和重新创建存储过程和触发器 以及检查完整性约束来快速填充事务日志。与确保在数据库设备上 有足够的空间相，数据恢复的重要性可能较低。

使用 with truncate_only，可以在不创建备份副本的情况下截断事务 日志：

dump transaction database_name with truncate_only

运行 dump transaction with truncate_only 之后，必须先转储数据库，然 后才可以运行例行日志转储。

截断没有可用空间的日志 ‌

在事务日志非常满时，您可能无法使用常规方法来转储它。如果使 用了 dump transaction 或 dump transaction with truncate_only，并且该命 令由于日志空间不足而失败，请使用 dump transaction 的 with no_log 选项：

dump transaction database_name with no_log

此选项截断日志，而不记录转储事务事件。因为此选项不复制任何 数据，所以它只要求数据库的名称。

警告！应该将 dump transaction with no_log 用作最后手段，并且在 dump transaction with truncate_only 失败后只使用它一次。如果在输入 dump transaction with no_log 后继续装载数据，日志可能会被完全填 满，从而导致随后的任何 dump transaction 命令失败。应使用 alter database 命令为数据库分配额外的空间。

每次使用 dump tran with no_log 都会在 Adaptive Server 错误日志中报 告。此外，也会将指示成功或失败的消息发送到错误日志中。 no_log 是唯一生成错误日志消息的转储选项。

使用 with truncate_only 和 with no_log 的风险

with truncate_only 和 with no_log 允许您截断可用空间极其不足的日志。 这两个选项都无法恢复自上次例行转储后已提交的事务。

警告！尽早运行 dump database 以确保数据可以恢复。

此示例先截断 mydb 的事务日志，然后再转储数据库：

dump transaction mydb with no_log

dump database mydb to ...

提供足够的日志空间

每次使用 dump transaction...with no_log 都被认为是一种错误并记录在 服务器的错误日志中。如果先使用不同于数据段的设备上的日志段 创建数据库，编写最后一个机会阈值过程来足够频繁地转储事务日 志，然后为日志和数据库分配足够的空间，则不必使用此选项。

但是，某些情况仍可能导致事务日志变得过满，即使使用频繁日志 转储也不能缓解。dump transaction 命令通过删除从日志开头到包含 未提交的事务记录（通称为最早的活动事务）页的前一页之间的所 有页来截断日志。由于 dump transaction 不能截断其它页，因此活动 事务未提交的持续时间越长，事务日志中的可用空间就越小。

在具有非常长的事务的应用程序修改具有较小事务日志的数据库中 的表时可能发生上述情况，这表明您应该增加日志的大小。当事务 长时间保持未提状态时（例如，当隐式 begin transaction 使用链式事 务模式时，或者当用户忘记完成事务时），也会发生这种情况。您 可以通过查询 syslogshold 系统表来在每个数据库中确定最旧的活动 事务。

syslogshold 表

master 数据库中的 syslogshold 表。表中的每行都表示：

• 数据库中最早的活动事务，或

• 数据库日志的 Replication Server 截断点。

数据库在 syslogshold 中可能没有行、具有一个代表上述一项的行， 或者具有两个代表上述两项的行。有关 Replication Server 截断点如 何影响截断数据库事务日志的信息，请见 Replication Server 文档。

查询 syslogshold 可提供每个数据库中当前状况的快照。由于大多数 事务都仅持续短暂的时间，因此查询的结果可能不一致。例如， syslogshold 的第一行中描述的最早活动事务可能会在 Adaptive Server 完成 syslogshold 的查询之前结束。但是，如果 syslogshold 的若干查 询经过一段时间后查询数据库的同一行，则该事务可能阻止 dump transaction 截断任何日志空间。

当事务日志达到最后一个机会阈值，并且 dump transaction 无法释放 日志中的空间时，可以查询 syslogshold 和 sysindexes 以标识阻止截 断的事务。例如：

select H.spid, H.name

from master..syslogshold H, threshdb..sysindexes I where H.dbid = db_id("threshdb")

and I.id = 8

and H.page = I.first

spid name

------ -------------------------------------

8 $user_transaction

(1 row affected)

此查询使用与 threshdb 数据库中的 syslogs (8) 相关联的对象 ID 将事 务日志的第一页与 syslogshold 中最旧的活动事务的第一页匹配。

您也可以查询 master 数据库中的 syslogshold 和 sysprocesses 以标识 拥有最旧的活动事务的特定主机和应用程序。例如：

select P.hostname, P.hostprocess, P.program_name,

H.name, H.starttime

from sysprocesses P, syslogshold H where P.spid = H.spid

and H.spid != 0

hostname hostprocess program_name name starttime

-------- ----------- ------------ ------------------ ------------------

(3 rows affected)

使用以上信息，可以通知或关闭拥有最旧活动事务的用户进程，并 继续 dump transaction。您也可以在数据库的阈值过程中包括上述类 型的查询，作为自动警报机制。例如，您可以决定事务日志应永不 达到其最后机会阈值。如果它达到最机会阈值，则最后机会阈值过 程 ( sp_thresholdaction) 会通过有关阻止事务转储的最旧活动事务的信 息提醒您。

注释 事务的初始日志记录可能位于用户日志高速缓存中，在将记 录刷新到日志（例如，在检查点之后）之前，该事务不会在 syslogshold 中显示。

请参见《参考手册：表》和 第 17 章“使用阈值管理可用空间”。

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