原文转自：http://blog.csdn.net/tianlesoftware/article/details/5678698
Oracle 10g中的RMAN 使用程序主要关注的是将磁盘备份作为介质恢复解决方案的最佳方法。 随着磁盘价格的下跌，大量的存储区网络（Storage Area Network：SAN）已经在很多数据中心找到了永久的存储空间。 随着业务向着价格越来越便宜而容量越来越大的磁盘发展，对RMAN的功能（如Flashback）进行了升级，从而可以最有效的利用可用存储空间。
RMAN 备份实用程序是按逻辑执行的过程，而写入到磁盘的操作正是Oracle 数据库所擅长的工作。因此，当Oracle 数据库开始改进磁盘写入功能时，RDBMS也会做相应的工作来改进性能。
但是在许多情况下，数据库的大小及其位置都使得它无法备份到磁盘。或者仍然存在要简历数据副本或者离站归档的业务需求。因此还是需要写入到老式的磁带设备。
Oracle 数据库的磁带备份需要第三方的辅助设备，这主要是因为市场上流行的连续介质子系统具有完全不同的性质。 RMAN 开发人员通常使用那些大供应商提供的可读写磁带产品，而不去尝试这些不同类型的磁带设备的不同系统调用。
Oracle 拥有自己的介质管理软件解决方案，称为 Oracle 安全备份（Oracle Secure Backup： OSB）。 OSB 是完全集成的，RMAN 到磁盘的解决方案，它不需要任何第三方供应商的软件插件，但是OSB 不成熟。
一． 使用磁带备份的原因
第一个理由是由于数据库的大小。现在的数据库平均大小已经达到100GB，并且这个数据还在继续增加。数据库的大小决定了是否需要执行磁带备份操作。即使磁盘价格在迅速下降，但购买很多磁盘需要的花费很大。 磁盘备份的优点在于快速恢复，而磁盘的备份和还原相对较慢。
第二个理由是易管理性。通常，全企业备份策略的实现和执行是由中央系统上的人员集中管理的，这样节省了备份的规模和开支，公司也有能力买大容量的磁带盒式设备来存储更多的数据。
第三个理由：可移植性。 为了归档和避免灾难，可以很容易的将一堆磁带离站移动，而硬盘则无法这么方便的传输。
集中备份资源的缺点：会导致备份复杂话，尤其是Oracle 数据库的复杂化。 Oracle数据文件，日志文件和控制文件的复杂性意味着我们不能简单的执行一个OS 作业。让它在空闲时间复制文件。 相反，我们必须使数据库做好执行备份的操作，然后通知开始复制，最后重新配置数据库。
使用RMAN可以避免这个数据库的配置，备份操作可以发生在任何时候，任何情况下，不过，要将备份写入集中的磁带备份位置，就必须执行一些特殊的RMAN 配置。
二． RMAN 和 介质管理器 概述
通过使用介质管理器，RMAN将数据备份到磁带上。 介质管理器（media manager：MM）是由第三方软件商提供的，它将数据块中的数据流从RMAN通道进程传递到相应的磁带中。 通常，介质服务器位于一个企业网中。 介质管理服务器（Media management Server）是一个集中化系统，在这里可以处理全企业的磁带备份操作。
计算机系统必须安装了介质管理（MM）客户端软件才能使用介质管理器。介质管理客户端软件可以连接ＭＭ服务器，并且通过网络传输数据。 如果RMAN要使用MM服务器，还需要另外的软件组件。 安装客户端软件之后，我们还必须为介质管理器安装Oracle 模块。 Oracle 模块（Oracle Module）是一个用于Oracle RDMBS 的软件插件，它可以连接RMAN与客户端管理软件，后者可以把数据传送到MM服务器。 Oracle 的这个插件也称为介质管理库（Media management Library: MML）.
2.1 介质管理器目录
介质管理器是我们使用的整个备份系统中的一个独立子系统。它有三个组件：与Oracle 结合的介质管理库（MML），介质管理客户端 和 介质管理服务器。MM 服务器有多种组件，这些组件的规范由供应商提供，所有的MM服务器都必须具有一些相同的组件。
介质管理器目录是MM服务器上的信息数据库，它保存了关于物理磁带本身，磁带的访问权限 和 磁带存储内容的相关信息。 备份完成时，介质管理器目录则记录RMAN文件句柄，句柄（Handle）是使用RMAN执行备份操作时创建的备份片名称。 如果执行磁盘备份操作，句柄就是物理文件名。如果执行磁带备份，介质管理器目录中使用的句柄就是备份所在的磁带位置。
RMAN 完成磁带备份操作时会向管理器提供句柄名，介质管理器把该句柄记录在目录中。需要执行还原操作时，RMAN会基于自身的目录向介质管理器请求指定的句柄。随后，介质管理器查找这个句柄，将该句柄与指定磁带关联在一起，同时判断磁带是否有效。 如果磁带有效，介质管理器会使用这个磁带，并且开始将数据流传送回RMAN，这样就可以重新构建数据文件。
2.2 介质管理器的其他软件组件
除了 介质管理器目录 以外，MM 管理器还包含两个基本组件：
（1） 设备代理程序（Device agent）：设备代理程序是负责使用实际磁带设备并在该设备上传送数据的组件
（2） 自动机器接口（Robotic Interface）: 自动机器接口控制所有自动机器的软件，这些自动机器负责在磁带满时或在请求写入已填满的磁带时更换磁带。
Oracle 中的RMAN 不了解这些组件的存在。 RMAN 只是简单地把命令请求发送给MML，随后MM 软件会处理相应的所有事件。 不过，由于备份和恢复的成功取决于这些组件，所以熟悉这些软件组件也是至关重要的。使用RMAN出现的问题大多数都与设备代理程序或自动机器接口有关，但从RMAN 接口几乎察觉不到这些问题。
2.3 介质管理库（MML）
MML 是一个库文件，它将RMAN的一致性的备份或还原请求解释为在据诶是管理服务器上的具体的系统调用，以实现要求的操作。 MML 与 MM 客户端软件和MM 服务器软件一样是由同一个供应商提供的，但是我们需要单独购买MML 和取得许可。
首次分配磁带通道时，MML 作为一个集成的库文件加载到Oracle 内存空间，它是Oracle RDBMS 软件的逻辑部分，因此RMAN可以生成正确的MM客户端软件调用。 这个集成实际上非常简单：分配磁带通道时，Oracle 加载一个名为libobk.so 的文件。 这个文件位于ORACLE_HOM/BIN 目录中，它只是一个要使用的MML 文件的符号连接。 在Windows平台上，Oracle 会在搜索路径中查找一个名为orasbt.dll 的库文件。 不论是哪一种介质管理器，在介质管理DDL 文件都名为： orasbt.dll， 介质管理器通常将其写入到WINDOWS/system32 目录中。 如果这个文件没有位于该目录中，在系统路径环境变量中有一个能够查找到orasbt.dll 文件的搜索路径。
示例： 使用Oracle 默认SBT 接口测试磁带通道
RMAN> run
2> {
3> allocate channel c1 type 'sbt_tape'
4> PARMS="SBT_LIBRARY=oracle.disksbt,
5> ENV=(BACKUP_DIR=f:/BACKUP/)";
6> BACKUP DATABASE FORMAT='%U';}
释放的通道: ORA_DISK_1
分配的通道: c1
通道 c1: SID=21 设备类型=SBT_TAPE
通道c1: WARNING: Oracle Test Disk API
启动 backup 于 18-6月 -10
通道 c1: 正在启动全部数据文件备份集
通道 c1: 正在指定备份集内的数据文件
输入数据文件: 文件号=00001 名称=D:/APP/ADMINISTRATOR/ORADATA/ORCL/SYSTEM01.DBF
输入数据文件: 文件号=00002 名称=D:/APP/ADMINISTRATOR/ORADATA/ORCL/SYSAUX01.DBF
输入数据文件: 文件号=00003 名称=D:/APP/ADMINISTRATOR/ORADATA/ORCL/UNDOTBS01.DBF
输入数据文件: 文件号=00004 名称=D:/APP/ADMINISTRATOR/ORADATA/ORCL/USERS01.DBF
通道 c1: 正在启动段 1 于 18-6月 -10
通道 c1: 已完成段 1 于 18-6月 -10
段句柄=06lghd3f_1_1 标记=TAG20100618T085926 注释=API Version 2.0,MMS Version 8.1
.3.0
通道 c1: 备份集已完成, 经过时间:00:01:35
通道 c1: 正在启动全部数据文件备份集
通道 c1: 正在指定备份集内的数据文件
备份集内包括当前控制文件
备份集内包括当前的 SPFILE
通道 c1: 正在启动段 1 于 18-6月 -10
通道 c1: 已完成段 1 于 18-6月 -10
段句柄=07lghd6e_1_1 标记=TAG20100618T085926 注释=API Version 2.0,MMS Version 8.1
.3.0
通道 c1: 备份集已完成, 经过时间:00:00:01
完成 backup 于 18-6月 -10
释放的通道: c1
也可以永久性配置命令设置Oracle 库：
Configure channel device type 'SBT_TAPE'
PARMS 'SBT_LIBRARY=oracle.disksbt,ENV=(BACKUP_DIR=f:/BACKUP/)';
如果视图分析介质管理器备份解决方案可能存在的问题或无法使备份工作时，上面的的示例就是一个很好的测试方法。 通过分配一个‘伪造的’磁带通道，可以测试RMAN 配置是否正确。
注意： 不要在产品备份时测试MML 文件。如果要在产品环境中执行磁盘备份操作，就分配磁盘通道。 伪造MML的性能非常糟糕，这是因为RMAN为磁带而不是磁盘分配内存缓冲区，因而磁盘写操作的速度远大于磁带写速度这一点没有体现。
2.4 连接MML 的接口
链接Oracle 与 MML时，意味着RMAN 可以通过它来传递命令以连接MML，或者进一步说，在数据库服务器上安装的MM 客户端软件。
要指定MM 服务器，我们必须在RMAN 会话中传递指定服务器名的环境变量。 具体来讲，在分配磁带通道时，我们将服务器名指定为环境变量。 在上面的示例中，我们用allocate channel 命令的PARMS 选项来传递环境变量。不同的MM 产品具有不同的环境变量。 如Veritas NetBackup 要求使用NB_ORA_SERV 参数。
Allocate channel t1 type 'sbt_tape' PARMS="ENV=(NB_ORA_SERV=storage1)";
这里的MM服务器名称就是storage1，同时数据库服务器在MM 服务器中已注册并具有写磁带设备的权限。
除了服务器名之外，我们还可以在通道分配时传递其他一些参数来利用服务器上的管理功能。 如Netbackup 允许我们指定用于备份操作的类或调度，而EMC Networker 允许我们指定资源池。
三． SBT API
RMAN可以不受影响地使用不同的介质管理器，这是因为不管加载哪一种MML，RMAN都会发送相同的命令。Oracle 使用SBT API 来开发RMAN,SBT API 是一种通用API, 提供给Oracle 数据库备份操作编码集成产品的第三方软件商，是RMAN向介质管理器发送命令的工具。
SBT API 负责向MM 服务器发送命令以初始化在磁带上备份文件的创建，还发送基于介质管理器目录中的文件句柄来查找先前备份的命令。 SBT API 可以发送删除备份的命令，也可以写新备份以及从备份位置读取备份。 Oracle RMAN SBT API 有1.1 和2.0 两种版本。 1.1 版本是与Oracle 8.0.x 一起发布和使用的。其后，RMAN 使用2.0 版本的规范生成介质管理器调用，运行备份时我们可以在RMAN输出中看到这个版本号。
RMAN 还会返回通道分配时的初始化的MML 版本，这可以在通道分配期间的RMAN输出中看到。 如果看到了MML 版本信息，也就说明已经成功链接了MML 与 RMAN，否则RMAN输出中就不能解析版本信息。
四． 磁带备份的全过程
概述一下磁带备份的全过程，具体细节是有编写集成MML的供应商来处理。
分配磁带通道时，RMAN 会在目标数据库上生成一个服务器进程，这个服务器进程随后生成sbtinit()的 SBT API 调用，该调用初始化MML 文件并将这个文件加载到内存，同时还向RMAN 返回MML支持的SBT API 版本。 调用sbtinit()后，RMAN还会调用sbtinit2(),sbtinit2()调用将向介质管理器软件提供更多详细的配置信息。
RMAN 分析备份命令后会执行远程过程调用（RPC），RPC 会生成sys.dbms_backup_restore.backuppiececreate 调用。 这时，通道进程将调用sbtbackup(),该调用在指定的磁带位置处理备份片的创建。 Sbtbackup（）调用会通知介质管理器,Oracle 将开始推入数据块流，这样介质管理器会为数据流准备好磁带备份。
RMAN 输入缓冲区被填满后会执行内存对内存的写操作把内容写入输出缓冲区。 输出缓冲区被填满时，通道进程调用sbtwrite2()，从而将输入缓冲区的内容写到磁带上。一般情况下，这种方式会在MM 服务器上使用设备代理来访问磁带自身。
当用于特定备份的所有输出缓冲区被清空，并且sbtwrite2() 调用的工作也完成时，通道会话会调用sbtclose2(), 该调用将彻底清空所有介质管理器缓冲区，并且将备份片提交给磁带。
完成备份后，通道进程调用sbtinfo2()，该调用确认介质管理器目录已经记录了备份片。Sbtinfo2() 调用向介质管理器目录请求备份的磁带，磁带位置和备份的完整时间，然后将备份片句柄写入介质管理器目录。
在确认备份片位置后，通道进程调用sbtend()，该调用清楚剩余的资源，并将他们释放，以用于其他数据库操作。最后执行的是收回通道进程的动作，它在目标数据库中完成。
五． 从磁带还原的全过程
在还原操作期间，SBT API 将经过一系列步骤还原磁带备份到数据库中。
还原分配磁带通道时，RMAN 会在目标数据库上创建一个服务器进程。随后通道进程调用sbtinit()来初始化介质管理软件。 这一步骤与备份操作相同，MML 文件被加载到内存中。
基于RMAN中的restore 命令的参数，RMAN 会检查RMAN目录来确定要进行还原的备份句柄名。随后，它使用sbtrestore()调用将请求的备份片句柄传递给介质管理器，该调用告诉介质管理器要为还原操作朱备好相应的磁带，即使用介质管理器目录来查找相应的磁带，如果有必要则向自动机器指令传递取磁带的命令。加载磁带后，磁带必须绕回到备份片的起始点。
为还原准备好磁带后，通道进程调用sbtread2() 函数从磁带设备读取数据并将数据流发送至ORACLE 进程。 这些数据被加载到输入缓冲区，然后被写入到输出缓冲区，最后被写入控制文件指定的数据文件位置。
在磁带上检测到备份片的结束点时，磁带通道进程调用sbtclose() 函数来断开该设备片所在的磁带，这表明Oracle 结束了对这个磁带的操作。 如果执行还原操作时需要多个备份片，通道进程会返回第二个步骤并为另一个被分片调用sbtstore()。
还原操作完成并且RMAN不再请求备份片时，通道进程调用sbtend()函数，该函数清理并释放通道资源以供其他方面使用。 然后通道进程结束，此后介质管理器就可以卸载已经请求过的磁带。
六. 使用 sbttest 和 loadsbt.exe
通常总有一些提示说明是否成功链接了MML 与Oracle，如，来自通道分配的信息说明了MML版本。不过这些指示不能保证最后的成功，在更下层的网络拓扑中（MM客户端或MM服务器）仍然可能出现故障。
Oracle 提供了一个名为sbttest的实用程序，可用它来测试以确保RMAN能够使用MM配置来执行磁带备份操作。 从命令可以调用这个实用程序，该程序执行一个完整的测试：sbttest 会向磁带写一个数据块，然后请求读取这个数据库。 通过这种方式，sbttest 运行备份操作期间执行的所有SBT API 函数，并确认这些函数能否成功。
Sbttest 的用法非常简单： 只要从命令提示符运行。 确认完成了所有的MM配置，然后进入RMAN运行环境中的命令提示符，并输入sbttest 和测试文件名。
-bash-3.2$ sbttest
Error: backup file name must be specified
Usage: sbttest backup_file_name
<-dbname database_name>
<-trace trace_file_name>
<-remove_before>
<-no_remove_after>
<-read_only>
<-no_regular_backup_restore>
<-no_proxy_backup>
<-no_proxy_restore>
<-file_type n>
<-copy_number n>
<-media_pool n>
<-os_res_size n>
<-pl_res_size n>
<-block_size block_size>
<-block_count block_count>
<-proxy_file os_file_name bk_file_name
[os_res_size pl_res_size block_size block_count]>
<-libname sbt_library_name>
Required parameters:
backup_file_name: The name of the backup file which will be created by
this program. If a BFS or Backup Piece already exists
with this name, then this program will not create a new
backup file - the existing file will be read in its
entirety and its contents will not be verified
Optional parameters:
-dbname specifies the database name which will be used by SBT
to identify the backup file. The default is "sbtdb"
-trace specifies the name of a file where the Media Management
software will write diagnostic messages.
-remove_before if specified, then the specified backup file will be
deleted before it is opened. This option is intended
for when sbttest has already been run but did not complete
successfully, leaving behind the backup file it created.
-no_remove_after The default behavior of this program is to delete the
backup file, if it was created by this program. If this
option is specified, then the file will not be
removed when this program is complete.
-read_only if -read_only is specified, then backup_file_name must already
exist. Its contents will be read. If it is determined that the
file was created by this program, then its contents is validated.
-no_regular_backup_restore skips non-proxy backup and restore.
-no_proxy_backup skips proxy copy backup session.
-no_proxy_restore skips proxy copy restore session.
-file_type specifies file type - 1, 2 or 3.
-copy_number this is the copy_number parameter to sbtpcbackup.
-media_pool this is the media_pool parameter to sbtpcbackup.
-os_res_size specifies the size in bytes of the os reserved block.
-pl_res_size specifies the size in bytes of the platform reserved block.
-block_size specifies the size in bytes of each block written to the
backup file. The default is 16384.
-block_count specifies how many blocks will be written to the
backup file. The default is 100.
-proxy_file specifies the os file name, backup file name, os reserved size,
platform reserved size, block size, and block count for each
proxy file. For each proxy_file, the os_file_name and
bk_file_name parameters are mandatory, the other four
parameters are optional. If none of the four is specified,
either the default or the value specified with -os_res_size,
pl_res_size, block_size, block_count will be used. It some of
the four are the same as the values set with -os_res_size,
pl_res_size, block_size, and block_count, a letter 'g' or 'G'
can be used.
For example,
stksbt2 -os_res_size 10 -pl_res_size 20 -block_count 30
-proxy_file file1.osf file1.bkf g g g 100
then, for file1.osf, the backup file name is file1.bkf, the
os reserved size is 10 bytes, and the platform reserved size
is 20, block size is 16384 byte, and the block count is 100.
But in this case,
stksbt2 -proxy_file file1.osf file1.bkf g g g 100
-os_res_size 10 -pl_res_size 20 -block_count 30
for file1.osf, the os_res_size and pl_res_size will be the
default value, 0 (instead of 10 and 20), and the block_count
will be 100 (instead of 30) and the block_size will also be
the default, 16384.
-libname specifies the SBT library to test. sbttest loads library
using dlopen() call. If this option is not used, sbttest
tries to test against libobk.so. Otherwise uses statically
linked library.
Specify oracle.disksbt for oracle's disk SBT library.
Sbttest 实用程序已经相当完善。 现在，我们可以传递许多参数来测试MM系统的所有过程，包括命名要测试的数据库，修改sbttest 写入的数据块数目，以及处理sbttest 写入磁带的文件。 从命令提示符简单的输入sbttest 会给出所有可以使用的参数开关和简单的文本说明。
Sbttest 使用程序只适用于Unix 平台；在windows 平台上，我们可以想Oracle Support 请求loadsbt.exe 实用程序。 遗憾的是，Loadsbt.exe 实用程序不具有与sbttest相同的性能，它只是简单的在搜索路劲中查找orasbt.dll 文件。 如果找到该文件，loadsbt.exe 实用程序会试图加载该文件，其加载方法与Oracle 在磁带备份操作期间加载的方法相同。 如果可以加载orasbt.dll 文件，loadsbt.exe 实用程序会通知用户，但它不会在磁带上写入数据块。 所以我们无法查看整个MM 配置工作。 因此，loadsbt.exe 的作用不如sbttest.
