Questions tagged «availability-groups»

可用性组是SQL Server 2012的一项新功能，可为一个或多个SQL Server数据库提供连续的数据同步，自动故障转移和辅助读取访问。

4
群集，事务复制与可用性组
假设您需要确保依赖于SQL Server 2012的应用程序全天候可用，因为它的数据库后端即使一台服务器计算机出现故障也是如此。 作为开发人员而不是DBA，我努力了解何时使用哪种方案进行故障转移/高可用性： Windows故障转移群集中的两台（或更多）服务器，SQL Server作为群集实例 两个（或多个）SQL Server实例与事务复制保持最新 SQL Server可用性组中的两个（或更多）SQL Server，以同步提交模式配置 这些方案中的每个方案都适合哪种工作负载，这些方案可以处理哪种故障/停机？它们是否具有可比性/可互换性？
8
SQL Server代理作业和可用性组
我正在寻找在SQL Server 2012可用性组中处理计划的SQL Server代理作业的最佳实践。也许我错过了一些东西，但是在当前状态下，我觉得SQL Server Agent并没有真正与这一出色的SQL2012功能集成在一起。 如何使计划的SQL代理作业知道节点切换？例如，我有一个在主节点上运行的作业，该作业每小时加载一次数据。现在，如果主服务器出现故障，我如何激活现在成为主服务器的辅助服务器上的作业？ 如果我将作业始终安排在辅助服务器上，则它将失败，因为辅助服务器是只读的。
5
从DMV中，您能否确定连接是否使用了ApplicationIntent = ReadOnly？
我设置了一个Always On可用性组，我想确保我的用户在其连接字符串中使用ApplicationIntent = ReadOnly。 从SQL Server通过DMV（或扩展事件或其他），我能否确定用户的连接字符串中是否与ApplicationIntent = ReadOnly连接？ 请不要回答如何防止连接-这不是这个问题。我不能简单地停止连接，因为我们现有的应用程序在连接时没有正确的字符串，我需要知道它们是哪个，以便我与开发人员和用户一起逐步解决问题。 假设用户有多个应用程序。例如，鲍勃与SQL Server Management Studio和Excel连接。当他需要更新时，他与SSMS连接；当他需要读取时，他与Excel连接。我需要确保他与Excel连接时正在使用ApplicationIntent = ReadOnly。（这不是确切的情况，但是足够接近以说明问题。）
3
服务器重新启动后，SQL Server分布式可用性组数据库未同步
我们已经准备好在SQL Server上执行大型升级，并注意到我正在尝试解决的Distributed Availability Groups的一些异常行为，然后再进行下一步。 上个月，我将远程辅助服务器从SQL Server 2016升级到SQL Server2017。该服务器是多个分布式可用性组（DAG）和单独的可用性组（AG）的一部分。升级该服务器时，我们没有意识到它会进入无法读取的状态，因此在过去的一个月中，我们仅依赖主服务器。 作为即将进行的升级的一部分，我将CU 4修补程序应用于服务器并重新启动了它。当服务器重新联机时，刚刚打补丁的辅助服务器显示所有DAG / AG都在同步，没有任何问题。 但是，小学的故事却截然不同。据报道 单独的AG正在同步，没有任何问题 但是DAG处于“ 不同步/不正常”状态 最初出现恐慌之后，我尝试了以下操作以使DAG中的内容再次同步： 从主服务器开始，我停止并恢复了数据移动。这没有开始同步数据。 在第二个（我刚刚打过补丁的）上，我运行了ALTER DATABASE [<database] SET HADR RESUME;-执行时没有错误，但是没有恢复任何同步 我最后一次再次同步数据的尝试是登录到辅助数据库，然后手动重新启动SQL Server服务。手动重新启动服务似乎有些极端，因为我希望重新启动服务器就足够了。 是否有人遇到过重启后DAG无法开始同步到辅助服务器的问题？如果是这样，如何解决？ 我同时检查了SQL Server错误日志和辅助服务器上的事件查看器，没有发现异常。
2
具有500个数据库的SQL Server 2017-自CU9起频繁的AG断开连接
大家好，在此先感谢您的帮助。SQL Server 2017可用性组面临挑战。 背景 公司是零售B2B后端软件。大约500个单租户数据库，以及所有租户使用的5个共享数据库。工作负载特征读取最多，大多数数据库的活动很少。 托管在同一地点的物理生产服务器最近从Windows Server 2012上的SQL Server 2014 Enterprise在共享SAN / FCI配置中升级到Windows Server 2016上的SQL Server 2017 Enterprise（2插槽/ 32核/ 768 GB RAM和本地）使用AlwaysOn AG的SSD驱动器。AG业务使用带交叉电缆连接的专用10G NIC端口。 他们的要求是所有数据库都一起进行故障转移，因此他们不得不将它们全部放在一个AG中。它是同一服务器上的单个不可读取的同步副本。 新服务器已于2018年6月投入生产。安装了最新的CU（当时为CU7）和Windows更新，并且系统运行良好。大约一个月后，在将服务器从CU7更新到CU9之后，他们开始注意到以下挑战，按优先顺序列出。 我们一直在使用SQL Sentry监视服务器，没有发现物理瓶颈。所有关键指标似乎都不错。CPU平均为20％，IO时间通常小于1ms，RAM未被充分利用，并且网络<1％。 挑战性 故障转移后，症状似乎会好转，但几天后又回来了，不管哪个服务器是主要服务器-两个服务器上的症状都相同。 零星的客户端超时和连接故障，例如 建立连接时发生错误 要么 执行超时已过期 有时这些会持续40秒钟，然后消失。 事务日志备份作业完成的时间比以前长10倍。以前备份所有500个数据库的日志需要2到3分钟，现在备份需要15到25分钟。我们已经验证了备份本身可以很好地运行并具有良好的吞吐量。但是，在完成一个日志的备份之后和启动下一个日志之前会有一个小的延迟。它开始时非常低，但是在一两天内会达到2-3秒。乘以500个数据库，便有区别。 有时，一些看似随机的数据库在手动故障转移后会陷入“未同步”状态。解决此问题的唯一方法是在辅助副本上重新启动SQL Server服务，或者将这些数据库删除并重新加入AG。 CU10引入的另一个问题（在CU11中未解决）：在master.sys.databases上阻塞时，辅助超时的连接，甚至无法将SSMS对象资源管理器用于辅助副本。根本原因似乎是由Microsoft SQL Server VSS编写器发出以下查询阻止的： select name, recovery_model_desc, state_desc, CONVERT(integer, is_in_standby), ISNULL(source_database_id,0) from …
4
RAID0代替RAID1或5，这很疯狂吗？
我正在考虑为我们的一个SQL Server群集使用RAID0设置。我将概述情况，并在寻找为什么这可能不是一个好主意。同样，如果您有用例，白皮书或其他文档的人，您可以在这个主题上向我指出，那就太好了。 我们在2个数据中心中有3台服务器，它们是SQL群集的一部分。它们都在可用性组中运行SQL Server。主数据库旁边有一个副本，另一个数据库中有另一个副本。他们正在运行具有自动故障转移功能的同步复制。所有驱动器均为企业级SSD。他们将运行SQL Server 2017或2019。 我认为与其他方法相比，在RAID0阵列上运行它们会带来多种好处，并且几乎没有真正的缺点。我目前看到的唯一负面消息是主服务器上缺乏冗余，因此失败率增加了。作为专家： 如果驱动器发生故障，而不是一直运行到慢速，降级的状态，直到有人收到手动操作的通知，服务器将立即失败，导致辅助服务器保持完整的操作能力。通知我们有关故障转移的更多好处，因此我们可以更快地调查原因。 它减少了每TB容量整体发生故障的机会。由于不需要奇偶校验或镜像驱动器，因此减少了每个阵列的驱动器数量。使用更少的驱动器，发生驱动器故障的机会就更少了。 这更便宜。需要更少的驱动器以达到我们所需的容量显然会降低成本。 我知道这不是传统的商业思想，但是我有没有在考虑什么呢？我会喜欢任何赞成或反对的意见。 我并不想这样做，以提高查询性能，但是如果有有意义的建议，请随时指出。我最关心的是无法考虑或解决我从未想到的可靠性或冗余性问题。 操作系统位于单独的镜像驱动器上，因此服务器本身应处于启动状态。这些驱动器之一可以更换并再次镜像。它很小，除了系统DB之外没有任何数据库文件。我无法想象这需要花费几分钟的时间。如果其中一个数据阵列发生故障，我们将更换驱动器，重建阵列，还原并与AG重新同步。以我个人的经验，恢复比RAID5驱动器重建快得多。我从来没有遇到过RAID1故障，所以我不知道该重建是否会更快。还原将来自备份，并前滚以匹配主数据库，因此，仅将最后几分钟的日志与恢复的副本同步，主服务器上的负载增加应该非常小。
1
AlwaysOn AG，具有故障转移功能的DTC
问题：如何在AlwaysOn可用性组（AG）中的所有服务器上运行分布式事务处理协调器（DTC）？我不需要通过故障转移/切换事件来维护事务。 设置：我有一个Windows故障转移群集（WSFC），其中包含三台都运行SQL 2012的Windows 2008 R2服务器。两台服务器位于一个数据中心，是AlwaysOn故障转移群集（FCI）的一部分，而第三台服务器在第二个数据中心。WSFC是一个多子网群集。这是设置的草图： 我已经能够安装和配置DTC，使其在两个FCI节点之间工作，因为它们位于同一子网中并共享存储。我已经配置了几个AG，它们运行良好。此屏幕快照显示了在FCI上安装的DTC： 此屏幕快照显示，我可以在一个FCI节点（无论哪个处于活动状态）上配置DTC： 我想将使用DTC的应用程序迁移到该群集上并使用AG。我读过AG不支持DTC（参考）。我还没有找到在第二个数据中心的第三个节点上配置DTC的方法。当我尝试在第三个节点上配置DTC时，它似乎不可用，如以下屏幕截图所示： 在Brent Ozar的可用性组的免费安装清单PDF中，他列出了： 群集安装... 29.如果涉及FCI，请根据您的“计划”部分的决定配置DTC。 在对SQL Server 2012 AlwaysOn可用性组的评论中，Rock Brent说：“ ...当AG发挥作用时，没有任何变化。请记住，可用性组中的数据库在一起故障转移到另一个副本时不支持事务一致性。 ..” 这使DTC似乎可以在可用性组中使用，只要您了解到事务不会在AG切换中维护。我不需要它来维护来自FCI节点的事务。在灾难性灾难（我丢失了主数据中心）的情况下，我只需要DTC可供应用程序使用即可。 如何在第三个节点上配置DTC？还是在使用AG和需要DTC的应用程序时我不走运？ 更新：我确定的解决方案是使用日志传送。但是，在故障转移的情况下，我仍然需要DTC在Node3上可用。我发现通过卸载在Node1和Node2之间共享的DTC的群集MSDTC-MSSQLSERVERCLU实例，它变得可用。删除后，我可以在Node3上设置和配置LocalDTC实例。之后，我可以重新安装群集的MSDTC-MSSQLSERVERCLU实例。按此顺序执行安装顺序似乎可行。我已经像这样跑了一段时间了，而且还没有发现任何不良影响。似乎这对于运行AlwaysOn可用性组也将起作用。我了解到分布式事务不会在AG故障转移中保留，我只需要新事务即可在故障转移后工作。但是我还没有
1
强制性的可读二级计划
如果计划是针对可用性组中的主数据库执行的，则该计划是否适用于在辅助数据库上运行的查询？ 我正在寻找涵盖计划强制的两种可能性的答案： 计划指南 查询存储强制计划 我阅读了以下内容，这些内容表明QS强制计划不会继续存在，但找不到文档中的权威内容或有关计划指南的任何内容。 Erin Stellato的查询存储和可用性组 在 Vikas Rana的AlwaysOn可读辅助数据库上查询数据存储强制计划行为 强迫的结论性证据将是二级执行计划中存在Use Plan或PlanGuideName和PlanGuideDB属性。
1
高可用性还原SQL Server 2012数据库
我有一个始终处于高可用性模式的数据库，该数据库与另一个实例上的另一个数据库同步。如何使用从.bak文件还原到主数据库T-SQL？ 我是高可用性的新手，并被告知我需要先使数据库脱离高可用性，然后才能进行还原，然后再次将其重新设置为高可用性，但我不确定。 我希望我可以在AlwaysOn仍启用的同时直接还原到主数据库，并且它将与辅助数据库自动同步。
4
登录不会在可用性组之间同步
AlwaysOn组中有2台服务器。 每个同步数据库中的用户帐户都位于两台服务器上，而数据库实例级别的登录仅存在于其中一台服务器上。即一台服务器上缺少DBINSTANCE-> Security-> Logins。 因此，当发生故障转移时，我在第二台服务器上遇到登录失败（该服务器没有相应的实例级别登录名）。 我该如何克服这个问题？我是否应该以特殊方式设置用户帐户？
2
为BULK INSERT配置不受约束的委托
我在Always On可用性组中有一对Microsoft SQL Server 2016节点。我正在尝试对BULK INSERTWindows Server 2016文件服务器故障转移群集上的文件执行（使用SQL Server 2016 Management Studio查询），但是出现以下错误： 消息4861，级别16，状态1 无法批量加载，因为无法打开文件“ \ nas2.my.domain \ Microsoft SQL Server 2016 Enterprise \ test.txt”。操作系统错误代码5（访问被拒绝。）。 无论我使用活动节点名称（nas2.my.domain）还是故障转移群集侦听器（nas.my.domain），都会发生这种情况。 环顾四周后，我发现这是由于SQL Server无法模拟与我连接的用户帐户所致BULK INSERT。 如果使用Windows身份验证连接到SQL Server，则SQL Server服务帐户将在连接到文件服务器时尝试模拟您的用户帐户。如果使用SQL Server身份验证进行连接，它将以SQL Server服务帐户连接到文件服务器。 如果未正确配置委派和模拟（默认状态），则SQL Server服务将无法模拟您的用户帐户，并且将退回尝试以匿名用户身份连接到文件服务器。 可以通过查看文件服务器上的安全事件日志来确认。这些事实以及有关配置不受约束和受约束的委派的指南记录在以下链接中： 如何：约束委派的SQL Server批量插入（访问被拒绝） 批量插入和Kerberos 我已经尝试按照thesqldude指南中的说明进行操作，但是仍然无法正常工作。 我尝试访问的数据库BULK INSERT不是可用性组的一部分，因此只有MSSQL1节点才有意义。文件服务器在NAS2节点上处于活动状态。检查文件服务器上的事件日志确实表明它仍然遇到此问题，并且SQL Server尝试以匿名用户身份验证文件服务器，而不是模拟我的用户帐户。 有人知道出什么事了吗？还是为了使这些指南过时而在SQL Server 2016中进行了某些更改？ 文件服务器安全事件日志条目 服务帐户委托 服务帐户SPN SQL …
3
可用性组数据库卡在“不同步/恢复挂起”模式下
在SQL Server 2014 SP1（12.0.4422.0）实例中升级存储时，我们遇到了以下问题：重新启动SQL Server后，其中两个数据库无法在辅助数据库上启动。在我们安装新的（更大）SSD并将数据文件复制到新卷中时，服务器已脱机几个小时。当我们重新启动SQL Server时，除两个数据库外，所有其他数据库再次开始同步。另外两个在SSMS中显示为“ 未同步/正在等待恢复”。 之前有类似的“ 不同步/恢复中”问题，我检查了“可用性组”->“可用性数据库”部分下的状态，但是它们显示为红色X： 甚至试图暂停数据移动都会产生错误消息： 无法挂起数据库“ StackExchange.Bycycles.Meta”中的数据移动，该数据库位于可用性组“ SENetwork_AG”中的可用性副本“ ny-sql03”上。（Microsoft.SqlServer.Smo） 附加信息：执行Transact-SQL语句或批处理时发生异常。（Microsoft.SqlServer.ConnectionInfo） 由于文件不可访问或内存或磁盘空间不足，无法打开数据库“ StackExchange.Bycycles.Meta”。有关详细信息，请参见SQL Server错误日志。（Microsoft Sql Server，错误：945） 我检查了文件是否存在，没有任何权限问题。我还检查了管理下SSMS中的SQL Server日志，但是没有看到有关挂起恢复或两个数据库有任何问题的信息。 在寻求帮助的过程中，我找到了两篇不同的文章，说需要还原数据库。 当数据库卡在恢复挂起中时，是否有任何方法可以在辅助数据库上恢复数据复制？
2
SQL Server 2012可用性组是否为“ AlwaysON”？
在传统的SQL Server群集中，当发生故障转移时，连接到SQL Server失败实例的所有客户端都会失去连接，并且每个客户端都必须重新建立与故障转移群集实例的新连接。 AlwaysON可用性组是否可以缓解此问题？如果SQL Server 2012 AlwaysON可用性组的故障转移对连接到SQL Server的客户端透明吗？
2
架构更改会“破坏”可用性组，还是透明处理？
我的组织计划采用SQL Server 2012可用性组，并且我试图了解它将对我们的应用程序升级过程产生什么影响（如果有）。 我们每8周发布一次应用程序更新，任何发布都可能包含架构更改和/或数据迁移。 我想了解的是HA / DR解决方案是否透明地处理架构更改（新列，索引添加到第二级），还是在每个实例上创建架构然后重新打开Always On所需的手动干预。 我假设的数据迁移部分是透明处理的，但也想确认一下。 我想我也在做出一个笼统的假设，即基于可用性组配置的这些行为也没有差异，这可能也是错误的。请告诉我。 简而言之; 在我的应用程序的任何给定发行版中，我都可以通过向表中添加列来更改非常大的表（10s至1亿亿条记录）。一些列可能是“ net new”的，因此它们可以利用企业在线模式更改功能。其他列可能是对现有列的重构（FullName被拆分为FirstName和LastName），并且将对表中的每一行运行迁移以填充这些字段。这些行为是否需要DBA更改AlwaysOn配置，或者默认情况下会进行处理，并且所有辅助节点都“免费”获得DDL和DML语句？ 感谢您的澄清。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.