সংস্করণ: এসকিউএল সার্ভার ২০০৮ আর 2 এন্টারপ্রাইজ এড্টন। (10.50.4000)
আমাদের বিভাজন কৌশলটি মূল্যায়ন করার প্রয়াসে, আমি পার্টিশনগুলিতে সূচকের বিপরীতে অ্যাক্সেসের পদ্ধতিগুলি পেতে (এই শব্দটির বিস্তৃত অর্থে, যদিও আমি স্তূপগুলি অপসারণ করছি) এই প্রশ্নটি লিখেছিলাম wrote পার্টিশনযুক্ত টেবিলগুলিতে আমার ফোকাস সংকীর্ণ করার সাথে সাথে আমি বিশ্বাস করি যে আমাকে দেখার প্রয়োজন 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 ;প্রাসঙ্গিক আউটপুট (টেবিলগুলির এসওর ফর্ম্যাটিংয়ের ফাঁক প্রদত্ত, এটি শেষের দুটি স্তম্ভ range_scan_countএবং singleton_lookup_countযথাক্রমে কোয়েরি থেকে প্রথম 9 টি কলামের একটি নমুনা ):
╔════════╦═════════════════╦════╦═══╦═══╦═══╦═══╦════════╦══════════╗
║ 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