SQL Server Archives

CÁCH FIX LỖI SQL DATABASE IN RECOVERY MODE

Ngữ cảnh lỗi.

Máy chủ đang chạy SQL Server bị ngắt điện đột ngột sẽ bị lỗi databases vì dữ liệu đang ghi log chưa checkpoint cho nên sẽ bị in recovery mode hoặc recovery pending.

Kết quả chúng ta không thể truy cập như hình.

Kiểm tra tình trạng hay trạng thái databases

SELECT name, state_desc from sys.databases

Dùng lệnh bên dưới để kiểm tra

Một số trạng thái của dữ liệu như sau:

ONLINE
RESTORING
RECOVERING
RECOVERY_PENDING
SUSPECT
EMERGENCY
OFFLINE
COPYING
OFFLINE_SECONDARY

Trạng thái chúng ta đang bị là Recovering

Nguyên nhân gây lỗi

Một số nguyên nhân sư sau:

Máy chủ SQL bị tắt do lỗi. Nó có thể là phần cứng, sức mạnh hoặc thứ gì khác.
Đĩa có thể bị thiếu.
Tệp MDF hoặc LDF có thể bị thiếu
Đĩa đầy
Quá trình nâng cấp SQL không diễn ra tốt đẹp hoặc bị gián đoạn.
Sự thay đổi lớn đang được đưa ra nhưng có điều gì đó đã thất bại giữa chừng, chẳng hạn như những thay đổi đối với tính năng FileStream.
Tệp LDF (nhật ký) bị hỏng.
Tệp MDF (dữ liệu) bị hỏng. Tệp db của tệp MDF có thể bị hỏng vì nhiều lý do như sự cố đĩa hoặc SAN, lỗi phần cứng, vi rút, v.v.
Máy chủ đã khởi động lại và có gì đó đã thay đổi, chẳng hạn như thiếu đĩa hoặc thư mục hoặc thiếu quyền.
Cryptoware đã mã hóa các tệp SQL của bạn.

Cách xử lý

Trường hợp 1: Set Database state to ONLINE

Lỗi do disk full thì không thể set online cũng như start chúng ta phải mở rộng disk trước khi thực hiện.

ALTER DATABASE ‘AdventureWorks2019’ SET ONLINE;

DBCC CHECKDB(‘AdventureWorks2019’) WITH NO_INFOMSGS;

Trường hợp 2: Rebuilding lại log file và detach và attach file

Nôm na là setup mode emergency, sau đó detach, attach lại.

ALTER DATABASE [AdventureWorks2019] SET EMERGENCY;

ALTER DATABASE [AdventureWorks2019] set MULTI_USER;

EXEC sp_detach_db '[AdventureWorks2019]';

EXEC sp_attach_single_file_db @DBName = '[AdventureWorks2019]', @physname = N'MDF_FILE_FULL_PATCH';

Trường hợp 3: Initiate DBCC CHECKDB with REPAIR option

Admin bị và xử lý theo cách 3 sẽ ok chúng ta có thể rơi vào từng trường hợp để test nhé.
Trường hợp này có thể bị mất dữ liệu, tốt nhất có thể chuẩn bị bản backup, trước khi thao tác.
Hãy chắc chắn rằng bạn có một bản sao lưu. Đừng làm điều này trên db DUY NHẤT mà bạn có, vì sau khi sửa chữa hoàn tất, bạn có thể mất dữ liệu và bạn có thể không thích những gì đã bị mất!
DBCC CHECKDB với tùy chọn SỬA CHỮA là một giao dịch được ghi lại và có thể phục hồi. Điều đó có ý nghĩa gì với bạn? Điều đó có nghĩa là nếu bạn gói DBCC CHECKDB với REPAIR vào một giao dịch (thực thi BEGIN TRANSACTION trước khi chạy lệnh) và bạn không thích kết quả cuối cùng, thì bạn có thể hoàn nguyên giao dịch và quay lại nơi bạn đã bắt đầu. Bằng cách đó, bạn sẽ có thể Khôi phục các thao tác sửa chữa nếu cần thiết.
3.1. REPAIR_REBUILD
Có nhiều cấp độ sửa chữa khác nhau. Hãy thử bắt đầu với “REPAIR_REBUILD”, thực hiện sửa chữa mà không có khả năng mất dữ liệu:
1. Đặt cơ sở dữ liệu ở chế độ một người dùng
2. Chạy DBBC CHECKDB với “REPAIR_REBUILD”
3. Đặt cơ sở dữ liệu thành “online” và kích hoạt lại chế độ nhiều người dùng

Câu lệnh bên dưới lưu ý thay databases của các bạn vào nhé:

ALTER DATABASE DATABASENAME SET SINGLE_USER;

DBCC CHECKDB (DATABASENAME, REPAIR_REBUILD) WITH NO_INFOMSGS, ALL_ERRORMSGS;

ALTER DATABASE [DATABASENAME] SET ONLINE;

ALTER DATABASE [DATABASENAME] SET MULTI_USER;

Nếu sửa chữa thành công, cơ sở dữ liệu có thể được đặt lại về chế độ nhiều người dùng. Nếu không, mức độ sửa chữa “REPAIR_ALLOW_DATA_LOSS” là tùy chọn tiếp theo.

3.2. REPAIR_ALLOW_DATA_LOSS

Bước này có thể bị mất dữ liệu nhé 😊

Đặt cơ sở dữ liệu ở chế độ Khẩn cấp
Chạy DBBC CHECKDB với “REPAIR_ALLOW_DATA_LOSS”
Đặt cơ sở dữ liệu thành “ONLINE” và kích hoạt lại chế độ nhiều người dùng

Code Sql:

ALTER DATABASE [DATABASENAME] SET EMERGENCY;

ALTER DATABASE [DATABASENAME] SET SINGLE_USER;

DBCC CHECKDB (DATABASENAME,REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;

ALTER DATABASE [DATABASENAME] SET ONLINE;

ALTER DATABASE [DATABASENAME] SET MULTI_USER;