ORACLE备 份 策 略.doc

备份策略1需求分析： 数据可大致分为业务数据与生产数据 业务数据有可用性期间。 生产数据需求7*24小时高可用性。 目标： 保护数据 防止各种由硬件、软件、人为误操作造成的数据丢失。 增长平均故障间隔时间（MTBF） 尽可能的减少失败次数。 减少平均恢复时间（MTTR） 尽可能在最短的时间内恢复数据。 最小化数据丢失 健壮性 这个数据库系统应该能够自动处理许多系统失败以及数据库失败。并且必须对每个单一失败点进行标识，同时为每个这种组件提供了相应的冗余组件。 透明的失败恢复系统 应该提供最大限度的失败恢复透明性，使得主数据库系统在崩溃时能够尽量不影响系统的整体可用性。需要说明的是，失败恢复不仅是指数据库系统失败的检测功能，时还包括作出相应响应动作的过程。必须提供一种机制，能够周期性地检测数据库系统的稳定性。如果将这种周期性检查的周期时间设置过短，那么就有可能会由于经常性的检测动作而导致系统整体性能的下降；而如果将这种周期性检查的周期时间设置过长，那么就有可能导致数据库系统服务的失败被终端用户所感觉到。此外，一旦主数据库系统的失败被检测到，所采用的失败恢复策略必须能够重新发现数据库的新连接路由，以便尽快地与数据库系统建立连接。这时需要注意的是，先前的数据库连接有可能是活跃的也有可能是非活跃的。其中对于数据库连接的活跃性判断非常关键，2 47方式必须保证数据库连接中的应用程序具有重新启动功能。如果这种功能不能实现，那么数据库的解决方案中就必须提供一种机制，能够在必要的情况下重新建立应用程序与数据库系统的连接，从而减少应用程序反复调用数据库的开销。有些时候，数据库系统服务的中断很容易被数据库访问用户所发现，这是因为用户可以明显地感觉到数据库系统连接被中断。 数据完整性 2 47方式下的数据库系统必须保证数据的完整性，不能允许出现数据的丢失或者数据内部相关性的冲突。例如，在将所有的数据从主数据库系统传送到备份数据库系统的过程中，不允许出现任何数据丢失的现象。 经济承受能力 实现数据库系统的开销以及数据库系统自身的开销，应该低于不采用2 47方式时的比例。在短时期内， 2 47方式数据库系统的开销也许会比较高。但是，随着时间的推移，这种高开销就会明显地下降，这是因为2 47所带来的效益。关于这一点，只有在将2 47方式下数据库系统的开销与潜在的系统停工时间所带来的效益损失进行比较才可以发现。在进行损失计算时，只要考虑在数据库系统访问的高峰期这个特殊情况就可以得到最坏情况下的损失大小。因为，在其他时间，所造成的损失应该不会大于此时的损失。 优化资源 使用2 47方式下的数据库系统应该以尽可能优化的方式来使用系统资源，以便不会到达系统的饱和状态（特别是在数据库系统访问的高峰期）。 系统实现的简单性 将公司的数据库系统移植到2 47方式下的工作量不应该过大并且系统停工时间以及服务质量的下降（对于用户来说）必须保证在用户可接受的范围之内（这个范围应该作为考虑系统方式移植的一个因素）。同时，对相关组件（包括应用程序、安全策略等等）所作的修改必须具有一定的可行性。 系统可维护性 必须保证公司内的系统管理人员能够在不求助于不可行方式（例如，频繁的脱产培训、复杂的维护工具、高级专家顾问的常规性访问）的情况下进行系统维护。 性能 在日常的工作中，新的数据库系统不应该影响系统性能。需要说明的是，某种程度上的性能影响也许会是不可避免的。例如，如果2 47方式要求所有的应用程序都必须通过多个数据库（包括位于远程站点的数据库）才能正常工作，那么网络延迟就有可能会影响应用程序的正常工作。但是，必须保证这种影响在可接受的范围之内。 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）。 辅助备份表备份： 大型事务表，含有数据库中大部分原始数据。 定时导出事务表，数据可依赖导入备份实现快速恢复。 对数据量大的表（主表）应分区备份，提高恢复速度。 聚集表，存储从事务表中聚集来的数据。 创建后导出表，恢复时主要依赖表重建。 代码表。 有较大变动后将其导出，恢复时主要依赖于导出操作。 临时工作表。 数据装载的每一步