SQL Server Cơ sở dữ liệu đang ở chế độ phục hồi? Nhận ngay 10 bản sửa lỗi đã được chứng minh! Giải pháp từng bước từ sửa lỗi đơn giản đến sửa chữa nâng cao.
1. Hiểu về SQL Server Chế độ phục hồi cơ sở dữ liệu
1.1 Chế độ phục hồi là gì trong SQL Server
Khi một SQL Server cơ sở dữ liệu hiển thị trạng thái "Đang khôi phục", điều đó có nghĩa là SQL Server đang thực hiện khôi phục sự cố hoặc khôi phục giao dịch để đảm bảo tính nhất quán của cơ sở dữ liệu. Quy trình tự động này duy trì tính toàn vẹn của dữ liệu bằng cách phát lại các giao dịch đã cam kết và khôi phục các giao dịch chưa cam kết.
Chế độ phục hồi thường xảy ra sau khi tắt máy đột ngột, mất điện hoặc trong quá trình khôi phục cơ sở dữ liệu. Mặc dù đây là cơ chế bảo vệ thông thường, nhưng vấn đề sẽ phát sinh khi SQL Server cơ sở dữ liệu trong quá trình phục hồi mất nhiều thời gian hơn bình thường hoặc có vẻ bị kẹt.
1.2 Ba giai đoạn phục hồi cơ sở dữ liệu
SQL Server quá trình phục hồi diễn ra theo ba giai đoạn riêng biệt:
1.2.1 Giai đoạn phân tích
SQL Server Quét nhật ký giao dịch từ điểm kiểm tra cuối cùng để xác định các trang bẩn và giao dịch đang hoạt động. Nó tạo Bảng Trang Bẩn (DPT) và Bảng Giao dịch Đang hoạt động (ATT) để theo dõi những gì cần khôi phục.
1.2.2 Giai đoạn làm lại (Cuộn tiếp)
Hệ thống sẽ phát lại tất cả các giao dịch đã cam kết chưa được ghi vào đĩa trước khi sự cố xảy ra. Điều này đảm bảo tất cả các thay đổi đã cam kết đều được áp dụng chính xác vào các tệp cơ sở dữ liệu.
1.2.3 Giai đoạn Hoàn tác (Hoàn tác)
Bất kỳ giao dịch nào chưa được cam kết sẽ được khôi phục để duy trì tính nhất quán của cơ sở dữ liệu. Sau khi hoàn tất, cơ sở dữ liệu sẽ sẵn sàng hoạt động bình thường.
1.3 Các triệu chứng phổ biến và thông báo lỗi
Khi bạn SQL Server db đang trong quá trình phục hồi, bạn thường sẽ thấy:
- Tên cơ sở dữ liệu hiển thị “(Đang khôi phục)” trong SQL Server Studio quản lý
- Lỗi đăng nhập với thông báo "cơ sở dữ liệu đang được khôi phục"
- Các mục nhật ký lỗi hiển thị phần trăm tiến trình phục hồi
- Trạng thái cơ sở dữ liệu hiển thị “ĐANG PHỤC HỒI” khi được truy vấn
2. Nguyên nhân gốc rễ của SQL Server Sự cố chế độ phục hồi
2.1 Thao tác khôi phục chưa hoàn tất
Các most nguyên nhân phổ biến xảy ra khi khôi phục từ nhiều tệp sao lưu bằng cách sử dụng KHÔNG PHÁT HIỆN tùy chọn không có kết quả cuối cùng CÓ SỰ PHỤC HỒI lệnh. Thao tác này khiến cơ sở dữ liệu phải chờ các thao tác khôi phục bổ sung.
2.2 Các vấn đề về Nhật ký giao dịch
Tệp nhật ký giao dịch lớn hoặc quá nhiều Tệp Nhật ký Ảo (VLF) làm chậm đáng kể quá trình phục hồi. Khi MS SQL đang trong quá trình phục hồi với hàng nghìn VLF, quá trình này có thể mất hàng giờ hoặc hàng ngày để hoàn tất.
2.3 Các vấn đề liên quan đến hệ thống
Lỗi phần cứng, mất điện hoặc không đủ dung lượng đĩa có thể làm gián đoạn hoạt động bình thường của cơ sở dữ liệu, kích hoạt quá trình khôi phục kéo dài trong quá trình khôi phục.tart.
2.4 Hỏng hóc cơ sở dữ liệu
Các tệp cơ sở dữ liệu bị hỏng ngăn cản quá trình khôi phục thành công, khiến cơ sở dữ liệu bị kẹt vô thời hạn ở chế độ khôi phục.
3. Chẩn đoánostCác bước trước khi sửa chữa
Kiểm tra 3.1 SQL Server Nhật ký lỗi
Trước khi cố gắng sửa chữa, hãy kiểm tra SQL Server Nhật ký lỗi để biết thông báo tiến trình khôi phục. Tìm các mục hiển thị tỷ lệ hoàn thành và thời gian ước tính còn lại.
- Mở SQL Server Studio quản lý
- Hướng đến Quản lý -> SQL Server Logs
- Xem lại các mục nhập gần đây cho tên cơ sở dữ liệu của bạn
- Tìm kiếm các chỉ số giai đoạn phục hồi (Giai đoạn 1, 2 hoặc 3 trong số 3)
3.2 Theo dõi tiến trình phục hồi
Sử dụng chế độ xem quản lý động để theo dõi các hoạt động phục hồi đang diễn ra:
SELECT session_id, command, blocking_session_id, wait_type, wait_time, wait_resource FROM sys.dm_exec_requests WHERE command = 'DB STARTUP';
3.3 Kiểm tra trạng thái cơ sở dữ liệu
Xác minh trạng thái cơ sở dữ liệu hiện tại để hiểu trạng thái phục hồi:
SELECT name, state_desc FROM sys.databases WHERE name = 'YourDatabaseName';
4. Sửa lỗi #1: Chờ quá trình phục hồi tự nhiên hoàn tất
Đôi khi sự kiên nhẫn là giải pháp tốt nhất khi bạn SQL Server Cơ sở dữ liệu đang trong quá trình phục hồi. Phương pháp này hiệu quả khi quá trình phục hồi diễn ra bình thường nhưng mất nhiều thời gian hơn dự kiến.
4.1 Khi nào cần kiên nhẫn
Cho phép hoàn thành tự nhiên khi:
- Nhật ký lỗi cho thấy tiến trình ổn định với ước tính thời gian giảm dần
- Không có lỗi tham nhũng nào được báo cáo
- Cơ sở dữ liệu gần đây đã trải qua các giao dịch lớn
- Số lượng VLF có thể kiểm soát được (dưới 1,000)
4.2 Theo dõi tiến trình phục hồi
Thời gian phục hồi ước tính trong nhật ký lỗi thường không chính xác. Hãy tập trung vào phần trăm tiến độ thay vì thời gian còn lại. Cơ sở dữ liệu lớn với lịch sử giao dịch phong phú có thể mất vài giờ để phục hồi hoàn toàn.
5. Sửa lỗi #2: Sử dụng RESTORE DATABASE VỚI RECOVERY
Bản sửa lỗi này giải quyết các thao tác khôi phục chưa hoàn tất khi bước khôi phục cuối cùng bị bỏ sót. Sử dụng bản sửa lỗi này khi SQL Server db trong quá trình phục hồi là kết quả của quá trình khôi phục bằng NORECOVERY.
5.1 Hiểu lệnh
KHÔI PHỤC CƠ SỞ DỮ LIỆU VỚI RECOVERY Lệnh hoàn tất quá trình khôi phục bằng cách khôi phục các giao dịch chưa cam kết và đưa cơ sở dữ liệu trực tuyến.
5.2 Các bước thực hiện
- Mở SQL Server Studio quản lý
- Kết nối với của bạn SQL Server ví dụ
- Nhấp chuột Mới > Truy vấn với kết nối hiện tại
- Hành hình:
RESTORE DATABASE [YourDatabaseName] WITH RECOVERY; - Chờ xác nhận hoàn tất
Cảnh báo: Chỉ sử dụng lệnh này nếu bạn chắc chắn không có hoạt động khôi phục bổ sung nào đang chờ xử lý.
6. Bản sửa lỗi #3: Giải quyết sự cố Nhật ký giao dịch
Sự cố nhật ký giao dịch là nguyên nhân chính gây ra thời gian phục hồi kéo dài. Bản sửa lỗi này giải quyết các vấn đề về nhật ký đầy, VLF quá mức và không gian nhật ký khiến SQL Server trong phục hồi.
6.1 Sao lưu nhật ký giao dịch
Giải phóng không gian nhật ký bằng cách tạo bản sao lưu nhật ký giao dịch:
- Mở SQL Server Studio quản lý
- Nhấp chuột phải vào cơ sở dữ liệu của bạn -> Nhiệm vụ -> Sao lưu
- Thay đổi Kiểu sao lưu đến Nhật ký giao dịch
- Chỉ định đích sao lưu
- Nhấp chuột OK để thực hiện
6.2 Quản lý tệp nhật ký ảo (VLF)
Kiểm tra số lượng VLF bằng:
DBCC LOGINFO('YourDatabaseName');
Nếu bạn có hơn 1,000 VLF, hãy giảm chúng theo:
- Sao lưu nhật ký giao dịch
- Thu nhỏ tệp nhật ký:
DBCC SHRINKFILE(LogFileName, TRUNCATEONLY); - Mở rộng tệp nhật ký thành các khối lớn (1GB trở lên)
6.3 Thu nhỏ tệp nhật ký một cách an toàn
Chỉ thu nhỏ nhật ký trong thời gian bảo trì khi không có giao dịch nào đang chạy. Luôn sao lưu cơ sở dữ liệu trước khi thực hiện thu nhỏ.
7. Sửa lỗi #4: Chạy DBCC CHECKDB và sửa chữa
Hỏng cơ sở dữ liệu có thể ngăn cản quá trình khôi phục thành công. DBCC CHECKDB là một lệnh tích hợp có thể xác định và sửa chữa các sự cố hỏng hóc nhỏ khiến MS SQL vẫn ở chế độ khôi phục.
7.1 Kiểm tra lỗi cơ sở dữ liệu
Start với phương pháp tiêu chuẩn để xác minh tính toàn vẹn của cơ sở dữ liệu. Hãy thử DBCC CHECKDB trực tiếp trước:
- Hành hình:
DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS; - Xem lại kết quả để tìm lỗi về tính nhất quán
- Ghi lại bất kỳ thông báo tham nhũng nào
Nếu DBCC CHECKDB không thành công Với các lỗi như "Cơ sở dữ liệu đang được khôi phục. Đang chờ cho đến khi khôi phục hoàn tất", điều này có nghĩa là cơ sở dữ liệu đang ở chế độ khôi phục và đang chặn truy cập. Trong trường hợp này, hãy chuyển sang mục 7.3 để sử dụng chế độ KHẨN CẤP.
7.2 Tùy chọn sửa chữa cho cơ sở dữ liệu có thể truy cập
Nếu DBCC CHECKDB chạy thành công và phát hiện lỗi, hãy sử dụng các bước sửa chữa sau:
- Đặt cơ sở dữ liệu ở chế độ người dùng đơn:
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER; - Cố gắng sửa chữa an toàn:
DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD); - Nếu không thành công, hãy sử dụng:
DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS); - Trở lại chế độ nhiều người dùng:
ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
7.3 Sử dụng chế độ khẩn cấp khi không thể truy cập cơ sở dữ liệu
Chế độ khẩn cấp chỉ được yêu cầu khi cơ sở dữ liệu bị kẹt trong quá trình khôi phục và từ chối các lần truy cập DBCC CHECKDB thông thường. Chế độ này đánh dấu cơ sở dữ liệu là READ_ONLY và vô hiệu hóa việc ghi nhật ký. Sử dụng phương pháp này khi truy cập tiêu chuẩn không thành công:
- Đặt chế độ khẩn cấp:
ALTER DATABASE [YourDatabaseName] SET EMERGENCY; - Thiết lập người dùng đơn lẻ:
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER; - Chạy kiểm tra tính toàn vẹn:
DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS; - Nếu phát hiện hỏng hóc, hãy chạy lệnh sửa chữa an toàn trước:
DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD); - Nếu không thành công, hãy sử dụng chức năng sửa chữa khi mất dữ liệu:
DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS); - Thiết lập nhiều người dùng:
ALTER DATABASE [YourDatabaseName] SET MULTI_USER; - Thiết lập trực tuyến:
ALTER DATABASE [YourDatabaseName] SET ONLINE;
Quan trọng: Chế độ KHẨN CẤP bỏ qua các quy trình khôi phục thông thường và chỉ nên sử dụng khi cơ sở dữ liệu hoàn toàn không thể truy cập được. Luôn thử phương pháp DBCC CHECKDB tiêu chuẩn trước khi chuyển sang chế độ KHẨN CẤP.
Bạn có thể tìm thấy hướng dẫn toàn diện hơn về cách sử dụng DBCC CHECKDB.
8. Sửa lỗi #5: Khôi phục từ bản sao lưu
Khi các phương pháp khác không thành công hoặc tính toàn vẹn của dữ liệu bị nghi ngờ, việc khôi phục từ bản sao lưu sạch thường là giải phápost giải pháp đáng tin cậy để giải quyết SQL Server vấn đề phục hồi cơ sở dữ liệu.
8.1 Khi nào nên chọn khôi phục sao lưu
Hãy cân nhắc khôi phục bản sao lưu khi:
- Quá trình phục hồi đã diễn ra trong hơn 24 giờ mà không có tiến triển
- Lỗi hỏng ngăn cản việc sửa chữa thành công
- Bạn có các bản sao lưu gần đây đã được xác minh
- Việc mất dữ liệu kể từ lần sao lưu cuối cùng là chấp nhận được
8.2 Quy trình phục hồi từng bước
- Mở SQL Server Studio quản lý
- Nhấp chuột phải Cơ sở dữ liệu -> Khôi phục cơ sở dữ liệu
- Chọn Dụng cụ dưới Nguồn
- Nhấp chuột Thêm và duyệt đến tập tin sao lưu của bạn
- Chọn bản sao lưu và nhấp vào OK
- Chọn Ghi đè lên cơ sở dữ liệu hiện có Nếu cần thiết
- Nhấp chuột OK sau đó ptarphục hồi t
8.3 Phục hồi tại một thời điểm
Để giảm thiểu mất mát dữ liệu, hãy sử dụng bản sao lưu nhật ký giao dịch để khôi phục về một thời điểm cụ thể. Đảm bảo bạn có một chuỗi sao lưu nhật ký liên tục từ bản sao lưu đầy đủ đến điểm khôi phục mong muốn.
8.4 Tham khảo
Bạn có thể tìm hiểu thêm thông tin từ chúng tôi hướng dẫn toàn diện về cách sao lưu và khôi phục SQL Server cơ sở dữ liệu.
9. Sửa lỗi #6: Vô hiệu hóa thuộc tính TỰ ĐỘNG ĐÓNG
Thuộc tính cơ sở dữ liệu TỰ ĐỘNG ĐÓNG có thể gây ra các chu kỳ phục hồi lặp đi lặp lại, khiến cho có vẻ như SQL Server db liên tục ở chế độ phục hồi. Tắt thuộc tính này sẽ giải quyết được vấn đề.
9.1 Hiểu về các vấn đề ĐÓNG TỰ ĐỘNG
Khi TỰ ĐỘNG ĐÓNG được bật, SQL Server đóng cơ sở dữ liệu sau khi kết nối cuối cùng kết thúc, sau đó mở lại để thực hiện kết nối mới. Việc mở lại này sẽ kích hoạt quy trình phục hồi mỗi lần.
9.2 Vô hiệu hóa chức năng tự động đóng
- Mở SQL Server Studio quản lý
- Nhấp chuột phải vào cơ sở dữ liệu của bạn -> Bất động sản
- Chọn Các lựa chọn từ bảng điều khiển bên trái
- Thiết lập Tự động đóng đến Sai
- Nhấp chuột OK để áp dụng các thay đổi
Ngoài ra, hãy sử dụng T-SQL:
ALTER DATABASE [YourDatabaseName] SET AUTO_CLOSE OFF;
10. Sửa lỗi #7: Restart SQL Server Dịch vụ
Dịch vụ restarcó thể giải quyết các quá trình phục hồi bị kẹt, nhưng nên sử dụng cẩn thận vì nó sẽ làm hỏngtart phục hồi từ đầu. Bản sửa lỗi này hoạt động khi SQL Server trong quá trình phục hồi có vẻ như bị đóng băng hoàn toàn.
10.1 Khi dịch vụ Restart Giúp
Restart dịch vụ khi:
- Tiến trình phục hồi đã bị đình trệ trong nhiều giờ
- Nhật ký lỗi không hiển thị mục nhập mới
- Các cơ sở dữ liệu khác đang hoạt động bình thường
- Bạn có thể đủ khả năng kéo dài thời gian ngừng hoạt động
10.2 Giải pháp an toàntart Thủ tục
- Mở SQL Server Quản lý cấu hình
- Hướng đến SQL Server Dịch vụ
- Tìm SQL Server trường hợp bạn muốn restart, sau đó nhấp chuột phải SQL Server (Tên phiên bản)
- Chọn Restart
- Chờ dịch vụ được phục hồi hoàn toàntart
- Theo dõi nhật ký lỗi để biết tiến trình phục hồi
Lưu ý: Restarting sẽ gây ra sự phục hồi bắt đầu từ start, có khả năng kéo dài thời gian phục hồi hoàn toàn.
11. Sửa lỗi #8: Sửa chữa cơ sở dữ liệu bằng cách tách và gắn lại
Trong trường hợp nghiêm trọng, hãy tách và gắn lại cơ sở dữ liệu:
- Tách cơ sở dữ liệu:
EXEC sp_detach_db 'YourDatabaseName'; - Chỉ đính kèm tệp MDF:
CREATE DATABASE [YourDB] ON (FILENAME = 'C:\Path\YourDB.mdf') FOR ATTACH_REBUILD_LOG; - Điều này xây dựng lại một nhật ký giao dịch mới
Cảnh báo: Phương pháp này có thể dẫn đến mất dữ liệu. Chỉ sử dụng khi các phương án khác không còn hiệu quả.
12. Bản sửa lỗi #9: Xử lý sự cố phản chiếu cơ sở dữ liệu
Cấu hình sao chép cơ sở dữ liệu có thể gây ra các sự cố khôi phục đặc thù. Bản sửa lỗi này giải quyết các sự cố cụ thể liên quan đến sao chép khiến cơ sở dữ liệu luôn ở trạng thái khôi phục.
12.1 Các vấn đề phục hồi cụ thể của phản chiếu
Cơ sở dữ liệu được sao chép có thể bị kẹt trong quá trình khôi phục do sự cố kết nối đối tác hoặc sự cố điểm cuối. Cả cơ sở dữ liệu chính và cơ sở dữ liệu sao chép đều có thể hiển thị trạng thái khôi phục.
12.2 Giải pháp phục hồi phản chiếu
Restart điểm cuối phản chiếu:
- Tìm tên điểm cuối:
SELECT * FROM sys.endpoints WHERE type = 4; - Điểm dừng cuối:
ALTER ENDPOINT [EndpointName] STATE = STOPPED; - Starđiểm cuối t:
ALTER ENDPOINT [EndpointName] STATE = STARTED;
Nếu điểm cuối restart thất bại, phá vỡ mối quan hệ đối tác phản chiếu:
- Hành hình:
ALTER DATABASE [DatabaseName] SET PARTNER OFF; - Chạy:
RESTORE DATABASE [DatabaseName] WITH RECOVERY; - Cấu hình lại phản chiếu sau khi cơ sở dữ liệu trực tuyến
13. Sửa lỗi #10: Sử dụng Công cụ Phục hồi Chuyên nghiệp
Các công cụ phục hồi của bên thứ ba cung cấp khả năng sửa chữa nâng cao khi được tích hợp sẵn SQL Server Các phương pháp này thường không thể khôi phục dữ liệu từ các cơ sở dữ liệu bị hỏng nghiêm trọng.
13.1 DataNumen SQL Recovery
DataNumen SQL Recovery có tỷ lệ phục hồi cao, cùng với các lựa chọn toàn diện.
Dưới đây là các bước sử dụng:
- Ngăn chặn SQL Server Dịch vụ.
- Tạo bản sao các tệp của cơ sở dữ liệu ở chế độ phục hồi, bao gồm cả tệp MDF chính và tệp NDF phụ.
- Start SQL Server Dịch vụ.
- Start DataNumen SQL Recovery.
- Chọn bản sao thay vì tệp gốc làm nguồn của cơ sở dữ liệu cần phục hồi.
- Nhấp vào “Start Recovery” và làm theo hướng dẫn để khôi phục cơ sở dữ liệu.
- Sau quá trình phục hồi, một cơ sở dữ liệu phục hồi mới sẽ xuất hiện trong SQL Server chứa tất cả dữ liệu đã phục hồi.
13.2 Khi nào nên cân nhắc sử dụng công cụ của bên thứ ba
Sử dụng các công cụ chuyên nghiệp khi:
- Các tùy chọn sửa chữa tích hợp không thành công hoặc báo cáo lỗi nghiêm trọng
- Không có bản sao lưu gần đây nào khả dụng
- Dữ liệu quan trọng phải được phục hồi mặc dù bị hỏng
- Các phương pháp phục hồi tiêu chuẩn dẫn đến mất dữ liệu đáng kể
14. Thực hành phòng ngừa tốt nhất
14.1 Nhiệm vụ bảo trì thường xuyên
Thực hiện các biện pháp này để ngăn ngừa SQL Server cơ sở dữ liệu trong các vấn đề phục hồi:
- Lên lịch sao lưu toàn bộ và nhật ký thường xuyên: Duy trì chuỗi sao lưu hoàn chỉnh
- Theo dõi số lượng VLF: Giữ VLF dưới 100 để có hiệu suất tối ưu
- Lập kế hoạch kích thước tệp nhật ký: Xác định kích thước gỗ trước để tránh tình trạng tự phát triển quá mức
- Chạy DBCC CHECKDB thường xuyên: Phát hiện tham nhũng sớm
14.2 Giám sát và cảnh báo
Thiết lập giám sát chủ động:
- Cấu hình cảnh báo cho những thay đổi trạng thái cơ sở dữ liệu
- Theo dõi dung lượng đĩa trên ổ đĩa tệp nhật ký
- Theo dõi các giao dịch dài hạn
- Cảnh báo về số lượng VLF quá mức
14.3 Phần cứng và Cơ sở hạ tầng
Đảm bảo cơ sở hạ tầng đáng tin cậy:
- Sử dụng bộ nhớ nhanh cho nhật ký giao dịch (tốt nhất là SSD)
- Triển khai nguồn điện dự phòng
- Tách riêng dữ liệu và tệp nhật ký trên các ổ đĩa khác nhau
- Hãy xem xét giải pháp khả dụng cao Lượt thích Luôn có sẵn các nhóm sẵn có
15. Xử lý sự cố các tình huống phức tạp
15.1 Nhiều vấn đề về cơ sở dữ liệu
Khi nhiều cơ sở dữ liệu bị kẹt trong quá trình khôi phục:
- Kiểm tra các vấn đề trên toàn hệ thống (dung lượng đĩa, bộ nhớ)
- Ưu tiên các cơ sở dữ liệu quan trọng để phục hồi
- Xem xét các vấn đề về phần cứng ảnh hưởng đến toàn bộ phiên bản
- Xem lại những thay đổi hoặc cập nhật hệ thống gần đây
15.2 Những cân nhắc về cơ sở dữ liệu lớn
Đối với cơ sở dữ liệu trên 1TB:
- Dự kiến thời gian phục hồi lâu hơn (có thể lên đến nhiều ngày)
- Đảm bảo phân bổ bộ nhớ đầy đủ
- Xem xét các thiết lập xử lý song song
- Theo dõi không gian tempdb trong quá trình phục hồi
15.3 Khi nào cần liên hệ với bộ phận hỗ trợ của Microsoft
Liên hệ với bộ phận hỗ trợ của Microsoft để:
- Hệ thống sản xuất quan trọng không có tùy chọn sao lưu
- Nghi ngờ SQL Server lỗi phần mềm
- Môi trường doanh nghiệp yêu cầu phục hồi được đảm bảo
- Các kịch bản phức tạp Luôn bật hoặc cụm
16. Câu hỏi thường gặp
Q: Nên kéo dài bao lâu? SQL Server phục hồi cơ sở dữ liệu thường mất bao lâu?
A: Thời gian phục hồi phụ thuộc vào kích thước cơ sở dữ liệu, khối lượng giao dịch và hiệu suất phần cứng. Cơ sở dữ liệu nhỏ thường phục hồi trong vài phút, trong khi cơ sở dữ liệu lớn với nhật ký giao dịch đồ sộ có thể mất vài giờ. Thời gian ước tính hiển thị trong nhật ký lỗi thường không chính xác, vì vậy hãy tập trung vào phần trăm tiến độ.
Q: Tôi có thể dừng lại không? SQL Server trong quá trình phục hồi mà không làm mất dữ liệu?
A: Dừng lại SQL Server trong quá trình phục hồi nói chung là an toàn nhưng sẽ restart quá trình phục hồi từ đầu khi dịch vụ restarts. Điều này kéo dài tổng thời gian khôi phục nhưng không gây mất dữ liệu thêm ngoài những gì đã xảy ra trong sự cố ban đầu.
H: Sự khác biệt giữa “Đang khôi phục” và “Đang chờ khôi phục” là gì?
A: “Đang hồi phục” có nghĩa là SQL Server đang tích cực thực hiện các hoạt động phục hồi. "Đang chờ phục hồi" cho biết quá trình phục hồi không thành công.tart, thường là do thiếu tệp, không đủ quyền hoặc vấn đề về dung lượng đĩa phải được giải quyết trước khi có thể tiến hành khôi phục.
Bạn có thể tìm thấy thông tin chi tiết hơn về "Đang chờ phục hồi" trong hướng dẫn toàn diện.
H: Tôi có mất dữ liệu không nếu sử dụng REPAIR_ALLOW_DATA_LOSS?
Đ: Có, REPAIR_ALLOW_DATA_LOSS có thể xóa dữ liệu bị hỏng để khôi phục tính nhất quán của cơ sở dữ liệu. Luôn thử REPAIR_REBUILD trước, phương pháp này sẽ khắc phục các sự cố về cấu trúc mà không làm mất dữ liệu. Chỉ sử dụng REPAIR_ALLOW_DATA_LOSS như một giải pháp cuối cùng khi bạn không còn lựa chọn khôi phục nào khác.
H: Tôi có thể truy cập các cơ sở dữ liệu khác khi một cơ sở dữ liệu đang được phục hồi không?
A: Có, các cơ sở dữ liệu khác trên cùng một SQL Server Phiên bản vẫn có thể truy cập được trong quá trình khôi phục. Chỉ cơ sở dữ liệu đang được khôi phục mới không khả dụng. Tuy nhiên, các thao tác khôi phục có thể ảnh hưởng đến hiệu suất tổng thể của máy chủ.
H: Nguyên nhân nào khiến cơ sở dữ liệu bị kẹt ở chế độ phục hồi?
A: Các nguyên nhân phổ biến bao gồm thao tác khôi phục chưa hoàn tất khi sử dụng NORECOVERY, quá nhiều Tệp Nhật ký Ảo (VLF), giao dịch lớn chưa được cam kết, cơ sở dữ liệu bị hỏng, dung lượng đĩa không đủ và sự cố phần cứng. Cơ sở dữ liệu được bật tính năng TỰ ĐỘNG ĐÓNG cũng có thể liên tục vào chế độ khôi phục.
H: Làm sao tôi biết được quá trình phục hồi đang tiến triển hay bị trì trệ?
A: Màn hình SQL Server Nhật ký lỗi cho các thông báo tiến trình phục hồi hiển thị tỷ lệ phần trăm hoàn thành. Sử dụng sys.dm_exec_requests để kiểm tra xem DB S có đang hoạt động hay không.TARLệnh TUP. Nếu tỷ lệ phần trăm tăng theo thời gian, quá trình khôi phục đang diễn ra. Việc không có mục nhật ký mới nào trong vài giờ có thể cho thấy quy trình bị kẹt.
Q: Có an toàn để restart SQL Server dịch vụ trong quá trình phục hồi?
A: Restarting là an toàn nhưng nên được sử dụng cẩn thận. Nó sẽ restart phục hồi từ đầu, có khả năng tăng gấp đôi thời gian phục hồi. Chỉ restart nếu quá trình phục hồi bị đóng băng hoàn toàn mà không có tiến triển trong nhiều giờ hoặc nếu bạn nghi ngờ quá trình này thực sự bị kẹt.
H: Sự khác biệt giữa chế độ ĐÓNG TỰ ĐỘNG và chế độ phục hồi là gì?
A: TỰ ĐỘNG ĐÓNG sẽ tự động đóng cơ sở dữ liệu khi không có kết nối nào tồn tại, sau đó mở lại để kết nối mới. Việc mở lại liên tục này sẽ kích hoạt các quy trình khôi phục ngắn mỗi lần, khiến cơ sở dữ liệu trông như đang trong quá trình khôi phục liên tục. Tắt TỰ ĐỘNG ĐÓNG sẽ giải quyết được vấn đề này.
H: Sao lưu nhật ký giao dịch có thể giúp ích trong quá trình phục hồi không?
A: Sao lưu nhật ký giao dịch có thể giải phóng dung lượng nhật ký nếu ổ đĩa nhật ký đầy, cho phép tiếp tục phục hồi. Tuy nhiên, bạn không thể sao lưu nhật ký của cơ sở dữ liệu đang ở chế độ phục hồi. Sao lưu nhật ký hữu ích hơn cho việc phòng ngừa vàost-bảo trì phục hồi.
H: Khi nào tôi nên liên hệ với Bộ phận hỗ trợ của Microsoft?
A: Liên hệ với Bộ phận hỗ trợ của Microsoft cho các hệ thống sản xuất quan trọng mà các phương pháp khôi phục tích hợp không thành công khi bạn nghi ngờ SQL Server lỗi phần mềm, cho các tình huống Luôn bật hoặc cụm phức tạp hoặc khi môi trường doanh nghiệp yêu cầu khôi phục dữ liệu được đảm bảo với thời gian ngừng hoạt động tối thiểu.
H: Làm thế nào để ngăn chặn cơ sở dữ liệu bị kẹt trong quá trình khôi phục?
A: Triển khai sao lưu toàn bộ và nhật ký thường xuyên, theo dõi và quản lý số lượng VLF, đảm bảo đủ dung lượng đĩa, sử dụng quy trình tắt máy thích hợp, duy trì độ tin cậy của phần cứng, vô hiệu hóa TỰ ĐỘNG ĐÓNG trên cơ sở dữ liệu sản xuất và chạy các hoạt động DBCC CHECKDB thường xuyên để phát hiện lỗi sớm.
H: VLF là gì và tại sao chúng ảnh hưởng đến quá trình phục hồi?
A: Tệp Nhật ký Ảo (VLF) là các phân đoạn nội bộ trong tệp nhật ký giao dịch. Quá nhiều VLF (trên 1,000) làm chậm đáng kể quá trình phục hồi vì SQL Server phải xử lý từng cái một. Việc thiết lập kích thước và tăng trưởng tệp nhật ký phù hợp giúp duy trì số lượng VLF tối ưu.
H: Tôi có thể khôi phục từ bản sao lưu khi cơ sở dữ liệu đang trong quá trình phục hồi không?
A: Bạn không thể khôi phục cơ sở dữ liệu hiện đang ở chế độ phục hồi. Bạn phải đợi quá trình phục hồi hoàn tất, dừng SQL Server dịch vụ hoặc khôi phục về tên cơ sở dữ liệu khác. Trong trường hợp khẩn cấp, hãy cân nhắc khôi phục về tên cơ sở dữ liệu mới rồi đổi tên sau khi sự cố khôi phục được giải quyết.
17. Kết luận và các bước tiếp theo
17.1 Tóm tắt các giải pháp chính
Khi bạn SQL Server cơ sở dữ liệu đang trong quá trình phục hồi, start với các cách tiếp cận sau theo thứ tự:
- Kiểm tra nhật ký lỗi và theo dõi tiến trình
- Chờ hoàn thành tự nhiên nếu tiến độ ổn định
- Sử dụng RESTORE WITH RECOVERY để khôi phục không hoàn chỉnh
- Giải quyết các vấn đề về nhật ký giao dịch
- Chạy DBCC CHECKDB hoặc các công cụ chuyên nghiệp để phát hiện lỗi
- Hãy cân nhắc khôi phục sao lưu cho những trường hợp nghiêm trọng
Most SQL Server db trong các tình huống khôi phục có thể được giải quyết trong vòng vài giờ bằng các phương pháp đã được chứng minh này. Đối với các tình huống phức tạp, đừng ngần ngại sử dụng các kỹ thuật tiên tiến hoặc công cụ chuyên nghiệp.
17.2 Tài nguyên Bổ sung
Để được hỗ trợ:
- microsoft SQL Server Tài liệu
- SQL Server Diễn đàn cộng đồng
- Blog quản trị cơ sở dữ liệu và tài nguyên kỹ thuật
- Dịch vụ phục hồi cơ sở dữ liệu chuyên nghiệp
Bảo trì và giám sát thường xuyên ngăn ngừa most các vấn đề phục hồi. Thực hiện các biện pháp phòng ngừa được nêu trong hướng dẫn này để giảm thiểu các sự cố MS SQL trong quá trình phục hồi trong tương lai.
Lưu ý
Nguyên Sinh là quản trị viên cơ sở dữ liệu cao cấp (DBA) với hơn 10 năm kinh nghiệm trong SQL Server môi trường và quản lý cơ sở dữ liệu doanh nghiệp. Ông đã giải quyết thành công hàng trăm tình huống khôi phục cơ sở dữ liệu trên khắp các tổ chức dịch vụ tài chính, chăm sóc sức khỏe và sản xuất.
Yuan chuyên về SQL Server Ông có kinh nghiệm thực tế sâu rộng trong việc quản lý cơ sở dữ liệu hàng terabyte, triển khai các Nhóm Luôn Sẵn Sàng (Always On Availability Groups) và phát triển các chiến lược sao lưu và phục hồi tự động cho các hệ thống kinh doanh quan trọng.
Nhờ chuyên môn kỹ thuật và phương pháp thực tế của mình, Yuan tập trung vào việc tạo ra các hướng dẫn toàn diện giúp quản trị viên cơ sở dữ liệu và chuyên gia CNTT giải quyết các vấn đề phức tạp SQL Server thách thức một cách hiệu quả. Anh ấy luôn cập nhật những thông tin mới nhất SQL Server phát hành và công nghệ cơ sở dữ liệu đang phát triển của Microsoft, thường xuyên kiểm tra các tình huống phục hồi để đảm bảo các khuyến nghị của ông phản ánh những phương pháp hay nhất trong thực tế.
Có thắc mắc về SQL Server phục hồi hoặc cần thêm hướng dẫn khắc phục sự cố cơ sở dữ liệu? Yuan hoan nghênh phản hồi và đề xuất để cải thiện các nguồn lực kỹ thuật này.









