Khôi phục cơ sở dữ liệu MySQL bằng phương pháp thủ công và “cơ học”. Khôi phục các tập tin cơ sở dữ liệu MySQL đã xóa

Đọc, làm thế nào để phục hồi bị mất hoặc căn cứ từ xa MySQL. Cách phục hồi các bảng bị hỏng Cơ sở dữ liệu MySQL sử dụng myisamchk. Cơ sở dữ liệu MySQL được cài đặt mặc định trên máy tính trong một thư mục trên ổ C:

C:\Tệp chương trình\MySQL\My Máy chủ SQL 5.7

Nhưng dữ liệu bảng được lưu trữ trong các tệp ở thư mục khác trên ổ C của máy tính, đó là:

Vị trí của các tệp này được chỉ định trong menu Trạng thái máy chủ Ứng dụng MySQL Workbench, trong phần Thư mục Máy chủ.

Nếu bạn cần khôi phục các bảng cơ sở dữ liệu, bạn sẽ quan tâm đến thư mục chứa dữ liệu của cơ sở dữ liệu cụ thể và các tệp nằm trong đó.

Nội dung:

Tệp cơ sở dữ liệu MySQL

MySQL tương thích với một lượng lớn các định dạng tệp, chẳng hạn như: .sql, .arm, .cnf, .dbs, .ddl, .frm, .ibd, .ism, .mrg, .myd, .myi, .mysql, .opt, .phl, .sal , .sqr, .tmd, .arz, .ibz, .ibc, .qbquery, .rul. Nhưng bài viết này không nói về điều đó. Ngày nay, chúng tôi quan tâm đến chính xác những tệp lưu trữ dữ liệu và bảng cơ sở dữ liệu, bằng cách khôi phục những tệp mà người dùng có thể quay lại Thông tin quan trọng và tránh những tổn thất có thể xảy ra trong tương lai.

Dữ liệu của mỗi cơ sở dữ liệu được lưu trữ trong một thư mục có tên của nó và tùy thuộc vào loại bảng, nó được lưu trữ trong các tệp có phần mở rộng sau:

db.opt– một tệp trong đó các đặc điểm của cơ sở dữ liệu được chỉ định trong quá trình tạo được lưu trữ;
.frm– tập tin cấu trúc bảng;
.myd– một tệp trong đó dữ liệu của các bảng MyISAM được lưu trữ;
.myi– một tệp trong đó các chỉ mục của bảng MyISAM được lưu trữ;
.ibd– một tệp trong đó dữ liệu và chỉ mục của các bảng InnoDB được lưu trữ.

Cách khôi phục cơ sở dữ liệu MySQL

Khôi phục cơ sở dữ liệu MySQL về mặt kỹ thuật không phải là quá trình khó khăn, nhưng còn phụ thuộc vào nhiều điều kiện. Vì Người dùng MySQL Chức năng bàn làm việc được cung cấp Xuất khẩu Và Nhập/Khôi phục dữ liệu cơ sở dữ liệu.

Ngoài ra còn có thể tạo bản sao lưu và khôi phục cơ sở dữ liệu Dữ liệu MySQL bằng cách sử dụng mysqldump(mà chúng tôi đã mô tả chi tiết trong một trong các bài viết của chúng tôi).

Nhưng những tính năng này liên quan nhiều hơn đến việc tạo bản sao lưu dữ liệu MySQL bằng các công cụ tích hợp sẵn. Những người dùng cao cấp hơn hoặc những người chưa sử dụng chức năng sao lưu dữ liệu cơ sở dữ liệu MySQL kịp thời cũng sẽ quan tâm đến phương pháp tạo bản sao và khôi phục dữ liệu cơ sở dữ liệu theo cách thủ công, bằng cách thay thế các tệp cấu trúc và dữ liệu bảng được mô tả ở trên:

Có thể tạo bản sao dữ liệu bảng cơ sở dữ liệu MySQL bằng cách sao chép các tệp cấu trúc và dữ liệu (*.opt, *.frm, *.myd, *.myi cho MyIsam; *.opt, *.frm, *.ibd cho InnoDB) và lưu chúng vào một thư mục khác.
Có thể khôi phục dữ liệu từ các bảng cơ sở dữ liệu MySQL bằng cách thay thế các tệp dữ liệu và cấu trúc đã sao chép trước đó vào các thư mục của cơ sở dữ liệu hiện có (trong trường hợp của chúng tôi, đây là hai cơ sở dữ liệu: my_db và my_db2).

Khôi phục cơ sở dữ liệu MySQL bị mất hoặc bị xóa

Vì vậy, nếu vì lý do nào đó bạn đã xóa cơ sở dữ liệu MySQL, cài đặt lại Windows hoặc định dạng ổ cứng, thì bạn có thể khôi phục nó bằng phương pháp được mô tả ở trên, bằng cách đặt các tệp cơ sở dữ liệu đã sao chép trước đó vào thư mục có tên của cơ sở dữ liệu:

C:\ProgramData\MySQL\MySQL Server 5.7\Data

Nếu người dùng không tạo trước bản sao của các tệp cơ sở dữ liệu, chúng có thể được khôi phục bằng cách sử dụng , sau đó được chuyển sang thư mục mong muốn theo cách được mô tả ở trên.

Đối với điều này:

Khôi phục các bảng cơ sở dữ liệu MySQL bị hỏng bằng myisamchk

Các bảng cơ sở dữ liệu MyISAM MySQL có thể bị hỏng do quá trình ghi bị gián đoạn bất ngờ hoặc do máy tính tắt, lỗi phần cứng hoặc phần mềm và cả trong trường hợp cố gắng gỡ lỗi bằng cách sử dụng myisamchk bảng được sử dụng bởi máy chủ.

Do bảng bị hỏng, dữ liệu có thể biến mất khỏi bảng hoặc hiển thị không chính xác, nhưng thông thường nhất, do bảng bị hỏng, người dùng gặp phải lỗi sau: “Tệp khóa không chính xác cho bảng: 'table_name'. Hãy cố gắng sửa chữa nó"

Để khôi phục các bảng MyISAM bị hỏng, bạn có thể sử dụng lệnh myisamchk.

Myisamchk hoạt động bằng cách gỡ lỗi và tạo bản sao của tệp .myd, sau đó thay thế tệp bị hỏng bằng tệp đó. Vì vậy, trước khi sử dụng lệnh này, tốt hơn là nên tạo trước bản sao lưu tập tin bảng cần được khôi phục.

Vì vậy, để khôi phục bảng bị hỏng, hãy sử dụng lệnh:

myisamchk -r -q TABLE_NAME

Ở đâu, -r -q- đây là chế độ khôi phục nhanh. TRONG trong trường hợp này sẽ được sửa tập tin chỉ mục mà không thay đổi tập tin dữ liệu. Nếu tệp dữ liệu chứa mọi thứ cần thiết và các liên kết từ xa trỏ tới đúng vị trí trong tệp dữ liệu, bảng sẽ được sửa do lệnh này.

Nếu lệnh trước đó không đưa ra kết quả cần thiết, sau đó tạo bản sao lưu của tệp dữ liệu và chạy lệnh:

myisamchk -r TABLE_NAME

Ở đâu, -r- đó chỉ là chế độ phục hồi. Trong trường hợp này, các mục nhập không chính xác và bị mất sẽ bị xóa khỏi tệp dữ liệu và tệp chỉ mục sẽ được tạo lại (như mô tả ở trên).

ghi chú. Nếu bạn định gỡ lỗi và khôi phục bảng từ dòng lệnh, thì trước tiên bạn phải dừng máy chủ. Cần lưu ý rằng khi chạy tắt máy mysqladmin với máy chủ từ xa mysqld sẽ vẫn chạy một lúc sau khi thoát mysqladmin, cho đến khi tất cả các truy vấn bị dừng và tất cả các khóa được chuyển vào đĩa.

Hôm nay trong bài học: MySQL.(MySQL là một hệ thống quản lý cơ sở dữ liệu miễn phí). Việc khôi phục cơ sở dữ liệu khá đơn giản nhưng để thực hiện được điều này bạn cần phải có bản sao lưu của cơ sở dữ liệu. Khi tôi gặp vấn đề với cơ sở dữ liệu, tôi không thể truy cập trang web và tất cả các bài viết của tôi đều biến mất. Tôi phải khẩn trương quyết định cách khôi phục cơ sở dữ liệu Wordpress.

Tình huống này đã xảy ra với tôi cách đây vài ngày khi tôi đang viết bài 59. Theo nghĩa đen, vài phút sau, tôi nhận được một tin nhắn SMS từ Yandex Metrica rằng trang web của tôi không khả dụng. Nếu bạn đã gặp phải vấn đề như vậy trước đây thì bạn biết cách trả lại mọi thứ về điều kiện làm việc, và nếu không, hãy đọc tiếp.

Cách khôi phục cơ sở dữ liệu WordPress (Phương pháp 1)

Hầu hết mọi người viết trên Internet cách tạo bản sao lưu cơ sở dữ liệu, nhưng ít người viết: cách khôi phục cơ sở dữ liệu Dữ liệu WordPress . Điều đó không cần thiết với cơ sở dữ liệu Vấn đề có thể phát sinh do lỗi của bạn. Lỗi có thể xảy ra trong cơ sở dữ liệu vì những lý do khác.

Nếu blog của bạn chưa cài đặt plugin hoặc plugin tương tự thì có nguy cơ bạn sẽ không có blog. Hãy tưởng tượng bạn đang viết blog trong một khoảng thời gian dài, rồi một lần, thế là xong! Amba! Plugin này sẽ ngăn điều này xảy ra. Nó giữ cơ sở dữ liệu blog của bạn vĩnh viễn trong chế độ tự động và không có sự tham gia của bạn.

Có rất nhiều thông tin về việc khôi phục cơ sở dữ liệu trên Internet, nhưng đôi khi họ viết những điều vô nghĩa như vậy khiến mọi người cũng biết ơn. Tác giả bài viết đưa ra lời khuyên về cách làm điều này điều kia một cách chính xác nhưng bản thân anh ta thậm chí còn không hiểu mình đang viết về cái gì. Thế là xong, đã đến lúc bắt tay vào công việc :)

Để đưa blog của bạn về trạng thái trước đó, bạn phải có bản sao lưu cơ sở dữ liệu mới. Giải nén tệp cơ sở dữ liệu và mở tệp đã giải nén trong sổ ghi chú Windows. Sao chép nội dung của tập tin vào . Chuyển đến bảng điều khiển trên dịch vụ lưu trữ của bạn trong PhpMyAdmin.

Bấm vào tên cơ sở dữ liệu bạn muốn khôi phục.

Sau đó, bạn cần phải bấm vào "SQL" và dán vào cửa sổ những gì bạn đã sao chép từ tệp cơ sở dữ liệu bằng cách nhấp vào " ĐIỀU KHIỂN " + "V.". Bấm sau" ĐƯỢC RỒI ".

Đợi cho đến khi quá trình khôi phục cơ sở dữ liệu hoàn tất. Một thông báo thành công sẽ xuất hiện.

Blog của bạn hiện đã được khôi phục hoàn toàn.

Cách khôi phục nhanh cơ sở dữ liệu WordPress của bạn (phương pháp 2)

Vì vậy, không cần giới thiệu không cần thiết. Đi đến lưu trữ của bạn trong bảng điều khiển(cPanel). Tìm liên kết " MySQL" hoặc " PhpMyAdmin ».

Bây giờ bạn cần đăng nhập vào bảng quản lý cơ sở dữ liệu, tức là PhpMyAdmin. Nhấp chuột " Để vào»

Bạn sẽ được đưa đến PhpMyAdmin. Ở bên trái, nhấp vào cơ sở dữ liệu bạn sẽ khôi phục. Trong trường hợp của tôi đây là cơ sở dữ liệu dvpress.

Khi bạn chọn cơ sở dữ liệu, tất cả các bảng trong cơ sở dữ liệu đó sẽ xuất hiện. Để đảm bảo không xảy ra lỗi trong quá trình khôi phục, cơ sở dữ liệu này phải được xóa hoàn toàn. Chúng tôi đi xuống tận cùng và tìm thấy “ Đánh dấu tất cả/Bỏ chọn " Bấm vào " Chọn tất cả "để tất cả các bảng cơ sở dữ liệu đều có dấu kiểm trong hộp kiểm. Chọn ở cửa sổ bên phải" Xóa bỏ"rồi xác nhận" Đúng". Cơ sở dữ liệu phải được xóa hoàn toàn khỏi tất cả các bảng.

Bây giờ nhiệm vụ của bạn là khôi phục cơ sở dữ liệu này từ bản sao lưu. Nhấp vào ở trên cùng " Nhập khẩu", sau đó nhấp vào nút" Chọn tập tin " Tìm bản sao lưu cơ sở dữ liệu trên máy tính của bạn và nhấp vào " Mở" Bây giờ trong PhpMyAdmin ở phía dưới hãy nhấp vào " ĐƯỢC RỒI" Hoạt động phải thành công, được biểu thị bằng dòng chữ “ truy vấn SQL hoàn thành thành công ».

SQL Server hỗ trợ ba nhiều loại khác nhau bản sao lưu – sao lưu toàn bộ, sao lưu khác biệt và sao lưu nhật ký giao dịch. Hai loại bản sao lưu đầu tiên có sẵn cho cơ sở dữ liệu trong bất kỳ mô hình khôi phục nào, bản sao lưu nhật ký giao dịch có sẵn cho cơ sở dữ liệu trong mô hình khôi phục FULL và BULK-LOGGED (bạn có thể đọc ngắn gọn về các mô hình khôi phục hoặc tốt hơn là trong BOL).

Nếu bạn sử dụng mô hình khôi phục SIMPLE, bạn sẽ chỉ có thể khôi phục cơ sở dữ liệu của mình từ một bản sao lưu đầy đủ (và ngoài ra, bản sao khác biệt). Bạn sẽ không bao giờ phục hồi được thời điểm trước khi xảy ra lỗi trừ khi bạn tạo bản sao lưu ngay trước khi xảy ra lỗi. Nếu cơ sở dữ liệu của bạn ở mô hình khôi phục ĐẦY ĐỦ và bạn không bao giờ sao lưu nhật ký giao dịch mà thỉnh thoảng cắt bớt nhật ký, hãy đọc tiếp để tìm hiểu xem bạn đang bỏ lỡ điều gì :).

Nếu bạn đang đọc phần này, tôi cho rằng cơ sở dữ liệu của bạn đang ở mô hình khôi phục ĐẦY ĐỦ, bạn thường xuyên thực hiện sao lưu đầy đủ và bản sao nhật ký giao dịch. Ngoài ra, "chuỗi khôi phục" của bạn từ bản sao lưu nhật ký giao dịch phải còn nguyên vẹn.

"chuỗi phục hồi" là gì?Đây là một chuỗi sao lưu liên tục bao gồm một bản sao lưu đầy đủ và một chuỗi sao lưu nhật ký giao dịch liên tục. Ví dụ: lúc 12h30 bạn đã tạo sao lưu đầy đủ(hãy gọi nó là full1), và vào lúc 12:45, 13:00 và 13:15, họ đã tạo các bản sao dự phòng của nhật ký giao dịch (trlog1, trlog2, trlog3, tương ứng). Miễn là bạn có tất cả các bản sao lưu này, bạn sẽ có thể khôi phục cơ sở dữ liệu của mình về bất kỳ thời điểm nào trong khoảng thời gian từ 12:30 đến 13:15, 12:48 chẳng hạn.

Nếu bạn xóa bản sao của trlog2 được tạo lúc 13:00, thì bản sao lưu của trlog3 (và tất cả các bản sao được tạo sau đó) sẽ hoàn toàn vô dụng - bạn có thể khôi phục về bất kỳ thời điểm nào trong khoảng thời gian từ 12:30 đến 12:45. Điều tương tự sẽ xảy ra nếu ai đó tạo một bản sao vào lúc 12.31 và xóa nó - tất cả các bản sao tiếp theo sẽ vô dụng. Để bắt đầu chuỗi khôi phục mới, bạn cần sao lưu toàn bộ và sau đó là sao lưu nhật ký giao dịch.

Có một khoảnh khắc không rõ ràng lắm (ít nhất là đối với tôi) trong tất cả những điều này. Bản sao lưu đầy đủ luôn bắt đầu nhưng không bao giờ phá vỡ chuỗi khôi phục (điều này đúng với SQL Server 2005 trở lên). Hãy xem xét điều này với một ví dụ. Ngoài các bản sao hiện có (full1, trlog1, trlog2, trlog3 - chuỗi khôi phục liên tục), chúng tôi sẽ tạo bản sao lưu đầy đủ của full2 lúc 13:30 và sao lưu nhật ký giao dịch trlog3, trlog4, trlog5 lần lượt vào lúc 13:45, 14:00 và 14:15.

Bây giờ, nếu chúng ta cần khôi phục cơ sở dữ liệu về 14.15, cách dễ nhất là sử dụng chuỗi khôi phục "mới", tức là. khôi phục full2 và “cuộn” trlog3, trlog4, trlog5 vào đó một cách tuần tự. Tuy nhiên, nếu chúng tôi không thể khôi phục từ bản sao full2 (ví dụ: đĩa chứa bản sao này đã bị phá hủy), thì chúng tôi có thể sử dụng chuỗi khôi phục “đầu tiên” của mình - khôi phục bản sao dự phòng full1 và tuần tự cuộn các bản sao của nhật ký giao dịch trlog1 , trlog2 trên đó , trlog3, trlog4, trlog5, trlog6. Theo cách tương tự, chúng ta có thể sử dụng chuỗi khôi phục đầu tiên để khôi phục cơ sở dữ liệu về 13.29 - chúng ta khôi phục full1 và cuộn lên trlog1, trlog2, trlog3 và trlog4.

Vì vậy, có một chuỗi khôi phục hoàn chỉnh, chúng ta có thể khôi phục cơ sở cần thiết dữ liệu tại bất kỳ thời điểm nào trong khoảng thời gian từ khi tạo bản sao lưu đầy đủ đến thời điểm tạo bản sao lưu cuối cùng. Một gợi ý nhỏ - nếu bạn có mô hình đầy đủ recovery, có một số bản sao lưu và không có bản sao của nhật ký giao dịch, nhưng bạn chưa bao giờ “cắt ngắn” nhật ký giao dịch - bạn có thể tạo bản sao lưu này ngay bây giờ và có thể khôi phục về bất kỳ thời điểm nào kể từ lần sao lưu đầy đủ đầu tiên và thời điểm hiện tại. Tuy nhiên, tôi nhắc lại, chỉ khi bản sao lưu nhật ký giao dịch chưa được tạo trước đó và nhật ký giao dịch chưa được cắt bớt.

Tiếp theo, tôi sẽ hướng dẫn bạn một số cách sử dụng bản sao lưu SQL Server.
Tùy chọn đầu tiên (nó hoạt động với tất cả các mô hình khôi phục) là cần thiết khôi phục cơ sở dữ liệu từ bản sao lưu đầy đủ. Mọi thứ ở đây đều đơn giản - bạn cần chạy tập lệnh T-SQL:

KHỞI LẠI CƠ SỞ DỮ LIỆU [database_name]
TỪ DISK = "đường dẫn đến bản sao lưu đầy đủ"
VỚI THAY THẾ, PHỤC HỒI, THỐNG KÊ = 10

Tham số REPLACE chỉ ra rằng nếu cơ sở dữ liệu có tên [database_name] tồn tại thì chúng tôi sẽ thay thế nội dung của nó bằng nội dung của bản sao lưu. Nếu bạn đang khôi phục cơ sở dữ liệu bằng GUI, bạn cần chỉ định “Ghi đè cơ sở dữ liệu hiện có” trên tab “Tùy chọn”.

PHỤC HỒI chỉ ra rằng cơ sở dữ liệu cần được đưa về trạng thái nhất quán và cho phép người dùng kết nối. Trong GUI, điều này tương ứng với tùy chọn “Để cơ sở dữ liệu sẵn sàng sử dụng bằng cách khôi phục các giao dịch chưa được cam kết. Nhật ký giao dịch bổ sung không thể được khôi phục." Nghĩa là, SQL Server khôi phục tất cả các giao dịch chưa được cam kết và cho phép người dùng làm việc với dữ liệu. Sau khi bạn đã khôi phục bản sao lưu từ với tham số RECOVERY, bản sao nhật ký giao dịch bổ sung và bản sao khác biệt không thể được áp dụng cho nó. Hãy cẩn thận, tùy chọn này được đặt theo mặc định và nếu bạn muốn “cuộn” một bản sao khác, quá trình khôi phục sẽ phải bắt đầu lại.

STATS = 10 có nhiệm vụ hiển thị thông tin về quá trình khôi phục. Trong trường hợp này, cứ sau 10% bản sao lưu được khôi phục, một thông báo sẽ xuất hiện trên tab Tin nhắn trong SSMS. Khi khôi phục bằng GUI, bạn không thể kiểm soát tham số này - bạn có thể theo dõi các thay đổi trong “biểu đồ” ở góc dưới bên trái.

Theo mặc định, bản sao được khôi phục về cùng vị trí nơi nó được tạo. Những thứ kia. nếu ban đầu tất cả các tệp cơ sở dữ liệu đều nằm trong thư mục C:\Database và bạn muốn khôi phục bản sao sang một vị trí khác thì bạn phải sử dụng tham số MOVE. Để sử dụng MOVE bạn cần biết tên tệp logic - chúng có thể được xem bằng cách sử dụng chế độ xem sys.database_files. Hình này cho thấy một ví dụ về việc sử dụng chế độ xem này.

Do đó, để khôi phục cơ sở dữ liệu AdventureWorks từ bản sao lưu và đồng thời di chuyển nó sang vị trí khác, bạn có thể sử dụng tập lệnh sau:

VỚI THAY THẾ, PHỤC HỒI, STATS = 10,

Nếu quá trình khôi phục được thực hiện bằng GUI, bạn phải chỉ định tên tệp mới trên tab “Tùy chọn” (bảng “Khôi phục các tệp cơ sở dữ liệu dưới dạng:”, cột “Khôi phục dưới dạng”).

Sự lựa chọn thứ hai - khôi phục từ bản sao lưu đầy đủ và tất cả các bản sao lưu nhật ký giao dịch(hoặc bản sao khác biệt).

Quá trình khôi phục luôn bắt đầu bằng việc khôi phục bản sao lưu đầy đủ, nhưng nếu bạn muốn khôi phục bất kỳ bản sao bổ sung nào sau đó, bạn cần để cơ sở dữ liệu ở trạng thái KHÔI PHỤC. Để làm điều này, chúng tôi sẽ sử dụng tập lệnh sau:

KHÔI PHỤC CƠ SỞ DỮ LIỆU
TỪ ĐĨA = "D:\backup\awfull.bak"
VỚI THAY THẾ, BÌNH THƯỜNG, STATS = 10,
DI CHUYỂN "AdventureWorks_Data" SANG "D:\database\AW_data.mdf",
DI CHUYỂN "AdventureWorks_Log" SANG "D:\database\AW_log.ldf"

Nếu sau khi thực hiện khôi phục mà bạn cố gắng truy cập vào cơ sở dữ liệu, bạn sẽ nhận được lỗi:
Cơ sở dữ liệu "AdventureWorks" không thể mở được. Nó đang trong quá trình khôi phục.
Sau khi khôi phục bản sao lưu đầy đủ, hãy khôi phục bản sao vi sai cuối cùng (nếu có):

KHÔI PHỤC CƠ SỞ DỮ LIỆU
TỪ ĐĨA = "D:\backup\awDIFF.bak"
VỚI BÌNH THƯỜNG, STATS = 10

Nếu bạn có một mô hình ĐƠN GIẢN, bạn có thể dừng ở đây - bạn sẽ không làm gì khác. Nếu bạn có một mô hình ĐẦY ĐỦ, bạn có thể bổ sung khôi phục bản sao lưu nhật ký giao dịch:

KHÔI PHỤC NHẬT KÝ
TỪ ĐĨA = "D:\backup\awlog1.trn"
VỚI BÌNH THƯỜNG
….
KHÔI PHỤC NHẬT KÝ
TỪ ĐĨA = "D:\backup\awlog12.trn"
CÓ PHỤC HỒI

Ghi chú, bản sao mới nhất phải được khôi phục với tham số RECOVERY. Nếu cơ sở dữ liệu vẫn ở trạng thái KHÔI PHỤC, nó có thể được đưa vào trạng thái hoạt động và không có bản sao lưu:

KHÔI PHỤC CƠ SỞ DỮ LIỆU
CÓ PHỤC HỒI

Sau đó, cơ sở dữ liệu sẽ “hoạt động trở lại”.
Tùy chọn thứ ba - thời điểm phục hồi. Tôi có cơ sở dữ liệu AdventureWorks, một bản sao lưu đầy đủ của nó và một bản sao lưu nhật ký giao dịch từ trước đó. Kết quả của yêu cầu

LỰA CHỌN *
TỪ Person.AddressType

thể hiện trong hình:

Lúc 13.46 bảng này đã bị xóa. Truy vấn tương tự bây giờ trả về:
Tên đối tượng không hợp lệ "Person.AddressType"
Để trả mọi thứ về vị trí của nó, trước hết chúng tôi tạo một bản sao lưu của nhật ký giao dịch:

NHẬT KÝ SAO LƯU
ĐẾN ĐĨA = "D:\backup\awlog2.trn"

Sau khi tạo bản sao, hãy khôi phục bản sao lưu đầy đủ và bản sao lưu nhật ký giao dịch đầu tiên (cả hai đều có tham số BÌNH THƯỜNG).
Bây giờ hãy khôi phục bản sao lưu cuối cùng được tạo SAU KHI bảng bị xóa:

KHÔI PHỤC NHẬT KÝ
VỚI PHỤC HỒI, DỪNG = "09/10/2010 13:45"
(ngày ở đây được chỉ định ở định dạng "MM/DD/YYYY HH:MM")
Sau đó, truy vấn ban đầu trả về kết quả bình thường, bảng đã được khôi phục.

Một lựa chọn khác để phục hồi dữ liệu. Câu chuyện cuộc sống :).
Một vài tháng trước, chúng tôi thấy mình ở trong một tình huống không mấy dễ chịu - các mục nhập vào một trong các sổ đăng ký thông tin (định kỳ, không phụ thuộc vào cơ quan đăng ký) đã bị “hỏng”. Nghĩa là, chúng dường như vẫn còn, nhưng chúng đã mất đi ý nghĩa. Sổ đăng ký rất lớn và cần thiết. Lỗi xảy ra cách đây vài giờ nên không thể khôi phục hoàn toàn cơ sở dữ liệu. Họ định truyền dữ liệu bằng cách sử dụng quá trình xử lý Tải lên dữ liệu XML, nhưng các lập trình viên đã yêu cầu thử truyền dữ liệu bằng SQL với hy vọng rằng việc này sẽ nhanh hơn.

Chúng tôi đã khôi phục bản sao của cơ sở dữ liệu từ bản sao lưu về thời điểm trước khi dữ liệu bị hỏng. Sử dụng chức năng “GetDatabaseStorageStructure”, chúng tôi đã tìm ra tên của thanh ghi thông tin trong cơ sở dữ liệu - _InfoReg4452 (ví dụ: tôi không nhớ chính xác). Chúng tôi đã xóa sổ đăng ký “bị hỏng” này trong cơ sở dữ liệu chính bằng TRUNCATE TABLE _InfoReg4452.
Trên bản sao của cơ sở dữ liệu, chúng tôi đã chọn NHIỆM VỤ -> Xuất dữ liệu, một bản sao có thanh ghi bình thường được chỉ định làm nguồn, máy chủ đang hoạt động và cơ sở dữ liệu đang hoạt động (có thanh ghi đã bị xóa) làm đích. Trên trang chọn đối tượng, chúng tôi chỉ chọn một – bảng chúng tôi cần:

Thêm hai cú click chuột nữa là xong. Bàn đã được dời đi, mọi người tiếp tục làm việc.
Tôi muốn thu hút sự chú ý của bạn đến một số sắc thái. Thứ nhất, nếu bạn không xóa bảng đích, tất cả dữ liệu sẽ vẫn còn trong đó và dữ liệu mới có thể không xuất hiện. Thứ hai, phương pháp này có thể phù hợp với một số thanh ghi và thư mục thông tin, nhưng đối với các bảng có chuyển động được thực hiện hoặc các đối tượng thực hiện chuyển động, sẽ cần phải khôi phục nhiều bảng bổ sung– Hãy suy nghĩ 100 lần trước khi sử dụng phương pháp này. Vâng, nói chung, phương pháp này đi ngược lại thỏa thuận cấp phép, nhưng nó nhanh chóng và thuận tiện trong một số trường hợp.
Tôi hy vọng thông tin này hữu ích với ít nhất một ai đó.

tái bút Đừng tin lời tôi - hãy thử làm tất cả những điều này trên bản sao của bạn!

Dành cho nhà phát triển và quản trị viên Microsoft SQL Máy chủ khá thường xuyên có nhu cầu phát sinh khôi phục cơ sở dữ liệu từ kho lưu trữ(sao lưu), ví dụ: để tạo một bản sao của cơ sở dữ liệu sẽ được sử dụng để kiểm tra ứng dụng hoặc ví dụ: bạn đã cài đặt lại hệ điều hành và bạn cần khôi phục cơ sở dữ liệu, đó chính xác là những gì chúng ta sẽ làm hôm nay.

Trong bài viết này, chúng ta sẽ xem xét việc khôi phục cơ sở dữ liệu bằng cách sử dụng DBMS làm ví dụ. Máy chủ Microsoft SQL 2000. Để khôi phục cơ sở dữ liệu, bạn cần có một kho lưu trữ cơ sở dữ liệu này. Nó được tạo với phần mở rộng *.dat. Tôi khuyên mọi người nên tạo kho lưu trữ cơ sở dữ liệu của mình và lưu trữ hàng ngày; nếu có bất kỳ điều gì xảy ra, bạn sẽ luôn có một kho lưu trữ để khôi phục.

Mô tả quá trình khôi phục cơ sở dữ liệu từ Sao lưu

Hãy bắt đầu, mở Enterprise Manager, chọn cơ sở dữ liệu mà bạn muốn khôi phục hoặc nếu bạn vừa cài đặt DBMS và chưa có cơ sở dữ liệu nào ở đó thì chỉ cần tạo cơ sở dữ liệu và khôi phục nó từ kho lưu trữ. Mở thực đơn " Công cụ->Khôi phục cơ sở dữ liệu"và cửa sổ sau sẽ mở ra:

Lựa chọn " Từ thiết bị" và nhấp vào " Chọn thiết bị».

(biểu ngữ vị trí tải3

Bấm OK và trong phần “ Chọn Khôi phục cơ sở dữ liệu» cũng nhấp vào OK. Và trong cửa sổ chính " Khôi phục cơ sở dữ liệu"Đừng vội bấm OK, hãy vào tab " Tùy chọn» và tích vào ô như trong hình.

Ngoài ra, ở đây hãy đặt đường dẫn cho các tệp cơ sở dữ liệu, vì nó có thể không chính xác và bạn có thể ghi đè, ví dụ: cơ sở hiện có data, nếu bạn tạo một bản sao của cơ sở dữ liệu và nếu bạn vừa cài đặt mọi thứ (DBMS) thì bạn không phải thay đổi nó.

Thế là xong, sau đó bạn có thể nhấn OK. Sau một thời gian, cơ sở dữ liệu sẽ được khôi phục và bạn có thể sử dụng nó.

Nhân tiện, nếu có ai quan tâm Ngôn ngữ T-SQL (là phần mở rộng của ngôn ngữ SQL trong Microsoft SQL Server), thì tôi có thể giới thiệu cuốn sách “ Con đường của lập trình viên T-SQL. Hướng dẫn ngôn ngữ Transact-SQL", sau khi đọc xong bạn sẽ có thể dễ dàng lập trình trong T-SQL.

Điều tôi đăng tuần trước dường như đã khơi dậy một số sự quan tâm, nhưng than ôi, nó không chứa “thực hành”. Có, nó nói cách bạn có thể lưu dữ liệu, nhưng không có ví dụ nào cả.
Ban đầu, tôi muốn thực hiện một bản dịch khác của cùng một tác giả, nhưng sau khi suy nghĩ kỹ, tôi quyết định viết một bài “của riêng mình”, như thể “dựa trên đó”. Tôi sẽ mô tả lý do thôi thúc tôi làm điều này ở cuối bài, trong phần ghi chú.

Khôi phục cơ sở dữ liệu trong SQL Server

Như đã đề cập trong bài viết trước, nếu các trang thuộc chỉ mục hoặc vùng nhớ cụm bị hỏng thì dữ liệu chứa trên các trang này sẽ bị mất và lựa chọn duy nhất để khôi phục chúng là khôi phục trực tiếp cơ sở dữ liệu.

SQL Server cung cấp nhiều tùy chọn để phục hồi cơ sở dữ liệu. Thứ nhất, đây là quá trình khôi phục toàn bộ cơ sở dữ liệu - có thể mất khá nhiều thời gian (tùy thuộc vào kích thước của cơ sở dữ liệu và tốc độ cứngđĩa). Thứ hai, khôi phục các nhóm tệp riêng lẻ hoặc các tệp nếu cơ sở dữ liệu của bạn bao gồm một số nhóm tệp (hoặc theo đó là các tệp). Trong trường hợp này, chỉ có thể khôi phục những phần cơ sở dữ liệu bị hỏng mà không ảnh hưởng đến phần còn lại. Hai kiểu phục hồi cơ sở dữ liệu này được sử dụng khá thường xuyên và sẽ không được thảo luận thêm.
Thứ ba, SQL Server 2005 giới thiệu khả năng khôi phục các trang riêng lẻ DB - trong trường hợp này, chỉ trang được chỉ định. Việc khôi phục như vậy sẽ đặc biệt quan trọng nếu DBCC CHECKDB tìm thấy một số trang bị hỏng trong một bảng lớn nào đó “nằm” trong một tệp nặng. Do thực tế là không phải toàn bộ tệp và thậm chí không phải toàn bộ bảng mà chỉ một số trang sẽ được khôi phục nên thời gian ngừng hoạt động có thể giảm đáng kể.

Yêu cầu và hạn chế

Mô hình khôi phục và tính khả dụng của bản sao lưu nhật ký giao dịch

Điều quan trọng nhất cần nhớ là để khôi phục từng trang riêng lẻ, cơ sở dữ liệu phải sử dụng mô hình khôi phục được ghi nhật ký đầy đủ hoặc hàng loạt. Nếu cơ sở dữ liệu của bạn ở mô hình khôi phục đơn giản thì bạn không cần phải đọc thêm.
Yêu cầu thứ hai là các bản sao lưu nhật ký giao dịch và đầy đủ của bạn phải tạo thành một chuỗi nhật ký không bị gián đoạn. Nếu bạn không bao giờ đưa ra lệnh BACKUP LOG WITH TRUNCATE_ONLY (NO_LOG) và chuyển sang mô hình đơn giản recovery để giảm nhật ký giao dịch và bạn có TẤT CẢ các bản sao lưu nhật ký giao dịch kể từ lần sao lưu đầy đủ cuối cùng không chứa các trang bị hỏng (bao gồm cả bản sao lưu hoàn chỉnh nhất đó) - bạn không phải lo lắng về chuỗi nhật ký.
Về lý thuyết, trong mô hình khôi phục được ghi nhật ký hàng loạt, việc khôi phục trang riêng lẻ sẽ hoạt động tốt miễn là các điều kiện được mô tả ở trên được đáp ứng và các trang đang được khôi phục chưa bị sửa đổi bởi các hoạt động được ghi nhật ký trần.

Phiên bản máy chủ SQL

Có thể khôi phục các trang trong bất kỳ phiên bản SQL Server nào, nhưng đối với Phiên bản doanh nghiệp và Phiên bản dành cho nhà phát triển, có thể khôi phục các trang bị hỏng trực tuyến, tức là. cơ sở dữ liệu có thể được truy cập trong quá trình khôi phục (và hơn thế nữa, bạn thậm chí có thể truy cập vào bảng đang được khôi phục trong khoảnh khắc này các trang, nếu bản thân các trang này sẽ không được "chạm" - nếu không, yêu cầu sẽ không thành công). Đối với các phiên bản “dưới” Enterprise Edition, quá trình khôi phục trang diễn ra ngoại tuyến và cơ sở dữ liệu sẽ không thể truy cập được trong thời gian khôi phục.

Loại trang bị hỏng

Nếu các trang chỉ mục hoặc dữ liệu bị hỏng, chúng có thể được khôi phục trực tuyến trong Phiên bản Doanh nghiệp.
Các trang thuộc bảng hệ thống quan trọng có thể được khôi phục nhưng cơ sở dữ liệu khi được khôi phục sẽ không có sẵn trong bất kỳ phiên bản SQL Server nào.
"Thẻ vị trí" không thể được khôi phục "riêng". Nếu các trang GAM, SGAM, PFS, ML, DIFF bị hỏng thì cần phải khôi phục toàn bộ cơ sở dữ liệu. Ngoại lệ duy nhất là các trang IAM. Mặc dù chúng được phân loại là "bản đồ vị trí", nhưng chúng chỉ mô tả một bảng chứ không phải toàn bộ cơ sở dữ liệu và chúng có thể được khôi phục.
Trang tải cơ sở dữ liệu (trang thứ 9 trong tệp cơ sở dữ liệu thứ 1) và trang tiêu đề tệp (trang thứ 0 trong mỗi tệp) không thể khôi phục “riêng biệt”; nếu chúng bị hỏng thì phải khôi phục toàn bộ cơ sở dữ liệu.

Trên thực tế, việc khôi phục

Bây giờ, cuối cùng, chúng ta chuyển từ lý thuyết sang thực hành.
Trước hết, để đào tạo, bạn cần có một cơ sở dữ liệu bị hỏng.

Chuyển cơ sở dữ liệu

Đối với các thử nghiệm của mình, tôi sẽ sử dụng cơ sở dữ liệu AdventureWorks đi kèm với SQL Server. Nếu bạn chưa cài đặt nó, bạn có thể tải xuống nếu muốn. Tôi dịch nó sang mô hình khôi phục đầy đủ:
THAY ĐỔI CƠ SỞ DỮ LIỆU AdventureWorks SET RECOVERY FULL Tôi đảm bảo rằng không có lỗi nào trong đó:
DBCC CHECKDB("AdventureWorks") VỚI NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY và tạo bản sao lưu đầy đủ:
SAO LƯU CƠ SỞ DỮ LIỆU AdventureWorks TO DISK = "D:\tmp\aw_backups\aw_full_ok1.bak"

Trong cơ sở dữ liệu này, tôi tạo một bảng sự cố.
TẠO BẢNG sự cố (txt varchar(1000)) Chúng tôi sẽ làm hỏng trường loại varchar để kiểm tra xem điều gì sẽ xảy ra nếu SQL Server đột nhiên tìm thấy trong đó dữ liệu không giống với những gì nó đã viết ở đó.
Trước khi làm hỏng thứ gì đó, bạn cần lấp đầy nó bằng thứ gì đó. Tôi nhập dữ liệu bên trái vào bảng đã tạo.
THIẾT LẬP NOCOUNT TRÊN KHAI THÁC @i INT SET @i = 1 WHILE @i<100000 BEGIN INSERT INTO crash SELECT REPLICATE("a", 1000) SET @i = @i + 1 END SET NOCOUNT OFF Теперь делаю резервную копию журнала транзакций:
NHẬT KÝ SAO LƯU AdventureWorks VÀO DISK = "D:\tmp\aw_backups\aw_log_ok1.trn"

Bây giờ hãy thay đổi dữ liệu một chút:

Vậy là mọi thứ đã sẵn sàng. Chúng tôi ngắt kết nối cơ sở dữ liệu và mở tệp mdf bằng FAR (hoặc bất cứ điều gì thuận tiện hơn cho bạn), tìm dòng “zzzzzzz” trong đó và thay thế một số “z” bằng các ký tự tùy ý:

Bây giờ cơ sở dữ liệu bị hỏng, chúng tôi kết nối nó. Và vâng, tôi nhớ rằng trong bài viết trước đã nêu rõ rằng bạn không nên tách/đính kèm cơ sở dữ liệu. Nhưng trong trường hợp của chúng tôi, nó hoàn toàn “an toàn” - cơ sở dữ liệu trong “nghi ngờ” sẽ không bị mất.

Đang tìm kiếm lỗi

Vì vậy, cơ sở dữ liệu bị hỏng đã hoạt động trở lại thành công. Hãy chạy lại kiểm tra tính toàn vẹn:
DBCC CHECKDB("AdventureWorks") VỚI NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY Kết quả là những gì chúng tôi đang chờ đợi ( Hãy nhớ nhớ số lượng trang bị hư hỏng!):

Msg 8928, Cấp 16, Bang 1, Dòng 1
ID đối tượng 1883153754, ID chỉ mục 0, ID phân vùng 72057594054246400, ID đơn vị phân bổ 72057594061651968 (loại dữ liệu liên tiếp): Không thể xử lý trang (1:20455). Xem các lỗi khác để biết chi tiết.
Msg 8939, Cấp 16, Tiểu bang 98, Dòng 1
Lỗi bảng: ID đối tượng 1883153754, ID chỉ mục 0, ID phân vùng 72057594054246400, ID đơn vị phân bổ 72057594061651968 (loại dữ liệu trong hàng), trang (1:20455). Kiểm tra (IS_OFF (BUF_IOERR, pBUF->bstat)) không thành công. Giá trị là 29493257 và -4.
CHECKDB tìm thấy 0 lỗi phân bổ và 2 lỗi nhất quán trong bảng "sự cố" (ID đối tượng 1883153754).
CHECKDB tìm thấy 0 lỗi phân bổ và 2 lỗi nhất quán trong cơ sở dữ liệu "AdventureWorks".
repair_allow_data_loss là mức sửa chữa tối thiểu cho các lỗi được tìm thấy bởi DBCC CHECKDB (AdventureWorks).
Trong trường hợp này, bản thân dữ liệu nằm trong heap (index id = 0) bị hỏng nên SQL Server sẽ không thể khôi phục dữ liệu này.
Hiện giờ chúng ta có ba lựa chọn:

Chấp nhận mất dữ liệu và chạy DBCC CHECKDB("AdventureWorks", REPAIR_ALLOW_DATA_LOSS)
Tạo bản sao lưu phần hoạt động của nhật ký giao dịch và khôi phục toàn bộ cơ sở dữ liệu - kết quả là sẽ không mất dữ liệu nhưng sẽ mất nhiều thời gian
Tạo bản sao lưu phần hoạt động của nhật ký giao dịch và chỉ khôi phục một trang bị hỏng (!)

Với tùy chọn thứ hai, mọi thứ sẽ rõ ràng, nhưng tôi sẽ chỉ ra điều gì sẽ xảy ra nếu bạn chạy DBCC CHECKDB hoặc cách khôi phục các trang riêng lẻ.

Khôi phục một trang bị hỏng

Trước hết, chúng ta cần tạo một bản sao lưu đoạn cuối cùng của nhật ký giao dịch (sao lưu đuôi). Đồng thời, nếu bạn có Phiên bản doanh nghiệp, bạn không phải thêm tham số BÌNH THƯỜNG, tham số này sẽ đặt cơ sở dữ liệu ở trạng thái "khôi phục", vì phiên bản này hỗ trợ khôi phục trang trực tuyến. Hơn nữa, nếu bạn thực hiện sao lưu nhật ký giao dịch thường xuyên để không làm gián đoạn chuỗi nhật ký, thì trong Phiên bản doanh nghiệp, bạn có thể tạo bản sao lưu COPY_ONLY.
Tôi đi theo con đường phục hồi ngoại tuyến và thực hiện:
NHẬT KÝ SAO LƯU AdventureWorks ĐẾN DISK = "D:\tmp\aw_backups\aw_log_fail3.trn" VỚI BÌNH THƯỜNG

Bây giờ, bạn có thể khôi phục trang bị hỏng. Trước hết, chúng tôi sử dụng bản sao lưu đầy đủ (aw_full_ok1.bak):

KHÔI PHỤC CƠ SỞ DỮ LIỆU AdventureWorks TRANG = "1:20455" TỪ DISK = "D:\tmp\aw_backups\aw_full_ok1.bak" VỚI BÌNH THƯỜNG
Kết quả là chúng ta có:

Xin lưu ý rằng bạn cần sử dụng tùy chọn BÌNH THƯỜNG vì chúng tôi vẫn phải đưa các bản sao lưu nhật ký giao dịch vào đó.
KHÔI PHỤC NHẬT KÝ AdventureWorks TỪ DISK = "D:\tmp\aw_backups\aw_log_ok1.trn" VỚI BÌNH THƯỜNG và
KHÔI PHỤC NHẬT KÝ AdventureWorks TỪ DISK = "D:\tmp\aw_backups\aw_log_fail3.trn" VỚI PHỤC HỒI

Mọi thứ dường như đã diễn ra tốt đẹp, hãy chạy DBCC CHECKDB và...

Việc khôi phục đã thành công.
Xin lưu ý rằng thời gian ngừng hoạt động giảm do thực tế là từ một bản sao lưu đầy đủ, chúng tôi không khôi phục toàn bộ cơ sở dữ liệu mà chỉ khôi phục các trang bị hỏng (nếu tôi đã khôi phục toàn bộ bản sao lưu, bản sao lưu sẽ được khôi phục sau 8,5 giây, nhưng tốc độ càng lớn kích thước cơ sở dữ liệu, sẽ có sự khác biệt về thời gian lớn hơn). Những người may mắn có SQL Server Enterprise Edition sử dụng khôi phục trực tuyến cũng sẽ tiết kiệm thời gian khôi phục từ bản sao lưu nhật ký và với khôi phục ngoại tuyến, than ôi, nhật ký sẽ được xử lý toàn bộ.
Cũng cần nói thêm rằng trong SQL Server 2005, 2008, 2008 R2, chỉ có thể khôi phục một trang bằng T-SQL; trong Denali, bạn có thể thực hiện việc này thông qua GUI.

Nhưng nếu đó là DBCC CHECKDB thì sao?

Để đề phòng, tôi quyết định kiểm tra xem SQL Server sẽ làm gì nếu tôi chạy DBCC CHECKDB với tham số REPAIR_ALLOW_DATA_LOSS. Vẫn lỗi tương tự:

Đầu tiên, chúng ta chuyển cơ sở dữ liệu sang chế độ SINGLE_USER:
THAY ĐỔI CƠ SỞ DỮ LIỆU AdventureWorks SET SINGLE_USER Và sau đó, chúng tôi bắt đầu quá trình khôi phục:
DBCC CHECKDB("AdventureWorks", REPAIR_ALLOW_DATA_LOSS) VỚI NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY Kết quả là:
Sửa chữa: Trang (1:20455) đã được hủy phân bổ khỏi ID đối tượng 1883153754, ID chỉ mục 0, ID phân vùng 72057594054246400, ID đơn vị phân bổ 72057594061651968 (loại dữ liệu trong hàng).
Đúng, SQL Server đã xóa trang "bị hỏng". Chúng tôi chuyển cơ sở dữ liệu sang chế độ MULTI_USER để mọi người có thể truy cập được và kiểm tra những gì còn thiếu:

Xét rằng kích thước trang trong SQL Server là 8KB và dữ liệu người dùng có sẵn ít hơn một chút, mọi thứ đều tự nhiên, bảng đã “giảm cân” 7 bản ghi (lúc đầu có 99999). Vì không có chỉ mục nhóm trên bảng này nên dữ liệu có thể được lưu trữ theo thứ tự ngẫu nhiên, tức là. chúng tôi thậm chí không thể biết dữ liệu nào sẽ bị mất.

Vậy tại sao rốt cuộc lại không phải là một bản dịch?

Vậy tại sao đây không phải là bản dịch mà là một bài viết “dựa trên”? Thực tế là bài viết “Khôi phục trang” của tác giả Gail Shaw không được công bố rộng rãi. Có một phần như vậy trong cuốn sách SQL Server MVP Deep Dives vol.2, được bán với số tiền khá lớn (nhưng, tất nhiên, có thể dễ dàng tìm thấy trên Internet) và tôi không chắc rằng việc xuất bản bản dịch ừm... đúng hay gì đó.
Nói chung, tôi đã đọc bài báo, ghi lại những điểm chính, sau đó tự viết văn bản và đồng thời tiến hành một thử nghiệm phục hồi. Tôi hy vọng kinh nghiệm này hữu ích cho ai đó.
Và, các quý ông, tôi chân thành hy vọng rằng nếu các bạn quyết định lặp lại thử nghiệm này, các bạn sẽ cực kỳ cẩn thận (ví dụ: bạn sẽ không thử nghiệm với cơ sở dữ liệu chính trên máy chủ sản xuất). Hãy nhớ rằng tôi không chịu bất kỳ trách nhiệm nào về hành động của bạn.