数据库备份策略

                     数据库备份策略

 

数据库备份策略在维护系统数据安全起着非同小可的作用，好的备份策略应该考虑保证数据的安全，并且操作较为方便。
基本过程很简单，如下：
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、数据库在恢复时可能出现哪些紧急情况
等等...


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


(jazy)
*****************************************************

偶们的数据库比较小，不需要经常备份！
即使备份也是整库备份！  
(miniyoyo2002)
*****************************************************
有一个问题，就是一旦崩溃总面临部分数据丢失，这在某些情况下是不能接受的。而sybase对日志的使用策略使很多管理员将日志设为截断方式。这也不稳当，在有复制服务器的时候，有时第二截断点使日志始终无法清除，最后涨满。
有一种方式是利用存储或软件方式形成的快照再对快照进行备份，可以并行地访问数据，并对日志作standby方式的备份（好像需要12以上），但需要暂停对数据库的访问以保证完整性，虽然sybase宣称可以不中止应用而屏蔽访问，但不允许应用有bcp或truncate，这一点实在难以接受，也许很快就会有新的策略吧。

(丁一)
*****************************************************
我也有一点想法，那就是采取截断日志的方式，究竟存在多大的风险？
sybase设计的是先写日志方式，但是如果我们采取裸设备的直接存储的方式，那么在数据库每次chekpoint时，应该已经将缓存中的数据写入了磁盘中，所以，就算系统崩溃，丢失的数据应该只是在一个截断点内的交易信息，所以我觉得对于交易不是非常频繁（每秒不超过10个的系统），采取截断方式的风险不是太大。
丁一所说的：“sybase宣称可以不中止应用而屏蔽访问”，我发现在测试中即使是正在进行备份，交易还可正常进行阿？也许跟我的备份方式有关。

(jazy)
*****************************************************
假如磁盘系统是可靠的，截断日志是没有危险的，就如同我们基本可以杀掉dataserver的进程，重起sybase，会自动恢复。
但如果磁盘故障？raid并不保证安全。raid5只能坏一块盘，raid10运气差的话也只能坏一块。应该说之所以要备份，多数是为了防止这种故障，可以在重建系统时，尽量少的丢失数据。如果我dump到磁带上或另一物理上独立的介质上，我就有了在这一时间点的一个0级备份。在这一点之后，如果没有截断日志，可以持续将日志备份。这样丢失的数据可能是交易级的。
但即使这样，仍有问题需要解决。如何验证备份的介质就是完好的？会影响生产系统的性能吗？操作繁琐吗？现在有远程镜像技术了，911楼都不见了，数据仍然恢复了，但代价对很多系统过于高昂，超过数据丢失的损失。也许备份首先要有一个定位，能接受什么样的损失，愿意付出什么样的代价。

(丁一)
****************************************************

数据库备份方案应该看用户数据的重要性！谈一谈我的备份方案（我的数据比命重要）。
每３０分钟备份一次日志，定时追加备份（我为了安全备份到磁带上，硬盘说不定哪天突然就。。。５５５５５５），每晚备份一次完整库（磁带上），完整库备份完后清一次日志，
经常检查ｂａｃｋｕｐｓｅｒｖｅｒ日志有无错误，特别是备份不成功时！！
定期在做完整库备份前用ｄｂｃｃ检查重要的表！！
备份磁带的分配：２０盘磁带，每天１盘备份完整库、１盘备份日志（每天两盘按天对应），保存一个星期的备份。
（续上贴）备份是很重要的，还别忘了养成经常定期检查系统的状况，如：系统的ｍｅｓｓａｇｅ，ｍａｉｌ等。
谈一次我的经历（想起就冤。。。５５５５）：有一次突然发现数据库出问题了，需要恢复前一天的库，结果无法恢复（５５５），因为每天备份都成功了的，所以奇怪，经检查（花了很长时间，专家会诊（ｓｙｂａｓｅ的人）），  
（续上贴）结果是服务器与阵列之间通讯不兼容的问题造成数据库数据不能使用，结果问题已经发生１０多天了，我还不知道，就因为ｓｙｂａｓｅ未有任何错误警告和日志记录，结果错误警告和日志记录只在系统的ｍｅｓｓａｇｅ中有硬件问题的警告，害的我花了两个星期调整数据（命苦啊）。 ｓｏ 大家一定不要忘了系统的定期检查啊，备份重要，系统好像跟重要！！！  

(hgy1999 )
*****************************************************

不知道大哥您杀了几次dataserver进程，估计您是没有遇到什么问题，您的手气是够好的，建议您以后杀dataserver进程时要三思，否则遇到大面积的表出现6xx，8xx错误，您就会后悔的。
(dangsl )
*****************************************************

决定采用的备份方案：
1、master库 做个原始备份，有新的修改再做备份

2、生产库：
数据：每天凌晨一个整库备份
日志：每小时一个日志备份，同时清空日志

保留一周的备份，每天备份的时候，在阵列上保留最新备份的同时，将其压缩转备到另外的硬盘中。管理员定期完成每周的从该硬盘将备份转移到磁带上。

另外，在备份之前先做dbcc checkdb() ，保证备份的正确性。（虽然会影响交易！）

(jazy)
*****************************************************

我的备份方法比较土：
一、用crontab命令定时调用shell命令备份。备份采用两种方式，1、全库备份：dump database to "/xxx/xxx.bk" at SYB_BKALL，SYB_BKALL是一台专用的服务器上的备份服务器，硬盘较大，2、bcp out，同样在那台专用的备份服务器上定时执行，编了一个shell脚本，把SQL SERVER、username、password、database作为参数，自动将所有表数据备份成为文件。当然检查相应的log文件。然后集中定时倒入磁带。
二、用crontab命令定时调用shell命令做dbcc检查，内容包括update statistics 表名sp_compile 表名，然后对库作dbcc checkalloc。检查相应的log文件。
用这种方法我每天晚上备份了12个库，当然每个库大小都不大最大dump备份文件才的377MB。
以下是我昨天晚上的dbcc的log文件（$DBCCDIR/log/today_dbcc.log）内容。
02-10-30(21:40:00-->;21:40:03): dbcc BSH3_hz_ovnitdb succeed.
02-10-30(21:40:03-->;21:40:05): dbcc BSH3_xa_ovnitdb succeed.
02-10-30(21:40:05-->;21:40:06): dbcc BSH3_fz_ovnitdb succeed.
02-10-30(21:40:06-->;21:40:09): dbcc BSH3_xm_ovnitdb succeed.
02-10-30(21:40:09-->;21:40:17): dbcc BSH3_ovnitdb succeed.
02-10-30(21:40:17-->;21:40:34): dbcc ITS_MSH_itspdb succeed.
02-10-30(21:40:34-->;21:43:45): dbcc ITS_MSH_tbpdb succeed.
02-10-30(21:43:45-->;21:43:57): dbcc ITS_MSH_ibopdb succeed.
02-10-30(21:43:57-->;21:45:32): dbcc ITS_BSH3_itsbdb succeed.
02-10-30(21:45:32-->;21:46:47): dbcc MSH_ibopdb succeed.
02-10-30(21:46:47-->;21:48:12): dbcc BSH3_ibobdb succeed.
02-10-30(21:48:12-->;22:19:17): dbcc CFETSTJ1_infodb error.
今天早上我查了最后一个日志文件（$DBCCDIR/CFETSTJ1_infodb/tmpDbcc.log）的出错信息：
Alloc page 389632 (# of extent=1 used pages=1 ref pages=1)
Msg 2540, Level 16, State 1:
Server 'CFETSTJ1', Line 1:
Table Corrupt: Page is allocated but not linked; check the following pages and
ids: allocation pg#=389888 extent id=389976 logical pg#=389980  object id on
extent=8 (object name = syslogs) indid on extent=0
Alloc page 389888 (# of extent=1 used pages=5 ref pages=1)
syslogs表的问题，关系不大，我抽空解决。
syslog错我还不知道如何处理，我dbcc checkalloc(xxx,fix)也不行。不过好像还能用。
(jackhoo72)
*****************************************************
你在做dbcc时数据库有访问吗？看你的情况是通过crontab处理的，如果不能保证没有用户使用，那么报syslog错应该没什么问题。
(chuxu )
*****************************************************
由于我的数据库晚上都不对外用了，所以我dbcc的时候已经置为单用户状态了，用sp_dboption db,"single user",true。但仍然报syslog错，不过我这个库不太重要，当然，如果那位大侠能指点一下非常感谢。
(jackhoo72)
*****************************************************
Error 2540
Severity Level
16
Error Message Text
Table Corrupt: Page is allocated but not linked; check the following pages and ids: allocation pg#=%ld extent id=%ld logical pg#=%ld object id on extent=%ld (object name = %S_OBJID) indid on extent=%ld
Explanation
This error occurs when dbcc checkalloc determines that a page is marked as allocated to an object but that page is not being used. There is no corruption or data loss associated with this error.
Each 2540 error means the loss of one blank data page. A few 2540 errors are no cause for concern. However, if many of these errors occur, the amount of "lost" disk space could be significant.
Note:The instructions below are for fixing 2540 errors once they have occurred. Two easy-to-use strategies exist for detecting this error sooner in the future. Refer to "Detecting Allocation Errors as Early as Possible" for information about these strategies.
Action
Occasionally dbcc checkalloc reports this error when no real error condition exists. You can either check to determine whether the error is real, or continue with this section and take action to correct it, whether or not it reflects a real allocation error.
Because the process used to discover whether or not the error is real can be time-consuming, you may want to go directly to "Error Resolution" now.
Verifying That the Error Is Real
Run dbcc checkalloc in single-user mode if you suspect the 2540 error messages are incorrect. If the error is in master, use the section "How to Start SQL Server in Single-User Mode" for instructions about how to invoke SQL Server in single-user mode. Refer to "dbcc" in the SQL Server Reference Manual for information about dbcc checkalloc.
Error Resolution
If many of these errors are occurring, it is possible to clear them all at once by using the dbcc checkalloc and dbcc checkalloc with fix option commands. Refer to "How to Fix and Prevent Allocation Errors" for information about using dbcc checkalloc.
If the text of the error message includes a real object name, not a number, then the error is on an existing object which the system catalog has correct references to, and you should continue now to "Identify Table: User or System Table".
If a number appears instead of the object name, then that object only partially exists and the error must be corrected using the procedure described in "How to Fix and Prevent Allocation Errors".
Identify Table: User or System Table
Look at the value for "object id on extent" in the error message. If it is 100 or greater, continue with "Action for User Tables". If the "object id on extent" is below 100, it is a system table and requires a different procedure as described in the section "Action for System Tables".
Action for User Tables
If the "object id on extent" in the error message is 100 or greater, follow these steps to correct the error:
1.Check the value of the "indid on extent" in the error message to determine whether it is a table (value = 0) or an index (value >; 0).
2.Run dbcc tablealloc or dbcc indexalloc, depending on whether the object named in the 2540 error message is a table or an index. Before you run the appropriate command, keep the following in mind:
- dbcc tablealloc corrects this problem on a table or an index, but if the problem is on an index, you can avoid affecting the entire table by using dbcc indexalloc. If the table is large or heavily used, it may be more practical to use dbcc indexalloc.
- These commands can correct the error only when run in the full or optimized mode, and with the nofix option not specified, the default for user tables.
- You can use the object name or object ID in the following commands where the argument "object_name" appears.
Use the command appropriate for your situation:
For Tables (index id in extent = 0)
For Indexes (0 < index id in extent < 255)
1>; dbcc tablealloc (object_name)
2>; go
1>; dbcc indexalloc (object_name,
2>; indid_on_extent)
3>; go
Refer to "dbcc" in the SQL Server Reference Manual and "Checking Database Consistency" in the System Administration Guide for information about dbcc tablealloc and dbcc indexalloc.
Action for System Tables
If the "object id on extent" in the error message is less than 100, follow these steps to correct the error:
1.Put the affected database in single-user mode:
- If the database is master, use the procedure in "How to Start SQL Server in Single-User Mode", and then go to step 2.
- If the database is not master, use the sp_dboption stored procedure to put the affected database in single-user mode:
1>; use master
2>; go
1>; sp_dboption database_name, single, true
2>; go
1>; use database_name
2>; go
1>; checkpoint
2>; go
2.Check the value of the "indid on extent" in the error message to determine whether it is a table (value is 0) or an index (value is greater than 0).
3.Run dbcc tablealloc or dbcc indexalloc, depending on whether the object named in the 2540 error message is a table or an index. Then execute the appropriate command. Before you run the appropriate command, keep the following in mind:
- dbcc tablealloc corrects either a table or an index, but if the problem is on an index, you can avoid affecting the entire table by using dbcc indexalloc. If you need to minimize the amount of time the table is unavailable, it may be most practical to use dbcc indexalloc.
- These commands correct the error only when run in the full or optimized mode, with the fix option specified, because the default value is nofix on system tables.
- You can use the "object name" or "object id on extent" in the commands above where the argument object_name appears.Use the command appropriate for your situation:
For Tables (index id in extent = 0)
For Indexes (0 < index id in extent < 255)
1>; dbcc tablealloc (object_name,
2>; full, fix)
3>; go
1>; dbcc indexalloc (object_name,
2>; indid_on_extent, full, fix)
3>; go
4.Turn off single-user mode in the database:
- If the database is master, refer to "Returning SQL Server to Multiuser Mode".
- If the database is not master, use the following procedure:
1>; use master
2>; go
1>; sp_dboption database_name, single, false
2>; go
1>; use database_name
2>; go
1>; checkpoint
2>; go
Refer to "dbcc" in the SQL Server Reference Manual and "Checking Database Consistency" in the System Administration Guide for information about dbcc tablealloc and dbcc indexalloc.
Releases in Which This Error Is Raised
11.0 and later

( molin  )
*****************************************************

小小感受:
增量备份是个理论概念
全备的同时最好也来个bcp数据备份,这在生产环境中是最实用的. bcp可做在crontab中.
(aladdin )
****************************************************
这个问题我正好前几天遇到了，我们采用11。9，数据量大概每天存储二十万条左右，而且有时实时系统，日志空间我也分配了1G多，我没有备份只是定期清楚，dump tran dbname with no_log ，结果后来用这个也不行了，慢了以后我只好再分配空间，最后，我把所有有关对数据库操做的应用都停了，最后才清调日志，但这也不是办法，用户不大可能自己清，（我们不考虑备份），我把dump tran dbname with no_log写在定时器里，但有时候不起作用，各位又什么更好的办法
(我爱SYBASE)
****************************************************
各位高手，大家的讨论对我很有启发。只是我现在对增量备份（即仅备份日志）有些怀疑，对于一些不完全记日志的操作（select into）对数据库的改变将不能被恢复，是否存在这个问题呢？请各位指点一下。
(joson )
****************************************************
我现在才有点醒悟，我们给用户做的有几张表数据是固定的
剩余两张表，历史数据表，历史告警表是不断变化的，如果可以允许数据库服务停止一段时间，那我们只需要备份我们的数据表不就可以了么，还那么麻烦作这么多库备份，日志备份
最多坏了以后重新装了。只要重要的表数据没丢失就可以了
(我爱SYBASE)