数据库备份和恢复方案毕业论文样本.doc

资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。备份和恢复方案 恢复方案在被真正付诸实施之前一般是不会得到检测的, 理由是没有时间或资源来 检测此方案, 由此阻止了数据的复原。如果你没有足够丰富渊博的知识来建立一个正确的备份方案, 那么当恢复问题出现时, 你可能会付出很大的代价。能够熟悉所有的恢复过程, 并按照可接受的恢复手段创立正确的备份方案, 可能即是你成功的关键。如果正确的备份方案得不到实施时, 你就会认为你的系统属于不可恢复的。多熟悉和了解备份和恢复方面的知识, 就能够创立一个完整的备份方案来保护你的系统。这篇文章介绍了很多知识技巧, 以助你创立一个完整的方案。 备份策略-快速参考 如下的备份方案是可行及有效的: * 全部和部分卸出( 数据) * 增量卸出数据( 一般不采纳) * 映象备份 * 热备份 * 归档 * 整个文件系统的复制 * 以上方法能够组合使用( 建议) 建议的备份方案包含如下: . Oracle执行程序( 映象) - 每月到每两周( 或执行程序改变时) . 完整卸出 - 一周一次( 如果在一个较频繁的开发环境中可增加次数) . 完整映象 - 每晚( 较好) 到每周 . 归档 - 激活( 肯定) 缩短备份时间及缩短数据库关闭时间: . 当数据库运行时能够使用热备份方式 . 备份到磁盘上而不是磁带上 缩短恢复时间 . 在磁盘而不是磁带上保存最近期的备份和归档文件 避免发生意外 . 多个Redo Log( 增加每一个Redo Log组的成员) . 卸出数据加归档( 对单个表丢失的恢复) . 控制文件的多个拷贝 . 数据库关闭时的映象备份( 冷备份) . 备份和恢复过程应制成文档 恢复策略 - 快速参考 如果你没有足够的知识来应用正确的恢复过程, 请不要盲目去做! 因为如果恢复的方法不正确, 那么可能会给系统造成更多的伤害。解决之道就是立即学习! 不要等到问题出现了才去学习正确的恢复手段。 成功的数据库恢复依赖下列条件: . DBA知识 . 实施正确的备份过程 . 认识到真正问题所在 . 采用正确的恢复办法 . 可用的备份文件 DBA决定采用哪一种恢复方案: . Instance恢复( 一般只是启动) . 用户错误恢复( 一般只是恢复用户创立的事务) . 进程恢复( 一般是数据库的关闭和启动) . 失败语句的恢复( 一般只是修复用户建立的事务) . 介质恢复( 是最难办的问题, 请看下面) 在恢复一个数据之前, DBA必须知道以下所列的哪一个被破坏了: . Database files( 对应系统中的表空间) . Redo Logs( On-line Redo Logs) . Archive Logs( Off-line Logs) . INIT.ORA( 如果丢失能够重建) . Control Files( 是否有可用的拷贝) 然后, DBA可用有效的指令处理恢复过程。 在进行下列三种恢复时数据库的状态: DB On-LineDB Off-Line数据库NoYes表空间YesNo数据文件YesYes 映象备份 所谓映象备份就是把数据库的关键文件拷贝到另一个目录的备份方法。映象备份或许是最快及最安全的备份Oracle的方法, 但其中的一个问题是你只能恢复到做映象备份的那一时间点。另一个问题就是在备份时必须先关闭数据库。多数与映象备份相关的问题能够经过日志归档来解决, 而用日志归档来恢复要依靠一个完好的映象备份( 数据库是关闭的) 。如果可能的话, 映象备份最好拷贝到磁盘上。然后启动数据库( 用户能够开始工作) , 再把映象备份拷贝到磁带上。 必须要拷贝的文件如下: . 所有Database File . 所有Control File . 所有On-Line Redo Log( 不归档) . INIT.ORA和CONFIG.ORA文件( 选择; 能够重建) 映象备份的优势及不足 优点: . 非常快的备份方法( 只需拷贝文件) . 易于归档( 简单的拷贝) . 易于及时恢复到某个时间点( 只需将备份文件复制回来) . 能够和日志归档方式结合使用, 能够恢复到数据库失败的时间点 . 易于维护, 很安全。 缺点: . 在备份时数据库要关闭 . 如果磁盘空间有限, 你或许不得不将它拷贝到速度很慢的磁带上 . 不能恢复单个表或用户 最好的用法: . 和日志归档一起使用 . 如磁盘空间允许, 先拷贝到磁盘上, 然后在数据库运行后再拷贝到磁带上 日志归档( 特别推荐) 日志归档是指Oracle自动将Redo Log备份( 拷贝) 到一个叫做归档文件的文件上。当用户改变数据库的数据( UPDATE,INSERT,DELETE.等等)时, 这种改变就被记录到”On-Line”Redo Log中。因为On-Line Redo Log能够重用, 如果被重用, 则记录在这个Redo Log中的所有修改信息将被覆盖。因此,DBA可将归档方式激活, 这样Oracle能够自动将备份到叫做归档文件的文件上, 而且所有的修改信息能够在归档文件中被保存。 激活归档方式的步骤: 编辑你的INIT.ORA文件以激活归档方式 在INIT.ORA文件中增加如下内容: LOG_ARCHIVE_START=TRUE LOG_ARCHIVE_DEST=/Oracle7/archive/arch 注意: 目录( /Oracle7/ archive) 是你自己创立的, 或者直接写到磁带上:”arch 是归档文件的前缀。 将数据库设置到ARCHIVELOG模式 $sqldba lmode=y( 或svrmgrl, 7.3版以上) SQLDBACONNECT INTERNAL SQLDBASTARTUP MOUNT SQLBDAALTER DATABASE ARCHIVELOG( 激活归档方式) SQLDBAALTER DATABASE OPEN SQLDBAARCHIVE LOG LIST( 看归档状态; 如下所示) DATABASE log mode ARCHIVEOG Automatic archival ENABLED Archiive destination /oracle7/archive/arch Oldest Online log seq.155 current log sequence 156 SQLDBAEXIT 注 意: 如果运行在归档模式, Oracle将启动一个叫做ARCH的后台进程, 可经过相应的操作系统命令看到这个进程。热备份优点: . 能够在数据库运行状态下进行 . 能够恢复到秒级 . 对于几乎所有的Instance恢复都可经过热备份进行恢复 . 恢复快, 大多数情况下可在数据库启动状态下进行 . 对于Oracle7版, 更易于维护 缺点: .恢复过程要绝对正确, 否则问题会更糟 .如果备份不起作用, 则无法恢复到失败点 .恢复步骤要小心, 难于维护 .如果一个归档文件被破坏了, 则必须重头再来 最适用于 .用于数据库”不能中断”有环境下 .24小时运行环境 .在必须快速恢复而且不影响整个系统的情况下 .DBA有足够的时间来维护必要的文件一些Oracle7.1的变化 .备份的”热”指没有”开始”和”结束备份”的 .”Alter tablespaceread only”命令( 仅一个备份需要在只读情况下) .并行恢复-较快的恢复 备份例子 确认要备份的数据文件: SELECT NAME, STATUS FROM SYS.V$DATAFILE; .NAME将返回数据文件的名字, 如: /oracle7/dbs/systora7.dbf .STATUS返回的值可为SYSTEM, ONLINE或OFFLINE 确认要备份的数据库的On-Line Redo Log: SELECT GROUP#, MEMBER FROM SYS.V$LOGFILE; .GROUP#将返回组号 ;如1,2或3 .MEMBER将返回物理文件的名字, 如: /Oracle7/dbs/log1ora7.dbf 确认要备份的数据库的控制文件: SQLDBASHOW PARAMETER contral_files; .该命令将返回 Name: control_files Type: string Value: Oracle7/dbs/ctrlora7.ctl 确认表空间和数据库文件的对应关系, 以及数据库文件的大小: SELECT TABLEAPACE_NAME, FILE_NAME, BYTES, STATUSFROM DBA_DATA_FILES; .该命令将返回表空间名 : 如SYSTEM, USERS等 .文件名: 如/Oracle7/dbs/systora7.dbf .大小: 如20,000,000,000 .状态: AVAILABLE或INVALID 确认那一个数据文件现在正在备份( 热备份) SELECT FILE#, STATUS FROM V$BACKUP; .File#将显示那一个数据文件正在备份: 如”1”或”2” .STATUS将显示: ACTIVE( 正在备份) 或INACTIVE 备份控制文件到Trace文件中( 可用之方便地重建控制文件) ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS; 全数据库export的部分参数文件 system/manager FULL=Y COMPRESS=Y GRANTS=Y ROWS=Y 对某个表空间做完整的热备份步骤: $sqldba lmode=y (或svrmgrl) SQLDBACONNECT INTERNAL SQLDBAALTER TABLESPACE tblspc_to_backup BEGIN BACKUP; SQLDDBAHOST cp /oracle7/dbs/tblsp1.dbf /backup/tblsp1.dbf SQLDBAALTER TABLESPACE tblspc_to_backup END BACKUP; 恢复策略 -举例说明 情况 .星期一晚11:00点: 整个数据库的映象备份 .星期二( 整天) : 保存所有的日志归档文件 .星期二晚10:00( 在下一个备份完成以前) 所有数据库文件被破坏, 系统不能运行。 恢复过程 .恢复星期一傍晚11:00点的映象备份( 不要恢复控制文件或日志文件) .恢复所有的归档文件到新的数据库 .恢复On-Line Redo Log( 还没有归档) 到新的数据库 .数据库恢复到失败前的状态 预防措施 .控制文件有多个复制 .日志文件有多个复制 .总是使用ARCHIVELOG方式 .使用export做为备份模式的一部分 一般原则 .如果有On-Line Redo Log和Off-Line Redo Log,则使用COMPLETE RECOVERY .如果缺少On-Line Redo Log或Off-Line Redo Log, 则使用INCOMPLETE RECOVERY .如果当前的控制文件丢失, 就使用备份的控制文件或重建 介质失败的恢复 这是一个极其复杂的处理过程。所有主要可能的方案归档为下面的两种( 归档模式的恢复; 没有归档模式的恢复), 请根据你的系统失败的原因采用相应的方式, 无论何种情况, 解决硬件问题是相当重要的, 它是解决问题的前题。如果没有把握解决问题, 则暂时先不要动, 因为恢复过程不正确将会出现严重后果。如果读了DBA手册以后, 还是不能确定如何做的话; 请打电话给你的技术支持, 以获得帮助! 注意: .归档用于映象备份, 不是Export! .失败现场的备份在RESETLOGS被执行前, 任何时间都能够做, 但建议在做恢复之前备份失败现场 .恢复成功以后, 要马上做一次备份! 下面这几种情况下的恢复( 归档方式) Oracle手册还没有包括下面15种错误的恢复, 除非你自己一节一节的把纠错方案 放在一起, 因此很容易造成恢复的错误, 要恢复这15种错误是很麻烦的( 要确 定一个正确的恢复方法时, 请参考Oracle7管理指南。) 1. 丢失所有文件( 包括数据文件、 redo log、 归档文件和控制文件) 2a. 只丢失数据文件-数据库正在运行 2b. 只丢失数据文件-数据库已经关闭 3a. 只丢失redo log文件的恢复( 日志文件未被访问) 3b. 只丢失redo log文件的恢复( 日志文件已被访问) 4. 只丢失归档文件 5a. 只丢失控制文件( 还有其它几个控制文件) 5b. 只丢失控制文件( 所有的控制文件都被损坏) 6. 丢失数据文件, redo log和归档文件-无归档模式 7a. 丢失数据文件, 归档文件和控制文件-有归档模式 7b. 丢失数据文件, 归档文件和控制文件-有归档模式 8. 丢失数据文件, redo log和控制文件 9. 丢失数据文件和redo log 10a.丢失数据文件和归档文件-无归档模式 10b.丢失数据文件和归档文件-有归档模式 11. 丢失数据文件的控制文件 12. 丢失redo log, 归档文件和控制文件 13. 丢失redo log和归档文件的恢复 14. 丢失redo log和控制文件的恢复 15. 丢失归档文件和控制文件的恢复 Import/Export-概述 Import和Export是Oracle的两个实用程序。Import/Export备份方法比较可靠, 但对速度不算很快。它最适用于恢复单个的表( 如你使用映象备份, 要恢复单个表是很困难的) , 一个Export出来的文件是能够恢复一个单独表。对开发环境来说, 由于开发者经常修改或删除表, 这种备份方法就比较适用。 优点: . 从整个数据库备份中能够恢复单个表 . 是安全和有效的 . 当恢复时, 能对表重新配置和清除碎块 . 整个数据库是在一个文件里 . 能以方便在不同的操作系统之间移动数据 . 能从一个用户移动数据到另一个 缺点: . 在备份以后数据没法追加( 只能恢复到备份的时间点) . 恢复时间较慢 . 数据库必须关闭以后得到一致性的备份 . 太容易维护 最适用于 . 与其它类型的备份交替, 例如归档 . 在非常少的数据更新时( 能重新产生) , 每天都做( 一个静态备份) . 开发环境情况下, 表被”意外”删除。 对象( 所有对象的统计数目) ; 在重建之前使用 * Database object count by owner by object type * set termout on set numwidth 3 set wrap on set verify on set recsep off set feedback on set space 2 set newpage 0 set pagesize 60 set linesize 79 set tab off set echo off break on today column today new_value_date select to_char(sysdate,mm/dd/yy)today from dual; clear break ttitle leftdesc_01.sq1 right printed: _date skip 1- center Database object Count by owner by object typeskip 2; btitle skip 2 center page SQL.PNO break on owner skip 2 column count format 9,999 heading count column owner format a30 heading owner column object_type format a30 heading Type spool desc_01.lis select owner,count(*) count,object _type from sys.dba_objects group by owner,object_type; spool off; exit; 数据库所有对象数目的统计可用于帮助DBA确认所有的实体是否已经被成功的重建。对DBA来说, 这是数据库完整与否的决定清单。做为一个DBA来说, ”实践是最重要的”, 每一个恢复的要求是必定要成功的。因此要练习你的恢复方案, 更加重新完善你的备份方案。如果你不是DBA, 也能够经过浏览Oracle DBA指南来找到一个方法来恢复你的系统。 归档备份技巧1.概念: 采用归档方式的目的在于当发生例程或介质失败时能最大限度的恢复数据, 以及进行联机的数据库备份。采用归档方式要求数据库必须处于archive log模式, 即采用Create database archivelog命令创立数据库, 或数据采用Noarchive log命令创立后, 用命令Alter database archive log将数据库改为archive log模式, 归档是指Oracle后台进程ARCH对Redolog文件进行拷贝。 设定自动归档模式的方法为设置数据库初始化参数log_archive_start=true, 这样, 后台进程ARCH被启动, ARCH搜索并拷贝非活动状态的redolog文 件。手工归档方式是指数据库已设定归档方式, 而且以参数log_archive_start=false( 缺省值) 启动。尽管这种方式使用户能够控制redo log文件何时被拷贝, 但并不推荐采用这种方式, 手工归档方式使数据库难以管理。例如: 当事务处理突然非常繁忙时, 数据库可能回挂死, 等待日志文件被手工 归档, 然而手工归档能够与自动归档相结合。 三个常见的手工归档命令: Alter system archive log all-归档所有的非活动的redo log文件 Alter system archive log next-只归档所下一个非活动的redo log文件 Alter system archive log current-归档所有的非活动的redo log文件和当前的 redo log文件 其中archive log all是最常见的命令, 它能够归档除当前的和已被归档的 以外所有的redo log文件。 线索(Thread)是并行服务器用到的概念。然而它对于并非服务器的备份与恢复也同样有效。一个线索包括在线的redo log文件和已被归档的日志文 件部分, 对于非并行服务器, 只有一个线索和多个redo log group。而并行服务器具有与并行例程相等的线索。日志文件能或不能被归档, 取决于这个线索的状态与模式, ARCH进程保证了一个线索的redo log的归档。在OPS环境下, ARCH进程保证了一个例程的线索的所有在线的redo log文件被归档, 除current状态的redo log文件以外。它能够归档: * 当前例程的线索的所有非活动的redo log group * 其它例程的线索的所有状态为closed和enabled的redo log group * 请求其它例程归档当前例程线索。 2.ARCH进程的流程 归档一个LOG文件主要包含以下三个阶段: 异步的读在线的redo log文件, 执行检查, 分配和写redo log buffer, 异步的写入一个新的或已存在的归档文件。下面是归档进程: * 读控制文件找到未归档的redo log文件 * 打开并读出在线的redo log文件 * 按照参数log_archive_buffers分配redo buffer * 异步的读在线的redo log文件。( 所读入的数据长度为log_archive_buffer_size) * 每个buffer流对应一个redo log member。 * 写入redo log buffer。( 判断buffer是否已满或处于文件尾) * 如果需要创立新文件, 创立UFS归档文件。 * 异步写入归档文件。( 所写入的数据长度为log_archive_buffer_size) * 更新控制文件 * 重复以上步骤直至完成归档。 ARCH进程会检查redo log文件的文件头和数据块的有效性, 只有有效的数据块才会被写入archive buffer。因此归档文件的大小总会小于或等于所对应的redo log文件。 3.Redo log文件和归档文件的配置 在事务处理过程中, 会对Redo log文件进行大量的写入, 归档进程或其它执行恢复的进程需读redo log文件, 也就是说, redo log文件所在硬盘会有大量的写入, 有时会有大量的读操作, 一般读和写不会产生竞争。 建议对redo log文件进行Oracle镜象或采用硬件镜象。redo log文件不应和归档文件放在同一个硬盘上, 理想的配置是redo log文件应与其它文件分别放在不同的磁盘上, redo log member或镜象文件应分开放在不同的硬盘和控制器上, 以防止单点故障和提高吞吐量。 建议redo log文件最好能放在采用Raid0+1(mirror and striping)配置的原始设备上, striping引入了写盘的并行机制, 能提高写入的速度。归档文件必须放在文件系统里, 理想的应采用Raid0+1配置, 同样, 建议采用striping来提高性能, 归档文件应与redo log文件放在不同的盘上。4.归档策略 成功的归档能够保证所有在线的redo log文件被归档和备份, 防止归档忙等待, 并经过将上次备份以来所有的归档文件保存在硬盘上来减少恢复的时间。 为保证所有的redo log文件被归档和备份, 应经常监控: 数据库, 归档的过程, 归档的目录, 及磁带管理过程。可经过检查$LOG视图和检查trace文件来监控归档的进行。 用户应写好脚本文件, 登录到数据库查询V$log试图, 列出需要被备份到磁带上的归档文件。同时, 应检查log_archive_dest目录的可用空间, 磁盘错误, 磁带错误等。使用磁带时应进行check sum来保证归档文件被成功的备份到磁带上。 建议在进行在线的数据热备份后, 使用alter system archive log current命令, 这个命令强制归档所有的活动和非活动的redolog文件, 一个成功的数据库和最新的归档日志文件, 保证了一旦事故发生后, 能够用这个备份来恢复数据库。 5.问题的解决: 对于一些关键任务处理系统, 特别是7*24系统, 应特别注意归档方面的问题, 应花费一定的时间收集潜在的信息。以便及时的采取相应的解决方案, 保证数据的完整性。比较常见的问题有, log_archive_dest目录空间不足, 或设置了归档方式, 但没有ARCH进程等。 当碰到归档问题时, 应采用如下方法解决问题: * 收集问题的详细描述。 * 用ARCHIVE命令调试。 用alter system archive lig list命令显示归档的配置和归档进程的状态。然后, 可执行alter system archive log next current命令, 一般会产生更明白的错误信息。 * 查看动态数据字典: 相关的数据字典: V$LOG V$DATABASE V$LOG FILE V$ARCHIVE * 查看alert文件和trace文件。 Alert.log和后台进程的trace文件可能会指出归档方面的错误。当前的归档目录由于缺乏空间而不能被写入。或采用手工归档方式时, 所有的redolog都被写满。用户可根据alert文件和trace文件中的错误信息采取相应的措施。 * 监控ARCH进程。 * 找出相应的解决方案以避免问题再次发生。 归档问题发生后, 应及时找出问题, 归档文件应备份到一定的介质上, 带离现场, 以保证数据获得最大的安全性。 Export/Import 使用技巧与常见错误 Export 和 Import 是一对读写Oracle数据的工具. Export 将 Oracle 数据库中的数据输出到操作系统文件中, Import 把这些文件中的数据读到Oracle 数据库中. Export/Import 能够用来完成以下工作: 数据归档, 数据库升级, 备份数据库, 把数据从一个数据库移到另一个数据库, 回收数据库存储碎片等等.使用Export除了要保证磁盘或磁带上有足够的空间, 还必须执行 expvew.sql和 expvew.sql来创立 Export使用的示图, 并创立 EXP_FULL_DATABASE ROLE. 使用 Export的用户应具有CREATE SESSION的权限, 若要Export其它用户的表还要有EXP_FULL_DATABASE ROLE。同样, 使用 Import 必须用 catex.sql 来创立 IMP_FULL_DATABASE ROLE。 使用Import的用户应具有CREATE SESSION的权限. Import只能读入用Export创立的文件。如果该文件是全库 Export, 使用 Import 的用户还要有 IMP_FULL_DATABASE ROLE。Export/Import 有三个级别 : 表级, 用户级和全数据库级。 表级允许 Export/Import 指定的表而不涉及其它数据库对象. 用户级 Export/Import 只针对属于指定用户的全部数据库对象. 只有拥有 EXP_FULL_DATABASE/IMP_FULL_DATABASE ROLE 的用户才能使用全数据库级的 Export/Import。有三种方式执行 Export/Import : 参数文件方式, 命令行方式和交互式。 使用参数文件是一种比较好的方式, 格式为 : Exp PARFILE = Imp PARFILE = 命令行方式是指在命令行中指定参数 :Exp TABLES = (emp,dept) GRANTS = yImp FROMUSER = scott TOUSER = test TABLES = (emp,dept) 交互式只要敲入Exp或Imp然后回答屏幕上的提问即可。Export/Import 还能用来备份/恢复数据库. 一般增量 (INCREMENTAL), 积累(CUMUL-ATIVE ) 和完全 ( COMPLETE ) 三种方式, 它们又统称增量 Export。但必须注意的是,为了保证数据的一致性,使用增量Export时不能有用户修改数据.增量 Export的好处在于能够缩短时间, 而不影响数据的可靠性. 增量Export只输出上次使用INCTYPE参数输出后又被修改过的表. 如果只修改了表中的一行, 那么整个表都将被输出。当你以查询为主的表时, 增量输出能节省时间的好处才能体现出来. 相反, 如果每天都要修改数据库中的多数表, 增量输出的好处就不那么突出了. 另一个需要注意的是, 在用增量输入(IMPORT)恢复数据前, IMPORT要删除增量输出的表. 对于那种含有经常需要修改的大表的数据库, 恢复数据会很费时间。三种增量输出的主要区别在于输出的总量不同 : 1.