Khôi phục trang trực tuyến đạt giới hạn 1000


13

Tôi đã được giao nhiệm vụ cố gắng khôi phục cơ sở dữ liệu bị hỏng (do lỗi I / O, đã được sửa chữa từ đó). Tôi không quen thuộc với cơ sở dữ liệu hoặc những gì nó chứa.

Tôi đã nhận được một bản sao lưu cũ (~ 3 tuần) và một loạt nhật ký giao dịch ... tuy nhiên vẫn còn thiếu nhật ký giao dịch, vì vậy tôi chỉ có thể khôi phục tối đa một ngày nhất định. Có khoảng 2,5 tuần dữ liệu bị mất (và có rất nhiều dữ liệu được thêm vào cơ sở dữ liệu này liên tục).

Tôi cũng đã nhận được một bản sao của cơ sở dữ liệu bị hỏng (có thể truy cập được, nhưng có rất nhiều trang bị hỏng / thiếu).

Tôi đã thử các DBCC CHECKDBlệnh thông thường (vẫn không repair_allow_data_loss, đó sẽ là phương án cuối cùng của tôi nếu không có gì khác hoạt động).

Sau nhiều lần đến và đi đến cơ sở dữ liệu (db là một con quái vật nhỏ 1,5 terabyte và mọi thứ tôi làm đều chậm và mất một lúc), tôi đã cố gắng thực hiện khôi phục trang trực tuyến từ bản sao lưu tốt được biết đến cuối cùng cho các trang bị hỏng.

Để làm điều đó, tôi đã thực hiện một tập lệnh tạo ra nhiều RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'lệnh từ DBCC CHECKDBđầu ra (về cơ bản là một biểu thức chính quy và khác biệt) ... cho đến nay, điều này đã làm việc đến mức nó nói rằng tôi đã đạt đến giới hạn 1000 trang mỗi tệp (có 8 tệp trên db này) cho mỗi lệnh khôi phục.

Vì vậy, nó yêu cầu tôi "hoàn thành khôi phục trực tuyến", nhưng tôi không biết làm thế nào để làm điều đó ... Tôi không có nhật ký đuôi hoặc bất cứ điều gì hoàn chỉnh hơn bản sao lưu đầy đủ mà tôi bắt đầu, vì vậy Về cơ bản, tôi không biết cách hoàn tất khôi phục để tiếp tục thử với các trang còn lại.

Tôi đã thử RESTORE DATABASE <foo> WITH RECOVERYnhưng nó cũng không hoạt động, nó yêu cầu tôi đăng nhập mà tôi không có.

Có ai có bất cứ lời khuyên nào về cách tôi có thể cố gắng phục hồi bất cứ điều gì từ đây không? Hoặc làm thế nào để "hoàn thành" khôi phục trực tuyến để tôi có thể tiếp tục cố gắng khôi phục nhiều trang hơn? Tôi có gặp vấn đề tương tự không nếu tôi thử khôi phục ngoại tuyến (về cơ bản là thêm WITH NORECOVERYvào mọi thứ và sau đó cố gắng đưa nó trở lại vào cuối?)

Xây dựng cơ sở dữ liệu bằng tay về cơ bản là không thể hoàn tác ... có hàng trăm bảng với hàng triệu hàng và không có ý nghĩa rõ ràng về bất kỳ bảng nào trong số đó. DB bị hỏng sẽ thất bại trong SELECTcác truy vấn sau vài triệu hàng nhưng tôi không chắc mình có thể tìm ra ở đâu. Tôi đã thử xây dựng lại tất cả các chỉ mục không được nhóm, nhưng có những trang bị hỏng với dữ liệu hàng, do đó cũng không hoạt động.

Một số mất dữ liệu sẽ được chấp nhận, nhưng ít nhất là phải đạt được sự nhất quán trên DB.

Cơ sở dữ liệu bị hỏng là trực tuyến và khách hàng đang làm việc với nó (vì vậy nó tiếp tục nhận được dữ liệu mới), do đó, bất kỳ quy trình nào tôi thực hiện trên băng ghế dự bị nên được sao chép trên cơ sở dữ liệu sản xuất sau đó (thời gian chết sẽ khó khăn cho nó).

Đây là SQL Server 2014 Enterprise

PS: Tôi không phải là DBA ... Tôi là một lập trình viên, nhưng khách hàng đã thử một số dịch vụ phục hồi thảm họa sql "chuyên gia" và họ đã từ bỏ, vì vậy tôi đã được yêu cầu xem xét và xem liệu tôi có thể làm bất cứ gì.


Cập nhật : sau nhiều thử nghiệm, việc khôi phục trang theo từng trang là không có, vì vậy chúng tôi đã từ bỏ ý tưởng này. Chúng tôi sẽ phục hồi thủ công (chọn thủ công các bản ghi bị thiếu từ các bảng bị hỏng và chèn chúng vào bản sao lưu tốt đã biết trước), thực hiện một số công cụ tự động cho nó (một lần nữa, có hàng trăm và hàng trăm bảng).

Câu trả lời:


16

Thủ tục tiêu chuẩn sẽ là:

  1. Lấy ID trang phải được khôi phục.
  2. Bắt đầu khôi phục trang với cơ sở dữ liệu đầy đủ.
  3. Áp dụng sao lưu vi sai gần đây nhất.
  4. Áp dụng sao lưu nhật ký tiếp theo.
  5. Tạo bản sao lưu nhật ký mới.
  6. Khôi phục lại bản sao lưu lob mới.

Sau khi sao lưu nhật ký mới được áp dụng, quá trình khôi phục trang được hoàn thành và các trang sau đó có thể sử dụng được.

Khôi phục ví dụ

RESTORE DATABASE <database> PAGE='1:57, 1:202, 1:916, 1:1016'  
   FROM <file_backup_of_file_B>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;   
BACKUP LOG <database> TO <new_log_backup>;   
RESTORE LOG <database> FROM <new_log_backup> WITH RECOVERY;  
GO  

Tham khảo: Khôi phục trang (SQL Server) (Microsoft Docs) Tham khảo: Báo cáo RESTORE (Transact-SQL) (Microsoft Docs)

Tuy nhiên, bạn có lỗ hổng trong các bản sao lưu TLOG của mình và việc khôi phục quy trình trên có thể đưa cơ sở dữ liệu của bạn trở lại trạng thái mà bạn không mong muốn.


Bạn đang ở trong một tình huống phức tạp.

  1. Cơ sở dữ liệu của bạn có các trang bị hỏng và công ty của bạn liên tục thêm dữ liệu mới vào cơ sở dữ liệu có vấn đề. Điều này có thể dẫn đến tổng thời gian chết của cơ sở dữ liệu. Bạn muốn mạo hiểm điều đó?

  2. Ai đó sẽ phải chịu trách nhiệm và bạn càng cố gắng sửa nó, ban quản lý càng có xu hướng quyết định rằng cuối cùng bạn có thể là người đó. Bạn muốn mạo hiểm điều đó?

  3. Bạn đang đặt mình vào một tình huống khó khăn bằng cách đảm nhận một vai trò mà bạn không được tuyển dụng. Bạn đang cố gắng để đạt được điều gì đó mà cả DBA của công ty và nhà tư vấn bên ngoài của bạn không thể làm được. Trong khi nó có vẻ là một cử chỉ cao quý, bạn đang tự đặt mình vào nguy cơ. Bạn có thể đã "ngầm hứa" một điều gì đó mà bạn sẽ không bao giờ có thể thực hiện được. Bạn muốn mạo hiểm điều đó?

  4. Khi ai đó làm việc với cơ sở dữ liệu truy vấn dữ liệu bị hỏng, họ có thể sẽ nhận được thông báo lỗi. Công việc hàng ngày đã bị ảnh hưởng. Bạn càng chờ đợi lâu thì càng không thể tránh khỏi năng suất. Bạn muốn mạo hiểm điều đó? (Câu hỏi này cũng có thể được nêu ra với quản lý)

  5. Quy trình sao lưu của công ty bạn dường như bị lỗi (nếu không thì sao lưu TLOG sẽ bị thiếu như thế nào?) Và bạn vẫn đang chạy cơ sở dữ liệu sản xuất của mình như thể không có vấn đề gì. Bạn muốn mạo hiểm điều đó?

Đề xuất tốt nhất tôi có thể cung cấp cho bạn là tạm dừng sản xuất và gọi cho Microsoft! Hoặc ít nhất gọi cho Microsoft và có thể dừng sản xuất.

Mặc dù bài viết của tôi có vẻ quá thận trọng và hơi bị kịch tính theo quan điểm của bạn, cá nhân tôi có thể liên quan đến một trải nghiệm như DBA khi dữ liệu bị mất trong tình huống tương tự. Chúng tôi chỉ mất nửa ngày dữ liệu, nhưng chúng tôi phải đồng bộ lại rất nhiều dữ liệu với các hệ thống xung quanh .

Bạn càng chờ đợi thời gian phục hồi đắt tiền hơn.


Về giới hạn trên trang khôi phục, đây là một trích dẫn từ tài liệu chính thức:

Các số trang tối đa có thể được phục hồi vào bất kỳ tập tin duy nhất trong một chuỗi phục hồi là 1000 . Tuy nhiên, nếu bạn có nhiều hơn một số lượng nhỏ các trang bị hỏng trong một tệp, hãy xem xét khôi phục toàn bộ tệp thay vì các trang.

( nhấn mạnh của tôi)

Tham khảo: Báo cáo RESTORE - Đối số (Transact-SQL) (Microsoft Docs)


Khi tất cả trở lại bình thường, các DBA và / hoặc chuyên gia tư vấn bên ngoài có thể muốn xem xét thực hiện một chính sách / thủ tục sao lưu / khôi phục khác cho cơ sở dữ liệu của bạn. Vì nó phải lên đến 7x24, bạn không thể mạo hiểm khi có một quy trình sao lưu không cung cấp khả năng khôi phục đầy đủ cho mọi tình huống.


2
Hầu hết các mối quan tâm của bạn tôi đã nêu ra và quan tâm (Tôi chắc chắn không chịu trách nhiệm nếu có bất kỳ sự cố nào xảy ra, việc sản xuất phải tạm dừng, v.v.). Tôi đã làm cho mình rất rõ ràng về sự tôn trọng đó, nhưng tôi không có quyền kiểm soát hay quyết định nào ở đó. Tôi không nghĩ rằng nó quá thận trọng hoặc bị kịch tính ... Tôi nghĩ rằng về cơ bản họ đang làm sai, và tôi chỉ đang cố gắng giúp đỡ ở đây, nhưng không có sự tự thỏa hiệp. Tôi hiểu giới hạn 1000 trang, nhưng tôi hy vọng rằng đó sẽ là một lệnh khôi phục duy nhất (vì tôi đang thực hiện trực tuyến, tôi đã hy vọng tôi không theo trình tự ... Tôi không thể làm rõ các tài liệu) .
Jcl

1

Tôi thấy bạn đã thử các phương pháp khác nhau, bao gồm làm việc với các "chuyên gia" phục hồi dữ liệu để sửa chữa cơ sở dữ liệu bị hỏng này, đặc biệt là với kích thước trên 1 TB. Điều này làm cho quá trình khó khăn hơn nhiều và một cuộc chạy đua với thời gian. Là một DBA có kinh nghiệm, tôi đã gặp các tình huống tương tự trong đó hầu hết thời gian, có các bản sao lưu tốt có sẵn để khôi phục. Trong trường hợp thừa hưởng các bản sao lưu xấu và cơ sở dữ liệu bị hỏng, tôi đã phụ thuộc rất nhiều vào công cụ của bên thứ ba có tên là công cụ sửa chữa cơ sở dữ liệu SQL của Stellar Phoenix . Công cụ này nổi tiếng để sửa chữa cơ sở dữ liệu bị hỏng (.mdf và .ndf). Dưới đây là một số chức năng của công cụ:

  • Sửa chữa các tệp Cơ sở dữ liệu SQL bị hỏng (.mdf & .ndf)
  • Khôi phục bảng, kích hoạt, chỉ mục, khóa, quy tắc và quy trình được lưu trữ
  • Thực hiện khôi phục các bản ghi đã bị xóa khỏi cơ sở dữ liệu SQL

  • Lưu kết quả quét của cơ sở dữ liệu để thực hiện khôi phục ở giai đoạn sau

  • Cho phép lưu tệp đã sửa chữa ở các định dạng MSSQL, HTML, XLS & CSV
  • Hỗ trợ MS SQL Server 2016, 2014, 2012,2008 và các phiên bản cũ hơn

Công cụ này yêu cầu các tệp .mdf và .ndf phải ngoại tuyến để nó hoạt động tốt khi bạn có một bản sao của cơ sở dữ liệu SẢN PHẨM bị hỏng và không phải dừng các dịch vụ SQL Server.

Phần tốt nhất là phiên bản dùng thử cung cấp cho bạn đầy đủ chức năng của công cụ ngoại trừ cơ sở dữ liệu đã sửa chữa không thể xuất / lưu. Bạn vẫn có thể xem tất cả các đối tượng cơ sở dữ liệu được phục hồi và tệp nhật ký sửa chữa mở rộng cung cấp chi tiết về các giai đoạn khác nhau của quy trình sửa chữa.

Hãy tải về và xem nếu nó giúp. Tải xuống ở đây

Tôi cũng đã viết một blog về cách công cụ này hoạt động tại trang web này: blog samosql

Cảm ơn và HTH đã biến bạn thành HERO của ngày!

Tái bút Khi cơn bão này kết thúc, hãy nhớ nói với ban quản lý rằng cần phải có một cuộc đại tu lớn về các thủ tục sao lưu của họ, đặc biệt là đối với một cơ sở dữ liệu như vậy. Một sự lặp lại của kịch bản này là hoàn toàn không thể chấp nhận! :)

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.