Chúng tôi có hai Máy chủ SQL sản xuất chạy SQL Server 2005 SP4 với bản cập nhật tích lũy 3. Cả hai máy chủ đều chạy trên các máy vật lý giống hệt nhau. DELL PowerEdge R815 với CPU 4 x 12 lõi và ram 512GB (có GB), với các ổ đĩa được kết nối iSCSI SAN 10GB cho tất cả các cơ sở dữ liệu và nhật ký SQL. Hệ điều hành là phiên bản Microsoft Windows Server 2008 R2 Enterprise với tất cả các bản cập nhật SP và windows. Ổ đĩa hệ điều hành là một mảng RAID 5 gồm 3 x 72GB 2,5 "Ổ đĩa 15k SAS. SAN là một Dell EqualLogic 6510 với các ổ 48 x 10K SAS 3.5", được định cấu hình trong RAID 50, được chia thành nhiều LUN khác nhau cho 2 Máy chủ SQL và cũng được chia sẻ với một máy Exchange và một số máy chủ VMWare.
Chúng tôi có hơn 20 cơ sở dữ liệu, 11 trong số đó được nhân đôi với tính sẵn sàng cao bằng cách sử dụng máy chủ chứng kiến. Máy chủ nhân chứng là một máy có công suất thấp hơn chạy phiên bản SQL Server được sử dụng cho mục đích khác ngoài việc cung cấp dịch vụ nhân chứng. Cơ sở dữ liệu nhân đôi lớn nhất là 450GB và tạo ra khoảng 100-300 iops. Trình theo dõi cơ sở dữ liệu báo cáo tốc độ gửi hiện tại khoảng 100kb đến 10mb mỗi giây và một cam kết trên gương là (thường) 0 mili giây. Máy chủ nhân bản không có vấn đề theo kịp hiệu trưởng.
Chúng tôi liên tục gặp thất bại phản ánh. Đôi khi một cơ sở dữ liệu sẽ chuyển đổi dự phòng, lần khác hầu như tất cả các cơ sở dữ liệu sẽ chuyển đổi đồng thời. Chẳng hạn, đêm qua, chúng tôi đã có 10 trong số 11 cơ sở dữ liệu chuyển đổi dự phòng, cơ sở dữ liệu còn lại vẫn có thể truy cập được cho đến khi tôi tự làm hỏng nó.
Tôi đã trải qua một số bước khắc phục sự cố để xác định sự cố, nhưng cho đến nay vẫn chưa thể giải quyết vấn đề:
1) Máy đi kèm với bộ chuyển đổi mạng Gigabit 4 cổng Broadcom BCM5709C NetXtreme II mà ban đầu chúng tôi sử dụng làm kết nối mạng chính. Kể từ đó, chúng tôi đã cài đặt Bộ điều hợp máy chủ cổng kép Intel (R) PRO / 1000 PT trên cả hai máy để loại bỏ vấn đề này.
2) Tất cả các cơ sở dữ liệu đều có bản sao lưu đầy đủ tự động hàng đêm cùng với bản sao lưu nhật ký cho cơ sở dữ liệu liên quan đến phản chiếu. Nhật ký tập tin được theo dõi và hiếm khi được sử dụng trên 15%. Tệp nhật ký cho cơ sở dữ liệu chính là 125GB, bao gồm 159 tệp nhật ký ảo có kích thước từ 511MB đến 1GB. TempDB là LUN của riêng nó và bao gồm các tệp 24 x 2GB.
3) Nhật ký máy chủ SQL trên nhân chứng cho thấy không có lỗi nào khác ngoài: Kết nối phản chiếu tới "TCP: //SQL02.DOMAIN.INET: 5022" đã hết thời gian cho cơ sở dữ liệu "Dữ liệu" sau 30 giây mà không có phản hồi. Kiểm tra các dịch vụ và kết nối mạng.
Nhật ký máy chủ SQL trên máy chủ chính và máy chủ thứ cấp hiển thị các thông báo liên quan đến phản chiếu:
Kết nối phản chiếu tới "TCP: //SQL01.DOMAIN.INET: 5022" đã hết thời gian cho cơ sở dữ liệu "Dữ liệu" sau 30 giây mà không có phản hồi. Kiểm tra các dịch vụ và kết nối mạng.
Cơ sở dữ liệu được nhân đôi "Dữ liệu" đang thay đổi vai trò từ "PRINCIPAL" sang "MIRROR" do Đồng bộ hóa vai trò. (Đồng bộ hóa được viết sai chính tả ở đây vì mục đích chính là cách hiển thị thông báo thực tế.)
Cơ sở dữ liệu được nhân đôi "Dữ liệu" đang thay đổi vai trò từ "PRINCIPAL" sang "MIRROR" do chuyển đổi dự phòng.
Cơ sở dữ liệu được nhân đôi "Dữ liệu" đang thay đổi vai trò từ "MIRROR" sang "PRINCIPAL" do chuyển đổi dự phòng từ đối tác.
Các dịch vụ SQL Server tiếp tục chạy và các kết nối mạng dường như vẫn hoạt động. Chúng tôi luôn có từ 500 đến 2500 phiên được kết nối với mỗi máy chủ (chủ yếu là các ứng dụng robot kết nối với hàng đợi môi giới dịch vụ trên một cơ sở dữ liệu).
4) TCP Chimney và RSS, vv bị vô hiệu hóa bằng cú pháp NET SH.
5) Tôi đã chạy Trình phân tích thực tiễn tốt nhất của SQL Server 2005 đối với cả hai máy và không tìm thấy gì ngoài lỗi Nhật ký sự kiện ứng dụng rất thường xuyên 833, không có trường hợp nào trùng với sự kiện chuyển đổi dự phòng:
SQL Server đã gặp phải 1 lần xuất hiện các yêu cầu I / O mất hơn 15 giây để hoàn thành tệp [F: \ Data.MDF] trong cơ sở dữ liệu [Dữ liệu] (9). Xử lý tệp hệ điều hành là 0x00000000000010A0. Giá trị bù của I / O dài mới nhất là: 0x000007d4b10000).
6) Thỉnh thoảng chúng tôi thấy "Máy khách không thể sử dụng lại phiên với SPID XXX, đã được đặt lại để kết nối. Lỗi này có thể do lỗi hoạt động trước đó không thành công. Kiểm tra nhật ký lỗi cho các hoạt động thất bại ngay trước thông báo lỗi này . " được tạo bởi cả hai máy chủ. Dường như không có tin nhắn "sớm hơn" cho thấy bất kỳ vấn đề.
7) Thư thỉnh thoảng cơ sở dữ liệu ghi lỗi vào nhật ký sự kiện Ứng dụng:
Loại ngoại lệ: Microsoft.SqlServer.Man Quản lý.SqlIMail.Server.Common.BaseException Thông báo: Có lỗi trên kết nối. Lý do: Hết hạn sử dụng. Khoảng thời gian chờ đã trôi qua trước khi hoàn thành thao tác hoặc máy chủ không phản hồi., Tham số kết nối: Tên máy chủ: MGQuery02, Tên cơ sở dữ liệu: msdb Dữ liệu: System.Collections.ListDixiI INTERNal TargetSite: Void OpenConnection (Microsoft.SqlServer.Man Quản lý. SqlConnectionInfo) HelpLink: NULL Nguồn: DatabaseMailEngine
Thông tin về StackTrace tại Microsoft.SqlServer.Man Quản lý.SqlIMail.Server.DataAccess. ) tại Microsoft.SqlServer.Man Quản lý.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (String dbName, String dbServerName, Int32 lifeMinimumSec, LogLevel logLevel)
Tôi tin rằng Hết giờ đang gây ra lỗi chuyển đổi; Điều gì có thể gây ra những khoảng thời gian này? Rõ ràng nếu có sự cố mạng thực sự như cáp xấu hoặc chuyển đổi xấu, điều đó có thể gây mất gói và do đó hết thời gian, tuy nhiên những thứ khác có thể gây ra thời gian chờ? Chặn? Nếu MSDB hoặc một số cơ sở dữ liệu hệ thống khác có thời gian chờ I / O có thể gây ra lỗi chuyển đổi phản chiếu?
Cảm ơn vì lời khuyên!
MSDN có những điều sau đây để nói về chính cơ chế hết thời gian chờ :
Cơ chế hết thời gian phản chiếu
Vì các lỗi mềm không thể được phát hiện trực tiếp bởi một cá thể máy chủ, nên một lỗi mềm có thể khiến một cá thể máy chủ phải chờ đợi vô thời hạn. Để ngăn chặn điều này, phản chiếu cơ sở dữ liệu thực hiện cơ chế hết thời gian riêng của mình, dựa trên từng phiên bản máy chủ trong phiên phản chiếu gửi ping trên mỗi kết nối mở trong một khoảng thời gian cố định.
Để giữ kết nối mở, một phiên bản máy chủ phải nhận được ping trên kết nối đó trong khoảng thời gian chờ được xác định, cộng với thời gian cần thiết để gửi thêm một ping. Nhận ping trong khoảng thời gian chờ cho biết kết nối vẫn mở và các phiên bản máy chủ đang liên lạc qua nó. Khi nhận được ping, một phiên bản máy chủ sẽ đặt lại bộ đếm thời gian chờ của nó trên kết nối đó.
Nếu không nhận được ping trên một kết nối trong khoảng thời gian chờ, một phiên bản máy chủ coi kết nối đã hết thời gian. Phiên bản máy chủ đóng kết nối hết thời gian và xử lý sự kiện hết thời gian theo trạng thái và chế độ hoạt động của phiên.
netsh interface tcp show global trình diễn:
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disabled
netsh interface ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
Start Port : 1025
Number of Ports : 64510
SELECT name, value_in_use FROM sys.configurations
Truy vấn phân phối Ad Hoc 0
mối quan hệ I / O mặt nạ 0
mặt nạ ái lực 0
affinity64 Mặt nạ I / O 0
mặt nạ ái lực 0
Tác nhân XP 1
cho phép cập nhật 0
awe kích hoạt 0
ngưỡng quy trình bị chặn 5
chế độ kiểm toán c2 0
kích hoạt 1
tuân thủ tiêu chí chung cho phép 0
ngưỡng chi phí cho song song 4
quyền sở hữu chéo chéo chuỗi 0
ngưỡng con trỏ -1
Cơ sở dữ liệu XP XP 1
ngôn ngữ toàn văn mặc định 1033
ngôn ngữ mặc định 0
theo dõi mặc định được kích hoạt 1
không cho phép kết quả từ kích hoạt 0
hệ số điền (%) 0
ft thu thập thông tin băng thông (tối đa) 100
ft thu thập thông tin băng thông (phút) 0
ft thông báo băng thông (tối đa) 100
ft thông báo băng thông (phút) 0
chỉ mục tạo bộ nhớ (KB) 0
nghi ngờ xact độ phân giải 0
tổng hợp nhẹ 0
khóa 0
mức độ song song tối đa 6
thu thập thông tin toàn văn bản tối đa 4
bộ nhớ máy chủ tối đa (MB) 393216
kích thước thay thế văn bản tối đa (B) 65536
chủ đề công nhân tối đa 0
duy trì phương tiện truyền thông 0
bộ nhớ tối thiểu trên mỗi truy vấn (KB) 2048
bộ nhớ máy chủ tối thiểu (MB) 52427
kích hoạt lồng nhau 1
kích thước gói mạng (B) 1400
Quy trình tự động hóa Ole 1
mở đối tượng 0
Thời gian chờ PH 60
xếp hạng 0
ưu tiên tăng 0
thống đốc truy vấn giới hạn chi phí 0
truy vấn chờ (s) -1
khoảng thời gian phục hồi (phút) 0
truy cập từ xa 1
kết nối quản trị từ xa 0
thời gian chờ đăng nhập từ xa 20
từ xa
thời gian chờ truy vấn từ xa (s) 600
Bản sao XP 0
quét để khởi động 0
đệ quy kích hoạt máy chủ 1
đặt kích thước bộ làm việc 0
hiển thị tùy chọn nâng cao 1
SMO và DMO XP 1
SQL Mail XP 0
biến đổi từ tiếng ồn 0
cắt hai chữ số năm 2049
kết nối người dùng 0
tùy chọn người dùng 4216
Thủ tục trợ lý web 0
xp_cmdshell 1
Cách đây một thời gian, tôi đã sửa đổi thủ công mirroring_connection_timeoutgiá trị cho tất cả các cơ sở dữ liệu được nhân đôi thành 30 giây để cố gắng khắc phục sự cố; điều này chỉ đơn giản là tăng thời lượng giữa các sự kiện chuyển đổi dự phòng. Với mirroring_connection_timeoutcài đặt được đặt ở mặc định là 10 giây, chúng ta sẽ thấy nhiều lỗi hơn.
Một bình luận đã yêu cầu tôi đảm bảo IPSec bị vô hiệu hóa, vì vậy tôi đang đăng nội dung của một số netshlệnh hiển thị cấu hình IPSec của hệ điều hành:
C: \> Netsh ipsec động hiển thị tất cả Không có chính sách được giao hiện tại Chính sách Mainmode không có sẵn. Chính sách Quickmode không có sẵn. Bộ lọc Mainmode chung không khả dụng. Bộ lọc Mainmode cụ thể không có sẵn. Bộ lọc Quickmode chung không khả dụng. Bộ lọc Quickmode cụ thể không có sẵn. IPsec Hiệp hội bảo mật MainMode không có sẵn. Hiệp hội bảo mật IPMec QuickMode không khả dụng. Thông số cấu hình IPsec ------------------------------ StrongCRLCheck: 1 IPsecexeem: 3 Thống kê IPsec ---------------- PGS hoạt động: 0 Giảm tải SA: 0 Khóa chờ: 0 Thêm khóa: 0 Xóa khóa: 0 Phím lại: 0 Đường hầm hoạt động: 0 SPI xấu: 0 Các mã không được giải mã: 0 Những người không được chứng thực: 0 Phát hiện với Phát lại Phát lại: 0 Số byte bí mật đã gửi: 0 Số byte bí mật nhận được: 0 Số byte xác thực đã gửi: 0 Số byte xác thực đã nhận: 0 Byte vận chuyển đã gửi: 0 Số byte vận chuyển đã nhận: 0 Byte được gửi trong đường hầm: 0 Số byte nhận được trong các đường hầm: 0 Số byte đã giảm đã gửi: 0 Số byte đã giảm nhận được: 0 C: \> Netsh ipsec tĩnh hiển thị tất cả ERR IPsec [05072]: Không có chính sách trong Kho chính sách
CẬP NHẬT: 2012-12-20
Hiện tại chúng tôi đã chuyển các hệ thống sản xuất của mình sang SQL Server 2012. Chúng tôi đã chạy nó từ sáng ngày 17 tháng 12 - cho đến nay không có lỗi. Tuy nhiên, một vài ngày là tốt trong những gì chúng ta đã thấy với các hệ thống dựa trên năm 2005.
Trong nỗ lực ghi lại hiệu suất của các hệ thống mới của chúng tôi, tôi đã xem xét sys.dm_os_wait_statskỹ hơn; và nhận thấy DBMIRROR_DBM_EVENT, đó là một loại chờ đợi không có giấy tờ. Graham Kent tại Microsoft có một bài viết thú vị liên quan đến việc khắc phục các lỗi không mong muốn và loại chờ này. Tôi sẽ tóm tắt những phát hiện của mình ở đây:
Khách hàng đã trải qua chuỗi chặn khổng lồ được xây dựng trên cơ sở dữ liệu OLTP khối lượng lớn, trong đó tất cả các trình chặn đầu đang chờ trên DBMIRROR_DBM_EVENT. Đây là chuỗi các sự kiện tôi đã trải qua:
Xem lại chính chuỗi chặn - ho giúp đỡ ở đây vì tất cả những gì chúng ta có thể thấy là chúng tôi đang chờ đợi trên DBMIRROR_DBM_EVENT
Xem lại nguồn cho loại chờ không có giấy tờ. Rõ ràng là bạn không thể làm điều này bên ngoài MS, nhưng tôi có thể nói rằng tại thời điểm viết loại chờ này đại diện cho sự chờ đợi được sử dụng khi hiệu trưởng đang chờ gương làm cứng LSN, có nghĩa là giao dịch mà nó không thể thực hiện được. . Điều này ngay lập tức chỉ ra khá cụ thể vấn đề mà hiệu trưởng không thể thực hiện giao dịch khi nó đang chờ trên gương. Bây giờ chúng tôi cần điều tra lý do tại sao chiếc gương không thực hiện giao dịch hoặc tại sao hiệu trưởng không biết liệu nó có.
Xem lại các bảng hệ thống msdb
(a) Nhìn vào bảng [backupset] để xem kích thước của các bản ghi được tạo ra tại thời điểm xảy ra sự cố cao hơn đáng kể so với bình thường. Nếu chúng đặc biệt lớn, có thể là chiếc gương tràn ngập các giao dịch và đơn giản là không thể theo kịp khối lượng. Đây là lý do tại sao sách trực tuyến đôi khi sẽ cho bạn biết tắt tính năng phản chiếu nếu bạn cần thực hiện một thao tác ghi nhật ký đặc biệt lớn như xây dựng lại chỉ mục. (tham khảo lý do tại sao điều này có tại http://technet.microsoft.com/en-us/l Library / cc917681.aspx ). Ở đây tôi đã sử dụng TSQL sau đây
SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go
select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'(b) thứ hai tôi đã xem dữ liệu trong các bảng [dbm_monitor_data]. Chìa khóa ở đây là xác định khung thời gian mà chúng tôi gặp sự cố và sau đó xem liệu chúng tôi có gặp phải những thay đổi đáng kể trong bất kỳ trường hợp nào sau đây không:
log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rateĐây là tất cả các chỉ số tương tự như phần (a) trong đó chúng có thể hiển thị một thành phần hoặc một phần của kiến trúc không đáp ứng. Ví dụ: nếu send_queue đột nhiên bắt đầu tăng nhưng hàng đợi re_do không phát triển, thì điều đó có nghĩa là hiệu trưởng không thể gửi các bản ghi nhật ký tới gương để bạn có thể xem kết nối có thể hoặc hàng đợi của nhà môi giới dịch vụ đối phó với việc truyền thực tế.
Trong kịch bản cụ thể này, chúng tôi đã lưu ý rằng tất cả các bộ đếm dường như có các giá trị lạ, trong đó có các bản sao lưu nhật ký đang diễn ra với kích thước bình thường, nhưng không có thay đổi trạng thái, 0 gửi hàng, 0 làm lại hàng đợi, tốc độ gửi phẳng và căn hộ làm lại tỷ lệ. Điều này rất lạ vì nó ngụ ý rằng Màn hình DBM không thể ghi lại bất kỳ giá trị nào từ bất kỳ đâu trong suốt thời gian xảy ra sự cố.
Xem lại nhật ký lỗi SQL Server. Trong trường hợp này không có lỗi hoặc thông báo thông tin nào, nhưng trong các tình huống khác như thế này, rất phổ biến cho các lỗi trong phạm vi 1400 được báo cáo, ví dụ bạn có thể tìm thấy ở những nơi khác trong các blog phản chiếu khác của tôi, chẳng hạn như ví dụ Lỗi 1413 này
Xem lại các tệp theo dõi mặc định - trong trường hợp này tôi không được cung cấp các dấu vết mặc định, tuy nhiên chúng là nguồn thông tin vấn đề DBM tuyệt vời, vì chúng ghi lại các sự kiện thay đổi trạng thái trên tất cả các đối tác. Điều này được ghi lại ở đây:
Cơ sở dữ liệu phản ánh trạng thái thay đổi lớp sự kiện
Điều này thường cung cấp cho bạn một bức tranh tuyệt vời về các tình huống như khi kết nối mạng không thành công giữa một hoặc tất cả các đối tác và sau đó là trạng thái của mối quan hệ đối tác sau đó.
KẾT LUẬN:
Trong kịch bản cụ thể này, tôi hiện đang thiếu 2 điểm chính của dữ liệu, nhưng ngoài ra tôi vẫn có thể đưa ra một giả thuyết hợp lý về thông tin trên. Chúng tôi chắc chắn có thể nói rằng việc chặn được gây ra bởi thực tế là DBM đã được kích hoạt do các trình chặn tất cả đang chờ trên loại chờ DBMIRROR_DBM_EVENT. Vì chúng tôi biết rằng chúng tôi đã không làm ngập gương với một hoạt động được ghi nhật ký lớn và việc triển khai này thường chạy một cách vui vẻ trong chế độ này, chúng tôi có thể loại trừ các hoạt động lớn bất thường. Điều này có nghĩa là chúng tôi có 2 ứng viên tiềm năng ở giai đoạn này:
Vấn đề phần cứng về kết nối giữa một số hoặc tất cả các đối tác.
Sự cạn kiệt CPU trên máy chủ nhân bản - đơn giản là không thể theo kịp các bản làm lại - sự cạn kiệt CPU có thể là do một quá trình bên ngoài SQL Server hoặc bên ngoài mối quan hệ đối tác nhân bản này.
Một vấn đề với chính mã phản chiếu (chúng tôi thực sự cần một số kết xuất bộ nhớ để xác nhận điều này).
Dựa trên kinh nghiệm tôi nghi ngờ 1 hoặc 2, nhưng tôi luôn giữ quan điểm cởi mở về 3, chúng tôi đang cố gắng thu thập thêm một số dữ liệu ngay bây giờ để xem xét vấn đề này chi tiết hơn.