1．需求分析：
? 数据可大致分为业务数据与生产数据
? 业务数据有可用性期间。
? 生产数据需求7*24小时高可用性。
? 目标：
• 保护数据防止各种由硬件、软件、人为误操作造成的数据丢失。
• 增长平均故障间隔时间（MTBF） 尽可能的减少失败次数。
• 减少平均恢复时间（MTTR） 尽可能在最短的时间内恢复数据。
• 最小化数据丢失
• 健壮性 这个数据库系统应该能够自动处理许多系统失败以及数据库失败。并且必须对每个单一失败点
进行标识，同时为每个这种组件提供了相应的冗余组件。
• 透明的失败恢复系统应该提供最大限度的失败恢复透明性，使得主数据库系统在崩溃时能够尽量不影
响系统的整体可用性。需要说明的是，失败恢复不仅是指数据库系统失败的检测功能，时还包括作出相
应响应动作的过程。必须提供一种机制，能够周期性地检测数据库系统的稳定性。如果将这种周期性检
查的周期时间设置过短，那么就有可能会由于经常性的检测动作而导致系统整体性能的下降；而如果将
这种周期性检查的周期时间设置过长，那么就有可能导致数据库系统服务的失败被终端用户所感觉到。
此外，一旦主数据库系统的失败被检测到，所采用的失败恢复策略必须能够重新发现数据库的新连接路
由，以便尽快地与数据库系统建立连接。这时需要注意的是，先前的数据库连接有可能是活跃的也有可
能是非活跃的。其中对于数据库连接的活跃性判断非常关键，2 4×7方式必须保证数据库连接中的应用
程序具有重新启动功能。如果这种功能不能实现，那么数据库的解决方案中就必须提供一种机制，能够
在必要的情况下重新建立应用程序与数据库系统的连接，从而减少应用程序反复调用数据库的开销。有
些时候，数据库系统服务的中断很容易被数据库访问用户所发现，这是因为用户可以明显地感觉到数据
库系统连接被中断。
• 数据完整性2 4×7方式下的数据库系统必须保证数据的完整性，不能允许出现数据的丢失或者数据内
部相关性的冲突。例如，在将所有的数据从主数据库系统传送到备份数据库系统的过程中，不允许出现
任何数据丢失的现象。
• 经济承受能力 实现数据库系统的开销以及数据库系统自身的开销，应该低于不采用2 4×7方式时的比
例。在短时期内， 2 4×7方式数据库系统的开销也许会比较高。但是，随着时间的推移，这种高开销就
会明显地下降，这是因为2 4×7所带来的效益。关于这一点，只有在将2 4×7方式下数据库系统的开销
与潜在的系统停工时间所带来的效益损失进行比较才可以发现。在进行损失计算时，只要考虑在数据库
系统访问的高峰期这个特殊情况就可以得到最坏情况下的损失大小。因为，在其他时间，所造成的损失
应该不会大于此时的损失。
• 优化资源 使用2 4×7方式下的数据库系统应该以尽可能优化的方式来使用系统资源，以便不会到达系
统的饱和状态（特别是在数据库系统访问的高峰期）。
• 系统实现的简单性将公司的数据库系统移植到2 4×7方式下的工作量不应该过大并且系统停工时间以
及服务质量的下降（对于用户来说）必须保证在用户可接受的范围之内（这个范围应该作为考虑系统方
式移植的一个因素）。同时，对相关组件（包括应用程序、安全策略等等）所作的修改必须具有一定的
可行性。
• 系统可维护性 必须保证公司内的系统管理人员能够在不求助于不可行方式（例如，频繁的脱产培训、
复杂的维护工具、高级专家顾问的常规性访问）的情况下进行系统维护。
• 性能在日常的工作中，新的数据库系统不应该影响系统性能。需要说明的是，某种程度上的性能影响
也许会是不可避免的。例如，如果2 4×7方式要求所有的应用程序都必须通过多个数据库（包括位于远
程站点的数据库）才能正常工作，那么网络延迟就有可能会影响应用程序的正常工作。但是，必须保证
这种影响在可接受的范围之内。
2．策略：
? 数据库环境稳定性及性能要求
? 提供底层的冗余系统环境
? 热插拔磁盘阵列系统。
? 网络系统（包括网络服务，例如：DNS）。
? 硬件厂商应提供24小时硬件快速替换服务，例如：主板，CUP等或整机替换。
? 提供至少3块备用硬盘。
? 操作系统及应用程序的备份（用来快速恢复软件环境）--使用软件环境的镜像（GHOST）或
磁带机备份等其他手段，推荐使用磁带机。
? 断电保护：
? 应尽量采用长延时UPS，建议8小时。
? 断电时UPS启动后，隔一定时间发现还没有恢复电，将自动关机，以便保护整个操作系
统和数据库。
? 当突然来电所有系统能自动启动进入工作状态.所有工作不需要人为干预。
? 高速的备份能力—尽量提供多磁盘和多磁带并行系统.。
? 建议，主服务器每两块硬盘做一个RAID 1阵列，每个RAID 1阵列对应一个逻辑盘符。
? 数据库工程师与系统工程师应保持密切的合作。
? 业务数据备份：
? 数据库运行日至归档模式。
? 提供主数据库的备用数据库服务器（BACKUP DATABASE）--备用数据库服务器尽量与主数
据库服务器硬件性能相当，磁盘的逻辑配置应一致。
? 每周六凌晨6:00做一次全库冷备份，此备份在主服上保留一个，同时通过网络往在备服上拷
贝一个(自动执行) 。
? 每天两次备份控制文件、在线日志组和归档日志，上午下班后一次，半夜1：00一次，同样
在主服务器上保留一个拷贝(另一块物理磁盘)，在备用服务器上保留一个拷贝（自动执行）。
? 每周三做备用服务器同步。
? 每半年的数据备份到磁带（6月、12月第一个星期日凌晨1：00 注：日期暂定）。
? 恢复的策略：
? 数据库失败的恢复：直接在主服务器上用冷备份加归档日志恢复。
? 操作系统级崩溃的恢复：启用备份服务器，在主服务器上用冷备份加归档日志恢复。
? 磁盘失败：依靠磁盘阵列恢复。
? 生产数据库备份：
? 生产数据库主服务器采用双机CLUSTER。
? 生产数据库运行日志归档模式
? 提供生产数据库的备用数据库服务器（BACKUP DATABASE）--备用数据库服务器尽量与生
产数据库服务器硬件性能相当，磁盘的逻辑配置应一致。
? 提供专用服务器处理第三方备份。
? 选定专业备份软件自动管理。
? 此服务器使用RAID5磁盘阵列。
? 该专业备份软件应实现以下功能
? 应能实现跨平台(UNIX、Windows NT/2000)的数据备份/恢复(包括磁带库备份、单
键恢复磁带备份、光盘备份)的集中化管理，能对数据备份/恢复工作的实时状态进
行监控和管理。
? 应能按照用户定义的数据备份策略自动实现数据备份，如可以定义马上开始执行备
份，或可以按一定的时间间隔定义备份策略。
? 应能详细记录所有备份的历史记录，包括备份的版本、时间、方式(完全备份或增
量备份);应能通过查阅记录信息，随时了解系统备份情况。
? 应能和现有的系统管理平台集成在一起，通过系统管理的界面可以进入数据备份/
恢复的配置、管理界面，通过事件管理窗口，可以浏览实时发送的备份数据信息。
? 应能将数据备份到现有的磁带库中，并能从磁带库上恢复数据。
? 对以后新增加的服务器、工作站和应用系统，如未购买新的许可证，应至少可以备
份目录和文件。
? 应能在线和脱机备份并恢复UNIX系统、NT系统的数据，包括系统配置数据、注册
表文件、目录、裸设备等。
? 应能在线和脱机备份并恢复正常状态下UNIX Cluster、NT Cluster两结点及共享磁
盘阵列的所有数据(文件、目录、裸设备),包括:系统数据、应用数据、以及创建于
Cluster架构之上的所有资源信息。
? 应能在线和脱机备份并恢复DB2与其它数据库管理系统的系统数据和数据库中的业
务数据，能对表进行独立备份恢复。
? 应能对所有带磁带机的服务器制作单键恢复磁带，并进行单键恢复。
? 应能完全恢复备份服务器本身的所有数据，并能恢复到最后一次备份后的时刻。
? 应能在一个工作日内恢复全部系统(硬件损坏除外)。
? 全库备份：
? 每周六凌晨6:00做一次全库冷备份。
? 每天两次备份控制文件、在线日志组和归档日志，上午下班后12：00一次，半夜1：00
一次。
? 每周三中午12：00做备用服务器同步。
? 每月一次全库冷备份（第一个星期日凌晨1：00）。
? 辅助备份——表备份：
? 大型事务表，含有数据库中大部分原始数据。
? 定时导出事务表，数据可依赖导入备份实现快速恢复。
? 对数据量大的表（主表）应分区备份，提高恢复速度。
? 聚集表，存储从事务表中聚集来的数据。
? 创建后导出表，恢复时主要依赖表重建。
? 代码表。
? 有较大变动后将其导出，恢复时主要依赖于导出操作。
? 临时工作表。
? 数据装载的每一步后都进行导出，恢复时主要依赖于数据重新装载。
? 日常作业
? 对每种备份的恢复功能都应当测试，确保备份方法能达到预期目标，并量化MTTR 与
MTBF。
? 至少保存两份最新的备份。
? 每天查看一次备份日志。
? 建立备份文档及维护记录。
? 建立数据库跟踪文档。
? 用户教育
? 建议：
? 使用DVD刻录机保存历史数据。
备用服务器与主服务器放置在不同的物理位置，至少相距100米