简单而快速地搞定 SQL Server 高可用（下篇）

内容导航：

简单而快速地搞定 SQL Server 高可用（下篇）

SQLServer2008的可用性和性能解决有什么办法

SQL Server2005高可用性还有哪些不足

如何快速掌握SQL Server中的日志转移

一、简单而快速地搞定 SQL Server 高可用（下篇）

网管小贾 / sysadm.cc

可能有人会说，你这一篇文章硬给扯成了三篇，这是写章回小说呢？

我感觉有点好笑。

老子道德经有云：上士闻道勤而行之。

我整个安装调试前前后后花了我一个多星期，期间还要抓图带注释记录，另外还得把踩的坑给记录下来，并找到填坑的方法。

这么费时费力、吃力不讨好的事儿我一直在干，你觉得我会和这种人计较吗？

当然了，我也只是个普通人，所以请允许我在此发发牢骚。

同时也让我继续写下去，好给那些真心求学和求进步的小伙伴们解疑释惑。

上一篇我们说到哪儿了？

没错，前面的准备工作已经完备，只欠东风了！

我们在此先回顾一下各节点服务器的信息列表。

A89230 192.168.89.230 SQL Server 节点一（主）A89231 192.168.89.231 SQL Server 节点二（辅）A89219 192.168.89.219 文件共享服务器（共享见证）A89220 192.168.89.220 AD 服务器（域名服务器）域名：sysadm.localMSSql_Cluster 192.168.89.232 群集名称（虚拟 IP 地址）MSSql_Listener 192.168.89.233 SQL Server Always On 可用性组侦听器（虚拟 IP 地址）

创建 SQL Server 的 Always On 可用性组

操作对象：主节点服务器（A89230）

所谓可用性组，就是一组节点服务器，将这些节点服务器放在一起形成一个组，即是可用性组。

在正式开始之前，我们需要备份一下数据库，因为在创建可用性组时，备份数据库是先决条件之一。

备份数据库很简单，你以前怎么备份的就怎么备份，没有什么特殊的。

备份完成后，就可以开始创建可用性组了。

左侧导航栏内展开 Always On 高可用性 ，右击 可用性组 ，选择 新建可用性组向导(N)... 。

填入你喜欢的可用性组名称（比如：MSSql_Cluster ），并将下方两项打上勾。

选择你需要赋予高可用功能的数据库，并确保其状态满足先决条件（比如已备份）。

这个数据库可以是新建的，也可以是已有导入的，并且可以选择多个。

此外要切记，副节点上不能有相同名字的数据库存在。

在 副本 选项卡中，点击 添加副本(A)... ，添加其他服务器实例副本。

之后勾选上 自动故障转移 一栏，并确保 可用性模式 为同步提交，同时 可读辅助副本 选择 是 。

在 备份首选项 选项卡中，选择 任意副本 。

这个任意副本的意思，就是当任意节点故障后，其他正常的节点就可以接管并提供正常的服务。

谁正常谁就是主节点，各节点的地位是平等的，后期恢复故障的节点将成为辅助副本。

在 侦听器 选项卡中，选择 创建可用性组侦听器(C) ，并填写侦听器 DNS 名称及端口，同时设定为静态IP地址。

正如前两篇中所说，这个名称也是 DNS 名称，也是要能解析到正确的 IP 地址才行的。

比如本例中，侦听器名称为 MSSql_Listener ，端口 1433 ，IP地址 192.168.89.233 。

数据同步首选项，选择 完整的数据库和日志备份 ，并指定之前的共享文件夹路径。

比如：\A89219\ClusterSharing 。

完成一系列校验、连接，直至创建成功完成。

效果测试

全部都做完了，让我们先来简单整理总结一下前面的内容，这对我们测试会有帮助。

我的做法如下，小伙伴们可以参考也可以自行测试。

首先，我们需要 Ping 得通侦听器的域名或IP，比如本例的 MSSql_Listener.sysadm.local 或 192.168.89.233 。

其次，使用 SSMS 可以正常连接到侦听器，并可以正常操作数据库或执行一些 SQL 语句。

再次，关闭任意一台节点服务器，SQL 服务连接虽然会出现短时间的抖动，但很快就会恢复正常访问。

最后，开启刚才关闭的节点服务器，待完全开启后，再关闭另一节点服务器，观察服务抖动与连接情况。

反复多次，最终验证其可靠性。

踩到的坑，含着泪也要自己填上

要说好运不可能天天有，但坑总是能赶上几个的，哈哈！

所以说，踩坑才是人生真谛，而能把坑给填上也算是牛人不是？

坑一：正在检查托管次要副本 XXX 的服务器实例上是否已存在所选数据库。

填坑：删除副本服务器上的相应数据库。

坑二：可用性组侦听器 XXX 的创建失败。

填坑：手动在 etc/hosts 文件中追加侦听器的域名解析，或通过追加主机域名后缀来解决。

比如：

192.168.89.233 MSSql_Listener192.168.89.233 MSSql_Listener.sysadm.local

坑三：最后一步一直停留在“正在将 XXX 联接到 XXX 上的可用性组 XXX ” 。

填坑：通常是因为非域环境下无法成功进行 DNS 解析，故节点之间无法正常通讯，建议追加使用 DNS 后缀，比如 host.domain.local 。

在 计算机名/域更改 中点击 其他(M)... ，然后在 此计算机的主DNS后缀(P) 中填入相应域名。

在 高级 TCP/IP 设置 中设定 此连接的 DNS 后缀(S) 为自己刚才设定的域名后缀，比如：sysadm.local 。

最后别忘记最好在 etc\hosts 文件中追加域名解析记录。

192.168.89.233 MSSql_Listener.sysadm.local

坑四：操作系统找不到已输入的环境选项，提示错误代码 0x800700cb 。

填坑：导致这个问题的原因还是 DNS 解析不正常。

通常在非域环境下，只有一个主机名就会导致这个问题的发生，即使主动做了 IP 地址指向也无济于事，所以可以参考前面的坑给加个域名后缀即可。

坑五：消息 41105：无法创建名称和类型为“SQL Server 可用性组”的 Windows Server 故障转移群集 (WSFC) 资源

填坑：这个问题挺让人无语的，原因是系统认为你没有设定好 Windows 故障转移群集，所以就不能开启 Always On 可用性组。

这就是在开玩笑了，我明明已经创建好群集了对吧。

好吧，处理方法也很简单，只要打开 SQL Server 配置管理器 ，在 SQL 服务属性的 启用 Always On 可用性组 选项卡中，将那个勾去掉、确定，然后重新给勾上、确定，最后重启服务即可。

总结

有不少小伙伴会将两台或多台节点服务器做成虚拟机形式，但却跑在了同一台物理机上。

我个人感觉这样并不能达到真正意义上的高可用，因为物理机一旦出现问题，虚拟机再多也是要挂的。

所以最佳做法，即使是跑虚拟机，也应该是建立在不同物理机的基础上来实现高可用，这样比较好。

本文分前后共分三篇，内容较长，适合菜鸟小白反复阅读。

同时也可能我踩的坑不算多，欢迎小伙伴们有踩到不一样坑的情况讨论区中留言讨论。

好了，别忘记你们最后还有一件非常重要的事要做，那就是关注我、一键三连！

网管小贾 / sysadm.cc

一、SQLServer2008的可用性和性能解决有什么办法

服务器有4G内存，内存采用动态分配，最小值为746M，最大值为2002M，为SQLServer保留物理内存，最小查询内存设为1024(KB)(M),
可是常常出现查询速度慢，常常很久没有显示结果，查看任务管理器，SQL占用的内存达到1.7G，
在SQL管理查看当前活动的进程，尽是一片红色，死锁怎么那么容易出现呢？配置哪里出错了，
有经验的请指点下，如果能有效解决问题再加分
SQL Server2008版本很多，根据我们的需求，选择的SQL Server2008版本也各不相同，而根据应用程序的需要，安装要求亦会有所不同。

不同版本的 SQL Server 能够满足单位和个人独特的性能、运行时以及价格要求。安装哪些 SQL Server 组件还取决于您的具体需要。下面的部分将帮助您了解如何在SQL Server2008的不同版本和可用组件中做出最佳选择。

SQL Server 2008 的服务器版本下表介绍SQL Server2008的各个服务器SQL Server2008版本版本：

术语 定义
Enterprise（x86、x64 和 IA64）1
SQL Server Enterprise 是一种综合的数据平台，可以为运行安全的业务关键应用程序提供企业级可扩展性、性能、高可用性和高级商业智能功能。有关详细信息，请参阅 SQL Server 2008 各个版本支持的功能。

Standard（x86 和 x64）
SQL Server Standard 是一个提供易用性和可管理性的完整数据平台。它的内置业务智能功能可用于运行部门应用程序。有关详细信息，请参阅 SQL Server 2008 各个版本支持的功能。

SQL Server Standard for Small Business 包含 SQL Server Standard 的所有技术组件和功能，可以在拥有 75 台或更少计算机的小型企业环境中运行。

1目前可以使用的 Enterprise 是可试用 180 天的 SQL Server 2008 Enterprise Evaluation。有关详细信息，请参阅 SQL Server 网站。
SQL Server 2008 专业版SQL Server 2008 专业版是针对特定的用户群体而设计的。下表介绍 SQL Server 2008 的各个专业版。

术语 定义
SQL Server 2008 Developer（x86、x64 和 IA64）
SQL Server 2008 Developer 支持开发人员构建基于 SQL Server 的任一种类型的应用程序。它包括 SQL Server 2008 Enterprise 的所有功能，但有许可限制，只能用作开发和测试系统，而不能用作生产服务器。SQL Server 2008 Developer 是构建和测试应用程序的人员的理想之选。可以升级 SQL Server 2008 Developer 以将其用于生产用途。

工作组（x86 和 x64）
SQL Server Workgroup 是运行分支位置数据库的理想选择，它提供一个可靠的数据管理和报告平台，其中包括安全的远程同步和管理功能。

Web（x86、x64）
对于为从小规模至大规模 Web 资产提供可扩展性和可管理性功能的 Web 宿主和网站来说，SQL Server 2008 Web 是一项总拥有成本较低的选择。

SQL Server Express（x86 和 x64）

SQL Server Express with Tools（x86 和 x64）

SQL Server Express with Advanced Services（x86 和 x64）
SQL Server Express 数据库平台基于 SQL Server 2008。它也可用于替换 Microsoft Desktop Engine (MSDE)。SQL Server Express 与 Visual Studio 集成，从而开发人员可以轻松开发功能丰富、存储安全且部署快速的数据驱动应用程序。

SQL Server Express 免费提供，且可以由 ISV 再次分发（视协议而定）。SQL Server Express 是学习和构建桌面及小型服务器应用程序的理想选择，也是独立软件供应商、非专业开发人员和热衷于构建客户端应用程序的人员的最佳选择。如果您需要使用更高级的数据库功能，则可以将 SQL Server Express 无缝升级到更复杂的 SQL Server 版本。

Compact 3.5 SP1 (x86)

Compact 3.1 (x86)
SQL Server Compact 3.5 免费提供，是生成用于基于各种 Windows 平台的移动设备、桌面和 Web 客户端的独立和偶尔连接的应用程序的嵌入式数据库理想选择。

有关 SQL Server 2008 各个专业版的详细信息，请参阅 SQL Server 网站。

二、SQL Server2005高可用性还有哪些不足

在高可用方面SQL Server供给了一系列高端支持能力，并对复制和快照技巧作了增强。但由于SQL Server几乎完全基于Windows平台，因此在HA方面还存在诸多不足：
　　1. Failover Cluster是大型企业实施SQL Server HA的关键技巧，该技巧基于微软的MSCS（Microsoft Cluster Service），虽然在05版本中供给更方便的安装和多至8节点（企业版）的支持，但在SCSI和光线通道产品的支持上相对比较“挑剔”，尤其对于一些高端的共享裸设备虽然可以支持，但调整不够自由；
　　2. Database Mirroring在保持持续联机可用方面作了很好的补充。不过从05版本看，还需要大力完善，包括供给更丰厚的镜像过程动态性能信息、并为高端HA应用供给更简便的镜像数据验证功能；
　　3. 作为一个异步HA机制，Log Shipping供给了一个相廉价而且定制空间较大的HA方式，但配置和管理相对繁杂，尤其在几个数据中心间跨库传播的管理成本相对较大；

三、如何快速掌握SQL Server中的日志转移

如何快速掌握SQL Server中的日志转移

　　集群是一种实现高可用性的有效解决方案，有时它会适得其反。而且，它还非常昂贵。因此，数据库管理员可使用日志转移代替集群来提供较高的可用性。

　　日志转移是这样一种处理过程，它能将某一数据库中的事务日志文件依次转存到备份的数据库中，进而为这一数据库创建一个“近乎”热备份。SQL Server 2000的数据库引擎中设置了日志转移功能，并在其中进行处理。所以它会自动完成复原到备份服务器的进程，而不需要数据库管理员手动操作。只有你的产品服务器操作失败，你才需手动完成到备份服务器的复原进程。(注释：尽管SQL Server 7.0和2005中均有日志转移功能，但本文主要针对SQL Server 2000。)

　　为什么要使用日志转移?

　　日志转移是一种解决高可用性的措施，并且十分有效。同样作为高可用性的措施方案，日志转移相对集群来说，最大的.好处是它要便宜许多。这是因为，使用集群功能有硬件要求，而日志转移则不需要。

　　日志转移在数据库与数据库而非服务器与服务器之间进行;因此才有可能将备份数据库存储在你已用作其他用途的服务器上。但如果转移失败则有可能会出现问题，这时你可换用备份数据库，这种选择是可用的。

　　日志转移相对比较容易安装。SQL Server提供了非常完善的向导帮助你安装这个进程。

　　日志转移允许你保存分布在不同地理位置中的冗余数据，SQL Server的集群功能则很难做到这一点。这一特点十分出众，因为，当你的数据中心遭到灾难时，你仍能在备份服务器中将其恢复过来。而在相同的数据中心，如果你使用的是集群功能，你就会陷入麻烦。

　　日志转移的另一优点是你能将备份数据库作为报告数据库使用，这对许多公司来说是很不错的选择。但如果你决定了用这个备份数据库作报告使用，就必须注意它的局限性。使用原始数据库中的日志时，SQL Server 要求指定唯一的通道，所以，当日志文件正在被应用时，报告则不能同时进行。

　　使用日志转移要考虑的相关因素

　　在将日志转移作为高可用性的方案来使用时，我们必须考虑以下几点因素。由于从原始数据库到备份数据库有一个潜伏期，对你的公司而言，它并非一定是可行的实现高可用性的一种解决方案。潜伏期由数据库管理员设置，时间也因需要而缩短, 但永远不能避免。

　　日志转移中没有设置恢复功能，这就意味着在将日志转移到备份服务器上时，这些日志都暂时不可用。因此，数据库管理员必须在将备份数据库放到网上前完成一系列的操作，这些步骤包括:

　　将已存储在备份数据服务器上原始数据库里的备份标签存储起来。一旦所有的标签被存储后，数据库就必须得到恢复，然后放到网上。

　　一旦所有的数据库都已放在网上，所有需要访问数据库的应用程序就需要改变自身的链接。如果你不能将应用程序尽快指向刚刚恢复的数据库，你就前功尽弃了。

　　一个SQL Server的实例能用于监控日志转移。这个实例可以在原始数据库、备份数据库或单独的数据库中。任何一种版本的SQL Server都能用于SQL Server监控。

　　注释：数据库登录必须在原始数据库与备份数据库之间同时进行。

;