DBA日常工作

1. 引言
   本指南旨在简要地列出Sybase ASE系统管理员（DBA）所需的日常维护工作。一般说来，在完成这些操作后，所管理的ASE数据库可以长期安全可靠地运行。本指南着重的是what to do，而不是how to do，也即是说本指南并不会详细地介绍如何进行这些日常工作，但会给出相应的参考手册。我们认为作为一个合格的数据库管理员，应及早发现可能导致的问题，而不是等到出现问题时才来解决。根据Sybase技术支持人员的经验，在出现问题时，因时间急迫，数据库管理员所采取的一些紧急措施往往容易导致更严重的问题。因此，本手册着重介绍的是一些事前的预防、检查措施，而不是事后的处理。
   考虑到目前仅ASE12.5.0有中文手册，因此，本指南所指出的参考的手册和章节均使用英文版手册的名称和章节。
   另外，需要注意的是，本指南只是 guide，实际生产环境差异甚大，请灵活掌握。如 2.10 和 2.11 节就不适合 7*24 运行的系统。同时，前期发布的本指南的 PDF 版本不再更新。
   本指南的撰写过程中，得到了Sybase广州办事处胡道军、周海涛工程师的大力支持和指正。SybaseBBS的朋友们也无私地贡献出他们宝贵的经验和意见。在此真诚地表示谢意。

1.1.适合的读者
本指南所面向的读者主要是Sybase ASE 数据库管理员，应具有Sybase ASE数据库基本知识，能独立进行数据库的基本操作。
本指南可以为那些希望制订适合所在组织的ASE数据库维护制度的管理人员提供参考。

1.2.约定
本手册遵从以下字体和风格约定：

元素

示例

书名、章节名

《System Administration Guide Volume 2》 、 Developing a Backup and Recovery Plan

定期频度

每周一次

存贮过程或、命令

sp_addserver targetservername

2.日常维护工作
2.1.定期备份master库
Master库是ASE最核心的系统库，它记录了所有数据库的物理和逻辑信息。因此其备份工作独立成节。
建议master数据库的备份频度为每周一次。同时，在进行任何系统表操作之前和之后，应事先/立即备份master库。如： disk init 、 sp_addumpdevice 、 sp_dropdevice 、磁盘镜像命令、 sp_addsegment 、 sp_dropsegment 或 sp_extendsegment 等。
Master数据库的备份可以采用在服务停止后，直接复制master.dat文件的方式进行。
有关备份master数据库的详细信息，请参考Sybase手册之 《System Administration Guide Volume 2》 中的 Developing a Backup and Recovery Plan 一章。

2.2.定期备份用户数据库
对于数据库维护而言，定期备份是十分重要的工作。ASE管理员应制定合理的备份策略，定期进行数据库备份（ dump database ）和日志备份（ dump transaction ）。建议数据库备份的频度至少为每周一次、日志备份的频度至少为每日一次。可根据应用的实际情况将日志备份调整为每半天一次或每小时一次，以尽可能地降低意外导致的损失。
需要注意的事，除了定期备份外，当发生以下操作之前和之后，也应及时进行数据库备份：

数据库版本升级；
创建新索引；
无日志记录操作，如无记录的writetext、永久表上的select into、快速批量复制（bcp）到一个没有触发器或索引的表等；
dump transaction with truncate_only 或 dump transaction with no_log 。
同时，建议在进行了任何DDL操作后，立即备份数据库。
对于小容量并使用文件系统文件为设备的数据库，可以采用直接备份设备文件的方式进行。采用此种方式备份，必须准确地记录设备文件所在的目录。
有关备份用户数据库的详细信息，请参考Sybase手册之 《System Administration Guide Volume 2》 中的 Developing a Backup and Recovery Plan 一章。

2.3.定期检查最早活动事务
最早活动事务（the oldest active transaction）是指一个数据库中的最早未完成（未提交或未回滚）的事务。它将导致日志空间逐渐减少，持续时间越长，日志空间越少。由于事务的瞬间性，通常并不会存在被记录下来的最早活动事务。但一些特殊情况可能会导致最早活动事务出现。比如，在一个大事务处理过程中，网络出现故障。
在master数据库中，系统表syslogshold为每个数据库记录了最早活动事务（如果存在的话）以及复制服务的截断点（如果存在的话），也就是说在该表中，每个数据库可能存在0、1或2条记录。
可以通过查询syslogshold表获取最早活动事务的情况。建议检查频度为每周一次。
有关备份用户数据库的详细信息，请参考Sybase手册之 《System Administration Guide Volume 2》 中的 Backing Up and Restoring User Databases__和__Managing Free Space with Thresholds 章节、 《Reference Manual: Procedures》 中的 System Procedures 一章以及 《Reference Manual: Tables》 中的 System Tables 一章。

2.4.定期检查数据库日志空间
ASE数据库采取的是先记日志的机制。每当用户执行修改数据库的操作时，ASE会自动地将变化写入日志中。一条SQL语句所产生的所有变化都被记录到日志后，它们才被写到数据页在缓冲区的拷贝中。日志对于数据库的数据安全性、完整性至关重要。如果当日志空间满了再来处理，有可能会造成一定的损失。因此，需要定期检查数据库日志空间。
可以通过 sp_spaceused syslogs 查看日志空间。有关该存贮过程的详细说明，请参考 《System Administration Guide Volume 2》 中的 Managing Free Space with Thresholds 一章和 《Reference Manual: Procedures》 中的 System Procedures 一章。
管理员应根据应用类型、业务量以及日志空间的大小来制订检查的频度。建议至少每周一次 。

2.5.定期检查数据库剩余空间
通常在设计时，数据库的容量比当前容量大很多。然而，随着时间的流逝、数据量的不断增加 ，数据库剩余空间逐渐减少。建议检查的频度至少为每月一次。
可以通过sp_helpdb查看数据库的使用情况，有关该存贮过程的详细说明，请参考 《Reference Manual: Procedures》 中的 System Procedures 一章。

2.6.定期查看（错误）日志
实际上，定期查看日志是任何系统的管理员都必须养成的良好习惯。日志（包含备份服务的日志）详细记录了数据库的运行过程情况，任何异常也会在日志中体现。查看日志并不需要多少时间，通常2－5分钟就足够了。将此项工作定期化，管理员就可以大致掌握数据库的运行状况，并及时分析异常并做出正确的响应。有鉴于此，强烈建议日志查看的频度为每日一次。
同时，在数据库发生任何异常时，请首先查看日志。
如何阅读日志，请参考Sybase ASE手册之 《System Administration Guide Volume 1》 中的 Diagnosing System Problems 一章。

2.7.定期检查数据库软件更新
虽然用户都希望能有一个没有Bug的软件，然而遗憾的是：任何软件都存在BUG，ASE自然也不会例外。因此，及时获取补丁并更新，是非常重要的工作。
强烈建议：

ASE管理员应至少每月查看一次Sybase官方网站的EBF包发布情况；建议在打补丁或更新前，管理员应认真阅读Targeted CR-List，分析并权衡更新可能对现有应用可能带来的影响。
只要可能，管理员也应认真阅读Target CR-List，了解当前ASE版本存在哪些问题，从而采取相应的措施，避免潜在的损失。
2.8.定期更新统计信息
ASE查询优化器依靠统计信息来生成查询计划，统计信息的正确与否，直接决定了SQL的执行速度。一个真实的例子是：一个应用系统运行一段时间后，性能急骤下降。监控过程中发现，一些查询SQL的SARG明明建有索引，但域名交易查询计划显示并未使用索引，而是全表扫描。在更新统计信息后，系统速度恢复正常。
建议根据表的更新程度，采取不同的频度执行此项工作。在ASE15之前，只能凭经验来估计需要更新的频度。而自版本15开始，ASE引入了一个 datachange 函数，可以获取表的更新程度，从而更灵活地更新统计信息。
需要注意的是，更新统计信息是极消耗系统资源的，因此应尽可能避免在业务时间内执行此项工作。同时，强烈建议不要使用update all模式，对于大表而言，update all将是一个灾难。同时对于大数据量的表，应使用采样更新。建议的采样率为10%到20%。
如何更新统计信息以及为哪些列增加统计信息，请参考Sybase ASE手册之 《Performance and Tuning:Monitoring and Analyzing》 的 Using Statistics to Improve Performance 一章以及 《Reference Manual: procedures》 。
由于 ASE 15的优化器可利用组合索引的非前导列，因此可适当增加 update index statistics 的执行频度。

2.9.定期进行性能检查
使用sp_sysmon存贮过程（所有ASE版本），定期检查数据库运行性能。也可以使用MDA（也称mon表，要求ASE版本为12.5.0.3以上），或者配合相关工具，如DB X-ray、Spotlight、Sybase DB Expert等。
有关 sp_sysmon 存贮过程的详细信息，请参考Sybase ASE手册之 《Reference Manual: procedures》 。
有关MDA的详细信息，请参考Sybase ASE手册之 《Performance and Tuning: Monitoring and Analyzing》 中的 Monitoring Tables 一节，

建议的频度为每周一次，尤其是在业务高峰期。

2.10.定期检查数据库完整性
DBCC（database consistency checker）提供了检查数据库逻辑和物理完整性的命令。其主要功能是：

使用checkstorage或checktable和checkdb检查页级和行级上的页链和数据指针；
使用checkstorage、checkalloc、checkverify、tablealloc和indexalloc检查分配页。
需要注意的是，DBCC需要消耗大量的资源，因此应尽可能地避免在业务时间内执行此项工作。建议定期DBCC的频度为每季度一次。另外，一旦发现硬件存贮可能存在问题，应尽快进行DBCC检查。
关于DBCC的详细信息，请参考Sybase手册之 《System Administration Guide Volume 2》 的 Checking Database Consistency 一章。

2.11.定期重新组织表空间
数据库运行一段时间后，频繁的表更新活动最终可能会导致空间利用不充分以及性能的降低。因此需要定期的重新组织表空间。
需要注意的是，重新组织表空间需要足够的空余空间，建议应保证1.5倍表原有空间以上。同时，重组表空间需要大量的资源，因此应尽可能地避免在业务时间内执行此项工作。
建议定期重新组织表空间的频度为每半年一次。

2.11.1.APL表
对于有聚集索引（Clustered Index）的APL表，可删除该聚集索引，并重建；
对于没有聚集索引的APL表，可选择一列创建聚集索引，然后删除。
关于如何创建和删除聚集索引的信息，请参考Sybase手册之 《Performance and Tuning: Basics》 中的 How Indexes Work 一章。

2.11.2.DOL表
自11.9.2开始，ASE引入了DOL表。与传统的APL表相比，DOL表的存贮发生了较大的变化。使用 Reorg 命令可以重组表空间的使用并提高性能。
关于reorg命令的使用，请参考Sybase手册之 《System Administration Guide Volume 2》 中的 Using the reorg Command 一章。

3.如何自动化
第2章所介绍的操作，一些操作是可以进行自动化的，如定期备份数据库、定期更新统计信息、定期检查数据库完整性、定期重新组织表空间等等。需要注意的是：自动化的操作一定要输出执行结果。执行完后，管理员必须要查看所记录的结果文档。

3.1.使用操作系统的任务调度
采用OS支持的脚本语言（如perl、bash、BAT）编写相应的操作脚本，使用操作系统的crontab（UNIX和类UNIX系统）或任务调度（Windows系统）周期性执行，适合于所有版本的ASE数据库。缺点是需要将数据库密码以明文方式写在脚本中。
另外，通过 xp 服务也可以调用系统程序，请自行参考相关手册。

3.2.使用ASE的任务调度
自12.5.1（UNIX）/12.5.2(Windows)开始，ASE引入了任务调度（Job Scheduler）。通过JS，可以完成以前只能有OS的任务调度才能完成的功能。需要注意的是：使用JS功能，应尽可能地更新ASE版本，建议ASE版本至少为12.5.3ESD4。
有关JS的配置和使用信息，本文不再描述。请参考本文的WORD版本（注：该WORD版本不再更新），或Sybase手册之 《Job Scheduler User’s Guide》 。

附录A Oracle DBA的任务（部份）
以下内容摘自 Oracle 10G Administration I Study Guide ，第26页

选择运行数据库软件的服务器硬件
安装和配置Oracle 10g
创建数据库
创建和管理应用所需的表和其它对象
创建和管理用数据库用户
建立可靠的备份和恢复过程
监视和优化数据库性能