Các nhóm luôn sẵn sàng log_send_rate


8

Trên tất cả các thiết lập Luôn luôn của chúng tôi, chạy Windows 2012 và SQL Server 2012 trong các máy ảo và trên kim loại trần, tôi thấy rằng log_send_rate trong sys.dm_hadr_database_replica_statesluôn trả về các giá trị không chính xác.

Ví dụ: (cho chế độ đồng bộ)

sys.dm_hadr_database_Vplica_states.log_send_rate (ave = 36,571 (kb / s được liệt kê trong bol))

Perfmon - SQLServer: Bản sao khả dụng - Byte được gửi tới bản sao / giây (max = 486.000.000, avg = 259.000.000)

Perfmon - SQLServer: Cơ sở dữ liệu - Nhật ký Byte Flushed / giây (max = 653,044.000, avg = 341.000.000)

Tôi chưa thấy bài viết nào về việc này nhưng có vẻ như nó không hoạt động chính xác. Một log_send_rategiá trị chính xác là hữu ích để theo dõi Luôn luôn.

Đã có ai thử điều này chưa?


Bạn đã xem xét việc làm một báo cáo tại connect.microsoft.com chưa?
Max Vernon

Luôn luôn được cấu hình - chế độ đồng bộ hoặc không đồng bộ? Có bất kỳ sự nhân rộng liên quan?
Kin Shah

Ý bạn là sys.dm_hadr_database_replica_stats, bởi vì DMV bạn lưu ý không chứa một log_send_ratecột. DMV cũng báo cáo điều này cho thấy KB / giây. Lưu ý trong bài viết khắc phục sự cố TechNet này để so sánh giá trị đó với bộ đếm Hiệu suất Log Bytes Flushed/sec, đây có phải là giá trị bạn đang đề cập đến không?

Cảm ơn phản hồi tôi đã cập nhật câu hỏi để chính xác hơn. Tôi dự định làm một báo cáo tại kết nối nhưng trước tiên tôi muốn xem có ai đồng ý rằng con số đó có vẻ sai không.
jonwold

Câu trả lời:


2

Có, điều này đã được sửa gần đây trong Gói dịch vụ 2, Cập nhật tích lũy 3. Đây là bài viết KB: http://support.microsoft.com/kb/3012182

"CỐ ĐỊNH: Cột Log_Send_Rate trong sys.dm_hadr_database_Vplica_states không thể phản ánh chính xác tỷ lệ trong SQL Server 2012"


0

Lý do tại sao log_send_rate(và redo_rate) hơi khó hiểu và "tương quan", đặc biệt là khi chúng ta đã quen với việc truyền dữ liệu theo kiểu suy nghĩ không bị gián đoạn là hai tốc độ này được tính trong thời gian hoạt động, không phải mọi lúc .

Nói cách khác, ý log_send_ratechí sẽ điều chỉnh khi có các khối nhật ký được gửi, nhưng nó sẽ không hoạt động khi nó yên tĩnh và bản sao chính đang chờ đăng nhập để gửi. Tương tự như vậy, ngược lại trên thứ hai với redo_rate.


0

Tôi đã xem các giá trị log_send_rate như là một phần của việc khắc phục sự cố độ trễ mà chúng tôi gặp phải trong một trong các môi trường sản xuất của chúng tôi.

Tôi đã đề xuất với Microsoft rằng định nghĩa của họ về lĩnh vực này là sai, như đã đề cập ở đây ( http://technet.microsoft.com/en-us/l Library / ff877972 ( v = sql.110 ) .aspx ). "Tốc độ mà các bản ghi nhật ký đang được gửi đến cơ sở dữ liệu thứ cấp, tính bằng kilobyte (KB) / giây."

Tôi nghĩ định nghĩa của tôi dưới đây là tốt hơn. Đó là ... Tốc độ mà các bản ghi nhật ký bị xóa khỏi hàng đợi gửi, và các bản ghi nhật ký chỉ có thể bị xóa khỏi hàng đợi này khi chúng đã được làm cứng trên tất cả các thứ cấp và điều đó chỉ có thể xảy ra khi chúng đã được được gửi và nhận, bất kể mất bao lâu để những hồ sơ đó được gửi đến, và mất bao lâu để chúng được làm cứng, và mất bao lâu để người thứ cấp gửi lại acks cho chính.

Đó là một định nghĩa rất khác nhau, ngay cả khi chúng trông giống nhau về mặt thẩm mỹ. Dữ liệu có thể được xóa khỏi một hàng cục bộ trong hàng đợi bộ nhớ (log_send_queue) nhanh hơn nhiều so với dữ liệu có thể được gửi đến phụ trong khu vực, quốc gia hoặc trung tâm dữ liệu khác.

Nikos

@Thomas (Tôi vẫn còn quá ít để thêm bình luận ở đây, xin lỗi. Nếu dễ dàng hơn tôi có thể cung cấp email công việc của mình và chúng tôi có thể thảo luận ngoại tuyến và cập nhật tại đây khi đạt được sự đồng thuận?) Xin chào Thomas

Thật không may, trong khi quan điểm của bạn là chính xác, nó không phải là điểm bị đe dọa. Đúng, khó tương quan hơn cho tất cả các lý do bạn đã mô tả, nhưng đó không phải là vấn đề tôi đang cố gắng nêu bật.

Vấn đề là, trường "log_send_rate" trong DMV không thực sự là tốc độ mà bản ghi nhật ký được gửi đến bản sao.

Chính xác hơn, đó là tốc độ mà các bản ghi nhật ký đang bị xóa khỏi hàng đợi gửi, SAU KHI chúng đã được gửi đến trung học, được làm cứng tại trung học và sau đó gửi một ack trở lại chính. Chỉ sau đó họ có thể bị xóa khỏi hàng đợi gửi chính.

Đó là một ý nghĩa hoàn toàn khác với ý nghĩa được liệt kê trong liên kết tôi đưa vào bài viết đầu tiên của mình. Cũng dễ dàng hơn nhiều để thấy sự khác biệt khi bạn đang giao dịch với các mức giá gửi qua khu vực (như London đến New York), thay vì gửi giá từ và đến trung tâm dữ liệu địa phương.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.