分类： 服务器与存储
2008-06-11 16:45:01
多数技术书籍在初始几章往往都是介绍基础知识，从命名、来由到基础概念，几乎都是大篇幅介绍，就俺看来这种方式在当前情况下极不适宜，原因有二。第一：多数有兴趣的朋友在研究某种技术之初往往都是想先看看其大致的使用方法，而概念介绍多数都是枯燥的连篇文字，很少有人有毅力在毫不了解这项技术的情况下研读进去，这就造成几种后果，有些人跳过初始几章直接从实际应用开始，等了解之后再翻回来看前面的介绍，有些人耐着性子看完前面却发现更加一头雾水，选择重看一遍或者不管接着往后看，而有些人则更是直接就放弃了。第二：目前技术发展日新月异，从业人员水平参差不齐，有些工作在分配给技术人员时，该技术甚至对此项工作一无所知，如种情况下还让他去看基础概念恐怕费时费力，保不齐书还没翻几篇，饭碗已不保，毕竟多数老板都是只看结果，过程是不管地。有鉴于此，俺希望能够在最开始的几章少一些枯燥的概念，多一些实际的操作，先让大家把手动来，把饭碗保住。同时，在经过一些操作之后，无论是对其了解或是兴趣应该都大大增加，这个时候再转回头来看看一些基本的概念，理解起来能够更加事半功倍吧。
基础毕竟是基础，乃物之根本，重中之重，俺老大每每在俺向其讨教时均向俺强调基础的重要，俺也深以为然，对于一个真正想要精通oracle的dba而言，无论如何都需要做到深入理解，认真铭记的。经过一些练习之后，相信大家对rman已经有所了解，对其操作也有了一定兴趣，我想这个时候来面对这些枯燥文字也应该稍稍能有些主观意愿吧，事不宜迟，请睡着的同学赶紧醒醒，进入补基础时间。
注：以下文字多摘抄自网络，如有错误纯属正常；如有侵权，这个。。。。。。你看不见我看不见我看不见我。。。。。。。。。。。。。。。。。
一、RMAN通道
上次基础知识讲理里简单提到了通道，在那里我把它形容为三环和五环，我感觉从便于理解的角度是可以这样描述的，RMAN通道实质是一个到存储设备的数据流。如果你想城市交通流通的更快些，多建几个环路对于缓解交通是有意义的。在RMAN中可以通过手动方式或自动方式分配通道。
1、手工分配通道
在执行BACKUP、RESTORE、DELETE等需要进行磁盘I/O操作的命令时，可以将它们与ALLOCATE CHANNEL命令放在一个RUN的命令块中，利用ALLOCATE CHANNEL为它们分配通道。例如：
RUN{
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK FORMAT 'd:/backup/%U';
BACKUP DATAFILE 'F:\ORAHOME1\ORADATA\JSSWEB\JWEB.ORA';
}
需要注意的是，RMAN中执行的每一条BACKUP、DELETE等命令都至少要求使用一个通道，通道数决定了这些操作执行的并行度。
2、自动分配通道
如果没有使用手工分配通道，那么RMAN在执行BACKUP等操作I/O的命令时将会使用预定义配置(configure，记起来了吧)中的设置来自动分配通道。
下列预定义配置命令均可以分配通道：
CONFIGURE DEVICE TYPE ... PARALLELISM
CONFIGURE DEFAULT DEVICE TYPE
CONFIGURE CHANNEL DEVICE TYPE
CONFIGURE CHANNEL n DEVICE TYPE
二、RMAN备份类型
利用RMAN进行备份时，可以通过三种方式来对RMAN的备份做分类
完全备份(Full Backup)与增量备份(Incremental Backup)
全备与增备是针对数据文件而言，控制文件和归档日志文件不能进行增量备份。当然，后两者可以做备份优化。
打开备份(Open Backup)或关闭备份(Closed Backup)
数据库打开状态下进行备份即是打开备份，数据库关闭状态下(加载状态)进行的备份即关闭备份。
一致备份(Consistent Backup)与不一致备份(Inconsistent Backup)
数据库打开状态或不干净关闭状态(shutdown abort)进行的备份是不一致备份，利用不一致的备份修复数据库后还需要做数据库的恢复。在数据库干净关闭状态进行的备份是一致备份，利用一致备份修复数据库后不需要做数据库的恢复。
三、增量备份的工作机制
所谓增量备份，顾名思义即是每次备份仅操作那些发生了"变化"的数据块。RMAN中增量备份有两种：Differential方式和Cumulative方式。下面将分别胡扯，请看官自辨真伪。。。
1、差异备份Differential
说起Differential，相当有意思，大家可以这样理解。有一家名为Differential的红社会组织，他们民主自由善良博爱为人忠恳正直(以下省略5000个褒义形容词)，总之呢，黑黑，他们会按照你与其约定的周期来向你收取保护费，因为他们的组织非常严密，(以上图为例吧)所有成员按照0,1,2分为不同等级，0级最高就是老大。贵为老大自然身份尊崇，手底下小弟多，开销也大，所以如果0级老大亲自登门收取的话，没啥说的，甭管它什么时候来，你的家底他都要重新清点一遍，从你成立开始到现在，总共应交多少保护费，一个子儿都不能少的都要交出来。每次来都是这样。而1级成员就显的温和多了，它每次来，只要求你将上次0级收到之后到现在应交的税款给交了就行了。甚至于如果上次也是个1级成员(与它平级)来收取的话，它也认同。当然，如果上次来收的是个2级成员，它是不承认的，好歹它也是个有身份的人，比它低级的成员打的收条它向来是不认同地。它至少要求将最后一个与它平级或级别比它要高的成员收取日期到现在应结的给它。1级成员带了头，2级成员也按这个来。
2、累积增量备份Cumulative
继续白话，名为Cumulative的红社会组织相比Differential差距就比较大，虽然它们也会按照与你约定的同期来收取，但是，这家组织显然作风是属于比较凶悍的。仍然以上图为例，假设它们也按照0,1,2分为三个等级，0级老大身份尊崇，表现倒与Differential家的相同。但级别比它低的那些小弟表现与Differential家的就相差较多。对于那些级别高于它们的成员打的收条，他们还是会认可，但是其它人，甚至与它们平级的成员它们都不认。哪怕上次就是它来收取的，他也能翻脸不认帐。比如某个1级成员昨天来时就直接从上次0级收取的时间开始算的，而今天来的又是这个家伙，可它对昨天的所为都拒不认帐，坚持还要从上次0级收取的时间开始算。
注意：这两家非0级成员都有个毛病，假如它们来收费时发现自你成立起，自家的0级老大从来都没来过，本着为老大尽心为老大尽责的高贵品格，他们都会替老大把你的家底翻个底朝天，来个大清算。
现在，大家对它们两家都有所了解了吧。另外backup命令在不显式指定的情况下，默认会选择Differential地哟：）
四、备份集概述
备份集由RMAN创建的具有特定格式的逻辑备份对象，一个备份集中可能包含多个数据库文件（包括数据文件，控制文件和归档日志文件）。RMAN中通过BACKUP命令建立备份集。
一个备份集是由多个备份片段组成，每个备份片段即是一个物理文件。
五、RMAN恢复目录(CATALOG)
Oracle9i版本因为控制文件的自动备份，可以很大程度不需要使用恢复目录。当然，号称使用目录数据库控制文件的方式将会非常的不安全，因为一旦备份文件丢失，不仅数据库崩溃，rman备份信息也将丢失（就个人使用而言，我觉着没有这么严重，9i中的控制文件备份就已经多种多样，而且恢复及重建方式也有许多，所以假如您在没有使用恢复目录的情况下丢失了控制文件，千万表以为就此玩完，准备摸脚走人。Google一下rman 控制文件 恢复，您会发现无数个能够挽救您饭碗的页面存在），扯了一堆，但愿没有给像上个礼拜的俺一样的初学者造成印象上的混淆，如果能用恢复目录还是推荐使用恢复目录，恢复目录实际上也是一个数据库，一般独立于目标数据库。因为它自己就是个数据库，所以一个恢复目录可以同时被多个目录数据库使用。网上搜了一些特点如下：
•有些命令只被恢复目录支持（找着不少，大家自己gg吧，这里就不一一介绍了，要不然俺这就不像在做笔记，倒像是在写高级参考大全，o对了还有，控制文件方式中无法直接存储rman备份脚本）
•能保留更多的历史备份信息
•一个恢复目录能管理与备份多个目标数据库
•如果没有恢复目录，而且发生了结构上的改变，时间点的恢复需要小心操作
•能存储备份与恢复的脚本
可以看到，主要是可以保留更多的备份信息与方便的管理多个目标数据库，这个在众多目标数据库的情况下，绝对是强烈推荐的，能省很多事儿。
同样，如果您选择使用恢复目录方式，千万表忘了对恢复目录数据库做备份哟，当然这个库您就不用再使用rman做备份了，呵呵：）,exp是个好法子，简单又方便，反正rman的恢复目录数据库也占不了什么空间。而且通过exp备份之后，一旦恢复目录数据库发生故障，也可能很轻易的通过imp进行恢复。
