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的朋友们也无私地贡献出他们宝贵的经验和意见。在此真诚地表示谢意。
考虑到目前仅ASE12.5.0有中文手册，因此，本指南所指出的参考的手册和章节均使用英文版手册的名称和章节。
另外，需要注意的是，本指南只是 guide，实际生产环境差异甚大，请灵活掌握。如 2.10 和 2.11 节就不适合 7*24 运行的系统。同时，前期发布的本指南的 PDF 版本不再更新。
本指南的撰写过程中，得到了Sybase广州办事处胡道军、周海涛工程师的大力支持和指正。SybaseBBS的朋友们也无私地贡献出他们宝贵的经验和意见。在此真诚地表示谢意。
1.1.适合的读者
本指南所面向的读者主要是Sybase ASE 数据库管理员，应具有Sybase ASE数据库基本知识，能独立进行数据库的基本操作。
本指南可以为那些希望制订适合所在组织的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 一章。
建议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 ）。建议数据库备份的频度至少为
每周一次、日志备份的频度至少为
每日一次。可根据应用的实际情况将日志备份调整为
每半天一次或
每小时一次，以尽可能地降低意外导致的损失。
需要注意的事，除了定期备份外，当发生以下操作之前和之后，也应及时进行数据库备份：
对于小容量并使用文件系统文件为设备的数据库，可以采用直接备份设备文件的方式进行。采用此种方式备份，必须准确地记录设备文件所在的目录。
有关备份用户数据库的详细信息，请参考Sybase手册之 《System Administration Guide Volume 2》 中的 Developing a Backup and Recovery Plan 一章。
需要注意的事，除了定期备份外，当发生以下操作之前和之后，也应及时进行数据库备份：
- 数据库版本升级；
- 创建新索引；
- 无日志记录操作，如无记录的writetext、永久表上的select into、快速批量复制（bcp）到一个没有触发器或索引的表等；
- dump transaction with truncate_only 或 dump transaction with no_log 。
对于小容量并使用文件系统文件为设备的数据库，可以采用直接备份设备文件的方式进行。采用此种方式备份，必须准确地记录设备文件所在的目录。
有关备份用户数据库的详细信息，请参考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 一章。
在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 一章。
管理员应根据应用类型、业务量以及日志空间的大小来制订检查的频度。建议至少 每周一次 。
可以通过 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 一章。
可以通过sp_helpdb查看数据库的使用情况，有关该存贮过程的详细说明，请参考 《Reference Manual: Procedures》 中的 System Procedures 一章。
2.6.定期查看（错误）日志
实际上，定期查看日志是任何系统的管理员都必须养成的良好习惯。日志（包含备份服务的日志）详细记录了数据库的运行过程情况，任何异常也会在日志中体现。查看日志并不需要多少时间，通常2－5分钟就足够了。将此项工作定期化，管理员就可以大致掌握数据库的运行状况，并及时分析异常并做出正确的响应。有鉴于此，强烈建议日志查看的频度为
每日一次。
同时，在数据库发生任何异常时，请首先查看日志。
如何阅读日志，请参考Sybase ASE手册之 《System Administration Guide Volume 1》 中的 Diagnosing System Problems 一章。
同时，在数据库发生任何异常时，请首先查看日志。
如何阅读日志，请参考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 的执行频度。
建议根据表的更新程度，采取不同的频度执行此项工作。在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 一节，或参考 ASE MDA 常见问与答。
建议的频度为 每周一次，尤其是在业务高峰期。
有关 sp_sysmon 存贮过程的详细信息，请参考Sybase ASE手册之 《Reference Manual: procedures》 。
有关MDA的详细信息，请参考Sybase ASE手册之 《Performance and Tuning: Monitoring and Analyzing》 中的 Monitoring Tables 一节，或参考 ASE MDA 常见问与答。
建议的频度为 每周一次，尤其是在业务高峰期。
2.10.定期检查数据库完整性
DBCC（database consistency checker）提供了检查数据库逻辑和物理完整性的命令。其主要功能是：
关于DBCC的详细信息，请参考Sybase手册之 《System Administration Guide Volume 2》 的 Checking Database Consistency 一章。
- 使用checkstorage或checktable和checkdb检查页级和行级上的页链和数据指针；
- 使用checkstorage、checkalloc、checkverify、tablealloc和indexalloc检查分配页。
关于DBCC的详细信息，请参考Sybase手册之 《System Administration Guide Volume 2》 的 Checking Database Consistency 一章。
2.11.定期重新组织表空间
数据库运行一段时间后，频繁的表更新活动最终可能会导致空间利用不充分以及性能的降低。因此需要定期的重新组织表空间。
需要注意的是，重新组织表空间需要足够的空余空间，建议应保证1.5倍表原有空间以上。同时，重组表空间需要大量的资源，因此应尽可能地避免在业务时间内执行此项工作。
建议定期重新组织表空间的频度为 每半年一次。
需要注意的是，重新组织表空间需要足够的空余空间，建议应保证1.5倍表原有空间以上。同时，重组表空间需要大量的资源，因此应尽可能地避免在业务时间内执行此项工作。
建议定期重新组织表空间的频度为 每半年一次。
2.11.1.APL表
对于有聚集索引（Clustered Index）的APL表，可删除该聚集索引，并重建；
对于没有聚集索引的APL表，可选择一列创建聚集索引，然后删除。
关于如何创建和删除聚集索引的信息，请参考Sybase手册之 《Performance and Tuning: Basics》 中的 How Indexes Work 一章。
对于没有聚集索引的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 一章。
关于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 服务也可以调用系统程序，请自行参考相关手册。
有关JS的配置和使用信息，本文不再描述。请参考本文的WORD版本（注：该WORD版本不再更新），或Sybase手册之 《Job Scheduler User’s Guide》 。
另外，通过 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
- 创建数据库
- 创建和管理应用所需的表和其它对象
- 创建和管理用数据库用户
- 建立可靠的备份和恢复过程
- 监视和优化数据库性能
-- FlybeanZhou - 2006年1月28日
职场 SYBASE 休闲
数据库
0
微博 QQ 微信
收藏
上一篇：关于 SYBASE 1608 错... 下一篇：×××
推荐专栏更多
十年老兵教你练一套正宗的MySQL降龙十八掌
MySQL全通晓
共18章 | 张甦
￥51.00 411人订阅
订 阅
负载均衡高手炼成记
高并发架构之路
共15章 | sery
￥51.00 535人订阅
订 阅
猜你喜欢
我的友情链接 Visual C++ Debug 与 Release版本区别 支付结算系统如何应对高并发、热点账户等问题 PostgreSQL WAL解析：构建WAL记录准备 playbook自动安装kafka集群 PostgreSQL的B-tree索引 PostgreSQL pg_rewind实例--could not find previous WA redis geo 地理位置系应用战案例 PostgreSQL逻辑备份pg_dump使用及其原理解析 PostgreSQL如何删除不使用的xlog文件 PostgreSQL pg_ctl start超时分析 Greenplum -- segment 死机后恢复 postgresql 主备及切换-恢复方案 顺丰删库工程师遭开除，难道他不会恢复误删数据？ 从删库到恢复到跑不了路-数据恢复工程师解说顺丰删库事件 【干货】数据库分库分表基础和实践 Hyperledger Fabric启用CouchDB为状态数据库 PostgreSQL启动恢复读取checkpoint记录失败的条件 GreenPlum 5.10.0 集群部署 Memcached安装及数据库操作管理
扫一扫,领取大礼包
0
分享
ribut9225
Ctrl+Enter 发布
发布
取消