Tôi đã giảng dạy và viết về các lỗi SQL Server phổ biến trong nhiều năm. Tôi cũng đã viết blog về nó cách đây nhiều năm, tuy nhiên thời gian trôi qua, hướng dẫn đã thay đổi một chút. Bài viết này sẽ mở rộng trên bài viết trước của tôi và chỉ ra cách chúng áp dụng cho SQL Server, Azure SQL Database và Azure SQL Managed Instance.
Trong nhiều năm, tôi nhận thấy người dùng mắc cùng một lỗi. Tôi gọi đó là những sai lầm, tuy nhiên, trong hầu hết các trường hợp, đó chỉ là mọi thứ không được thực hiện đúng cách vì những người quản lý môi trường không biết gì tốt hơn. Dưới đây là một số mục quan trọng hơn mà bất kỳ ai cài đặt và hỗ trợ SQL Server nên biết:
- Bản sao lưu
- DBCC CHECKDB
- Cài đặt bộ nhớ
- Thống kê
- Duy trì chỉ mục
- MAXDOP và ngưỡng chi phí cho song song
- Cảnh báo của SQL Server Agent
Bản sao lưu
Tôi luôn kiểm tra các bản sao lưu đầu tiên khi xem xét một hệ thống mới. Có các bản sao lưu thích hợp để đáp ứng các mục tiêu khôi phục là rất quan trọng. Mất dữ liệu có thể gây bất lợi cho một tổ chức. Khi xem các bản sao lưu, tôi kiểm tra mô hình khôi phục và lịch sử hiện tại của các bản sao lưu cho từng cơ sở dữ liệu. Tôi thường tìm thấy sự kết hợp của những điều sau:
- Không có bản sao lưu nào - không có bản ghi nào về bất kỳ bản sao lưu nào cho cơ sở dữ liệu
- Thiếu các bản sao lưu - không có bản sao lưu nhật ký nào cho cơ sở dữ liệu bằng cách sử dụng mô hình khôi phục đầy đủ
- Không có bản sao lưu nào gần đây - bản sao lưu gần đây nhất là tuần / tháng / năm tuổi
Các bản sao lưu bị định cấu hình sai sẽ gây bất lợi cho tổ chức khi tình huống khôi phục xuất hiện. Làm việc với và phải nói với khách hàng rằng họ bị mất dữ liệu không bao giờ là điều thú vị hay dễ dàng. Việc có các bản sao lưu thích hợp để đáp ứng SLA nên là ưu tiên hàng đầu của bất kỳ tổ chức nào ngoài việc đảm bảo có các bản sao của các bản sao lưu này được lưu trữ ở một vị trí phụ bên ngoài.
Tình huống này áp dụng cho SQL Server và IaaS tại chỗ. Cơ sở dữ liệu Azure SQL và Phiên bản được quản lý Azure có các bản sao lưu được quản lý.
DBCC CHECKDB
Không may xảy ra hỏng cơ sở dữ liệu. Nếu không thường xuyên kiểm tra xem có hỏng hóc hay không, khách hàng có thể gặp khó khăn khi không có bản sao lưu để khôi phục khi lỗi đó ảnh hưởng đến dữ liệu vật lý. Để kiểm tra tham nhũng, DBCC CHECKDB nên được chạy trên từng cơ sở dữ liệu một cách thường xuyên. Những gì tôi thấy rất giống với các bản sao lưu:
- Không có DBCC CHECKDB nào được thực hiện
- DBCC CHECKDB chỉ được thực hiện trên một số cơ sở dữ liệu được chọn
- DBCC CHECKDB được thực hiện gần đây nhất là tháng hoặc năm trước
Trường hợp tệ nhất là báo cáo công việc theo lịch trình DBCC CHECKDB không thành công
Việc phát hiện tham nhũng hoặc để khách hàng liên hệ với vấn đề tham nhũng không bao giờ là dễ chịu khi tham nhũng là một chỉ mục đống hoặc nhóm và không có bản sao lưu trước khi tham nhũng xảy ra. Trong những trường hợp này, tham nhũng là dữ liệu thực tế và bắt đầu khôi phục từ trước khi tham nhũng trong hầu hết các trường hợp, là lựa chọn duy nhất. Trong trường hợp tham nhũng là một chỉ mục không phân cụm, việc xây dựng lại chỉ mục là cách khắc phục.
Trong một vài tình huống, tôi đã phải làm việc với những khách hàng có hành vi tham nhũng nghiêm trọng mà không có bản sao lưu thích hợp, nơi tôi có thể viết kịch bản cho cơ sở dữ liệu và sao chép thủ công tất cả dữ liệu có thể sử dụng vào cơ sở dữ liệu mới được tạo. Có thể dễ dàng tránh được những tình huống tốn kém này bằng cách chạy DBCC CHECKDB và lưu giữ bản sao lưu thích hợp.
Tôi khuyên khách hàng nên chạy DBCC CHECKDB tại chỗ, IaaS, Cơ sở dữ liệu Azure SQL và Phiên bản được quản lý SQL Azure. Azure thực hiện một công việc tuyệt vời trong việc kiểm tra sự hư hỏng về thể chất; tuy nhiên, tôi cảm thấy rằng người tiêu dùng cần phải kiểm tra xem có tham nhũng hợp lý hay không.
Cài đặt bộ nhớ
Cài đặt mặc định của Microsoft SQL Server có giá trị bộ nhớ tối thiểu được đặt thành 0 và giá trị bộ nhớ máy chủ tối đa được đặt thành 2147483647 MB, là 2 Petabyte. Trước SQL Server 2012, giá trị bộ nhớ máy chủ tối đa chỉ áp dụng cho vùng đệm, vì vậy khách hàng cần giới hạn dung lượng bộ nhớ mà vùng đệm có thể sử dụng để tiết kiệm bộ nhớ cho hệ điều hành và các quy trình khác. SQL Server 2012 đã giới thiệu ghi lại trình quản lý bộ nhớ để giá trị bộ nhớ máy chủ tối đa áp dụng cho tất cả cấp phát bộ nhớ SQL Server.
Bạn rất nên đặt giá trị tối đa cho phiên bản SQL Server của mình. Jonathan Kehayias đã viết một bài đăng trên blog Máy chủ SQL của tôi thực sự cần bao nhiêu bộ nhớ, với một công thức giúp thiết lập đường cơ sở cho giá trị bộ nhớ tối đa. Trong trường hợp sử dụng Máy chủ SQL được chia sẻ, tôi khuyên khách hàng của mình nên đặt giá trị tối thiểu là 30% bộ nhớ trên máy chủ.
Trong các tình huống có nhiều trường hợp hoặc nơi máy chủ được sử dụng cho SQL Server, SSIS, SSAS hoặc SSRS, bạn cần đánh giá dung lượng bộ nhớ mà các hệ thống khác cần và giảm giá trị bộ nhớ máy chủ tối đa để cho phép đủ bộ nhớ cho HĐH và hệ thống khác dịch vụ.
Sự cố này hợp lệ đối với tại chỗ, IaaS và một phần đối với Phiên bản được quản lý SQL Azure. Phiên bản được quản lý đặt giá trị bộ nhớ máy chủ tối đa dựa trên cấp được triển khai, tuy nhiên khi tôi thử nghiệm thay đổi kích thước môi trường, giá trị bộ nhớ tối đa không được thay đổi động. Trong trường hợp đó, bạn cần phải cập nhật giá trị theo cách thủ công. Sự cố này không áp dụng cho Cơ sở dữ liệu Azure SQL.
Thống kê
Trình tối ưu hóa truy vấn sử dụng số liệu thống kê để xây dựng kế hoạch thực thi. Điều này có nghĩa là SQL Server cần cập nhật số liệu thống kê để trình tối ưu hóa truy vấn có cơ hội tốt hơn trong việc xây dựng kế hoạch thực thi tốt. Theo mặc định, thống kê được cập nhật sau khi sửa đổi 20% +500 hàng dữ liệu. Điều đó có thể mất nhiều thời gian trên các bảng lớn hơn. Bắt đầu từ mức độ tương thích 130, ngưỡng cập nhật thống kê cho các bảng lớn đã được hạ xuống. Đối với SQL Server 2008R - 2014, bạn có thể giảm ngưỡng này bằng cách sử dụng cờ theo dõi 2371.
Tôi thường xuyên nhận thấy rằng khách hàng không cập nhật thống kê theo cách thủ công và ngay cả với ngưỡng thấp hơn, tôi nhận thấy rằng cập nhật theo cách thủ công làm cho môi trường ổn định hơn.
Tôi khuyên khách hàng nên sử dụng tập lệnh của bên thứ ba để cập nhật số liệu thống kê. Ola Hallengren đã xuất bản Giải pháp bảo trì được sử dụng rộng rãi cho SQL Server. Một phần của quy trình đó là quy trình Tối ưu hóa chỉ mục của anh ấy, có thể lấy các tham số bổ sung để cập nhật thống kê.
@UpdateStatistics
ALL = update index and column statistics
INDEX = update index statistics
COLUMNS = update column statistics
NULL = Do not perform statistics maintenance (this is the default)
@OnlyModifiedStatistics
Y = Update statistics only if rows have been modified since most recent stats update
N = Update statistics regardless of whether any rows have been modified
Tôi nhận thấy rằng những khách hàng đang sử dụng các sản phẩm hoặc tập lệnh của bên thứ ba để thực hiện bảo trì chỉ mục dựa trên mức độ phân mảnh của chỉ mục đang không xem xét rằng việc tổ chức lại không cập nhật thống kê như những người xây dựng lại vẫn làm. Nhiều ứng dụng của bên thứ ba này có các tùy chọn để cập nhật số liệu thống kê giống như quy trình Tối ưu hóa chỉ mục của Ola, bạn chỉ cần bật nó lên.
Cập nhật thống kê áp dụng cho tại chỗ, IaaS, Cơ sở dữ liệu Azure SQL và Phiên bản được quản lý SQL Azure.
Duy trì chỉ mục
Thực hiện bảo trì chỉ mục bằng cách loại bỏ phân mảnh khỏi chỉ mục của bạn vẫn quan trọng. Một số tài liệu đã nghỉ hưu của Microsoft cho biết rằng phân mảnh chỉ mục có thể có tác động tiêu cực từ 13-460% tùy thuộc vào kích thước của môi trường và mức độ phân mảnh. Mặc dù phần cứng như SAN thông minh, Solid State Disk và các cải tiến khác đã giúp tăng tốc mọi thứ, nhưng không gian lãng phí trong chỉ mục có thể chuyển thành không gian lãng phí trong vùng đệm cũng như lãng phí nhiều I / O hơn.
Sự phân mảnh xảy ra thông qua các hoạt động thường xuyên như chèn, cập nhật và xóa. Để khắc phục điều này, cần duy trì chỉ mục thích hợp để xây dựng lại hoặc tổ chức lại các chỉ mục của bạn. Tôi lại quay sang Ola Hallengren, cho kịch bản Tối ưu hóa chỉ mục của anh ấy. Ola’s script cung cấp khả năng chỉ định để xây dựng lại hoặc tổ chức lại dựa trên mức độ phân mảnh và các trang tối thiểu. Nhiều công cụ của bên thứ ba cung cấp cùng một logic. Các kế hoạch Bảo trì Cơ sở dữ liệu SQL Server trước SQL Server 2016 chỉ được phép xây dựng lại hoặc tổ chức lại tất cả các chỉ mục. Bắt đầu với SQL Server 2016, bây giờ bạn có thể chỉ định logic tương tự dựa trên mức độ phân mảnh. Đừng quên những thống kê đó nếu bạn đang sử dụng logic thông minh dựa trên mức độ phân mảnh.
Tôi thích tập lệnh của Ola và các công cụ của bên thứ ba ghi vào bảng. Sau đó, tôi có thể truy vấn bảng để xem liệu tôi có bất kỳ điểm nóng lập chỉ mục nào liên tục xảy ra phân mảnh ở các cấp độ cao hay không và khắc phục sự cố tại sao phân mảnh lại phổ biến như vậy và có thể làm được gì không.
Có những ngoại lệ cho mọi quy tắc hoặc phương pháp hay nhất. Một số kiểu truy cập dữ liệu dẫn đến phân mảnh liên tục. Chi phí liên tục xây dựng lại / sắp xếp lại các bảng đó có thể không đáng và có thể được loại trừ khỏi việc bảo trì. Những tình huống đó nên được đánh giá theo từng trường hợp.
Điều này áp dụng cho tại chỗ, IaaS, Cơ sở dữ liệu Azure SQL và Phiên bản được quản lý SQL Azure.
MAXDOP
Tôi thấy rằng mức độ song song tối đa và ngưỡng chi phí cho tính song song thường được để ở các giá trị mặc định trên máy chủ khách hàng. Đối với MAXDOP, giá trị mặc định bằng 0 có nghĩa là số lượng CPU 'không giới hạn' có thể được sử dụng để thực thi một vùng song song của một truy vấn. Về mặt kỹ thuật, tối đa 64 bộ xử lý trừ khi bạn bật cờ theo dõi để sử dụng nhiều hơn.
Một thập kỷ trước, khi các bộ xử lý có số lõi thấp hơn, giá trị này có thể chấp nhận được. Ngày nay, với mật độ lõi cao và máy chủ đa ổ cắm, số lượng CPU không giới hạn để chạy song song không phải là điều quá tốt. Microsoft đã đưa ra hướng dẫn về những giá trị nào cần sử dụng cho MAXDOP.
Nếu bạn đang sử dụng SQL Server 2008 - SQL Server 2014, đối với một nút NUMA duy nhất có ít hơn 8 bộ xử lý logic, hãy giữ MAXDOP bằng hoặc thấp hơn số bộ xử lý logic. Nếu bạn có nhiều hơn 8 bộ xử lý logic, hãy giữ MAXDOP ở mức 8. Nếu bạn có nhiều nút NUMA với ít hơn 8 bộ xử lý logic trên mỗi nút NUMA, hãy giữ MAXDOP bằng hoặc thấp hơn số bộ xử lý logic trên mỗi nút NUMA. Lớn hơn 8, giữ MAXDOP ở mức 8.
SQL Server 2016 đã giới thiệu các nút mềm-NUMA. Trong khi khởi động dịch vụ, nếu Công cụ cơ sở dữ liệu phát hiện nhiều hơn 8 lõi vật lý trên mỗi nút hoặc ổ cắm NUMA, các nút mềm NUMA sẽ được tạo tự động. Công cụ xử lý việc đặt các bộ xử lý logic từ cùng một lõi vật lý vào các nút mềm NUMA khác nhau. Vì lý do đó, chúng tôi có hướng dẫn hơi khác cho MAXDOP dành cho SQL Server 2016 trở đi.
Nếu bạn đang sử dụng SQL Server 2016 trở lên, đối với một nút NUMA duy nhất có ít hơn 16 bộ xử lý logic, hãy giữ MAXDOP bằng hoặc thấp hơn số bộ xử lý logic. Nếu bạn có hơn 16 bộ xử lý logic, hãy giữ MAXDOP ở mức 16. Nếu bạn có nhiều nút NUMA với ít hơn 16 bộ xử lý logic trên mỗi nút NUMA, hãy giữ MAXDOP bằng hoặc thấp hơn số bộ xử lý logic trên mỗi nút NUMA. Lớn hơn 16, giữ MAXDOP bằng một nửa số bộ xử lý logic trên mỗi nút NUMA với giá trị MAX là 16.
Nếu bạn hầu hết được ảo hóa trên các máy có 8 bộ xử lý logic trở xuống với MAXDOP mặc định, bạn có thể OK. Nếu bạn có phần cứng vật lý lớn với giá trị mặc định, thì bạn nên xem xét việc tối ưu hóa MAXDOP.
Tất cả các số liệu trên là hướng dẫn, không phải là sự thật. Khối lượng công việc của bạn khác nhau và cần cân nhắc khi bạn xác định giá trị nào là tối ưu nhất cho khối lượng công việc của mình.
Cấu hình MAXDOP áp dụng cho phiên bản quản lý SQL tại chỗ, IaaS và Azure. Tuy nhiên, có một cấu hình phạm vi cơ sở dữ liệu có thể được áp dụng cho mỗi cơ sở dữ liệu bắt đầu với SQL Server 2016 và điều này áp dụng cho Cơ sở dữ liệu Azure SQL.
Ngưỡng chi phí cho song song
Ngưỡng chi phí cho tính song song có giá trị mặc định là 5. Lịch sử của con số này quay trở lại những ngày đầu của SQL Server và máy trạm thực hiện kiểm tra khối lượng công việc. Với phần cứng hiện đại, ước tính chi phí của 5 là lỗi thời. Thử nghiệm đã chỉ ra rằng việc tăng số lượng từ 5 lên một giá trị cao hơn sẽ ngăn các truy vấn chạy ngắn hơn không có kế hoạch song song. Tôi có xu hướng khuyên bạn nên tăng giá trị này lên một số cao hơn sau khi kiểm tra Plan Cache. Trong nhiều trường hợp, tôi kết thúc bằng giá trị 25, sau đó theo dõi thêm và điều chỉnh từ đó, nếu cần. Để biết thêm thông tin về ngưỡng chi phí điều chỉnh cho song song, Jonathan Kehayias đã viết:Điều chỉnh "ngưỡng chi phí cho song song" từ Plan Cache.
Điều này áp dụng cho Phiên bản được quản lý SQL tại chỗ, IaaS và Azure.
Cảnh báo tác nhân máy chủ SQL
Mọi người nên tận dụng cảnh báo SQL Agent trừ khi họ có ứng dụng của bên thứ ba giám sát các điều kiện lỗi tương tự. Việc định cấu hình cảnh báo rất dễ dàng và miễn phí, đồng thời việc định cấu hình chúng sẽ cung cấp cho bạn thông tin quan trọng khi máy chủ của bạn gặp sự cố.
Tôi đã viết một bài báo có tiêu đề Cảnh báo tác nhân SQL Server, cung cấp hướng dẫn từng bước về cách tạo cảnh báo cho các lỗi 19-25 mức độ nghiêm trọng và lỗi 825. Bật các cảnh báo này rất dễ dàng:bật thư cơ sở dữ liệu, tạo toán tử thư và sau đó tạo cảnh báo. Điều này có thể được thực hiện bằng GUI hoặc T-SQL. Tôi khuyến khích mọi người của tôi viết kịch bản cho quy trình này bằng T-SQL và biến nó thành một phần của bản dựng máy chủ tiêu chuẩn của bạn.
Điều này áp dụng cho Phiên bản được quản lý SQL tại chỗ, IaaS và Azure.
Tóm tắt
Như bạn có thể thấy, có nhiều cài đặt cần được sửa đổi từ cài đặt mặc định sau khi cài đặt SQL Server. Đây không phải là một danh sách toàn diện; tuy nhiên, nó đề cập đến nhiều vấn đề nghiêm trọng hơn và ảnh hưởng đến hiệu suất mà tôi nhận thấy và tôi đã gộp chung vào danh mục "Các sự cố máy chủ SQL" của mình.
