sql server2012数据库镜像首先运行的是哪个数据库

在SQL01、SQL02和SQL03三台数据库效劳器，翻开效劳器管理器并依据导游完结Net framework 35的装置，在这三台数据库效劳器别离刺进并运转SQL Server 2012 Enterprise SP1装置程序，点击“装置”—“全新SQL Server独立装置或向现有装置增加功用”，依据导游完结SQL功用的装置；

在”功用挑选”页面，依据实践使用需要勾选所需的功用，下一步；

在”效劳器装备”页面，修正效劳账户为域账户（保证该账户暗码永不过期），发动类型为”自动”，依据导游在SQL01、SQL02、SQL03完结数据库功用的成功装置；

4

在SQL01、SQL02、SQL03中别离翻开SQL Server装备管理器，启用TCP/IP协议；并在这三个中先后翻开Management Studio，右键实例挑选“方面”，挑选“外围使用装备器”—将特点“RemoteDACEnabled”的值改为“True”。

SQL Server SP 的新特性

SQL Server Service Pack 为数据库管理员们提供了数据库镜像 支持SAP NetWeaver 商务智能 支持全文本和额外功能的准产品 减轻了他们充分利用一个全新的数据库管理系统的痛苦 我们最近采访了微软的产品和项目 询问了他们一些有关新的特性和在Community Technology Preview过程中出现的相关问题的话题 以下是我们对微软的Michael Raheem Tim Tow Herain Oberoi 和 Grant Culbertson四位产品和项目经理采访的问题与回答

在部署新的数据库镜像特性之前 有什么必需满足的先决条件吗

高级产品经理Michael Raheem:SP 中的数据库镜像的先决条件没有发生改变;与 SQL Server 在线书籍 中记录的RTM版本的SQL Server相同

要使数据库镜像成为可出售的产品 你们做了什么

Raheem:在SP 中 数据库镜像经过了更加广泛的测试来确保它可以提供关键任务应用程序所需的高品质和可用性

什么是SQL Server Management Studio Express

产品经理Tim Tow:客户告诉我们他们希望在所有的具有更高生产力和可预测性的版本上都具有相同的用户体验 我们用SQL Server Management Studio Express (SSMSE)做出了回答 这是一个企业管理工具 为SQL Server Express 版本进行了裁剪

SSMSE为数据库 表 视图和查询添加了更多的管理对话框 图形化设计工具 还有图形化的查询执行计划显示 此外 SSMSE是基于Visual Studio外壳的 并且使用了Visual Studio文本编辑工具 这个工具在Express Manager中可以获得 为T SQL提供了丰富得多的编辑环境

SSMSE可以应用在哪些版本的SQL Server上

Tow:SSMSE将重点集中在Express版本产品的管理工具和特殊功能上 然而 它同样还可以用在其他的SQL Server 和SQL Server 版本上

这个更新是如何满足客户的需求的

Tow:SSMSE为客户提供了SQL Express中含有的和可以用在SQL Express上的免费工具 与此同时 新增的全文本查询和报告服务功能还使得客户可以开发更加丰富的数据驱动应用程序

此外 我们的合作伙伴需要一个免费的 容易使用的下载 其中包括可以免费用在他们为自己的客户提供的应用程序中的工具和特性

SP 中对SAP NetWeaver Business Intelligence (BI)的支持所作的改变如何

产品经理Herain Oberoi:对SAP NetWeaver商务智能的新的支持特别与SQL Server报告服务有关 以前的SQL Server都是在SAP运行的机器上面作为底层的数据库存在 现在 除了为SAP NetWeaver商务智能提供数据存储平台之外 SQL Server还提供了报告服务 以有意义的方式直接查询SAP的SAP BW立方体 使报告的创建成为可能

记住 SQL Server不需要为了在SAP BW数据上生成报告而成为底层数据库平台 你可以在不同的数据库上运行SAP 并且使用SQL Server报告服务在数据上进行查询和报告

NET provider和 MDX Query Designer如何与SAP NetWeaver商务智能合作

Oberoi:有一个白皮书很详细地解释了它的工作方式: 在SAP NetWeaver 商务智能中使用SQL Server 报告服务

在CTP阶段出现了什么问题 在SP 发布之前是否得到了解决

lishixinzhi/Article/program/SQLServer/201311/22488

数据库复制和镜像都是一种数据库恢复技术，即为了避免因一些突发情况，导致数据库崩溃或数据库中数据丢失

其实要问这两个名词区别的话，那么，数据库的镜像是由数据库复制而来的，复制是一个过程，镜像是一种结果，就像照相一样，“照相”是过程，“照片”是一种结果，而最终的目的就是把这一幕记录下来而已，呵呵，有点远了

数据库的镜像就是为了以后恢复数据库。。。

另外，如果深入讨论数据库镜像的话，就要说到并发 *** 作了，也就是对数据库的一些 *** 作，不仅可以在原数据库上，还可以在原数据库很“忙”的时候（被多人访问），先对其镜像 *** 作，提高效率

都是自己的语言说的，希望可以帮你o(∩_∩)o

我们首先来看一下什么是数据镜像： 现在几乎所有的应用系统都是基于数据库的，那么数据库的负荷是比较大的，在一天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集群： 实验到此结束! 本文出自 “杜飞” 博客

为了将停机时间减到最少 您很可能必须使用日志传送 除非您的数据库相当小并且在一段时间内没有用户建立连接 在移交之前 您都可以正确执行日志传送 接着 删除这些用户 剪切并传送最后的日志 然后指向新实例上的应用程序 (有关感兴趣的日志传送替代方法 请参阅下面的数据库镜像部分 )如果使用DNS别名 您甚至可能不需要指向新实例上的应用程序 而是只需更新 DNS 别名 这种方法的优点是 如果您的迁移只进行了一部分 但必须要回退到原始状态 那您至少还有原始文件

您还可以采用一种成本较低的方案 但需要您做更多的预先规划 一个群集可以支持多个SQL Server实例 但每个实例必须有其自己的磁盘资源 因此 在划分SAN时 请留出一个LUN 以备将来升级 要执行升级 请在此磁盘资源上安装 SQL Server 二进制文件 您可以演习一下该系统 当您准备好后 关闭当前SQL Server 将磁盘资源从旧的 SQL Server组中移出 更新依赖关系 然后使新SQL Server实例在线 连接旧实例中的数据库 然后启动并运行 (您已提早备份了所有数据 对吗)

这就是成本较低的方法 实行这个方法需要承担一些风险 如果出现故障 您无法将数据库与新实例分离开来并放回原来位置 您的 *** 作已简化为从备份恢复 这意味着需要很长的停机时间

还有一种方法是将两个SQL Server实例都放在您的SAN中 前提是您有足够的磁盘空间 将生产备份(和日志传送)恢复为新实例 然后按前面介绍的步骤继续进行 但现在您有退路了 而且 一旦完成迁移 您还可以释放旧实例占用的SAN资源 您只需增加额外的磁盘

负载平衡

让我们首先揭穿这样一个常见误解 MSCS群集是用于获得高可用性的 而非用于实现负载平衡 此外 SQL Server没有任何内置的 自动负载平衡功能 您必须通过应用程序的物理设计来实现负载平衡 这意味着什么

随着表的逐渐增长 您可能会预料到性能会降低 特别是在涉及到表扫描 *** 作时 当行数达到数百万或数十亿时 传统的解决方案会使用已分区视图 这种视图由若干具有相同结构 使用 union ALL 挂接在一起的表组成 此外 还会在适当位置放置 CHECK 约束来区分这些成员表 而这会阻止跨已分区视图复制数据 如果在 CHECK 约束中使用的列也是主键的一部分 则该视图是可更新的

如果成员表在其自己的文件组中 则如果这些文件组中的文件分别位于不同的物理驱动器上 那么您会获得更佳的磁盘性能 这些表甚至也可以位于不同的数据库中 但是 在SQL Server 中 只要所有数据均在同一个数据库中 您就可以使用表分区 而表分区实现起来就容易得多了

但是 假设您已经尽可能地利用了表分区或(本地)已分区视图 但性能仍然很低 如果您拥有SQL Server 或SQL Server 就可以利用分布式已分区视图了 主要差别在于 成员表可以位于不同的 SQL Server 实例上 而且这些实例可以安装在 N+ 群集上 为什么鼓励您这样做如果已分区视图中的任何一个成员表转入离线状态 则整个视图也将转入离线状态 使这些成员成为群集的一部分可以为您提供支持性能和实现负载平衡所需的可靠性

您真的需要群集吗

或许您有一些备用服务器无事可做 但这些服务器不在 Windows 目录的群集部分中 如果您在这些服务器可用的情况下 只是为了支持群集就必须出去购置新服务器 那么这是一种浪费可耻的行为

数据库镜像可能是最适合替代群集的一种方法 镜像涉及到三个元素 存储镜像数据库的实例称为主体;备份服务器称为镜像;如果要实现自动故障转移 还需要第三台服务器 称为见证方 简而言之 主体上的数据库中的事务会在镜像中再次运行 当主体出现故障时 如果有见证方 数据库会自动故障转移到镜像 您必须为每个应用程序数据库设置镜像 但不能镜像系统数据库

镜像是单独的SQL Server 实例 与群集不同的是 镜像可以位于几千英里以外 其高速缓存中填充的是由于从主体中复制事务而发生的更新活动 当然 还可以假设 除了从主体接收镜像事务之外 镜像上没有其他活动 既然 SQL Server 已经在镜像中运行 所以 故障转移的速度通常要比在群集中快 由于至少有部分高速缓存已准备好 所以 初始性能并不像在群集方案中那样低 另请注意 当镜像数据库发生故障转移时 主体和镜像会互换角色

数据库镜像的不足之处是 需要的总磁盘容量是群集的两倍 如果您想在同步模式下运行且不想丢失任何数据 那么您还会需要更多的 CPU 处理能力 正如我所说的 要想实现高可用性 需要花费很高的成本

组合方法

由于镜像与主体之间的距离可以相当遥远 所以对于灾难恢复 (DR) 计划来说 选择镜像是非常明智的 群集是您的第一道防线 但是 如果您要同时利用群集和镜像 那会出现什么情况呢在群集故障转移中 如果您的镜像配置中有见证方 则当群集 SQL Server 转入在线状态时 镜像会成为主体 但是 请注意 从新主体回到(群集的)新镜像的故障转移不是自动进行的 因此 当与群集结合使用时 最好不要对您的镜像数据库启用自动故障转移

灾难恢复并不是您使用镜像的唯一原因;当您必须向主体应用服务包或修补程序时 镜像也是非常有用的 在这种情况下 您可以手动故障转移到镜像 在应用服务包或修补程序时 旧的主体服务器暂时处于离线状态 在新主体上发生的已提交事务会排队等候 等待被发送回新镜像(旧主体) 在完成服务包或修补程序的安装之后将会进行同步 最终 这两台服务器将完全处于同步状态 现在您便可以在主体和镜像之间转换角色了 故障转移与恢复只需要几秒钟的停机时间 您可以使用这种方法将 SQL Server 迁移到另一台计算机 只是不能实现故障恢复

虚拟服务器添加灵活性

虚拟化允许您在一台物理服务器上并行运行一个或多个 *** 作系统 虚拟化软件为群集概念添加了另外一层功能 因为您可以将软件加入群集 因此 如果主机正在其上运行的服务器出现故障 则主机及其来宾 OS 会故障转移到备份节点 这可能是迁移来宾服务器的最简便方法 补充一点 来宾 OS 不必具有群集功能 因此 您可以在运行于某群集中的 Microsoft Virtual Server 之上的来宾 Windows Server 内部运行 SQL Server Workgroup Edition 实质上 您会间接拥有群集 Workgroup Edition

在控制之下

如果您在负责 SQL Server 实现 您需要确信您的服务器始终处于可用状态 服务器群集会帮助确保您的服务器始终可用 本文提供了一些来之不易的技巧 以帮助您入门 您可以在 群集资源 边栏中找到更多有用信息

lishixinzhi/Article/program/SQLServer/201311/22476

以上就是关于sql server2012数据库镜像首先运行的是哪个数据库全部的内容，包括:sql server2012数据库镜像首先运行的是哪个数据库、SQL Server 2005 SP1的新特性、数据库复制和镜像有何作用等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！