SQLServer2012setAlwaysOntosolvethesubmissiondelaycausedbynetworkjitter
事件原因：最近的一次研发反应，经过一个数据库从08到12的环境，出现了写操作延迟的问题。事件分析：消除系统资源争用问题后，初步分析可能是由网络抖动造成的，其结果往往是同步的AlwaysOn节点等待时间的承诺。
在调查之后，扩展事件发现经常发生35202错误，这是连接恢复消息的副本。
由于网络环境的复杂性，数据库服务器和应用服务器在业务高峰时使用交换机，由于上行端口流频繁出现连接故障。
由于网络环境不可能在短期内重建，它从SQLServer服务器本身入手，只有改革的数据同步的部分。
现有的环境：
SQL：两个节点的同步模式。两个节点的每个节点都有一个连接到交换机的网卡。没有直接的连接跳线（WSFC不再需要一个独立的心跳网络）。
改革方案：
1个节点和两个节点使网卡可以直接连接通信，并配置私有地址。
复制代码代码如下所示：
server_a：10.0.0.11
server_b：10.0.0.12
2、删除两节点的端点，并手动重新创建listener_ip作为直接IP端点
三.在每个副本的endpoint_url改变银
4，等待数据同步；
剧本的第三步是两个节点上运行，并注意listener_ip是直接连接的网卡的IP。
复制代码代码如下所示：
对象：端点{ hadr_endpoint }脚本日期：2015 / 1 / 6 / ****** 16:06:17 ****** /
滴终点{ hadr_endpoint }
对象：端点{ hadr_endpoint }脚本日期：2015 / 1 / 6 / ****** 16:06:17 ****** /
创建端点hadr_endpoint } {
状态=开始
TCP（listener_port = 5022，listener_ip =（10.0.0.11））
对于data_mirroring（角色=，= Windows认证netiate）
需要alrithm AES）加密=
第四步的脚本后面是主副本。
复制代码代码如下所示：
改变可用性组alwayson01 } {
在n'node_01'with修改副本（endpoint_url = n'tcp： / / 10.0.0.11:5022）
改变可用性组alwayson01 } {
在n'node_02'with修改副本（endpoint_url = n'tcp： / / 10.0.0.12:5022）
注：两份后的终点是不同步的，但在听众和AG组的数据库不受影响。对于应用程序，主副本的服务仍然正常。