备份策略配置和操作由什么执行

⑴ 如何制定数据备份策略

制定数据备份策略要根据数据量的大小以及数据的增加速度等有很大的关系，而使用什么样的数据备份策略还是请专门的技术人员制定比较好，这样不会带来损失而且还能很好的操作，数据备份不是简单的事情，需要软硬件的结合，以及备份数据的多少，睿芸备份软件根据用户的需求可以选择不同作用的备份软件，并且备份软件还能很好的操作，只需要设置好时间以及备份的数据，就能轻松的实现备份，最重要的是不会影响工作。

⑵ RMAN备份策略都有哪些

建立增量备份：
如果数据库运行于不归档模式下，只能在数据库干净关闭的情况下 ( 以 normal 、
immediate 、 transactional 方式关闭 ) 才能进行一致性的增量备份，如果数据库运行于归
档模式下，那即可以在数据库关闭状态进行，也可以在数据库打开状态进行备份。再
次说明了打开归档模式的优势，归档日志也就是多占些磁盘空间，可也相当于又给数
据加了层保护。建立增量备份，实质就是一个参数 incremental level=n ，在执行 backup
命令时加上即可，例如，建立一个增量级别 0 的全库备份：
rman> backup incremental level=0 database;
再例如，建立一个增量级别 1 的 users01.dbf 数据文件备份
rman> backup incremental level=1 tablespace system
datafile ‘e:\oracle\oraback\sj_data.dbf’;
注： rman 默认创建的增量备份是 differential 方式，如果要建立 cumulative 方式的增
量备份，在执行 backup 命令时显式指定即可，例如：
rman> backup incremental level=2 cumulative database;

建立镜像复制：
rman 中的镜像复制实质与通过操作系统 命令备份相同，甚至连命令的格式
都相似，只不过直接应用操作系统的 命令复制数据文件时，只是文件拷贝，而rman
的 则能够在复制的同时，验证数据的有效性。个人认为 rman 中的镜像复制应用
有限，而且也体现不出 rman 的优势，所以俺也只是大致了解了概念，没有进行过实际
操作，感兴趣的朋友可以自己做做试验，这里就不多做介绍了）

建立冗余备份

（

rman 提供了一种更谨慎的备份策略： plexed 方式备份，其实质即是在生成备份
集的同时，向指定位置生成指定份数 ( 最大不超过 4 份 ) 的备份集复制，以避免在灾难性
事故时数据库损坏和备份丢失的情况下导致完全崩溃，提高备份可用性。 rman 中提供
了三种方式实现 plexed 方式备份：

1) 在 rman 中执行 backup 命令时显式指定 copies 参数。例如：
rman> backup copies 3 database;
上述命令将会在全库备份的同时，自动生成当前备份集的 2 份拷贝到默认备份目录。

2) 在 run ｛｝命令块中利用 set backup copies 命令为该命令块中所有的 backup命令设
置 plexed 方式，例如：
rman> run{
set backup copies 2;
backup device type disk format
‘e:\oracle\oraback\dyk1\%u’,'e:\oracle\oraback\dyk2\%u’
tablespace users,sales;
}
上述命令将生成两份备份集，分别存储到 e:\oracle\oraback\dyk1 和
e:\oracle\oraback\dyk2 目录。

3) 通过 configure ….. backup copies 命令设置预定义的备份 plexed 方式
configure … backup copies 命令格式，可以为指定设备类型设置默认备份拷贝数
量。这个配置仅适用于数据文件与归档重做日志文件和备份，并且，只有在使用自动
分配的通道时才能够使用 configure …
backup copies 命令设置的配置。例如：
rman> configure default device type to disk;
rman> configure datafile backup copies for device type disk to 2;
rman> configure archivelog backup copies for device type disk to 2;
上述命令将 disk 设置上数据文件与归档文件的拷备数量设置为 2 ，当再执行 backup
database 备份时，即会自动生成 2 份数据文件的备份集。

设置 rman 备份的保存策略
策略，如果数据库非常大，并且备份执行也比较频繁，有必要对这些备份文件的
保存制订合理的策略。在通过 rman 创建的备份片段中，由于备份文件也是由 rman创
建和维护，所以手工删除并不明智，并且 rman 也提供了备份保留策略，合理制订，由
rman 自动删除陈旧备份文件更加安全也更加方便， rman 中提供了两种备份保留策略：
基于时间，和基于冗余数量
为 rman 设置了备份保留策略之后， rman 会自动判断哪些备份集或镜像复制文件
不必再保留。这些备份文件将会被标记为 “ 废弃 (obsolete)” ，可以通过 report obsolete
命令查看当前处于废弃状态的备份文件，或者通过 delete obsolete 命令删除这些废弃的
备份。例如：
rman> report obsolete;

rman> delete obsolete;

在执行删除命令时有两点需要了解：
如果被判断为废弃的备份是一个单独数据文件的镜像复制，那么在执行 delete 命
令时将直接删除这个镜像复制文件；如果被判断为废弃的备份是一个备份集中的一部
分，则必须等到整个备份集中所有其它文件都被废弃之后，才能删除这个备份集。
1) 基于时间的备份保留策略。
说的简单些，就是你希望数据库最早能恢复到几天前。比如将恢复时间段设置为 7，那
么 rman 所保留的备份即是可以保证你将数据库恢复到一周内任何时刻下那些文件。设
置基于时间的备份保留策略可以通过 configure 命令，例如：
rman> configure retention policy to recovery window of n days;
注： n= 大于 0 的正整数执行该命令后， rman 将始终保留那些将数据库恢复到 n 天前的
状态时需要用到的备份，比如，恢复时间段被设置为 7 天，那么各个数据文件的备

份必须满足如下条件：
sysdate-(select checkpoint_time from v$datafile)>=7
任何不满足上述条件的备份都将被 rman 废弃并可通过 delete obsolete 命令删除。

2) 基于冗余数量的备份保留策略
基于冗余数量实质即某个数据文件以各种形式（包括备份集和镜像复制）存在的
备份的数量。如果某个数据文件的冗余备份数量超出了指定数量， rman 将废弃陈旧的
备份。同样，基于数量的备份保留策略也是通过 configure 命令设置，例如：
rman> configure retention policy to recovery window of n days;
同上： n= 大于 0 的正整数
也可以设置不保留任何数据的策略
rman> configure retention policy to none;

备份优化
rman 中的备份优化 (backup optimization) 是指在备份过程中，如果满足特定条件， rman
将自动跳过某些文件而不将它们包含在备份集中以节省时间和空间。通常满足如下几
个条件情况下，才能够启用备份优化的功能：
configure backup optimization 参数置为 on ；
执行的 backup database 或 backup archivelog 命令中带有 all 或 like 参数。
分配的通道仅使用了一种设备类型，也就是没有同时分配使用 sbt （磁带）与 disk
（磁盘）的多个通道。

打开备份优化设置通过如下命令：
rman> configure backup optimization on;
在进行备份优化时， rman 是如何判断要备份的文件是否需要被优化，这个算法就
相当复杂，可能影响优化算法的因素也非常多，假如某库在上午 9 点被执行过一次全
库备份，等下午 3 点再次执行全库备份时，备份的文件没有变动而且也已经被备份过
时，才会跳过这部分文件。所以理论上备份优化仅对于只读表空间或 offline 表空间起
作用。当然对于已经备份过的 archivelog 文件，它也会跳过
3 ）基础补充
format 字符串替代变量，使用 format 参数时可使用的各种替换变量，如下：
%c ：备份片的拷贝数 ( 从 1 开始编号 ) ；

%d ：数据库名称；
%d ：位于该月中的天数 (dd) ；
%m ：位于该年中的月份 (mm) ；
%f ：一个基于 dbid 唯一的名称 , 这个格式的形式为 C-IIIIIIIIII-YYYYMMDD-QQ, 其
中 IIIIIIIIII 为该数据库的 dbid ， YYYYMMDD 为日期， QQ 是一个 1-256 的序列；
%n ：数据库名称，并且会在右侧用 x 字符进行填充，使其保持长度为 8 ；
%u ：是一个由备份集编号和建立时间压缩后组成的 8 字符名称。利用 %u 可以为每个
备份集生成一个唯一的名称；
%p ：表示备份集中备份片段的编号，从 1 开始编号；
%u ：是 %u_%p_%c 的简写形式，利用它可以为每一个备份片段（即磁盘文件）生成
一个唯一名称，这是最常用的命名方式；
%s ：备份集的号；
%t ：备份集时间戳；
%t ：年月日格式 (yyyymmdd) ； s
注：如果在 backup 命令中没有指定 format 选项，则 rman 默认使用 %u 为备份片段命
名。

configure 配置项介绍
首先，先来查看一下当前配置，通过 show all 命令：
连接到目标数据库 : jssweb (dbid=3391142503)
rman> show all;
正在使用目标数据库控制文件替代恢复目录
rman 配置参数为 :
configure retention policy to recovery window of 3 days;
configure backup optimization off; # default
configure default device type to disk; # default
configure controlfile autobackup on;
configure controlfile autobackup format for device type disk to ‘e:\oracle\oraback\%f’;
configure device type disk parallelism 1; # default
configure datafile backup copies for device type disk to 1; # default
configure archivelog backup copies for device type disk to 1; # default
configure maxsetsize to unlimited; # default
configure snapshot controlfile name to ‘e:\oracle\oraback\sj_data.ora’; #
default
rman>

show 命令在 rman 命令篇简单介绍过，同时也知道后跟 #default 表示该条配置仍
然是初始的默认配置，如果想把某条更改过配置选项再置为

初始设置，用如下命令： configure … clear; 例如：
rman> configure retention policy clear;
configure retention policy to recovery window of 3 days;
上述的各项配置，在前面章节中有一些已经有所体现，以下是详细介绍：
1)configure retention policy 配置备份保留策略

两种保留策略设置：
基于时间：
configure retention policy to recovery window of n days;
基于冗余数量：
configure retention policy to rendancy n;
也可以取消备份保留策略：
configure retention policy to none;
2)configure backup optimization 配置备份优化
备份优化 : 包括 off 和 on 两个状态
打开备份优化：
configure backup optimization on;
关闭备份优化：
configure backup optimization off;
3)configure default device type 配置 io 设备类型
rman 支持的 io 设备类型有两种：磁盘 (disk) 和磁带 (sbt) ，默认情况下为磁盘。
使用磁盘设备：
configure default device type to disk;
使用磁带设置：
configure default device type to sbt;
在这里需要注意的一点是：如果 io 设备发生变化，相关配置项也需要修改。例如：
rman> configure device type disk parallelism 2;
4) configure controlfile autobackup 配置控制文件自动备份
是否自动备份，包含两个状态： off 和 on
打开自动备份
configure controlfile autobackup on
禁止自动备份
configure controlfile autobackup off
指定备份的控制格式和路径。例如：
configure controlfile autobackup format for device type disk to
‘e:\oracle\oraback\%f’;
在备份期间，将产生一个控制文件的快照，用于控制文件的读一致性，这个快照可以
通过如下配置： configure snapshot controlfile name to
‘e:\oracle\oraback\sj_data.ora’;

5)configure device type 设置并行备份
rman 支持并行备份与恢复，也可以在配置中指定默认的并行程度。例如：
configure device type disk parallelism 2;
指定在以后备份与恢复中，将采用并行度为 2 ，同时开启 2 个通道进行备份与恢复，
当然也可以在 run 中指定通道来决定备份与恢复的并行程度。并行的数目决定了开启
通道的个数。如果指定了通道配置，将采用指定的通道，如果没有指定通道，将采用
默认通道配置。默认情况下，自动分配通道的并行度为 1 ，如果你通过设置 parallelism
设置了并行通道为 2 ，那么在 run 块中，它会默认使用 2 条并行通道 ; 如果在 run命令
块中指定数个 allocate channel ，那么 rman 在执行备份命令时会以设置的 channel 为准，
而不管 configure 中配置了多个并行通道。需要注意的是，在 backup 命令中有一个

filesperset 参数，该参数是指 rman 建立的每个备份集中所能包含的备份片段 ( 即磁盘文
件 ) 的最大数，该参数默认值为 64 ；如果在执行 backup 命令时没有指定该参数值，那
么 rman 会仅使用第一个通道来执行备份，其它通道将处于空闲状态。关于通道数与
filesperset 值之间也有一个大小关系，即 filesperset 值不要小于设定通道数。

6) 设置备份文件冗余度
configure datafile backup copies

如下：
rman> run{
set backup copies 2;
backup device type disk format
‘e:\oracle\oraback\dyk1\%u’,'e:\oracle\oraback\dyk2\%u’
tablespace users,sales;
}

7)configure maxsetsize 配置备份集的最大尺寸
该配置限制通道上备份集的最大尺寸。单位支持 bytes,k,m,g 。默认值是 unlimited。

8) rman 备份相关的动态性能表
v$archived_log ：本视图包含了所有归档重做日志文件的创建情况，备份情况以及其
他信息。
v$backup_corruption ：这个视图显示了 rman 在哪些备份集中发现了损坏的数据坏。
在你使用 backup validate 命令对备份集进行检查时如果发现了损坏的数据块， rman
将在这个视图中写入记录。
v$_corruptio ：本视图显示了哪些镜像复制备份文件已经被损坏。
v$backup_datafile ：本视图通常用来获取每个数据文件中非空白数据块的数量，从
而帮助你创建出大小基本相等的备份集。另外，在视图中也包含了数据文件中损坏的
数据块的信息。
v$backup_redolog ：本视图显示了在现有的备份集中饮食有哪些归档重做日志文件。
v$backup_set ：本视图显示了已经创建的备份集的信息。
v$backup_piect ：本视图显示了已经创建的备份片段的信息。
可以通过如下 sql 语句获得正在进行的镜像复制操作的状态信息：
select sid,
serial#,
context,
sofar,
totalwork,
round(sofar / totalwork * 100, 2) “% complete”
from v$session_longops
where opname like ‘rman:%’
and opname not like ‘rman:aggregate%’
通过如下 sql 获得 rman 用来完成备份操作的服务进程的 sid 与 spid 信息：
select sid,spid,client_info from v$process p,v$session s where p.addr=s.paddr and
client_info like ‘%id=rman%’

rman 通道
上次基础知识讲提到了通道， rman 通道实质是一个到存储设备的数据流。就像城市交
通道路，多建几个环路对于缓解交通是有意义的。在 rman 中可以通过手动方式或自动
方式分配通道。
1) 手工分配通道
在执行 backup 、 restore 、 delete 等需要进行磁盘 i/o 操作的命令时，可以将它们与 allocate
channel 命令放在一个 run 的命令块中，利用 allocate channel 为它们分配通道。例如：
run{
allocate channel ch1 device type disk format ‘e:\oracle\oraback\%u’;
backup datafile ‘e:\oracle\oradata\oradb1\sj_data.ora’;
}
需要注意的是， rman 中执行的每一条 backup 、 delete 等命令都至少要求使用一个通道，
通道数决定了这些操作执行的并行度。

⑶ SVN的操作说明以及备份策略

2.1 文件检出
安装TortoiseSVN后，SVN会跟Windows的资源管理器完美集成。点击右键，我们可以在菜单栏中选择“SVN检出”选项，输入要检出代码的文件库的URL地址，我们就可以检出该URL地址下的文件库的文件。默认情况下是检出最新版本的代码，如果需要，我们可以通过浏览日志，根据日志来找出想要的版本，然后在“版本”选项中指定相应版本就可以检出相关代码了 。
之后，对于同一个项目的主干开发，我们都在这个检出的代码文件目录下操作，而不是每一次提交或更新都重新检出一次。
2.2 文件添加
我们在本地创建的文件(包括目录)不会受SVN的控制，为了让其接受SVN的控制必须将其添加到文件库中。对于团队其他成员需要的文件，如代码文件、某些模块的.a文件（由于某些需要，该模块代码不公开），我们必须让它们接受SVN的控制，并且保持最新的版本。
2.3 文件删除
当我们需要删除无用的文件(包括目录)时，不能使用Windows的资源管理工具，而必须使用SVN本身的删除文件功能。这样该文件被删除后，其所有修改历史仍然保存在SVN服务器中，以后仍然可以获得该文件的修改历史。
2.4 文件改名
当我们需要对文件(包括目录)进行改名的时，不能使用Windows的资源管理工具，而必须使用SVN本身的文件改名功能。这样该文件被改名后，其改名前的所有修改历史仍然保存在SVN服务器中，保持连续的修改信息。
2.5 文件更新
其他团队成员提交到SVN上的改动不会自动更新到你的本地拷贝中来，我们需要通过更新文件操作来获取其他成员对项目文件所做的修改。SVN更新文件操作会把文件库里的文件与本地文件进行合并，从而达到了同时保留其他成员的修改及本地的修改的目的。如果无法自动合并则会发生冲突，需要使用文件比较工具进行手工合并，合并完成后才能提交已解决冲突的文件。冲突的详细解决方法见第三章——冲突解决。
在团队开发时，更新是一件很重要的工作，可以保持团队成员之间的工作内容一致，因此要注意经常更新自己的工作拷贝，以保证自己能够获得最新的修改内容。
2.6 改动提交
我们对文件(包括目录)所做的一切改动，包括添加、删除、修改文件都必须提交到SVN服务器文件库中才能正式生效，之后团队的其他成员才可以获取你所作的修改。
提交是很重要的一项操作，要求做到：
 提交代码之前一定要保证修改后的代码能编译通过，不能提交编译不通过的代码。
 比较修改前及修改后的代码，把调试信息或其他不相关的信息去掉，再次确保提交的代码是正确的并且提交的是需要提交的文件。
 不要等到修改了很多代码才提交，而是相关小功能完成时就应该提交一次。这样以后发现问题时就很容易撤销有问题的代码——因为撤销只能针对一次提交，所以在一次提交里涉及过多的功能是不推荐的。
 提交时必须填写log信息，说明这次提交增加了什么功能或者修正了什么bug。这些信息有助于自己和其他团队成员了解整个项目的历史。当出现问题时也方便定位到对应的版本代码，所以log信息必须足够详细。
 事务性提交。也就是说提交要么成功，要么全部失败——即提交出现错误时会自动回滚，实际上没有提交任何东西。出现错误时，解决错误，再次提交上次提交的全部内容即可。
3. 冲突解决
冲突的解决是我们使用SVN过程中的一个棘手问题，所以独立一节来谈论。
3.1 冲突的产生
冲突发生在多个成员同时对同一个文件进行修改的情形下。即当有其他成员已经提交了修改，而自己在本地拷贝中也对该文件进行了修改，而且修改的是同一个地方，那么在进行本地文件的更新时，SVN会不知道该选择那个修改（SVN上的修改还是本地的修改）来进行合并，所以冲突就产生了。
举例说，假如受SVN控制的文件Day.txt在SVN服务器上的当前内容如下：
图表 3 Day.txt文件在本地的修改
我们可以看到，在文本的第一行，SVN上及本地都做了修改。这样当在本地进行更新（提交之前必须先更新），SVN合并时就不知道monday后面到底该是work还是sleep，所以冲突就产生了。
而第三、五行是各自进行了修改，并没有冲突，所以这两行可以顺利合并，合并后可以看到所有人所做的修改。
3.2 冲突的解决
冲突发生后，SVN会在本地保存该文件的不同修改版本，见下图蓝色图标：

图表 4 Day.txt文件的不同版本
 Day.txt.r35是版本35的Day.txt文件（本地拷贝最新版本）
 Day.txt.r37是版本37的Day.txt文件（SVN上最新版本）
 Day.txt.mine的是本地修改后的Day.txt文件
 Day.txt文件中包含了合并后的内容
3.2.1 简单冲突解决
对于简单的内容冲突，我们可以直接在合并后的文件上修改。在上例中，我们打开Day.txt文件，可以看到SVN合并后的内容：

图表 5 Day.txt合并后内容
我们看到没有冲突的修改：(play basketball)及（meeting）顺利地合并了，而冲突的部分出现了一些标记。其中标记
<<<<<<< .mine
=======
之间包含的是本地修改的冲突部分的内容，即monday(work)。而标记
=======
>>>>>>> .r37
之间包含的是版本37（SVN上最新版本）该部分内容，即monday(sleep)。
不失一般性，假如我们现在要保留的内容是monday(work)，那么我们只要把标记及monday(sleep)部分内容去掉即可：

图表 6 Day.txt解决冲突后内容
确保修改正确后，把Day.txt文件设置为“已解决的”。

图表 7 Day.txt标记为已解决
之后，后缀为mine,r35,r37文件全部消失，仅保留已解决冲突的Day.txt文件，提交到SVN即可。
3.2.2 复杂冲突解决
对于文件内容复杂的文件，上述的解决方法容易漏掉一些要修改的部分，解决起来也耗时耗力。这时要通过SVN提供的工具来解决。
选择SVN功能“编辑冲突”，打开冲突编辑工具:

图表 8 冲突编辑工具
上半部分的两个内容栏分别显示的是版本37的内容及本地修改的内容。
下半部分的内容栏显示的是合并后的内容。
每个内容栏左边的标记清楚地标识了该文件做了那些修改。
文件冲突的部分用红色显眼地表示了出来。在合并栏，点击冲突部分，点击右键，我们可以选择用哪个内容（SVN上最新内容或者本地修改内容）来解决冲突部分，也可以选择两个内容都使用，同时选择它们出现的先后顺序。
逐一解决各个冲突。确保所有冲突都解决后，保存文件，并标记为“已解决”的，退出该工具即完成冲突的解决。
4. 加锁策略
事实上，解决冲突还有一种方法，那就是“严格加锁”。
“严格加锁”要求在编辑文件之前必须先对文件加锁，然后才能进行编辑。此时团队其他成员不能对该文件进行编辑，即保证了同一时刻只有一个人在编辑该文件，因此避免了冲突的出现。
那么，什么类型的文件我们应该采取“严格加锁”呢？
 Excel、图片等不可合并的文件，我们必须对其“严格加锁”。“严格加锁”的文件都标记为“可读”的，即不可编辑。要编辑这些“严格加锁”的文件，必须先对其加锁，加锁后文件更改为“可读可写”。编辑完这类文件后要第一时间提交。提交完成时，SVN会自动解开任何你拥有的锁 。
 文本文件，比如程序代码，SVN通常可以为我们合并改动，无须“严格加锁”。对于一些大家都频繁改动的重要源代码文件，可能会引起大量冲突，我们也不推荐“严格加锁”，因为加锁会导致大家持续得走来走去去询问加锁情况。正确做法是把文件分成数个逻辑单元，大家都修改各自的单元，减少合并时的冲突。
5. 标签&分支
一个项目最初存放的目录我们称之为主干(trunk)。下面我们讨论除了主干之外其他存放项目的目录——标签(tag)和分支(branch)。
5.1 标签（tag）
版本号可以区分多次的代码修改，我们可以使用版本号来检出需要的代码，但对于重要版本的代码，如第三版发布代码，我们不希望记住r37这样的数字。这时，我们就可以通过创建标签来对SVN中这个发布版本的文件的这个时刻的状态创建一个“快照”，以后就可以通过这个标签名字来检出第三发布版本的代码。
标签其实是当前项目文件的简单拷贝，保存在标签所在的目录下。创建标签也是挺简单的，不过要注意：
 标签的名字一定要有描述性，可以仅凭名字就知道为什么要创建标签。
 不能过多地使用标签，只有在重要时刻或者发布版本时才可以创建标签。
 标签是项目文件在某个时刻的状态，不能对其进行修改 。
5.2 分支（branch）
分支跟标签一样，也是当前项目文件的简单拷贝，保存在分支所在的目录下。
分支跟标签的根本区别在于，标签不能对其进行修改，而分支就是为了某种目的的修改而建立的。在检出代码时检出指定分支即可，分支的操作跟主干上的操作完全相同。
5.2.1 何时创建
遇到下述情况，我们可以通过创建分支来解决问题：
 发布分支
当我们快要发布一个版本了，一个开发小团队要为这次发布做好准备，比如说修改一些收尾的bug。这时他们需要的是项目的稳定性，而同时我们还有其他团队要开发预计下次发布才会添加进去的功能，显然他们不能在同一份代码上工作，因此我们需要从主干中建立出一个发布分支，发布团队都从这个发布分支检出及提交代码。当程序被发布之后，这个分支依然是活动的。这样，如果客户报告了一些bug，团队会在这个发布分支中修正它们并视情况合并到主干中去。
 试验分支
当我们需要对项目做大范围的改动，并且这改动对系统的其余部分有深远的影响，而我们又不能保证这次改动一定能成功的时候就可以建立试验分支。如果试验失败了，可以废弃这个分支；成功了我们只要把分支的改动合并到主干代码中去就可以了。
其他情况，我们不建议创建分支，更不推荐在分支上创建分支，因为分支过多，合并时的冲突将会是一种难于解决的灾难。
5.2.2 合并分支
我们在分支上所修正的bug很可能在主干上或者其他分支上也存在，因为它们往往来自同一份代码，所以我们在分支上所做的改动有必要合并到主干或者其他分支中去。
对于简单的bug，一次提交就能解决问题的，那么我们只要记住提交新版本号，然后使用新版本号把改动合并到其他的受影响的主干及分支中去就可以了。
对于复杂的bug，可能需要多个开发者花几天的时间提交多次才能修好。这时光用版本号来记住修改的内容就有点勉为其难了。因此，我们可以使用标签来标记我们修正过程的开始和结束，然后使用这些标签帮助我们把修正的代码合并到主干和其他分支中去。整个过程如下：
① 给分支打个标签，标记bug修改开始。
② 测试重现bug，修正代码让新测试通过。
③ 提交你的改动到SVN上。
④ 重复步骤2、3，直到确定bug已经修正。
⑤ 再给分支打个标签，标记bug修正结束。
⑥ 使用两个标签来把修正的代码合并到所有其他受影响的主干和分支上。
6. 注意事项
经常更新
 由于文件可能有多个人修改，应该经常更新你的工作拷贝中的文件，这样能降低发生冲突的可能性。
测试提交
 提交前先在本地进行测试。不允许将有错误的文件提交到SVN服务器上。
填写备注
 提交时一定要写备注：备注有助于其他人（包括三个月后的你自己）理解你对文件所做的修改。
整体提交
 提交文件时注意要提交一项改动所对应的所有文件，不要一次提交一个文件或者一次提交修改了很多功能的一堆文件。
发布标签
 对于每一个发布的版本都要建立标签：当用户告诉你发生某个问题时，你可以迅速地追踪到问题是在哪个版本引入的 。

附：测试自动化小组SVN使用指导原则
1. Project的构建
Project在SVN服务器上的目录架构如下：

SVN上的项目文件：
1. 必须保证Trunk上的代码是最新的！定期对Trunk上的代码进行更新，各小组可根据各自实际情况自己把握
2. Tag是根据项目需要所打的标签，每一个发布的版本都要打Tag，主要是方便有需要时可以直接根据Tag返回到之前的状态，以便于分析、测试；Tag中必须包含相应的release文件及当时编译或发布时的源代码，必须有相关的文档注明项目背景、发布情况等。
3. Branch文件夹可以用作备份用，可以用个人名字命名文件夹；此外，Branch分支主要用来进行短暂或者探索性的开发使用，最终的软件版本必须更新、合并到Trunk主干上。
4. 关于同一项目组开发环境的建议：同一项目组成员的开发环境最好一致，软件安装路径和Project文件存放路径最好一致。
2. 版本号
关于版本号命名规则：主版本号.子版本号.修正版本号
1. 项目初版本时，版本号为0.1.0；
2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0；
4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1，子版本号和修正版本号复位为0；
5. 编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，如果编译器不能自动生成，人手添加，数值代表为当前的系统时间。
例子：V1.0.1 Build090305 Rel111123
其它版本使用规则：
1. α（alphal）内部测试版
此版本表示该软件仅仅是一个初步完成品，只在组内内部交流，该版本软件的 bug 较多，限内部测试使用。
例子：V0.1.1 Build090305 alphal1
2. β（beta）外部测试版
该版本相对于α版已有了很大的改进，经过组内的测试，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模测试来进一步消除。
例子：V0.1.2 Build090305 beta1
3. demo 演示版
仅限评审或讲解时做介绍使用。
例子：V0.1.3 Build090305 demo1
4. release 最终版
该版本意味“最终释放版”，在出了一系列的测试版之后，终归会有一个正式版本，一般情况下，release不会以单词形式出现在软件封面上，取而代之的是符号 (Rel) 。release版本发布时，必须将待发布的软件和相应版本更新记录打包在一起发出。
例子：V1.0.1 Build090305 Rel111123
3. 权限限制
如果项目本身需要对项目组成员作不同的权限控制，可以考虑维护两个工程：一个工程里面有相应的源文件，一个则只有编译后的文件。
4. 模块的版本维护
1. 文件一般不需要版本，但要有详细的更新历史记录；
2. 模块可以以版本来维护，具体可以不同的文件夹区分。

⑷ 备份旧计算机中的用户文件和配置信息的具体操作方法

1、系统备份文件（如*.gho文件）部分是可以直接拷到其它电脑上使用的，如果其它电脑的配件和备份电脑的配置是完全一样的，那么这个备份文件安装完就可以使用，无需再进行任何操作和设置。系统和原备份电脑是一模一样的。 2、电脑配置不一样，但架构平台相同的，如INTEL平台，旧架构的备份文件不能用在新架构的电脑上，会蓝屏。高版本的备份文件则可以用在低版本的电脑上，不过安装后，要先进入安全模式，卸载有差别配件的驱动，再相应本机电脑，安装正确的驱动。 3、如果架构平台不相同，如INTEL平台的备份文件用在AMD平台上，或反之，都是不行的。 4、如果用一定的电脑基础，备份文件前，先用专门的封装软件，先将原系统进行封装后，再进行备份的备份文件，则可以在任何配置不同，架构新旧不同和架构平台不同的电脑上进行安装。（就象卖的GHOST版本系统安装光盘中的文件）

⑸ 什么是备份策略

什么是备份
所谓备份，就是把数据库复制到转储设备的过程。其中，转储设备是指用于放置数据库拷贝的磁带或磁盘。通常也将存放于转储设备中的数据库的拷贝称为原数据库的备份或转储。如下图所示：

ORACLE数据库的备份分为物理备份和逻辑备份两种。物理备份是将实际组成数据库的操作系统文件从一处拷贝到另一处的备份过程，通常是从磁盘到磁带。可以使用 Oracle 的恢复管理器（Recovery Manager，RMAN）或操作系统命令进行数据库的物理备份。逻辑备份是利用SQL语言从数据库中抽取数据并存于二进制文件的过程。Oracle提供的逻辑备份工具是 EXP。

数据库逻辑备份是物理备份的补充。

根据在物理备份时数据库的状态，可以将备份分为一致性备份（consistent backup）和不一致性备份（inconsistent backup）两种：

一致性备份：一致性备份是当数据库的所有可读写的数据库文件和控制文件具有相同的系统改变号（SCN），并且数据文件不包含当前 SCN 之外的任何改变。在做数据库检查点时，Oracle 使所有的控制文件和数据文件一致。对于只读表空间和脱机的表空间，Oracle 也认为它们是一致的。使数据库处于一致状态的唯一方法是数据库正常关闭（用shutdown normal 或 shutdown immediate 命令关闭）。因此，只有在以下条件下的备份是一致性备份：
数据库正常关闭（用shutdown normal 或 shutdown immediate 命令关闭）。
不一致性备份：不一致备份是当数据库的可读写的数据库文件和控制文件的系统改变号（SCN）在不一致条件下的备份。对于一个 7*24 工作的数据库来说，由于不可能关机，而数据库数据是不断改变的，因此只能进行不一致备份。在 SCN 号不一致的条件下，数据库必须通过应用重做日志使 SCN 一致的情况下才能启动。因此，如果进行不一致备份，数据库必须设为归档状态，并对重做日志归档才有意义。在以下条件下的备份是不一致性备份：
数据库处于打开状态。
数据库处于关闭状态，但是用非正常手段关闭的。例如，数据库是通过 shutdown abort 或机器掉电等等方法关闭的。

什么是恢复
所谓恢复，就是把数据库由存在故障的状态转变为无故障状态的过程。根据出现故障的原因，恢复分为两种类型：

实例恢复。这种恢复是Oracle实例出现失败后，Oracle自动进行的恢复。
介质恢复。这种恢复是当存放数据库的介质出现故障时所做的恢复。本书后面提到的恢复都是指介质恢复。
装载（restore）物理备份与恢复（Recover）物理备份是介质恢复的手段。装载是将备份考回到磁盘，恢复是利用重做日志（物理备份的一部分）修改考回到磁盘的数据文件（物理备份的另一部分），从而恢复数据库的过程。如下图所示：

根据数据库的恢复程度，将恢复方法分为两种类型：

完全恢复：将数据库恢复到数据库失败时数据库的状态。这种恢复是通过装载数据库备份和并应用全部的重做日志做到的。
不完全恢复：将数据库恢复到数据库失败前的某一时刻数据库的状态。这种恢复是通过装载数据库备份和并应用部分的重做日志做到的。进行不完全恢复后必须在启动数据库时用 resetlogs 选项重设联机重做日志。
例如，在上午10：00，由于磁盘损坏导致数据库中止使用。现在使用两种方法进行数据库的恢复，第一种方法使数据库可以正常使用，且使恢复后与损坏时（10：00）数据库中的数据相同，那么第一种恢复方法就属于完全恢复类型；第二种方法能使数据库正常使用，但只能使恢复后与损坏前（例如9：00）数据库中的数据相同，没能恢复数据库到失败时（10:00）数据库的状态，那么第二种恢复方法就属于不完全恢复类型。

事实上，如果数据库备份是一致性的备份，则装载后的数据库即可使用，从而也可以不用重做日志恢复到数据库备份时的点。这也是一种不完全恢复。

备份与恢复的关系
备份一个ORACLE数据库，类似于买医疗保险——在遇到疾病之前不会意识到它的重要性，获得保险金的数量取决于保险单的种类。同理，随着制作备份的种类和频繁程度的不同，数据库发生故障后其恢复的可行性、难度与所花费的时间也不同。

数据库故障是指数据库运行过程中影响数据库正常使用的特殊事件。数据库故障有许多类型，最严重的是介质失败（如磁盘损坏），这种故障如不能恢复将导致数据库中数据的丢失。数据库故障类型有：

语句失败。
用户进程失败。
实例失败。
用户或应用错误操作。这类错误可能是意外地删除了表中的数据等错误操作。
介质失败。如硬盘失败，硬盘中的数据丢失。
自然灾害。如地震、洪水等。
由于故障类型的不同，恢复数据库的方法也不同。通过装载备份来恢复数据库既是常用的恢复手段，也是恢复介质失败故障的主要方法。

备份与恢复要考虑的问题
备份与恢复要考虑以下的三个问题：

备份与恢复策略要考虑的商业、操作、及技术问题
灾难恢复计划的组成
测试备份与恢复策略的重要性
能够进行什么样的恢复依赖于有什么样的备份。作为 DBA，有责任从以下三个方面维护数据库的可恢复性：

使数据库的失效次数减到最少，从而使数据库保持最大的可用性；
当数据库不可避免地失效后，要使恢复时间减到最少，从而使恢复的效率达到最高；
当数据库失效后，要确保尽量少的数据丢失或根本不丢失，从而使数据具有最大的可恢复性。
备份与恢复策略要考虑的商业、操作、及技术问题
作为 DBA，首先需要了解企业是如何使用数据库系统的，以及企业对数据库的可用性，恢复性能，和数据的可恢复性以及恢复时间的要求。然后，DBA 需要使企业的管理人员了解维护这样的数据库的可用性的代价有多大。做到这点的最好方法是评估恢复需要的花费，以及丢失数据给企业带来的损失。

在代价被评估后，就可以进行备份与恢复的讨论了。此时，要定义数据库总体的可用性需求，并根据各项工作对数据库可用性的影响程度来定义工作重点的次序。例如，如果数据库需要 7*24 的可用性，那么其重要性就高于其它任何工作，其它任何需要关机才能做的工作就不能做。

另外，数据库变化的情况也是备份与恢复策略需要考虑的一个因素。例如，如果数据不断改变，有新数据或数据文件加入，或表结构有大的变化，则应该经常备份；反之，如果数据是静态的或只读的，则备份一次即可。无论如何，应遵从这样一个原则，如果怀疑数据库的可恢复性，就应该备份。

灾难恢复计划的组成
针对灾难恢复，必须回答下述问题：

系统可能出现什么样的灾难恢复情况？
如果出现数据丢失，灾难恢复情况是怎样的？
系统中数据的易变程度如何？
如果出现问题，系统需要多快的速度恢复？
在各种情况下恢复策略的代价，以及相应的花时间重新录入数据的代价?
对这些问题的回答组成了灾难恢复计划。

计算机是易坏的。主板上的芯片、主板电路、内存、电源等任何一项不能正常工作，都会导致计算机系统不能正常工作。当然，这些损坏可以修复，不会导致应用和数据的损坏。但是，如果计算机的硬盘损坏，将会导致数据丢失，此时必须用备份恢复数据。

灾难恢复的最重要步骤是设计充足频率的硬盘备份过程。备份过程应该满足系统要求的可恢复性。例如，如果数据库可有较长的关机时间，则可以每周进行一次冷备份，并归档重做日志；但是，如果数据库只有极少的关机时间，则只能从硬件的角度来考虑备份与恢复的问题，例如使用硬盘镜像或双机系统。选择备份策略的依据是：丢是数据的代价与确保数据不丢失的代价之比。

果每天都能备份当然会很理想，但要考虑其现实性。企业都在想办法降低维护成本，现实的方案才可能被采用。只要仔细计划，并想办法达到数据库可用性的底线，花少量的钱进行成功的备份与恢复也是可能的。

DBA 还应以服务协议的形式制订一个可恢复性与可用性的标准文件。该文件应成为讨论DBA 服务，以及服务是否能达到预期标准的依据。这样做可使所有相关人员对同样的预期有潜在的危机感。

测试备份与恢复策略的重要性
备份与恢复策略必须经测试无误后才可使用。如果进行了备份，但不知道该备份是否支持希望的恢复目标则与根本没有备份没有两样。

恢复策略也要考虑虑对环境的依赖性。例如，假如机器的硬盘失效了，供货商能在多长时间内提供一个新的硬盘；在机器需要重新启动时，能找到操作系统管理员吗？

另外一个需要考虑的问题是数据库是否能经受自然的破坏。应在与计算机不同的地方再存储一份备份介质，以免出现自然灾害时主机与备份一起遭到破坏。

最后需要考虑的问题是万一DBA 出现了问题怎么办？后备的DBA能否执行备份策略？他或她能找到支持用的文档吗？这些文档存在吗？

没有比花了大精力指定了好的计划，但没有测试其有效性而使其付诸东流的了。一个好的计划还应容纳人为错误，特别是用于开发的系统。理想的测试计划应包括以下内容：

一系列的测试例子及其状态描述；
测试结果是否成功的标准；
解决这些状态的步骤。
只有在上述情况测试成功的前提下，DBA 才应该考虑把备份

⑹ 常见的3种备份策略是什么

备份策略指确定需备份的内容、备份时间及备份方式。常见的备份策略有完全备份、增量备份、差异备份三种类型。作以简单介绍：
1、完全备份(Full Backup)：
每次对数据进行完整的备份。当发生数据丢失的灾难情况时，完全备份无需依赖其他信息，即可实现100%数据恢复，其恢复时间最短且操作最方便；
2、增量备份(Incremental Backup)：
只有那些在上次完全备份或者增量备份后被修改了的文件才会被备份。优点是备份数据量小，需要的时间短，缺点是恢复的时候需要依赖之前的备份记录，出问题的风险较大；
3、差异备份(Differential Backup)：
备份那些自从上次完全备份之后被修改过的文件。因此从差异备份中恢复数据的时间较短，因为只需要两份数据——最后一次完全备份和最后一次差异备份，缺点是每次备份需要的时间较长。

⑺ 一个完整的数据备份及恢复方案应包括那些

尊敬的用户您好：
常见的数据备份与恢复方法有以下几种：
1.数据备份：数据备份(Backup)是指将计算机硬盘上的原始数据（程序）复制到可移动媒体(Removable Media)上，如磁盘、磁带、光盘等，在出现数据丢失或系统灾难时将复制在可移动媒体上的数据恢复到硬盘上，从而保护计算机的系统数据和应用数据。
2.数据恢复：数据恢复(Recover)是数据备份的逆过程，即将备份的数据恢复到硬盘上的操
作。
3.数据归档：数据归档(Archive)将硬盘数据复制到可移动媒体上，与数据备份不同的是，数据归档在完成复制工作后将原始数据从硬盘上删除，释放硬盘空间。数据归档一般是对与年度或某一项目相关的数据进行操作，在一年结束或某一项目完成时将其相关数据存到可移动媒体上，以备日后查询和统计，同时释放宝贵的硬盘空间。
3.归档恢复：归档恢复(Retrieve)是数据归档的逆操作，将归档数据写回到硬盘上。
4.在线备份：在线备份(On-line backup)是指对正在运行的数据库或应用进行备份，通常对打开的数据库和应用是禁止备份操作的，然而现在的有些计算机应用系统要求24小时运转(如银行的ATM业务)，因此要求数据存储管理软件能够对在线的数据库和应用进行备份。
5.离线备份：离线备份(Off-line backup)指在数据库SHUTDOWN或应用关闭后对其数据进行备份，离线
备份通常采用全备份。
6.全备份：全备份(Full backup)是备份策略的一种。执行数据全部备份操作。
7.增量备份：增量备份(Incremental backup)相对全备份而言，是备份策略的一种，只备份上一次备份后数据的改变量。
8.并行技术：并行技术(Parallelism)是指将不同的数据源同时备份/恢复到同一个备份设备/硬盘上。并行技术是考察数据存储管理软件性能的一个重要参数，有些厂商的软件只能支持并行备份，而有的厂商则可以实现并行地备份及恢复；并且，真正有效的并行技术将可以充分利用备份设备的备份速度(带宽)，实现大数据量有限时间备份。
9.数据克隆：数据克隆(Clone)是实现灾难恢复的一种重要手段，通过将原始数据同时备份到两份可移动媒体上，将其中一份备份数据(Clone)转移到地理位置不同的办公室存放，在计算机系统发生重大灾难如火灾，系统连接的
备份设备和备份数据都被损坏的情况下，将重要数据在另一套系统上恢复，保障业务的正常运行。所有数据存储管理软件都提供克隆功能。

中国电信提供最优质的网络通讯服务，老友换新机，网龄抵现金，百兆宽带免费体验，超清电视iTV，电信活动可以直接通过营业厅查询。

⑻ 数据库备份的方法和策略是怎样的

不知道你是用的那种数据库
可能不通的数据库用的方法有差异吧
一般可以采用增量差异备份
其实呢,要指定符合自己实际的备份策略
不能盲目的意味照搬网上的方法
一般有0级备份,一级增量备份,二级增量备份等
一般周末做个0级备份,星期一至星期三做个二级增量备份,星期四做个1级增量备份周五-周六再做个2级增量备份,网上有很多这样的说法,现实中这种策略也是比较好的