Sybase的备份及恢复
1, 概述
本文档以用户需求及在集成中可能遇到的备份恢复需求为基础，以可指导项目快速集成为目的，重点在于说明Sybase备份方案的实施及备份后的恢复方法，并不全面探讨各种备份恢复方法、技巧、应用。想仔细了解，请参考SYBASE出的管理手册。
2, 备份恢复基础
2.1, 查看数据库大小
Sp_helpsegment logsegment|system|"default"
说明：
分别计算日志大小、系统表大小、用户表大小（需要data和log分开存储）
注：如果data和log没分开，可使用sp_spaceused syslogs计算log的大小。
2.2, 设置数据库自动删除日志
在开发数据库上，一般设置 sp_dboption "trunk log on chkpt",true //检查点自动删除日志。满足日志快速增长的维护，在生产数据库上一般设置为false。
2.3, 恢复时设置消息显示
在数据库恢复时，默认恢复信息是不在控制台显示的，可使用sp_configure "print recovery information",1设置为显示。或在恢复时，使用命令 set flushmessage on查看。
2.4, 使用磁带备份时更换磁带
如直接用磁带备份，sp_volchanged命令可通知backup server已经更换磁带可以继续备份。
2.5, 数据库自动恢复顺序
系统每次启动的时候，都进行自动恢复，顺序为：master、sybsystemprocs、model、tempdb、sybsystemdb、sybsecurity。
也可以使用sp_dbrecovery_order db_name,recover_num定义用户数据库的恢复顺序（不能指定系统数据库）。如果要插入改变顺序，则再使用db_name,recover_num,force选项。取消则设置recover_num为-1即可，如果不行，强制使用"force"选项，sp_dbrecovery_order就可查看当前的恢复顺序设置。
2.6, 设置数据库最大恢复时间
sp_configure "recovery interval in minutes",3
可指定每个数据库的最大恢复时间，这个时间决定了数据库检查点的执行时间，默认为5分钟，其实还与数据库大小、数据活动是否频繁等有很大关系，建议一般应用不修改。
2.7, 阻塞和恢复对数据库的更新
quiesce database hold允许在对每个数据库设备的磁盘进行取消镜像或外部复制时，阻塞对一个或多个数据库的更新。此时允许对数据库进行只读操作，要恢复对数据库的更新，在完成相应操作后，发出quiesce database release命令即可。
, quiesce database tag_name hold db_name[,db_name] [for external dump]
, quiesce database tag_name release
一次最多允许8个数据库被hold
说明：tag_name为用户设置的释放数据库列表的标签。
例：
1>, quiesce database pubs_tag hold pubs2
2>, go
1>, quiesce database pubs_tag release
2>, go
2.8, Master系统数据库平时维护配置注意事项
1)不要在master主设备上存储用户数据或创建任何非master、tempdb、model数据库。
2)始终bcp备份重要的系统表
3)每次执行init数据库设备、创建或变更数据库或添加新的服务器名等等操作之后，都要备份master数据库。
2.9, Master数据库数据库日志的特殊
master 数据库日志与数据存储在同一个设备上，而且不能移动master数据库的日志，所以必须经常使用dump database命令备份master数据库，且定期使用truncate_only选项的dump transaction删除日志。
model数据库也应该经常备份，不然恢复时也要使用保留的修改命令重新应用。他的日志清除方法和master数据库一样。
sybsystemprocs数据库与master的备份一样，默认数据库设置为trunc log on chkpt，不需要单独清除日志，恢复时使用installmaster命令，然后输入所有改动，不然就得对其进行备份。
2.10, 备份数据库
如果使用dump database和load database 从一个机器运动数据库到另一个机器（同一硬件和软件平台），必须确保被恢复和原来的设备分配情况相同。备份master的时候，一定要取消主设备镜像，防止启动时寻找旧镜像文件启动，在恢复前，应将数据库设置为单用户模式。
dump database命令备份整个数据库（包括数据和日志），但该备份操作他不会删除已备份的日志。dump database命令运行的时候，用户可继续对数据库进行访问。
2.10.1, 备份到磁盘
1>, dump database db_name to "备份目标绝对路径/备份文件名" //备份到本地磁盘
1>, dump database db_name to "备份目标绝对路径/备份文件名" at remote_server
//远程备份到远程磁盘。前提：在DB Server上配置Client的baackup server服务名，at该backup server服务名，可在Client上执行备份命令（当然要在Client上配置Server的主服务名）。
要完成远程备份，需要修改允许远程备份的动态参数为1，设置为0为禁止：sp_configure "allow remote access",1
2.10.2, 备份到磁带
1>dump database db_name to "/dev/nrmt4" with init //初始化（设备被覆盖）
1>dump database db_name to "/dev/nrmt4" //默认 noinit nounload
1>dump database db_name to "/dev/nrmt4" with unload //磁带回卷并卸下
1>dump database db_name to "/dev/rmt/0"
可使用：sp_configure "tape retention in days",15 //设置静态参数，在dump时候带retaindays设置磁带可被重写的最低天数，以上设置为15天。
2.11, 备份日志
dump transaction命令备份从上一次数据库或日志备份以来改变了的日志。备份完后，dump transaction命令会删除已备份的日志。而且只有日志存储在自己单独的logsegment上时，才可使用该命令备份。
dump transaction db_name to "备份目标绝对路径/备份文件名" at remote_server
dump transaction db_name to "dev/rmt/0" with no_truncate
dump transaction选项：
, with no_truncate //备份但不删除日志
, with no_log //备份日志的过程不记录日志
, with truncate_only //只删除日志不备份
with no_log作为作后手段，并仅在with no_truncate失败后使用一次，此前应该使用alter database 为数据库分配更多的空间。
2.12, 一般数据库故障恢复办法
在数据库发生故障时，请参考如下步骤：
1）马上对故障发生时的数据库执行dump transaction with no_truncate命令备份日志。
2）使用load database 恢复最新的数据库备份。
3）依次使用已备份的日志增量备份load transaction增量恢复应用，然后再使用故障发生时备份的日志进行恢复。也可使用load transaction ... until_time指定恢复到某个时候。
4）由于在恢复过程中，数据库是脱机状态的，所以恢复完后，应该使数据库online database。
5）检查是否恢复到故障发生时的数据库状态。
3, 备份恢复数据库
默认adaptive server可同时备份或恢复6个数据库，但可以修改增加16K的缓冲区，如下：sp_configure "number of large i/o buffers",12 //静态参数
3.1, 备份用户数据库
dump database
dump transaction
除了安排好合理的例行备份外，还应该在以下情况发生时备份数据库，节省数据库失败时的恢复时间：
1）, 升级数据库、创建索引、执行无记录操作、运行dump tran with no_log或dump tran with truncate_only之后。
对于日志和数据放在同一设备的数据库，使用dump database db_name to my_device后，使用dump transaction db_name with truncate_only删除日志。
由于使用with truncate_only的时候，还是要写一些数据到磁盘，如果没有足够的空间，则可以使用with no_log来删除日志：dump transaction db_name with no_log；应该是用alter database 扩展数据库空间，with truncate_only和with no_log后，是没有办法恢复从上次备份后生成的日志、提交的事务的。
详细备份过程请参考"2.10备份数据库"
3.2, 恢复用户数据库
load database
load transaction
从备份中恢复数据库，此数据库必须存在，可以使用create database 的for load选项创建数据库；或通过恢复覆盖一个已有数据库，这样会覆盖已有数据库的所有信息。
磁盘发生故障原因不同，如只是一个块坏，则数据库可能还是能正常工作一段时间，除非运行dbcc命令，如果是整个数据库不能使用，则会把数据库标记为可疑，然后写一条告警信息，数据库不可用了。
比如设备损坏，建议恢复流程：
1，获取设备上每个数据库的当前日志的备份（with no_truncate）
2，检查设备上每个数据库的空间使用情况
3，删除每个数据库
4，删除发生故障的设备
5，初始化新设备
6，重新创建数据库，每次创建一个
7，将最近的数据库备份load到每个数据库
8，按备份的日志时间开始恢复每个日志备份
下面对各步骤详细介绍
3.2.1, 第一步：获取设备上每个数据库的当前日志的备份
dump transaction db_name to "路径/名字" [at remote_server] with no_truncate
3.2.2, 第二步：检查设备上每个数据库的空间使用情况
1）在master中，检查已损坏数据库的设备分配和使用情况：
select segmap,size from sysusages where dbid=db_id("db_name"
2)查看输出结果，segmap值为3的表示一个数据分配，4表示一个日志分配，更高的表示用户自定义段，size表示大小
3）sp_helpdb db_name
1> select segmap,size from sysusages where dbid=db_id("joli_db"
2> go
segmap size
----------- -----------
3 5120
4 2048
数据：(5120*2)/1024=10M
日志：(2048*2)/1024=4M
sp_helpdb joli_db
1> select segmap,size from sysusages where dbid=db_id("testdb"
2> go
segmap size
----------- -----------
7 1536
日志和数据混合在一起
3.2.3, 第三步：删除每个数据库
drop database db_name
如果在使用drop database时，系统由于数据库损坏报告错误，则可以使用dbcc dbrepair命令的dropdb选项：dbcc dbrepair (db_name,dropdb)
3.2.4, 第四步：删除发生故障的设备
sp_dropdevice
3.2.5, 第五步：初始化新设备
disk init
3.2.6, 第六步：重新创建数据库
重新创建数据库，每次创建一个，如果没有按sysusages分配与原来匹配的段，则恢复后数据和日志可能会混合在一个设备上。
create database db_name on datadev1=20,datadev2=10 log on logdev1=10 for load
for load暂时锁定新创建的数据库。可用命令增加创建的数据库大小alter database db_name on datadev3="2M" log on logdev1="4M" for load如果恢复数据库时又发生故障，则adaptive server不会继续恢复已部分恢复的数据库，此时必须重复使用load database重新恢复。
//for load选项包括了恢复数据库
3.2.7, 第七步：将最近的数据库备份load到每个数据库
load database db_name from "路径/名字"
3.2.8, 第八步：按备份的日志时间开始恢复每个日志备份
load transaction恢复日志时，如果顺序不对，会报告错误，恢复完了，应使用dbcc检查其一致性。
有可使用until_time精确时间恢复：
select convert(char(26),getdate(),109)
load transaction employees_db from "/dev/nrmt5" with until_time="Mar 26 1997 12:35:59:650PM"
联机已恢复数据库
onlie database db_name
3.3, 备份系统数据库
除了要经常备份master数据库外，通常在发出如下命令时也要进行备份：
1）, disk init、sp_addumpdevice、sp_dropdevice、磁盘镜像命令
2）, 分段系统过程sp_addsegment、sp_dropsegment、sp_extendsegment
3）, create procedure、drop procedure
4）, sp_logdevice
5）, sp_configure
6）, create database、alter database
不然如果master失败，恢复时有些系统表可能需要重新创建。
应对disk init、create database、alter database的命令脚本进行保存，并对sysdatabases、sysusages、sysdevices、syslogins进行经常备份。
3.4, 恢复master系统数据库
恢复系统数据库，可：
1）使用load database恢复备份
2）使用dataserver、installmaster、installmodel命令创建这些数据库的初始状态
3）混合使用以上两种方法
master数据库坏的症状：
1)adaptive server不能启动
2)频繁或破坏性的分段错误或输入、输出错误
3)dbcc报告损坏情况
假设master故障满足：
1)master数据库已损坏或者主设备已损坏
2)有系统表的最新备份
3)主设备只包括master,tempdb,model
4)有master数据库的最新备份，且备份以来，未初始化任何设备，位创建或变更任何数据库
5)服务器使用缺省排序
我们一般使用以下步骤恢复系统数据库。
3.4.1, 第一步：找到系统表备份
sysdatabases,sysdevices,sysusages,sysloginroles,syslogins
用这些备份，可以确保结束时系统可以全部恢复
3.4.2, 第二步：建立新的主设备
注意事项：
1)检查sysusages的备份，如果dbid 1只有一行，则转到第5步
2)保留旧设备。
3)使用dataserver命令前，应关闭adaptive server。
4)知道主设备的全名和最大大小。
dataserver -d /informix/device/master.dat -b20M
3.4.3, 第三步：以主恢复方式启动adaptive server
复制原来的RUN_servername文件为m_RUN_servername，并在文件中dataserver命令行添加-m参数，再使用
startserver -f m_RUN_servername 启动数据库
3.4.4, 第四步：重新创建master设备分配
1）从sysdevices(备份)查看每个设备的low和high区间，任何sysusages.vstart值在此范围内的任何数据库分配表示该设备上的分配。
2）再查询sysusages(备份)，如果有多行dbid=1的记录，则需要增加master的大小以恢复数据库，alter database增加多大，则根据多出的行区间判断（一般单位为2K）或者size列/512大小，一行对应一条alter database ；而且如果只是主设备损坏，则只需分配到master 设备最后一行即可。（master的dbid=1,tempdb的dbid=2,model的dbid=3）
3）检查改变后的sysusages是否与备份一致，要确保一致。
3.4.5, 第五步：检查backup server的sysservers信息
使用isql登录，检查backup server的服务名svrname，如果不是SYB_BACKUP，必须更新sysservers为SYB_BACKUP；再检查 srvnetname ，确保与$SYBASE/interfaces文件中的描述一致，如果不一致，要更新sysservers表以一致。
select * from sysservers where srvname = "SYB_BACKUP"
go
begin transaction
update sysservers
set srvnetname = "PRODUCTION_BSRV"
where srvname = "SYB_BACKUP"
go
如果修改错误，则发出rollback transaction命令回退；如果成功，则发出commit transaction命令提交。
3.4.6, 第六步：确认backup server正在运行
使用showserver命令确认backup server正在运行，必要也可重新启动backup server。
3.4.7, 第七步：恢复master备份
使用命令load database master from "...."
进行恢复，恢复完后会关闭adaptive server，注意查看恢复和adaptive server关闭过程中是否有错误信息。
3.4.8, 第八步：更新number of devices参数
仅仅在数据库使用的设备数比缺省的要多时，才需要更新。
可修改配置文件，在master 启动时，会读取该文件。
3.4.9, 第九步：以主恢复方式重新启动adaptive server
参考第三步。
注意是否有错误信息提示。
3.4.10, 第十步：检查系统表，核实master的当前备份
如果在最新的disk init,create database,alter database 命令后备份的master数据库，则sysusages,sysdatabase,sysdevices的内容和备份表一致。
不过还是要检查一下，注意：
1）如果恢复后的sysdevices中未包含备份的sysdevices表中的任何设备，则表示上次master备份后添加了新设备，必须运行disk reinit和disk refit命令。
2）如果恢复后sysdatabases表中未包含备份的sysdatabases表中某些数据库，则表示上次master备份后有新的数据创建，则必须运行disk refit。
3.4.11, 第十一步：重新启动adaptive server
用常规模式启动adaptive server
3.4.12, 第十二步：恢复服务器用户ID
检查syslogins和备份的syslogins表，注意：
1）如果不一致，备份后添加了新的登录名，则应重新使用sp_addlogin命令添加。
2）如果删除了登录名，则应重新使用sp_droplogin删除。
3）如果锁定了服务器帐号，应重新使用sp_locklogin锁定。
4）检查由于人为使用sp_modifylogin而引起的其他差别。
确保指派给用户的suids正确，不然会导致权限问题，检查的有效方法是对用户数据库的每个sysusers表执行union，如有权使用master，可包括master ：
select suid,name from master..sysusers
union
select suid,name from sales..sysusers
union
select suid,name from parts..sysusers
union
select suid,name from accounting..sysusers
3.4.13, 第十三步：恢复model数据库
1）如果有保留的model备份，则load database 恢复该备份。
2）如果没有备份，则：
1,运行installmodel脚本创建
cd $SYBASE/ASE-12_5/scripts
isql -Usa -Ppassword -Sserver_name < installmodel
2,重复对model数据库的任何修改。
参考"3.5恢复model系统数据库"
3.4.14, 第十四步：检查adaptive server
仔细检查：
1）备份的sysusages与运行的sysusages比较。
2）备份的sysdatabases与运行的sysdatabases比较。
3）在每个数据库上运行dbcc checkalloc。
4）检查每个数据库中重要的表。
3.4.15, 第十五步：备份master数据库
使用备份命令备份master数据库
3.5, 恢复model系统数据库
以下讲述的是，只需要恢复model数据库时的恢复步骤：
, 第一种：由于没对model数据库做任何更改，只需恢复通用的model数据库。
dataserver可在maste正常工作的情况下恢复model数据库。
dataserver -d /devname -x
, 第二种：已经修改了model数据库，但有model的最新备份。
直接load database恢复model数据库。
, 第三种：已经修改了model数据库，但没有model的备份。
先按第一种恢复，然后重新发出更改model时所发出的所有命令。
3.6, 恢复sybsystemprocs系统数据库
如果有sybsystemprocs的最新备份，直接使用load database 恢复即可。
如果没有，可使用如下方法恢复：
第一步：查询sybsystemprocs存储于什么设备
如果可以使用sp_helpdb，则使用sp_helpdb sybsystemprocs命令查询device_fragments列。
如果不可以使用，则使用
select sysdevices.name,sysusages.size / 512
from sysdevices,sysdatabases,sysusages
where sysdatabases.name = "sybsystemprocs"
and sysdatabases.dbid = sysusages.dbid
and sysdevices.low <= sysusages.size + vstart
and sysdevices.high >= sysusages.size + vstart -1
go
如查询出：sprocdev 28
第二步：删除sybsystemprocs数据库
drop database sybsystemprocs
go
如果物理磁盘损坏，则使用dbcc dbrepair删除此数据库，然后使用sp_dropdevice删除此设备；如果必要，使用disk init初始化一个新的数据库设备。
第三步：创建数据库
使用第一步查询的大小，在查询出的设备上创建sybsystemprocs数据库
create database sybsystemprocs on sprocdev = 28
go
第四步：运行installmaster脚本
在运行installmaster前，应删除sybsystemprocs，然后重新创建。
cd $SYBASE/ASE-12_5/scripts
isql -Usa -Ppassword -Sserver_name < installmaster
第五步：更改 sybsystemprocs
如果更改了sybsystemprocs中的权限，或向数据库添加了自己的过程，则必须重复这些更改。
如果编写的有自己的过程并存储在 sybsystemprocs中，则当数据库损坏时，有如下两种恢复方法：
1，使用上面说所的，使用installmaster恢复sybsystemprocs数据库，然后重新使用create procedure命令创建这些过程。
2，保留数据库的备份，并使用load database恢复备份。（注意，如果是使用磁带，应该保留一个完整的sybsystempprocs在一个磁带上，因为在恢复该数据库期间，将不能使用sp_volchanged换磁带）。
4, 使用disk reinit和disk refit恢复系统表
如果从不能反映最新的disk init,create database,alter database 中恢复master数据库，应该使用本处的方法正确来恢复sysusages,sysdatabases,sysdevices表中的正确信息。
4.1, 使用disk reinit恢复sysdevices
如果上次备份后添加了任何数据库设备，则必须使用disk reinit向 sysdevices添加每个新设备。如果保留的有原来的disk init脚本，应以此脚本提供参数。如果disk reinit提供的vstart参数不同，可能会损坏数据库。
如果没有disk init的脚本，则应查看最新的sysdevices备份获取一些正确的参数，如果在最初的disk init中使用了自定义的vstart，则仍需要知道vstart的值。
disk reinit只能在master中运行，语法如下：
disk reinit
name = "device_name",
physname = "physical_name",
[vdevno = virtual_device_number,]
size = number_of_blocks
[,vstart = virtual_address,
cntrltype = controller_number]
说明：size为(high-low)+1
4.2, 使用disk refit恢复sysusages和sysdatabase表
只能在master数据库中运行。
命令语法为：disk refit
在执行重建系统表后，adaptive server 将关闭。
应该监视全过程中是否有错误信息输出。
如果disk refit提供不准确的信息可能会导致数据库永久性的损坏。
在运行disk refit 后，必须使用dbcc检查adaptive server
本文档以用户需求及在集成中可能遇到的备份恢复需求为基础，以可指导项目快速集成为目的，重点在于说明Sybase备份方案的实施及备份后的恢复方法，并不全面探讨各种备份恢复方法、技巧、应用。想仔细了解，请参考SYBASE出的管理手册。
2, 备份恢复基础
2.1, 查看数据库大小
Sp_helpsegment logsegment|system|"default"
说明：
分别计算日志大小、系统表大小、用户表大小（需要data和log分开存储）
注：如果data和log没分开，可使用sp_spaceused syslogs计算log的大小。
2.2, 设置数据库自动删除日志
在开发数据库上，一般设置 sp_dboption "trunk log on chkpt",true //检查点自动删除日志。满足日志快速增长的维护，在生产数据库上一般设置为false。
2.3, 恢复时设置消息显示
在数据库恢复时，默认恢复信息是不在控制台显示的，可使用sp_configure "print recovery information",1设置为显示。或在恢复时，使用命令 set flushmessage on查看。
2.4, 使用磁带备份时更换磁带
如直接用磁带备份，sp_volchanged命令可通知backup server已经更换磁带可以继续备份。
2.5, 数据库自动恢复顺序
系统每次启动的时候，都进行自动恢复，顺序为：master、sybsystemprocs、model、tempdb、sybsystemdb、sybsecurity。
也可以使用sp_dbrecovery_order db_name,recover_num定义用户数据库的恢复顺序（不能指定系统数据库）。如果要插入改变顺序，则再使用db_name,recover_num,force选项。取消则设置recover_num为-1即可，如果不行，强制使用"force"选项，sp_dbrecovery_order就可查看当前的恢复顺序设置。
2.6, 设置数据库最大恢复时间
sp_configure "recovery interval in minutes",3
可指定每个数据库的最大恢复时间，这个时间决定了数据库检查点的执行时间，默认为5分钟，其实还与数据库大小、数据活动是否频繁等有很大关系，建议一般应用不修改。
2.7, 阻塞和恢复对数据库的更新
quiesce database hold允许在对每个数据库设备的磁盘进行取消镜像或外部复制时，阻塞对一个或多个数据库的更新。此时允许对数据库进行只读操作，要恢复对数据库的更新，在完成相应操作后，发出quiesce database release命令即可。
, quiesce database tag_name hold db_name[,db_name] [for external dump]
, quiesce database tag_name release
一次最多允许8个数据库被hold
说明：tag_name为用户设置的释放数据库列表的标签。
例：
1>, quiesce database pubs_tag hold pubs2
2>, go
1>, quiesce database pubs_tag release
2>, go
2.8, Master系统数据库平时维护配置注意事项
1)不要在master主设备上存储用户数据或创建任何非master、tempdb、model数据库。
2)始终bcp备份重要的系统表
3)每次执行init数据库设备、创建或变更数据库或添加新的服务器名等等操作之后，都要备份master数据库。
2.9, Master数据库数据库日志的特殊
master 数据库日志与数据存储在同一个设备上，而且不能移动master数据库的日志，所以必须经常使用dump database命令备份master数据库，且定期使用truncate_only选项的dump transaction删除日志。
model数据库也应该经常备份，不然恢复时也要使用保留的修改命令重新应用。他的日志清除方法和master数据库一样。
sybsystemprocs数据库与master的备份一样，默认数据库设置为trunc log on chkpt，不需要单独清除日志，恢复时使用installmaster命令，然后输入所有改动，不然就得对其进行备份。
2.10, 备份数据库
如果使用dump database和load database 从一个机器运动数据库到另一个机器（同一硬件和软件平台），必须确保被恢复和原来的设备分配情况相同。备份master的时候，一定要取消主设备镜像，防止启动时寻找旧镜像文件启动，在恢复前，应将数据库设置为单用户模式。
dump database命令备份整个数据库（包括数据和日志），但该备份操作他不会删除已备份的日志。dump database命令运行的时候，用户可继续对数据库进行访问。
2.10.1, 备份到磁盘
1>, dump database db_name to "备份目标绝对路径/备份文件名" //备份到本地磁盘
1>, dump database db_name to "备份目标绝对路径/备份文件名" at remote_server
//远程备份到远程磁盘。前提：在DB Server上配置Client的baackup server服务名，at该backup server服务名，可在Client上执行备份命令（当然要在Client上配置Server的主服务名）。
要完成远程备份，需要修改允许远程备份的动态参数为1，设置为0为禁止：sp_configure "allow remote access",1
2.10.2, 备份到磁带
1>dump database db_name to "/dev/nrmt4" with init //初始化（设备被覆盖）
1>dump database db_name to "/dev/nrmt4" //默认 noinit nounload
1>dump database db_name to "/dev/nrmt4" with unload //磁带回卷并卸下
1>dump database db_name to "/dev/rmt/0"
可使用：sp_configure "tape retention in days",15 //设置静态参数，在dump时候带retaindays设置磁带可被重写的最低天数，以上设置为15天。
2.11, 备份日志
dump transaction命令备份从上一次数据库或日志备份以来改变了的日志。备份完后，dump transaction命令会删除已备份的日志。而且只有日志存储在自己单独的logsegment上时，才可使用该命令备份。
dump transaction db_name to "备份目标绝对路径/备份文件名" at remote_server
dump transaction db_name to "dev/rmt/0" with no_truncate
dump transaction选项：
, with no_truncate //备份但不删除日志
, with no_log //备份日志的过程不记录日志
, with truncate_only //只删除日志不备份
with no_log作为作后手段，并仅在with no_truncate失败后使用一次，此前应该使用alter database 为数据库分配更多的空间。
2.12, 一般数据库故障恢复办法
在数据库发生故障时，请参考如下步骤：
1）马上对故障发生时的数据库执行dump transaction with no_truncate命令备份日志。
2）使用load database 恢复最新的数据库备份。
3）依次使用已备份的日志增量备份load transaction增量恢复应用，然后再使用故障发生时备份的日志进行恢复。也可使用load transaction ... until_time指定恢复到某个时候。
4）由于在恢复过程中，数据库是脱机状态的，所以恢复完后，应该使数据库online database。
5）检查是否恢复到故障发生时的数据库状态。
3, 备份恢复数据库
默认adaptive server可同时备份或恢复6个数据库，但可以修改增加16K的缓冲区，如下：sp_configure "number of large i/o buffers",12 //静态参数
3.1, 备份用户数据库
dump database
dump transaction
除了安排好合理的例行备份外，还应该在以下情况发生时备份数据库，节省数据库失败时的恢复时间：
1）, 升级数据库、创建索引、执行无记录操作、运行dump tran with no_log或dump tran with truncate_only之后。
对于日志和数据放在同一设备的数据库，使用dump database db_name to my_device后，使用dump transaction db_name with truncate_only删除日志。
由于使用with truncate_only的时候，还是要写一些数据到磁盘，如果没有足够的空间，则可以使用with no_log来删除日志：dump transaction db_name with no_log；应该是用alter database 扩展数据库空间，with truncate_only和with no_log后，是没有办法恢复从上次备份后生成的日志、提交的事务的。
详细备份过程请参考"2.10备份数据库"
3.2, 恢复用户数据库
load database
load transaction
从备份中恢复数据库，此数据库必须存在，可以使用create database 的for load选项创建数据库；或通过恢复覆盖一个已有数据库，这样会覆盖已有数据库的所有信息。
磁盘发生故障原因不同，如只是一个块坏，则数据库可能还是能正常工作一段时间，除非运行dbcc命令，如果是整个数据库不能使用，则会把数据库标记为可疑，然后写一条告警信息，数据库不可用了。
比如设备损坏，建议恢复流程：
1，获取设备上每个数据库的当前日志的备份（with no_truncate）
2，检查设备上每个数据库的空间使用情况
3，删除每个数据库
4，删除发生故障的设备
5，初始化新设备
6，重新创建数据库，每次创建一个
7，将最近的数据库备份load到每个数据库
8，按备份的日志时间开始恢复每个日志备份
下面对各步骤详细介绍
3.2.1, 第一步：获取设备上每个数据库的当前日志的备份
dump transaction db_name to "路径/名字" [at remote_server] with no_truncate
3.2.2, 第二步：检查设备上每个数据库的空间使用情况
1）在master中，检查已损坏数据库的设备分配和使用情况：
select segmap,size from sysusages where dbid=db_id("db_name"
2)查看输出结果，segmap值为3的表示一个数据分配，4表示一个日志分配，更高的表示用户自定义段，size表示大小
3）sp_helpdb db_name
1> select segmap,size from sysusages where dbid=db_id("joli_db"
2> go
segmap size
----------- -----------
3 5120
4 2048
数据：(5120*2)/1024=10M
日志：(2048*2)/1024=4M
sp_helpdb joli_db
1> select segmap,size from sysusages where dbid=db_id("testdb"
2> go
segmap size
----------- -----------
7 1536
日志和数据混合在一起
3.2.3, 第三步：删除每个数据库
drop database db_name
如果在使用drop database时，系统由于数据库损坏报告错误，则可以使用dbcc dbrepair命令的dropdb选项：dbcc dbrepair (db_name,dropdb)
3.2.4, 第四步：删除发生故障的设备
sp_dropdevice
3.2.5, 第五步：初始化新设备
disk init
3.2.6, 第六步：重新创建数据库
重新创建数据库，每次创建一个，如果没有按sysusages分配与原来匹配的段，则恢复后数据和日志可能会混合在一个设备上。
create database db_name on datadev1=20,datadev2=10 log on logdev1=10 for load
for load暂时锁定新创建的数据库。可用命令增加创建的数据库大小alter database db_name on datadev3="2M" log on logdev1="4M" for load如果恢复数据库时又发生故障，则adaptive server不会继续恢复已部分恢复的数据库，此时必须重复使用load database重新恢复。
//for load选项包括了恢复数据库
3.2.7, 第七步：将最近的数据库备份load到每个数据库
load database db_name from "路径/名字"
3.2.8, 第八步：按备份的日志时间开始恢复每个日志备份
load transaction恢复日志时，如果顺序不对，会报告错误，恢复完了，应使用dbcc检查其一致性。
有可使用until_time精确时间恢复：
select convert(char(26),getdate(),109)
load transaction employees_db from "/dev/nrmt5" with until_time="Mar 26 1997 12:35:59:650PM"
联机已恢复数据库
onlie database db_name
3.3, 备份系统数据库
除了要经常备份master数据库外，通常在发出如下命令时也要进行备份：
1）, disk init、sp_addumpdevice、sp_dropdevice、磁盘镜像命令
2）, 分段系统过程sp_addsegment、sp_dropsegment、sp_extendsegment
3）, create procedure、drop procedure
4）, sp_logdevice
5）, sp_configure
6）, create database、alter database
不然如果master失败，恢复时有些系统表可能需要重新创建。
应对disk init、create database、alter database的命令脚本进行保存，并对sysdatabases、sysusages、sysdevices、syslogins进行经常备份。
3.4, 恢复master系统数据库
恢复系统数据库，可：
1）使用load database恢复备份
2）使用dataserver、installmaster、installmodel命令创建这些数据库的初始状态
3）混合使用以上两种方法
master数据库坏的症状：
1)adaptive server不能启动
2)频繁或破坏性的分段错误或输入、输出错误
3)dbcc报告损坏情况
假设master故障满足：
1)master数据库已损坏或者主设备已损坏
2)有系统表的最新备份
3)主设备只包括master,tempdb,model
4)有master数据库的最新备份，且备份以来，未初始化任何设备，位创建或变更任何数据库
5)服务器使用缺省排序
我们一般使用以下步骤恢复系统数据库。
3.4.1, 第一步：找到系统表备份
sysdatabases,sysdevices,sysusages,sysloginroles,syslogins
用这些备份，可以确保结束时系统可以全部恢复
3.4.2, 第二步：建立新的主设备
注意事项：
1)检查sysusages的备份，如果dbid 1只有一行，则转到第5步
2)保留旧设备。
3)使用dataserver命令前，应关闭adaptive server。
4)知道主设备的全名和最大大小。
dataserver -d /informix/device/master.dat -b20M
3.4.3, 第三步：以主恢复方式启动adaptive server
复制原来的RUN_servername文件为m_RUN_servername，并在文件中dataserver命令行添加-m参数，再使用
startserver -f m_RUN_servername 启动数据库
3.4.4, 第四步：重新创建master设备分配
1）从sysdevices(备份)查看每个设备的low和high区间，任何sysusages.vstart值在此范围内的任何数据库分配表示该设备上的分配。
2）再查询sysusages(备份)，如果有多行dbid=1的记录，则需要增加master的大小以恢复数据库，alter database增加多大，则根据多出的行区间判断（一般单位为2K）或者size列/512大小，一行对应一条alter database ；而且如果只是主设备损坏，则只需分配到master 设备最后一行即可。（master的dbid=1,tempdb的dbid=2,model的dbid=3）
3）检查改变后的sysusages是否与备份一致，要确保一致。
3.4.5, 第五步：检查backup server的sysservers信息
使用isql登录，检查backup server的服务名svrname，如果不是SYB_BACKUP，必须更新sysservers为SYB_BACKUP；再检查 srvnetname ，确保与$SYBASE/interfaces文件中的描述一致，如果不一致，要更新sysservers表以一致。
select * from sysservers where srvname = "SYB_BACKUP"
go
begin transaction
update sysservers
set srvnetname = "PRODUCTION_BSRV"
where srvname = "SYB_BACKUP"
go
如果修改错误，则发出rollback transaction命令回退；如果成功，则发出commit transaction命令提交。
3.4.6, 第六步：确认backup server正在运行
使用showserver命令确认backup server正在运行，必要也可重新启动backup server。
3.4.7, 第七步：恢复master备份
使用命令load database master from "...."
进行恢复，恢复完后会关闭adaptive server，注意查看恢复和adaptive server关闭过程中是否有错误信息。
3.4.8, 第八步：更新number of devices参数
仅仅在数据库使用的设备数比缺省的要多时，才需要更新。
可修改配置文件，在master 启动时，会读取该文件。
3.4.9, 第九步：以主恢复方式重新启动adaptive server
参考第三步。
注意是否有错误信息提示。
3.4.10, 第十步：检查系统表，核实master的当前备份
如果在最新的disk init,create database,alter database 命令后备份的master数据库，则sysusages,sysdatabase,sysdevices的内容和备份表一致。
不过还是要检查一下，注意：
1）如果恢复后的sysdevices中未包含备份的sysdevices表中的任何设备，则表示上次master备份后添加了新设备，必须运行disk reinit和disk refit命令。
2）如果恢复后sysdatabases表中未包含备份的sysdatabases表中某些数据库，则表示上次master备份后有新的数据创建，则必须运行disk refit。
3.4.11, 第十一步：重新启动adaptive server
用常规模式启动adaptive server
3.4.12, 第十二步：恢复服务器用户ID
检查syslogins和备份的syslogins表，注意：
1）如果不一致，备份后添加了新的登录名，则应重新使用sp_addlogin命令添加。
2）如果删除了登录名，则应重新使用sp_droplogin删除。
3）如果锁定了服务器帐号，应重新使用sp_locklogin锁定。
4）检查由于人为使用sp_modifylogin而引起的其他差别。
确保指派给用户的suids正确，不然会导致权限问题，检查的有效方法是对用户数据库的每个sysusers表执行union，如有权使用master，可包括master ：
select suid,name from master..sysusers
union
select suid,name from sales..sysusers
union
select suid,name from parts..sysusers
union
select suid,name from accounting..sysusers
3.4.13, 第十三步：恢复model数据库
1）如果有保留的model备份，则load database 恢复该备份。
2）如果没有备份，则：
1,运行installmodel脚本创建
cd $SYBASE/ASE-12_5/scripts
isql -Usa -Ppassword -Sserver_name < installmodel
2,重复对model数据库的任何修改。
参考"3.5恢复model系统数据库"
3.4.14, 第十四步：检查adaptive server
仔细检查：
1）备份的sysusages与运行的sysusages比较。
2）备份的sysdatabases与运行的sysdatabases比较。
3）在每个数据库上运行dbcc checkalloc。
4）检查每个数据库中重要的表。
3.4.15, 第十五步：备份master数据库
使用备份命令备份master数据库
3.5, 恢复model系统数据库
以下讲述的是，只需要恢复model数据库时的恢复步骤：
, 第一种：由于没对model数据库做任何更改，只需恢复通用的model数据库。
dataserver可在maste正常工作的情况下恢复model数据库。
dataserver -d /devname -x
, 第二种：已经修改了model数据库，但有model的最新备份。
直接load database恢复model数据库。
, 第三种：已经修改了model数据库，但没有model的备份。
先按第一种恢复，然后重新发出更改model时所发出的所有命令。
3.6, 恢复sybsystemprocs系统数据库
如果有sybsystemprocs的最新备份，直接使用load database 恢复即可。
如果没有，可使用如下方法恢复：
第一步：查询sybsystemprocs存储于什么设备
如果可以使用sp_helpdb，则使用sp_helpdb sybsystemprocs命令查询device_fragments列。
如果不可以使用，则使用
select sysdevices.name,sysusages.size / 512
from sysdevices,sysdatabases,sysusages
where sysdatabases.name = "sybsystemprocs"
and sysdatabases.dbid = sysusages.dbid
and sysdevices.low <= sysusages.size + vstart
and sysdevices.high >= sysusages.size + vstart -1
go
如查询出：sprocdev 28
第二步：删除sybsystemprocs数据库
drop database sybsystemprocs
go
如果物理磁盘损坏，则使用dbcc dbrepair删除此数据库，然后使用sp_dropdevice删除此设备；如果必要，使用disk init初始化一个新的数据库设备。
第三步：创建数据库
使用第一步查询的大小，在查询出的设备上创建sybsystemprocs数据库
create database sybsystemprocs on sprocdev = 28
go
第四步：运行installmaster脚本
在运行installmaster前，应删除sybsystemprocs，然后重新创建。
cd $SYBASE/ASE-12_5/scripts
isql -Usa -Ppassword -Sserver_name < installmaster
第五步：更改 sybsystemprocs
如果更改了sybsystemprocs中的权限，或向数据库添加了自己的过程，则必须重复这些更改。
如果编写的有自己的过程并存储在 sybsystemprocs中，则当数据库损坏时，有如下两种恢复方法：
1，使用上面说所的，使用installmaster恢复sybsystemprocs数据库，然后重新使用create procedure命令创建这些过程。
2，保留数据库的备份，并使用load database恢复备份。（注意，如果是使用磁带，应该保留一个完整的sybsystempprocs在一个磁带上，因为在恢复该数据库期间，将不能使用sp_volchanged换磁带）。
4, 使用disk reinit和disk refit恢复系统表
如果从不能反映最新的disk init,create database,alter database 中恢复master数据库，应该使用本处的方法正确来恢复sysusages,sysdatabases,sysdevices表中的正确信息。
4.1, 使用disk reinit恢复sysdevices
如果上次备份后添加了任何数据库设备，则必须使用disk reinit向 sysdevices添加每个新设备。如果保留的有原来的disk init脚本，应以此脚本提供参数。如果disk reinit提供的vstart参数不同，可能会损坏数据库。
如果没有disk init的脚本，则应查看最新的sysdevices备份获取一些正确的参数，如果在最初的disk init中使用了自定义的vstart，则仍需要知道vstart的值。
disk reinit只能在master中运行，语法如下：
disk reinit
name = "device_name",
physname = "physical_name",
[vdevno = virtual_device_number,]
size = number_of_blocks
[,vstart = virtual_address,
cntrltype = controller_number]
说明：size为(high-low)+1
4.2, 使用disk refit恢复sysusages和sysdatabase表
只能在master数据库中运行。
命令语法为：disk refit
在执行重建系统表后，adaptive server 将关闭。
应该监视全过程中是否有错误信息输出。
如果disk refit提供不准确的信息可能会导致数据库永久性的损坏。
在运行disk refit 后，必须使用dbcc检查adaptive server