C#完成Oracle数据库镜像与还原

对 *** 作系统进行备份和还原也许是最常用的 实际业务环境升级后 因多方面原因存在严重问题 这时很可能需要还原到升级前的状态 因此数据库建立备份并能进行还原就很有意义 本文是一个使用C#(Visual Studio )结合Oracle客户端完成还原点的建立与恢复的完整例子

明确还原目标

在建立还原点时 首先要明确还原对象 我们所提及的还原并不是简单地对数据库某个时间点整个数据库的备份与还原 因为在升级后发生的实际业务数据是不能进行还原的

会引起重要问题的主要是程序 在数据库中体现在包 函数和存储过程以及与流程相关的参数 方案等核心字典数据与界面层的一致性 而具体业务中产生的数据如收费项目 收费明细等 是不能进行还原的 明确还原目标后 问题的解决就有方向性了

要建立还原点 首先要了解数据库中关键对象的存放位置 对于包 函数等可以在Oracle的数据库视图user_source中找到

备份 建立还原对象列表

在建立C#的工程之后 今天我们利用配置文件nfig xml 设定了相应的 导出对象 Oracle连接 等内容 如图

这样参数就可以在CONFIG中进行调整了 在进行备份时 我们首先要取得相关的程序列表 下面的语句可以找到我们需要的导出对象

selectdistinctus name us typefromuser_sourceuswhereus typein( PROCEDURE FUNCTION PACKAGE PACKAGEBODY );

可以使用 configurationAppSettings来取得配置文件中的设置 如导出对象 数据库连接 回滚目录 如

ls_configs=(string)(configurationAppSettings GetValue( 导出对象 typeof(string))); 首先针对 导出对象 所定义的串进行拆分 ls_typeinfo存放需要导出的类型 并建立Oracle的数据库连接 再根据需要取得数据查询结果

ls_querysql= SelectdistinctUs Name

us typeFromUser_SourceUswhereus typein( +ls_typeinfo+ )orderbyus Name us Type ;

OracleCommand CommandText=ls_querysql;

OracleCommand CommandType=CommandType Text;

//如何解析mandText的值

OracleDataReadermyReader=OracleCommand ExecuteReader(CommandBehavior CloseConnection);

while(myReader Read())

//使用OracleDateReader前进到下一条记录 通过循环 获得信息列表存放到对象列表listPrcInfo中 它包括两个项目 分别就是 对象名strName 对象类别strType

备份 有进度地产生各个对象体

生成了对象列表后 再根据每个对象名和对象类别来读取内容 相对来说就比较简单 只要使用以下方法

ls_querysql = Select us line us text From User_Source Us where us name = + listPrcInfo[i] strName + and us type= +listPrcInfo[i] strType+ order by us line ;  OracleCommand CommandText = ls_querysql;  OracleCommand CommandType = CommandType Text;//如何解析mandText的值 来读取对象的程序内容 并按照我们在CONFIG中所对应的各种文件扩展名来保存文件:

我们首先来看一下什么是数据镜像： 现在几乎所有的应用系统都是基于数据库的，那么数据库的负荷是比较大的，在一天24小时中，任何时间都有可能会有数据要保存到数据库，或是从数据库中读出数据。任意时刻都会有用户连接到我们的数据库服务器上，几十，几百甚至成千上万个用户来连接使用我们的数据库，那么不论是计划内的宕机还是计划外的故障都会造成一定的损失。给我们的用户或是企业带很大的损失，特别是随着数据时代的到来，用户对数据的使用提出了更高的要求，那么作为一个DBA，就要想怎么做才能将这个损失减少到最低，正是因为基于这种需求，数据库镜像技术出现了！SQL SERVER2005中首次提出了数据库镜像概念。特点： 基于软件的高可用性解决方案 那是完全基于软件的高可用性解决方案。不需要增加硬件成本，也就是低硬件成本 快速的故障转移恢复， 最主要的一个亮点，就是快速的故障转移恢复。3秒（对于用户或是DBA是特别有吸引力的） 数据量大的情况一般10秒 在这个数据库镜像技术中有一个数据库服务器我们称为主数据库。它负责用户的连接和数据的处理。还有一个是从服务器，确切来说，这里应该叫镜像服务器，上面也有一个数据库，叫镜像数据库，这个数据库用于存放我们主数据库的一个热备份。也就是说它虽然不连接用户机，但是它对于主服务器上的数据更改呀，变化呀，都能做一个热备份，也就是说如果用户更新了主数据库中的内容，那么主数据库会根据镜像技术将更新传送给镜像服务器，这样就能保证主服务器和从服务器之间的数据是一致的，那么假如说由于某种原因，我们的主服务器或是主数据库不可用了，例如，网络中断，系统故障等等，那么客户端会重新定向到镜像服务器，那么客户端仍然能读取数据，写入数据，他感觉不到主数据库服务已经宕机了。所以采用数据库镜像技术以后，对于用户来说这个可用性就增强了，而且对于故障恢复时间也缩短了。那么客户仍然可以向镜像数据库上写数据。读数据，更新相关的事务，这是我们应用数据库镜像的一个过程。 想实现这个过程，必须要涉及到这么几个角色： 数据库镜像中的服务器角色：这几个角色刚才通过图形介绍了一点，那么在2005中有三种服务器角色，分别是 主体服务器：承载主体数据库 接受用户连接和事务处理请求 也就是说主体服务器正常的情况下就是主体服务器来提供服务 镜像服务器：承载镜像数据库 作为主体数据库的执备份 所谓热备份是说，主体数据库上的变化会立即反应硬驱镜像数据库上。 仅在故障转移后接受用户连接，处理事务请求 见证服务器：监视服务器状态和连接性，实现自动故障转移 也就是说见证服务器会时刻监视两个服务器的状态和连接性，当主体服务器发生宕机或者不可用以后，见证服务器会立即启用故障转移，将镜像服务器切换为主体服务器。继续为用户提供服务器 这是数据库镜像中的三个服务器角色，但是要注意一下就是这三个角色不是固定下来的，是可以变化的： 主体数据库和镜像数据库互为伙伴： 主体和镜像是可以相互转换的 故障转移后伙伴角色发生变化 当主体服务器正常的情况下，用户所有的连接及数据的更新都是直接送到主体服务器的，只不过是主体服务器再将数据备份到镜像服务器上，但是主体服务器不可用时，此时角色就发生了改变。镜像服务器就变成了主体服务器。那么如果原来的主体服务器恢复正常了，那么怎么办，它就会成为镜像服务器。所以它们的角色就彻底变化了。那如果这个服务器又不可用了。那么又是一个转换的过程。 那大家可能又要问一个问题就是这三个角色怎么知道到底哪一个可用，哪一个不可用： 各个服务器实例通过PING交换消息相互监视。与DOS命令的PING原理差不多，但是功能比DOS下的PING要强大的多，DOS下的PING只是检查网络的连通性，而此处的PING即要监视网络的连通性，这是第一步，还要监视数据库服务器实例的运行情况，服务器是否是正常的，还有就是这个服务器上的数据库是否正常。 总结一下数据库镜像工作过程： 正常情况下，配置好数据库镜像以后，用户只能连接主体数据库，但此时镜像数据库是不可用的。用户连上去也没有用。用户只能使用主体服务器时，主体服务器会将数据一方面写到自己的数据库中，另一方面通过事务日志的方式传给镜像服务器，写到镜像服务器的数据库，此时主体服务器会进入一个等待状态。等待镜像服务器的确认，也就是当镜像服务器的数据成功写入到镜像数据库以后会发一个消息给主体数据库，说我现在已经完成了数据的更新了也就是在镜像服务器上执行了一个REDO的过程。这是一个确认。当主体服务器收到这个确认以后会给客户端一个回应，说刚才的那个数据更新的 *** 作已经完成了 那么为什么能实现一个快速恢复机制，这主要和2005中的一个机制是分不开的 但SQL 2005不是没有必要等到回滚结束只要在REDO之后就可以使用了，至于UNDO的 *** 作，在用户使用的过程中你再继续UNDO，所以当主体服务器发生数据更新了，镜像服务器会以最短的时候来时间更新，以至于如果主体数据发生故障了，镜像服务器右以在最短的时间内接替主服务器进行工作。 下面来介绍一下数据库镜像中的三种 *** 作模式： 高可用性：最常用的。 高级别保护 高性能 下面咱们分别来看一下这三种模式，当然最主要的就是高可用性，这是使用比较广的一个模式 高可用性模式： 服务器角色： 主体服务器 镜像服务器 见证服务器 应用场景： 要求高可用性的场合 如股票交易 证券交易 银行等。 要求实现自动故障转移 确保数据的完整： 要求只要是用户提交到服务器上的数据，那怕说数据刚提交上主体服务器就发生故障了，也能保证数据不会丢失。故障转移之后的数据是不会丢失，从而保证数据库的完整性 高级别保护模式： 我们从名称上也能看出来，它的重点在于对数据的一种保护，而不是实现可用性 服务器角色： 主体服务器 镜像服务器 应用场景： 高的数据完整性要求 不要求自动故障转移 对服务的可用性要求较低 也就是说主体数据库的宕机还是可以接受的，但是数据的丢失是不可以接受的，那么这种场合可以使用高级别保护模式 因为没有见证服务器，所以是不能进行自动的故障转移的。那如果主体服务器不可用，那么想实现故障转移，只能是手工完成，所以对服务器的可用性要求较低 高性能模式： 服务器角色： 主体服务器 镜像服务器 应用场景： 主体服务器和镜像服务器距离很远的时候 十几公里或是完全两个城市 通讯链路有明显的延迟 对性能的要求高于数据的完整性 原理是：当主体服务器收到用户的 *** 作后，将此事务传给镜像服务器，因此距离远所以有明显的延迟，所以他不会等镜像服务器的确认，也就是说它不管这个数据到底有没有写到镜像服务器，所以这种模式就在于尽快的响应用户的请求，也就是对用户对性能有一个较高的要求，这个要求是高于数据的完整性。 这种模式下会存在数据的丢失，也就是说如果主体服务器宕机了，我们会把镜像服务器作为主体服务器，但是不能保证这里面的数据就是和主体服务器上的数据是一致的，因为有可能会有丢失。 我们对几个概念简单的介绍一下： 事务安全性： FULL 主体和镜像数据库同步传输的模式， 主体在发送日志后等待镜像的确认 主体和镜像的日志完全一致 OFF 主体和发送日志后不等待镜像的确认，继续处理后继的 *** 作。 主体失败时在镜像上可能丢失部分数据 仲裁：在高可用性或是高级别保护模式下需要仲裁。以决定那一个服务器是主体服务器， 仲裁的改变将导致故障转移，如主体服务器发生故障了，则会发生仲裁的改变，将镜像服务器定为主体服务器。 形成仲裁的形式一般有这么几种： 下面我们就来看一下如何配置数据库镜像： 这应该是大家感觉很兴奋的，因为听我西里哗拉的讲了半天。终于不用再受罪了。其实配置很简单的，只要注意几个步骤就行了。 准备镜像数据库 在镜像服务器上准备镜像数据库 创建数据库镜像端点 在各个服务器上配置镜像端点 配置安全性 启动数据库镜像 下面我们就具体看一下如何去做，有哪些需要注意： 这里需要提到的一点的就是在SQL SERVER2005刚刚发布出来的时候数据库镜像这个服务默认是关闭的，也是不支持的。在刚刚发布SQL SERVER2005正式版本的时候，认为数据库镜像这个技术还不成熟，有待完善。所以如果你使用的是正式版本则无法使用这个技术。 那么需要下载SP1或是以上的补丁。 · 版本号 sql server 2005 版本 9001399 sql server 2005（初始版本） 9002047 sql server 2005 SP1 9003042 sql server 2005 SP2 我们这里直接打SP2补丁：略 准备数据库： 条件 很重要： 主体数据库必须是完全恢复模式 创建镜像数据库 在主体数据库上做一个完全备份，在镜像服务器上使用NORECOVER选项恢复主体数据库。 继续恢复后续日志备份（NORECOVER） NORECOVER 很重要 配置数据库镜像端点 （ENDPOINT） 数据库镜像端点实现镜像会话的通讯，也就是各个服务器的入口点，有点类似于端口号。但不是。也就是说你创建了这个端点之后，各个服务器之间就可以使用TCP协议进行实例间的通讯。每个镜像端点上都在一个唯一的TCP端口号上侦听，一般大家都使用5022号端口。 创建数据库镜像端点： 需要在每个实例上创建 只有管理员组的成员才能权限。 设置端点角色 即有的是伙伴端点，有的是见证端点，所以必须要指定。 激活端点 默认是不能使用的，所以要激活。 下面我们看一下使用T-SQL 语句创建端点 CREATE ENDPOINT DBMIRRORING AS TCP（LISTENER_PORT=5022）当然也可以使用其他端口，只要没有被使用 FOR DATABASE_MIRRORING(ROLE=PARTNER,ENCRYPTION=SUPPORTED) GO -- 创建的是一个数据库镜像端点，角色是伙伴，通讯过程是通过加密的。 ALTER ENDPOINT DBMIRRORING STATE=STARTED GO --激活 此时这个端点就开始侦听了。 创建见证服务器的端点：创建的时候激活端点。 CREATE ENDPOINT DBMIRRORING STATE=STARTED AS TCP（LISTENER_PORT=5022） For DATABASE_MIRRORING (ROLE=WITNESS,ENCRYPTION=SUPPORTED) 配置安全性： 数据库镜像中的实例之间必须可信 都使用WINDOWS 身份验证或是基于证书的身份验证（非信任域），为了简单为例，我们使用WINDOWS身份验证。 赋予服务帐户对端点的连接权限。 在这里我们都使用相同的用户名口令 下面我们创建完端点后就要启动数据库镜像，注意顺序很重要 指定镜像数据库的伙伴 在镜像服务器上 *** 作 指定主体数据库伙伴 在主体服务器上 *** 作 指定见证服务器 在见证服务器上 *** 作 指定事务安全选项 FULL 还是 OFF 对应语句分别是： ALTER DATABASE NOTHWIND SET PARTNER=N'TCP：/SERVER1H:5022' –-在SERVER2（镜像）上执行 ALTER DATABASE NOTHWIND SET PARTNER=N'TCP:/SERVER2:5022' --在SERVER1（主体）上执行 ALTER DATABASE NOTHWIND SET WITNESS=N'TCP:/SERVER3:5022' --在SERVER1（主体）上执行 ALTER DATABASE NOTHWIND SET SAFETY FULL; --在SERVER1（主体）上执行 高可用性 当然也可以使用SMSS 那么完成之后怎么来查看数据库镜像是否完成，可以通过以下两种方法： SMSS 数据库属性---镜像状态 T-SQL SELECT FROM SYSDATABASE——MIRRORING SELECT FROM SYSDATABASE——MIRRORING——WITNESS 下面我们具体看一下配置高可用性数据库镜像 我们使用T-SQL 可以很明显的看到配置的过程。 下面我来介绍一下我们所使用的环境： SERVER1为主体服务器 SERVER2为镜像服务器 SERVER3 为见证服务器 首先我们要 准备数据库：一个是备份主体数据库，一个是在镜像服务器上恢复。 所以 在SERVE1上： BACKUP DATABASE NORTHWIND TO DISK='C:\NWBAK' 在 SERVER2上： RESTORE DATABASE NORTHWIND FROM DISK='C:\NWBAK' WITH NORECOVERY 创建数据库端点： 1． 在SERVER1上创建数据库镜像端点，用于伙伴通讯 Create endpoint dbmirrep as tcp (listener_port=5022) For database_mirroring (role=partner,encryption=supported ); Alter endpoint dbmirrep state=started 通过图形界面可以查看到 2． 在SERVER2上创建数据库端点，也是用于伙伴通讯 Create endpoint dbmirrep as tcp (listener_port=5022) For database_mirroring (role=partner,encryption=supported) Alter endpoint dbmirrep state=started 3． 在SERVER3上创建镜像端点，用于见证通讯 CREATE ENDPOINT DBMIRREP AS TCP （LISTENER_PORT=5022） FOR DATABASE_MIRRORING (role=witness,encryption=supported) ALTER ENDPOINT DBMIRREP STATE=STARTED 4． 检查端点配置 SELECT FROM SYSDATABASE_MIRRORING_ENDPOINTS 也可以通过图形界面查看 配置数据库镜像安全性：也就是指定哪些用户可以使用这个端点。肯定是管理员，一般用户不让他访问。 分别执行: Grant connect on endpoint::"dbmirrep" to "server1\dufei" Grant connect on endpoint::"dbmirrep" to "server2\dufei" Grant connect on endpoint::"dbmirrep" to "server3\dufei" 最后一个就是启动数据库镜像。注意：顺序 首先要从镜像服务上配置 在SERVER2上，指定伙伴端点： ALTER DATABASE ITET SET PARTNER='TCP://SERVER1:5022' 在SERVER1上，指定伙伴端点： ALTER DATABASE itet SET PARTNER='TCP://SERVER2:5022' –查看数据库 --到此为止，就是咱们前面所介绍的高级别保护模式。可以实现数据完整性，但是不能实现高可用性。所以还要继续，也就是说到这里为止，不要见证服务器也可以，但是不能实现故障的自动转移： 在 SERVER1上，指定见证服务器端点： Alter database ITET set wiTness=N'TCP://SERVER3:5022' 设置数据库镜像事务安全级别： ALTER DATABASE ITET SET SAFETY FULL 实验结束,但一定要注意细节 最后看一下数据库镜像角色切换：也就是如何实现故障转移 自动故障转移： 只针对高可用性模式 SAFETY=FULL 测试：禁用主服务器的网卡，查看库状态，再启用再查看 我们到这里已经知道了如何实现数据库镜像，那么用户如何来使用：客户端都是连接到主体服务器上进行工作的。那么如果主体服务器不可用了，那么就会造成用户连接的失败，它怎么知道去自动连接镜像服务器，这里一般使用ADO技术，如ASPNET 或是微软所提借的连接工具。 我们这里借助WINDOWS 的集群功能：来进行测试： SERVER1与SERVER2配置成WINDOWS集群： 实验到此结束! 本文出自 “杜飞” 博客

确定镜像数据库是否与主体数据库保持同步。 在高性能模式下，主体服务器可能会积压大量仍需发送到镜像服务器的未发送日志记录。而且在任意运行模式下，镜像服务器也有可能积压大量已写入日志文件但仍需在镜像数据库中进行还原的未还原日志记录。 确定在高性能模式下，当主体服务器实例变得不可用时所丢失的数据量。 可以通过查看未发送的事务日志量（如果有）以及在主体服务器上提交丢失事务的时间间隔，来确定数据的丢失量。 将当前性能与过去性能进行比较 出现问题时，数据库管理员可以查看镜像性能的历史记录来帮助了解当前状态。通过查看历史记录，用户可以检测性能走向，识别性能问题的模式（例如，一天当中网络变慢或进入日志中的命令数变得异常庞大的时间）。 解决镜像伙伴之间数据流减小的问题。 设置关键绩效指标的警告阈值。 如果新状态行中的值超过阈值，则系统便会向 Windows 事件日志发送提示性事件。系统管理员可以随后根据这些事件手动配置警报。有关详细信息，请参阅将警告阈值和警报用于镜像性能指标。 数据库镜像状态监视工具 可以使用数据库镜像监视器或 sp_dbmmonitorresults 系统存储过程来监视镜像状态。两个系统管理员（即 sysadmin 固定服务器角色成员以及在 msdb 数据库中，由系统管理员添加到 dbm_monitor 固定数据库角色的用户）均可使用这些工具监视本地服务器实例上任何镜像数据库中的数据库镜像。使用上述任意一种工具时，系统管理员还可以手动刷新镜像状态。 注意： 系统管理员还可以配置并查看关键绩效指标的警告阈值。

确定镜像数据库是否与主体数据库保持同步

在高性能模式下，主体服务器可能会积压大量仍需发送到镜像服务器的未发送日志记录

而且在任意运行模式下，镜像服务器也有可能积压大量已写入日志文件但仍需在镜像数据库中进行还原的未还原日志记录

确定在高性能模式下，当主体服务器实例变得不可用时所丢失的数据量

可以通过查看未发送的事务日志量（如果有）以及在主体服务器上提交丢失事务的时间间隔，来确定数据的丢失量

将当前性能与过去性能进行比较出现问题时，数据库管理员可以查看镜像性能的历史记录来帮助了解当前状态

数据库镜像是将数据库事务处理从一个数据库移动到不同环境中的另一个数据库中 镜像的拷贝是一个备用的拷贝 不能直接访问 它只用在错误恢复的情况下 Oracle数据库与MSSQL数据 *** 作上有很大的不同 但是 在镜像 *** 作方面有类比的地方 这篇文章关于MSSQL数据库镜像在Oracle数据库中是如何实现的 它们之间存在哪些差异呢

首先 微软SQL数据库中的镜像数据库类似于Oracle数据库中的备用数据库 我说的只是类似 确切的说 我们需要考虑不同数据库在自己体系中的差异 MSSQL作为一个实例来 *** 作 一个实例包含几个数据库 你首先要登录一个实例 然后选择哪个数据库作用于该实例 而在Oracle数据库中 简单模式（忽略RAC）就只有一个数据库与一个实例相联系 因此 可以这么说 在Oracle数据库中 备份数据库（standby database）就完全是主数据库的快照 而在MSSQL中 镜像数据库仅仅是选择的那个数据库的备份 但没有包括代理 登录 任务（这些或者更多的数据库项目需要单独在数据库镜像上创建或者复制）这些外部数据项

在服务器数量上 Oracle的主数据库和备用数据库配置最小需要 台 在MSSQL中 最小数据是 个或 个 根据你所选择的高可用性 高安全性 高性能方式所决定

高可用性方式 这个 *** 作模式选项允许你在两台服务器上同步事务写入 并支持自动错误恢复 要使用这个选项 你必须还要使用一个证人服务器

高保护方式 这个选项可以让你在两台服务器上同步事物写入 但是错误恢复是手工的 因为自动的错误恢复不是这个选项的一部分 所以也不会用到证人服务器

高性能方式 这个选项不关心两台服务器上的写入是否是同步的 因此在性能上有所提高 当使用这个选项的时候 你只能假设镜像服务器上的所有事情都是成功完成 这个选项只允许手工的错误恢复 因此不会用到证人服务器

为了保证故障自动恢复 就需要有第三台服务器 可以称之为目击者（另外两个就是主数据库和镜像数据库） 你可以将这个目击者当作群集中的一个成员 它实现了 比 投票的能力 当我的一个组件不可达 并因此需要进行错误恢复的时候 证人服务器只有在你想实现自动错误恢复的时候才需要用到

在Oracle数据的一个事务中 日志缓冲器在废数据写入数据文件（忽略write ahead情况）前被刷新或者写入到redo日志中 这种刷新或者写入到redo日志的行为是有必要的 如像实例失败（使用前滚和回滚恢复过程）这样的事件发生时 MSSQL也承认将日志缓冲器写入到磁盘的重要性 不过这里称之为硬化（hardening） 首先将事务日志缓冲器的信息写入到磁盘或者硬化 接着将日志记录块发送到镜像数据库中 镜像数据库接收到该日志记录块后 将之存入到某个缓冲器中 随后依次硬化该日志记录块

当数据发生变化时 MSSQL数据库如何保持主数据库和镜像数据库的一致性呢？

Oracle用户非常熟悉SCN 而MSSQL用户通过使用mirroring_failover_lsn机制（粗略来讲就是一个日志序列号） MSSQL与Oracle不同 MSSQL将事务分离（两个事务在两个机器上） 而不是一个分布式事务（在自身提交前需要远程等待提交）

另外一个相似点 但稍微有些畸变的反射就是redo日志和事务日志 在Oracle中 完成的redo日志将被发送到远程的服务器中 将完成的redo日志应用到备份数据中去 在MSSQL中 事务日志没有被传输 但是就像我以上提到的 日志缓冲器数据发送到网络上 这就导致另外一个镜像反射 备份和恢复模式

在Oracle中 当你处于归档模式或者非归档模式的时候 这些 *** 作是内定的 如果归档redo日志被传输或者提交到一个远程的服务器 那么主数据库明显就是在归档模式下 那些文件就是这么产生的 运行在这种模式下 允许有少量的数据丢失 因为在发生故障（无论什么样的故障）前 恢复能够在任意一个点上执行 在MSSQL中是类似的 但是有三种状态需要选择

《SQL Server联机丛书》 像许多其它的在线资源一样 讲述了在使用MSSQL时 种恢复模式的不同点 快速的比较有 MSSQL完整模式对应于Oracle中的归档模式 简单模式对应于非归档模式 bulk模式与使用直接路径插入 添加提示 或者与nologging模式 *** 作类似

根据以上三种模式（这三种模式很容易转换 不需要关机或者重启）的描述以及日志缓冲器和归档redo日志的讨论中 很容易断定在MSSQL中进行数据库的镜像需要将数据的回复模式设置成完全模式（full model） 简单模式（Simple model）或许也能行 但是这种模式下维持事务日志中的小部分数据 在备份中 如果在日志被删节了 整个镜像过程也就破环了 因为当你在将事务发送到镜像数据库中的时候 如果日志被删节了 这个过程就不能完成

说到数据库被破坏该怎么办呢？

这正是镜像（或者说备份）的主要目的 当主数据库断开或者说遇到故障时候我们希望系统能回到镜像前或者备份前的状况去 这如何才能实现呢？我们能自动实现或者手动实现 想实现这些 需要一些已经完成的设置 在MSSQL中 自动故障恢复 回到原来状态需要在HA模式 事务安全是full 数据传输是同步 有目击服务器的情况下 这种模式下运行还需要使用企业版的数据库系统 高安全性和高性能在标准版的情况下也能实现

MSSQL还有其它版本的选择 但是这些并不如Oracle的反射 干净 这些版本包括 Developer Workgroup 和 SQL Express 举个例子 目击服务器能够是任何的版本 但是如果你想给镜像服务器做一个快照 那么你就需要企业或者开发版的了

在设置伙伴（partner 通常有主数据库和镜像数据库组成）过程中 他们的恢复状态开始起作用 通过使用相同的名字 镜像在远程/镜像服务器上建立（使用配置数据库镜像安全向导是最简单的方法）起来 并且镜像数据库被设置成NORECOVERY 通常它是恢复（recovering）状态的 在MSSQL中 恢复数据库是没有的 因此没有进行上述的设置 是不能被其他用户当作只读数据库来使用的

为了避免这个中缺陷 你可以给镜像做一个快照 使得该 影像 对用户可见 正如我上述所提到的那样 这需要你的数据库版本是企业（或者开发）版 这就意味着用户需要有快照数据库的知识 知道如何进入存储它 如何告诉应用程序使用哪个数据库 惯例上来说 配置文件使用的 NET环境 你能建立一个主数据库和一个故障回滚的辅数据库 如果在Oracle中配置过备份数据库 你就会觉得这很类似

结论

这篇文章内容包括按照Oracle的方式 如何更好的理解在另一种主流的RDBMS上执行镜像或者复制 试着学习和解释你的RDBMS如何工作的 从另外一种模式来得到你的注意有助于你搞清楚你当前数据库系统运行原理 举个例子 我发现非常有实用价值的是Oracle归档模式和MSSQL三种恢复模式之间的关系 使用在MSSQL中的一些术语（伙伴 主数据库 目击 镜像）有助于你构成和识别Oracle中执行数据库镜像的 *** 作

lishixinzhi/Article/program/Oracle/201311/18083

以上就是关于C#完成Oracle数据库镜像与还原全部的内容，包括:C#完成Oracle数据库镜像与还原、哪些系统需要采用数据库镜像技术、数据库镜像后是不是就能完全同步.求大神，该如何处理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！