数据库备份和恢复方案毕业论文

　 备份和恢复方案

　恢复方案在被真正付诸实施之前通常是不会得到检测的，理由是没有时间或资源来

　检测此方案，由此阻止了数据的复原。如果你没有足够丰富渊博的知识来建立一个正确的备份方案，那么当恢复问题出现时，你也许会付出很大的代价。能够熟悉所有的恢复过程，并按照可接受的恢复手段创建正确的备份方案，也许即是你成功的关键。如果正确的备份方案得不到实施时，你就会认为你的系统属于不可恢复的。多熟悉和了解备份和恢复方面的知识，就可以创建一个完整的备份方案来保护你的系统。这篇文章介绍了很多知识技巧，以助你创建一个完整的方案。

　备份策略 ----- 快速参考

　如下的备份方案是可行及有效的：

　 * 全部和部分卸出（数据）

　 * 增量卸出数据（一般不采纳）

　 * 映象备份

　 * 热备份

　 * 归档

　 * 整个文件系统的复制

　 * 以上方法可以组合使用（建议）

　 建议的备份方案包含如下：

　 . 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-Line DB Off-Line 数据库 No Yes 表空间 Yes No 数据文件 Yes Yes

　 映象备份

　 所谓映象备份就是把数据库的关键文件拷贝到另一个目录的备份方法。映象备份或许是最快及最安全的备份 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<sid>.ORA 文件以激活归档方式

　 在 INIT<sid>.ORA 文件中增加如下内容：

　 LOG_ARCHIVE_START=TRUE

　 LOG_ARCHIVE_DEST=/Oracle7/archive/arch

　 注意：目录（/Oracle7/ archive）是你自己创建的，或者直接写到磁带上:“arch" 是归档文件的前缀。

　 将数据库设置到 ARCHIVELOG 模式

　 $sqldba lmode=y（或 svrmgrl，7.3 版以上）

　 SQLDBA>CONNECT INTERNAL

　 SQLDBA>STARTUP MOUNT

　 SQLBDA>ALTER DATABASE ARCHIVELOG（激活归档方式）

　 SQLDBA>ALTER DATABASE OPEN

　 SQLDBA>ARCHIVE LOG LIST（看归档状态；如下所示）

　 DATABASE log mode ARCHIVEOG

　Automatic archival ENABLED

　Archiive destination

　/oracle7/archive/arch

　Oldest Online log seq.155

　current log sequence 156

　SQLDBA>EXIT

　 注 意：如果运行在归档模式，Oracle 将启动一个叫做 ARCH 的后台进程，可通过相应的操作系统命令看到这个进程。

　热备份优点:

　. 可以在数据库运行状态下进行

　. 可以恢复到秒级

　. 对于几乎所有的 Instance 恢复都可通过热备份进行恢复

　. 恢复快，大多数情况下可在数据库启动状态下进行

　.

　对于 Oracle7 版，更易于维护

　缺点：

　 .恢复过程要绝对正确，否则问题会更糟

　 .如果备份不起作用，则无法恢复到失败点

　 .恢复步骤要小心，难于维护

　 .如果一个归档文件被破坏了，则必须重头再来

　最适用于

　 .用于数据库“不能中断”有环境下

　 .24 小时运行环境

　 .在必须快速恢复并且不影响整个系统的情况下

　 .DBA 有足够的时间来维护必要的文件一些 Oracle7.1 的变化

　 .备份的“热”指没有“开始”和“结束备份”的

　 .“Alter tablespace×××read 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"

　 确认要备份的数据库的控制文件：

　 SQLDBA>SHOW PARAMETER contral_files;

　.该命令将返回 Name：control_files

　Type：string

　Value："Oracle7/dbs/ctrlora7.ctl"

　 确认表空间和数据库文件的对应关系，以及数据库文件的大小：

　SELECT

　TABLEAPACE_NAME, , BYTES, STATUS FROM

　 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

　CONTROL TRACE NORESETLOGS；

　 全数据库 export 的部分参数文件

　system/manager

　FULL=Y

　COMPRESS=Y

　GRANTS=Y

　ROWS=Y

　 对某个表空间做完整的热备份步骤：

　 $sqldba lmode=y (或 svrmgrl)

　 SQLDBA>CONNECT INTERNAL

　 SQLDBA>ALTER TABLESPACE tblspc_to_backup BEGIN BACKUP;

　 SQLDDBA>HOST cp /oracle7/dbs/tblsp1.dbf /backup/tblsp1.dbf

　 SQLDBA>ALTER 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 left‘desc_01.sq1" right "printed:"

　_date skip 1-

　center "Database object Count by owner by

　object type‘skip 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 文件。

　g 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 <username/password> PARFILE = <> Imp <username/password> PARFILE = <>

　 命令行方式是指在命令行中指定参数 : Exp <username/password> TABLES = (emp,dept) GRANTS = y Imp <username/password> FROMUSER = scott TOUSER = test TABLES = (emp,dept)

　 交互式只要敲入 Exp 或 Imp 然后回答屏幕上的提问即可。

　Export/Import 还 能 用 来 备 份 / 恢 复 数 据 库 . 通 常 增 量 (INCREMENTAL), 积 累(CUMUL-ATIVE ) 和完全 ( COMPLETE ) 三种方式, 它们又统称增量 Export。但必须注意的是,为了保证数据的一致性,使用增量 Export 时不能有用户修改数据.增量 Export 的好处在于能够缩短时间, 而不影响数据的可靠性. 增量 Export 只输出上次使用 INCTYPE 参数输出后又被修改过的表. 如果只修改了表中的一行, 那么整个表都将被输出。当你以查询为主的表时, 增量输出能节省时间的好处才能体现出来. 相反, 如果每天都要修改数据库中的多数表, 增量输出的好处就不那么突出了. 另一个需要注意的是, 在用增量输入(IMPORT)恢复数据前, IMPORT 要删除增量输出的表. 对于那种含有经常需要修改的大表的数据库, 恢复数据会很费时间。

　三种增量输出的主要区别在于输出的总量不同

　:

　 1. 完全输出(相当于全库输出)输出全部对象并清除增量输出的表. 虽然完全增量输出和全库(FULL EXPORT)相同的信息, 但还要对表作标识, 作为下次增量输出的基础。

　 2. 积累输出输出从上一次积累输出或完全输出后被修改的对象。

　 3. 增量输出(INCREMENTAL EXPORT)输出上一次完全, 积累或增量输出后被修改的对象.每次增量输出都要在增量输出表中插入信息. 完全增量输出在清除这些表后再插入信息。

　下图是某公司使用增量输出的例子 :

　 1. 每月的第一天作完全增量输出( COMPLETE EXPORT -- X )

　 2. 每周作积累输出( CUMULATIVE EXPORT -- C ) 3.

　每天作增量输出( INCREMENTAL EXPORT -- I )

　1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 M

　 T W T F S S M T W T F S S M

　X I I I I I C I I I I I I C I

　16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 T W T F S S M T W T F S S M T I I I I I C I I I I I I C I I

　第七天的积累输出包含了第一天完全增量输出后修改的全部对象. 并且包含了第二天到第六天增量输出相同的信息. 积累输出的好处在恢复数据时就体现出来了, 那时只用一个文件就可以而不必使用六个文件。

　 为了用增量输出恢复数据, 必须初始化数据库, 开始 IMPORT. 因为许多输出文件包含相同的表,增量 IMPORT 开始前总要删除这些表, 防止数据重复输入。

　 下面是增量输入建表的例子 : IMPORTING USER UserName DROP TABLE TableName CREATE TABLE TableName 开始输入数据之前, 数据库结构必须恢复到最后一次输出时的状态. 这要使用最后一个输出文件并加上"INCTYPE=SYSTEM"参数. 这时, 只输入表空间, 用户和回滚段等系统对象。

　数据库结构恢复后， 原有的用户也以经存在, 就可以 IMPORT 数据了。IMPORT 数据时, 从完全增量输出文件开始,然后是积累输出文件, 最后在次使用增量输出文件, 但这次参数改为 "INCTYPE=RESTORE"。

　 注意: 最后一个增量输出文件必须使用两次. 第一次在开时, 用 "INCTYPE=SYSTEM"参数恢复系统对象，另一次用 "INCTYPE=RESTORE" 参数恢复当前数据。具体步骤如下 : imp SYSTEM/MANAGER INCTYPE=SYSTEM FULL=Y

　 imp SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y

　imp SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y

　imp SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y

　imp SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y

　imp SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y

　imp SYSTEM/MANAGER INCTYPE=RESTORE FULL=Y

　 下面介绍一些

　EXPORT/IMPORT 的使用技巧

　 把数据库对象从一个用户移到另一个用户

　 Oracle 不允许直接改变表的拥有者, 利用 Export/Import 可以达到这一目的.假设要把表 T 的拥有者 User1 改为 User2, 具体步骤是 : - exp system/manager tables = User1.T - imp system/manager fromuser = User1 touser = User2 tables = T - drop table User1.T

　 把数据库对象从一个表空间移到另一个表空间

　 建表时可以指定表空间, 表空间一经确定就部能随意改变. 若要表 T 从表空间 tbs1 移到表空间 tbs2, 就要采用以下方法: - exp <user/passwd> tables = T - imp <user/passwd> tables = T indexfile = temp.sql - drop table T - 编辑 temp.sql 只保留所需的建表命令并指定表空间为 tbs2

　- 以表的所有者执行 temp.sql - imp <user/passwd> tables = T ignore = Y  只输出一个的表空间

　 通常数据库设计成用户若属于某个表空间, 那么这个用户创建的数据库对象也在该表空间内。

　 Export 某个表空间可用如下方法 :

　- 查看表空间内所有用户 spool owners select owner

　from dba_segments where tablespace_name = "<TablespaceName>"; spool off

　- 查看表空间内所有数据库对象 spool objects select owner, object_name, object_type from dba_objects where owner = "owner1" or owner = "owner2" ... or owner = "ownern";

　 spool off

　- 作表级 Export

　 - 从 Exp 文件中提取创建数据库对象的命令

　 在 IMPORT 时使用 "INDEXFILE = ", IMPORT 把创建数据库对象的命令输出到指定的文件中， 编辑后运行这个文件就能建立数据库对象。

　下面介绍

　Export/Import 使用中几个常见的问题和解决办法

　 Export/Import 使用不同的字符集

　Export 文件中包含着字符信息. 如过输入/输出都使用担字节字符集, 如 EBCDIC 或 US7ASCII, 输入时将自动进行字符集转换. 转换过程中, 若输出文件中含有的目标字符集中不能匹配的字符会自动设成缺省字符。

　 对于多字节字符集, 如 ZHS16CGB231280, 通常不能自动转换, 只有在字符串长度不变的情况下才能自动转换。

　 空间不够 -- 碎片问题

　 有些时候，空间不够的错误出现, 即使数据库仍有足够的空间, 使用 IMPORT 时却出 这种现象通常是由于数据库中存在碎片, 即有很多小的不连续的空闲空间. 解决办法 是先将数据库全库 EXPORT(FULL=Y), SHUTDOWN 数据库, 重新建库 (CREATE

　DATABASE) 后用 IMPORT FULL=Y 恢复数据。

　 ROLLBACK 段不够

　 Export/Import 使用过程中, 如果数据量很大会出现 "ROLLBACK 段不够" 的错误。这时要建一个足够大的 ROLLBACK 段, 使它 ONLINE 而其他 ROLLBACK 段 OFFLINE. 这样, Export/Import 使用这个大 ROLLBACK 段, 从而避免上述现象.