संस्करण: SQL सर्वर 2008 R2 एंटरप्राइज़ Edtn। (10.50.4000)
हमारी विभाजन की रणनीति का मूल्यांकन करने के प्रयास में, मैंने विभाजन पर अनुक्रमणिका के विरुद्ध पहुँच विधियों को प्राप्त करने के लिए यह क्वेरी लिखी (शब्द के व्यापक अर्थ में, हालांकि मैं ढेर मिटा रहा हूँ)। मैं विभाजित तालिकाओं के लिए मेरी फ़ोकस को संकीर्ण रूप में, मैं मैं पर विचार करना की जरूरत का मानना है range_scan_countऔर singleton_lookup_countलेकिन एक कठिन समय कोंसेप्टूलाइज़िंग हो रहा है।
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 ;
प्रासंगिक उत्पादन (एसओ को सारणी के प्रारूपण में अंतर को देखते हुए, यह पिछले 9 स्तंभों के साथ ऊपर दिए गए क्वेरी से पहले 9 स्तंभों का एक नमूना है range_scan_countऔर singleton_lookup_countक्रमशः):
╔════════╦═════════════════╦════╦═══╦═══╦═══╦═══╦════════╦══════════╗
║ 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 ║
╚════════╩═════════════════╩════╩═══╩═══╩═══╩═══╩════════╩══════════╝
मैं कुछ अलग संभावना देखता हूं, लेकिन मुझे इस बारे में सोचने के लिए कुछ दिशा की आवश्यकता है (निश्चित रूप से मैं इसे " मई " में काउच कर रहा हूं क्योंकि मुझे पता है कि "यह निर्भर करता है", लेकिन मैं वैचारिक समझ की भी तलाश कर रहा हूं):
- के सभी विभाजनों के लिए इसी तरह मान
range_scan_countसकते हैं संकेत मिलता है कि हम अच्छा विभाजन उन्मूलन नहीं मिल रहे हैं, क्योंकि हम मोटे तौर पर बराबर बार सभी विभाजनों को स्कैन कर रहे हैं। - सभी
singleton_lookup_countनिम्न विभाजनों के साथ भिन्न मानों के लिए भिन्न मान अच्छे विभाजन को समाप्त करने का संकेतrange_scan_countहो सकता है क्योंकि हम जो मांग रहे हैं उससे कम स्कैन कर रहे हैं। - ?
वे अब तक के मेरे विचार हैं। मैं उम्मीद कर रहा था कि कोई व्यक्ति इस पर भार डाल सकता है कि मैं इसका उपयोग कैसे करूं, या जानकारी का एक और सेट, यह निर्धारित करने के लिए कि कौन से तालिकाओं को विभाजन के पक्ष में पूरी तरह से छोड़ने से लाभ होगा।
संपादित करें
यहाँ एक क्लिप डीडीएल है:
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