使用sybase过程中，数据库备份策略

数据库备份策略在维护系统数据安全起着非同小可的作用，好的备份策略应该考虑保证数据的安全，并且操作较为方便。

基本过程很简单，如下：
1．备份到本地硬盘： 
dump transaction with truncate_only 
dump database … to … 
dump transaction 
。。。 

2．当装载数据库和事务日志时，为防止其他用户对数据库的操作，须把数据库设置为 dbo use only。 
进行装载时的顺序为： 
dump transaction with no_truncate 
load database database_name from ... 
load transaction database_name from ... 
。。。 
online database 
也可以用until指定恢复到某个时间 

使用阈值管理 
可以使用阈值管理，在阈值管理中安排当超过某个阈值时自动转储事务日志。当超过阀值以后，SQL Serve中断或挂起试图写这个日志的用户事务。对每一个挂起的事务 向errorlog 发一条消息；然后执行sp_thresholdaction 
sp_thresholdaction用户自己编写 
create procedure sp_thresholdaction 
@dbname varchar（30）, 
@segmentname varchar（30）, 
as 
dump transaction @dbname to "DEVICE" 
print "LOG DUMP: %1! for %2! dumped", @segmentname, @dbname 
其中参数 ： 
            @dbname 为达到阀值的数据库名； 
            @segmentname 为达到阀值的段名； 

用户数据库损坏的处理 
如果数据库处于suspect状态，无法用drop database 删除时： 
dbcc dbrepair (db_name, dropdb) 
create database db_name on dev_name  for load 
load database db_name from dump_device 

master库损坏的处理 
?使用 buildmaster  -m 重建一个新的 master 数据库； 
buildmaster 建立 master 设备并在这个设备上建立 master， model， tempdb 库。 
-m 选项只重新写 master 库， 而不修改配置块或初始化 master 设备。 
? 以单用户方式重启动服务器， 如果需要的话， 则需增加转储设备； 
? 从备份装载 master 数据库； 
? 用 startserver 重启 SQL Server； 
? 检查一致性： 对每一个数据库运行 dbcc  checkalloc，并对重要的表进行检查； 


但是，当我们问及sybase的技术支持是否建议使用threshold  时，他们并不积极建议这样做，理由是自动化操作往往会出现一些难于预料的结果。当然，要是有那么负责的dba，天天定时手工备份，当然是再好不过了。
基本的备份操作是简单，但是我们在实际实施备策略时，往往会考虑这样那样的问题，也会出现一些意想不到的问题，比如：
 1、是整库备份还是增量备份
 2、每天什么时候备份，备份时间怎么安排
 3、万一需要恢复数据库，当前的备份能恢复到一个什么程度
 4、数据库在恢复时可能出现哪些紧急情况
 等等...


   欢迎大家就这个主题进行一下讨论，以激发出一些好的想法和经验，以共同增强系统数据的安全性！