Phiên bản: SQL Server 2008 R2 Enterprise Edtn. (10.50.4000)
Trong nỗ lực đánh giá chiến lược phân vùng của chúng tôi, tôi đã viết truy vấn này để có được các phương thức truy cập chống lại các chỉ mục trên các phân vùng (theo nghĩa rộng nhất của thuật ngữ này, mặc dù tôi đang loại bỏ hàng đống). Khi tôi thu hẹp sự tập trung của mình vào các bảng được phân vùng, tôi tin rằng tôi cần phải xem xét range_scan_countvà singleton_lookup_countđang gặp khó khăn trong việc khái niệm hóa.
SELECT
t.name AS table_name,
i.name AS index_name,
ios.partition_number,
leaf_insert_count,
leaf_delete_count,
leaf_update_count,
leaf_ghost_count,
range_scan_count,
singleton_lookup_count,
page_latch_wait_count ,
page_latch_wait_in_ms,
row_lock_count ,
page_lock_count,
row_lock_wait_in_ms ,
page_lock_wait_in_ms,
page_io_latch_wait_count ,
page_io_latch_wait_in_ms
FROM sys.dm_db_partition_stats ps
JOIN sys.tables t
ON ps.object_id = t.object_id
JOIN sys.schemas s
ON t.schema_id = s.schema_id
JOIN sys.indexes i
ON t.object_id = i.object_id
AND ps.index_id = i.index_id
OUTER APPLY sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) ios
WHERE
ps.object_id = ios.object_id
AND ps.index_id = ios.index_id
AND ps.partition_number = ios.partition_number
and ps.index_id = ios.index_id
and ps.partition_number = ios.partition_number
and s.name <> 'sys'
and ps.index_id <> 0 ;Đầu ra có liên quan (được cung cấp khoảng cách trong định dạng bảng của SO, đây là mẫu của 9 cột đầu tiên từ truy vấn ở trên với hai cột cuối cùng range_scan_countvà singleton_lookup_count, tương ứng):
╔════════╦═════════════════╦════╦═══╦═══╦═══╦═══╦════════╦══════════╗
║ datetb ║ idx_datetb_col ║ 1 ║ 0 ║ 0 ║ 0 ║ 0 ║ 205740 ║ 3486408 ║
║ datetb ║ idx_datetb_col ║ 2 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 1079649 ║
║ datetb ║ idx_datetb_col ║ 3 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 1174547 ║
║ datetb ║ idx_datetb_col ║ 4 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 2952991 ║
║ datetb ║ idx_datetb_col ║ 5 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 3974886 ║
║ datetb ║ idx_datetb_col ║ 6 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 2931450 ║
║ datetb ║ idx_datetb_col ║ 7 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 3316960 ║
║ datetb ║ idx_datetb_col ║ 8 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 3393439 ║
║ datetb ║ idx_datetb_col ║ 9 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 3735495 ║
║ datetb ║ idx_datetb_col ║ 10 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 4803804 ║
║ datetb ║ idx_datetb_col ║ 11 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 7655091 ║
║ datetb ║ idx_datetb_col ║ 12 ║ 1 ║ 0 ║ 0 ║ 0 ║ 174326 ║ 47377226 ║
╚════════╩═════════════════╩════╩═══╩═══╩═══╩═══╩════════╩══════════╝Tôi thấy một vài khả năng khác nhau nhưng tôi cần một số hướng về cách suy nghĩ về điều này (tất nhiên tôi đang nói điều này trong " có thể " bởi vì tôi biết rằng "nó phụ thuộc", nhưng tôi cũng đang tìm kiếm sự hiểu biết khái niệm):
- Các giá trị tương tự cho tất cả các phân vùng
range_scan_countcó thể chỉ ra rằng chúng tôi không loại bỏ phân vùng tốt vì chúng tôi đang quét tất cả các phân vùng có cùng số lần. - Các giá trị khác nhau cho tất cả các phân vùng
singleton_lookup_countđi kèm với các giá trị thấp hơn đáng kểrange_scan_countcó thể cho thấy loại bỏ phân vùng thường xuyên tốt vì chúng tôi đang quét ít hơn chúng tôi đang tìm kiếm. - ?
Đó là những suy nghĩ của tôi cho đến nay. Tôi đã hy vọng có ai đó cân nhắc về cách tôi có thể sử dụng thông tin này hoặc một bộ thông tin khác, để xác định bảng nào có thể có lợi nhất từ việc bỏ phân vùng có lợi cho các chỉ mục hoàn toàn.
BIÊN TẬP
Đây là một DDL bị cắt:
CREATE TABLE [dbo].[date_table](
[date_id] [int] NOT NULL,
[calendar_date] [datetime] NULL,
[valdate] [datetime] NULL,
CONSTRAINT [PK_datedb] PRIMARY KEY CLUSTERED
(
[date_id] ASC
) ON [partschm]([date_id]);
CREATE UNIQUE NONCLUSTERED INDEX [idx_datetb_col] ON [dbo].[date_table]
(
[calendar_date] DESC,
[date_id] ASC
) ON [partschm]([date_id])
GO