ক্লাস্টারড ইনডেক্সে পুনর্নির্মাণ করুন, কেন ডেটাসাইজ সঙ্কুচিত হবে?

Question

যখন আমরা একটি টেবিলের ক্লাস্টারড ইনডেক্সে একটি পুনর্নির্মাণ করেছি যার মধ্যে প্রায় 15gb ডেটা রয়েছে এবং ডেটাসাইজ সঙ্কুচিত হয়ে 5 জিবি হয়, এটি কীভাবে হতে পারে? কোন ধরণের "ডেটা" সরানো হয়?

ডেটা সাইজ বলতে আমি ডিবিসিসির এসপি_স্পেসেসের "ডেটা" কলামটি বুঝি

ক্লাস্টারড ইনডেক্সে পুনর্নির্মাণের আগে:

name                  rows        reserved    data        index_size  unused
LEDGERJOURNALTRANS    43583730    39169656 KB 15857960 KB 22916496 KB 395200 KB

---

ক্লাস্টারড ইনডেক্সে পুনর্নির্মাণের পরে:

name                  rows        reserved    data        index_size  unused
LEDGERJOURNALTRANS    43583730    29076736 KB 5867048 KB  22880144 KB 329544 KB

পুনর্নির্মাণের জন্য টিএসকিউএল:

USE [DAX5TEST]
GO
ALTER INDEX [I_212RECID] ON [dbo].[LEDGERJOURNALTRANS] REBUILD PARTITION = ALL WITH ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, ONLINE = ON, SORT_IN_TEMPDB = OFF, DATA_COMPRESSION = PAGE, FILLFACTOR = 85 )
GO

Comments

আপনি কি ফাইলের আকার থেকে ডেটা আকার নির্ধারণ করছেন?

— জেএনকে

ডেটা আকারের অর্থ আমি ডিবিসিসির এসপি_স্পেসের "ডেটা" কলামটি বুঝি

— ড্যানিয়েল

এটি হবে "ডেটা" কলামের EXEC sp_spaceused।

— আরএলএফ

প্রতিটি শরীর কি মিস করেছে যে ওপি তার পুনর্নির্মাণ স্ক্রিপ্টে পৃষ্ঠা সংক্ষেপণ = সক্ষম করেছে এবং আমি অনুমান করি যে এটি আগে ছিল না। ড্যানিয়েল আপনি নিশ্চিত করতে পারেন?

— শানকি

@ শ্যাঙ্কি: ALTER INDEXউক্তিটি দেখে মনে হচ্ছে এটি কোড দ্বারা উত্পন্ন হয়েছিল (এটিতে তাদের ডিফল্ট সেটিংয়ে বিকল্পগুলির একটি গোছা রয়েছে) তাই আমার সন্দেহ হয় যে এটি সূচকের বিদ্যমান বিকল্পগুলি থেকে তৈরি হয়েছিল। তবে আপনি ঠিক বলেছেন: এটি চালানোর আগে যদি ক্লাস্টারড ইনডেক্সে সংক্ষেপণ সক্ষম না করা হত তবে ডেটা পায়ের ছাপ হ্রাসের বেশিরভাগ বিষয়টি অবশ্যই স্পষ্টভাবে ব্যাখ্যা করবে। (আবার: ড্যানিয়েল, আপনি কোনও উপায়ে বা অন্যটি নিশ্চিত করতে পেরেছিলেন?)

— ডেভিড স্পিলিট

Answer 1

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

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

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

ভেরিয়েবল দৈর্ঘ্যের সারিগুলির জন্য আপডেটগুলিও একই প্রভাব ফেলতে পারে: একটি সারি ছোট হওয়ার সাথে সাথে এটি তার পৃষ্ঠায় স্থান ছেড়ে দিতে পারে যা পরে পুনরায় ব্যবহার করা সহজ নয় এবং প্রায় পুরো পৃষ্ঠায় একটি সারি যদি দীর্ঘতর হয় তবে এটি পৃষ্ঠার বিভাজনকে বাধ্য করতে পারে ।

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

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

পৃষ্ঠা বিভক্ত উদাহরণ

নির্দিষ্ট দৈর্ঘ্যের সারিগুলির সাথে সূচী ক্রমের মধ্যে সন্নিবেশ করা হচ্ছে যার মধ্যে একটি পৃষ্ঠায় চারটি ফিট করে:

Start with one empty page: 
        [__|__|__|__]
Add the first item in index order:
        [00|__|__|__]
Add the next three
        [00|02|04|06]
Adding the next will result in a new page:
        [00|02|04|06] [08|__|__|__]
And so on...
        [00|02|04|06] [08|10|12|14] [16|18|__|__]

এখন সূচী ক্রমের বাইরে সারি যুক্ত করার জন্য (এই কারণেই আমি কেবল উপরের সংখ্যাগুলিও ব্যবহার করেছি): যোগ করার 11অর্থ হ'ল হয় দ্বিতীয় পৃষ্ঠাকে প্রসারিত করা (তারা স্থির আকারের হিসাবে সম্ভব নয়), একের উপরে সমস্ত কিছু সরিয়ে নিয়ে যাওয়া (এতে খুব ব্যয়বহুল) একটি বৃহত সূচক) বা পৃষ্ঠাটিকে এভাবে ভাগ করা:

[00|02|04|06] [08|10|11|__] [12|14|__|__] [16|18|__|__]

এখান থেকে যুক্ত করা 13এবং 17প্রাসঙ্গিক পৃষ্ঠাগুলিতে বর্তমানে জায়গা থাকায় বিভাজনের ফল পাবেন না:

[00|02|04|06] [08|10|11|__] [12|13|14|__] [16|17|18|__]

তবে 03 যোগ করে:

[00|02|03|__] [04|06|__|__] [08|10|11|__] [12|13|14|__] [16|17|18|__]

আপনি দেখতে পাচ্ছেন, inোকানো অপারেশনগুলির পরে আমাদের কাছে বর্তমানে 5 টি পৃষ্ঠাগুলি বরাদ্দ রয়েছে যা মোট 20 টি সারি মাপসই করতে পারে তবে আমাদের কেবল সেখানে 14 টি সারি রয়েছে ("30% জায়গার অপচয়")।

ডিফল্ট বিকল্পগুলির সাথে একটি পুনর্নির্মাণ (নীচে "" ফ্যাক্টর ফ্যাক্টর "দেখুন) এর ফলস্বরূপ:

[00|02|03|04] [06|08|10|11] [12|13|14|16] [17|18|__|__]

এই সাধারণ উদাহরণে একটি পৃষ্ঠা সংরক্ষণ করা। মুছে ফেলা কীভাবে ইনডেক্স-ইনডেক্স-অর্ডার সন্নিবেশগুলির মতো একই প্রভাব ফেলতে পারে তা দেখতে সহজ।

প্রশমন

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

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

আমি ধরে নিচ্ছি অন্যান্য বড় নাম ডিবিগুলিরও একই বিকল্প রয়েছে, যদি আপনার এগুলিরও এই স্তরের নিয়ন্ত্রণের প্রয়োজন হয়।

হালনাগাদ

ALTER INDEXআমি উপরোক্ত টাইপ করা শুরু করার পরে প্রশ্নের সাথে যুক্ত হওয়া বিবৃতি সম্পর্কে : আমি ধরে নিয়েছি যে বিকল্পগুলি একই রকম হয় যখন সূচকটি প্রথম নির্মিত হয়েছিল (বা শেষ পুনর্নির্মাণ) তবে তা না হলে সংক্ষেপণ বিকল্পটি এটি যুক্ত করা হলে খুব তাৎপর্যপূর্ণ হতে পারে প্রায় সময় এছাড়াও সেই বিবৃতিতে ফিলফ্যাক্টরটি 85% তে সেট করা হয়েছে 100% নয় তাই প্রতিটি পাতার পৃষ্ঠা পুনর্নির্মাণের অবিলম্বে 15 ডলার খালি হবে।

Comments

+1 পৃষ্ঠা পূরণের উপাদানটি যদি 100% এরও কম হয়, উদাহরণস্বরূপ পৃষ্ঠাটি পূরণের ফ্যাক্টর 50% ছিল তবে সদ্য পুনর্নির্মাণ ক্লাস্টার ইনডেক্স ( টেবিল ) দ্বিগুণ হবে যতটা 100% ফিল ফ্যাক্টর দিয়ে পুনর্নির্মাণ করা হয়েছিল।

— ম্যাক্স ভার্নন

Answer 2

আপনি যখন একটি সূচি পুনর্নির্মাণ করেন, এটি আক্ষরিক অর্থে সমস্ত ডেটা নতুন পৃষ্ঠাগুলিতে রাখে। আমার যে সন্দেহ হয়েছিল তা হ'ল আপনি পুনর্নির্মাণের পূর্বে প্রচুর ডেটা মুছে ফেলেছেন, যেমন একটি কলাম সরিয়েছেন, পরিবর্তনশীল-প্রস্থের কলামকে কম ডেটা রাখতে আপডেট করেছেন, একটি নির্দিষ্ট-প্রস্থের কলামের আকার পরিবর্তন করেছেন, বা প্রচুর সারি মুছে দিয়েছেন। এই অপারেশনগুলির কোনও একটিই পৃষ্ঠাগুলিতে প্রচুর খালি জায়গা ছেড়ে দিতে পারে, এটি পুনর্নির্মাণ না হওয়া পর্যন্ত পুনরায় দাবি করতে পারে না। "ডেটা" কলামটিতে sp_spaceusedপ্রকৃত ডেটা পরিমাপ করছে না, তবে ডেটা সংরক্ষণের জন্য ব্যবহৃত 8 কে পৃষ্ঠার সংখ্যা। পুনর্নির্মাণের কারণে সেই পৃষ্ঠাগুলি এখন আরও পূর্ণ, সুতরাং একই পরিমাণের ডেটা অল্প সংখ্যক পৃষ্ঠায় ফিট করে on

Answer 3

sp_spaceusedসঞ্চিত পদ্ধতি ডাটাবেসের মধ্যে সারি মোট culmulative আকার পরীক্ষা করা হয় না। এটি ডেটার জন্য বরাদ্দকৃত এক্সেন্টেন্টগুলির সংশ্লেষিত আকারে সেই ডেটা ধরে রাখতে স্থান বরাদ্দের আকারের প্রতিবেদন করছে।

যদি অনেকগুলি মুছে ফেলা সারিগুলির মতো উল্লেখযোগ্য ফ্রাইস্পেস উপলভ্য থাকে তবে ক্লাস্টারড ইনডেক্সের একটি পুনর্নির্মাণ পৃষ্ঠাগুলিতে স্থানটি কমপ্যাক্ট করবে এবং পারফরম্যান্সের কারণে আরও দক্ষ (অর্থাত্ ছোট) হতে পারে।

সুতরাং, কোনও ডেটা ফেলে দেওয়া উচিত ছিল না , তবে পুনর্নির্মাণ প্রক্রিয়া সেই ফ্রি স্পেস তৈরি করেছিল যা আবার উপলব্ধ ডেটা পৃষ্ঠাগুলিতে এমবেড করা ছিল।