Trong bài viết trước của tôi về Cơ sở dữ liệu hệ thống SQL Server, chúng ta đã tìm hiểu về từng cơ sở dữ liệu hệ thống đi kèm trong quá trình cài đặt SQL Server. Bài viết hiện tại sẽ tập trung vào các vấn đề thường gặp xung quanh cơ sở dữ liệu tempdb và cách giải quyết chúng một cách chính xác.
SQL Server TempDB
Như tên của cơ sở dữ liệu hệ thống này cho biết, tempdb giữ đối tượng tạm thời được tạo bởi SQL Server. Chúng liên quan đến một số hoạt động và hoạt động như một khu vực làm việc Toàn cầu cho tất cả người dùng kết nối với các phiên bản SQL Server.
Cơ sở dữ liệu Tempdb sẽ chứa các loại đối tượng bên dưới trong khi người dùng thực hiện các thao tác của họ:
- Các đối tượng tạm thời được người dùng tạo một cách rõ ràng. Chúng có thể là bảng và chỉ mục tạm thời Cục bộ hoặc Toàn cục, Biến bảng, bảng được sử dụng trong các hàm có giá trị Bảng và Con trỏ.
- Các đối tượng bên trong được tạo bởi công cụ Cơ sở dữ liệu như
- Bảng công việc lưu trữ các kết quả trung gian cho các cuộn, con trỏ, sắp xếp và các đối tượng lớn tạm thời (LOB).
- Làm việc các tệp trong khi thực hiện các hoạt động Hash Join hoặc Hash tổng hợp.
- Kết quả sắp xếp trung gian trong khi tạo hoặc xây dựng lại chỉ mục nếu SORT_IN_TEMPDB được đặt thành BẬT và các hoạt động khác như truy vấn GROUP BY, ORDER BY hoặc SQL UNION.
- Cửa hàng phiên bản hỗ trợ tính năng lập phiên bản Hàng, Cửa hàng phiên bản chung hoặc Cửa hàng phiên bản tạo chỉ mục trực tuyến sử dụng tệp cơ sở dữ liệu tempdb.
Cơ sở dữ liệu Tempdb được tạo mỗi khi Dịch vụ SQL Server khởi động. Do đó, thời gian tạo cơ sở dữ liệu tempdb có thể được coi là thời gian khởi động SQL Server Service gần đúng. Chúng tôi có thể xác định nó từ sys.databases DMV sử dụng truy vấn được hiển thị bên dưới:
SELECT name, database_id, create_date
FROM sys.databases
WHERE name = 'tempdb'
Tuy nhiên, quá trình khởi động thực tế của SQL Server Service liên quan đến việc khởi động tất cả cơ sở dữ liệu hệ thống theo một trình tự cụ thể. Nó có thể xảy ra sớm hơn một chút so với thời gian tạo tempdb. Chúng tôi có thể nhận được giá trị bằng cách sử dụng sys.databases DMV bằng cách thực hiện truy vấn bên dưới trên sys.dm_os_sys_info DMV .
SELECT ms_ticks, sqlserver_start_time_ms_ticks, sqlserver_start_time
FROM sys.dm_os_sys_info
ms_ticks chỉ định số mili giây kể từ khi máy tính hoặc Máy chủ khởi động. sqlserver_start_time_ms_ticks cột chỉ định số mili giây kể từ ms_ticks số khi Dịch vụ SQL Server bắt đầu.
Chúng tôi có thể tìm thêm thông tin về thứ tự cơ sở dữ liệu đã khởi động khi khởi động dịch vụ SQL Server trong Nhật ký lỗi SQL Server.
Trong SSMS, hãy mở rộng Quản lý > Nhật ký lỗi máy chủ SQL > mở hiện tại nhật ký lỗi. Áp dụng Bắt đầu up cơ sở dữ liệu lọc và nhấp vào Ngày để sắp xếp nó theo thứ tự tăng dần:
Chúng ta có thể thấy rằng cơ sở dữ liệu chính đã khởi động trước khi khởi động dịch vụ SQL Server. Sau đó, tất cả cơ sở dữ liệu người dùng và tất cả các cơ sở dữ liệu hệ thống khác theo sau. Cuối cùng, tempdb bắt đầu. Bạn cũng có thể tìm nạp thông tin này theo chương trình bằng cách thực thi xp_readerrorlog thủ tục hệ thống:
Lưu ý :Cả hai phương pháp trên có thể không hiển thị thông tin cần thiết nếu Dịch vụ SQL Server không được khởi động lại gần đây và Nhật ký lỗi SQL Server đã được tái chế, điều này có thể đã đẩy các nhật ký lỗi cũ hơn sang các tệp cũ hơn. Trong trường hợp đó, chúng tôi có thể cần quét dữ liệu trên các tệp Nhật ký Lỗi Máy chủ SQL đã Lưu trữ.
Các vấn đề thường gặp trong Cơ sở dữ liệu SQL TempDB
Vì tempdb cung cấp một khu vực làm việc toàn cầu cho tất cả các phiên hoặc hoạt động của người dùng, nên nó có thể trở thành nút thắt cổ chai về hiệu suất cho các hoạt động của người dùng nếu không được định cấu hình cẩn thận. Trong bài viết trước của tôi, chúng tôi đã thảo luận về các phương pháp hay nhất được khuyến nghị để triển khai trong cơ sở dữ liệu tempdb. Tuy nhiên, ngay cả sau khi triển khai chúng, chúng tôi có thể gặp phải các vấn đề thường xuyên:
- Tốc độ phát triển tệp không đồng đều trên các tệp dữ liệu tempdb.
- Các tệp dữ liệu Tempdb đang phát triển đến một giá trị lớn và cần phải thu nhỏ Tempdb.
Tệp tăng trưởng không đồng đều trên các tệp dữ liệu TempDB
Bắt đầu từ SQL Server 2000, khuyến nghị mặc định là có nhiều tệp dữ liệu dựa trên số lượng lõi lôgic có sẵn trong Máy chủ.
Khi chúng ta có nhiều tệp dữ liệu, chẳng hạn như 4 tệp dữ liệu tempdb như trong hình ảnh dưới đây, tự động phát triển tệp dữ liệu tempdb sẽ xảy ra 64 MB theo kiểu vòng tròn bắt đầu từ tempdev> temp2> temp3> temp4> tempdev> và như vậy.
Nếu một trong các kích thước tệp không thể tự động phát triển vì lý do nào đó, thì điều đó sẽ dẫn đến kích thước tệp nhất định rất lớn so với các tệp khác. Nó dẫn đến quá tải bổ sung được đặt trên các tệp lớn và tác động tiêu cực đến hiệu suất trên cơ sở dữ liệu tempdb.
Chúng tôi cần đảm bảo rằng tất cả các tệp dữ liệu tempdb đều có kích thước đồng đều tại bất kỳ thời điểm nào theo cách thủ công để tránh tranh chấp hoặc các vấn đề về hiệu suất cho đến SQL Server 2014. Microsoft đã thay đổi hành vi này bắt đầu từ SQL Server 2016 và các phiên bản mới hơn bằng cách triển khai một số tính năng sẽ sẽ thảo luận sau trong bài viết này.
Để khắc phục các vấn đề về hiệu suất ở trên, SQL Server đã giới thiệu 2 Cờ theo dõi có tên 1117 và 1118 để tránh các vấn đề tranh cãi xung quanh tempdb.
- Cờ theo dõi 1117 - cho phép Tự động phát triển tất cả các tệp trong một Nhóm tệp duy nhất
- Cờ theo dõi 1118 - bật TIỆN ÍCH ĐẦY ĐỦ ĐỒNG PHỤC cho tempdb
Cờ theo dõi 1117
Khi không bật Trace Flag 1117, bất cứ khi nào tempdb được định cấu hình với nhiều tệp dữ liệu có kích thước đồng đều và các tệp dữ liệu cần tự động phát triển, SQL Server theo mặc định sẽ cố gắng tăng kích thước tệp theo kiểu vòng lặp nếu tất cả các tệp. Nếu các tệp dữ liệu có kích thước không đồng đều, thì SQL Server sẽ cố gắng tăng kích thước của tệp dữ liệu lớn nhất của tempdb và sẽ sử dụng tệp lớn hơn này cho hầu hết các hoạt động của người dùng, dẫn đến các vấn đề về tranh chấp tempdb ..
Để giải quyết vấn đề này, SQL Server đã giới thiệu Trace Flag 1117. Sau khi được bật, nếu một tệp trong nhóm tệp cần tự động phát triển, nó sẽ tự động phát triển tất cả các tệp trong nhóm tệp đó. Nó giải quyết các vấn đề tranh chấp tempdb. Tuy nhiên, điều bắt buộc là khi cờ theo dõi 1117 được bật, tính năng tự động tăng trưởng cũng được định cấu hình cho tất cả cơ sở dữ liệu người dùng.
Cờ theo dõi 1118
Cờ theo dõi 1118 được sử dụng để kích hoạt TIỆN ÍCH ĐẦY ĐỦ. Hãy quay lại một bước để hiểu cách SQL Server lưu trữ dữ liệu từ cơ bản.
Trang là đơn vị lưu trữ cơ bản trong SQL Server với kích thước 8 Kilobyte (KB).
Mức độ là một tập hợp gồm 8 trang liền kề về mặt vật lý với kích thước 64KB (8 * 8KB). Dựa trên số lượng đối tượng hoặc chủ sở hữu lưu trữ dữ liệu trong một Extent, Extent có thể được phân loại thành:
- Mức độ thống nhất là 8 trang liền kề được sử dụng hoặc truy cập bởi một đối tượng hoặc chủ sở hữu;
- Hỗn hợp Mức độ - là 8 trang liền kề được sử dụng hoặc truy cập bởi tối thiểu 2 và tối đa 8 đối tượng hoặc chủ sở hữu
Bật Cờ theo dõi 1118 sẽ cho phép tempdb có phạm vi đồng nhất, dẫn đến hiệu suất tốt hơn.
Cách bật cờ theo dõi 1117 &1118
Cờ theo dõi có thể được kích hoạt thông qua một số cách tiếp cận. Bạn có thể xác định cách phù hợp từ các tùy chọn dưới đây:
Tham số khởi động dịch vụ SQL Server
Có sẵn vĩnh viễn ngay cả sau khi khởi động lại Dịch vụ SQL. Cách được đề xuất là bật Cờ theo dõi 1117 và 1118 thông qua tham số khởi động Dịch vụ SQL Server .
Mở Trình quản lý cấu hình máy chủ SQL và nhấp vào Dịch vụ SQL Server để liệt kê các dịch vụ có sẵn trong máy chủ đó:
- Nhấp chuột phải vào SQL Server (MSSQLSERVER) > Thuộc tính > Thông số khởi động .
- Loại - T vào trường trống để biểu thị Cờ theo dõi .
- Cung cấp các giá trị 1117 và 1118 như hình bên dưới.
- Nhấp vào Thêm để thêm Cờ theo dõi làm thông số Khởi động.
Sau đó nhấp vào OK để có các cờ theo dõi được thêm vĩnh viễn cho phiên bản SQL Server này. Khởi động lại Dịch vụ SQL Server để các thay đổi được phản ánh.
DBCC TRACEON (, -1)
Bật cờ theo dõi trên toàn cầu. Dịch vụ SQL Server sẽ mất các cờ theo dõi khi khởi động lại Dịch vụ. Để bật cờ theo dõi trên toàn cầu, hãy thực thi tập lệnh dưới đây trong cửa sổ truy vấn mới:
DBCC TRACEON(1117,-1);
DBCC TRACEON(1118,-1);
DBCC TRACEON ()
Bật cờ theo dõi ở cấp phiên. Nó chỉ áp dụng cho phiên hiện tại do người dùng tạo. Để bật cờ theo dõi ở cấp phiên, hãy thực thi tập lệnh dưới đây trong cửa sổ truy vấn mới:
DBCC TRACEON(1117);
DBCC TRACEON(1118);
Để xem danh sách các cờ theo dõi được bật trong một phiên bản của SQL Server, chúng tôi có thể sử dụng DBCC TRACESTATUS lệnh:
DBCC TRACESTATUS();
Như chúng ta có thể thấy, Cờ theo dõi 1117 và 1118 được bật Toàn cầu trong trường hợp của tôi cùng với Phiên .
Để tắt Cờ theo dõi, chúng ta có thể sử dụng lệnh DBCC TRACEOFF như:
DBCC TRACEOFF(1117,-1);
DBCC TRACEOFF(1118,-1);
Các cải tiến TempDB của SQL Server 2016
Trên các phiên bản SQL Server từ SQL Server 2000 đến SQL Server 2014, chúng tôi phải bật Cờ theo dõi 1117 và 1118 cùng với việc giám sát hoàn toàn tempdb để tránh các vấn đề về tranh chấp tempdb. Bắt đầu từ SQL Server 2016 và các phiên bản mới hơn, các Cờ theo dõi 1117 và 1118 được triển khai theo mặc định.
Tuy nhiên, dựa trên kinh nghiệm cá nhân của tôi, tốt hơn là nên phát triển trước tempdb lên kích thước lớn để tránh nhu cầu tự động chạy nhiều lần và để loại bỏ kích thước tệp không đồng đều hoặc tệp đơn đang được SQL Server sử dụng rộng rãi .
Chúng tôi có thể xác minh cách thức triển khai Cờ theo dõi 1117 và 1118 trong SQL Server 2016:
Cờ theo dõi 1117 cài đặt Tự động phát triển của tất cả các Tệp trong nhóm tệp hiện là một thuộc tính của Nhóm tệp . Chúng tôi có thể định cấu hình nó trong khi tạo Nhóm tệp mới hoặc sửa đổi nhóm hiện có.
Để xác minh thuộc tính tự động phát triển của Nhóm tệp , thực thi tập lệnh bên dưới từ sys.filegroups DMV :
SELECT name Filegroup_Name, is_autogrow_all_files
FROM sys.filegroups
Để sửa đổi thuộc tính tự động tăng trưởng của Nhóm tệp chính của cơ sở dữ liệu AdventureWorks , chúng tôi thực thi tập lệnh dưới đây với AUTOGROW_ALL_FILES để tự động phát triển tất cả các tệp bằng nhau hoặc AUTOGROW_SINGLE_FILE để chỉ cho phép tự động phát triển một tệp dữ liệu.
ALTER DATABASE Adventureworks MODIFY FILEGROUP [PRIMARY]
AUTOGROW_SINGLE_FILE
-- AUTOGROW_ALL_FILES is the default behavior
GO
Cờ theo dõi 1118 đặt thuộc tính Mức độ đồng nhất của tệp dữ liệu được bật theo mặc định cho tempdb và tất cả cơ sở dữ liệu người dùng bắt đầu từ SQL Server 2016 . Chúng tôi không thể thay đổi các thuộc tính cho tempdb, vì nó hiện chỉ hỗ trợ tùy chọn Mức độ đồng nhất.
Đối với cơ sở dữ liệu Người dùng, chúng tôi có thể sửa đổi tham số này. Cơ sở dữ liệu hệ thống chính, mô hình và msdb hỗ trợ các phạm vi hỗn hợp theo mặc định và cũng không thể thay đổi được.
Để sửa đổi các giá trị thuộc tính phân bổ Trang hỗn hợp cho Cơ sở dữ liệu người dùng, hãy sử dụng tập lệnh dưới đây:
ALTER DATABASE Adventureworks SET MIXED_PAGE_ALLOCATION ON
-- OFF is the default behavior
GO
Để xác minh thuộc tính Phân bổ trang hỗn hợp, chúng tôi có thể truy vấn is_mixed_page_allocation_on cột từ sys.databases DMV với giá trị là 0, cho biết phân bổ trang ở phạm vi thống nhất và 1 để chỉ ra phân bổ trang ở phạm vi hỗn hợp.
SELECT name, is_mixed_page_allocation_on
FROM sys.databases
Tệp dữ liệu TempDB đang phát triển đến một giá trị lớn, đòi hỏi TempDB phải co lại
Trong SQL Server 2014 hoặc các phiên bản cũ hơn, nếu cờ theo dõi 1117 và 1118 không được định cấu hình đúng cách cùng với nhiều tệp dữ liệu được tạo cho cơ sở dữ liệu tempdb, một số tệp đó chắc chắn sẽ phát triển rất lớn. Nếu điều đó xảy ra, một DBA thường cố gắng thu nhỏ các tệp dữ liệu tempdb. Nhưng nó là một không phù hợp cách tiếp cận để xử lý tình huống này.
Có các tùy chọn khác có sẵn để thu nhỏ tempdb.
Hãy xem xét các lệnh DBCC có sẵn để Thu nhỏ tempdb và các tác động của việc thực hiện các hoạt động này.
DBCC SHRINKDATABASE
DBCC SHRINKDATABASE lệnh console hoạt động bằng cách thu nhỏ phần cuối của Data \ Log Files .
Để thu nhỏ cơ sở dữ liệu thành công, lệnh cần có dung lượng trống ở cuối tệp. Nếu có bất kỳ giao dịch nào đang hoạt động ở cuối tệp, thì tệp cơ sở dữ liệu không thể bị thu hẹp.
Tác động của việc thực thi DBCC SHRINKDATABASE là nó sẽ cố gắng xóa dung lượng trống có sẵn ở cuối mỗi tệp dữ liệu hoặc tệp nhật ký có thể đã được dành riêng cho sự phát triển dữ liệu bảng trong tương lai. Do đó, việc chạy lệnh này có thể dẫn đến kích thước tệp không đồng đều dẫn đến các vấn đề tranh chấp tempdb.
Cú pháp để thu nhỏ cơ sở dữ liệu người dùng, ví dụ cơ sở dữ liệu Adventureworks sẽ là
DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);DBCC SHRINKFILE
DBCC SHRINKFILE lệnh console hoạt động tương tự như DBCC SHRINKDATABASE, nhưng nó thu nhỏ các tệp Nhật ký hoặc Dữ liệu cơ sở dữ liệu được chỉ định .
Nếu bạn xác định rằng một tệp Dữ liệu tempdb cụ thể là rất lớn, chúng tôi có thể thử thu nhỏ mục cụ thể đó bằng cách sử dụng DBCC SHRINKFILE như được hiển thị bên dưới.
Hãy cẩn thận khi sử dụng lệnh này trên tempdb vì nếu một tệp bị thu hẹp đến một giá trị thấp hơn hoặc cao hơn các tệp dữ liệu khác, thì tệp dữ liệu cụ thể đó sẽ không được sử dụng hiệu quả. Hoặc, nó sẽ được sử dụng thường xuyên hơn dẫn đến các vấn đề về tranh chấp tạm thời.
Cú pháp để thực thi thao tác DBCC SHRINKFILE trên tệp dữ liệu AdventureWorks có kích thước 1GB (1024 MB) sẽ là:
DBCC SHRINKFILE (AdventureWorks, 1024);
GO
DBCC DROPCLEANBUFFERS
DBCC DROPCLEANBUFFERS lệnh console được sử dụng để xóa tất cả các bộ đệm sạch khỏi nhóm Bộ đệm và các đối tượng cột trong nhóm đối tượng cột .
Chỉ cần thực hiện lệnh dưới đây:
DBCC DROPCLEANBUFFERSDBCC FREEPROCCACHE
ĐƯỜNG DÂY CHUYỂN HÓA DBCC lệnh xóa tất cả bộ nhớ cache của kế hoạch thực thi thủ tục được lưu trữ .
Bộ đệm ẩn kế hoạch thực thi thủ tục được SQL Server sử dụng để thực hiện các lệnh gọi thủ tục tương tự nhanh hơn. Sau khi thực thi DBCC FREEPROCCACHE, Plan Cache sẽ bị xóa. Do đó, SQL Server phải tạo lại bộ đệm khi thủ tục được lưu trữ được thực thi trong phiên bản. Nó để lại tác động tiêu cực nghiêm trọng khi được thực thi trong các phiên bản Production DB.
Không nên thực thi DBCC FREEPROCCACHE trên phiên bản cơ sở dữ liệu Sản xuất!
Cú pháp để thực thi DBCC FREEPROCCACHE dưới đây:
DBCC FREEPROCCACHETẦN SỐ DBCC
DBCC FREESESSIONCACHE lệnh xóa bộ đệm ẩn kết nối truy vấn phân phối khỏi phiên bản SQL Server . Sẽ rất hữu ích khi có nhiều truy vấn phân tán đang thực thi trên một phiên bản SQL Server cụ thể.
Cú pháp để thực thi DBCC FREESESSIONCACHE sẽ là:
DBCC FREESESSIONCACHEDBCC FREESYSTEMCACHE
DBCC FREESYSTEMCACHE lệnh xóa tất cả các mục nhập bộ đệm không sử dụng khỏi tất cả bộ đệm . SQL Server thực hiện điều này theo mặc định để cung cấp thêm bộ nhớ cho các hoạt động mới. Tuy nhiên, chúng tôi có thể thực thi nó theo cách thủ công bằng lệnh dưới đây:
DBCC FREESYSTEMCACHENhư chúng ta đã biết, tempdb lưu trữ tất cả các đối tượng người dùng tạm thời hoặc các đối tượng bên trong bao gồm Bộ đệm ẩn kế hoạch thực thi, dữ liệu vùng đệm, Bộ đệm phiên và Bộ đệm hệ thống. Do đó, việc thực hiện 6 lệnh DBCC ở trên sẽ giúp xóa các tệp dữ liệu tempdb ngăn cản quá trình thu nhỏ thông thường.
Mặc dù chúng tôi đã trải qua các bước về cách thu nhỏ tempdb thông qua nhiều cách tiếp cận khác nhau, nhưng các phương pháp hay nhất được đề xuất để xử lý cơ sở dữ liệu tempdb được liệt kê dưới đây:
a. Khởi động lại Dịch vụ SQL Server nếu có thể để tạo lại đồng đều các tệp dữ liệu tempdb. Tác động tiềm tàng sẽ là, chúng tôi sẽ mất tất cả các kế hoạch Thực thi và thông tin bộ nhớ cache khác đã thảo luận ở trên.
b. Tăng trưởng trước các tệp dữ liệu tempdb lên một kích thước tệp lớn có sẵn trong ổ đĩa chứa các tệp dữ liệu tempdb. Điều này sẽ ngăn SQL Server tăng kích thước tệp không đồng đều trong SQL Server phiên bản 2014 trở về trước.
c. Nếu không thể khởi động lại Dịch vụ máy chủ SQL do RTO hoặc RPO, thì hãy thử các lệnh DBCC ở trên sau khi hiểu rõ các tác động.
d. Thu hẹp cơ sở dữ liệu tempdb hoặc các tệp dữ liệu không phải là cách tiếp cận được khuyến nghị và do đó không bao giờ làm điều đó trong môi trường Sản xuất của bạn trừ khi không có tùy chọn nào khác.
Kết luận
Chúng tôi đã tìm hiểu thêm về bên trong của cách hoạt động của tempdb để chúng tôi có thể định cấu hình tempdb để có hiệu suất tốt hơn, tránh các vấn đề tranh chấp trên tempdb. Chúng tôi cũng đã xem xét các vấn đề thường gặp phải trong tempdb, các biện pháp có sẵn trong SQL Server trên các phiên bản khác nhau và cách xử lý nó một cách hiệu quả. Ngoài ra, chúng tôi đã xem xét lý do tại sao Thu hẹp cơ sở dữ liệu tempdb hoặc các tệp dữ liệu không phải là cách tiếp cận được khuyến nghị khi xử lý cơ sở dữ liệu tempdb.
