SQL数据库与oracle数据库镜像有什么不同对比

Oracle数据库与MSSQL数据操作上有很大的不同,但是,在镜像操作方面有类比的地方。这篇文章关于MSSQL数据库镜像在Oracle数据库中是如何实现的,它们之间存在哪些差异呢。

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

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

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

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

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

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

在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时,3种恢复模式的不同点。快速的比较有: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中执行数据库镜像的操作。
为了更好的评价数据库镜像是如何运作,如何实施的,你可以运行两个单独的MSSQL实例,操作系统是XP或者是2003都没有关系。按照MSDN联机丛书的步骤完成一遍。下载或者选用AdventureWorks数据库(类似于Oracle的HR/SH数据库等。这些都没有预安装的),将其镜像到主机服务器上。呈现在你面前的不仅仅是另外一个数据的所具有功能特性,你将还会看到MSSQL所具有的操作,得到自己的正确评价(我平时使用的是Oracle数据库,测试用的是MSSQL,反过来说,你平时使用的是MSSQL,现在用Oracle来测试的话,也会有新的发现)。

(0)

相关推荐

  • mssql2005数据库镜像搭建教程

    一 概述 数据库镜像是SQL SERVER 2005用于提高数据库可用性的新技术.数据库镜像将事务日志记录直接从一台服务器传输到另一台服务器,并且能够在出现故障时快速转移到备用服务器.可以编写客户端程序自动重定向连接信息,这样一旦出现故障转移就可以自动连接到备用服务器和数据库. 优势:数据库镜像可以在不丢失已提交数据的前提下进行快速故障转移,无须专门的硬件,并且易于配置和管理. 二 环境准备 操作系统:Window 2003 enterprise sp2(至少两台,如要启用自动故障转移,必需三台

  • SQL Server 2008 数据库镜像部署实例之二 配置镜像,实施手动故障转移

    上一篇文章已经为配置镜像数据库做好了准备,接下来就要进入真正的配置阶段 一.在镜像数据库服务器上设置安全性并启动数据库镜像会话 1.展开数据库,选择VirtualManagerDB,点击右键选择任务--镜像 2.点击配置安全性,点选是,包括见证服务器 3.去掉见证服务器,以后进行配置 4.设置主体服务器,填入端点名称为site1 5.添加镜像服务器,取端点名为site2 6.指定服务账户为域管理员账户(可以在域内事先配置) 7.创建成功,点击关闭 8.弹出对话框,选择不开始开始镜像 9.点选高性

  • SQL Server 2008 数据库镜像部署实例之一 数据库准备

    一.目标 利用Sql Server 2008 enterprise X64,建立异步(高性能)镜像数据库,同时建立见证服务器实现自动故障转移. 二.前提条件.限制和建议 2.1.伙伴双方(主体服务器和镜像服务器)及见证服务器必须使用相同版本的Sql Server 2.2.如使用见证服务器,择须确保其系统上安装 Sql Server 2005或更高版本 2.3.在镜像服务器上创建镜像数据库时,确保制定相同的数据库名称WITH NOREBOVORY来还原主题数据库备份.另外,还必须通过 WITH N

  • SQL Server 2008 R2数据库镜像部署图文教程

    概述 "数据库镜像"是一种针对数据库高可用性的基于软件的解决方案.其维护着一个数据库的两个相同的副本,这两个副本分别放置在不同的SQL Server数据库实例中.建议使用不同位置的两台服务器来承载.在同一时刻,其中一台上的数据库用于客户端访问,充当"主体服务器"角色:而另一台则根据镜像会话的配置和状态,充当热备份服务器,即"镜像服务器角色",这两种角色不是绝对的. 优点 l 增强了数据保护功能 l 提高了数据库的可用性 l 提高了生产数据库在升级

  • SQL Server 2005 镜像构建手册(sql2005数据库同步镜像方案)

    一. 镜像简介 1. 简介 数据库镜像是将数据库事务处理从一个SQL Server数据库移动到不同SQL Server环境中的另一个SQL Server数据库中.镜像不能直接访问;它只用在错误恢复的情况下才可以被访问. 要进行数据库镜像所需的最小需求包括了两个不同的SQL Server运行环境.主服务器被称为"主机",第二个服务器被称作"备机".主机数据库就是你实际用着的数据库,镜像数据库就是你的数据库的备用拷贝.当事务写入你的基本服务器的时候,他们也同样被传送到并

  • MySQL 数据库双向镜像、循环镜像(复制)

    对于双向数据库镜像,就是数据库A的数据变化要镜像到数据库B中,同时数据库B里的修改也要同时复制到数据库A里. 对于循环数据库镜像,就是多个数据库A.B.C.D等,对其中任一个数据库的修改,都要同时镜像到其它的数据库里. 应用:同一个Zen Cart网店的数据库和程序,可以放置在不同的主机上,在任一台主机上新增的订单.客户资料,都会同时加入其它的主机数据库里. 要实现双向或循环数据库镜像,首先要解决的就是防止数据库中自动递增(AUTO_INCREMENT)字段的冲突,以免多数据库各自生成一样的增量

  • SQL Server误区30日谈 第10天 数据库镜像在故障发生后 马上就能发现

    误区10.数据库镜像在故障发生后,马上就能发现 错误 市面上大肆宣传数据库镜像技术可以在故障发生后,立即检测到错误并进行故障转移. 但事实并不是这样,检测到故障发生的速度要取决于故障的类型. 检测故障发生的最快的情况是,镜像中的主体实例崩溃,从而镜像服务器每秒一次的PING就无法返回值,从而知道主体服务器上不再有这个进程侦听相应的TCP端口,这种情况下,镜像服务器几乎瞬间就能发现故障. 检测到故障发生第二快的情况是主体服务器的操作系统崩溃.此时主体服务器不再响应镜像服务器的PING,从而在镜像服

  • 监视SQLServer数据库镜像[图文]

    1.首先,打开SMS,在任意一个数据库上面点右键,任务,启动数据库镜像监视器. 2.点击注册镜像数据库,在服务器实例下拉菜单中选择镜像数据库的实例名,如果没有,可以直接点连接,然后在链接到服务器窗口中进行设置,如下图所示: 3.设置好后点确定就出现如下窗口所示了: 4. 点击警告选项卡,可以设置对警告的阈值进行设置,如下图所示: 5.在步骤3的窗口上点击历史记录,就可以查看SQLServer数据库镜像运行的历史记录了.如下图所示:

  • SQL Server 2008 数据库镜像部署实例之三 配置见证服务器

    前面已经完成了镜像数据库的配置,并进行那个了故障转移测试.接下来将部署见证服务器,实现自动故障转移. 一.关于见证服务器 1.若要支持自动故障转移,必须在高安全性模式下配置数据库镜像会话,并且还要具有第三个服务器实例(也称为"见证服务器").见证服务器是 SQL Server 的可选实例,它能使高安全性模式会话中的镜像服务器识别出是否要启动自动故障转移.与这两个伙伴不同的是,见证服务器并不能用于数据库.见证服务器的唯一角色是支持自动故障转移. 2.为了给数据库设置见证服务器,数据库所有

  • 简述SQL Server 2005数据库镜像相关知识

    SQL Server 数据库中,数据库镜像是用于提高数据库可用性的主要软件解决方案.数据库镜像基于每个数据库实现,并且只适用于使用完整恢复模式的数据库.简单恢复模式和大容量日志恢复模式不支持数据库镜像,数据库镜像不能镜像master.msdb.tempdb 或 model 数据库.本文我们主要就介绍一下数据库镜像的相关知识,接在来就让我们来一起了解一下吧! 数据库镜像维护一个数据库的两个副本,这两个副本必须驻留在不同的SQL Server 数据库引擎实例(服务器实例)上.通常,这些服务器实例驻留

  • 利用SQL SERVER 2005数据库镜像实现可用性分析

    我们首先来看一下什么是数据镜像: 现在几乎所有的应用系统都是基于数据库的,那么数据库的负荷是比较大的,在一天24小时中,任何时间都有可能会有数据要保存到数据库,或是从数据库中读出数据.任意时刻都会有用户连接到我们的数据库服务器上,几十,几百甚至成千上万个用户来连接使用我们的数据库,那么不论是计划内的宕机还是计划外的故障都会造成一定的损失.给我们的用户或是企业带很大的损失,特别是随着数据时代的到来,用户对数据的使用提出了更高的要求,那么作为一个DBA,就要想怎么做才能将这个损失减少到最低,正是因为

随机推荐