সরান সহজ, কিন্তু কার্যকর সম্পাদনের পরিকল্পনা

Question

আমি এই মুছা চালানোর সময়:

DELETE FROM ETLHeaders WHERE ETLHeaderID < 32465870

... এটি 39,157 টি সারি মুছে ফেলে। এটি সহজ হওয়া উচিত কারণ এটি ETLHeaderID এ মুছে ফেলা হচ্ছে যা ক্লাস্টারড সূচক এবং প্রাথমিক কী। তবে (সম্পাদন পরিকল্পনা অনুসারে) মনে হচ্ছে এটি 361,190 সারিটিকে আঘাত করছে এবং অন্যান্য সূচী ব্যবহার করছে। টেবিলে একটি এক্সএমএল ডেটা টাইপযুক্ত ক্ষেত্র রয়েছে (যদি এই ডিলেটটি প্রভাবিত করে)।

কোনও ধারণা কেন এবং কীভাবে আমি এই মুছে ফেলতে গতি বাড়িয়ে তুলতে পারি?

এখানে কার্যকরকরণ পরিকল্পনা: http://sharetext.org/qwDY সারণী স্কিমা এখানে: http://sharetext.org/Vl9j

ধন্যবাদ

Answer 1

পরিকল্পনার শীর্ষ স্তরগুলি বেস টেবিল (ক্লাস্টারড ইনডেক্স) থেকে সারিগুলি সরিয়ে, এবং চারটি অবিচ্ছিন্ন সূচক বজায় রাখার সাথে সম্পর্কিত। এর মধ্যে দুটি সূচক একই সাথে সারি-সারি বজায় রাখা হয় ক্লাস্টারড ইনডেক্স মোছা প্রক্রিয়া করা হয়। এগুলি নীচে সবুজতে হাইলাইট করা "+2 নন-ক্লাস্টার ইনডেক্স"।

অপর দুটি অবিচ্ছিন্ন সূচকের জন্য, অপ্টিমাইজার সিদ্ধান্ত নিয়েছে যে এই সূচির কীগুলি কোনও টেম্পডিবি ওয়ার্কটেবল (ইজার স্পুল) এ সংরক্ষণ করা ভাল, তারপরে ক্রমিক ক্রমের অ্যাক্সেস প্যাটার্ন প্রচারের জন্য সূচি কী দ্বারা বাছাই করে দু'বার স্পুলটি বাজানো ভাল।

অপারেশনের চূড়ান্ত ক্রমটি প্রাথমিক ও মাধ্যমিক xmlসূচকগুলি বজায় রাখার সাথে সম্পর্কিত যা আপনার ডিডিএল স্ক্রিপ্টে অন্তর্ভুক্ত ছিল না:

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

এই xmlসূচকগুলি বিশেষত সমস্যাযুক্ত বলে জানিয়েছে । অপ্টিমাইজারের পক্ষে সঠিকভাবে নির্ধারণ করা খুব কঠিন যে এই পরিস্থিতিতে কতগুলি সারি যোগ্য হবে। প্রকৃতপক্ষে, এটি xmlসূচকের জন্য বর্ধমানভাবে অনুমান করে , ফলে প্রায় 12 গিগাবাইট মেমরি এই প্রশ্নের জন্য মঞ্জুরিপ্রাপ্ত হয় (যদিও রানটাইমের সময় কেবল 28MB ব্যবহৃত হয়):

অতিরিক্ত মেমরি অনুদানের প্রভাব হ্রাস করার আশায় আপনি ছোট ব্যাচে মুছে ফেলার বিষয়টি বিবেচনা করতে পারেন।

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

Answer 2

আপনি সঠিক পথে রয়েছেন - এক্সএমএল সূচক সমস্যা। স্পষ্টতই, একটি প্রাথমিক পাশাপাশি একটি গৌণ এক্সএমএল সূচক রয়েছে।

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

দীর্ঘ সময়কালের জন্য সূচক হ'ল গৌণ এক্সএমএল সূচক [এক্সএমএল_আইএক্স_ইটিএল হিয়ার্স_প্রোট্টি]। আপনার "রিলেশনাল টেবিল" এ 39,157 টি সারি প্রাথমিক এক্সএমএল সূচক [এক্সএমএল_আইএক্স_ইটিএইচইডার্স] এর 361,190 টি সারি উল্লেখ করে। এবং সেই 361 কে সারিগুলি বাছাই করা দরকার যাতে গৌণ সূচকটি মোছার জন্য ব্যবহৃত হতে পারে। এবং এই সাজানোর ক্রিয়াকলাপটি ক্যোয়ারির দীর্ঘ সময়কালের কারণ ঘটায়। (পার্শ্ব নোট হিসাবে, উভয় এক্সএমএল সূচকের সূচকের পরিসংখ্যানগুলি একেবারে বন্ধ বলে মনে হচ্ছে: প্রাথমিক এক্সএমএল সূচকের ৩1১ কে সারিগুলির প্রকৃত ডেটা আকার 160 এমবি যেখানে আনুমানিক ডেটা আকার প্রায় 4 টিবি (হ্যাঁ, 4 টেরাবাইট !!)) ।

আমি এই ক্যোয়ারীটি গতি বাড়ানোর একমাত্র বিকল্প হ'ল মাধ্যমিক এক্সএমএল সূচককে বাদ দেওয়া eliminate ডেটা উপর নির্ভর করে এক্সএমএল ডেটা একটি সম্পর্কিত টেবিলের মধ্যে ছিটিয়ে দেওয়া আরও ভাল বিকল্প হতে পারে।