Khả năng phục hồi sự cố của SQL Server có thể được cải thiện không?


20

Chúng tôi có PC chạy SQL Server (2008 SP4 và 2016 SP1) thường xuyên bị mất điện. Rõ ràng, điều này đôi khi dẫn đến (chỉ mục) hỏng cơ sở dữ liệu SQL Server, mà chúng ta cần khôi phục sau đó.

Tôi biết rằng SQL Server không được thiết kế cho các tình huống như vậy và giải pháp chính xác là khắc phục nguyên nhân gây ra sự cố mất điện (nhiều hơn về điều đó dưới đây, nếu bạn tò mò). Tuy nhiên, có bất kỳ tùy chọn điều chỉnh nào trong SQL Server mà tôi có thể đặt để giảm nguy cơ hỏng cơ sở dữ liệu khi mất điện không?


Bối cảnh: "PC" là máy tính bảng Windows được gắn trên xe nâng. Khi người dùng tắt xe nâng, máy tính bảng sẽ mất điện. Chúng tôi đã cố gắng dạy người dùng tắt Windows đúng cách trước khi tắt xe nâng, nhưng không thành công (có lẽ vì chỉ tắt nó "hoạt động" hầu hết thời gian). Chúng tôi hiện cũng đang điều tra các tùy chọn khác, chẳng hạn như thêm một UPS báo hiệu máy tính bảng sẽ tắt khi mất điện.

Câu trả lời:


28

Tôi biết rằng SQL Server không được thiết kế cho các tình huống như vậy và giải pháp chính xác là khắc phục nguyên nhân gây mất điện.

Trên thực tế, nó được thiết kế để đối phó với việc mất điện, đó là lý do tại sao có những thứ như ghi nhật ký trước (WAL) và khôi phục sự cố khi khởi động (hoặc bất cứ điều gì bạn muốn gọi nó). Một trong những cách này được thực hiện là bằng cách chọn không ghi cache mà dường như đó là những gì máy tính bảng đang làm, do đó tham nhũng.

Tuy nhiên, có bất kỳ tùy chọn điều chỉnh nào trong SQL Server mà tôi có thể đặt để giảm nguy cơ hỏng cơ sở dữ liệu khi mất điện không?

Không, SQL Server đang làm những gì nó cần. Bạn nên xem bên ngoài SQL Server (cài đặt windows cho bộ nhớ đệm ổ đĩa [mà SQL muốn tắt nhưng chúng tôi không thể ép buộc bạn], cập nhật phần cứng / phần sụn, v.v.) hoặc như Eric đã nói, mua một bộ nguồn bên ngoài tương đối giá rẻ có thể giải quyết các triệu chứng (vấn đề thực tế có lẽ là một số loại bộ nhớ đệm hoặc ghi pin không thực sự được hỗ trợ).



1
Tôi đoán khá rõ cài đặt nào là thủ phạm nếu đó là sự cố hệ điều hành . (mặc dù đây có lẽ là một trong những HĐH nhúng cũ nếu tôi đoán, không bao giờ kiểm tra xem chúng có cài đặt đó không). Và sau đó, ít nhất hầu hết các đĩa cứng cấp độ người tiêu dùng đều nói dối một cách đáng xấu hổ về việc đã hoàn thành việc ghi vì "lý do tối ưu hóa hiệu suất", vì vậy về cơ bản không có hy vọng nào cho những điều đó.
Voo

26

Nếu máy tính bảng có pin hoạt động , bạn có thể định cấu hình Windows để tắt khi pin yếu .

Nếu máy tính bảng có pin không hoạt động , hãy xem xét thay pin. (Tôi đã có máy tính xách tay như vậy - bạn sẽ ngạc nhiên khi pin thay thế rẻ tiền có thể có trên eBay. Chúng không hoạt động tốt như OEM, nhưng này, mọi thứ đều tốt hơn không có gì trong tình huống này.)

Nếu máy tính bảng hoàn toàn không có khả năng sử dụng pin , hãy xem xét thêm một nguồn cung cấp điện nhỏ không bị gián đoạn (UPS) với đầu ra USB có thể giao tiếp với Windows để báo cho nó biết khi nó chạy bằng nguồn pin. (Ví dụ: tôi có máy tính để bàn của riêng mình được cấu hình để tắt khi UPS hết pin - theo cách đó, nó sẽ tắt khi mất điện ngay cả khi tôi không ở nhà.)

Nếu không có lựa chọn nào trong số đó là một lựa chọn, bạn sẽ không gặp may. Đó là một tờ giấy trắng cũ, nhưng về cơ bản I / O SQL Server 2000 của Microsoft giải thích rằng bạn cần một hệ thống con I / O có thể xử lý sự cố mất điện một cách duyên dáng.

Có các tùy chọn bạn có thể sử dụng để tăng rủi ro - như độ bền Độ trễ hoặc bảng chỉ dành cho bộ nhớ (không bền) - nhưng theo mặc định, SQL Server đã cố gắng hết sức để tối đa hóa độ tin cậy với mỗi lần ghi vào nhật ký giao dịch. Nếu thậm chí ghi nhật ký giao dịch không thể được đảm bảo do mất điện ngẫu nhiên, hãy chi 100 đô la cho pin UPS.


6

Giả sử bạn có DB cục bộ trên xe nâng chứ không phải máy chủ vì các kết nối không dây không chính xác? Rõ ràng việc đưa SQL ra khỏi xe nâng sẽ là giải pháp thích hợp hơn.

Dù sao, như Brent đề xuất, hãy đặt máy tính bảng tự tắt nguồn sau x phút sử dụng pin hoặc một số tiêu chí tương tự.

Không, một UPS nhỏ có thể khởi động tắt máy bình thường có lẽ sẽ là lựa chọn tốt nhất của bạn trong trường hợp đó. Dựa vào người dùng cho những thứ như thế là yêu cầu thất bại.


1
"Giả sử bạn có DB cục bộ trên xe nâng chứ không phải máy chủ vì kết nối không dây không chính xác?" Vâng, đó chính xác là trường hợp. Ứng dụng giữ cho DB cục bộ và DB máy chủ đồng bộ, cho phép xe nâng rời khỏi khu vực được bao phủ bởi mạng WLAN và vẫn sử dụng ứng dụng.
Heinzi

2

Hệ điều hành cơ bản phải đảm bảo ghi lại thành công hoặc trả về lỗi. Hệ điều hành lần lượt dựa vào các trình điều khiển, lần lượt dựa vào phần sụn phụ thuộc vào phần cứng Nếu cả hai trình điều khiển, phần cứng đều không có cửa sổ hoặc máy chủ sql có thể làm gì về điều đó.

Đây là lý do tại sao bạn cần kiểm tra với nhà sản xuất trình điều khiển / phần sụn / phần cứng.

Ngoài ra, thứ tự viết phải được đảm bảo trên tất cả các lớp để cần phải được kiểm tra.

Ngay cả bộ nhớ cache được hỗ trợ bằng pin cũng có thể thất bại, ví dụ như trong cơn bão New York, một số trung tâm dữ liệu không thể truy cập được trong nhiều ngày và pin sẽ hết, có khả năng bị mất đi

https://www.postgresql.org/docs/devel/static/wal-relabilities.html

https://brad.livejournal.com/2116715.html

http://rhaas.blogspot.com/2010/10/wal-relabilities.html?m=1


1

Để mở rộng các câu trả lời khác:

Trước tiên, hãy thử đưa SQL ra khỏi xe nâng nếu có thể. Nghĩ rằng phục hồi sau khi mất điện là điều tồi tệ, hãy thử làm điều đó sau khi máy tính xách tay đã chạy hơn 7.000 lbs. Với hàng giờ hoạt động kho trên đó, không được sao lưu ...

Thứ hai, dù sao đi nữa, một cơ chế cho máy tính xách tay thực hiện tự động tắt máy sau x thời gian sử dụng pin.

Thứ ba, việc kết nối máy tính xách tay với nguồn cấp điện không chuyển đổi trên xe nâng có phải là một lựa chọn không? Hãy chắc chắn xem xét các quy định an toàn (môi trường có thể yêu cầu mọi thứ tắt với chìa khóa xe nâng) và thời gian sử dụng của xe nâng giữa các lần sử dụng (đặc biệt vào cuối tuần và ngày lễ) để tránh làm cạn kiệt pin máy.

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.