原文:SQL Server的备份 0.参考文献 1.恢复模式 SQL Server 备份和还原操作发生在数据库的恢复模式的上下文中。 恢复模式旨在控制事务日志维护。 “恢复模式”是一种数据库属性，它控制如何记录事务，事务日志是否需要（以及允许）备份，以及可以使用哪些类型的还原操作。 有三种恢复模式：简单恢复模式、完整恢复模式和大容量日志恢复模式。通常，数据库使用完整恢复模式或简单恢复模式。可以在执行大容量操作之前切换到大容量日志恢复模式，以补充完整恢复模式。数据库可以随时切换为其他恢复模式。 1.1恢复模式概述 下表概述了这三种恢复模式。   恢复模式 说明 工作丢失的风险 能否恢复到时点？ 简单(SIMPLE) 无日志备份。 自动回收日志空间以减少空间需求，实际上不再需要管理事务日志空间。 有关简单恢复模式下数据库备份的信息，请参阅完整数据库备份 (SQL Server)。 最新备份之后的更改不受保护。 在发生灾难时，这些更改必须重做。 只能恢复到备份的结尾。 有关详细信息，请参阅完整数据库还原（简单恢复模式）。 完全(FULL) 需要日志备份。 数据文件丢失或损坏不会导致丢失工作。 可以恢复到任意时点（例如应用程序或用户错误之前）。 有关完整恢复模式下数据库备份的信息，请参阅完整数据库备份 (SQL Server)和完整数据库还原（完整恢复模式）。 正常情况下没有。 如果日志尾部损坏，则必须重做自最新日志备份之后所做的更改。 如果备份在接近特定的时点完成，则可以恢复到该时点。 有关使用日志备份还原到故障点的信息，请参阅将 SQL Server 数据库还原到某个时点（完整恢复模式）.  注意 如果有两个或更多必须在逻辑上保持一致的完整恢复模式数据库，则最好执行特殊步骤，以确保这些数据库的可恢复性。 有关详细信息，请参阅包含标记的事务的相关数据库的恢复。 大容量日志(BULK_INSERT) 需要日志备份。 是完整恢复模式的附加模式，允许执行高性能的大容量复制操作。 通过使用最小方式记录大多数大容量操作，减少日志空间使用量。 有关尽量减少日志量的操作的信息，请参阅事务日志 (SQL Server)。 有关大容量日志恢复模式下数据库备份的信息，请参阅完整数据库备份 (SQL Server) 和完整数据库还原（完整恢复模式）。 如果在最新日志备份后发生日志损坏或执行大容量日志记录操作，则必须重做自该上次备份之后所做的更改。 否则不丢失任何工作。 可以恢复到任何备份的结尾。 不支持时点恢复。 1.2.如何查看或更改数据库恢复模式 (SQL Server Management Studio) 查看或更改数据库的恢复模式 连接到相应的 Microsoft SQL Server 数据库引擎 实例之后，在对象资源管理器中，单击服务器名称以展开服务器树。 展开“数据库”，然后根据数据库的不同，选择用户数据库，或展开“系统数据库”，再选择系统数据库。 右键单击该数据库，再单击“属性”，这将打开“数据库属性”对话框。 在“选择页”窗格中，单击“选项”。 当前恢复模式显示在“恢复模式”列表框中。 也可以从列表中选择不同的模式来更改恢复模式。可以选择“完整”、“大容量日志”或“简单”。如下图所示：  1.3.使用TSQL更改数据库恢复模式 --更改数据库恢复模式 alter database AdventureWorks2012 set recovery {FULL|SIMPLE|BULK_LOGGED} --简单恢复模式 alter database AdventureWorks2012 set recovery SIMPLE --完整恢复模式 alter database AdventureWorks2012 set recovery BULK_LOGGED --大容量日志恢复模式 alter database AdventureWorks2012 set recovery FULL 1.4.估计完整数据库备份的大小 　　在实现备份与还原策略之前，应当估计完整数据库备份将使用的磁盘空间。 备份操作会将数据库中的数据复制到备份文件。 备份仅包含数据库中的实际数据，而不包含任何未使用的空间。 因此，备份通常小于数据库本身。（这也是为什么完整数据库备份比文件备份更加节省空间的原因。） 您可以使用 sp_spaceused系统存储过程估计完整数据库备份的大小。 有关详细信息，请参阅 sp_spaceused (Transact-SQL)。 2.为磁盘文件定义逻辑备份设备 2.1.限制和局限 逻辑设备名称在服务器实例上的所有逻辑备份设备中必须是唯一的。 若要查看现有逻辑设备名称，请查询sys.backup_devices 目录视图。 2.2.建议 我们建议备份磁盘应不同于数据库数据和日志的磁盘。 这是数据或日志磁盘出现故障时访问备份数据必不可少的。 2.3使用 SQL Server Management Studio为磁盘文件定义逻辑备份设备 连接到相应的 Microsoft SQL Server 数据库引擎实例之后，在对象资源管理器中，单击服务器名称以展开服务器树。 展开“服务器对象”，然后右键单击“备份设备”。 单击“新建备份设备”。 将打开“备份设备”对话框。 输入设备名称。 若要确定目标位置，请单击“文件”并指定该文件的完整路径。 若要定义新设备，请单击“确定”。 若要备份至新设备，右键设备名称，选择"back up a database"，然后再具体的对话框中选择需要备份的数据库。如下图所示： 2.4.使用 Transact-SQL为磁盘文件定义逻辑备份 --查询备份设备 select * from sys.backup_devices; --定义磁盘备份设备 EXEC sp_addumpdevice 'disk', 'mybackupdisk', 'd:\backup\backup1.bak' ; --删除磁盘备份设备 EXEC sp_dropdevice 'mybackupdisk', 'delfile' ; 3.创建完整数据库备份 (SQL Server) 关于完整备份的点（PS：2012-7-17） 问题：sql server从2点开始备份，4点备份完。那么进行完整还原的时候，恢复到的是哪一个时间点。是2点，还是4点，或者是其他时间点。 解答：首先，恢复到的是4点。这是因为在进行full database backup的时候，会有一个开始备份的LSNs，在full database backup 完成的时候，又有一个备份完成的LSNe。在备份完成以后，数据库会redo从LSNa到LSNb这一段log record。所以回复到的是4点。 执行如下命令 dbcc log(TESTDB3,3) checkpoint backup database TESTDB3 to disk='d:\backup\backup3.bak' dbcc log(TESTDB3,3) 查询结果如下所示： 这说明进行backup的时候会被记录到log record中。 3.1.限制和局限 不允许在显式或隐式事务中使用 BACKUP 语句。 无法在早期版本的 SQL Server 中还原较新版本的 SQL Server 创建的备份。 3.2.建议 随着数据库不断增大，完整备份需花费更多时间才能完成，并且需要更多的存储空间。 因此，对于大型数据库而言，您可以用一系列“差异数据库备份”来补充完整数据库备份。 有关详细信息，请参阅差异备份 (SQL Server)。 您可以使用 sp_spaceused 系统存储过程估计完整数据库备份的大小。 默认情况下，每个成功的备份操作都会在 SQL Server 错误日志和系统事件日志中添加一个条目。 如果非常频繁地备份日志，这些成功消息会迅速累积，从而产生一个巨大的错误日志，这样会使查找其他消息变得非常困难。 在这些情况下，如果任何脚本均不依赖于这些日志条目，则可以使用跟踪标志 3226 取消这些条目。 有关详细信息，请参阅跟踪标志 (Transact-SQL)。 3.3.权限 默认情况下，为 sysadmin 固定服务器角色以及 db_owner 和 db_backupoperator 固定数据库角色的成员授予 BACKUP DATABASE 和 BACKUP LOG 权限。 备份设备的物理文件的所有权和权限问题可能会妨碍备份操作。 SQL Server 必须能够读取和写入设备；运行 SQL Server 服务的帐户必须具有写入权限。 但是，用于在系统表中为备份设备添加项目的 sp_addumpdevice 不检查文件访问权限。 备份设备物理文件的这些问题可能直到为备份或还原而访问物理资源时才会出现。 3.4.使用 SQL Server Management Studio备份数据库 右键数据库AdventureWorks2012->tasks->back up，如下图所示： 完全备份配置选项 backup type:full，表示完全备份 backup component:database backup set->name:默认 backup set will expire：after：0，表示永远不失效。 destination：disk，表示备份到磁盘 点击add选择备份设备或者指定备份路径，如下图所示： 我们这里选择的是前面创建的backup device：mybackupdisk。 注意：我们可以指定多个backup device。指定多个备份设备可以节约备份时间。并行写入。 验证 完成上述配置以后并确定备份，我们就可以在磁盘目录”d:\backup\backup1.bak"下找到我们的备份文件，一共有189MB。 3.5.使用 Transact-SQL创建完整数据库备份 --默认情况下，BACKUP DATABASE 创建完整备份。 --定义备份设备 EXEC sp_addumpdevice 'disk', 'mybackupdisk2', 'd:\backup\backup2.bak'; --备份到逻辑设备 BACKUP DATABASE AdventureWorks2012 TO mybackupdisk2 WITH NOINIT,NAME = 'Full Backup of AdventureWorks2012'; --直接备份到磁盘 BACKUP DATABASE AdventureWorks2012 TO disk='d:\backup\backup3.bak' WITH NOINIT,NAME = 'Full Backup of AdventureWorks2012'; BACKUP具体语法参考BACKUP (Transact-SQL)。 4.差异数据库备份 4.1.必备条件 　　创建差异数据库备份需要有以前的完整数据库备份。 如果选定的数据库从未进行过备份，则请在创建任何差异备份之前，先执行完整数据库备份。 有关详细信息，请参阅创建完整数据库备份 (SQL Server)。 4.2.建议 　　当差异备份的大小增大时，还原差异备份会显著延长还原数据库所需的时间。 因此，建议按设定的间隔执行新的完整备份，以便为数据建立新的差异基准。 例如，您可以每周执行一次整个数据库的完整备份（即完整数据库备份），然后在该周内执行一系列常规的差异数据库备份。 4.3.使用 SQL Server Management Studio创建差异数据库备份 操作步骤跟3.4节完整备份数据库一样，只是将buckup type类型改成Differential而已。destination可以依然选择完整备份的那一个device，不过要求是NOINIT，而不能是INIT，因为如果是INIT的话会覆盖原来的完整备份。 4.4.使用 Transact-SQL创建差异数据库备份 USE [TSQL2012] --定义备份设备 EXEC sp_addumpdevice 'disk', 'backupdevice1', 'd:\backup\backup_tsql2012.bak'; --完整备份数据库 BACKUP DATABASE TSQL2012 TO backupdevice1 WITH NOINIT,NAME = 'Full Backup of TSQL2012'; --插入数据 INSERT INTO dbo.test(OrderID,ProductID) VALUES(1,1); INSERT INTO dbo.test(OrderID,ProductID) VALUES(2,2); INSERT INTO dbo.test(OrderID,ProductID) VALUES(3,3); --差异备份数据库 BACKUP DATABASE TSQL2012 TO backupdevice1 WITH DIFFERENTIAL,NOINIT,NAME = 'DIFFERENTIAL Backup of TSQL2012'; 验证我们创建的完整备份和差异备份 右键选择数据库TSQL2012->tasks->restore->database，出现如下图所示内容： 如上图所示，出现了我们之前创建的完整备份和差异备份。 5.事务日志备份 5.1.建议 如果数据库使用完整恢复模式或大容量日志恢复模式，则必须足够频繁地备份事务日志，以保护数据和避免事务日志变满。 这将截断日志，并且支持将数据库还原到特定时间点。 默认情况下，每个成功的备份操作都会在 SQL Server 错误日志和系统事件日志中添加一个条目。 如果非常频繁地备份日志，这些成功消息会迅速累积，从而产生一个巨大的错误日志，这样会使查找其他消息变得非常困难。 在这些情况下，如果任何脚本均不依赖于这些日志条目，则可以使用跟踪标志 3226 取消这些条目。 有关详细信息，请参阅跟踪标志 (Transact-SQL)。 5.2.使用 SQL Server Management Studio创建差异数据库备份 5.2.1.例行事务日志的备份 操作步骤跟3.4节完整备份数据库一样，只是将buckup type类型改成Transaction Log而已。然后选择Option选项，我们重点看一下Transaction Log选项。对于例行的日志备份，请保留默认选项“通过删除不活动的条目截断事务日志(Truncate the transaction log)”。如下图所示： 5.2.2.尾部事务日志的备份 若要备份日志尾部（即活动的日志），请选中“备份日志尾部，并使数据库处于还原状态(Back up the tail of the log, and leave database in the restoring state)”。 5.3.使用 Transact-SQL创建差异数据库备份 --插入数据 INSERT INTO dbo.test(OrderID,ProductID) VALUES(4,4); INSERT INTO dbo.test(OrderID,ProductID) VALUES(5,5); --事务日志备份，NOINIT是默认的，表示不重写，而是追加 BACKUP LOG TSQL2012 TO backupdevice1 WITH NAME = 'Transaction Log Backup of TSQL2012'; --插入数据 INSERT INTO dbo.test(OrderID,ProductID) VALUES(6,6); INSERT INTO dbo.test(OrderID,ProductID) VALUES(7,7); --结尾日志备份，如果报错说数据库正在使用，请重启服务。 use master go BACKUP LOG TSQL2012 TO backupdevice1 WITH NORECOVERY,NAME = 'Transaction Tail-Log Backup of TSQL2012'; go 注意：事务日志备份与结尾日志备份就只差了一个关键字NORECOVERY，数据库备份可以有多个事务日志，但是只有一个结尾日志。一般结尾日志多用在数据库恢复的时候。在数据库恢复中，恢复事务日志并不能说明数据库已经恢复完成，但是一旦恢复了结尾日志，这表明数据库恢复工作完成。 验证我们创建的事务日志与结尾日志 右键选择数据库TSQL2012->tasks->restore->database，出现如下图所示内容： 由上图可见，备份中多出我们上述定义的事务日志：Transaction Log Backup of TSQL2012和结尾日志：Transaction Tail-Log Backup of TSQL2012。              

  一、备份Master 及相关的系统数据库 由于系统数据库对Sql Server来说尤其重要，为了确保SQL SERVER系统的正常运行，除了日常备份用户的数据库之外，我们还需要备份系统数据库，如对Master，Model，Msdb（TempDB不需备份）进行完整备份 二、还原Master数据库 如果系统配置丢失或Master出现问题，可以进入单用户模式进行还原；如果出现下列情况，必须重新生成损坏的 master 数据库： A.       master 数据库的当前备份不可用。 B.        存在 master 数据库备份，但由于 Microsoft SQL Server 实例无法启动，因此无法还原该备份。 1、重新生成 master 数据库： 注意：  在 SQL Server 2005 中已废止 Rebuildm.exe 程序。若要重新生成 master 数据库，请使用 setup.exe。 1、  Start /wait setup.exe /qn INSTANCENAME=<InstanceName> REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=<NewStrongPassword> 例：start /wait e:/setup.exe /qn INSTANCENAME=mssqlserver REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=abc123@!@ 注：INSTANCENAME：指定实例名，默认实例则用mssqlserver表示 REINSTALL：指定引擎 SAPWD：强密码 Setup.exe：指定光盘1中的根目录下的文件 /qn 开关用于取消所有安装程序对话框和错误消息。如果指定 /qn 开关，则所有安装程序消息（包括错误消息）都将写入安装程序日志文件。有关日志文件的详细信息，请参阅如何查看 SQL Server 2005 安装日志文件。  指定 /qb 开关将显示基本的安装程序对话框。还会显示错误消息。 本文转自yonghu86 51CTO博客，原文链接：http://blog.51cto.com/yonghu/1321449，如需转载请自行联系原作者

0.参考文献 1.恢复模式 SQL Server 备份和还原操作发生在数据库的恢复模式的上下文中。 恢复模式旨在控制事务日志维护。 “恢复模式”是一种数据库属性，它控制如何记录事务，事务日志是否需要（以及允许）备份，以及可以使用哪些类型的还原操作。 有三种恢复模式：简单恢复模式、完整恢复模式和大容量日志恢复模式。通常，数据库使用完整恢复模式或简单恢复模式。可以在执行大容量操作之前切换到大容量日志恢复模式，以补充完整恢复模式。数据库可以随时切换为其他恢复模式。 1.1恢复模式概述 下表概述了这三种恢复模式。   恢复模式 说明 工作丢失的风险 能否恢复到时点？ 简单(SIMPLE) 无日志备份。 自动回收日志空间以减少空间需求，实际上不再需要管理事务日志空间。 有关简单恢复模式下数据库备份的信息，请参阅完整数据库备份 (SQL Server)。 最新备份之后的更改不受保护。 在发生灾难时，这些更改必须重做。 只能恢复到备份的结尾。 有关详细信息，请参阅完整数据库还原（简单恢复模式）。 完全(FULL) 需要日志备份。 数据文件丢失或损坏不会导致丢失工作。 可以恢复到任意时点（例如应用程序或用户错误之前）。 有关完整恢复模式下数据库备份的信息，请参阅完整数据库备份 (SQL Server)和完整数据库还原（完整恢复模式）。 正常情况下没有。 如果日志尾部损坏，则必须重做自最新日志备份之后所做的更改。 如果备份在接近特定的时点完成，则可以恢复到该时点。 有关使用日志备份还原到故障点的信息，请参阅将 SQL Server 数据库还原到某个时点（完整恢复模式）.  注意 如果有两个或更多必须在逻辑上保持一致的完整恢复模式数据库，则最好执行特殊步骤，以确保这些数据库的可恢复性。 有关详细信息，请参阅包含标记的事务的相关数据库的恢复。 大容量日志(BULK_INSERT) 需要日志备份。 是完整恢复模式的附加模式，允许执行高性能的大容量复制操作。 通过使用最小方式记录大多数大容量操作，减少日志空间使用量。 有关尽量减少日志量的操作的信息，请参阅事务日志 (SQL Server)。 有关大容量日志恢复模式下数据库备份的信息，请参阅完整数据库备份 (SQL Server) 和完整数据库还原（完整恢复模式）。 如果在最新日志备份后发生日志损坏或执行大容量日志记录操作，则必须重做自该上次备份之后所做的更改。 否则不丢失任何工作。 可以恢复到任何备份的结尾。 不支持时点恢复。 1.2.如何查看或更改数据库恢复模式 (SQL Server Management Studio) 查看或更改数据库的恢复模式 连接到相应的 Microsoft SQL Server 数据库引擎 实例之后，在对象资源管理器中，单击服务器名称以展开服务器树。 展开“数据库”，然后根据数据库的不同，选择用户数据库，或展开“系统数据库”，再选择系统数据库。 右键单击该数据库，再单击“属性”，这将打开“数据库属性”对话框。 在“选择页”窗格中，单击“选项”。 当前恢复模式显示在“恢复模式”列表框中。 也可以从列表中选择不同的模式来更改恢复模式。可以选择“完整”、“大容量日志”或“简单”。如下图所示：  1.3.使用TSQL更改数据库恢复模式 --更改数据库恢复模式 alter database AdventureWorks2012 set recovery {FULL|SIMPLE|BULK_LOGGED} --简单恢复模式 alter database AdventureWorks2012 set recovery SIMPLE --完整恢复模式 alter database AdventureWorks2012 set recovery BULK_LOGGED --大容量日志恢复模式 alter database AdventureWorks2012 set recovery FULL 1.4.估计完整数据库备份的大小 　　在实现备份与还原策略之前，应当估计完整数据库备份将使用的磁盘空间。 备份操作会将数据库中的数据复制到备份文件。 备份仅包含数据库中的实际数据，而不包含任何未使用的空间。 因此，备份通常小于数据库本身。（这也是为什么完整数据库备份比文件备份更加节省空间的原因。） 您可以使用 sp_spaceused系统存储过程估计完整数据库备份的大小。 有关详细信息，请参阅 sp_spaceused (Transact-SQL)。 2.为磁盘文件定义逻辑备份设备 2.1.限制和局限 逻辑设备名称在服务器实例上的所有逻辑备份设备中必须是唯一的。 若要查看现有逻辑设备名称，请查询sys.backup_devices 目录视图。 2.2.建议 我们建议备份磁盘应不同于数据库数据和日志的磁盘。 这是数据或日志磁盘出现故障时访问备份数据必不可少的。 2.3使用 SQL Server Management Studio为磁盘文件定义逻辑备份设备 连接到相应的 Microsoft SQL Server 数据库引擎实例之后，在对象资源管理器中，单击服务器名称以展开服务器树。 展开“服务器对象”，然后右键单击“备份设备”。 单击“新建备份设备”。 将打开“备份设备”对话框。 输入设备名称。 若要确定目标位置，请单击“文件”并指定该文件的完整路径。 若要定义新设备，请单击“确定”。 若要备份至新设备，右键设备名称，选择"back up a database"，然后再具体的对话框中选择需要备份的数据库。如下图所示： 2.4.使用 Transact-SQL为磁盘文件定义逻辑备份 --查询备份设备 select * from sys.backup_devices; --定义磁盘备份设备 EXEC sp_addumpdevice 'disk', 'mybackupdisk', 'd:\backup\backup1.bak' ; --删除磁盘备份设备 EXEC sp_dropdevice 'mybackupdisk', 'delfile' ; 3.创建完整数据库备份 (SQL Server) 关于完整备份的点（PS：2012-7-17） 问题：sql server从2点开始备份，4点备份完。那么进行完整还原的时候，恢复到的是哪一个时间点。是2点，还是4点，或者是其他时间点。 解答：首先，恢复到的是4点。这是因为在进行full database backup的时候，会有一个开始备份的LSNs，在full database backup 完成的时候，又有一个备份完成的LSNe。在备份完成以后，数据库会redo从LSNa到LSNb这一段log record。所以回复到的是4点。 执行如下命令 dbcc log(TESTDB3,3) checkpoint backup database TESTDB3 to disk='d:\backup\backup3.bak' dbcc log(TESTDB3,3) 查询结果如下所示： 这说明进行backup的时候会被记录到log record中。 3.1.限制和局限 不允许在显式或隐式事务中使用 BACKUP 语句。 无法在早期版本的 SQL Server 中还原较新版本的 SQL Server 创建的备份。 3.2.建议 随着数据库不断增大，完整备份需花费更多时间才能完成，并且需要更多的存储空间。 因此，对于大型数据库而言，您可以用一系列“差异数据库备份”来补充完整数据库备份。 有关详细信息，请参阅差异备份 (SQL Server)。 您可以使用 sp_spaceused 系统存储过程估计完整数据库备份的大小。 默认情况下，每个成功的备份操作都会在 SQL Server 错误日志和系统事件日志中添加一个条目。 如果非常频繁地备份日志，这些成功消息会迅速累积，从而产生一个巨大的错误日志，这样会使查找其他消息变得非常困难。 在这些情况下，如果任何脚本均不依赖于这些日志条目，则可以使用跟踪标志 3226 取消这些条目。 有关详细信息，请参阅跟踪标志 (Transact-SQL)。 3.3.权限 默认情况下，为 sysadmin 固定服务器角色以及 db_owner 和 db_backupoperator 固定数据库角色的成员授予 BACKUP DATABASE 和 BACKUP LOG 权限。 备份设备的物理文件的所有权和权限问题可能会妨碍备份操作。 SQL Server 必须能够读取和写入设备；运行 SQL Server 服务的帐户必须具有写入权限。 但是，用于在系统表中为备份设备添加项目的 sp_addumpdevice 不检查文件访问权限。 备份设备物理文件的这些问题可能直到为备份或还原而访问物理资源时才会出现。 3.4.使用 SQL Server Management Studio备份数据库 右键数据库AdventureWorks2012->tasks->back up，如下图所示： 完全备份配置选项 backup type:full，表示完全备份 backup component:database backup set->name:默认 backup set will expire：after：0，表示永远不失效。 destination：disk，表示备份到磁盘 点击add选择备份设备或者指定备份路径，如下图所示： 我们这里选择的是前面创建的backup device：mybackupdisk。 注意：我们可以指定多个backup device。指定多个备份设备可以节约备份时间。并行写入。 验证 完成上述配置以后并确定备份，我们就可以在磁盘目录”d:\backup\backup1.bak"下找到我们的备份文件，一共有189MB。 3.5.使用 Transact-SQL创建完整数据库备份 --默认情况下，BACKUP DATABASE 创建完整备份。 --定义备份设备 EXEC sp_addumpdevice 'disk', 'mybackupdisk2', 'd:\backup\backup2.bak'; --备份到逻辑设备 BACKUP DATABASE AdventureWorks2012 TO mybackupdisk2 WITH NOINIT,NAME = 'Full Backup of AdventureWorks2012'; --直接备份到磁盘 BACKUP DATABASE AdventureWorks2012 TO disk='d:\backup\backup3.bak' WITH NOINIT,NAME = 'Full Backup of AdventureWorks2012'; BACKUP具体语法参考BACKUP (Transact-SQL)。 4.差异数据库备份 4.1.必备条件 　　创建差异数据库备份需要有以前的完整数据库备份。 如果选定的数据库从未进行过备份，则请在创建任何差异备份之前，先执行完整数据库备份。 有关详细信息，请参阅创建完整数据库备份 (SQL Server)。 4.2.建议 　　当差异备份的大小增大时，还原差异备份会显著延长还原数据库所需的时间。 因此，建议按设定的间隔执行新的完整备份，以便为数据建立新的差异基准。 例如，您可以每周执行一次整个数据库的完整备份（即完整数据库备份），然后在该周内执行一系列常规的差异数据库备份。 4.3.使用 SQL Server Management Studio创建差异数据库备份 操作步骤跟3.4节完整备份数据库一样，只是将buckup type类型改成Differential而已。destination可以依然选择完整备份的那一个device，不过要求是NOINIT，而不能是INIT，因为如果是INIT的话会覆盖原来的完整备份。 4.4.使用 Transact-SQL创建差异数据库备份 USE [TSQL2012] --定义备份设备 EXEC sp_addumpdevice 'disk', 'backupdevice1', 'd:\backup\backup_tsql2012.bak'; --完整备份数据库 BACKUP DATABASE TSQL2012 TO backupdevice1 WITH NOINIT,NAME = 'Full Backup of TSQL2012'; --插入数据 INSERT INTO dbo.test(OrderID,ProductID) VALUES(1,1); INSERT INTO dbo.test(OrderID,ProductID) VALUES(2,2); INSERT INTO dbo.test(OrderID,ProductID) VALUES(3,3); --差异备份数据库 BACKUP DATABASE TSQL2012 TO backupdevice1 WITH DIFFERENTIAL,NOINIT,NAME = 'DIFFERENTIAL Backup of TSQL2012'; 验证我们创建的完整备份和差异备份 右键选择数据库TSQL2012->tasks->restore->database，出现如下图所示内容： 如上图所示，出现了我们之前创建的完整备份和差异备份。 5.事务日志备份 5.1.建议 如果数据库使用完整恢复模式或大容量日志恢复模式，则必须足够频繁地备份事务日志，以保护数据和避免事务日志变满。 这将截断日志，并且支持将数据库还原到特定时间点。 默认情况下，每个成功的备份操作都会在 SQL Server 错误日志和系统事件日志中添加一个条目。 如果非常频繁地备份日志，这些成功消息会迅速累积，从而产生一个巨大的错误日志，这样会使查找其他消息变得非常困难。 在这些情况下，如果任何脚本均不依赖于这些日志条目，则可以使用跟踪标志 3226 取消这些条目。 有关详细信息，请参阅跟踪标志 (Transact-SQL)。 5.2.使用 SQL Server Management Studio创建差异数据库备份 5.2.1.例行事务日志的备份 操作步骤跟3.4节完整备份数据库一样，只是将buckup type类型改成Transaction Log而已。然后选择Option选项，我们重点看一下Transaction Log选项。对于例行的日志备份，请保留默认选项“通过删除不活动的条目截断事务日志(Truncate the transaction log)”。如下图所示： 5.2.2.尾部事务日志的备份 若要备份日志尾部（即活动的日志），请选中“备份日志尾部，并使数据库处于还原状态(Back up the tail of the log, and leave database in the restoring state)”。 5.3.使用 Transact-SQL创建差异数据库备份 --插入数据 INSERT INTO dbo.test(OrderID,ProductID) VALUES(4,4); INSERT INTO dbo.test(OrderID,ProductID) VALUES(5,5); --事务日志备份，NOINIT是默认的，表示不重写，而是追加 BACKUP LOG TSQL2012 TO backupdevice1 WITH NAME = 'Transaction Log Backup of TSQL2012'; --插入数据 INSERT INTO dbo.test(OrderID,ProductID) VALUES(6,6); INSERT INTO dbo.test(OrderID,ProductID) VALUES(7,7); --结尾日志备份，如果报错说数据库正在使用，请重启服务。 use master go BACKUP LOG TSQL2012 TO backupdevice1 WITH NORECOVERY,NAME = 'Transaction Tail-Log Backup of TSQL2012'; go 注意：事务日志备份与结尾日志备份就只差了一个关键字NORECOVERY，数据库备份可以有多个事务日志，但是只有一个结尾日志。一般结尾日志多用在数据库恢复的时候。在数据库恢复中，恢复事务日志并不能说明数据库已经恢复完成，但是一旦恢复了结尾日志，这表明数据库恢复工作完成。 验证我们创建的事务日志与结尾日志 右键选择数据库TSQL2012->tasks->restore->database，出现如下图所示内容： 由上图可见，备份中多出我们上述定义的事务日志：Transaction Log Backup of TSQL2012和结尾日志：Transaction Tail-Log Backup of TSQL2012。      本文转自xwdreamer博客园博客，原文链接：http://www.cnblogs.com/xwdreamer/archive/2012/06/27/2565380.html，如需转载请自行联系原作者    

　　首先，去SharePoint 2010的数据库服务器上，找到站点的数据库，备份、还原到SharePoint 2013环境中； 　　如果不知道数据库服务器是哪台，可以通过服务器场上的服务器查看； 　　如果不知道是哪个数据库的话，可以到管理内容数据库查看； 　　备份SharePoint 2010站点的内容数据库，还原到SharePoint 2013站点上（数据库备份还原，此步略）； 　　然后新建一个web应用程序，删掉默认的内容数据库，附加这个还原过来的内容数据库（比较简单，此步略）； 　　但是附加的时候，发现报错，如下图，意思是需要使用PowerShell命令来附加； 　　使用提示的命令行附加（如有不明白，msdn可以查到PowerShell的使用方法），有个百分比的进度条，等到完成，如下图： 　　看到附加结束以后，有一个报错，我没有理这个错误，如下图： 　　打开管理中心，管理内容数据库，发现虽然报错，也已经关联上了，如下图： 　　修改网站集管理员，我们尝试访问一下新的站点，如下图： 　　访问迁移过来的站点，发现报错，很明显是解决方案的问题了，这就好办了，如下图： 　　如果想临时查看这个站点，可以去母版页或者页面布局中，找到这个解决方案的引用，然后delete掉，就可以预览了。 　　或者在SharePoint 2013环境中，用vs2013打开2010版本的解决方案，vs会提示是否升级到2013版本，点击升级然后部署也可以。 　　通过vs升级以后的解决方案就可以部署了，但是注意程序里写死的layouts要在后面加上15等问题，或者controltemplate也要在后面加上15等问题。 　　预览页面，发现提示想体验SharePoint 2013的所有功能，点击Start Now，如下图： 　　点击Start Now，进入准备阶段，如下图： 　　点击Upgrade this site collection，进入检查阶段，如下图： 　　升级等待中，这时候可以取消，再到下一步就不可以取消了，如下图： 　　网站升级进行中，这一步没办法取消了，等就可以了，如下图： 　　升级完成，没有错误，有一些警告，如下图： 　　这时打开站点，发现部分样式有问题了，应该是SharePoint 2010的母版页，和SharePoint 2013的内容部件冲突了； 　　这时候我选择重建母版页，就是新建一个2013版本的母版页，按照2010的模样创建一下，然后引用即可。 　　其实这时候，站点升级已经完成，所有数据都已经升级到13版本，查阅项什么的都很正常，如果你也部署了升级上来的源代码，可能仅仅需要修改一下母版页即可。 　　无论是SharePoint自带页面，还是新建Pages页面，或者母版页，或者其他，都是sp2013版本的，甚至只能用Designer 2013打开了。 　　可以看到如下图，所有sp2010的内容，都带进来2013了，如下图： 总 结 　　升级的过程，基本就是把sp2010的数据库备份还原到sp2013环境中，新建web应用程序删掉默认的数据库，用PowerShell命令附加还原过来的数据库，而后在sp2013环境中的vs打开sp2010版本解决方案自动升级，修改升级后解决方案写死的路径并部署，修改母版页即可。 　　整过过程就是上面描述的，而后就是配置搜索了，因为这个两个版本的SharePoint还有有些区别的，不过也很简单，就不多说了。

整理自《Oracle database 11g RMAN 备份与恢复》 001 概述     顾名思义，不完全恢复就是指不完全的数据库恢复。不完全恢复与完全恢复在许多方面是相同的，它们基本的命令集相同，但不完全恢复添加了一些其它命令。引起不完全恢复的原因有很多，如丢失了联机重做日志或归档的重做日志，或者出现重大的用户错误。不完全恢复会影响整个数据库；换句话说，不能只对数据库的一部分执行不完全恢复操作，因为这会使数据库的一部分具有与这个数据库其余部分不同的系统更改号（SCN）或时间点。     不完全恢复影响的是整个数据库，这一点是非常重要的概念。一个典型的例子是：用户错误地删除了表空间中的一个表，并且没有备份这个表。要求将这个表空间恢复发哦该用户执行删除操作之前的时间点。     初级DBA起初可能会认为只需要还原损坏表空间的数据文件并将这些数据文件恢复到执行删除操作之前的时间点。这些操作看上去非常符合逻辑，实际上，这正是逻辑备份的操作。因此，初级DBA还原了数据文件，并将表空间恢复到删除操作之前的时间点，但当其尝试打开数据库时，RMAN会给出下面的信息： ERROR at line 1: ORA-01113:file 3 needs media revoery ORA-01110:data file 3:'/u01/app/oracle/oradata/ORCL/INDEX01.DBF'     在这个示例中，Oracle告诉用户恢复数据文件是成功的，但是这些数据文件恢复得不够，与数据库的其他部分不一致！因此，不完全恢复并非所有灾难的解决方案，它只是某些灾难的解决方案。如果需要某种形式的不一致恢复（将一些数据库数据还原至与数据库剩余部分不同的时间点），则有表空间时间点恢复，或者闪回技术。     然而，如果需要将整个数据库还原到闪回数据库无法到达的过去的某个时间点，则需要使用不完全恢复。当执行数据库不完全恢复时，需要使用Resetlogs命令，因为差不多所有的不完全恢复情况都要用到Resetlogs命令。     我们将在下面介绍该命令，随后还要讨论实际的不完全恢复方法，这些方法包括基于时间、SCN、日志序列或取消的恢复。 002 使用Resetlogs命令     在不完全恢复期间，通常需要使用Resetlogs命令打开数据库，这是因为我们要从已经建立的现有重做流中脱离出来，并且需要向Oracle说明这种情况。Resetlogs命令表示一个数据库逻辑生存周期的结束和另一个数据库逻辑生存周期的开始。数据库的逻辑生存期也称为一个对应物（incarnation）。每次使用Resetlogs命令都会创建一个新的数据库对应物，这对于恢复操作来说非常重要，我们将在后面讨论这个问题。     每次使用Resetlogs命令时，SCN计数器不会被重置，不过Oracle会重置其它计数器（如日志序列号），同时还会重置联机重做日志的内容（如果有必要还可以重新创建联机重做日志）。     从Oracle database 10g开始，简化了通过Resetlogs命令进行的恢复。在归档的重做日志名中添加了一个新的替换字符串（%r），该字符串表示Resetlogs ID号。在log_archive_dest_format参数字符串中包括%r时，归档的重做日志名在每个Resetlogs命令中保持唯一。这种改动以及其他的内部Oracle数据库改动使Oracle可以很容易地通过给定的Resetlogs操作恢复数据库。因此，可以很容易地在执行Resetlogs操作后立刻备份数据库。然而，我们仍然认为在任何不完全恢复后备份数据库是很好的想法。     注意：在以前版本的RMAN中，需要重新创建所有的临时表空间临时文件。Oracle database 10g和以后的版本中则不需要这种操作，RMAN在恢复数据库过程期间会创建这些数据文件，甚至在不完全恢复期间也是如此！ 003 创建恢复点     使用RMAN执行不完全恢复操作时需要完成的一个工作是创建恢复目标。恢复目标是恢复进程的终点，通常我们基于一个时间点、一个指定的SCN或一个日志序列号来标识它。我们可以使用许多不同的方法创建恢复目标。首先，可以在run代码块中使用set命令与until time、until SCN或until sequence参数，下面的示例使用set until time命令创建了一个为2016年1月19日下午3点的恢复目标：     run     {     set until time "to_date('01/19/16 15:00:00','mm/dd/yy hh24:mi:ss')";     restore database;     recover database;     alter database open resetlogs;     }     执行这条命令时，RMAN会查找与恢复目标时间最近（并非恢复目标时间本身，也不能是恢复目标之后的时间）的备份集，并且从这个备份集中还原数据库。如果数据库置于noarchivelog模式中，恢复操作会在备份集的时间点停止；否则在执行recover命令期间，Oracle会在所定义的恢复目标（不包含恢复目标本身）上应用归档的重做日志（以及需要应用的任何增量备份）。     注意：如果尝试恢复到特定备份的完成点，则必须恢复到备份集中文件的ckp SCN或ckp time，在不同备份集的RMAN的list命令中列出了这些内容（例如 list backup）。有时候使用备份的ckp time并不够，还可能导致ORA-1152错误。     也可以选择在restore和recover命令中直接使用until time、until SCN或until sequence命令，这样就避免使用run代码块（我们倾向于使用这种方法）。下面是在还原和恢复数据库时所使用的until time命令示例：     --we assume that your control file is intact     startup mount；     restore database until time     “to_date('01/19/16 13:00:00','MM/DD/YY HH24:MI:SS')";     recover database until time     "to_date('01/19/16 13:00:00','MM/DD/YY HH24:MI:SS')";     alter database open resetlogs; 004 基于时间的恢复     003中给出了一些基于时间的恢复示例。这种恢复类型允许用户将数据库恢复到与指定时间一致的状态。当然，如果不存在能将数据库还原到用户请求的时间的有效备份或归档重做日志，Oracle就会生成如下所示的错误：     最后需要强调的是必须具备在我们所指定的恢复时间之前生成的数据库备份，此外还需要所有的归档重做日志。利用list和report命令，我们可以确定RMAN还原数据库可以使用的备份。 005 基于SCN的恢复     Oracle允许用户将数据库恢复到指定的SCN。实际上，这并不是一种常用的恢复方法，不过最好了解一下它的用法。下面是一个将数据库还原到指定SCN的示例：     假定控制文件完整：     startup mount;     restore database until SCN 10000;     recover database until SCN 10000;     alter database open resetlogs;     在这个示例中，我们将数据库还原到SCN 10000（但是不包含这个SCN）。 006 基于日志序列的恢复     RMAN允许用户将数据库恢复到指定序列号的归档重做日志。如果归档的重做日志中存在间隙，使用这种恢复方法就非常方便。间隙通常意味着我们只能将数据库还原到间隙的开始点。下面是一个在RMAN中执行基于日志序列的恢复操作的示例：     假定控制文件是完整的：     startup mount;     restore database until sequence 100 thread 1;     recover database until sequence 100 thread 1;     alter database open resetlogs;     在这个示例中，我们将数据库还原到日志序列为100（但是不包含这个日志序列）的数据库。 007 基于删除的恢复     RMAN不支持类似于sqlplus所做的基于删除的恢复（虽然基于删除的恢复在一定程度上非常类似于基于日志序列的恢复），而是希望用户了解恢复到的时间、SCN或日志序列号，因为这样非常有意义。如果需要执行基于删除的恢复，则需要从RMAN中将数据文件还原到恢复时间之前的一些时间点。我们需要手动析取基于删除的恢复所需的归档重做日志，然后需要从sqlplus客户端中执行数据库的基于删除的恢复。 008 使用还原点恢复     可以利用还原点定义数据库还原到的时间点。基于还原点还原数据库，只包含restore和recover命令的to restore point子句，如下所示：     startup mount;     restore database until restore point tango_one;     recover database until restore point tango_one;     alter database open resetlogs;     也可以使用run代码块和set until restore point命令创建还原点，如下所示：     startup mount;     run {     set restore point tango_one;     restore databsae tango_one;     recover database tango_one;     }     alter database open resetlogs;

原文: SQL Server高可用——日志传送（4-3）——使用   顺接上一篇：SQL Server高可用——日志传送（4-2）——部署 本文为本系列最重要的一篇，讲述如何使用日志传送及一些注意事项。从上一篇可以看到，其实配置不难，难是难在一旦出现问题，如何处理。这些是4大高可用的同性。配置都不会很难，只是如何故障排除而已。     监控日志传送：       在配置好日志传送之后，需要进行监控，监控备份、复制及还原的作业运作情况。这三类作业任何一个没有成功都意味着日志传送失败。 有两种方法可以监控辅助服务器是否与主服务器同步以及两者的时间差： 1、 使用“事务日志传送状态”       2、 执行master.dbo.sp_help_log_shipping_monitor   还可以使用sys.sp_check_log_shipping_monitor_alert来检查是否超过预先设置的阈值。如果超过了，存储过程会发出一个警报。 在监控服务器上执行存储过程：sp_help_log_shipping_monitor，可以看到主服务器和辅助服务器的信息，该结果和使用方法1中的结果基本一致。       故障排查： 日志传送由三部分组成：备份事务日志、复制文件和还原事务日志。所以当出现故障的时候，检查这三部分。       可以查看SQL代理的日志传送作业历史和windows事件查看器来确认真正的错误信息。       如复制文件失败，可能是网络不正常，如果还原失败，可能服务器不可用或者数据库处于standby模式时用户正在使用数据库。另外，如果数据库恢复模式改为“简单”，会中断日志传送，因为会截断日志。而不是备份日志。这时需要重新配置事务日志。       要注意一点，在日志传送之外不应该存在任何其他的事务日志备份操作。因为这样会引起主服务器和辅助服务器的日志链不匹配，从而导致日志传送的中断。   数据库备份计划： 在日志传送中，，对于备份，要考虑以下几点： l 数据库备份进程和事务日志备份进程不能并发运行。所以一个大型、活跃的数据库，备份可能要花费一段时间，引起日志快速的增长，从而导致辅助服务器和主服务器不同步。因为数据库备份完成之前无法及时地收到事务日志。 l 除日志传送之外不能有其他事务日志备份，因为会断开日志链。 l 截断事务日志将断开日志链，从而导致日志传送无法正常工作。 l 如果把数据库恢复模式转换成“简单”，那么SQLServer会截断事务日志。从而导致日志传送无法正常工作。   删除日志传送： 在删除日志传送数据库之前，先要删除数据库中的日志传送。当删除日志传送后，所有的时间表、作业、历史以及错误信息都会被删除。   使用ssms删除： 只需要把主服务器中下面红框处取消勾选即可。     也可以用下面那里点击【删除】           使用T-SQL删除： 在主服务器上：   Use master; Sp_delete_log_shipping_primary_secondary @primary_database,@secondary_server,@secondary_database     这个命令是删除主服务器上的msdb.dbo.log_shipping_primary_secondaries表中辅助服务器的信息。   在辅助服务器上：   Use master; Sp_delete_log_shipping_secondary_database @secondary_database;     删除辅助服务器上有关服务服务器的信息和作业。   然后再回到主服务器：   Use master; Sp_delete_log_shipping_primary_database @database     该存储过程删除对应的信息和作业。   日志传送性能： 1、 日志传送备份目录存放到与数据库不同的磁盘驱动器上。并使用备份压缩（2008出现） 2、  需要监控I/O性能计数器以找到所有的瓶颈（如每个物理驱动器的队列平均程度大于2） 3、 在空间时段进行数据库管理活动（如索引碎片整理），因为碎片越多，日志文件越大，备份和还原的时间就越长。 4、为了确保角色切换中数据库能快速恢复，辅助服务器应该与主服务器完全一样的容量。 5、需要把文件复制目录与数据库分离。 6、确保网络不会成为瓶颈。

13.4 故障转移 13.4.1 故障定位 在前几节明确的提及到，日志传送由三个基本的作业组成：备份作业、复制作业和还原作业。通过上一节日志传送监控功能来定位哪一个作业出了问题： 如果备份作业出了问题，检查主服务器状态。 如果还原作业出了问题，检查辅助服务器状态；或者辅助数据库处于STANDBY模式时用户正在使用辅助数据库。 如果复制作业出了问题，检查除了辅助服务器状态外，还需要检查网络状态。 13.4.2 故障转移 日志传送的故障转移除了考虑切换技术操作以外，更需要考虑主服务器和辅助服务器之间的各类依赖的对象和基础环境是否一致。 1. 同步依赖对象 基于业务连续性需求，数据库系统的高可用性解决方案必须允许在当前的主数据库和辅助数据库之间能够切换。日志传送技术也是数据库高可用性解决方案之一，但是日志传送是数据库级别的，它不会传送在被传送的数据库之外的对象。例如，存储在master数据库中的SQL Server登陆名和存储在MSDB中的SQL作业，以及其他所依赖的对象。 提示： 建议通SSIS包来传送依赖对象，配合SQL作业定期执行以保证主服务器和辅助服务器的依赖对象能够同步，以避免在故障转移期间辅助服务器因缺少这些依赖对象也变得不可用。 2. 故障转移 当主服务器出现故障变为不可用，切换辅助服务器担当主服务器角色。在主服务器故障发生后，SQL代理上的复制作业和还原作业可能还未将最近的事务日志备份复制并还原到辅助服务器上。尽可能的同步辅助服务器，保证业务数据在故障期间丢失最少。手动转移步骤如下： （1）利用“标准报表”“事务日志传送”查看主服务器故障发生后还未复制和还原的日志备份； （2）手动复制事务日志备份到辅助服务器，并和在NORECOVERY模式下将事务日志备份还原到辅助数据库； 这个时候辅助服务器已经可以担当主服务器对外可用。 提示： （1） 使用norecovery模式还原辅助数据库，使其可用；更重要的是日志传送的故障转移只能手动执行。 （2） 待原主服务器故障修复后，可以使用以原辅助服务器作为主服务器，原主服务器作为辅助服务器重建日志传送；操作步骤按照13.2.3章节。 3. 客户端重定向连接到辅助服务器 故障转移以后需要把客户端重新定向到辅助服务器，并且尽可能的减少终断用户的操作，一般来说有以下方式： 应用程序代码 在应用程序中开发自动感知故障的功能，逻辑上首先连接主服务器，如果主服务器不可用，通过应用程序自动或者手动连接辅助服务器。 网络负载均衡（NLB）通过网络负载均衡或者类似的硬件解决方案，一旦故障发生需要手动或者使用脚本将在NORECOVERY模式下还原后辅助服务器添加到网络负载均衡器上，网络负载均衡会自动将应用程序重定向到辅助服务器。 域名服务(DNS) DNS提供名称到IP地址的映射。一旦主服务器发生故障，只需要更改名称对应的IP地址为辅助服务器的IP地址，便可将客户端的数据库请求重定向到辅助服务器。 SQL客户端别名 主数据库故障修改SQL Native Client中SQL 客户端别名可将客户端的数据库请求重新定向到辅助服务器；假如有大量的客户端需要修改则这个方式不一定实用。如果客户端是通过Web或者应用程序服务器来连接数据库服务器，只需要修改Web或者应用程序服务器上的SQL客户端别名，所有的客户端就重定向到辅助服务器 。 13.5 删除日志传送 13.5.1 通过Management Studio删除日志传送 通过Management Studio删除日志传送步骤如下： 1.打开主服务器SQLSVR1中作为日志传送的主数据库DB01的属性页面，，然后选择“事务日志传送”；取消“将此数据库启用为日志传送配置中的主数据库（E）”复选框。 2.在弹出的数据库属性界面，单击“是”； 3.单击“确定”； 4.等待删除日志传送配置完成，单击“关闭”；完成删除日志传送。   13.5.2 通过T-SQL删除日志传送 1.在主服务器上运行以下命令删除主服务器sqlsvr1上msdb.dbo.log_shipping_primary_secondaries表中有关辅助服务器sqlsvr2的信息： 1 2 3 Use master; go sp_delete_log_shipping_primary_secondary db01,sqlsvr2,db01; 2.在辅助服务器sqlsvr2上运行以下命令删除辅助服务器sqlsvr2上有关辅助服务器sqlsvr2的信息和复制和还原作业： 1 2 3 Use master; go sp_delete_log_shipping_secondary_database db01; 3. 在日志传送主服务器上，执行以下命令以删除有关主服务器的日志传送配置的信息。 此操作还将删除备份作业。 1 2 3 Use master; go sp_delete_log_shipping_primary_database DB01; 4.在日志的监视服务器上，执行以下命令删除监视日志传送的警报作业。 1 2 3 USE master; GO sp_delete_log_shipping_alert_job;   小结 日志传送是简单的，廉价和可靠的SQL Server高可用性解决方案，可保留较长时间的跟踪记录。作为灾难恢复解决方案，可以部署在远程，通过维护一台辅助服务器来缓解局部灾难、电网故障和网络故障造成的影响，以便提供业务连续性。日志传送可以把事务日志传送到世界上的任何地方，唯一的限制是及时传输事务日志所需要的网络带宽。 本文转自 bannerpei 51CTO博客，原文链接：http://blog.51cto.com/281816327/1598318，如需转载请自行联系原作者

  RMAN备用数据库 1、介绍几个新RMAN命令 INCLUDE CURRENT CONTROLFILE FOR STANDBY：在备份命令中包含一个备用控制文件，RMAN为了创建备用数据库必须在其备份中有一个备用控制文件。 DUPLICATE TARGET DATABASE FOR STANDBY：创建一个副本数据库作为目标的备用数据库。 DORECOVER：从目标数据库用归档日志备份恢复备用数据库。一旦备用数据库的创建完成，RMAN将对备用数据库应用主数据库中的所有归档日志，一直到RMAN中注册的最新的归档日志。 2、在RMAN为备用操作复制数据库期间，RMAN将自动执行任务的所有要求。当连接到目标辅助和可选的目录数据库时，RMAN将进行以下任务：  1)决定需要还原哪个基本备份。  2)根据辅助数据库参数或者RMAN设置命令和选项，确定将数据文件放置在辅助实例的什么位置。  3)为辅助数据库还原备用控制文件。  4)加载备用数据库控制文件。  5)从第1)步决定的备份片或者映像拷贝来还原数据文件。  6)如果指定了DORECOVER选项，将根据恢复停止点对还原的数据文件应用 所有的增量备份   7)如果指定了DORECOVER选项，将根据恢复点停止点从磁盘或备份对还原的数据文件应用所有归档日志文件。 3、当RMAN创建备用数据库时，就注意以下事项：  1)如果在备用数据库还原期间不希望使用目录，则应在RMAN命令行中指定NOCATALOG.  2)在备份备用控制文件时的重做日志必须被归档。  3)必须有包含备用控制文件的备份，否则，当试图创建备用数据库时会得到一个“RMAN-06024:no backup or copy of the controlfile found to restore”错误。  4)不能在备用创建期间执行完全恢复。如果当前的联机重做日志对数据库不可用，则常常会发生这种情况。应用DORECOVER选项后，RMAN将应用已知的归档日志文件。  5）如果备用数据库驻留在其它的服务器上并拥有与主服务器相同的目录结构，则在备用创建期间不必重命名任何一个文件。默认情况下，DUPLICATE命令将不能继续执行，而RMAN将会通知还原的辅助文件的位置与被备份的目标数据库文件的原始位置是一致的。这样做可以防止DBA偶然覆盖已存在的数据文件。NOFILENAMECHECK选项将会忽略这个检查。  6)备用数据库的数据库名称必须和主数据库的名称相同。如果主数据库和备用数据库在同一机器上，则对备用数据库使用LOCK_NAME_SPACE初始化参数。这将允许两个具有相同名称的数据库驻留在同一机器上，而不相互干扰。  7)RMAN将只创建备用数据库并在创建点上初步恢复该数据库。不能进行备用数据库的后续的维护和恢复(传送、应用归档重做日志文件) 4、创建步骤：            1)目录：创建所有的管理目录($ORACLE_BASE/admin/STBY)和数据目录(/oradata/STBY)。            2)参数文件：拷贝目标数据库的参数文件并命名为initSTBY.ora，这样就创建了一个参数文件。将所有目标数据库名(MYDB)修改为”STBY”,除了数据库名(DB_NAME)必须保留，使备用数据库与原始数据库的名称相同，为了在备用数据库创建期间转换文件名，增加两个转换参数。同时，增加LOCK_NAME_SPACE参数以便可以在同一台机器上同时打开两个同名的数据库： DB_FILE_NAME_CONVERT = (“MYDB”,”STBY”) LOG_FILE_NAME_CONVERT = (“MYDB”,”STBY”) LOCK_NAME_SPACE = “STBY” STANDBY_ARCHIVE_DEST = /oradata/stby/arvhice            3)口令文件：为备用数据库创建一个口令文件，以便RMAN可以用SYSDBA身分连接到SYSDBA。            4)Windows服务：在windows环境中，使用oradim工具为STBY数据库创建一个新的名为OracleServiceSTBY的数据库服务。            5)配置Net8            6)备份目标数据库(MYDB)：创建备用数据库需要一个备用控制文件的备份。备用控制文件备份以后还需要一个日志切换，在命令行中增加一个日志文件参数，以便该脚本输出可以输入到一个文件中： LINUX>rman trace = b_standby.log RMAN> connect target sys/oracle 已联机到目标数据库: MYDB (DBID=2567199153) RMAN> connect catalog rman/rman@standby 已联机至复原目录数据库 RMAN>@b_standby.rcv b_standby.rcv内容如下： run{ ALLOCATE channel d1 TYPE DISK; BACKUP incremental LEVEL 0 DATABASE    format 'd:\oraclebak\db%d_%s_%p_%t'    tag = 'stby_inc0'    include CURRENT CONTROLFILE FOR STANDBY;  SQL 'alter system archive log current '; BACKUP ARCHIVELOG FROM TIME 'sysdate - 1/24'    format 'd:\oraclebak\arc%d_%s_%p_%t';} 脚本说明：  Control file for standby:当备份整个数据库时，控制文件将自动包含在系统表空间中。为了备用数据库的生成必须创建一个特殊的控制文件。RMAN可以在一个数据文件备份片中存储这个特殊文件。如果需要，这个备份文件也可以用于还原目标数据库的控制文件。  Archive log current:当备用数据控制文件创建时，备用数据库的恢复从这个当前日志开始。 屏幕输出如下： RMAN> run{ 2>   ALLOCATE channel d1 TYPE DISK; 3>   BACKUP incremental LEVEL 0 DATABASE 4>     format 'd:\oraclebak\db%d_%s_%p_%t' 5>     tag = 'stby_inc0' 6>     include CURRENT CONTROLFILE FOR STANDBY; 7>   SQL 'alter system archive log current '; 8>   BACKUP ARCHIVELOG FROM TIME 'sysdate - 1/24' 9>     format 'd:\oraclebak\arc%d_%s_%p_%t';} 已配置信道: d1 通道d1: sid=16 devtype=DISK 开始backup, 于2008/05/07 22:49:02 通道d1: 正在启动incremental level 0 数据文件备份集 通道d1: 正在设定备份集中的数据文件 在备份集中包括目前的SPFILE 在备份集中包括待命控制档 输入数据文件fno=00001 name=C:\ORACLE\ORADATA\MYDB\SYSTEM01.DBF 输入数据文件fno=00002 name=C:\ORACLE\ORADATA\MYDB\UNDOTBS01.DBF 输入数据文件fno=00005 name=C:\ORACLE\ORADATA\MYDB\EXAMPLE01.DBF 输入数据文件fno=00010 name=C:\ORACLE\ORADATA\MYDB\XDB01.DBF 输入数据文件fno=00006 name=C:\ORACLE\ORADATA\MYDB\INDX1.DBF 输入数据文件fno=00009 name=C:\ORACLE\ORADATA\MYDB\USERS01.DBF 输入数据文件fno=00003 name=C:\ORACLE\ORADATA\MYDB\CWMLITE01.DBF 输入数据文件fno=00004 name=C:\ORACLE\ORADATA\MYDB\DRSYS01.DBF 输入数据文件fno=00007 name=C:\ORACLE\ORADATA\MYDB\ODM01.DBF 输入数据文件fno=00011 name=C:\ORACLE\ORADATA\MYDB\MYTS01.DBF 输入数据文件fno=00008 name=C:\ORACLE\ORADATA\MYDB\TOOLS01.DBF 通道d1: 启动部份1, 在2008/05/07 22:49:09 通道d1: 已完成部份1, 在2008/05/07 22:59:39 处理片=D:\ORACLEBAK\DBMYDB_12_1_654130144 批注=NONE 通道d1: 备份集完成, 经历时间: 00:10:35 完成backup, 于2008/05/07 22:59:39 sql 叙述句: alter system archive log current 开始backup, 于2008/05/07 23:00:13 已存盘目前的日志 通道d1: 启动存盘日志备份集 通道d1: 指定备份集中的存盘日志 输入存盘日志系线=1 顺序=4 recid=22 戳记=654130812 输入存盘日志系线=1 顺序=5 recid=23 戳记=654130813 通道d1: 启动部份1, 在2008/05/07 23:00:15 通道d1: 已完成部份1, 在2008/05/07 23:00:54 处理片=D:\ORACLEBAK\ARCMYDB_13_1_654130814 批注=NONE 通道d1: 备份集完成, 经历时间: 00:00:40 完成backup, 于2008/05/07 23:00:54 已释放通道: d1 RMAN> 请记录目标数据库当前的日志序号，自动恢复将从这个日志序号开始： SQL>SELECT SEQUENCE# FROM V$LOG WHERE STATUS = ‘CURRENT’; 如何知道一个备份集中是否包含一个备用控制文件？可以在目录中查询名RC_BACKUP_CONTROLFILE的视图中的该注册数据库，控制文件类型“S”(Standby)。正常的控制文件备份将是一个控制文件类型“B”(Backup) SQL> SELECT SET_COUNT,       CHECKPOINT_CHANGE#,       CHECKPOINT_TIME,       STATUS,       COMPLETION_TIME,       CONTROLFILE_TYPE FROM RMAN.RC_BACKUP_CONTROLFILE  WHERE DB_NAME = 'MYDB'   AND CONTROLFILE_TYPE = 'S'; 同时下面的查询语句可以在备份集和备份片中查找包含的备用控制文件。 SQL> SELECT BS.BS_KEY,       BS.SET_COUNT,       BS.BACKUP_TYPE,       BS.INCREMENTAL_LEVEL,       BS.COMPLETION_TIME,       BS.ELAPSED_SECONDS,       BP.HANDLE,       BP.STATUS FROM RMAN.RC_BACKUP_SET BS, RMAN.RC_BACKUP_PIECE BP WHERE BS.CONTROLFILE_INCLUDED = 'STANDBY'   AND BS.DB_ID = BP.DB_ID   AND BS.BS_KEY = BP.BS_KEY   AND BS.DB_ID IN (SELECT DBID FROM RMAN.RC_DATABASE WHERE NAME = 'MYDB');  7)创建备用数据库：简单地启动RMAN并连接到目标、目录和辅助数据库上。设置NLS语言环境变量，如果目标数据库与默认的环境的语言属性相同，则该变量没有必要设置，如果NLS_LANG环境变量与目标数据库的不同则有可能使备用数据库创建失败。 RMAN执行的备用数据库创建工作只需要几个命令。用前述任务中创建的备份生成备用数据库： LINUX>rman trace=/opt/oracle/standby.log RMAN>connect target sys/oracle@mydb RMAN>connect catalog rman/rman@standby RMAN>connect auxiliary sys/stby RMAN> run{ SET command ID TO 'Standby Creation'; ALLOCATE auxiliary channel d1 TYPE DISK; duplicate target DATABASE FOR STANDBY dorecover;} 这向行命令用数据库的备份创建了MYDB数据库的副本，尽管这个脚本中的命令很少，但实际上RMAN完成了大量的工作： Set command id :这个设置选项使RMAN填充了v$session视图的client_inof列。因此，在STBY数据库被创建时，可以将client_info的值设置为“Standby Creation”来查询v$session表，并观察会话的进行。 Duplicate target database for standby :这个命令创建备用数据库需要完成大量的工作，首先，备用数据库的控制文件需要被复制到辅助数据库init.ora文件中的control_files参数值指定的位置，然后，目标数据库备份中数据文件将被还原到辅助数据库的还原位置上。 Dorecover :当目标数据库复制之后，备份数据库将用增量RMAN备份和归档重做日志恢复。一直恢复到停止点的位置。 屏幕输出如下： C:>rman trace=c:\oracle\standby.log Recovery Manager: 版本9.2.0.1.0 - Production Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved. Windows 2000 Version 5.1 Service Pack 2, CPU type 586 Starting with debugging turned off RMAN> connect target sys/oracle@mydb 已联机到目标数据库: MYDB (DBID=2567199153) RMAN> connect catalog rman/rman@standby 已联机至复原目录数据库 RMAN> connect auxiliary sys/stby@stby 联机至辅助数据库: mydb (未挂载) RMAN> 2> 3> 4> 执行命令: SET COMMAND ID 已配置信道: d1 通道d1: sid=13 devtype=DISK 开始Duplicate Db, 于 08-5月-08 打印储存的命令档: Memory Script {    restore clone standby controlfile to clone_cf;    replicate clone controlfile from clone_cf;    sql clone 'alter database mount standby database'; } 执行命令档: Memory Script 开始restore, 于 08-5月-08 通道d1: 启动数据文件备份集的回复 通道d1: 回复控制档案 输出文件名称=C:\ORACLE\ORADATA\STBY\CONTROL01.CTL 通道d1: 回复备份片1 处理片=D:\ORACLEBAK\DBMYDB_12_1_654130144 标志=STBY_INC0 参数=NULL 通道d1: 回复完成 完成restore, 于 08-5月-08 复制控制档案 输入文件名称=C:\ORACLE\ORADATA\STBY\CONTROL01.CTL 输出文件名称=C:\ORACLE\ORADATA\STBY\CONTROL02.CTL 输出文件名称=C:\ORACLE\ORADATA\STBY\CONTROL03.CTL sql 叙述句: alter database mount standby database 打印储存的命令档: Memory Script {    set until scn 1170983;    set newname for datafile 1 to  "C:\ORACLE\ORADATA\STBY\SYSTEM01.DBF";    set newname for datafile 2 to  "C:\ORACLE\ORADATA\STBY\UNDOTBS01.DBF";    set newname for datafile 3 to  "C:\ORACLE\ORADATA\STBY\CWMLITE01.DBF";    set newname for datafile 4 to  "C:\ORACLE\ORADATA\STBY\DRSYS01.DBF";    set newname for datafile 5 to  "C:\ORACLE\ORADATA\STBY\EXAMPLE01.DBF";    set newname for datafile 6 to  "C:\ORACLE\ORADATA\STBY\INDX1.DBF";    set newname for datafile 7 to  "C:\ORACLE\ORADATA\STBY\ODM01.DBF";    set newname for datafile 8 to  "C:\ORACLE\ORADATA\STBY\TOOLS01.DBF";    set newname for datafile 9 to  "C:\ORACLE\ORADATA\STBY\USERS01.DBF";    set newname for datafile 10 to  "C:\ORACLE\ORADATA\STBY\XDB01.DBF";    set newname for datafile 11 to  "C:\ORACLE\ORADATA\STBY\MYTS01.DBF";    restore    check readonly    clone database    ; } 执行命令档: Memory Script 执行命令: SET until clause 执行命令: SET NEWNAME 执行命令: SET NEWNAME 执行命令: SET NEWNAME 执行命令: SET NEWNAME 执行命令: SET NEWNAME 执行命令: SET NEWNAME 执行命令: SET NEWNAME 执行命令: SET NEWNAME 执行命令: SET NEWNAME 执行命令: SET NEWNAME 执行命令: SET NEWNAME 开始restore, 于 08-5月-08 通道d1: 启动数据文件备份集的回复 通道d1: 正在设定要从备份集回复的数据文件 正在将资料文件 00001 回复为C:\ORACLE\ORADATA\STBY\SYSTEM01.DBF 正在将资料文件 00002 回复为C:\ORACLE\ORADATA\STBY\UNDOTBS01.DBF 正在将资料文件 00003 回复为C:\ORACLE\ORADATA\STBY\CWMLITE01.DBF 正在将资料文件 00004 回复为C:\ORACLE\ORADATA\STBY\DRSYS01.DBF 正在将资料文件 00005 回复为C:\ORACLE\ORADATA\STBY\EXAMPLE01.DBF 正在将资料文件 00006 回复为C:\ORACLE\ORADATA\STBY\INDX1.DBF 正在将资料文件 00007 回复为C:\ORACLE\ORADATA\STBY\ODM01.DBF 正在将资料文件 00008 回复为C:\ORACLE\ORADATA\STBY\TOOLS01.DBF 正在将资料文件 00009 回复为C:\ORACLE\ORADATA\STBY\USERS01.DBF 正在将资料文件 00010 回复为C:\ORACLE\ORADATA\STBY\XDB01.DBF 正在将资料文件 00011 回复为C:\ORACLE\ORADATA\STBY\MYTS01.DBF 通道d1: 回复备份片1 处理片=D:\ORACLEBAK\DBMYDB_12_1_654130144 标志=STBY_INC0 参数=NULL 通道d1: 回复完成 完成restore, 于 08-5月-08 打印储存的命令档: Memory Script {    switch clone datafile all; } 执行命令档: Memory Script 数据文件2 已切换至数据文件复制本 输入数据文件复本recid=158 戳记=654135499 文件名称=C:\ORACLE\ORADATA\STBY\UNDOTBS01.DBF 数据文件3 已切换至数据文件复制本 输入数据文件复本recid=159 戳记=654135499 文件名称=C:\ORACLE\ORADATA\STBY\CWMLITE01.DBF 数据文件4 已切换至数据文件复制本 输入数据文件复本recid=160 戳记=654135499 文件名称=C:\ORACLE\ORADATA\STBY\DRSYS01.DBF 数据文件5 已切换至数据文件复制本 输入数据文件复本recid=161 戳记=654135499 文件名称=C:\ORACLE\ORADATA\STBY\EXAMPLE01.DBF 数据文件6 已切换至数据文件复制本 输入数据文件复本recid=162 戳记=654135499 文件名称=C:\ORACLE\ORADATA\STBY\INDX1.DBF 数据文件7 已切换至数据文件复制本 输入数据文件复本recid=163 戳记=654135499 文件名称=C:\ORACLE\ORADATA\STBY\ODM01.DBF 数据文件 8 已切换至数据文件复制本 输入数据文件复本recid=164 戳记=654135499 文件名称=C:\ORACLE\ORADATA\STBY\TOOLS01.DBF 数据文件9 已切换至数据文件复制本 输入数据文件复本recid=165 戳记=654135499 文件名称=C:\ORACLE\ORADATA\STBY\USERS01.DBF 数据文件10 已切换至数据文件复制本 输入数据文件复本recid=166 戳记=654135499 文件名称=C:\ORACLE\ORADATA\STBY\XDB01.DBF 数据文件11 已切换至数据文件复制本 输入数据文件复本recid=167 戳记=654135499 文件名称=C:\ORACLE\ORADATA\STBY\MYTS01.DBF 打印储存的命令档: Memory Script {    set until scn 1170983;    recover    standby    clone database     delete archivelog    ; } 执行命令档: Memory Script 执行命令: SET until clause 开始recover, 于 08-5月-08 启动媒体恢复 通道d1: 启动存盘日志回复到预设目的 通道d1: 回复存盘日志 存盘日志系线=1 顺序=4 通道d1: 回复存盘日志 存盘日志系线=1 顺序=5 通道d1: 回复备份片1 处理片=D:\ORACLEBAK\ARCMYDB_13_1_654130814 标志=TAG20080507T230014 参数=NULL 通道d1: 回复完成 存盘日志文件名称=C:\ORACLE\ORADATA\STBY\ARCHIVE1_4.DBF 系线=1 顺序=4 通道clone_default: 删除存盘日志 存盘日志文件名称=C:\ORACLE\ORADATA\STBY\ARCHIVE1_4.DBF recid=2 戳记=654135509 存盘日志文件名称=C:\ORACLE\ORADATA\STBY\ARCHIVE1_5.DBF 系线=1 顺序=5 通道clone_default: 删除存盘日志 存盘日志文件名称=C:\ORACLE\ORADATA\STBY\ARCHIVE1_5.DBF recid=1 戳记=654135507 媒体恢复完成 完成recover, 于 08-5月-08 完成Duplicate Db, 于 08-5月-08 已释放通道: d1 RMAN> 8)启动管理恢复 修改目标数据库的参数文件，然后重启实例，如下： SQL>ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = "MANDATORY SERVICE=STBY REOPEN=30"; SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE2 = ENABLE; 命令备用数据库开始管理恢复： SQL>RECOVER MANAGED STANDBY DATABASE; 当提交这个命令之后，可能会认为这个命令的执行被堵塞了，得不到任何反馈信息，SQL提示符也不出现，这是正常的。此时STBY数据库已经启动了RFS后台进程接收任何从MYDB数据库传送来的归档日志，存放在由standby_archive_dest参数指定的位置上，生成归档日志并应用它们的工作持续进行，直到管理恢复被取消。 SQL>RECOVER MANAGED STANDBY DATABASE CANCEL; 上面这个取消命令必须在STBY数据库上的另一个SQL*PLUS会话中提交。  9)以只读方式打开备用数据库 取消STBY数据库上的恢复，打开STBY数据库查验数据变化情况： SQL>ALTER DATABASE OPEN READ ONLY;  10)将备用数据库返回到恢复模式 为了使STBY数据库从只读打开模式返回到恢复模式，首先必须关闭数据库： SQL>SHUTDOWN IMMEDIATE;SQL>STARTUP NOMOUNT;SQL>ALTER DATABASE MOUNT STANDBY DATABASE; SQL>RECOVER MANAGED STANDBY DATABASE;  11)激活备用数据库 SQL>ALTER DATABASE ACTIVATE STANDBY DATABASE; SQL>SHUTDOWN IMMEDIATE; SQL>STARTUP; 一旦创建了备用数据库，就可以用RMAN来备份这个备用数据库了，备份备用数据库实际上就是对目标数据库的备份。这样就减少了主服务器的资源开销。不能用RMAN对备用控制文件进行备份，必须从目标数据库进行控制文件的备份。

本文转自网络，地址不详。 　 这篇文章是去年写的了，最初发表在chinaunix.net的oracle论坛里，收录在旧版文集中，可能很多没有看到，总有人写信要，今天乘改版之际就把它单独拿出来了。 RMAN(RecoveryManager)是DBA的一个重要工具，用于备份、还原和恢复oracle数据库，前一段时间有网友找我要，可惜没时间，趁这两天出差在外没什么事，就写了一下，供初学的朋友参考。本文将介绍RMAN 的基本操作，更多的信息请参考《Oracle8iBackup & Recovery Guide》及RMAN 手册，或者是OCP Student GuideM09096《Backup andRecovery Workshop》Volume 2，也可以通过 gototop@ncn.cn 和我联系。Oracle 自带的例子参考$ORACLE_HOME/rdbms/demo 目录下的*.rcv脚本。 一、RMAN 简介 RMAN可以用来备份和恢复数据库文件、归档日志和控制文件，也可以用来执行完全或不完全的数据库恢复。RMAN有三种不同的用户接口： COMMAND LINE方式、 GUI 方式（集成在OEM 中的备份管理器）、 API 方式（用于集成到第三方的备份软件中）。 具有如下特点： 1）功能类似物理备份，但比物理备份强大N倍，从下面的特点可以看到； 2）可以压缩空块； 3）可以在块水平上实现增量； 4）可以把备份的输出打包成备份集，也可以按固定大小分割备份集； 5）备份与恢复的过程可以自动管理； 6）可以使用脚本（存在Recoverycatalog 中） 7）可以做坏块监测 二、相关术语解释 1）Backup sets 备份集 备份集顾名思义就是一次备份的集合，它包含本次备份的所有备份片，以oracle专有的格式保存。一个备份集根据备份的类型不同，可能构成一个完全备份或增量备份。 2）Backup pieces 备份片 一个备份集由若干个备份片组成。每个备份片是一个单独的输出文件。一个备份片的大小是有限制的；如果没有大小的限制， 备份集就只由一个备份片构成。备份片的大小不能大于你的文件系统所支持的文件长度的最大值。 3）Image copies 映像备份 映像备份不压缩、不打包、直接COPY 独立文件（数据文件、归档日志、控制文件），类似操作系统级的文件备份。而且只能COPY 到磁盘，不能到磁带。可以作为增量备份的0级，一般用来备份控制文件。 4）Full backup 全备份 全备份是指对数据文件中使用过的数据块进行备份，没有使用过的数据块是不做备份的，也就是说，RMAN 进行备份是进行压缩的。 5）Incremental backup 增量备份 增量备份是指备份数据文件中自从上一次同一级别的或更低级别的备份以来被修改过的数据块。与完全备份相同，增量备份也进行压缩。增量备份虽然概念很好，备份也很简单，但恢复起来却是另外一回事，不仅麻烦而且容易出错，所以实际中越来越少使用，到了Oracle 9i已经建议不再使用，以后版本会逐渐取消对增量备份的支持。 6）Recovery catalog 恢复目录 恢复目录用于记录RMAN 使用过程中的控制信息，恢复目录应该经常被同步（这在后面会讲到）。尽管我们可以使用nocatalog 方式来使用RMAN，此时控制信息记录在目标数据库的控制文件中，但这样毕竟不安全，因为一旦目标数据库的控制文件损坏就意味着所有的RMAN 备份失效。同样的道理恢复目录应该建立在另外一个数据库中，在下面的例子中我们称作“目录数据库”。 三、创建恢复目录 1、在目录数据库中创建恢复目录所用表空间 SQL> create tablespace rmants datafile 'c:\oracle\oradata\cc\rmants.ora'size 20M ; 表空间已创建。 2、在目录数据库中创建RMAN 用户并授权 SQL> create user rman identified by rman default tablespace rmants temporarytablespace temp quota unlimited on rmants; 用户已创建 SQL> grant recovery_catalog_owner to rman ; 授权成功。 3、在目录数据库中创建恢复目录 C:\>rman catalog rman/rman 恢复管理器：版本8.1.7.0.0 -Production RMAN-06008：连接到恢复目录数据库 RMAN-06428：未安装恢复目录 RMAN>create catalog tablespace rmants; RMAN-06431：恢复目录已创建 4、注册目标数据库到恢复目录注意哦，这里我的目标数据库使用的服务名称是rman，意思为要使用RMAN 进行备份的数据库，而目录 数据库使用的服务名称是CC。 C:\>rman target sys/sys@rman 恢复管理器：版本8.1.7.0.0 -Production RMAN-06005：连接到目标数据库：RMAN(DBID=1303772234) RMAN>connect catalog rman/rman@cc RMAN-06008：连接到恢复目录数据库 RMAN>register database; RMAN-03022：正在编译命令：register RMAN-03023：正在执行命令：register RMAN-08006：注册在恢复目录中的数据库 RMAN-03023：正在执行命令：full resync RMAN-08002：正在启动全部恢复目录的resync RMAN-08004：完成全部resync 好了，到此为止前面的准备工作都做好了，下面就可以使用RMAN 来进行备份和恢复了。 四、使用RMAN 下面通过具体的例子来说明RMAN 的使用，这里会涉及到除了恢复以外的所有RMAN 操作，关于使用RMAN 进行恢复的内容请参考我以前写的另外一篇文章：RMAN 恢复实践。 1、备份整个数据库 RMAN>run { 2> allocate channel c1 type disk; 3> backup datab ase format'e:\dbbackup\2db.dmp'; 4> } 2、复制数据文件 RMAN>run { 2> allocate channel c1 type disk; 3> copy datafile'c:\oracle\oradata\rman\users01.dbf' to 'e:\dbbackup\u.dbf' tag =u1215; 4> } 3、查看备份及复制的信息 RMAN>list backup; RMAN-03022：正在编译命令：list 备份集列表 关键字Recid 标记LV 集合标记集合计数完成时间 ------- ---------- ---------- -- -------------------- ---------------------- 216 1 417347013 0 417346992 1 26-12 月-00 备份段列表 关键字Pc# Cp# 状态完成时间段名 ------- --- --- ----------- ---------------------------------------------- 217 1 1 AVAILABLE 26-12 月-00E:\DBBACKUP\2DB.DMP 数据文件包括列表 文件名称LV 类型检查点SCN 检查点时间 ---- ------------------------------------- -- -------------- ------------- 1 C:\ORACLE\ORADATA\RMAN\SYSTEM01.DBF 0 Full 33224 26-12 月-00 2 C:\ORACLE\ORADATA\RMAN\RBS01.DBF 0 Full 33224 26-12 月-00 3 C:\ORACLE\ORADATA\RMAN\USERS01.DBF 0 Full 33224 26-12 月-00 4 C:\ORACLE\ORADATA\RMAN\TEMP01.DBF 0 Full 33224 26-12 月-00 5 C:\ORACLE\ORADATA\RMAN\TOOLS01.DBF 0 Full 33224 26-12 月-00 6 C:\ORACLE\ORADATA\RMAN\INDX01.DBF 0 Full 33224 26-12 月-00 RMAN>list copy of datafile'c:\oracle\oradata\rman\users01.dbf'; RMAN-03022：正在编译命令：list 数据文件备份列表 关键字文件状态完成时间检查点SCN 检查点时间名称 ------- ---- - --------------- ------------------------- ------ 226 3 A26-12 月-00 33226 26-12 月-00E:\DBBACKUP\U.DBF 4、在备份是设置相关参数 format --文件输出格式， %d--database name, %s--backup sets sequence number, %p--backup pieces sequence number filesperset --每个备份集中所包括的文件数 更多参数请参考本文开始时列出的书。 RMAN>run { 2> allocate channel c1 type disk; 3> set limit channel c1 kbytes 8000; 4> backup 5> format 'e:\dbbackup\db_%d_%s_%p.bck' 6> (database filesperset=2 ); 7> } RMAN-03022：正在编译命令：allocate RMAN-03023：正在执行命令：allocate RMAN-08030：分配的通道：c1 RMAN-08500：通道c1：sid=9devtype=DISK RMAN-03022：正在编译命令：setlimit RMAN-03023：正在执行命令：setlimit RMAN-03022：正在编译命令：backup RMAN-03023：正在执行命令：backup RMAN-08008：通道c1：正在启动full数据文件备份集 RMAN-08502：set_count=6set_stamp=417351064 creation_time=26-12 月-00 RMAN-08010：通道c1：正在指定备份集中的数据文件 RMAN-08522：输入数据文件fno=00003name=C:\ORACLE\ORADATA\RMAN\USERS01.DBF RMAN-08522：输入数据文件fno=00005name=C:\ORACLE\ORADATA\RMAN\TOOLS01.DBF RMAN-08013：通道c1：已创建1 段 RMAN-08503：段handle=E:\DBBACKUP\DB_RMAN_6_1.BCKcomment=NONE RMAN-08525：备份集完成，经过时间：00:00:03 RMAN-08008：通道c1：正在启动full数据文件备份集 RMAN-08502：set_count=7set_stamp=417351067 creation_time=26-12 月-00 RMAN-08010：通道c1：正在指定备份集中的数据文件 RMAN-08522：输入数据文件fno=00002name=C:\ORACLE\ORADATA\RMAN\RBS01.DBF RMAN-08522：输入数据文件fno=00006name=C:\ORACLE\ORADATA\RMAN\INDX01.DBF RMAN-08013：通道c1：已创建1 段 RMAN-08503：段handle=E:\DBBACKUP\DB_RMAN_7_1.BCKcomment=NONE RMAN-08525：备份集完成，经过时间：00:00:04 RMAN-08008：通道c1：正在启动full数据文件备份集 RMAN-08502：set_count=8set_stamp=417351071 creation_time=26-12 月-00 RMAN-08010：通道c1：正在指定备份集中的数据文件 RMAN-08522：输入数据文件fno=00001name=C:\ORACLE\ORADA TA\RMAN\SYSTEM01.DBF RMAN-08011：备份集中包括当前控制文件 RMAN-08013：通道c1：已创建1 段 RMAN-08503：段handle=E:\DBBACKUP\DB_RMAN_8_1.BCKcomment=NONE RMAN-08013：通道c1：已创建2 段 RMAN-08503：段handle=E:\DBBACKUP\DB_RMAN_8_2.BCKcomment=NONE RMAN-08013：通道c1：已创建3 段 RMAN-08503：段handle=E:\DBBACKUP\DB_RMAN_8_3.BCKcomment=NONE RMAN-08013：通道c1：已创建4 段 RMAN-08503：段handle=E:\DBBACKUP\DB_RMAN_8_4.BCKcomment=NONE RMAN-08013：通道c1：已创建5 段 RMAN-08503：段handle=E:\DBBACKUP\DB_RMAN_8_5.BCKcomment=NONE RMAN-08013：通道c1：已创建6 段 RMAN-08503：段handle=E:\DBBACKUP\DB_RMAN_8_6.BCKcomment=NONE RMAN-08013：通道c1：已创建7 段 RMAN-08503：段handle=E:\DBBACKUP\DB_RMAN_8_7.BCKcomment=NONE RMAN-08525：备份集完成，经过时间：00:00:19 .... .... RMAN-08008：通道c1：正在启动full数据文件备份集 RMAN-08502：set_count=9set_stamp=417351090 creation_time=26-12 月-00 RMAN-08010：通道c1：正在指定备份集中的数据文件 RMAN-08522：输入数据文件fno=00004name=C:\ORACLE\ORADATA\RMAN\TEMP01.DBF RMAN-08013：通道c1：已创建1 段 RMAN-08503：段handle=E:\DBBACKUP\DB_RMAN_9_1.BCKcomment=NONE RMAN-08525：备份集完成，经过时间：00:00:07 RMAN-03023：正在执行命令：partialresync RMAN-08003：启动部分恢复目录的resync RMAN-08005：完成部分resync RMAN-08031：释放的通道：c1 5、使用脚本功能 使用脚本的目的在于方便我们操作中的方便，操作上和存储过程相似。 RMAN>create script l0dbbackup { 2> allocate channel c1 type disk; 3> backup 4> format 'e:\dbbackup\db_%d_%s_%p.bck' 5> (database filesperset=2 ); 6> } RMAN-03022：正在编译命令：createscript RMAN-03023：正在执行命令：createscript RMAN-08085：已创建脚本l0dbbackup RMAN>run {execute script l0dbbackup; } 五、RMAN 使用程序 恢复管理器, Recovery Manager, 简陈 RMAN。 RMAN 实现一直服务器管理恢复（Server Managed Recovery： SMR）。 SMR 是一种数据库执行所需要的操作以确保自身备份成功的能力，依赖于Oracle RDBMS 内核中的内置代码可以完成这一功能。 SMR 的功能主要体现在能够减少用户的操作。 RMAN 是SMR的具体实现，它是Oracle 提供的，RMAN 是一个独立的应用程序，它负责建立到Oracle 数据库的客户端连接，以访问数据库内部的备份和恢复数据包。RMAN 的核心命令是解释程序，命令解释程序接受所输入的命令，并将这些命令转换为在数据库上执行的远程调用（Remote Procedure call： RPC）. 要强调的是，RMAN 只是做少量的工作。虽然时间的协调非常重要，但是备份和恢复一个数据库的具体工作实际上是由目标数据库上的进程完成的，目标数据库（target database）指的是要备份的数据库。Oracle 数据库的内部数据包可以将RMAN 中的PL/SQL 块变成系统调用，这些调用即可以写入数据库服务器的磁盘系统，也可以读取数据库服务器的磁盘子系统。 RMAN 实用程序是Database Utilities的一部分。Database Utilities是一组命令行形式的使用程序，包括Import，export，sql*loader和 dbverify。 典型的安装Oracle 时会自动安装RMAN。RMAN 分企业版和标准版2种，如果只能使用标准版的RMAN，那么RMAN 就只能分配一个通道。 RMAN 实用由两部分组成，可执行文件和recover.bsq 文件。  Recover.bsq 文件：实质上是库文件，可执行文件从recover.bsq 文件中析取代码来创建在目标数据库上执行的PL/SQL 调用。Recover.bsq 文件是整个操作的中枢。这个文件始终保持链接，并在逻辑上构成RMAN 客户端使用程序。要注意的是： recover.bsq 文件和 可执行文件的版本必须是相同，否则不能正常工作。 RMAN 实用程序有一种独特的，有序的，可预测的用法：解释在目标数据库上远程执行的PL/SQL 调用中的命令。 RMAN 实用程序完成了我们需要做的所有备份，还原，恢复和处理备份工作。由可执行解释程序负责解释这些程序命令，并基于用户的请求收集信息。 如果要求I/O 操作（即一条备份命令或一条还原命令），RMAN 会在返回信息时准备另一个过程块，并将这个过程块传递回目标数据库。这些过程负责执行OS的系统调用以进行指定的读或写操作。 RMAN 与数据库权限 RMAN 需要访问目标数据库上sys模式中存在的各种数据包，还需要具有启动和关闭目标数据库的权限。 因此RMAN 通常以sysdba 用户身份连接到目标数据库。 如果以不具有sysdba 权限的用户连接到目标数据库，RMAN 会报ORA-01031: insufficient privileges 错误。  在一般情况下，大多数Unix 系统中都有一个Oracle 用户，它是dba组的一个成员。 这是最初安装Oracle 软件的用户，如果以Oracle 用户登录，在RMAN 中以什么身份连接就变的不重要，它将总是作为sysdba 用来连接目标数据库，并且能够访问sys 模式，同时也具有启动和关闭数据库能力。 在windows 平台上，Oracle 会创建一个ORA_DBA本地组，并将安装Oracle 软件的用户添加到这个本地组中。 如果作为dba组成员之外的用户登录并需要使用RMAN，就必须创建和使用一个口令文件来连接来连接到目标数据库。如果要使用一个客户系统通过网络来连接RMAN，也需要创建和使用一个口令文件。 六、RMAN 备份的网络拓扑结构  RMAN 是一个客户端应用程序，它通过Oracle net 连接来与目标数据库连接。 如果目标数据库位于ORACLE_HOME 主目录中，运行同样位于这个主目录中的RMAN 可执行文件，ORACLE net连接就会是一个本地连接。  只要在Oracle 环境中设置了合适的ORACLE_SID 变量，就不需要为这个连接提供一个Oracle net 别名。 否则，我们必须配置tnsnames.ora 文件，在文件中指定目标数据库，并且在将要运行RMAN的位置上完成这个操作。  一般倾向与在目标数据库的ORACLE_HOME 中运行rman， 这是避免在混合环境中出现兼容性问题的最简单和最直观的方法。 我们需要在这种混合环境中负责跨越多个Oracle 数据库和版本的备份。也可以使用OEM 来处理。 6.1 远程运行RMAN 如果你负责管理许多数据库。最好在单个客户端系统上将应用程序合并，这样就可以在这个客户端系统上更好的管理tnsnames.ora 文件内容。如果在RMAN 配置中使用了恢复目录（recovery catalog），由于每次操作RMAN时都会生成一个以上的Oracle net 连接，所以这样的客户端/ 服务端模型不会让人混淆。另一方面，运行与目标数据库不同系统（或者是不同ORACLE_HOME主目录）上的RMAN时，我们需要建立一个口令文件，这样在每个目标数据库上都需要更过的配置和管理。 恢复目录： 用于存储RMAN 备份的历史记录，它含有有关备份发生时间，备份内容和备份大小的元数据。 历史记录中还含有恢复备份所需的关键信息。 元数据是从默认位置（目标数据库控制文件）析取的，并保留在用户模式的数据库表内。 如果要建立一个RMAN 和 目标数据库之间的远程连接，需要创建一个使用专用服务器进程连接到目标数据库的tnsnames.ora 条目。 因为RMAN 不能使用共享服务器（通常称多线程服务器或者MTS）来建立数据库连接。  MYICD =   (DESCRIPTION =     (ADDRESS = (PROTOCOL = TCP)(HOST = DavidDai)(PORT = 1521))     (CONNECT_DATA =       (SERVER = DEDICATED)       (SERVICE_NAME = myicd)     )   ) 6.2 在目标数据库的ORACLE_HOME 中运行本地RMAN 从每个目标数据库中本地运行RMAN 实际上是管理具有数百或者上千 数据库目标的大型企业的唯一方法。 因为RMAN一直具有兼容性问题，将rman.exe 与目标数据库紧密绑定可在长期运行中节省时间。虽然这种方式部署RMAN 备份存在一些缺陷,但这也是最佳方式.  本地运行RMAN意味着只需要本地连接数据库，而不需要建立口令文件和配置tnsnames.ora 文件。但这种简易性也正是它的缺陷。因为一旦引入恢复目录或者执行数据库复制操作，就会遇到我们之前的问题。 七、 数据库控制文件 控制文件平常的作用是负责数据库的物理结构，控制文件控制数据库查找物理文件的位置，并控制每个文件当前包含（或应当包含）的头信息，其内容包括数据文件信息，重做日志信息和归档文件信息。  控制文件还含有与数据库关联的关键文件的每一个文件头的快照（snapshot）。  由于控制文件存储的是数据库文件信息，所以RMAN 会利用控制文件获取备份所需的信息，具体的操作方式是： RMAN 使用控制文件来编译文件列表，得到检查点信息，并确定可恢复性。通过直接访问控制文件，RMAN可以编译文件列表而不需要用户创建文件列表，这样避免了备份脚本时的一个非常繁琐的步骤，并且在添加一个新文件时不需要更改这个脚本。控制文件会存储新文件的信息，因此RMAN也能从控制文件中得到这个信息。 控制文件还能用作RMAN 目录。RMAN完成数据库任何部分的备份后，会在控制文件中添加该备份的记录，以及说明备份开始和结束时间的检查点。这也是从Oracle 7 到Oracle 8 版本控制文件大小呈指数增长的一个主要原因：控制文件中存在RMAN记录。控制文件中的这些记录通常成为元数据，它和实际备份中记录的数据有 ，它也可以存储在恢复目录中。 7.1 在控制文件中重用记录 控制文件将内部数据记录分为两类： 循环重用记录 和 非循环重用记录。  循环重用记录包含可以从控制文件中删除的信息。如： 归档日志历史信息可以被删除，并且不会影响产品数据库。   非循环重用记录是哪些不能被删除的记录，如果控制文件因这类记录而空间不足，则会删除这些记录以得到更多的空间。 非循环重用记录包括 数据文件列表 和日志文件列表。 控制文件中的RMAN 备份记录属于循环重用记录类型，如果含有这些记录的控制文件区域已满，这些记录就会删除。这会给恢复带来灾难，致使控制文件中不存在任何备份记录，就好像从未发生过备份一样。一定要注意的一点： 如果控制文件不含有任何RMAN 备份记录，RMAN 就不能使用备份来执行恢复操作。 删除记录指发生在控制文件空间已经满的情况下，因此被删除的备份肯定是非常陈旧的。 我门还可以设置更大的时间帧(time frame) 来决定控制文件删除记录的时间。Init.ora 文件中的CONTROLFILE_RECORD_KEEP_TIME 参数控制删除时间，默认值是7.既报错7天。可以设置成更大的参数值，如30天。 这些就会扩展控制文件，且只有当记录保留时间超过一个月时才会重写这些记录。 一般将该参数设为较大比较好。 如果参数设为0，将不会发生重用记录，相应地控制文件将不断扩展至无法管理。当然不推荐这么设置。 此外，如果要实现一个恢复目录，就不必担心会循环重用记录。因为只要在CONTROLFILE_RECORD_KEEP_TIME  参数指定的时间内至少实现一次恢复目录同步，那么这些记录将随着时间的推移被删除-- 恢复目录则从不会删除记录。 重新构建控制文件 通常某些条件下需要重新构建数据库控制文件，如重新设置MAXLOGFILES 参数或者MAXLOGHISTORY参数。由于某些参数定义了保存非循环重用记录的内部控制文件表的大小，所有只有在重新构建控制文件时才能设置这些参数。如果需要更大的内部控制文件，就必须重新构建控制文件。 如果使用RMAN 而不使用恢复目录，就必须重视控制文件的重新构建。执行： Alter database backup controlfile to trace; 生成的脚本不包含控制文件中标识备份的信息。如果不存在备份记录，就不能在使用这些备份恢复时访问它们，此时所有的RMAN 信息丢失并且无法恢复。在重新构建控制文件时，只有那些RMAN设置的永久配置参数才被重新构建。 在Oracle 10g有一些新的控制用于生成控制文件中的有限备份元数据，但仍然需要许多手工操作，并且无法完全生成所有的元数据。因此建议要避免重新构建控制文件。 如果将控制文件备份为一个二进制文件而不是一个跟踪文件，所有备份信息都将被保留。 该命令类似于： Alter database backup controlfile to '/u01/backup/bkup_cfile.ctl'; 7.2 快照控制文件 控制文件是一个非常繁忙的文件，它存储数据库的结构信息，这些信息包括用于恢复的检查点SCN信息。连续的SCN 和文件管理对于数据库的生命期来说至关重要，因此RDBMS 必须能够持续的使用控制文件。 这样就会为RMAN带来一个问题。RMAN 开始备份每一个数据文件时需要得到一个一致的控制文件视图，此时RMAN 只需要知道备份开始时最新的检查点信息和文件就够信息。开始备份后，RMAN 需要这些信息在备份操作期间保持一致，也就是说RMAN需要一个读取一致的控制文件视图。除非RMAN 在备份持续时间内锁定控制文件，否则数据库会不断更新控制文件，所以不可能。 但是，锁定控制文件意味着数据库不能执行检查点操作和切换日志，或则不能产生新的归档日志，这些操作是不可能的。 RMAN 使用快照控制文件（snapshot controlfile）来解决前面提出的问题，快照控制文件是控制文件的副本。 RMAN 只在备份和同步操作期间使用快照控制文件。 这些操作开始时，RMAN 会根据实际控制文件来刷新快照控制文件，这样会短暂的锁住控制文件，随后，RMAN 会切换到快照并在备份持续使用这个快照。 这种方式具有读取一致性，且不妨碍数据库活动。 在默认情况下，快照控制文件位于UNIX 平台上的ORACLE_HOME/dbs 目录中，或者是在windows 的ORACLE_HOME/database 目录下。 快照控制文件的默认名为SNCF<SID>.ORA。 使用configure snapshot controlfile命令可以在任何时候更改快照控制文件名： Configure snapshot controlfile name to 'location/file_name'; 八、RMAN 服务器进程 RMAN 生成一个到目标数据库的客户连接，并创建两个服务器进程。其中主要进程生成对SYS模式中的数据包的调用，从而执行备份和恢复操作，该进程会在备份和还原期间协调通道进程的工作。 另外一个次要的进程（或影子进程）轮询RMAN中的所有长事务（long-running transaction）并在内部记录信息。 在V$version_longops 视图中可以查看到下面的轮询结果： /* Formatted on 2010/6/8 16:49:36 (QP5 v5.115.810.9015) */ SELECT   sid,          serial#,          context,          sofar,          totalwork,          ROUND (sofar / totalwork * 100, 2) "%_complete"   FROM   V$SESSION_LONGOPS  WHERE       opname LIKE 'PMAN'          AND opname NOT LIKE '%aggregate%'          AND totalwork != 0          AND sofar <> TOTALWORK 还可以在v$version 视图中查看这些进程。 RMAN 分配一个通道时，它会在输出中提供如果所示的会话ID信息： 分配的通道: ORA_DISK_1 通道 ORA_DISK_1: SID=19 设备类型=DISK SID 信息对应与v$session 中的SID 列。 SQL> col client_info format a30 SQL> col program format a15 SQL> select sid,saddr,paddr,program,client_info from v$session where sid=19;        SID SADDR    PADDR    PROGRAM         CLIENT_INFO ---------- -------- -------- --------------- ------------------------------         19 A9CCBD10 AA728C44 rman.exe        rman channel=ORA_DISK_1 8.1 RMAN 通道进程 除了默认的两个进程外，在备份活还原操作期间还会为分配的每个通道单独的创建一个进程。 RMAN 将通道视为目标数据库上的服务器进程，该进程在备份期间协调读取数据文件和写入指定位置的操作，在还原期间则协调读取备份位置和在数据文件位置写入数据块的操作。 通道进程只有两种类型: 磁盘通道 和 磁带通道。 我们不能为一个备份操作同时分配这两种通道，备份只能写入磁盘或写入磁带。  与后台RMAN 进程一样，可以从数据字典（data directory）跟踪通道进程。并且将通道进程在OS 级别（OS level）上与一个SID 关联。 正是这些通道进程的活动被轮询的影子进程记录到V$SESSION_LONGOPS 视图中。 8.2 RMAN 和 I/0 从属 如果在目标数据库上配置了I/O从属，RMAN 就可以使用I/0从属。 为了用RMAN 备份和还原，有两种可用的I/0从属： 磁盘I/0 从属 和 磁带I/0 从属。 使用DBWR_IO_SLAVES 参数可以配置磁盘I/O从属。 这个参数可以被设置为任意数值，它的主要作用是在将‘脏’缓冲区（即写满的缓冲区）的内容写入磁盘时唤醒另外的DBWR从属来执行磁盘写操作。 如果参数被设置为非0值（如：1，12或23），RMAN 会自动在每个通道中切换使用4个I/O 从属来帮助将数据库读入RMAN内存缓冲区。 这是一个不错的功能，但是RMAN 分配内存的方式有很大的变化。 只有在OS 平台不支持本地异步或者禁止Oracle RDBMS使用异步I/O时，DBWR_IS_SLAVES参数才会起到作用，如果支持异步I/O，就不需要使用磁盘I/O从属。 磁带I/O 从属可帮助服务器进程访问磁带设备。 如果BACKUP_TAPE_IO_SLAVES 参数被设置为TRUE，RMAN 会为每个磁带通道进程分配一个I/O 从属来帮助在磁带位置上执行写操作。 与磁盘I/O 从属不同的是，BACKUP_TAPE_IO_SLAVES 参数只对RMAN 磁带备份起作用。 由于磁带设备不存在本地异步I/O，我们建议将该参数设置为true。 这有助于保持磁带设备传输，以达到更佳的备份和还原性能。 九、 RMAN 使用的SYS数据包 RMAN 服务器进程在协调通道工作时要访问两个SYS数据包：DBMS_RCVMAN 数据包 和 DBMS_BACKUP_RESTORE 数据包， 这两个包包含了目标数据库中RMAN的所有功能。 9.1  SYS.DBMS_RCVMAN 数据包 DBMS_RCVMAN 数据包用来访问控制文件中的表并将此信息传递给RMAN，使用RMAN 可以构建准确反应数据库结构的备份和还原操作。DBMS_RCVMAN 包负责在执行任何操作前设置time 运算符和校验数据文件头中的检查点信息，并检查文件位置和大小，以及有关节点相似性（在RAC 环境中）和磁盘相似性的其他信息。 这种信息会影响RMAN的性能，并且RMAN 在构建实际备份/还原命令之前自动执行负载均衡（load-balancing）算法和性能增强（performance-enhancing）算法。   9.2 SYS.DBMS_BACKUP_RESTORE 数据包 SYS.DBMS_RCVMAN 包访问控制文件并校验所有必须的信息。 这些必须的信息被传递回RMAN服务器进程，RMAN 服务器进程随后会基于recover.bsq 文件中的代码创建一些PL/SQL 块。 这些PL/SQL 块含有对DBMS_BACKUP_RESOTRE 数据包的调用，实际上RMAN 中是由DBMS_BACKUP_RESTORE数据包来创建系统调用以备份数据文件，控制文件和归档的redo log。 RMAN 接收从DBMS_RCVMAN 数据包返回的信息，并在通道间基于负载均衡算法分配工作，然后创建一系列DBMS_BACKUP_RESTORE 数据包调用。   在V$SESSION_LONGOPS 视图中可以跟踪的是DBMS_BACKUP_RESTORE 数据包的工作。它执行备份和还原操作，此外还可以以受限方式访问控制文件。 DBMS_BACKUP_RESTORE 数据包访问控制文件以备份该文件（实际上是控制文件的快照），在备份完成后写入备份信息。 一旦完成了一个备份集， DBMS_BACKUP_RESTORE 数据包就会在控制文件的表中写入备份开始时间，备份大小和备份名的信息。 9.3 内核中的RMAN 数据包 创建数据库时，运行cataproc.sql 脚本可以默认安装上述两个RMAN 数据包。 数据库创建期间无法跳过这一步骤。所以在8i 以后的每个版本里都存在rman 包。 这些RMAN 数据包还有一个重要的特性，他们被硬编码到Oracle 软件的库文件中，因此及时没有打开数据库也可以调用这些数据包。 我们知道，大多数数据包只在数据库打开时才能被使用，不过RMAN可以在数据库实例处于未加载模式或者加载模式时编写对DBMS_BACKUP_RESTORE 数据包的调用。 这也是为什么在没有打开数据库时也能够备份和还原数据库。 十、 备份数据块 即使是高级备份技术，备份的单元依然是数据文件，最终进行备份的OS 使用程序将查看并备份整个文件，因此需要特别注意保证Oracle 数据块的完整性，然后，RMAN 与之不同，因为RMAN 是集成在RDBMS 中的，它是在数据块层面访问数据，这和数据库本身所使用的方式相同。 块级别访问是RMAN 区别于其他备份工具的地方，正是由于rman 采用了这一层面的访问，才使得它具有诸多优势，因此我们可以更有效的利用数据块进行备份和恢复。 10.1 数据块备份概述 数据块备份的工作原理：RMAN 基于备份算法规则来编译要备份的文件列表。基于通道数和同时备份的文件数，RMAN 在Oracle 共享内存段中创建一些内存缓冲区。 一般在PGA中，不过有时内存缓冲区会被推入SGA。 通道服务器进程随后开始读取数据文件，并在RMAN缓冲区中填充这些数据块。一个缓冲区被填充时，输入缓冲区中的数据快会被推入输出缓冲区。 数据文件中的每个数据块都会发生这种内存对内存的写操作（memor-to-memory write）。 如果数据块复合备份的标准并且内存对内存的写操作没有检测到讹误（corruption），则这些数据块会保留在输出缓冲区中直至输出缓冲区被填满。 一旦输出缓冲区被填满，输出缓冲区就会被推至备份位置（磁带或者磁盘）。 一旦所有文件已通过内存缓冲区过滤，就完成了备份片，同时RMAN 会在目标数据库的控制文件中写入备份片的完成时间和备份片的名称。 10.2 块级备份的优点 每个数据块从磁盘移入内存时都会发生内存对内存的写操作，在这个操作期间会检查数据块的讹误。讹误检查是RMAN的一个重要特性。 要注意的是: 执行代理复制操作时是不会使用数据库检查的。 访问数据块时可以选择 空值压缩（null compression），我们可以删除从来没有使用过的数据块（头为0），并在执行内存对内存的写操作时丢弃这些数据块，因此，我们只需要备份使用过的数据块，从而执行更有效的备份操作。 块级备份从生成redo 的角度来说也提供了性能增益。如果是老式的热备份方法，运行热备份模式的表空间生成的redo log数量有失会呈指数增长，这会造成过多的redo 切换，检查点故障和 生成大量的redo log。巨量的archive log会给日志归档位置上的空间管理带来一定困难。 另一方面，由于在备份期间不要求保证数据块的一致性，所以RMAN不要求用热备份模式。RMAN 对数据块的访问允许RMAN 与写‘脏’缓冲区的DBWR进程协调，并且在将这个数据块读入内存以前，它可以等待直至数据块达到一致，因此数据块不会被转存为redo，并且备份中的数据块总是一致的。 当然，RMAN 也不要求用archive log 模式，但是如果是非归档模式，rman 不允许我们在数据库打开时备份一个数据文件，否则会报如下错误：ora-19602：cannot backup or copy active file in NOARCHIVELOG mode。 RMAN 可以使用块级备份提供进一步的恢复新选项： 块介质恢复（block media recovery）. 如果出现： ora-1578:block corruption detected, 就不需要恢复整个文件以及执行恢复操作，RMAN 可以简单的恢复坏数据块并执行恢复操作，也就是说数据文件中的其他数据在恢复期间仍然可用。 十一、内存中的RMAN RMAN 会在内存中构建一些缓冲区，然后通过这些缓冲区将数据块写入到备份中。 内存的利用与PGA(有时是SGA)的总体大小有关。 内存缓冲区分为输入缓冲区和输出缓冲区。 输入缓冲区（input buffer）填充从备份文件中读取的数据块；输出缓冲区（output buffer）则在执行内存对内存的写操作时填充需要备份的数据块，一旦输出缓冲区被填满，输出缓冲区的内容就会被写到备份位置。 11.1 输入内存缓冲区 备份数据库时，输入内存缓冲区的大小和数据取决于实际执行的备份命令，事实上它主要取决于在一个备份中多路服用（multiplexing）的文件数。 多路复用指的是在同一个备份片中备份某数据块的文件数。为了保持合理范围的内存分配，根据一起备份的文件数，分配内存缓冲大小需要应用下面的规则。 1） 如果备份集内的文件数小于或者等于4个，RMAN 会为每个文件分配4个大小为1MB的缓冲区。缓冲区总和小于或者等于16MB。 2） 如果备份集内文件数多余4个但少于等于8个，RMAN 会为每个文件分配4个大小为512KB的缓冲区。缓冲区总和确保少于或者等于16MB。 3） 如果多路复用的文件数多余8个，RMAN 会为每个文件分配4个大小为128KB的缓冲区。这就确保每个要备份的文件占用512KB的缓冲区内存。 一定要记住在每个通道基础上分配内存大小。因此，如果分配两个通道来备份具有32个数据文件的数据库，RMAN会根据负载均衡来分配两个通道，而不是为每个通道分配16个文件。 如果某些文件比另外的文件大的多，我们可能在一个备份集内备份8个文件，在另一个备份集内备份24个文件。 如果是这样，则用于第一个通道（8个文件）的缓冲区会分配16MB的输入缓冲区（8个文件，每个文件有4个缓冲区，每个缓冲区512Kb），用于第二个通道（24个数据文件）的缓冲区会分配12MB的输入缓冲区（24个文件，每个文件的缓冲区为512KB）。 可以使用如下的查询来监控备份运行时基于每个每个文件的缓冲区大小： /* Formatted on 2010/6/9 9:37:52 (QP5 v5.115.810.9015) */   SELECT   set_count,            device_type,            TYPE,            filename,            buffer_size,            buffer_count,            open_time,            close_time     FROM   v$backup_async_io ORDER BY   set_count,            TYPE,            open_time,            close_time; 11.1.1 备份到磁盘时的输出内存缓冲区 除了输入缓冲区之外，RMAN还会根据输出设备分配输出缓冲区。如果备份到磁盘，则RMAN 将分配输出缓冲区以在数据溢出到备份片之前接收来自输入缓冲区的数据块。此时，每个通道有4个输出缓冲区，每个输出缓冲区大小为1MB，因此每个通道的内存区域通常为4MB。 11.1.2 备份到磁带时的输出内存缓冲区 备份到磁带时的内存分配是不同的，这是由于磁带设备的I/0速率较慢。在磁带上备份或从磁带上恢复时，RMAN会为每个通道进程分配4个输出缓冲区，每个缓冲区的大小为256KB，因此每个通道的内存区域通常为1MB。 11.2 用于还原的内存缓冲区 还原操作期间的内存分配与备份操作期间的内存分配稍有不同，这是因为他们的作用是相反的：备份操作是读取数据文件并写入备份位置，而还原操作则是读取备份位置并写入数据文件。 还原磁盘备份时，输入缓冲区的大小为1MB，同时RMAN 会为每个通道分配4个缓冲区。 还原磁带备份时,RMAN 会分配4个输入缓冲区，每个缓冲区的大小等于blksize参数的值（默认值为256kb）。用于还原的输出缓冲区通常为128kb，并且每个通道有4个输出缓冲区。 11.3 RMAN内存利用： PGA 和 SGA 在磁盘上的备份会使用PGA内存空间作为备份缓冲区，PGA 内存空间从用于通道进程的内存空间中分配。如果操作系统没有配置本地异步I/O，可以利用DBWR_IO_SLAVES参数使用I/O从属来填充内存中的输入缓冲区。如果设置DBWR_IO_SLAVES 参数为任意的非零值，RMAN 会自动分配4个I/O 从属协调输入缓冲区内存中的数据块加载。为了实现这一功能，RMAN 必须利用一个共享内存区域。因此，用于磁盘备份的内存区会被推入共享池，如果存在large池，则被推入large池。 如果没有使用磁带I/O从属，会在PGA中分配用于磁带输出缓冲区的内存。设置init.ora 参数BACKUP_TAPE_IO_SLAVES=TRUE，可以使用磁带I/O从属，必要时还可以在spfile里动态修改。 该参数设为true时，rman 会为每个通道创建一个从属进程来帮助备份工作。为了协调这一功能，RMAN 会将内存分配推进SGA。 如果配置了任一种I/O从属选项并且没有配置large 池，则会在SGA的共享池曲终分配内存。如果没有配置large池又要使用I/O从属，建议最好创建一个large池，这个large池的大小基于为备份分配的通道总数（加上1MB用于开销）。 十二、 恢复目录 恢复目录存储的是与RMAN 备份有关的元数据。在某种意义上，恢复目录可以看做是保存RMAN 备份和恢复所需的相关信息的副本。我们可以在Oracle 数据库中在用户模式下创建恢复目录，这个恢复目录仅仅是一些数据包，表，索引和视图。 RMAN 中的再同步命令会使得目标数据库控制文件中的内容刷新这些表中的数据。当然，区别在于恢复目录可以包含企业中所有数据库的信息，而控制文件只包含关于它自己的数据库的信息。 在连接恢复目录的连接字符串中，要输入该RMAN目录用户的用户名和口令。与连接目标数据库不同，到恢复目录的连接不是一个sysdba连接，因此不需要sysdba 权限。 一旦连接了恢复目录，就可以手工在同步恢复目录，或者任何备份操作都可以隐式的再同步恢复目录。 再同步是指用目标数据库控制文件中的内容刷新恢复目录中表的信息。 一个恢复目录可以存储多个目标数据库的信息，这样可以集中管理许多不同数据库的备份，通过SQL可以查询恢复目录的视图，由此确定在恢复目录中注册的每个目标数据库的备份数，备份大小和备份范围。  恢复目录中存在数据包DBMS_RCVMAN会给包含该恢复目录的数据库带来混乱，这样的数据库通常称为目录数据库（catalog database）。目录数据库也可能是目标数据库，它也含有SYS模式中的DBMS_RCVMAN 数据包，因此如果选择目录数据库中的DBA_OBJECTS，就会存在模式不同但是名称相同的两个数据包。 这样并不会引起错误或我难题。因为其中一个数据包在数据库创建时由cataproc.sql 构建（在SYS模式下），另外一个数据包则是在创建恢复目录时构建，在常规用户模式下。 恢复目录中的第二个数据包是DBMS_RCVCAT数据包，这个数据包只在RMAN操作期间执行特殊的恢复目录操作。实质上，可以将这个数据包看做恢复目录的DBMS_BACKUP_RESTORE数据包实现。区别仅在于DBMS_BACKUP_RESTORE数据包在目标数据库控制文件中写入备份完成信息，而DBMS_RCVCAT数据包则将这些信息写入恢复目录。 另外，包含恢复目录中信息的基表（base table）并不重要，因为我们不想手工修改这些基表。为了保护恢复目录，Oracle创建了一系列前缀为RC_的视图，使用这些视图可以从恢复目录中析取信息。手工执行任何针对目录对象的DML命令都是非常危险的。还有一点，这些视图是数据库控制文件中相应v$视图的不同实现。 十三、 辅助数据库 辅助数据库（auxiliary database）是指在表空间时间点恢复（Tablespace Point In Time Recovery: TSPITR）,,复制操作(克隆数据库)或使用RMAN 备份创建备用数据库时,为了还原目标数据库的文件而临时生成的实例。执行上述任一种任务时，我们都要在RMAN中同时连接目标数据库和辅助数据库，这样就可以利用目标数据库控制文件中的备份信息在辅助数据库位置调整这些备份还原。 RMAN>connect target / RMAN>connect auxiliary sys/pwd@SID 执行这些命令后，RMAN会同时生成到每个数据库的连接，并要求访问目标数据库与辅助数据库中的SYS.DBMS_BACKUP_RESTORE 和 SYS.DBMS_RCVMAN 数据包。 这样一来，RMAN要求用户对辅助数据库具有与目标数据库相同的sysdba权限。由于RMAN必须生成到这两个数据库的sysdba 连接，而且不可能本地连接两个不同的数据库，所以必须至少要配置一个数据库，创建一个口令文件，并且生成到这个数据库的Oracle net 连接。 十四、 版本兼容性 鉴于必须使用多种不同的组件，所以在使用RMAN时必须注意数据库版本的限制。兼容性问题分为5个部分，每一个部分都有一个版本号： 1） RMAN 可执行文件版本（客户端使用程序） 2） 目标数据库 3） 恢复目录模式 4） 恢复目录数据库 5） 辅助数据库（用户复制，TSPITR和备用数据库的创建） 当然，解决兼容性问题的最佳方法是保证这些组件都使用最新的版本，如果使用相同版本的组件，一切都会井然有序。 14.1 目标数据库与RMAN 可执行文件  一个通用规则：尽量保证目标数据库与RMAN可执行文件使用的是相同的版本。如果在目标数据库环境下运行RMAN，做到这一点就很容易。如果从一个集中的客户端接口运行所有RMAN工作，这将非常棘手，它意味着客户端需要安装一个ORACLE_HOME客户端，版本上要对应需要连接和备份的每个数据库版本，该解决方案相当复杂。 使用10G 的OEM 可以解决这个问题，该软件支持集中的客户端接口，因为我们可以从单个控制台使用远程RMAN可执行文件，或者在多个DBA完成备份任务时从控制台使用远程RMAN可执行文件。 14.2 恢复目录数据库与版本目录模式 针对恢复目录数据库与恢复目录模式的兼容性问题，一种简单的方法，就是在高版本的数据库（如11g）中创建该版本的恢复目录，那么这个目录可以注册低版本的数据库。但是低版本不能注册高版本的。 14.3 辅助数据库 从兼容性观点看，辅助数据库必须与要复制的目标数据库采用相同的版本。实际上，最好在复制的数据库中插入与目标数据库相同版本的ORACLE_HOME 主目录。 十五、 RMAN 进程 先举一个简单的备份例子： C:>Rman target / Rman>backup database; 详细的看一下RMAN 备份的全过程： RMAN 生成到目标数据库的bequeath连接，这就是说RMAN会检查ORACLE_SID变量中的实例名，并在该实例上产生一个服务器进程，然后作为sysdba用户登录。这样我们被连接为内部数据库用户sys，rman会立即产生一个用于执行备份操作的通道进程。 如果使用默认设置，就只分配一个通道。 在没有使用I/O从属的情况下，通道进程会在PGA中分配内存。 随后RMAN 通过编译一个sys.DBMS_RCVMAN调用，从目标数据库控制文件中请求数据库结构信息，显示确定目标数据库的版本。RMAN从控制文件中收集版本信息和控制文件本身的信息，控制文件本身的信息包括控制文件的类型，控制文件中的当前序列号以及控制文件的创建时间。 我们在例子中指定了数据库的完全备份，所以RMAN会请求数据库中每个数据文件的信息，并且判断是否存在离线的数据文件。这些数据文件信息包括每个数据文件所在磁盘和工作方式的信息，由于使用了默认设置，所以只存在一个通道和一个备份集。 这样以来，rman会忽略所有的相似性信息，把注意力放在编译包含在数据集内的文件列表上。 编译了文件列表之后，RMAN 就准备开始执行备份进程。 为了保证一致性，RMAN必须构建快照控制文件。如果存在快照控制文件，RMAN会将这个文件重写为新的快照控制文件。 接下来，RMAN创建对DBMS_BACKUP_RESTORE数据包的调用，该调用可以创建备份片，备份片被构建在默认的文件位置中，UNIX系统中的这个文件位置是ORACLE_HOME/DBS，WINDOWS 下默认位置是: ORACLE_HOME/database。 RMAN 拥有文件列表，所以它可以为磁盘读取操作分配内存缓冲区。假如实例有20个数据文件，这样RMAN 会分配一些大小为128KB的输入缓冲区，由于每个文件有4个输入缓冲区，所以这些输入缓冲区总共就需要10MB内存。RMAN 只分配4个输出缓冲区，每个输出缓冲区为1MB。 所以备份操作总共需要的内存是14MB。 分配了内存之后，RMAN 初始化备份片。备份片会得到一个唯一的默认名。随后RMAN 开始备份。从9i以后，RMAN 以50M 为增量分配磁盘空间，在磁盘上分配50MB的空间并填充输出缓冲区，当输出缓冲区满时，则获取另一个50MB空间，知道将最后一个数据块转存到被分片上。当备份完成时，释放最后一个50MB数据块上的剩余空间。 要注意的是：RMAN 不再检查是否存在用于成功备份操作的足够空间，这是因为空值压缩和新的10g 空白压缩可以极大地减少备份中的数据文件大小。相反，RMAN 将运行它的备份知道空间用完，然后备份失败。 一旦初始化了备份片，通道进程就可以开始数据库备份进程。RMAN会判断是否使用了spfile，如果使用了spfile，RMAN 会自动将该文件备份为备份集的一部分。RMAN 还要在备份集中备份当前控制文件。只要备份了SYSTEM 表空间，就会自动备份当前的控制文件。 完成spfile和控制文件的备份后，就开始读取数据文件并将数据块推入内存，为了实现这一功能，通道进程在磁盘上执行预读（read-ahead）操作，并且将多个数据块同事推入内存。随后发生的是从输入缓冲区到输出缓冲区的内存对内存的写操作，在这个写操作期间，RMAN会判断数据块是否被初始化，或者数据块头信息是否仍然为零。如果数据块未被使用过，就不会发生到输出缓冲区的写操作，同时丢弃这个数据块。如果数据块被使用过，RMAN就会在这个数据块上执行检验和checksum 操作。 如果数据块的头和脚注不匹配，这个数据就会被写入输出缓冲区。 一旦输出缓冲区被填满，就会将输出缓冲区的内容转存储到备份文件位置。 由于RMAN缓冲区填充来之所有数据文件的数据块，所以在转存储文件中的数据块是杂乱无序的。 转储文件只是一个存储段，只有RMAN能够在还原时将这些数据块还原到正确的位置。在备份片中写入数据块时，可以从RMAN影子进程中得到备份的状态信息。RMAN影子进程在目标数据库上检查远程过程调用（RPC），并将信息传递给V$VERSION_LONGOPS视图，以供用户查看。基于在备份操作开始时收集的信息，RMAN会估计每个通道进程完成的百分比，可以通过一下SQL 查看： /* Formatted on 2010/6/9 22:50:05 (QP5 v5.115.810.9015) */ SELECT   sid,          serial#,          context,          sofar,          totalwork,          ROUND (sofar / totalwork * 100, 2) "%_complete"   FROM   v$session_longops  WHERE       opname LIKE 'RMAN%'          AND OPNAME NOT LIKE '%aggregate%'          AND sofar <> totalwork; 在备份进程期间，可以重复执行这个脚本，来查看剩余工作量信息。 一旦一个数据文件的所有数据块都被读入输入缓冲区并且确定状态，RMAN 就会通过将这个数据文件头写入被分片来结束该文件的备份操作。在所有数据文件头都被写入备份片之后，RMAN 会生成最后一个对SYS.DBMS_BACKUP_RESTORE数据包的调用，该调用在控制文件中写入备份信息，这些备份信息包括备份片名，启动备份操作时的检查点的SCN和完成备份操作的时间。 以上就是备份操作的所有过程。如果想进一步了解备份内存的工作流程，可以启动调试选项，从而得到一个完成的进程列表。 不过这个操作可能会影响备份的性能。 最好只在测试环境下使用。 Rman target / debug trace=/u01/backup/rmanback.out 十六、 闪回恢复区 闪回恢复区（Flash recovery area： FRA）不是所有RMAN 需要的组件，但是它应该成为RMAN所需的组件。作为10g 版本的新特性，FRA是磁盘上用于存储所有Oracle 恢复文件的特定位置。 恢复文件是指进行介质恢复时所需的所有文件: 完全的数据文件备份，增量备份，数据文件副本，备份控制文件以及归档的日志。 FRA 也存储联机重做日志，块更改跟踪文件以及当前控制文件的镜像副本。 具体内容参考： Oracle Flashback 技术 总结 http://blog.csdn.net/tianlesoftware/archive/2009/10/16/4677378.aspx

title: SQLServer · 最佳实践 · 透明数据加密TDE在SQLServer的应用 author: 石沫 背景 作为云计算的服务提供者，我们在向用户提供优秀的服务能力时会遇到一个合规的问题。在数据库领域，数据是极其敏感和珍贵的，保护好数据，就如保护好企业的生命线。因此，需要采取一些预防措施来帮助保护数据库的安全，如设计一个安全系统、加密机密资产以及在数据库服务器的周围构建防火墙。但是，如果遇到物理介质被盗的情况，恶意破坏方只需还原或附加数据库即可浏览数据，或者遭遇拖库情况。一种解决方案是加密数据库中的敏感数据，并通过证书保护用于加密数据的密钥。这可以防止任何没有密钥的人使用这些数据，但这种保护必须事先计划。在SQL Server中，透明数据加密 (TDE) 可以加密 SQL Server数据文件，能够有效保护好我们的数据资产。 实现原理 数据库文件的加密在页级别执行。已加密数据库中的页在写入磁盘之前会进行加密，在读入内存时会进行解密，TDE 不会增加已加密数据库的大小。TDE 可对数据和日志文件执行实时 I/O 加密和解密。这种加密使用数据库加密密钥，该密钥存储在数据库引导记录中以供恢复时使用。数据库加密密钥是使用存储在服务器的 master 数据库中的证书保护的对称密钥，或者是由 EKM 模块保护的非对称密钥。TDE 保护“处于休眠状态”的数据，即数据和日志文件。体系如下: 实现方法 场景说明： 如果只是简单的配置一个加密数据库，如下步骤即可：创建主密钥，创建证书，创建DEK，应用加密，我们选取了一个比较复杂的场景，与数据库镜像的共存。。同时镜像的创建是在非WINDOWS认证的安全策略，是通过证书的安全认证，这里涉及到master key等信息的特殊处理，证书的多样性。 下面列举实现的方法：首先，需要配置好用户数据库的镜像: 在principal: 创建master key 先判断是否存在master key, 如果存在可以先DROP再创建，因为涉及到master key密码需要利用，老的master key不一定记得住密码: USE master GO CREATE MASTER KEY ENCRYPTION BY PASSWORD='mypassword' 查询验证： SELECT * FROM sys.symmetric_keys WHERE name='##MS_DatabaseMasterKey##' 在Principal:创建镜像使用的证书 USE master GO CREATE CERTIFICATE cer_db_mirror_principal WITH SUBJECT='certification for mirror', START_DATE='01/01/1999', EXPIRY_DATE='12/31/2099'; 查询验证： SELECT * FROM sys.certificates WHERE name='cer_db_mirror_principal' 在principal: 创建镜像使用的端点 CREATE ENDPOINT endpoint_mirroring STATE=STARTED AS TCP ( LISTENER_PORT=5022, LISTENER_IP=ALL ) FOR data_mirroring( AUTHENTICATION=CERTIFICATE cer_db_mirror_principal, ENCRYPTION= REQUIRED ALGORITHM RC4, ROLE=ALL ) 查询验证： SELECT * FROM sys.tcp_endpoints WHERE name='endpoint_mirroring' 在principal: 备份master key OPEN MASTER KEY DECRYPTION BY PASSWORD = 'mypassword'; BACKUP MASTER KEY TO FILE = 'D:\backup\master_key.mky' ENCRYPTION BY PASSWORD = 'context' 在principal: 备份证书 BACKUP CERTIFICATE cer_db_mirror_principal TO FILE='D:\backup\cer_db_mirror_principal.cer' 在mirror: 还原master key RESTORE MASTER KEY FROM FILE = 'D:\Backup\master_key.mky' DECRYPTION BY PASSWORD = 'context' ENCRYPTION BY PASSWORD = 'context'; 查询验证： SELECT * FROM sys.symmetric_keys WHERE name='##MS_DatabaseMasterKey##' 在mirror: 创建证书 USE master GO OPEN MASTER KEY DECRYPTION BY PASSWORD = 'context' CREATE CERTIFICATE cer_db_mirror_mirror WITH SUBJECT='CERTIFICATION FOR MIRROR', START_DATE='01/01/1999', EXPIRY_DATE='12/31/2099' 查询验证： SELECT * FROM sys.certificates WHERE name='cer_db_mirror_mirror' 在mirror: 创建端点 CREATE ENDPOINT endpoint_mirroring STATE=STARTED AS TCP ( LISTENER_PORT=5022, LISTENER_IP=ALL ) FOR DATA_MIRRORING( AUTHENTICATION=CERTIFICATE cer_db_mirror_mirror, ENCRYPTION= REQUIRED ALGORITHM RC4, ROLE=ALL ) 查询验证： SELECT * FROM sys.tcp_endpoints WHERE name='endpoint_mirroring' 在mirror: 备份镜像证书 BACKUP CERTIFICATE cer_db_mirror_mirror TO FILE='D:\backup\cer_db_mirror_mirror.cer' 在principal: 创建端点的连接认证用户 USE master GO CREATE LOGIN mirror_for_login WITH PASSWORD=N'22266320-AA49-4F52-A38E-98D5DE313B85' GO CREATE USER mirror_for_user FOR LOGIN mirror_for_login 在principal: 创建镜像的证书，以打通相互成功握手通道 CREATE CERTIFICATE cer_db_mirror_mirror AUTHORIZATION mirror_for_user FROM FILE='D:\Backup\cer_db_mirror_mirror.cer'; 在principal: 为端点授权 GRANT CONNECT ON ENDPOINT::endpoint_mirroring TO mirror_for_login; 在mirror: 创建端点的连接认证用户 USE master GO CREATE LOGIN principal_for_login WITH PASSWORD=N'dd266320-AA4d-4R52-G38E-9DF5DE313B85' GO CREATE USER principal_for_user FOR LOGIN principal_for_login 在mirror: 创建镜像的证书，以打通相互成功握手通道 CREATE CERTIFICATE cer_db_mirror_principal AUTHORIZATION principal_for_user FROM FILE='D:\Backup\cer_db_mirror_principal.cer' 在mirror: 为端点授权 GRANT CONNECT ON ENDPOINT::endpoint_mirroring TO principal_for_login 在principal: 创建一个测试书库 CREATE DATABASE tde_mirror 在principal: 设置数据库的恢复模式为FULL，并备份数据库和日志 ALTER DATABASE tde_mirror SET RECOVERY FULL BACKUP DATABASE tde_mirror TO DISK='D:\Backup\tde_mirror.bak' WITH STATS=5,COMPRESSION BACKUP LOG tde_mirror TO DISK='D:\Backup\tde_mirror.trn' WITH STATS=5,COMPRESSION 在mirror: 还原数据库 RESTORE DATABASE tde_mirror FROM DISK='D:\Backup\tde_mirror.bak' WITH STATS=5,NORECOVERY RESTORE LOG tde_mirror FROM DISK='D:\Backup\tde_mirror.trn' WITH STATS=5,NORECOVERY 在mirror: 设置镜像 OPEN MASTER KEY DECRYPTION BY PASSWORD = 'context' ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY ALTER DATABASE tde_mirror SET PARTNER = 'TCP://10.0.0.1:5022' --ip address or host name 在principal: 应用镜像 ALTER DATABASE tde_mirror SET PARTNER = 'TCP://10.0.0.2:5022' --ip address or host name 在principal: 创建TDE需要的证书 CREATE CERTIFICATE cer_tde WITH SUBJECT='cert for tde', START_DATE='01/01/1999', EXPIRY_DATE='12/31/2099'; 注意，创建完证书，数据库的同步状态可能会是SUSPEND，主备完成加密设置后才会恢复正常。 在principal: 在主库用户数据库创建DEK USE tde_mirror GO CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128 ENCRYPTION BY SERVER CERTIFICATE cer_tde 在principal: 设置数据库加密 USE master GO ALTER DATABASE tde_mirror SET ENCRYPTION ON 查询验证：这个状态应该是3 SELECT d.name,DEK.encryption_state FROM sys.dm_database_encryption_keys dek INNER JOIN sys.databases d ON dek.database_id=d.database_id 在principal: 备份TDE证书 BACKUP CERTIFICATE cer_tde TO FILE = 'D:\Backup\cer_tde.cer' WITH PRIVATE KEY ( FILE = 'D:\Backup\cer_tde.pvk', ENCRYPTION BY PASSWORD = 'tde_password'); 在mirror: 创建证书 OPEN MASTER KEY DECRYPTION BY PASSWORD = 'context' CREATE CERTIFICATE cer_tde FROM FILE = 'D:\Backup\cer_tde.cer' WITH PRIVATE KEY (FILE = 'D:\Backup\cer_tde.pvk', DECRYPTION BY PASSWORD = 'tde_password') 验证： 这个状态应该是1，做FAILOVER后才变成3 SELECT d.name,DEK.encryption_state FROM sys.dm_database_encryption_keys dek INNER JOIN sys.databases d ON dek.database_id=d.database_id 总结 当TDE和镜像共存时，很多步骤还是不一样，配置也多了许多步骤，可以看出有几个点特别注意：第一是master key的处理方式；第二是镜像的证书和TDE证书的区分；第三是镜像数据库TDE的状态变化。 还原数据库 启用了 TDE 的数据库的备份文件也使用数据库加密密钥进行加密。因此，当您还原这些备份时，用于保护数据库加密密钥的证书必须可用。也就是说，除了备份数据库之外，您还要确保自己保留了服务器证书的备份以防数据丢失。如果证书不再可用，将会导致数据丢失。还原数据库需要解密过程，restore database, resotore filelistonly等等，都需要先还原证书，因此备份证书和密钥是必须的。示例： 首先备份TDE证书 BACKUP CERTIFICATE cer_tde TO FILE = 'D:\Backup\cer_tde.cer' WITH PRIVATE KEY ( FILE = 'D:\Backup\cer_tde.pvk', ENCRYPTION BY PASSWORD = 'tde_password'); 备份数据库 BACKUP DATABASE tde_mirror TO DISK='d:\backup\tde_mirror_201605.bak' WITH STATS=5,COMPRESSION 在需要还原的数据库上创建TDE证书 CREATE CERTIFICATE cer_tde FROM FILE = 'D:\Backup\cer_tde.cer' WITH PRIVATE KEY (FILE = 'D:\Backup\cer_tde.pvk', DECRYPTION BY PASSWORD = 'tde_password') 还原数据库 RESTORE FILELISTONLY FROM DISK='D:\backup\tde_mirror_201605.bak' RESTORE DATABASE tde_mirror FROM DISK='D:\backup\tde_mirror_201605.bak' 透明数据库加密共存性 事务日志 允许数据库使用 TDE 具有将虚拟事务日志的剩余部分“清零”以强制加密下一个虚拟事务日志的效果。这可以保证在数据库设置为加密后事务日志中不会留有明文。所有在数据库加密密钥更改前写入事务日志的数据都将使用之前的数据库加密密钥加密。在数据库加密密钥修改过两次后，必须执行日志备份才能再次对数据库加密密钥进行修改 tempdb系统数据库 如果 tempdb 实例中的任何用户数据库是使用 TDE 加密的，则会加密tempdb数据库。如果取消所有数据库加密状态，tempdb的加密数据库状态不会改变。 复制 复制不会以加密形式从启用了 TDE 的数据库中自动复制数据。如果您想保护分发和订阅服务器数据库，则必须单独启用 TDE。快照复制以及用于事务和合并复制的初始数据分发，都能够在未加密的中间文件（例如 bcp 文件）中存储数据。 在事务或合并复制期间，可以启用加密来保护通信信道。 与FileStream数据 即使启用了 TDE，也不会加密 FILESTREAM 数据。 内存中的OLTP 可在拥有内存中 OLTP 对象的数据库上启用 TDE。如果启用 TDE，则内存中 OLTP 日志记录会被加密。如果启用了 TDE，则不对 MEMORY_OPTIMIZED_DATA 文件组中的数据进行加密。