Như tên cho thấy, TempDB là một không gian làm việc tạm thời được SQL Server yêu cầu để tạo và lưu giữ các đối tượng trung gian và tạm thời.
TempDB là một bánh răng quan trọng trong bộ máy SQL Server tổng thể và là một không gian làm việc tạm thời - dữ liệu mà nó lưu giữ về bản chất là tạm thời. Nói cách khác, phiên bản SQL Server của bạn tạo lại TempDB mỗi khi nó khởi động lại - tạo cho chính nó một bảng điều khiển sạch để nó có thể hoạt động.
- các đối tượng tạm thời được kích hoạt bởi yêu cầu của người dùng
- các đối tượng được yêu cầu bởi các quy trình hệ thống nội bộ
- thông tin lập phiên bản hàng
Không cần phải nói, nếu TempDB không được cấu hình tối ưu, nó có thể dẫn đến tắc nghẽn hoạt động và làm giảm hiệu suất. Nó có thể khiến bạn tự hỏi tại sao các truy vấn của bạn với các phép nối phức tạp và các thao tác sắp xếp không tạo ra kết quả nhanh như mong đợi.
Không có cách nào dễ dàng để khái quát về các phương pháp hay nhất để tối ưu hóa TempDB, các tình huống quá đa dạng và những gì hoạt động trong một tình huống nhất định có thể không hoạt động trong một tình huống khác. Ngay cả khi cơ sở dữ liệu của bạn đã được đưa vào sản xuất, bạn nên tiếp tục xem xét thiết lập TempDB của mình để đảm bảo nó được định cấu hình như bình thường.
Một trong những vấn đề nghiêm trọng nhất trong hiệu suất cơ sở dữ liệu là sự tranh chấp TempDB. Điều này xảy ra khi nhiều tài nguyên yêu cầu TempDB, nhưng chỉ có một tệp dữ liệu TempDB duy nhất để truy cập.
Tranh chấp TempDB có thể gây ra các vấn đề nghiêm trọng về hiệu suất và thường bị hiểu nhầm là chặn thông thường do khóa cơ sở dữ liệu. Nhiều lần, nó thực sự được chốt lại trên các trang phân bổ bằng các quy trình đồng thời. Điều này có thể dẫn đến tắc nghẽn khi mỗi quy trình chờ đến lượt. Vì lượt đi không đủ nhanh, các kết nối cơ bản sẽ hết thời gian chờ và các quy trình cần được phân bổ.
Bạn được những gì? Ùn tắc giao thông ảo của các quy trình bị chặn.
Làm cách nào để giải quyết tranh chấp TempDB và tối ưu hóa hiệu suất SQL Server? Chúng ta hãy xem xét các khái niệm cơ bản và làm việc theo cách của chúng tôi từ đó.
Số lượng tệp dữ liệu - Tôi nên có bao nhiêu tệp?
Khi bạn thiết lập SQL Server và giữ cấu hình mặc định, bạn chỉ có một tệp dữ liệu duy nhất cho TempDB. Đừng hài lòng với cấu hình này.
Một trong những quy tắc ngón tay cái thường được giới thiệu là một tệp dữ liệu duy nhất trên mỗi lõi. Nhưng hãy thận trọng trong trường hợp này, nếu máy chủ của bạn có 12 lõi, thì không sử dụng 12 tệp dữ liệu TempDB trừ khi được ứng dụng và các yêu cầu tải giải thích.
Tùy chọn tốt nhất, dựa trên cấu hình phần cứng ngày nay, là bắt đầu với 8 tệp dữ liệu chính có kích thước bằng nhau và xem liệu vấn đề tranh chấp có được giải quyết hay không. Làm việc theo cách của bạn trở lên và thêm bốn tệp khác nếu cần. Trình hướng dẫn cài đặt và thiết lập của SQL Server 2016 có một tính năng tích hợp đảm bảo bạn có đủ số lượng tệp dữ liệu TempDB bằng cách phát hiện số lõi CPU và tự động tạo số tệp dữ liệu TempDB thích hợp.
Kích thước quan trọng - Các tệp dữ liệu nên được định cấu hình như thế nào cho phù hợp với kích thước?
Bây giờ chúng ta đã bao gồm số lượng tệp, hãy xem kích thước được đề xuất của mỗi tệp. Kích thước mặc định là 8 MB, cung cấp cho SQL Server tổng không gian TempDB là 64 MB, không đủ cho hầu hết các môi trường sản xuất. Giữ Autogrowth cũng là một tùy chọn, nhưng SQL Server sẽ phải tạm dừng và phân bổ thêm dung lượng đĩa cho các tệp TempDB khi được yêu cầu - thêm chi phí đáng kể cho SQL Server trong quá trình chạy sản xuất.
Phương pháp được khuyến nghị là giữ các tệp và dung lượng ban đầu cần thiết cho mỗi tệp là khoảng 80 đến 90% dung lượng mà TempDB được lưu trữ trên đó. Dung lượng đĩa còn lại từ 10 đến 20% cho bộ nhớ ảo dựa trên hệ điều hành.
Nói cách khác, định kích thước trước các tệp dữ liệu trong quá trình thiết lập hoặc thay đổi kích thước tệp trong môi trường sản xuất. Điều này sẽ đảm bảo đủ không gian đĩa được phân bổ cho TempDB. Tại thời điểm này, bạn nên bật tùy chọn Tự động phát triển, nhưng lý tưởng nhất là hãy cố gắng đảm bảo Máy chủ SQL không phải cấp phát thêm dung lượng ổ đĩa quá thường xuyên.
Một thực tế thú vị, trước SQL Server 2017, không thể phân bổ nhiều hơn 1 GB cho mỗi tệp dữ liệu TempDB tại thời điểm thiết lập. Với phiên bản mới nhất, có thể phân bổ tối đa 256 GB cho tệp dữ liệu TempDB trong khi thiết lập.
Điều này đưa chúng ta đến câu hỏi tiếp theo:
Tôi lưu các tệp dữ liệu TempDB ở đâu?
Trước SQL Server 2012, trong trường hợp môi trường phân cụm, TempDB phải được đặt trên các đĩa được chia sẻ giữa môi trường phân nhóm, như mạng vùng lưu trữ (SAN). Bắt đầu với SQL Server 2012, có thể giữ các tệp dữ liệu TempDB trên bộ lưu trữ cục bộ dựa trên SSD. Điều này cắt giảm những gì sẽ là rất nhiều lưu lượng giữa SAN được chia sẻ và phiên bản SQL Server.
Trong hầu hết các trường hợp, tùy chọn tốt nhất cho vị trí TempDB là một ổ SSD cục bộ chuyên dụng. Nếu điều đó là không thể, thì việc giữ nó trên một ổ đĩa chuyên dụng của riêng nó, với đủ dung lượng đĩa được cấp phát trước sẽ giải quyết được các vấn đề về hiệu suất có thể xảy ra. Đảm bảo bạn liên tục theo dõi tình trạng ổ đĩa để quá trình đọc và ghi đĩa được thực hiện ở mức tối ưu.
Lý tưởng nhất, phương tiện phải là phương tiện nhanh nhất có thể với cấu hình máy chủ, yêu cầu ứng dụng và cuối cùng nhưng không kém phần quan trọng, ngân sách được phân bổ.
Bây giờ chúng ta đã xem qua các khái niệm cơ bản, hãy xem các bổ sung có liên quan và được hoan nghênh cho các bổ sung SQL Server khác nhau sau SQL Server 2012.
Có gì mới không?
SQL Server 2016
Tab chuyên dụng trong khi thiết lập
- Với phiên bản này, SQL Server có một tab dành riêng cho cấu hình TempDB trong quá trình thiết lập công việc
- Trình hướng dẫn cài đặt và thiết lập của SQL Server 2016 có tính năng tích hợp đảm bảo bạn có đủ số lượng tệp dữ liệu TempDB tại thời điểm cài đặt SQL Server. Nó phát hiện số lõi CPU và tự động tạo tệp dữ liệu TempDB, tối đa là 8. Bạn có thể tăng số này sau khi thiết lập SQL Server.
Khởi tạo tệp tức thì
- SQL Server phải phân bổ không gian đĩa cho TempDB trong quá trình thiết lập ban đầu cũng như khi kích thước tệp tăng lên trong quá trình chạy sản xuất. Sự phân bổ này có thể thực hiện được theo hai cách. Cách đầu tiên là khởi tạo không gian đĩa không sử dụng bằng cách ghi các số 0 trước khi phân bổ dung lượng. Cách thứ hai là phân bổ ngay không gian tệp để tăng TempDB.
- Trong phương pháp đầu tiên, SQL Server phải thực hiện hoạt động chuyên sâu về đĩa bằng cách khởi tạo từng cụm đĩa logic. Trong phương pháp này, các tiến trình chạy trên máy chủ cần TempDB có thể phải chờ, tạo ra một nút cổ chai.
- Nếu bạn chọn cấp phát ngay không gian tệp thay vào đó, máy chủ SQL sẽ phân bổ ngay không gian cho Autogrowth mà không cần khởi tạo dung lượng đĩa. Điều này làm giảm i / o đĩa mỗi khi có yêu cầu Autogrowth và đảm bảo thông lượng và hiệu suất tốt hơn. Mặc dù có thể bật IFI trong các phiên bản trước nhưng đó là một quá trình phức tạp. Trong phiên bản SQL Server này, việc thiết lập IFI tại thời điểm thiết lập máy chủ sẽ dễ dàng hơn.
- Cờ theo dõi 1117 &1118 là thừa
SQL Server 2017
- Trước SQL Server 2017, không thể phân bổ nhiều hơn 1 GB cho mỗi tệp dữ liệu TempDB tại thời điểm thiết lập, có nghĩa là kích thước tệp TempDB phải được tăng lên sau khi thiết lập xong. Với phiên bản này, có thể phân bổ tối đa 256 GB cho tệp dữ liệu TempDB trong quá trình thiết lập.
Giám sát TempDB
Theo dõi TempDB có thể khó khăn. Làm thế nào bạn có thể biết nếu bạn đang có sự tranh chấp TempDB? Điều gì đang được phân bổ cho các đối tượng người dùng, cửa hàng phiên bản hoặc các đối tượng nội bộ? Những thứ này có xu hướng như thế nào theo thời gian? Những phiên nào đang tiêu thụ TempDB và ở mức độ nào? Spotlight Cloud giúp việc trả lời những câu hỏi này trở nên dễ dàng. Nó giám sát tất cả các khía cạnh của hiệu suất máy chủ SQL của bạn 24/7 và cung cấp quy trình phân tích sâu để giải quyết mọi vấn đề về hiệu suất. Theo dõi TempDB của bạn theo thời gian và nhận tư vấn tự động của chuyên gia về cấu hình.
Là một giải pháp SaaS, Spotlight Cloud dễ dàng thiết lập và cấu hình. Nó lưu giữ dữ liệu hiệu suất có giá trị lên đến một năm, mang lại thông tin chi tiết về điều chỉnh không thể cạnh tranh được. Các vấn đề về hiệu suất có thể được giải quyết trong vài giây với phân tích nguyên nhân gốc rễ. Đừng lãng phí thời gian nữa để tìm hiểu các tập lệnh phức tạp - hãy bắt đầu bản dùng thử 30 ngày của bạn ngay bây giờ. Giám sát hiệu suất SQL Server hàng đầu bắt đầu ngay bây giờ.
