आप जो परिवर्तन कर रहे हैं उसके आधार पर, कभी-कभी रखरखाव विंडो लेना आसान हो सकता है। उस विंडो के दौरान (जहां कोई भी तालिका में डेटा को बदलने में सक्षम नहीं होना चाहिए) आप यह कर सकते हैं:
- पुराने कॉलम को इंगित करने वाले किसी भी इंडेक्स/बाधाओं को छोड़ दें, और ट्रिगर अक्षम करें
- एक नया अशक्तजोड़ें नए डेटा प्रकार के साथ कॉलम (भले ही यह NULL न हो)
- नए कॉलम को पुराने कॉलम के मान के बराबर सेट करते हुए अपडेट करें (और आप इसे अलग-अलग लेन-देन के हिस्से में कर सकते हैं (जैसे,
UPDATE TOP (10000) ... SET newcol = oldcol WHERE newcol IS NULL) और अपने लॉग को ओवररन करने से बचने के लिए CHECKPOINT के साथ) - एक बार सभी अपडेट हो जाने के बाद, पुराने कॉलम को छोड़ दें
- नए कॉलम का नाम बदलें (और यदि उपयुक्त हो तो NOT NULL बाधा जोड़ें)
- अनुक्रमणिका का पुनर्निर्माण करें और आंकड़े अपडेट करें
यहां कुंजी यह है कि यह आपको चरण 3 में क्रमिक रूप से अद्यतन करने की अनुमति देता है, जो कि आप एक ALTER TABLE कमांड में नहीं कर सकते।
यह मानता है कि कॉलम डेटा अखंडता में एक प्रमुख भूमिका नहीं निभा रहा है - यदि यह विदेशी कुंजी संबंधों के समूह में शामिल है, तो और भी कदम हैं।
संपादित करें
इसके अलावा, और बस जोर से सोच रहा था, मैंने इसके लिए कोई परीक्षण नहीं किया है (लेकिन इसे सूची में जोड़ रहा हूं)। मुझे आश्चर्य है कि क्या पृष्ठ + पंक्ति संपीड़न यहाँ मदद करेगा? यदि आप एक INT को BIGINT में बदलते हैं, तो संपीड़न के साथ SQL सर्वर को अभी भी सभी मानों का इलाज करना चाहिए जैसे कि वे अभी भी एक INT में फिट हैं। दोबारा, मैंने परीक्षण नहीं किया है कि क्या यह तेजी से या धीमी गति से बदलाव करेगा, या पहले स्थान पर संपीड़न जोड़ने में कितना समय लगेगा। बस इसे वहीं फेंक दो।
