SQL Errorlog Constant FlushCache Messages
Máy chủ là một phần của nhóm Luôn sẵn sàng (BAG) SQL 2017 Tôi đã nhận thấy sự gia tăng các thông báo này. Tôi hiểu đây là những thông báo xuất hiện trong nhật ký theo tiêu chuẩn từ năm 2012 (cờ theo dõi trước năm 2012) nhưng trong 2 ngày qua, chúng xuất hiện vài phút một lần, không có bản sao lưu nào đang chạy hoặc công việc bảo trì vào những thời điểm này
Máy chủ đang hoạt động như lỗi thứ cấp không thể đọc được trước đối tác và máy chủ chính không thể hiện hành vi tương tự.
09/04/2020 10: 52: 24, spid82s, Không xác định, FlushCache: đã dọn sạch 2303 bufs với 1881 lần viết trong 81090 ms (tránh 11 bufs bẩn mới) cho db 7: 0 09/04/2020 10:52:07, spid52s, Không xác định, mục tiêu cuối cùng còn tồn đọng: 2 avgWriteLatency 86 09/04/2020 10: 52: 07, spid52s, Unknown, trung bình ghi mỗi giây: 17,70 lần ghi / giây Thông lượng trung bình: 0,19 MB / giây Độ bão hòa I / O: 13073 công tắc ngữ cảnh 15434
Cũng có một cảnh báo trong nhật ký lỗi hệ thống về vấn đề ổ đĩa, vài giây sau khi nhóm khả dụng không thành công vì các thông báo FlushCache đã tăng lên.
Có ai đã trải qua bất cứ điều gì tương tự hoặc có bất kỳ lời khuyên nào không, sysadmin của tôi cũng đang xem xét bất động sản SAN và VMware.
Bạn có đột ngột nghĩ những điều này có thể do các hoạt động tự phát triển gây ra không?
Trả lời
Chuyển sang các điểm kiểm tra gián tiếp (nói chung, đặt thời gian khoảng thời gian khôi phục thành 60 giây, ít nhất cho cơ sở dữ liệu người dùng).
Tôi đã viết về vấn đề này ở đây và ở đây , và bạn nên đọc đầy đủ các bài đăng đó trước khi thực hiện thay đổi, mặc dù đó là một IMHO không có trí tuệ.
Tác động trong môi trường của chúng tôi là mạnh mẽ và tức thì, và thật đơn giản để chứng minh sự thay đổi là có trách nhiệm. Mọi cơ sở dữ liệu có hiện tượng này đều đi từ các điểm kiểm tra 30-60 giây và các nhật ký lỗi đầy đủ các thông báo này, đến các điểm kiểm tra phụ thứ hai và không còn mục nhật ký lỗi nào nữa.
Có lẽ cũng có những kỹ thuật giảm thiểu khối lượng công việc của bạn, chẳng hạn như xem bài đăng này của Itzik Ben-Gan nhưng làm cho các trạm kiểm soát hiệu quả hơn là một con đường nhanh chóng và dễ dàng hơn. Tuy nhiên, bộ nhớ của bạn và người dùng máy ảo không có lợi; chắc chắn có vấn đề về đĩa mà họ cần giải quyết (nhưng tôi không đồng ý rằng các thông báo FlushCache này là nguyên nhân gốc rễ của bất kỳ chuyển đổi dự phòng nào; nhiều khả năng chúng chỉ là một nạn nhân / triệu chứng khác).
Kiểm tra với quản trị viên lưu trữ của bạn nếu có bất kỳ bản cập nhật chương trình cơ sở nào gần đây hoặc hệ thống con lưu trữ của bạn cần bản cập nhật chương trình cơ sở mới hơn. Tôi đã thấy thông báo này trên môi trường SQL nhiều lần và một điều bạn có thể xem là cấu hình lớp lưu trữ (đây là nguyên nhân phổ biến). Ngoài ra, một điều để theo dõi hiệu suất đĩa của bạn bằng perfmon. quầy đĩa bạn cần phải tập trung vào: avg disk sec/Read, avg disk sec/Write, avg disk sec/Transfer.
Bạn có thể kiểm tra liên kết sau, bạn có thể xem bên dưới:
- Cách hoạt động: Khi nào thông báo FlushCache được thêm vào Nhật ký lỗi máy chủ SQL?
- https://techcommunity.microsoft.com/t5/sql-server-support/how-it-works-when-is-the-flushcache-message-added-to-sql-server/ba-p/317038
Khi tôi nói lớp lưu trữ, hãy kiểm tra những điều sau: HBA / CNA, Cáp quang, Công tắc FC, Cổng, Bộ điều khiển lưu trữ, Phần mềm (Trình điều khiển MPIO) - tất cả cấu hình của nó
Cuối cùng, tôi thực sự khuyên bạn nên luôn kiểm tra và điều tra thông báo cảnh báo / lỗi trên nhật ký sự kiện của bạn. ĐỪNG để nó trôi qua vì những loại tin nhắn này có hậu quả lâu dài.