বর্ধিত আপডেটের পরে পরিসংখ্যানগুলি অদৃশ্য হয়ে যায়

Question

আমাদের বর্ধিত পরিসংখ্যান ব্যবহার করে একটি বৃহত পার্টিশনযুক্ত এসকিউএল সার্ভার ডাটাবেস রয়েছে। সমস্ত সূচী সারিবদ্ধভাবে সাজানো আছে। যখন আমরা পার্টিশন দ্বারা একটি পার্টিশন অনলাইনে পুনর্নির্মাণের চেষ্টা করি তখন সূচি পুনঃনির্মাণের পরে সমস্ত পরিসংখ্যান অদৃশ্য হয়ে যায়।

অ্যাডভেঞ্চার ওয়ার্কস ২০১৪ ডাটাবেস সহ এসকিউএল সার্ভার ২০১৪-এ সমস্যাটির প্রতিলিপি দেওয়ার জন্য নীচে একটি স্ক্রিপ্ট রয়েছে।

--Example against AdventureWorks2014 Database

CREATE PARTITION FUNCTION TransactionRangePF1 (DATETIME)
AS RANGE RIGHT FOR VALUES 
(
   '20130501', '20130601', '20130701', '20130801', 
   '20130901', '20131001', '20131101', '20131201', 
   '20140101', '20140201', '20140301'
);
GO

CREATE PARTITION SCHEME TransactionsPS1 AS PARTITION TransactionRangePF1 TO 
(
  [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], 
  [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], 
  [PRIMARY], [PRIMARY], [PRIMARY]
);
GO

CREATE TABLE dbo.TransactionHistory 
(
  TransactionID        INT      NOT NULL, -- not bothering with IDENTITY here
  ProductID            INT      NOT NULL,
  ReferenceOrderID     INT      NOT NULL,
  ReferenceOrderLineID INT      NOT NULL DEFAULT (0),
  TransactionDate      DATETIME NOT NULL DEFAULT (GETDATE()),
  TransactionType      NCHAR(1) NOT NULL,
  Quantity             INT      NOT NULL,
  ActualCost           MONEY    NOT NULL,
  ModifiedDate         DATETIME NOT NULL DEFAULT (GETDATE()),
  CONSTRAINT CK_TransactionType 
    CHECK (UPPER(TransactionType) IN (N'W', N'S', N'P'))
) 
ON TransactionsPS1 (TransactionDate);


INSERT INTO dbo.TransactionHistory
SELECT * FROM Production.TransactionHistory
--  SELECT * FROM sys.partitions
--  WHERE object_id = OBJECT_ID('dbo.TransactionHistory');

CREATE NONCLUSTERED INDEX IDX_ProductId ON dbo.TransactionHistory (ProductId) 
  WITH (DATA_COMPRESSION = ROW, STATISTICS_INCREMENTAL=ON)  
  ON TransactionsPS1 (TransactionDate)

DBCC SHOW_STATISTICS('dbo.TransactionHistory', IDX_ProductId);
PRINT 'Stats are avialable'  

ALTER INDEX [IDX_ProductId] ON [dbo].[TransactionHistory] REBUILD 
  PARTITION = 9 WITH (ONLINE = ON , DATA_COMPRESSION = ROW)

PRINT 'After online index rebuild by partition stats are now gone'
DBCC SHOW_STATISTICS('dbo.TransactionHistory', IDX_ProductId);

PRINT 'Rebuild the stats with a rebuild for all paritions (this works)' 
ALTER INDEX [IDX_ProductId] ON [dbo].[TransactionHistory] REBUILD 
  PARTITION = ALL WITH (ONLINE = ON , DATA_COMPRESSION = ROW, 
  STATISTICS_INCREMENTAL = ON)

PRINT 'Stats are back'
DBCC SHOW_STATISTICS('dbo.TransactionHistory', IDX_ProductId);

PRINT 'Works correctly for an offline rebuild by partition'
ALTER INDEX [IDX_ProductId] ON [dbo].[TransactionHistory] REBUILD 
  PARTITION = 9 WITH (ONLINE = OFF , DATA_COMPRESSION = ROW)

    --stats still there  
DBCC SHOW_STATISTICS('dbo.TransactionHistory', IDX_ProductId);

ALTER INDEX [IDX_ProductId] ON [dbo].[TransactionHistory] REBUILD 
  PARTITION = 9 WITH (ONLINE = ON , DATA_COMPRESSION = ROW)

DBCC SHOW_STATISTICS('dbo.TransactionHistory', IDX_ProductId);
PRINT' stats are gone!!!!!!'

যেমন দেখানো হয়েছে, আমরা সূচীর জন্য সমস্ত পরিসংখ্যান না হারিয়ে পার্টিশন দ্বারা সূচিগুলি পুনরায় তৈরি করতে পারি না। এটি আমাদের জন্য রক্ষণাবেক্ষণের একটি বড় সমস্যা। এটি প্রায়শই উপস্থিত হয় যে পরিসংখ্যান বর্ধিত বিকল্পটি একক সূচক পুনর্নির্মাণ সিনট্যাক্সের একটি অংশ হওয়া দরকার বা অফলাইন বিকল্পের মতো অনলাইন বিকল্পটিকে এটি সঠিকভাবে পরিচালনা করতে হবে।

আমি যদি কিছু মিস করছি তবে দয়া করে আমাকে জানান?

আপডেট:

আমাদের বর্ধিত পরিসংখ্যানগুলির যতদূর প্রয়োজন: আমরা কোনও অভ্যন্তরীণ গ্রাহক আইডিতে পার্টিশন করছি, তারিখ নয়। সুতরাং যখন কোনও নতুন ক্লায়েন্ট আনা হবে (তথ্যের বৃহত ব্যাক-লোড) আমরা সহজেই পার্টিশনের জন্য পরিসংখ্যান আপডেট করতে পারি এবং এই নতুন গ্রাহকের জন্য যে কোনও কুৎসিত পরিকল্পনা তৈরি হচ্ছে তা দ্রুত এড়াতে পারি। আমি মনে করি আমি এটি একটি বাগ হিসাবে মাইক্রোসফ্টের কাছে ফাইল করব এবং তাদের কী বলতে হবে তা দেখুন এবং সেই পার্টিশনের জন্য পরিসংখ্যানগুলি পুনরায় স্যাম্পল করার সমাধান নিয়ে যাব।

সংযুক্ত বাগ রিপোর্ট:

অনলাইন সূচকগুলি ইনক্রিমেন্টাল পরিসংখ্যানগুলির সাথে পুনর্নির্মাণের পরে পরিসংখ্যানগুলি অদৃশ্য হয়ে যায়

আপডেট: মাইক্রোসফ্ট নিশ্চিত করেছে যে এটি একটি বাগ।

Comments

আপডেট: মাইক্রোসফ্ট আজ সকালে আমাকে একটি ইমেল পাঠিয়েছে যে এসকিউএল 2014 এর পরবর্তী সিইউ আপডেটে এই বাগটি সংশোধন করা হবে

— জেসনআর

আপনি কি জানেন যে কোন সিইউ এটি স্থির করেছে, বা কেবি কী তারা সেই ইমেলটিতে রিপোর্ট করেছে? কখন ঠিক করা হয়েছে তা দেখার চেষ্টা করছি।

— এমবার্গন

খুব নিশ্চিত যে এটি ভিএসটিএস বাগ নম্বর 8046729 কেবি নিবন্ধ নম্বর 3194959 যা এসকিউএল সার্ভার 2014 এসপি 1 এর জন্য সিইউ 9 এর একটি অংশ ছিল। কেবি'র একটি লিঙ্ক এখানে ।

— জেসনআর

হ্যাঁ, এটি দেখতে দেখতে দেখতে - এটি গত মাসে 2016SP1 এ ঠিক করা হয়েছিল। অনেক অনেক ধন্যবাদ!

— এমবার্গন

সংশোধন: সবেমাত্র 2016 এসপি 1 সিই 2 তে স্থির। এটি 2016 এসপি 1 সিই 1 এ ঘটে।

— এমবার্গন

Answer 1

এটি প্রতি বাগ কিনা তা নিশ্চিত নন তবে এটি অবশ্যই একটি আকর্ষণীয় ঘটনা। অনলাইন পার্টিশন পুনর্নির্মাণগুলি এসকিউএল সার্ভার ২০১৪-তে নতুন so

আপনার জন্য আমার সেরা ব্যাখ্যা এখানে। বর্ধিত পরিসংখ্যানগুলির জন্য একেবারে প্রয়োজন যে সমস্ত পার্টিশন একই হারে নমুনা করা উচিত যাতে ইঞ্জিন যখন পরিসংখ্যান পৃষ্ঠাগুলি একত্রিত করে তখন নিশ্চিত হয়ে যায় যে নমুনা বিতরণ তুলনীয়। REBUILDঅগত্যা 100% নমুনা হারে ডেটা স্যাম্পল করে। পার্টিশন 9-তে 100% নমুনা হার সর্বদা বাকী পার্টিশনের সঠিক নমুনার হার হতে চলেছে এমন কোনও গ্যারান্টি নেই। এর কারণ হিসাবে, এটি ইঞ্জিনটি নমুনাগুলি একীভূত করতে পারে না এমন মনে হয় এবং আপনি একটি খালি পরিসংখ্যান ব্লব দিয়ে শেষ করেন। তবে, পরিসংখ্যান অবজেক্ট এখনও আছে:

select 
    check_time = sysdatetime(),                         
    schema_name = sh.name,
    table_name = t.name,
    stat_name = s.name,
    index_name = i.name,
    stats_column = index_col(quotename(sh.name)+'.'+quotename(t.name),s.stats_id,1),
    s.stats_id,
    s.has_filter,                       
    s.is_incremental,
    s.auto_created,
    sp.last_updated,    
    sp.rows,
    sp.rows_sampled,                        
    sp.unfiltered_rows,
    modification_counter 
from sys.stats s 
join sys.tables t 
    on s.object_id = t.object_id
join sys.schemas sh
    on t.schema_id = sh.schema_id
left join sys.indexes i 
    on s.object_id = i.object_id
    and s.name = i.name
outer apply sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
where t.name = 'TransactionHistory' and sh.name = 'dbo'

আপনি যে কোনও সংখ্যক মাধ্যমে ব্লবটি পূরণ করতে পারেন:

UPDATE STATISTICS dbo.TransactionHistory (IDX_ProductId) WITH RESAMPLE;

অথবা

UPDATE STATISTICS dbo.TransactionHistory (IDX_ProductId) WITH RESAMPLE ON PARTITIONS (9);

অথবা আপনি সেই বস্তুটি ব্যবহার করে কোনও ক্যোয়ারী পরিকল্পনার প্রথম সংকলনটিতে অটোস্ট্যাটসের আপডেট হওয়ার অপেক্ষা করতে পারেন:

-- look at my creative query
select * 
from dbo.TransactionHistory
where TransactionDate = '20140101';

সব বলেছে, ইরিন স্টেলাটো এই আলোকিত পোস্ট post যা বর্ধিত পরিসংখ্যানের একটি বড় ঘাটতি হিসাবে বিবেচিত হয়েছে তা তুলে ধরেছে। তাদের পার্টিশন-স্তরের ডেটাগুলি কোয়েরি প্ল্যান জেনারেশনে অপ্টিমাইজার ব্যবহার করে না, বর্ধিত পরিসংখ্যানগুলির অনুমিত সুবিধা হ্রাস করে। তাহলে, বর্ধিত পরিসংখ্যানের বর্তমান উপকারটি কী? আমি জমা দিচ্ছি যে তাদের প্রাথমিক ইউটিলিটি tableতিহ্যগত পরিসংখ্যানের তুলনায় আরও বেশি হারে আরও বড় ধারাবাহিকভাবে বড় টেবিলগুলির নমুনা নেওয়ার ক্ষমতাতে রয়েছে।

আপনার উদাহরণ ব্যবহার করে জিনিসগুলি দেখতে কেমন তা এখানে:

set statistics time on;

update statistics dbo.TransactionHistory(IDX_ProductId)
with fullscan;

--SQL Server Execution Times:
--  CPU time = 94 ms,  elapsed time = 131 ms.


update statistics dbo.TransactionHistory(IDX_ProductId)
with resample on partitions(2);

 --SQL Server Execution Times:
 --  CPU time = 0 ms,  elapsed time = 5 ms.

drop index IDX_ProductId On dbo.TransactionHistory;

CREATE NONCLUSTERED INDEX IDX_ProductId ON dbo.TransactionHistory (ProductId) 
  WITH (DATA_COMPRESSION = ROW)  
  ON [PRIMARY]

update statistics dbo.TransactionHistory(IDX_ProductId)
with fullscan;

 --SQL Server Execution Times:
 --  CPU time = 76 ms,  elapsed time = 66 ms.

বর্ধিত পরিসংখ্যান সম্পর্কিত পূর্ণ স্ক্যান পরিসংখ্যান আপডেটের মূল্য 131 এমএস। নন পার্টিশন-অ্যালাইনড স্ট্যাটিস্টিকের জন্য সম্পূর্ণ স্ক্যান পরিসংখ্যান আপডেট update costs এমএস। অ্যালায়েন্সযুক্ত পরিসংখ্যানগুলি ওভারহেডের কারণে ব্যয় হওয়ায় সম্ভবত ধীর মূল-হিস্টোগ্রামে স্বতন্ত্র পরিসংখ্যান পৃষ্ঠাগুলি আবার মার্জ করে। যাইহোক, পার্টিশন-সারিবদ্ধ পরিসংখ্যান অবজেক্টটি ব্যবহার করে আমরা একটি পার্টিশন আপডেট করতে পারি এবং 5 এমএসে এটিকে আবার মূল হিস্টগ্রাম ব্লাবে রূপান্তর করতে পারি। সুতরাং এই মুহুর্তে বর্ধিত পরিসংখ্যান সহ প্রশাসক একটি সিদ্ধান্তের মুখোমুখি হন। তারা কেবলমাত্র পার্টিশনগুলি আপডেট করার মাধ্যমে তাদের সামগ্রিক পরিসংখ্যান রক্ষণাবেক্ষণের সময় হ্রাস করতে পারে traditionতিহ্যগতভাবে আপডেট করার প্রয়োজন হবে বা তারা উচ্চতর নমুনা হার নিয়ে পরীক্ষা করতে পারে যাতে তারা আগের রক্ষণাবেক্ষণের সময়সীমার একই সময়ের মধ্যে আরও সারি নমুনা পেতে পারে get প্রাক্তনটি রক্ষণাবেক্ষণ উইন্ডোতে শ্বাসকষ্টের অনুমতি দেয়, পরবর্তীটিহতে পারে খুব বড় টেবিলে এমন একটি স্থানে পরিসংখ্যান যেখানে কোয়েরি আরও সঠিক পরিসংখ্যানের ভিত্তিতে আরও ভাল পরিকল্পনা করে। এটি কোনও গ্যারান্টি নয় এবং আপনার মাইলেজটি আলাদা হতে পারে।

পাঠক দেখতে পাচ্ছেন যে এই টেবিলটিতে ms 66 এমএস একটি বেদনাদায়ক পরিসংখ্যান আপডেটের সময় নয় তাই আমি স্ট্যাকেক্সচেঞ্জের ডেটা সেটটিতে একটি পরীক্ষা করার চেষ্টা করেছি। আমি যে সাম্প্রতিক ডাম্প ডাউনলোড করেছি তাতে 6,418,608 টি পোস্ট রয়েছে (2012 সালের স্ট্যাকওভারফ্লো পোস্টগুলি এবং সমস্ত পোস্টগুলি - আমার পক্ষ থেকে একটি ডেটা ত্রুটি)।

আমি ডেটা ভাগ করেছি [CreationDate]কারণ ... ডেমো।

কিছু চমত্কার স্ট্যান্ডার্ড দৃশ্যের জন্য এখানে কিছু সময় রয়েছে (100% - সূচি পুনর্নির্মাণ, ডিফল্ট - পরিসংখ্যান স্বতঃ-আপডেট বা UPDATE STATISTICSনির্দিষ্ট নমুনা হার ছাড়াই:

• ফুলস্ক্যান সহ অ বর্ধিত পরিসংখ্যান তৈরি করুন: সিপিইউ সময় = 23500 এমএস, অতিবাহিত সময় = 22521 এমএস।
• পূর্ণ স্ক্যান সহ বর্ধিত পরিসংখ্যান তৈরি করুন: সিপিইউ সময় = 20406 এমএস, অতিবাহিত সময় = 15413 এমএস।
• ডিফল্ট নমুনা হারের সাথে অ বর্ধিত পরিসংখ্যান আপডেট করুন: সিপিইউ সময় = 406 এমএস, অতিবাহিত সময় = 408 এমএস।
• ডিফল্ট নমুনা হার সহ বর্ধিত পরিসংখ্যান আপডেট করুন: সিপিইউ সময় = 453 এমএস, অতিবাহিত সময় = 507 এমএস।

ধরা যাক আমরা এই পূর্বনির্ধারিত পরিস্থিতিতে তুলনায় আরও পরিশীলিত হয়েছি এবং সিদ্ধান্ত নিয়েছি যে 10% নমুনা হার হ'ল ন্যূনতম হার যা আমাদের প্রয়োজনমত পরিকল্পনা গ্রহণ করা উচিত যখন রক্ষণাবেক্ষণের সময়টি একটি যুক্তিসঙ্গত সময়সীমার সাথে রাখে।

• নমুনা 10 শতাংশ সহ অ-বর্ধিত পরিসংখ্যান আপডেট করুন: সিপিইউ সময় = 2344 এমএস, অতিবাহিত সময় = 2441 এমএস।
• নমুনা 10 শতাংশ সহ বর্ধিত পরিসংখ্যান আপডেট করুন: সিপিইউ সময় = 2344 মিমি, অতিবাহিত সময় = 2388 এমএস।

এখনও পর্যন্ত একটি বর্ধিত পরিসংখ্যান থাকার কোনও সুস্পষ্ট সুবিধা নেই benefit তবে, আমরা যদি অনিবন্ধিত sys.dm_db_stats_properties_internal() ডিএমভি (নীচে) কে উত্তোলন করি তবে আপনি কোন বিভাজন (গুলি) আপডেট করতে চাইতে পারেন সে সম্পর্কে কিছুটা অন্তর্দৃষ্টি পেতে পারেন। ধরা যাক আমরা পার্টিশন 3-তে ডেটাতে পরিবর্তন করেছি এবং আমরা নিশ্চিত করতে চাই যে পরিসংখ্যানগুলি আগত জিজ্ঞাসার জন্য নতুন are আমাদের বিকল্পগুলি এখানে:

• ডিফল্ট অ বর্ধিত আপডেট করুন (অটো-স্ট্যাটাস আপডেটের ডিফল্ট আচরণও): 408 এমএস।
• 10%: 2441 এমএস এ অ-বর্ধিত আপডেট করুন।
• বর্ধিত পরিসংখ্যান আপডেট করুন, পুনরায় নমুনা সহ পার্টিশন 3 (10% - আমাদের সংজ্ঞায়িত নমুনার হার): সিপিইউ সময় = 63 এমএস, অতিবাহিত সময় = 63 এমএস।

আমাদের এখানে সিদ্ধান্ত নেওয়া দরকার। আমরা কি 63৩ এমএসের বিজয় নিই? পার্টিশন ভিত্তিক পরিসংখ্যান ভিত্তিক আপডেট, বা আমরা কি আরও বেশি নমুনা হার bump? ধরা যাক আমরা বর্ধিত পরিসংখ্যানের ভিত্তিতে নমুনা গ্রহণের প্রাথমিক হিট 50% এ নিতে ইচ্ছুক:

• 50% এ বর্ধিত পরিসংখ্যান আপডেট করুন: অতিবাহিত সময় = 16840 এমএস।
• বর্ধিত পরিসংখ্যান আপডেট করুন, পুনরায় নমুনা সহ পার্টিশন 3 (50% - আমাদের নতুন আপডেটের সময়): অতিবাহিত সময় = 295 এমএস।

আমরা আরও অনেক ডেটা নমুনা করতে সক্ষম হয়েছি, সম্ভবত আমাদের ডেটা সম্পর্কে আরও ভাল অনুমানের জন্য অপ্টিমাইজার স্থাপন করা (যদিও এটি পার্টিশন-স্তরের পরিসংখ্যানগুলি ব্যবহার করছে না, যদিও) এবং আমরা এখন এটি আরও দ্রুত করতে সক্ষম হয়েছি বর্ধিত পরিসংখ্যান।

যদিও শেষ একটি মজার জিনিস। সিঙ্ক্রোনাস স্ট্যাটাস আপডেট সম্পর্কে কী? অটোস্ট্যাটস কিক লাগানো অবস্থায়ও কি 50% নমুনা হার সংরক্ষণ করা যায়?

আমি পার্টিশন 3 থেকে ডেটা মুছলাম এবং ক্রিয়েশনডেটে একটি কোয়েরি চালিয়েছি এবং নীচে একই কোয়েরির সাথে রেটগুলি চেক করেছি checked 50% নমুনা হার সংরক্ষণ করা হয়েছিল।

সুতরাং, দীর্ঘ গল্প সংক্ষিপ্ত: বর্ধিত পরিসংখ্যান সঠিক পরিমাণে চিন্তাভাবনা এবং প্রাথমিক সেটআপ কাজের সাথে একটি দরকারী সরঞ্জাম হতে পারে। তবে, আপনি যে সমস্যাটি সমাধান করার চেষ্টা করছেন তা অবশ্যই আপনার জানা উচিত এবং তারপরে আপনার যথাযথভাবে সমাধান করার প্রয়োজন। আপনি খারাপ cardinality অনুমান পেয়ে থাকেন, তাহলে আপনি পারে একটি কৌশলগত নমুনা হার এবং কিছু বিনিয়োগ হস্তক্ষেপের মাধ্যমে আরও ভাল পরিকল্পনা পেতে সক্ষম হবেন। তবে, আপনি কেবলমাত্র সুবিধার একটি অল্প অংশ পাচ্ছেন যেহেতু হিস্টোগ্রামটি ব্যবহৃত হচ্ছে একক, মার্জড পরিসংখ্যান পৃষ্ঠা এবং পার্টিশন-স্তরের তথ্য নয়। আপনি যদি আপনার রক্ষণাবেক্ষণ উইন্ডোতে ব্যথা অনুভব করেন তবে সম্ভবত বর্ধিত পরিসংখ্যান আপনাকে সহায়তা করতে পারে তবে সম্ভবত এটি আপনাকে উচ্চ-স্পর্শ রক্ষণাবেক্ষণের হস্তক্ষেপ প্রক্রিয়া সেটআপ করার প্রয়োজন হবে। নির্বিশেষে, মনে রাখবেন:

• সূচিগুলি দিয়ে তৈরি পরিসংখ্যানগুলি যা বেস টেবিলের সাথে পার্টিশন-প্রান্তিক নয়।
• সর্বদা পঠনযোগ্য মাধ্যমিক ডাটাবেসগুলিতে পরিসংখ্যান তৈরি হয়েছে।
• পরিসংখ্যানগুলি কেবল পঠনযোগ্য ডেটাবেজে তৈরি করা হয়েছে।
• ফিল্টার সূচকগুলিতে পরিসংখ্যান তৈরি।
• পরিসংখ্যান ভিউ তৈরি।
• অভ্যন্তরীণ টেবিলগুলিতে পরিসংখ্যান তৈরি হয়েছে।
• স্থানিক সূচকগুলি বা এক্সএমএল সূচী দিয়ে তৈরি পরিসংখ্যান।

আশাকরি এটা সাহায্য করবে

select 
    sysdatetime(),                          
    schema_name = sh.name,
    table_name = t.name,
    stat_name = s.name,
    index_name = i.name,
    leading_column = index_col(quotename(sh.name)+'.'+quotename(t.name),s.stats_id,1),
    s.stats_id,
    parition_number = isnull(sp.partition_number,1),
    s.has_filter,                       
    s.is_incremental,
    s.auto_created,
    sp.last_updated,    
    sp.rows,
    sp.rows_sampled,                        
    sp.unfiltered_rows,
    modification_counter = coalesce(sp.modification_counter, n1.modification_counter) 
from sys.stats s 
join sys.tables t 
    on s.object_id = t.object_id
join sys.schemas sh
    on t.schema_id = sh.schema_id
left join sys.indexes i 
    on s.object_id = i.object_id
        and s.name = i.name
cross apply sys.dm_db_stats_properties_internal(s.object_id, s.stats_id) sp
outer apply sys.dm_db_stats_properties_internal(s.object_id, s.stats_id) n1
where n1.node_id = 1
    and (
            (is_incremental = 0)
               or
            (is_incremental = 1 and sp.partition_number is not null)
         )
    and t.name = 'Posts'
    and s.name like 'st_posts%'
order by s.stats_id,isnull(sp.partition_number,1)