Trong bài viết trước của tôi về Cảnh báo tác nhân SQL Server, tôi đã cung cấp hướng dẫn từng bước về cách thiết lập và định cấu hình cảnh báo tác nhân SQL cho các lỗi nghiêm trọng cao 19-25 cũng như lỗi 825. Trong bài viết này, tôi sẽ thảo luận chi tiết về những lỗi này và chia sẻ những gì bạn nên làm nếu chúng xảy ra trong môi trường của bạn.
Các lỗi có mức độ nghiêm trọng từ 19 trở lên sẽ khiến lô hiện tại không thể hoàn thành. Các lỗi có mức độ nghiêm trọng từ 20 trở lên là lỗi nghiêm trọng và chấm dứt kết nối máy khách hiện tại. Những lỗi này cũng có thể ảnh hưởng đến tất cả các quy trình trong cơ sở dữ liệu. Lỗi nghiêm trọng là chính xác những gì tên của nó ngụ ý:quá trình đang chạy bị chấm dứt và kết nối máy khách bị đóng.
Mức độ nghiêm trọng 19 lỗi
Lỗi nghiêm trọng 19 là lỗi do thiếu tài nguyên. Điều này có nghĩa là giới hạn nội bộ (mà bạn không thể định cấu hình) đã bị vượt quá và khiến lô hiện tại kết thúc. Những lỗi này hiếm khi xảy ra và bạn có thể làm rất ít để khắc phục sự cố. Nếu một lỗi nghiêm trọng 19 xảy ra, bạn nên liên hệ với nhà cung cấp dịch vụ hỗ trợ chính của mình; thông thường, đó sẽ là Microsoft.
Trong tất cả những năm làm việc với SQL Server, tôi không thể nhớ lại bất kỳ sự cố nào mà lỗi nghiêm trọng 19 được tạo ra. Ngay cả khi tìm kiếm trên Bing, tôi cũng gặp khó khăn khi tìm các lần xuất hiện lỗi; một số tham chiếu mà tôi tìm thấy có liên quan đến phiên bản SQL Server ban đầu và tham chiếu đến một lỗi trong chính SQL Server.
20 lỗi nghiêm trọng
Lỗi nghiêm trọng 20 là một lỗi nghiêm trọng trong quy trình hiện tại. Điều này cho thấy rằng một câu lệnh đã gặp sự cố và đã bị chấm dứt. Vì điều này chỉ ảnh hưởng đến quá trình hiện tại nên rất ít có khả năng bản thân cơ sở dữ liệu đã bị hỏng. Những lỗi này được gắn với một tuyên bố riêng lẻ, vì vậy bạn sẽ cần phải thu thập toàn bộ thông báo lỗi và liên hệ với người hoặc nhóm chịu trách nhiệm về bit mã đó. Đây có thể là nội bộ hoặc có thể là nhà cung cấp ứng dụng. Một lỗi ví dụ là:
Lỗi:18056, Mức độ nghiêm trọng 20, Trạng thái:29Máy khách không thể sử dụng lại phiên với SPID 123, phiên đã được đặt lại để gộp kết nối.
Đối với lỗi này, tôi sẽ liên hệ với nhà phát triển ứng dụng hoặc nhà cung cấp, vì lỗi liên quan đến kết nối gộp gặp lỗi khi cố gắng đặt lại. Tôi cũng sẽ xem xét nhật ký SQL Server có thể có thông báo lỗi chi tiết hơn về những gì đang thực sự xảy ra gây ra lỗi.
Mức độ nghiêm trọng 21 lỗi
Lỗi nghiêm trọng 21 là một lỗi nghiêm trọng trong cơ sở dữ liệu ảnh hưởng đến tất cả các quá trình sử dụng cơ sở dữ liệu đó.
Tôi đã thấy lỗi này xảy ra khi cố gắng khôi phục cơ sở dữ liệu bằng cách sử dụng các tính năng Doanh nghiệp cho phiên bản Standard Edition, cũng như khi cơ sở dữ liệu bị hỏng và người dùng cố gắng truy cập trang bị hỏng. Thông báo lỗi mẫu thuộc loại này là:
Lỗi:605, Mức độ nghiêm trọng:21, Trạng thái 1Cố gắng tìm nạp trang logic (1:8574233) trong cơ sở dữ liệu 'DB_NAME' thuộc đối tượng '0', không thuộc đối tượng 'Table01'.
Khi cố gắng khôi phục cơ sở dữ liệu đang sử dụng các tính năng Doanh nghiệp sang phiên bản Standard Edition, trước tiên bạn sẽ phải xóa các tính năng Doanh nghiệp. Ví dụ:nếu bạn đang sử dụng tính năng nén dữ liệu hoặc thay đổi tính năng thu thập dữ liệu, trước tiên bạn sẽ phải ngừng sử dụng và xóa các tính năng đó khỏi cơ sở dữ liệu, sao lưu cơ sở dữ liệu, rồi khôi phục nó về phiên bản Standard Edition. Bạn có thể sử dụng DMV sys.dm_db_persisted_sku_features
để kiểm tra xem bạn có bất kỳ tính năng chỉ dành cho Doanh nghiệp nào đang được sử dụng hay không.
Đối với các lỗi tham nhũng, bạn sẽ cần chạy DBCC CHECKDB
để xác định mức độ của tham nhũng và đi từ đó. Nếu bạn may mắn, lỗi sẽ nằm trong chỉ mục không hợp nhất mà bạn có thể xây dựng lại và giải quyết vấn đề. Nếu tình trạng hư hỏng nghiêm trọng hơn, bạn có thể xem xét hoạt động khôi phục. Để hiểu rõ hơn về tham nhũng và cách giải quyết các khía cạnh khác nhau của tham nhũng, tôi khuyến khích bạn xem lại các bài đăng trên blog khác nhau của Paul Randal. Paul có toàn bộ danh mục về tham nhũng mà bạn có thể xem tại đây:
- http://www.sqlskills.com/blogs/paul/category/corrupt/
Đang chạy DBCC CHECKDB
như là một phần của công việc được lên lịch thường xuyên dựa trên cơ sở dữ liệu của bạn để phát hiện tham nhũng càng sớm càng tốt. Nếu bạn không thường xuyên kiểm tra để phát hiện tham nhũng, thì bạn có nguy cơ rất lớn là không thể khôi phục dữ liệu bị hỏng.
Mức độ nghiêm trọng 22 lỗi
Lỗi nghiêm trọng 22 là một lỗi nghiêm trọng do tính toàn vẹn của bảng bị nghi ngờ, về cơ bản chỉ ra rằng bảng hoặc chỉ mục được chỉ định trong thông báo bị hỏng. Tham nhũng xảy ra và xảy ra thường xuyên. Kinh nghiệm của chúng tôi là phần lớn lỗi xảy ra do sự cố liên quan đến hệ thống con I / O. Nếu bạn gặp phải lỗi nghiêm trọng 22, bạn sẽ cần chạy DBCC CHECKDB
để xác định mức độ thiệt hại. Một lỗi ví dụ là:
Không thể mở XYZ vì tệp không hợp lệ ID ## trong cơ sở dữ liệu. Bảng hoặc cơ sở dữ liệu có thể bị hỏng.
Nếu lỗi nằm trong chỉ mục không hợp nhất, thì bạn chỉ có thể xây dựng lại chỉ mục và sửa lỗi. Nếu tham nhũng nằm trong chỉ mục đống hoặc nhóm, thì bạn sẽ cần khôi phục cơ sở dữ liệu về trạng thái nhất quán.
Tôi đã thấy các báo cáo trong đó tham nhũng nằm trong bộ nhớ nhưng không có trên đĩa. Trong trường hợp đó, khởi động lại phiên bản hoặc thiết lập cơ sở dữ liệu ngoại tuyến rồi trực tuyến sẽ xóa lỗi.
23 lỗi nghiêm trọng
Lỗi 23 nghiêm trọng là một lỗi nghiêm trọng khác báo cáo rằng bản thân cơ sở dữ liệu có vấn đề về tính toàn vẹn. Cách giải quyết tương tự như đối với lỗi nghiêm trọng 22, trong đó bạn cần chạy ngay DBCC CHECKDB
để tìm toàn bộ mức độ thiệt hại đối với cơ sở dữ liệu.
Mức độ tham nhũng này được phát hiện là ảnh hưởng đến toàn bộ cơ sở dữ liệu. Đây có thể là lỗi trong chính tệp dữ liệu hoặc lỗi trong tệp nhật ký. Các chi tiết của lỗi sẽ hướng bạn đến vấn đề gốc. Ví dụ:lỗi sau chỉ ra rằng chúng tôi cần khôi phục cơ sở dữ liệu của mình hoặc cố gắng xây dựng lại nhật ký. Để nhất quán, tôi sẽ khôi phục từ bản sao lưu gần đây nhất của mình và tất cả các bản sao lưu nhật ký giao dịch có sẵn.
Lỗi:9004, Mức độ nghiêm trọng:23 Trạng thái:6Đã xảy ra lỗi khi xử lý nhật ký cho cơ sở dữ liệu 'db_name'. Nếu có thể, hãy khôi phục từ bản sao lưu. Nếu không có bản sao lưu, có thể cần phải xây dựng lại nhật ký.
Mức độ nghiêm trọng 24 lỗi
Lỗi nghiêm trọng 24 là một lỗi nghiêm trọng liên quan đến phần cứng. Thông báo này sẽ xảy ra do một số loại phương tiện bị lỗi. Các loại lỗi phổ biến nhất mà tôi đã thấy có liên quan đến các vấn đề với bộ nhớ và lỗi I / O. Ví dụ:
Lỗi:832, Mức độ nghiêm trọng:24, Trạng thái:1Một trang đáng lẽ không đổi đã thay đổi (tổng kiểm tra dự kiến:
Khi các lỗi như thế này xảy ra, bạn nên liên hệ với nhóm hỗ trợ hệ thống của mình để chạy kiểm tra bộ nhớ trên máy chủ của bạn và kiểm tra tình trạng máy chủ tốt. Lỗi này có thể là bộ nhớ kém hoặc trình ghi chép bộ nhớ (một quá trình hạt nhân hoặc một cái gì đó đang thay đổi bộ nhớ của SQL Server).
Một ví dụ khác:
Lỗi:824, Mức độ nghiêm trọng:24, Trạng thái:2Máy chủ SQL đã phát hiện ra lỗi I / O dựa trên tính nhất quán lôgic:sai pageid (mong đợi 1:123; thực tế 0:0). Nó xảy ra khi đọc trang (1:123) trong cơ sở dữ liệu ID
Lỗi này chỉ ra lỗi nhất quán trong tệp dữ liệu chính của cơ sở dữ liệu. Bạn sẽ cần chạy ngay lập tức DBCC CHECKDB
để xác định mức độ hư hỏng và thực hiện hành động thích hợp để sửa chữa hoặc khôi phục cơ sở dữ liệu.
25 lỗi nghiêm trọng
Lỗi 25 nghiêm trọng là một lỗi hệ thống nghiêm trọng. Tôi đã nghe nói rằng mức độ nghiêm trọng 25 ít nhiều là một lỗi chung cho các lỗi nghiêm trọng khác. Tôi chỉ gặp lỗi này khi liên quan đến nâng cấp không thành công:có điều gì đó ngăn một trong các tập lệnh nâng cấp chạy và lỗi 25 nghiêm trọng được đưa ra. Bạn sẽ gặp lỗi tương tự như:
Nâng cấp cấp tập lệnh cho cơ sở dữ liệu 'chính' không thành công vì bước nâng cấp 'sqlagent90_sysdbupg.sql' gặp lỗi 598, trạng thái 1, mức độ nghiêm trọng 25. Đây là một tình trạng lỗi nghiêm trọng có thể ảnh hưởng đến hoạt động bình thường và cơ sở dữ liệu sẽ được đưa vào ngoại tuyến. Nếu lỗi xảy ra trong quá trình nâng cấp cơ sở dữ liệu 'chính', nó sẽ ngăn toàn bộ phiên bản SQL Server khởi động. Kiểm tra lỗi của các mục ghi lỗi trước đó, thực hiện các hành động sửa chữa thích hợp và khởi động lại cơ sở dữ liệu để hoàn thành các bước nâng cấp tập lệnh.Trong trường hợp này, các lỗi trước thông báo này đã chỉ ra một đường dẫn không chính xác cho vị trí dữ liệu mặc định cho SQL Server. Sau khi điều đó được sửa chữa, quá trình nâng cấp đã chạy thành công.
Lỗi 825
Lỗi 825 thường được gọi là cảnh báo thử đọc lại, tuy nhiên điều kiện là cho cả hoạt động đọc và ghi. Lỗi này cho bạn biết rằng cần phải thử lại thao tác và SQL Server phải thử lại bao nhiêu lần trước khi thành công. SQL Server sẽ thử lại các hoạt động tối đa bốn lần, sau bốn lần thử lại, nó sẽ phát sinh lỗi 823 hoặc 824. Thông báo lỗi 825 sẽ tương tự như sau:
Đã đọc thành công tệp 'đường dẫn đến tên tệp \ db_name.mdf' ở độ lệch 0x00000002000 sau khi không thành công 2 lần với lỗi:tổng kiểm tra không chính xác (dự kiến:XYZ; ABC thực). Thông báo bổ sung trong nhật ký lỗi SQL Server và nhật ký sự kiện hệ thống có thể cung cấp thêm chi tiết. Tình trạng lỗi này đe dọa tính toàn vẹn của cơ sở dữ liệu và phải được sửa chữa. Hoàn thành kiểm tra tính nhất quán đầy đủ của cơ sở dữ liệu (DBCC CHECKDB). Lỗi này có thể do nhiều yếu tố gây ra; để biết thêm thông tin, hãy xem SQL Server Books Online.
Những thông báo này rất quan trọng vì chúng chỉ ra rằng bạn gặp sự cố lớn hơn với hệ thống con ổ đĩa của mình. Phương pháp khắc phục sự cố sẽ là chạy DBCC CHECKDB
để đảm bảo cơ sở dữ liệu nhất quán, như lỗi khuyến cáo, cũng như xem lại nhật ký sự kiện Windows để tìm lỗi từ hệ điều hành hoặc thiết bị lưu trữ. Bạn cũng nên nhờ nhóm hỗ trợ phần cứng và bộ nhớ của mình xem xét hệ thống con I / O cơ bản để tìm lỗi.
Tóm tắt
Việc định cấu hình cảnh báo SQL Agent là miễn phí và dễ dàng. Chủ động và đáp ứng những cảnh báo này là điều quan trọng để giúp giảm thiểu thời gian chết cho bạn và khách hàng của bạn. Như bạn đã biết, nhiều thứ có thể ảnh hưởng đến SQL Server và tính nhất quán của cơ sở dữ liệu của bạn và cách bảo vệ tốt nhất để có thể khôi phục từ những lỗi này là có bản sao lưu tốt và biết các tùy chọn sửa chữa khác nhau cho DBCC CHECKDB
. Bạn luôn nên chạy DBCC CHECKDB
thường xuyên chống lại cơ sở dữ liệu của bạn để phát hiện lỗi càng sớm càng tốt, vì bạn phát hiện ra lỗi càng nhanh thì bạn càng có nhiều khả năng được sao lưu dữ liệu để bạn có thể khôi phục mà không bị mất dữ liệu.