Làm thế nào để tìm hiểu số liệu đọc/ghi của bảng SQL Server?

Question

Có cách nào để tìm số liệu thống kê trên bảng đọc và ghi trên SQL Server 2005/2008?

Tôi đặc biệt đang tìm kiếm DMVs/DMFs mà không sử dụng trình kích hoạt hoặc kiểm tra.

Mục tiêu ở đây là để tìm hiểu yếu tố làm phù hợp với chỉ số - có một ý tưởng từ bài viết này (Fill Factor Defined).

---

[UPDATE] Có một theo dõi câu hỏi trên ServerFault
How to determine Read/Write intensive table from DMV/DMF statistics

Answer 1

• sys.dm_db_index_physical_stats (kích thước và sự phân mảnh)
• sys.dm_db_index_usage_stats (sử dụng, số quét/tìm kiếm/cập nhật v.v.)
• sys.dm_db_index_operational_stats (hoạt động hiện tại trên chỉ mục)

Nhớ 'bảng' có nghĩa là chỉ mục nhóm hoặc 'đống'.

Answer 2

Để xác định hệ số lấp đầy thích hợp cho chỉ mục của bảng, bạn cần xem xét số lượng phân tách trang xảy ra. Điều này được hiển thị trong sys.dm_db_index_operational_stats:

Số phân bổ lá: Tổng số trang chia tách ở cấp độ lá của chỉ mục.

Số phân bổ không phải là số: Tổng số lần chia trang trên cấp độ lá của chỉ mục.

Tổng hợp trang lá: Tổng số trang được hợp nhất ở cấp độ lá của chỉ mục.

Sau khi thực hiện một chút đào, tôi đã nhìn thấy một vài bài viết nói rằng số trang phân chia từ DMV không hữu ích (tôi chưa xác nhận cá nhân điều này), nhưng cũng có một bộ đếm hiệu suất " chia tách/giây "(nhưng nó chỉ ở cấp độ cá thể SQL Server).

Tôi sử dụng quy tắc chung mà các bảng thông thường sử dụng hệ số lấp đầy 90% mặc định, các bảng chèn cao ở đâu đó từ 70 - 85% (tùy thuộc vào kích thước hàng). Chỉ đọc các bảng có thể sử dụng hệ số lấp đầy của 100%

Answer 3

Truy vấn sau có thể được sử dụng để tìm số đọc và ghi trên tất cả các bảng trong cơ sở dữ liệu. Kết quả truy vấn này có thể được xuất sang tệp CSV và sau đó sử dụng công thức excel bạn có thể dễ dàng tính toán tỷ lệ đọc/ghi. Rất hữu ích trong khi kế hoạch chỉ mục trên một bảng

DECLARE @dbid int 
SELECT @dbid = db_id('database_name') 

SELECT TableName = object_name(s.object_id), 
     Reads = SUM(user_seeks + user_scans + user_lookups), Writes = SUM(user_updates) 
FROM sys.dm_db_index_usage_stats AS s 
INNER JOIN sys.indexes AS i 
ON s.object_id = i.object_id 
AND i.index_id = s.index_id 
WHERE objectproperty(s.object_id,'IsUserTable') = 1 
AND s.database_id = @dbid 
GROUP BY object_name(s.object_id) 
ORDER BY writes DESC 

Answer 4

Nếu bạn có một nhóm chỉ số tốt (ví dụ, ngày càng tăng, độc đáo, hẹp) thì vấn đề xác định thực sự cho Fill Yếu tố là làm thế nào bảng được cập nhật và các kiểu dữ liệu của các cột. Nếu các cột đều có kích thước cố định (ví dụ: số nguyên, thập phân, phao, Char) và không thể vô hiệu thì bản cập nhật không thể tăng dung lượng cần thiết cho một hàng.Với chỉ số nhóm tốt, bạn nên chọn một Hệ số lấp đầy là 90+ thậm chí 100 kể từ khi chia tách trang sẽ không xảy ra. Nếu bạn có một vài cột có độ dài thay đổi (ví dụ: Varchar để giữ Tên người dùng) và các cột ít khi được cập nhật sau khi chèn thì bạn vẫn có thể giữ một Hệ số điền tương đối cao. Nếu bạn có dữ liệu có độ dài thay đổi cao (ví dụ: đường dẫn UNC, trường Nhận xét, XML) thì nên giảm Hệ số lấp đầy. Đặc biệt nếu các cột được cập nhật thường xuyên và phát triển (như cột bình luận). Chỉ mục không được phân cụm thường giống nhau, ngoại trừ khóa chỉ mục có thể có vấn đề hơn (không phải duy nhất, có lẽ không bao giờ tăng). Tôi nghĩ rằng sys.dm_db_index_physical_stats cung cấp các số liệu tốt nhất cho điều này nhưng nó là sau khi thực tế. Nhìn vào kích thước bản ghi avg/min/max, kích thước fragg frag, không gian trang avg được sử dụng để có được một hình ảnh về cách không gian chỉ mục đang được sử dụng. HTH.