क्या यह निर्धारित करने का एक विश्वसनीय तरीका है कि आपको अंतरिक्ष को पुनः प्राप्त करने के लिए DBCC CLEANTABLE को कब चलाना चाहिए?

Question

80% फ़ाइल उपयोग के निकट होने पर, केवल बढ़ती फ़ाइलों के बजाय, मैं सामान्य चाल के माध्यम से अंतरिक्ष को पुनः व्यवस्थित करने में अधिक सक्रिय रहा हूँ, जैसे कि ढेर सूचकांक को जोड़ना, घटित अनुक्रमों को जोड़ना और पंक्ति या पृष्ठ संपीड़न को लागू करना, आदि।

हालाँकि, ऐसे कुछ मामले हैं जहाँ मैं DBCC CLEANTABLE को निष्पादित करके और भी अधिक स्थान प्राप्त करने में सक्षम था । मेरे वातावरण में सैकड़ों डेटाबेस के साथ, यह जानना संभव नहीं है कि उपयोगकर्ता प्रत्येक में क्या करते हैं और यह पूरी तरह से स्वीकार्य है कि निश्चित लंबाई के स्तंभों को छोड़ने से जुड़े परिवर्तन होंगे। मैंने आमतौर पर पंक्ति के काउंट बनाम पेज काउंट को कुछ ऑब्जेक्ट स्पेस उपयोग स्क्रिप्ट्स में देखा है जिन्हें मैंने लिखा है। मैं इस प्रकार के परिदृश्यों का पता लगाने का प्रयास करके इसे और आगे ले जाना चाहता हूँ।

मैं जानना चाहता हूं कि क्या कोई है जो इस तरह के अवसरों के लिए सक्रिय रूप से निगरानी कर रहा है और यदि हां, तो आप विशेष रूप से क्या देखते हैं?

मेरे विचार पंक्ति के अधिकतम और न्यूनतम आकार, तालिका में पंक्तियों की संख्या, आवंटित किए गए पृष्ठों की संख्या और उपयोग किए गए पृष्ठों की संख्या के साथ कुछ लिखने के लिए थे, फिर परिणाम लॉग करने के लिए कुछ बुनियादी गणित कर रहे थे कि अच्छी तरह से बाहर हैं "उम्मीद" क्या होगा।

Comments

मैं बड़े टेबल पर बैच_साइज पैरामीटर का उपयोग करने की अत्यधिक सलाह देता हूं। यह एक विशाल लेनदेन के विपरीत आदेश को लेनदेन की एक श्रृंखला में चलाने का कारण होगा।

— डेटागोड

Answer 1

इस समस्या के लिए मैं जो उपाय सोचता हूं, वह है साप्ताहिक रूप से एक नौकरी चलाना जो डेटाबेस में सभी तालिकाओं के लिए sp_spaceused चलेंगे और इस डेटा को एक तालिका में सहेजेंगे। यदि प्रत्येक तालिका के लिए आकार में भिन्नताएं हैं..ज्यादा से कहें..10%, मैं dbcc को साफ-सुथरा चलाऊंगा।

तालिका आकार के माध्यम से लूप को मेरा कोड इस तरह दिखता है:

if OBJECT_ID ('tempdb.dbo.#temp') is not null
    drop table #temp;

if OBJECT_ID ('dbo.BigTables') is not null
    drop table dbo.BigTables;
go

CREATE TABLE [dbo].[BigTables] (
    [table_name] [sysname] NOT NULL,
    [row_count] [int] NULL,
    [col_count] [int] NULL,
    [data_size] [varchar](50) NULL,
    [Date] [datetime] NOT NULL,
    [DBName] [nvarchar](128) NULL
);
GO

CREATE TABLE #temp (
    table_name sysname ,
    row_count int,
    reserved_size varchar(50),
    data_size varchar(50),
    index_size varchar(50),
    unused_size varchar(50)
);
go

INSERT     #temp
EXEC       sp_msforeachtable 'sp_spaceused ''?'''

insert into dbo.BigTables
SELECT     a.table_name,
           a.row_count,
           count(*) as col_count,
           a.data_size,
           getdate() as [Date],
    'MY DB' as DBName
FROM       #temp a
INNER JOIN information_schema.columns b
           ON a.table_name collate database_default
                = b.table_name collate database_default
GROUP BY   a.table_name, a.row_count, a.data_size
ORDER BY   CAST(Replace(a.data_size, ' KB', '') as integer) desc

DROP TABLE #temp;

Select * from dbo.BigTables;

अब आपको केवल तर्क का निर्माण करने की आवश्यकता है जो यह सत्यापित करेगा कि सप्ताह के माध्यम से आकार में क्या बदलाव होगा और इसे शेड्यूल किया जाएगा।

Comments

अब, यदि तालिका आकार रिपोर्ट में अशुद्धि पर संदेह करने के कारण हैं, तो आपको DBCC UPDATEUSAGE के लिए जाना चाहिए (यह पंक्ति और पृष्ठ संख्या को ठीक कर देगा)। सहायता करके हमें खुशी होगी!

— मरिअन