SQLServer 2012中設置AlwaysOn處理收集發抖招致的提交延遲成績。本站提示廣大學習愛好者：（SQLServer 2012中設置AlwaysOn處理收集發抖招致的提交延遲成績）文章只能為提供參考，不一定能成為您想要的結果。以下是SQLServer 2012中設置AlwaysOn處理收集發抖招致的提交延遲成績正文
事宜原由：近期有研發反響，某數據庫從08切換到12情況後，不按期湧現寫操作提交延遲的成績；
事宜剖析：在消除了體系資本爭用等成績後，初步剖析能夠因為收集發抖招致同步形式alwayson節點常常湧現會話超時期待提交的成績招致。
經由排查，擴大事宜裡發明不按期湧現35202毛病，這是一條正本銜接恢復的新聞。
因為機房收集情況龐雜，數據庫辦事器和運用辦事器混用一個交流機，在營業岑嶺期時，因上聯端口流量打滿而招致銜接掉敗的情形屢有產生。
既然短時間內沒法改革收集情況，那就從SQLSERVER辦事器本身動身，只對數據同步的部門停止改革；
現有情況：
SQL AG：為兩節點的同步形式，兩個節點各有一塊網卡銜接到交流機，沒有直連心跳線（WSFC也不再請求有自力的心跳收集）
改革計劃：
1、兩個節點各啟用一塊網卡，采取直連方法停止通訊，同時設置裝備擺設公有地址
Server_A：10.0.0.11
Server_B：10.0.0.12
2、刪除兩個節點的endpoint，手動從新創立Listener_IP為直連IP的endpoint
3、更改AG中，每一個正本的endpoint_url
4、期待數據從新同步；
個中第三步的劇本以下，要在兩個節點上分離操作，留意Listener_IP為直連網卡的IP
/****** Object: Endpoint [Hadr_endpoint] Script Date: 2015/1/6 16:06:17 ******/
DROP ENDPOINT [Hadr_endpoint]
GO
/****** Object: Endpoint [Hadr_endpoint] Script Date: 2015/1/6 16:06:17 ******/
CREATE ENDPOINT [Hadr_endpoint]
STATE=STARTED
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (10.0.0.11))
FOR DATA_MIRRORING (ROLE = ALL, AUTHENTICATION = WINDOWS NEGOTIATE
, ENCRYPTION = REQUIRED ALGORITHM AES)
GO
第四步的劇本以下，在主正本履行便可
ALTER AVAILABILITY GROUP [Alwayson01]
MODIFY REPLICA ON N'Node_01' WITH (ENDPOINT_URL = N'TCP://10.0.0.11:5022')
ALTER AVAILABILITY GROUP [Alwayson01]
MODIFY REPLICA ON N'Node_02' WITH (ENDPOINT_URL = N'TCP://10.0.0.12:5022')
留意：刪除endpoint後兩正本即為未同步狀況，但偵聽器和AG組中的數據庫不受影響，對運用而言，主正本的辦事依然正常；
