没人了解测试备份远比数据库管理员(DBA)重要。然是对于大多数公司来说,依赖磁带备份进行灾难恢复既不合适也不可靠,在本文中,我们考虑的是个各种灾难恢复解决方案的优缺点。 在你选择一种灾难恢复技术之前,你先要确定你的目标。如那些金融领域里的一些公司就不能容忍任何数据丢失。
而对于另一些公司来说,高可用性才是最主要的。新闻媒体和通信公司将在灾难期间经历高要求负荷。 SQL Server灾难恢复基本点 你的灾难恢复计划应该完整并要包含各种依赖项。虽然存储最新版的SQL Server是基础,但是你还必须保证SQL Server所有的属性都比较适当。
Windows用户,文件系统依赖项、应用软件……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号

TechTarget
官方微博

TechTarget中国
没人了解测试备份远比数据库管理员(DBA)重要。然是对于大多数公司来说,依赖磁带备份进行灾难恢复既不合适也不可靠,在本文中,我们考虑的是个各种灾难恢复解决方案的优缺点。
在你选择一种灾难恢复技术之前,你先要确定你的目标。如那些金融领域里的一些公司就不能容忍任何数据丢失。而对于另一些公司来说,高可用性才是最主要的。新闻媒体和通信公司将在灾难期间经历高要求负荷。
SQL Server灾难恢复基本点
你的灾难恢复计划应该完整并要包含各种依赖项。虽然存储最新版的SQL Server是基础,但是你还必须保证SQL Server所有的属性都比较适当。Windows用户,文件系统依赖项、应用软件和服务器的其他方面都必须有,因为一些灾难恢复计划通常是由于硬件依赖项没有在适当的位置,包括在不同地点的磁带驱动、丢失了受密码保护的磁带的密码、固件的错误版本或者是磁带进行自行驱动。
你的灾难恢复计划还应该尽可能简单。一些灾难恢复计划限制了那些能够在来源服务器上做的东西,例如你是否能够改变使用数据库镜像时的恢复模式。而其他技术要求一些重要步骤从而确保灾难恢复地点及时更新:复制和日志传送(log shipping)不会复制注册,并且很有必要用另外一些步骤保证所有登陆都就位到目前灾难恢复的地点。
其他解决方案在确定执行地点之间会要求一些重要时间,如一些软件数据库镜像解决方案在登陆数据库之前就要花些时间。执行灾难恢复计划是一项涉及到许多步骤的复杂操作,只迁移少部分简单计划既减小了复杂程度,同时又增加了灾难恢复计划的可靠性。
自动恢复(failback)计划也很重要。一旦灾难恢复站点可以执行了,它就会包括这些更改。当你准备返回到你的原始地点,这些更改就会和你一起迁移。
恢复地点还需要足够的网络带宽来支持数据流同步。这项工作还要考虑到:如果发生灾难,该地点就有足够的硬件来支持更大负荷而不是它主要的数据中心。原因就是在灾难期间,人们会比平常时段更频繁使用公司资源。相反,一些名贵珠宝零售商将站点设计成只支持最小核心业务功能。他们意识到,如果发生灾难,更多客户就不会购买贵商品。
最后,灾难恢复计划应该及时更新。用旧版本的数据库的恢复地点对于目前访问这些数据的应用版本没有用。我咨询的一些大型在线销售点在灾难恢复地点进行开发和质量保证,确保该站点还保留有数据中心的精确版本。
翻译
相关推荐
-
Linux支持的引入 推动了SQL Server 2016集成服务的发展
随着SQL Server的不断发展,集成服务也在发生相应的变化。在最新的SSIS更新中,增加Linux支持和SQL Server 2016升级向导。
-
Notre Dame对云端SQL Server性能基准的探索实践
确立SQL Server的性能基准,对于云端迁移来说是至关重要的第一步,一位来自于University of Notre Dame 的DBA表示,他正在试图通过数据库监控软件,找出SQL server的性能基准。
-
横向扩展SQL Server应用程序:提高工作负载的选项
SQL Server管理员面临的最大挑战之一就是扩展数据库以适应更为繁重的数据处理工作负载。然而事情越发复杂的是,虽然Microsoft提供了许多不同的SQL Server可扩展性选项,但它们并不都适合于每种情况。
-
五大技巧构建首个SQL Server容器
容器的世界庞大而复杂,使用者可能会感到困扰,这里我们将列出一些示例,以便引导您顺利完成SQL Server容器的创建和管理。