बड़ी डिलीट क्वेरी जम गई है

Question

हमने 1.8bn पंक्तियों के साथ डेटाबेस पर एक डिलीट क्वेरी को चलाया। यह हटाए जाने से 1.2bn पंक्तियाँ नष्ट हो जाएंगी।

हेंडसाइट में, हमने इस क्वेरी को एक समय में 100 मीटर तक तोड़ दिया होगा, लेकिन हम ऐसी स्थिति में हैं जहां यह 24 घंटे से चल रहा है और लॉग फ़ाइल 2Tb पर है जो लॉग फ़ाइल के लिए अनुमत अधिकतम आकार प्रतीत होता है।

डेटाबेस SIMPLE रिकवरी मोड में है।

क्या इस क्वेरी में कोई बचत है? या क्या हमें SQL सर्वर को पुनः आरंभ करने और क्या होता है देखने की आवश्यकता है? क्या डेटाबेस अनुपयोगी होगा? क्या ऐसा कुछ भी है जिसे हम यथासंभव साफ-सफाई से मार सकते हैं?

Comments

क्या आपने इसे SSMS से चलाया? बस इसे रद्द कर दो। इसे रद्द करने में थोड़ा समय लगेगा। जैसे कि लंबे समय से यह चल रहा है। आपको धैर्य रखने की जरूरत है।

— पापाराज़ो

@Gememe अरब-रिकॉर्ड डेटाबेस के साथ हमारे अनुभव से (हम उनमें से एक जोड़े को चला रहे हैं) पीड़ित मेज से शेष रिकॉर्ड को बचाने के लिए कभी-कभी तेज होता है, इसे काट दें, इसे हटा दें, सहेजे गए रिकॉर्ड को मूल नाम पर वापस लौटाएं और फिर किसी भी अनुक्रमणिका को पुनर्स्थापित करें ।

— एंटोन क्राउगलोव

एक बार जब आप इस स्पिड को साफ कर लेते हैं, तो मैं 100 मीटर से अधिक छोटे बैचों की सिफारिश करूंगा, मैं आमतौर पर 100k से 1 मी करता हूं। इसके अलावा, यदि संभव हो तो हटाने के लिए रिकॉर्ड का चयन करने के लिए अपनी प्राथमिक कुंजी के रूप में अपनी प्राथमिक कुंजी का उपयोग करें।

— ब्रैडेक

बड़ी मात्रा में डेटा हटाने और लॉग समस्याओं से बचने की कोशिश करते समय ट्रंकेट आपका मित्र है।

— जेफ। क्लार्क

Answer 1

सबसे पहले, SQL एररोलॉग को यह देखने के लिए जांचें कि क्या यह वास्तव में लॉग के लिए अधिकतम आकार मारा है। यदि ऐसा किया जाता है, तो क्वेरी को पूरा करने की कोई उम्मीद नहीं है, यह संभवतः पहले से ही रोलबैक स्थिति में है।

यहां तक ​​कि अगर यह है, तो मैं हमेशा स्पिड को मैन्युअल रूप से मारना पसंद करता हूं (उपयोग करें sp_who2या sp_WhoIsActiveस्पिड को खोजने के लिए, फिर एक kill 59या जो भी करें)। जब तक आप एक स्पष्ट KILL नहीं करते हैं, तब तक आप रोलबैक स्थिति की जांच नहीं कर सकते हैं ।

चूँकि यह डिलीट है, और अपडेट या इंसर्ट नहीं, तो आप बहुत भाग्यशाली हो सकते हैं और पाते हैं कि यह तुरंत वापस आ गया है। यदि नहीं, तो इस बिंदु पर पहुंचने के लिए इसे वापस करने में लंबा (या लंबा) लग सकता है।

रोलबैक स्थिति देखने के लिए, का उपयोग करें

kill 59 with statusonly

दुर्भाग्य से, मैंने पाया है कि यह अक्सर कुछ भी उपयोगी नहीं दिखाता है, बस "0% पूर्ण"। उस स्थिति में, आपको sp_who2IO और CPU का उपयोग करना होगा और देखना होगा कि क्या यह अभी भी कुछ कर रहा है।

रिबूट के संबंध में, यह एक गंभीर जोखिम है। यदि स्पिड सक्रिय रूप से वापस चल रहा है (सीपीयू और आईओ बदल रहे हैं), तो SQL को पुनरारंभ करना केवल डेटाबेस को पूरी तरह से ऑफ़लाइन ले जाएगा जब तक कि रोलबैक पूरी तरह से समाप्त नहीं हो जाता है (घंटे और घंटे)। लेकिन , अगर सीपीयू और आईओ नहीं चल रहे हैं , तो यह वास्तव में इसे तुरंत साफ कर सकता है। किसी भी तरह से, यह एक जोखिम है।

एक अंतिम विकल्प, अगर चीजें विशेष रूप से गंभीर हैं: यदि आपके पास डिलीट शुरू होने से ठीक पहले से बैकअप है (और डीबी के लिए अन्य अपडेट नहीं हैं) , तो पुनर्प्राप्त करने का सबसे तेज़ तरीका बस डीबी को छोड़ना हो सकता है, पुनरारंभ करें SQL, और बैकअप से पुनर्स्थापित करें।

यदि आप DB को ड्रॉप नहीं कर सकते (या यदि आपने पहले ही इंस्टेंस को फिर से शुरू कर दिया है और sql errorlog 24-घंटे की रिकवरी टाइम की भविष्यवाणी कर रहा है), तो SQL सेवाओं को बंद कर दें, डिस्क से MDF और LDF फ़ाइलों को हटा दें, SQL शुरू करें, ड्रॉप करें (भूत) डेटाबेस, और बैकअप से पुनर्स्थापित करें।

जाहिर है कि आप केवल यह प्रयास करेंगे कि यदि यह एक बैक-एंड प्रोसेसिंग डेटाबेस था, जो उपयोगकर्ताओं के साथ बातचीत नहीं करता था।

Comments

पुनर्स्थापना विकल्प के बारे में अच्छी सलाह। नरक के रूप में डरावना, लेकिन फिर भी अच्छी सलाह।

— मैक्स वर्नोन

हां, हमारे पास इस हालत में एक डीबीए का उदाहरण था, जिसने हमें दो बहुत खराब विकल्पों के बीच फैसला करने के लिए मजबूर किया: 18-24 घंटों के लिए नीचे रहें, या क्वेरी शुरू होने से पहले वापस रोल करके डेटा खो दें। व्यवसाय ने वापस रोल करने के लिए चुना।

— ब्रैडेक

हमारे पास 4 मार्च से पूर्ण बैकअप है जो कि रिबूट काम नहीं करता है तो हम अंतिम उपाय के रूप में पुनर्स्थापित करेंगे। सौभाग्य से यह एक स्थैतिक पर्याप्त DB है जिसे हम नीचे ट्रिम करना चाहते थे। प्रतिक्रिया के लिए धन्यवाद, बहुत उपयोगी

— ग्रीम

@ ग्रेमी - FYI करें - 1.2 बिलियन पंक्तियों को हटाने की कोशिश करने के बजाय, टेबल संरचना की एक प्रतिलिपि बनाएँ, उन पंक्तियों की प्रतिलिपि बनाएँ जिन्हें आप नई तालिका में रखना चाहते हैं, फिर पुरानी तालिका को छोड़ दें। यदि आप एक नया प्रश्न पूछते हैं कि यह कैसे करना है, तो मैं आपको एक बहुत ही सुस्त तरीका दिखा सकता हूं जो 1.2 बिलियन पंक्तियों को हटाने की तुलना में बहुत तेज़ है।

— मैक्स वर्नोन

मेरा उत्तर मानता है कि db SIMPLE रिकवरी मोड में है। यदि यह पूर्ण मोड में है, तो आपको विशाल ट्रांस लॉग बैकअप भी प्रबंधित करना होगा।

— ब्रैडेक

Answer 2

SQL सर्वर को पुनर्स्थापित न करें। यह केवल आपकी पीड़ा को लम्बा कर देगा क्योंकि रिकवरी होगी, जो आपके डिलीट सहित किसी भी लेनदेन को पूरा नहीं करेगा, उसे रोलबैक या फिर से करेगा।

हटाए जाने वाले सत्र को मारने से रोलबैक घटित होगा, जिसे पूरा होने में भी लंबा समय लगेगा।

आप ऑपरेशन की स्थिति देखने के लिए निम्नलिखित प्रश्न देखना चाहते हैं:

SELECT des.session_id 
    , des.host_name
    , des.login_name
    , der.command
    , der.estimated_completion_time
    , der.blocking_session_id
    , der.last_wait_type
    , der.percent_complete
    , der.start_time
    , der.status
    , der.wait_resource
    , der.wait_type
    , der.wait_time
FROM sys.dm_exec_sessions des
    INNER JOIN sys.dm_exec_requests der ON des.session_id = der.session_id
WHERE des.session_id <> @@SPID
    AND des.is_user_process = 1
ORDER BY des.session_id;

percent_completeस्तंभ, और इस तरह के रूप में उन है कि उस पर भरोसा करते हैं, estimated_completion_time, केवल निम्न कार्रवाई भर जाती है:

ALTER INDEX REORGANIZE
AUTO_SHRINK option with ALTER DATABASE
BACKUP DATABASE
DBCC CHECKDB
DBCC CHECKFILEGROUP
DBCC CHECKTABLE
DBCC INDEXDEFRAG
DBCC SHRINKDATABASE
DBCC SHRINKFILE
RECOVERY
RESTORE DATABASE
ROLLBACK
TDE ENCRYPTION

यदि आप पहले ही हटाए गए कथन को रद्द कर चुके हैं, और आप पहले से ही SQL सर्वर को पुनरारंभ कर चुके हैं और यह रिकवरी में है, तो आप केवल उस कॉलम को सार्थक देखेंगे।

अगर द blocking_session_id कॉलम में कोई संख्या है, तो यह इंगित करता है कि अन्य सत्र डिलीट ऑपरेशन को रोक रहा है। यदि वह सत्र हटाए गए ऑपरेशन को रोक रहा है, तो शुरू होने के बाद आप बिना किसी रोलबैक के ऑपरेशन को रद्द करने में सक्षम हो सकते हैं।

Comments

अच्छी क्वेरी, लेकिन ऐसा लगता है कि यदि लॉग को अवरुद्ध किया जा रहा था तो लॉग बहुत बड़ा हो जाएगा।

— ब्रैड

हाँ। मैं केवल आउटपुट को थोड़ा समझाने का प्रयास कर रहा हूं। भविष्य के पाठक भी इसे देख सकते हैं। वास्तव में, मुझे संदेह है कि अगर हम अगले समय में ओपी से सुनेंगे। वह काफी व्यस्त रहने की संभावना है।

— मैक्स वर्नोन