आप जो परिवर्तन कर रहे हैं उसके आधार पर, कभी-कभी रखरखाव विंडो लेना आसान हो सकता है। उस खिड़की (जहां कोई भी तालिका में डेटा को बदलने में सक्षम होना चाहिए) के दौरान आप कर सकते हैं:
- बूंद किसी भी अनुक्रमित/बाधाओं वर्ष स्तंभ की ओर इशारा करते, और अक्षम चलाता
- एक नया नल स्तंभ जोड़ने नए डेटा प्रकार के साथ (भले ही यह शून्य न हो)
- पुराने कॉलम के मान के बराबर नई कॉलम सेटिंग अपडेट करें (और आप इसे व्यक्तिगत लेनदेन के टुकड़ों में कर सकते हैं (कहें, 10000 पंक्तियों को प्रभावित करना
UPDATE TOP (10000) ... SET newcol = oldcol WHERE newcol IS NULL का उपयोग करके समय) और अपने लॉग को ओवरराइज करने से बचने के लिए चेकपॉइंट के साथ)
- एक बार अपडेट सब किया जाता है, पुराने कॉलम
- नया स्तंभ का नाम बदलने के ड्रॉप (और एक नहीं शून्य बाधा अगर उचित जोड़ने)
- अनुक्रमित और अद्यतन आंकड़ों के पुनर्निर्माण
कुंजी यहाँ है कि यह आप की अनुमति देता है चरण 3 में वृद्धि को अद्यतन करने के लिए, जिसे आप एकल ALTER तालिका कमांड में नहीं कर सकते हैं।
यह मानता है कि कॉलम डेटा अखंडता में एक प्रमुख भूमिका निभा रहा है - यदि यह विदेशी कुंजी संबंधों के समूह में शामिल है, तो और भी कदम हैं।
संपादित
इसके अलावा, और बस ज़ोर से सोच रहा है, मैं इस के लिए किसी भी परीक्षण नहीं किया है (लेकिन सूची में जोड़कर)। मुझे आश्चर्य है कि पेज + पंक्ति संपीड़न यहां मदद करेगा? यदि आप एक आईआईएन को बिगिनट में बदलते हैं, तो जगह में संपीड़न के साथ SQL सर्वर को अभी भी सभी मानों का इलाज करना चाहिए जैसे कि वे अभी भी एक आईएनटी में फिट हैं। दोबारा, मैंने परीक्षण नहीं किया है अगर यह तेजी से या धीमा हो जाएगा, या पहली जगह संपीड़न जोड़ने में कितना समय लगेगा। बस इसे बाहर फेंका जा रहा है।
स्रोत
2012-05-25 12:49:56
क्या आप समझा सकते हैं कि आप डेटा प्रकार को किस प्रकार से बदल रहे हैं? –
मैं नहीं देख सकता कि कॉलम प्रकार बदलने के लिए आप कर्सर का उपयोग कैसे कर सकते हैं? एक कॉलम प्रकार किसी तालिका में _all_ मानों में परिवर्तन होता है। – Oded
ints bigints – user1417408