Suửa lỗi không nhận được database trong sql năm 2024

9. Vấn đề đặt ra

• Trong quá trình làm việc, có một lần sau sự cố cúp điện đột ngột, tôi khởi động lại máy và phát hiện Database của mình đã chuyển sang trạng thái Suspect.
• Tôi không thể thực hiện bất kỳ câu truy vấn gì với Database này, và bản Backup gần nhất được thực hiện cách đây đã mấy ngày, trong khi tôi lại muốn làm việc với dữ liệu mới nhất. Vậy làm thế nào giải quyết sự cố Database bị Suspect.

II. Giải pháp

• Câu trả lời là chuyển Database sang trạng thái khẩn cấp (Emergency State) và bắt đầu các thao tác sửa chữa Database.
• Trạng thái khẩn cấp được giới thiệu từ phiên bản SQL Server 2005. Nó hữu dụng khi ta phải làm việc với một Database đang bị SQL Server đánh dấu là không đáng tin cậy (Suspect).
• Trong quy trình giải quyết các sự cố đã xảy đến với Database, trạng thái khẩn cấp cung cấp một vài tính năng linh động cho ta làm việc với một Database bị hư hay bị đánh dấu là không đáng tin cậy. Khi một Database được đặt vào trạng thái khẩn cấp, có 3 thay đổi chính trong cấu hình của Database này:
  • Database trở thành READ ONLY
  • Chỉ cho các user cấp cao nhất (như sa) truy cập
  • Không cho đăng nhập vào (vì nó đang ở trạng thái READ ONLY)
• Ở trạng thái khẩn cấp, ta có thể truy cập dữ liệu, và có thể Export dữ liệu sang một Database khác, hay ta cũng có thể chạy DBCC CHECKDB trên Database này để sửa các lỗi đang tồn tại.

III. Thực hành

• Để minh họa sự hữu ích của trạng thái khẩn cấp, ta cùng theo dõi bài thực hành sau đây, được thực hiện trên SQL Server 2008:
• Trước hết tôi tạo một Database và làm cho SQL Server đánh giá nó là không đáng tin cậy

–Tạo 1 Database tên là DBEmergency CREATE DATABASE DBEmergency GO USE DBEmergency GO –Tạo 1 Table tên là tblTest với 2 cột Number, Name CREATE TABLE tblTest (Number TINYINT, Name VARCHAR(15)) GO –Insert 5 dòng vào Table tblTest INSERT INTO tblTest (Number, Name) SELECT 1, ‘One’ UNION ALL SELECT 2, ‘Two’ UNION ALL SELECT 3, ‘Three’ UNION ALL SELECT 4, ‘Four’ UNION ALL SELECT 5, ‘Five’ GO

• Sau đó tôi làm tiếp các bước sau:
  • Stop SQL Server Service
  • Mở file ldf của Database DBEmergency bằng notepad, sửa một vài dòng và lưu, đóng file lại.
• Start SQL Server Service.
• Bây giờ ta thấy Database đã ở trạng thái không đáng tin cậy (Suspect). Ta cũng có thể dùng T-SQL để xác nhận điều này

SELECT DATABASEPROPERTYEX (‘DBEmergency’, ‘STATUS’) AS ‘DBStatus’

• Và ở trạng thái này, ta không thể thực hiện bất kỳ câu truy vấn nào.

• Tiếp theo tôi chuyển Database sang trạng thái Emergency

ALTER DATABASE DBEmergency SET EMERGENCY GO Ta sẽ thấy như sau:

• Bây giờ ta sẽ dùng lệnh DBCC CHECKDB với tùy chọn REPAIR_ALLOW_DATA_LOSS để sửa lỗi cho Database này. Khi ta dùng REPAIR_ALLOW_DATA_LOSS, dữ liệu hay những Index bị hư sẽ bị loại bỏ khỏi Database để bảo đảm tính nhất quán. Nếu như những vấn đề phát sinh là do sự cố liên quan đến Transaction Log File, quá trình này sẽ tạo lại log file, ta đang ở trong trường hợp này
• Chạy đoạn script sau:

–Để sửa lỗi Database, ta cần chuyển sang chế độ Single User ALTER DATABASE DBEmergency SET SINGLE_USER WITH ROLLBACK IMMEDIATE GO –Bắt đầu sửa lỗi cho Database DBCC CHECKDB (DBEmergency, REPAIR_ALLOW_DATA_LOSS) GO –Thiết lập Database trở lại trạng thái bình thường ALTER DATABASE DBEmergency SET MULTI_USER WITH ROLLBACK IMMEDIATE GO ALTER DATABASE DBEmergency SET ONLINE GO

• Như vậy là ta đã hoàn thành việc khắc phục một Database bị sự cố Suspect. Kết quả như sau:

• Mặc dù trạng thái khẩn cấp là một giải pháp tuyệt vời đưa Database của chúng ta trở lại trạng thái họat động bình thường, nhưng đây không phải cách tiếp cận cho Database lớn hơn. Điều quan trọng ta cần ghi nhớ là cần có một chiến lược hiệu quả cho việc Backup dữ liệu.
• Khi một Database đang ở trạng thái RESTORING, thì không thể chuyển sang trạng thái EMERGENCY, tương tự là các trạng thái OFFLINE, ONLINE.

Kiến thức bài viết được tham khảo từ mssqltips.com