উত্পাদন সারণিতে কলাম যুক্ত করা হচ্ছে

Question

এসকিউএল সার্ভার ২০০৮ আর 2-তে বড় উত্পাদনের টেবিলে কলাম যুক্ত করার সর্বোত্তম উপায় কী? অনলাইনে মাইক্রোসফ্ট এর বই অনুসারে:

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

(Http://msdn.microsoft.com/en-us/library/ms190273.aspx)

কয়েক মিলিয়ন সারি সহ একটি বৃহত টেবিলে, এটি কিছুটা সময় নিতে পারে। আউটেজ নেওয়া কি একমাত্র বিকল্প? এই ধরণের পরিস্থিতি পরিচালনা করার সবচেয়ে ভাল উপায় কী?

Comments

এই সমস্যা সম্পর্কিত সাম্প্রতিক নিবন্ধ: sqlservercentral.com/articles/Change+ ট্র্যাকিং

— কেবি

Answer 1

"এটা নির্ভর করে"

আপনি যদি একটি কলাম যুক্ত করেন যা সারিগুলিতে ডেটা যুক্ত করার প্রয়োজন হয় না, তবে এটি বেশ দ্রুত হতে পারে।

উদাহরণস্বরূপ, কোনও int বা চর যোগ করার জন্য শারীরিক সারি চলাচল প্রয়োজন। কোনও ডিফল্ট না দিয়ে একটি naclable varchar যুক্ত করা উচিত নয় (যদি না NULL বিটম্যাপটি প্রসারিত করার প্রয়োজন হয়)

অনুমান করার জন্য আপনাকে এটির পুনরুদ্ধার করা অনুলিপিটিতে চেষ্টা করা দরকার

একটি নতুন টেবিল তৈরি করা, অনুলিপি করা, পুনর্নামকরণ করা যদি আপনাকে বিলিয়ন সারি টেবিলের ইনডেক্স এবং কীগুলি পুনরায় যুক্ত করতে হয় তবে বেশি সময় লাগতে পারে।

আমি বিলিয়ন সারি সারণী পরিবর্তন করেছি যেগুলি একটি নালামযোগ্য কলাম যুক্ত করতে কয়েক সেকেন্ড সময় নিয়েছিল।

আমি কি প্রথমে ব্যাকআপ নেওয়ার কথা বলেছি?

Comments

ব্যাকআপে +1 করুন। এবং আপনার পর্যাপ্ত লগ স্পেস রয়েছে তা নিশ্চিত করুন।

— SqlACID

আপনি কি স্পষ্ট করে বলতে পারেন যে কোনও ইন্ট বা চর যোগ করার জন্য শারীরিক সারি চলাচলের প্রয়োজন কেন?

— sh-beta

আপনার দ্বিতীয় লাইনের সারিগুলিতে ডেটা যুক্ত করার দরকার নেই "?"

— বেন ব্রোকা

Answer 2

কলামটি যদি নলযোগ্য হয় তবে এর প্রভাব নগণ্য হওয়া উচিত। যদি কলামটি NULL না হয়ে থাকতে পারে এবং মানটি সেট করতে হবে তবে তা বেশ আলাদা হতে পারে। আমি এই ক্ষেত্রে যা করব তা হ'ল এক শটে একটি নাল এবং ডিফল্ট সীমাবদ্ধতার পরিবর্তে কার্যকরভাবে প্রতিটি সারিতে ডেটা যুক্ত করুন:

• কলামটি নুয়েল হিসাবে যুক্ত করুন - বেশিরভাগ ক্ষেত্রে দ্রুত হওয়া উচিত
• মানগুলি ডিফল্টতে আপডেট করুন
  • আপনি প্রয়োজনে ব্যাচগুলিতে এটি করতে পারেন
  • আপনি শর্তযুক্ত যুক্তি প্রয়োগ করতে এটি ব্যবহার করতে পারেন যেখানে কিছু সারি ডিফল্ট নাও পেতে পারে
• নাল / ডিফল্ট সীমাবদ্ধতাগুলি যুক্ত করুন
  • এটি দ্রুত হবে যখন ডেটাগুলির কোনওটিই নাল নয়, তবে এখনও পরিমাপযোগ্য

@Gbn এর সাথে সম্মত হন যে আপনি উত্পাদনটির একটি অনুলিপি পুনরুদ্ধার করে এবং এটি চেষ্টা করে এটি পরীক্ষা করতে পারবেন ... আপনি সময় নির্ধারণের একটি ভাল ধারণা পাবেন (হার্ডওয়্যারটি কিছুটা অনুরূপ বলে ধরে নিচ্ছেন) এবং আপনি লেনদেনের লগের প্রভাবও দেখতে পাবেন।

Comments

শেষ বিটটি আবার: •add the not null/default constraintsআমি নিশ্চিত নই যে এটির সাথে কোনও সম্ভাব্য সমস্যা নেই ... যখন এমএসএসকিউএল (এমনকি ২০০৮আর ২) নাল নয় একটি কলামটি বাতিল করে দেয়, আপনি যদি কোনও ট্রেস রাখেন তবে আপনি এটি আসলে কভারগুলির নীচে দেখতে পাবেন টেবিলের প্রতিটি সারিটির সম্পূর্ণ আপডেট করা, অর্থাত update table1 set column1 = column1আমি ধরে নিচ্ছি এটি সম্পূর্ণ বোকামি উপায়ে নন-নাল যাচাইকরণ করছে। এই লেনদেনটি টেবিলের আকারের দ্বিগুণ (পৃষ্ঠাগুলির আগে এবং পরে) তাই কোনও ডিডাব্লু টেবিলের জন্য বিশাল হতে পারে। পূর্বে আমাদের ডেটা

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

আরে @ মাইক, এটি নিজের মতো করে একটি ভাল সম্ভাব্য প্রশ্ন বলে মনে হচ্ছে।

— ডেরেক ডউনি

Answer 3

আপনি কি বিবেচনা করেছেন:

1. একটি নতুন টেবিল তৈরি করা হচ্ছে যাতে সারণির সংজ্ঞায় পরিবর্তনগুলি অন্তর্ভুক্ত রয়েছে।
2. মূল টেবিল থেকে নির্বাচন করে নতুন টেবিল সংজ্ঞা সন্নিবেশ করা হচ্ছে।
3. মূল টেবিলটির নাম _orig এ রাখুন এবং তারপরে নতুন টেবিলটির নামটি মূল টেবিলের নামকরণ করুন।

এখানে অসুবিধা হ'ল এই পরিবর্তনটি করার জন্য আপনার ডাটাবেসে পর্যাপ্ত স্থান থাকতে হবে। কোনও নোংরা পাঠ্য রোধ করতে আপনার এখনও টেবিলে একটি পড়ার তালার প্রয়োজন হতে পারে।

যাইহোক, যদি মূল টেবিলের একই সাথে অ্যাক্সেস করার কোনও সুযোগ বা প্রয়োজন থাকে তবে আপনি শেষ ব্যবহারকারীদের উপর প্রভাব হ্রাস করুন। এটি লক স্থিতি কমাতে হবে।

Comments

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

— সমস্ত ট্রেডের জোন

পরিবর্তনগুলি একটু সহজভাবে নিয়ন্ত্রণ করা যায় সেখানে আমার ডেটা গুদামের টুপি নিয়ে আমার চিন্তাভাবনা ছিল। কোনও ওলটিপি পরিস্থিতিতে আপনি সঠিক, টেবিলে পরিবর্তনগুলি এড়াতে একটি লেখার লক প্রয়োজন।

— রবপ্যালার