[讨论]大家讨论一下在使用sybase过程中，数据库备份策略_SyBase_学习笔记★闵涛★计算机学习电脑编程软硬件技巧


	转至繁体中文版	\| 网站首页 \| 图文教程 \| 资源下载 \| 站长博客 \| 图片素材 \| 武汉seo \| 武汉网站优化 \|

[讨论]大家讨论一下在使用sybase过程中，数据库备份策略

作者：闵涛文章来源：闵涛的学习笔记点击数：2053 更新时间：2009/4/22 23:10:00

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

基本过程很简单，如下：
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、数据库在恢复时可能出现哪些紧急情况
等等...

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

miniyoyo2002 回复于：2002-10-09 17:21:32 偶们的数据库比较小，不需要经常备份！
即使备份也是整库备份！

jazy 回复于：2002-10-09 17:51:30 那估计你设置了 trunc log on chkpt 为 true了吧！

要不然，你也得经常截断日志！

jazy 回复于：2002-10-09 18:55:42 建议斑竹将该页置顶如何？

miniyoyo2002 回复于：2002-10-09 18:59:55 我同意，支持！

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

jazy 回复于：2002-10-10 09:48:29 我也有一点想法，那就是采取截断日志的方式，究竟存在多大的风险？
sybase设计的是先写日志方式，但是如果我们采取裸设备的直接存储的方式，那么在数据库每次chekpoint时，应该已经将缓存中的数据写入了磁盘中，所以，就算系统崩溃，丢失的数据应该只是在一个截断点内的交易信息，所以我觉得对于交易不是非常频繁（每秒不超过10个的系统），采取截断方式的风险不是太大。

丁一所说的：“sybase宣称可以不中止应用而屏蔽访问”，我发现在测试中即使是正在进行备份，交易还可正常进行阿？也许跟我的备份方式有关。

月冷西湖回复于：2002-10-10 12:23:30 很经典的论题！

jazy 回复于：2002-10-10 13:04:05 希望大家能多发表点自己的想法！

molin 回复于：2002-10-10 13:49:56 备份策略各人应该根据自己的系统架构,环境,应用情况来制订的

jazy 回复于：2002-10-10 13:54:34 molin说的不错，的确，不同的系统备份策略不尽相同，但你能否具体点，说说自己的情况呢？

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

hgy1999 回复于：2002-10-13 12:07:10 数据库备份方案应该看用户数据的重要性！谈一谈我的备份方案（我的数据比命重要）。
每３０分钟备份一次日志，定时追加备份（我为了安全备份到磁带上，硬盘说不定哪天突然就。。。５５５５５５），每晚备份一次完整库（磁带上），完整库备份完后清一次日志，
经常检查ｂａｃｋｕｐｓｅｒｖｅｒ日志有无错误，特别是备份不成功时！！
定期在做完整库备份前用ｄｂｃｃ检查重要的表！！
备份磁带的分配：２０盘磁带，每天１盘备份完整库、１盘备份日志（每天两盘按天对应），保存一个星期的备份。

hgy1999 回复于：2002-10-13 12:22:17 （续上贴）备份是很重要的，还别忘了养成经常定期检查系统的状况，如：系统的ｍｅｓｓａｇｅ，ｍａｉｌ等。
谈一次我的经历（想起就冤。。。５５５５）：有一次突然发现数据库出问题了，需要恢复前一天的库，结果无法恢复（５５５），因为每天备份都成功了的，所以奇怪，经检查（花了很长时间，专家会诊（ｓｙｂａｓｅ的人）），

jazy 回复于：2002-10-13 12:28:12 谢谢 hgy1999 的备份方案，　我想对于大部分交易型数据库，为了确保数据的安全，都应该象 hgy1999 那样对数据进行完整备份。在对重要表进行dbcc时，若数据量很大可能会花较长的时间，并会造成交易阻塞。另外要做到经常检查backup server的日志，最好还是采用自动检测告警的方式.以确保备份的正确性！

hgy1999 回复于：2002-10-13 12:31:44 （续上贴）结果是服务器与阵列之间通讯不兼容的问题造成数据库数据不能使用，结果问题已经发生１０多天了，我还不知道，就因为ｓｙｂａｓｅ未有任何错误警告和日志记录，结果错误警告和日志记录只在系统的ｍｅｓｓａｇｅ中有硬件问题的警告，害的我花了两个星期调整数据（命苦啊）。ｓｏ大家一定不要忘了系统的定期检查啊，备份重要，系统好像跟重要！！！

jazy 回复于：2002-10-13 12:41:11 [quote][b]下面引用由[u]hgy1999[/u]在 [i]2002/10/13 12:31pm[/i] 发表的内容：[/b]
（续上贴）结果是服务器与阵列之间通讯不兼容的问题造成数据库数据不能使用，结果问题已经发生１０多天了，我还不知道，就因为ｓｙｂａｓｅ未有任何错误警告和日志记录，结果错误警告和日志记录只在系统的ｍｅｓ ...
[/quote]
真不知道你们是个什么系统阿，问题发生了10天，都没有用户投诉吗！我们这个系统就不行了，只要有几分钟不能使用就有人投诉的！

hgy1999 回复于：2002-10-14 10:00:40 你的系统一定是客户服务系统，而我的系统是内部物流控制系统，历史数据一般在月底才用，而发生问题时正常数据录入没有问题（表面上看）。jazy 你每天不是都活在高度紧张中。：）

jazy 回复于：2002-10-14 11:40:54 haha,知我者，hgy1999 也，是啊，比较紧张，责任重大，不过以后不会是我维护！

jazy 回复于：2002-10-17 13:36:17 我在考虑，日备的数据是保存到磁带上还是直接保存在硬盘（非阵列）上。如果保存在别的机器的硬盘上，则不需要经常更换磁带，而且现有条件可能不能使用带库！

大家觉得呢？

guoyunzhi 回复于：2002-10-18 16:32:27 太好了。我们单位只是晚上进行一次数据库完整备份，对日志没有进行备份。看样子，我要重写备份方案。

jazy 回复于：2002-10-19 11:02:38 哈哈，看你们数据库的具体情况了！

dangsl 回复于：2002-10-21 17:35:46 不知道大哥您杀了几次dataserver进程，估计您是没有遇到什么问题，您的手气是够好的，建议您以后杀dataserver进程时要三思，否则遇到大面积的表出现6xx，8xx错误，您就会后悔的。

jazy 回复于：2002-10-22 13:01:39 考虑再三！我决定采用仅保证一小时内数据可丢失的备份策略！
由于omniback没配起来，就不使用他了，改用硬盘了，为了防止数据被一窝端，备份数据除了保存在阵列中的一个整库备份和12小时的日志备份外，同时在主机上保留前两天的备份和今天的备份。

hugwh 回复于：2002-10-23 10:08:34 我个人认为还是完全备份来的妥当，最后也能够定期备份MASTer库

jazy 回复于：2002-10-24 12:18:18 决定采用的备份方案：

1、master库做个原始备份，有新的修改再做备份

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

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

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

jazy 回复于：2002-10-27 14:06:02 大家有没有制定用Omni Back 来备份sybase的备份方案的经验?

使用Omni Back 可以非常方便的实现将数据自动备份到磁介质中.但是对于数据库的俄备份,我们可能还需要进行一些pro exec 和post exec 操作,但是如何进行这方面的操作呢,能否在执行整库备份之前先执行一下dbcc呢? 具体如何做?

jazy 回复于：2002-10-29 14:09:59 ok!no problem!I have get it!

jackhoo72 回复于：2002-10-31 09:45:38 我的备份方法比较土：
一、用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表的问题，关系不大，我抽空解决。

jazy 回复于：2002-11-01 18:02:58 to jackhoo72 :其实你的备份方式还是非常可靠的。基本上属于二次备份的双保险的模

[1] [2] [3] 下一页

没有相关教程

教程录入：mintao 责任编辑：mintao

上一篇教程： Sybase11.0.3 序列号。

下一篇教程： sybase基础知识

【字体：小大】【发表评论】【加入收藏】【告诉好友】【打印此文】【关闭窗口】

注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网]

　网友评论：（只显示最新10条。评论内容只代表网友观点，与本站立场无关！）

同类栏目

· Sql Server  · MySql
· Access  · ORACLE
· SyBase  · 其他

热门推荐

没有教程

赞助链接

闵涛博文

500 - 内部服务器错误。

您查找的资源存在问题，因而无法显示。

鄂公网安备 42011102001154号

站长：MinTao ICP备案号：鄂ICP备11006601号-18

闵涛站盟:医药大全-武穴网。A打造B、C、D……