我想我是海 冬天的大海 心情随风轻摆

数据库一旦搭建alwayson， 则日志无法用简单日志， 必须采用完整日志。 生产环境的完整日志天长日久会很庞大， 如何处理？在 d 盘下创建 Tools\bat_tools 文件夹1. 创建 backup_log.sql 文件， 脚本如下：use [dbName]declare @bakfile nvarchar(100)--@bakfile备份文件名set @bakfi

由于网络的不稳定等原因，Windows群集服务可能会停止， 如何减少这种可能呢？可以设置相关的参数：但不是长久之计， 最重要的还是根据集群日志， 彻底解决为好。

在这个警告的提示之后，接着有错误提示：Cluster Service 服务因 群集节点的仲裁不存在，无法形成群集。 服务特定错误而停止。修改注册表：[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NlaSvc\Parameters\Internet]EnableActiveProbing值由 1 改为 0 。再

Alwayson 可实现故障转移这个就不用多说了， 不过以前只是将作为高可用的一个备用副本而已。 如果希望客户端在发生故障时能无缝切换到可用的副本， 那就必须用到侦听器。几点总结：一、所有节点（包括侦听器）的端口必须一致：侦听器的IP和端口如下图可以看到：在搭建 alwayson 时， 建议将所有节点（包括侦听器）的 端口调整为同一个， 避免不必要的麻烦。如

SQLServer2014的安装， 谈不上难， 但如果你不把握好， 可能还是安装不上的。首先是软硬件环境。最好看一下：安装 SQL Server 2014 的硬件和软件要求因为要搭建 Alwayson 集群，而不是在自己本机玩玩新特性， 所以需要服务器版本的OS才行。win2003就不要奢望了，最好是2008或者2012。我这里就采用 Windows Server 2008 R2 ...

Windows集群在某些情况下是不稳定的，这容易影响到 alwayson ，导致某些节点使用不正常。我们可以借 powershell 来定时检测， 如果是停止状态则重启集群服务。定时工具我这里选择 SQL Server 的代理服务， 主要是使用比较方便， 比 Windows 计划任务方便一些， 当然， 你用计划任务也行。首先， 将 SQL Server 代理服务的登录改为“本地系统账户”（不这样脚...

环境：均为 Windows Server2008, SQL Server版本为 2014 企业版。Windows群集共有 5 个节点：1. sql12. sql23. h14. h25. websql1(主副本), sql2 有一个alwayson可用性组，无侦听器，异步提交，手动转移;h1(主副本), h2 有一个alwayson可用性组，无侦听器，异步提交，手动转移。web 节点用来充数（实现...

以前一直以为是没有双网卡导致的，后来有个集群全是双网卡， 也有这个问题，所以排除了不是双网卡的原因。后来发现跟虚拟底层系统（ESXi）有关，底层系统连不上硬盘了，虚拟机自然也会有问题了，两者出问题的时间能对上(如下图)。将虚拟机迁移之后，问题解决。

发现故障：主副本数据库显示 “未同步”， 主副本服务器上的集群服务无法启动。数据库已不可使用。在 SSMS 界面， 直接删除可用性组不可行， 改为在 Windows群集中删除应用程序后可以删除可用性组了：再执行RESTORE DATABASE dbName WITH RECOVERY;使数据库可正常使用， 应急。后来认为是 dns 解析不正常， 处理

一个生产库， 使用量不算特别大， 内存 64GB， 数据库 60 GB左右。IO 也非常不错，虽然是虚拟机，但性能很好。版本： SQL Server2014 企业版。 搭建了 Alwayson ， 同步模式、自动故障转移。奇怪的是， 用扩展事件捕获到的慢SQL特别多（但占用CPU很低）， 用户实际使用也比较慢， 连纯插入语句都很慢， 一天产生几万数据量的表插入居然要几秒（无更新和删除，

alwayson的辅助副本无法创建数据库用户， 这点比较致命。 但是否无法创建数据库用户了呢？也不是， 不过只能在主副本创建登录名和数据库用户， 然后在辅助副本上设置相同sid的登录名。具体步骤如下：步骤1：查看主库上该账号的sid 查看语句为：SELECT *FROM [数据库名称]..sysusers步骤2：在副本数据库上创建对应账号。创建语句为：CRE

alwayson 配置侦听器看起来非常简单，实则容易出错：尝试为侦听器创建网络名称和 IP 地址失败.WSFC 服务可能未在运行或在其当前状态原因在于必须先在“故障转移群集管理”-“服务和应用程序”上右键、配置一个“客户端访问点”，并将现有群集脱集，再将现有群集的属性中的依赖项与刚才配置的“客户端访问点”关联。详见：点击打开链接

原文： 点击打开链接msdn 相关内容： 点击打开链接什么是looksalive check和is alive check      SQL Server故障转移集群是建立在windows集群服务上的一种热备的高可用方案。在集群运行过程中，windows集群服务定期检测节点的资源健康状态，如果发生了故障，会根据预先定义的故障转移策略把SQL Server服务从故障节点切换到

作为DBA， 在本机搭建 Alwayson 是非常有必要的。而某些情况下可能需要其它计算机也能连接访问。搭建 Alwayson ， 最少配置也得有3台机：1、域控（DC）： 内存：1GB， 硬盘：30GB （ C：20GB， D：10GB ）2、主副本： 内存：2GB， 硬盘：40GB （ C：25GB， D：15GB ）3、辅助副本： 内存：2GB， 硬盘：40GB （ C：25

原文：点击打开链接之前和很多群友聊天发现对2016的无域和负载均衡满心期待，毕竟可以简单搭建而且可以不适用第三方负载均衡器，SQL自己可以负载了。windows2016已经可以下载使用了，那么这回终于可以揭开令人憧憬向往的AlwaysOn2016 负载均衡集群的神秘面纱了。　　本篇主要描述个人集群搭建中遇到的坑和一些注意事项，以及2016无域负载均衡的简单体验测试。搭建

ALTER DATABASE [axx] SET HADR SUSPEND;GO创建一个job，每个小时执行一次ALTER DATABASE [axx] SET HADR SUSPEND;GOJOB STARTALTER DATABASE [axx] SET HADR RESUME;GOJOB STARTALTER DATABASE [axx] SET HADR SUS

原文： 点击打开链接下面简单介绍一下如何在Ubuntu上一步一步创建一个SQL Server AG（Always On Availability Group），以及配置过程中遇到的坑的填充方法。目前在Linux上可以搭建两种类型的SQL Server AG，一种是高可用性的结构同时使用Cluster服务器提供业务连续性。这种结构包括read-scale节点。接下来就会介绍这种AG的

SELECT [master].sys.fn_hadr_is_primary_replica( DB_NAME() ) AS [是否alwayson主副本], [master].sys.fn_hadr_backup_is_preferred_replica( DB_NAME() ) AS [是否备份首选副本]/*当备份优先级相同时，如何决定备份首选副本？--当备份首选项为“主副本”时，主

alwayson可用性组在主副本那边已被破坏， 看不到了， 但辅助副本这边还有， 却删除不了可用性数据库：ALTER DATABASE [dbName] SET HADR OFF;提示：消息 41121，级别 16，状态 0，第 1 行可用性组“ag”的本地可用性副本在其当前角色“RESOLVING_NORMAL”和状态下(配置为 Windows Server 故障转移群集存储区中

关于同步和异步， 本人总结：1. 无论是同步还是异步， 都会有延迟；2. 同步会保证没有不会丢失数据; 异步则没办法保证，但异步的性能更高一些;3. 同步或异步选择哪个， 看你要安全（同步）还是高性能（异步）；4. 同步或异步， 都要走两个过程：一是日志的固化（Harden, 将日志传过来）， 二是日志的重做（redo,将日志应用到副本）;5. 可能延迟多少秒，没有一个确定

select a.*,c.is_local,c.role_desc,d.endpoint_url,d.read_only_routing_url from sys.dm_hadr_availability_replica_cluster_nodes ajoin sys.dm_hadr_availability_replica_cluster_states bon a.replica_serv...