Làm cách nào để xác minh rằng khôi phục cơ sở dữ liệu đầy đủ phản ánh cơ sở dữ liệu nguồn chính xác trong SQL Server?

Chúng tôi đang ngừng hoạt động SQL Server 2000 Ent cũ của chúng tôi. ví dụ có lợi cho SQL Server 2008 R2 Ent. Con đường di chuyển theo kế hoạch của tôi là:

1. Chấm dứt kết nối máy khách (2000)
2. Sao lưu toàn bộ (2000)
3. Khôi phục (2008 R2)

Tôi đang được yêu cầu cung cấp bằng chứng thuyết phục rằng mọi giao dịch đều "thực hiện" và dữ liệu là bản sao chính xác của những gì tồn tại trên ví dụ 2000.

Tôi hy vọng rằng tôi có thể sử dụng các tài liệu sau đây làm bằng chứng:

• Sao lưu cơ sở dữ liệu đầy đủ
• Thực hiện khôi phục cơ sở dữ liệu hoàn chỉnh (Mô hình khôi phục hoàn toàn)

Tuy nhiên, nếu điều này là không đủ, điều duy nhất tôi có thể nghĩ đến là trích xuất từng hàng của mỗi bảng của mỗi cơ sở dữ liệu và tính toán tổng kiểm tra (trên cả hai trường hợp) cũng như lấy số lượng hàng cho mỗi bảng trong mỗi cơ sở dữ liệu.

Có cách nào tốt hơn để đáp ứng các tiêu chí xác minh "bản sao chính xác" không? Tôi cũng mở tài liệu tốt hơn.

Khi bạn thực hiện sao lưu cơ sở dữ liệu, LSN cuối cùng trên nguồn sẽ là X. Nếu có bất kỳ hoạt động nào xảy ra (bao gồm, giả sử, một điểm kiểm tra tự động), LSN nguồn sẽ chuyển tiếp sang X + n. Nếu có bất kỳ hoạt động nào xảy ra trên nguồn và không được ghi lại trong bản sao lưu thì nó sẽ để lại dấu ấn trong nhật ký nguồn, ở đâu đó giữa LSN X và X + n. Sử dụng fn_dblogmột người có thể nhìn vào nhật ký và xem nếu có bất kỳ hoạt động như vậy xảy ra.

Một cách dễ dàng để đảm bảo không có hoạt động nào như vậy xảy ra sau khi sao lưu là đặt cơ sở dữ liệu thành read_only ngay sau khi thực hiện sao lưu. Để ngăn chặn mọi hoạt động lén lút giữa bản sao lưu và thay đổi thành read_only, bạn có thể tắt kết nối hoặc đặt cơ sở dữ liệu ở chế độ single_user, thậm chí khởi động máy chủ ở chế độ người dùng .

Vì vậy, một quy trình như sau sẽ có khả năng chống đạn khá nhiều:

• khởi động lại máy chủ nguồn ở chế độ người dùng ( -m)
• kết nối và sao lưu
• thay đổi cơ sở dữ liệu thành read_only
• khôi phục cơ sở dữ liệu trên máy chủ mới
• chạy bất kỳ bài kiểm tra nào bạn có trên máy chủ mới
• kết nối các ứng dụng với máy chủ mới
• ngừng hoạt động hoặc khởi động lại máy chủ cũ

Tôi sẽ nói:

1. vô hiệu hóa kết nối trên máy chủ 2000.
2. Tạo một bản sao lưu trên máy chủ 2000, sau đó xác minh nó dựa trên cơ sở dữ liệu.
3. Khôi phục máy chủ 2008.
4. Đảm bảo các kết nối vẫn bị vô hiệu hóa trên máy chủ 2000.
5. Thay đổi tên trên máy chủ 2000 và tắt dịch vụ SQL Server.
6. Đăng xuất rằng bạn đã khôi phục bản sao đã được xác minh của cơ sở dữ liệu trên máy chủ mới.
7. Bắt đầu máy chủ mới.

Tôi không thấy làm thế nào có thể thiếu các giao dịch trên máy chủ mới, giả sử không có giao dịch nào diễn ra trên máy nguồn trong và sau quá trình sao lưu.

Để chứng minh, điều duy nhất bạn có thể làm là so sánh dữ liệu trong cơ sở dữ liệu nguồn và đích; tuy nhiên đó là quá mức cần thiết vì sao lưu và xác minh sẽ làm chính xác điều đó.

Có rất nhiều cách để làm điều đó.

a. Sao lưu từ 2000 dụ và khôi phục nó trên phiên bản 2008R2. Điều này sẽ yêu cầu thời gian chết ứng dụng của bạn cho đến khi bạn khôi phục lại bản sao lưu thành công vào phiên bản 2008R2.

Ngoài ra, bạn phải hủy tất cả các kết nối đến phiên bản 2000 vì bạn không muốn mất dữ liệu.

b. Thiết lập logshipping từ 2000 đến 2008R2. Khi thất bại, bạn chỉ cần thực hiện đăng nhập lại đuôi và khôi phục tại phiên bản thứ cấp (2008R2) và sau đó đưa cơ sở dữ liệu trực tuyến.

Tùy chọn b sẽ yêu cầu ít thời gian chết hơn.

BIÊN TẬP :

Bạn có thể có Log-Shipping giữa SQL 2000 và SQL 2005 / 2008R2. NHƯNG bạn không thể giữ thứ cấp trong chế độ STANDBY.

Một số tài liệu tham khảo về Thực hiện vận chuyển Nhật ký trên SQL 2000. Lưu ý rằng điều này cũng áp dụng cho việc thiết lập vận chuyển nhật ký từ 2000 đến 2005/2008 / 2008R2.

Thực hiện vận chuyển gỗ

Di chuyển cấu hình vận chuyển nhật ký SQL Server 2000 sang SQL Server 2008

Nhật ký vận chuyển tùy chỉnh

Đăng nhập bằng Powershell