42 मिलियन पंक्तियों के साथ तालिका के लिए सहसंबंधित सबक्वायरी के साथ एसक्यूएल हटाएं?

Question

मेरे पास 42,795,120 पंक्तियों के साथ एक तालिका cats है।

स्पष्ट रूप से यह बहुत सारी पंक्तियां हैं। तो जब मैं कार्य करें:

/* owner_cats is a many-to-many join table */ 
DELETE FROM cats 
WHERE cats.id_cat IN (
SELECT owner_cats.id_cat FROM owner_cats 
WHERE owner_cats.id_owner = 1) 

क्वेरी का समय समाप्त :(

:

मैं (संपादन मैं अपनेCommandTimeoutमूल्य में वृद्धि करने की जरूरत है, डिफ़ॉल्ट केवल 30 सेकंड है) TRUNCATE TABLE cats का उपयोग नहीं कर सकता क्योंकि मैं अन्य मालिकों से बिल्लियों को उड़ाना नहीं चाहता हूं।

मैं एस का उपयोग कर रहा हूं "। सरल":

DELETE TOP (25) PERCENT FROM cats 
WHERE cats.id_cat IN (
SELECT owner_cats.id_cat FROM owner_cats 
WHERE owner_cats.id_owner = 1) 

DELETE TOP(50) PERCENT FROM cats 
WHERE cats.id_cat IN (
SELECT owner_cats.id_cat FROM owner_cats 
WHERE owner_cats.id_owner = 1) 

DELETE FROM cats 
WHERE cats.id_cat IN (
SELECT owner_cats.id_cat FROM owner_cats 
WHERE owner_cats.id_owner = 1) 

मेरा प्रश्न है: QL सर्वर 2005 "रिकवरी मॉडल" करने के लिए सेट के साथ

तो, मैं कुछ इस तरह (Btw एक आवेदन से इस एसक्यूएल को क्रियान्वित करने) करने के बारे में सोचा था कि क्या एसक्यूएल सर्वर 2005 में DELETE पंक्तियों की संख्या की दहलीज है?

या, यदि मेरा दृष्टिकोण इष्टतम नहीं है, तो कृपया एक बेहतर दृष्टिकोण का सुझाव दें। धन्यवाद।

इस पोस्ट में मुझे काफी मदद नहीं की:

• SQL Server Efficiently dropping a group of rows with millions and millions of rows

संपादित करें (2010/08/06):

ठीक है, मैं सिर्फ पढ़ने के बाद एहसास हुआ उपरोक्त लिंक फिर से कि मेरे पास इन तालिकाओं पर अनुक्रमणिका नहीं थी। इसके अलावा, आप में से कुछ ने पहले ही टिप्पणियों में उस मुद्दे को इंगित कर दिया है। ध्यान रखें कि यह एक कल्पित स्कीमा है, इसलिए id_cat एक पीके नहीं है, क्योंकि मेरे वास्तविक जीवन स्कीमा में, यह एक अद्वितीय क्षेत्र नहीं है।

मैं सूचक डाल देंगे:

1. cats.id_cat
2. owner_cats.id_cat
3. owner_cats.id_owner

मुझे लगता है कि मैं अभी भी इस डेटा भंडारण के हैंग हो रही है, और स्पष्ट रूप से मैं अनुक्रमित की जरूरत है सभी JOIN फ़ील्ड पर सही है?

हालांकि, मुझे बैच लोड प्रक्रिया करने में घंटों लगते हैं। मैं इसे पहले से ही SqlBulkCopy (भाग में, 42 मिलियन नहीं एक बार) के रूप में कर रहा हूं। मेरे पास कुछ इंडेक्स और पीके हैं।मैं निम्न पदों जो मेरे सिद्धांत है कि अनुक्रमित नीचे भी एक थोक प्रतिलिपि धीमा कर रहे हैं इस बात की पुष्टि पढ़ें:

• SqlBulkCopy slow as molasses
• What’s the fastest way to bulk insert a lot of data in SQL Server (C# client)

तो मैं नकल से पहले अपने अनुक्रमित DROP लिए जा रहा हूँ और फिर इसे पूरा होने पर CREATE फिर से करें।

लंबे समय तक लोड होने के कारण, मुझे इन सुझावों का परीक्षण करने में थोड़ी देर लग जाएगी। मैं परिणामों के साथ वापस रिपोर्ट करूंगा।

अद्यतन (2010/08/07):

टॉम सुझाव: बनाम 22 सेकंड:

DELETE 
FROM cats c 
WHERE EXISTS (SELECT 1 
FROM owner_cats o 
WHERE o.id_cat = c.id_cat 
AND o.id_owner = 1) 

और अभी भी कोई सूचकांक, 42 लाख पंक्तियों के लिए, यह 13:21 मिनट लग गए : 08 ऊपर वर्णित तरीके से। हालांकि, 13 मिलियन पंक्तियों के लिए, उसे 2:13 बनाम 2:10 मेरा पुराना तरीका मिला। यह एक साफ विचार है, लेकिन मुझे अभी भी इंडेक्स का उपयोग करने की आवश्यकता है!

अद्यतन (2010/08/08):

कुछ बहुत गलत है! अब इंडेक्स के साथ, ऊपर मेरी पहली हटाई गई क्वेरी 1: 9 बजे: मिनट (हाँ एक घंटा!) बनाम 22:08 मिनट: सेकंड और 13:21 मिनट: सेक बनाम 2:10 मिनट: सेक के लिए 42 मिलियन पंक्तियां और 13 मिलियन पंक्तियां क्रमशः। मैं इंडेक्स के साथ टॉम की क्वेरी को आजमाने की कोशिश कर रहा हूं, लेकिन यह गलत दिशा में जा रहा है। कृपया मदद करे।

अद्यतन (2010/08/09): 42 मील पंक्तियों और 10:50 मिनट के लिए मिनट: 13 मील पंक्तियों के लिए सूचकांक बनाम 13:21 मिनट सेकंड

टॉम हटाने 01:06 बजे ले लिया : सेक और 2:13 मिनट: सेकंड क्रमशः। जब मैं परिमाण के क्रम से इंडेक्स का उपयोग करता हूं तो मेरे डेटाबेस पर हटाए जा रहे हैं! मुझे लगता है कि मुझे पता है क्यों, मेरा डेटाबेस। एमडीएफ और .ldf पहले (42 मिलियन) के दौरान 3.5 जीबी से 40.6 जीबी तक बढ़ गया! मैं क्या गलत कर रहा हूँ?

अद्यतन (2010/08/10):

:

किसी भी अन्य विकल्पों की कमी के लिए, मैं क्या मुझे लगता है एक फीके समाधान (उम्मीद अस्थायी) है के साथ आए हैं

1. 1 घंटे के लिए डेटाबेस कनेक्शन के लिए बढ़ाएँ टाइमआउट
2. उपयोग टॉम की क्वेरी (CommandTimeout=60000; डिफ़ॉल्ट 30 सेकंड था): DELETE FROM WHERE EXISTS (SELECT 1 ...) क्योंकि यह प्रदर्शन एक छोटे से तेजी से
3. DROP सभी इंडेक्स और पीके हटाए जाने से पहले (???)
4. भागो DELETE बयान
5. CREATE सभी अनुक्रमित और पीकेएस

पागल लगता है, लेकिन कम से कम यह TRUNCATE का उपयोग करने और पहले owner_id साथ शुरू से ही मेरी लोड से शुरू की तुलना में तेजी है, क्योंकि में से एक मेरी owner_id 2:30 बजे लेता है: बनाम लोड करने के लिए न्यूनतम 17:22 मिनट: हटाए गए प्रक्रिया के लिए सेकंड मैंने अभी 42 मिल पंक्तियों के साथ वर्णित किया है। (नोट: यदि मेरी लोड प्रक्रिया अपवाद फेंकता है, तो मैं उस owner_id के लिए शुरू करता हूं, लेकिन मैं पिछले owner_id को उड़ाना नहीं चाहता, इसलिए मैं TRUNCATEowner_cats तालिका नहीं चाहता, इसलिए मैं कोशिश कर रहा हूं DELETE का उपयोग करें।)

एनीमोर मदद अभी भी सराहना की जाएगी :)

Answer 1

कोई व्यावहारिक सीमा नहीं है। यह इस बात पर निर्भर करता है कि आपके कमांड टाइमआउट आपके कनेक्शन पर क्या सेट है।

ध्यान रखें कि समय यह इन पंक्तियों के सभी नष्ट करने के लिए ले जाता है पर निर्भर है:

• समय यह ब्याज
• समय उस में लेन-देन के लिए लॉग इन पर ले जाता है की पंक्तियों को खोजने के लिए ले जाता है लेन-देन लॉग
• समय यह ब्याज
• समय यह ब्याज
• बार यह अन्य प्रक्रियाओं के लिए प्रतीक्षा करने लगते हैं की वास्तविक पंक्तियां हटाना लेता के सूचकांक प्रविष्टियों को हटाने के लिए ले जाता है तालिका का उपयोग बंद करने के लिए ताकि आप इस मामले में क्या हासिल कर सकें, एक विशेष टेबल लॉक

अंतिम बिंदु अक्सर सबसे महत्वपूर्ण हो सकता है। यह सुनिश्चित करने के लिए कि आपके आदेश को निष्पादित करने से रोकें, यह सुनिश्चित करने के लिए एक और क्वेरी विंडो में sp_who2 कमांड करें।

अनुचित रूप से कॉन्फ़िगर किए गए SQL सर्वर इस प्रकार की क्वेरी पर खराब प्रदर्शन करेंगे। लेनदेन लॉग जो बहुत छोटे होते हैं और/या एक ही डिस्क साझा करते हैं क्योंकि डेटा फ़ाइलों को बड़ी पंक्तियों के साथ काम करते समय अक्सर गंभीर प्रदर्शन दंड लगाना पड़ता है।

एक समाधान के लिए, अच्छी तरह से, सभी चीजों की तरह, यह निर्भर करता है। क्या यह ऐसा कुछ है जिसे आप अक्सर करना चाहते हैं? आपके द्वारा छोड़ी गई कई पंक्तियों के आधार पर, तालिका का पुनर्निर्माण करने का सबसे तेज़ तरीका एक और नाम के रूप में हो सकता है और फिर उसका नाम बदल सकता है और लेनदेन के अंदर सभी बाधाओं को फिर से बना सकता है। यदि यह केवल एक विज्ञापन-वस्तु है, तो सुनिश्चित करें कि आपका एडीओ कमांडटाइम काफी अधिक सेट है और आप केवल इस बड़े डिलीट की लागत ले सकते हैं।

Answer 2

इस तरह की कोई सीमा नहीं है - आप किसी भी तालिका से सभी पंक्तियों को हटा सकते हैं पर्याप्त लेनदेन लॉग स्पेस - जहां आपकी क्वेरी अधिकतर गिरने की संभावना है। आप अपने हटाएं से कुछ परिणाम (एन) बिल्लियों से प्रतिशत मिल रहे हैं जहां ... तो आप इसे नीचे के रूप में एक पाश में लपेट कर सकते हैं:

SELECT 1 
WHILE @@ROWCOUNT <> 0 
BEGIN 
DELETE TOP (somevalue) PERCENT FROM cats 
WHERE cats.id_cat IN (
SELECT owner_cats.id_cat FROM owner_cats 
WHERE owner_cats.id_owner = 1) 
END 

Answer 3

दूसरों के रूप में उल्लेख किया है, जब आप 42 लाख पंक्तियां हटाना , डीबी डेटाबेस के खिलाफ 42 मिलियन हटाने को लॉग इन करना है। इस प्रकार, लेनदेन लॉग में काफी वृद्धि हुई है। आप कोशिश कर सकते हैं कि हिस्सों में डिलीट को तोड़ना है। निम्नलिखित क्वेरी में, मैं 100 बाल्टी में पंक्तियों को तोड़ने के लिए एनटीआईएल रैंकिंग फ़ंक्शन का उपयोग करता हूं।यदि यह बहुत धीमा है, तो आप बाल्टी की संख्या का विस्तार कर सकते हैं ताकि प्रत्येक डिलीट छोटा हो। owner_cats.id_owner, owner_cats.id_cats और cats.id_cat पर एक इंडेक्स होने पर यह बहुत मददगार होगा (जिसे मैंने प्राथमिक कुंजी और संख्यात्मक माना है)।

Declare @Cats Cursor 
Declare @CatId int --assuming an integer PK here 
Declare @Start int 
Declare @End int 
Declare @GroupCount int 

Set @GroupCount = 100 

Set @Cats = Cursor Fast_Forward For 
    With CatHerd As 
     (
     Select cats.id_cat 
      , NTile(@GroupCount) Over (Order By cats.id_cat) As Grp 
     From cats 
      Join owner_cats 
       On owner_cats.id_cat = cats.id_cat 
     Where owner_cats.id_owner = 1 
     ) 
     Select Grp, Min(id_cat) As MinCat, Max(id_cat) As MaxCat 
     From CatHerd 
     Group By Grp 
Open @Cats 
Fetch Next From @Cats Into @CatId, @Start, @End 

While @@Fetch_Status = 0 
Begin 
    Delete cats 
    Where id_cat Between @Start And @End 

    Fetch Next From @Cats Into @CatId, @Start, @End 
End 

Close @Cats 
Deallocate @Cats 

उपरोक्त दृष्टिकोण के साथ उल्लेखनीय पकड़ यह है कि यह लेनदेन नहीं है। इस प्रकार, यदि यह 40 वें हिस्से में विफल रहता है, तो आप पंक्तियों का 40% हटा देंगे और अन्य 60% अभी भी मौजूद होंगे।

Answer 4

यदि डिलीट तालिका से पंक्तियों की "एक महत्वपूर्ण संख्या" को हटा देगा, तो यह एक डेलीटे का विकल्प हो सकता है: रिकॉर्ड्स को कहीं और रखने के लिए रखें, मूल तालिका को छोटा करें, 'रखवाले' को वापस रखें। कुछ की तरह:

SELECT * 
INTO #cats_to_keep 
FROM cats 
WHERE cats.id_cat NOT IN ( -- note the NOT 
SELECT owner_cats.id_cat FROM owner_cats 
WHERE owner_cats.id_owner = 1) 

TRUNCATE TABLE cats 

INSERT INTO cats 
SELECT * FROM #cats_to_keep 

Answer 5

यदि आप एक IN बजाय एक EXISTS उपयोग करते हैं, में कहीं बेहतर प्रदर्शन मिलना चाहिए। इसे आज़माएं:

DELETE 
    FROM cats c 
WHERE EXISTS (SELECT 1 
       FROM owner_cats o 
       WHERE o.id_cat = c.id_cat 
        AND o.id_owner = 1) 

Answer 6

क्या आपने कोई सबक्वायरी नहीं की है और इसके बजाय शामिल होने का उपयोग किया है?

DELETE cats 
FROM 
cats c 
INNER JOIN owner_cats oc 
on c.id_cat = oc.id_cat 
WHERE 
    id_owner =1 

और यदि आपने भी अलग-अलग संकेतों का प्रयास किया है तो संकेतों में शामिल हों।

"अपने DELETE कि तालिका में पंक्तियों की एक महान बहुमत को खत्म करने का इरादा है, तो एक बात लोगों को अक्सर करते हैं कि प्रति सिर्फ पंक्तियों है:

DELETE cats 
FROM 
cats c 
INNER HASH JOIN owner_cats oc 
on c.id_cat = oc.id_cat 
WHERE 
    id_owner =1 

Answer 7

Bill Karwin's answer एक और सवाल करने के लिए भी मेरी स्थिति पर लागू होता है आप एक डुप्लिकेट टेबल रखना चाहते हैं, और फिर मूल तालिका को और अधिक तेज़ करने के लिए DROP TABLE या TRUNCATE का उपयोग करें। "

"। ऑफ़लाइन और एक बड़ा% को हटाने, तो अर्थपूर्ण हो सकता है सिर्फ रखने के लिए डेटा, पुराने तालिका छोड़ देते हैं और नाम बदलने के साथ एक नई तालिका का निर्माण करने के लिए":

Matt in this answer इसे इस तरह कहते हैं

ammoQ in this answer (वही सवाल से) (दूसरे शब्दों में बयान) की सिफारिश: एक मेज ताला

• मुद्दा जब किसी भी विदेशी कुंजी स्तंभों पर पंक्तियों
• डाल अनुक्रमित की एक बड़ी राशि को हटाने

Answer 8

< संपादित करें > (9/28/2011)
मेरा उत्तर मूल रूप से थॉमस समाधान (6 अगस्त '10) जैसा ही करता है। जब मैंने अपना जवाब पोस्ट किया तो मैंने इसे याद किया क्योंकि वह एक वास्तविक कर्सर का उपयोग करता है, इसलिए मैंने शामिल रिकॉर्ड के # कारणों के कारण खुद को "बुरा" माना। हालांकि, जब मैंने अपना जवाब दोबारा पढ़ा तो मुझे एहसास हुआ कि जिस तरह से वह कर्सर का उपयोग करता है वह वास्तव में "अच्छा" है। बहुत चालाक। मैंने अभी उसका जवाब वोट दिया और शायद भविष्य में अपने दृष्टिकोण का उपयोग करेगा। यदि आप समझ में नहीं आते हैं, तो इसे फिर से देखें। यदि आप अभी भी इसे नहीं देख पा रहे हैं, तो इस उत्तर पर एक टिप्पणी पोस्ट करें और मैं वापस आऊंगा और विस्तार से व्याख्या करने की कोशिश करूंगा। मैंने अपना जवाब छोड़ने का फैसला किया क्योंकि किसी के पास एक डीबीए हो सकता है जो कि "अच्छा" होने के बावजूद उन्हें एक वास्तविक कर्सर का उपयोग करने से इंकार कर देता है।:-)
</संपादित >

मुझे लगता है कि इस सवाल का एक साल का है, लेकिन मैं हाल ही में एक ऐसी ही स्थिति थी। मैं एक बड़ी मेज में शामिल होने के साथ एक बड़ी मेज पर "थोक" अपडेट करने की कोशिश कर रहा था, यह भी काफी बड़ा था। समस्या यह थी कि इस कार्यक्रम में इतने सारे "रिकॉर्ड में शामिल हुए" के परिणामस्वरूप प्रक्रिया में बहुत लंबा लगा और विवाद की समस्याएं हो सकती थीं। चूंकि यह एक बार अपडेट था, मैं निम्नलिखित "हैक" के साथ आया था। मैंने एक WHILE लूप बनाया जो तालिका के माध्यम से अपडेट किया गया और एक समय में अपडेट करने के लिए 50,000 रिकॉर्ड चुने। यह इस तरह कुछ दिखता था:

DECLARE @RecId bigint 
DECLARE @NumRecs bigint 
SET @NumRecs = (SELECT MAX(Id) FROM [TableToUpdate]) 
SET @RecId = 1 
WHILE @RecId < @NumRecs 
BEGIN 
    UPDATE [TableToUpdate] 
    SET UpdatedOn = GETDATE(), 
     SomeColumn = t2.[ColumnInTable2] 
    FROM [TableToUpdate] t 
    INNER JOIN [Table2] t2 ON t2.Name = t.DBAName 
     AND ISNULL(t.PhoneNumber,'') = t2.PhoneNumber 
     AND ISNULL(t.FaxNumber, '') = t2.FaxNumber 
    LEFT JOIN [Address] d ON d.AddressId = t.DbaAddressId 
     AND ISNULL(d.Address1,'') = t2.DBAAddress1 
     AND ISNULL(d.[State],'') = t2.DBAState 
     AND ISNULL(d.PostalCode,'') = t2.DBAPostalCode 
    WHERE t.Id BETWEEN @RecId AND (@RecId + 49999) 
    SET @RecId = @RecId + 50000 
END 

कुछ भी नहीं फैंसी लेकिन यह काम पूरा हो गया। चूंकि यह एक समय में केवल 50,000 रिकॉर्ड प्रसंस्करण कर रहा था, इसलिए बनाए गए किसी भी ताले कम रहते थे। साथ ही, ऑप्टिमाइज़र को एहसास हुआ कि उसे पूरी तालिका नहीं करनी पड़ी, इसलिए निष्पादन योजना चुनने का बेहतर काम हुआ।

< संपादित > (9/28/2011)
सुझाव है कि यहां एक से अधिक बार उल्लेख किया गया है और "अच्छा" कॉपी करने के बारे में वेब के आसपास जगह भर में पोस्ट किया जाता है करने के लिए एक विशाल चेतावनी है एक अलग तालिका में रिकॉर्ड, एक ट्रंकेट (या ड्रॉप और रीक्रेट, या डीआरओपी और नाम बदलें) और फिर तालिका को दोबारा बदलना।

यदि आप पीके-एफके रिलेशनशिप (या अन्य कन्स्ट्रेंट) में पीके टेबल है तो आप यह नहीं कर सकते हैं। अनुमोदित, आप रिश्ते को कम कर सकते हैं, साफ कर सकते हैं, और रिश्ते को दोबारा स्थापित कर सकते हैं, लेकिन आपको एफके टेबल भी साफ करनी होगी। आप रिश्ते को फिर से स्थापित करने से पहले ऐसा कर सकते हैं, जिसका अर्थ है "डाउन-टाइम", या आप निर्माण पर कंसस्ट्रेंट को सुधारने और बाद में साफ करने का चयन नहीं कर सकते हैं। मुझे लगता है कि आप पीके टेबल को साफ करने से पहले एफके टेबल को भी साफ कर सकते हैं। निचली पंक्ति यह है कि आपको एफके टेबल, एक तरफ या दूसरे को स्पष्ट रूप से साफ़ करना होगा।

मेरा उत्तर एक संकर एसईटी-आधारित/अर्ध-कर्सर प्रक्रिया है। इस विधि का एक अन्य लाभ यह है कि यदि पीके-एफके रिश्ते कोस्केड डिलीट्स पर सेट किया गया है तो आपको ऊपर उल्लिखित सफाई करने की ज़रूरत नहीं है क्योंकि सर्वर आपके लिए इसका ख्याल रखेगा। यदि आपकी कंपनी/डीबीए कैस्केडिंग डिलीट को हतोत्साहित करती है, तो आप यह पूछ सकते हैं कि यह केवल तब सक्षम हो सकता है जब यह प्रक्रिया चल रही हो और फिर समाप्त होने पर अक्षम हो। साफ-सफाई वाले खाते के अनुमति स्तरों के आधार पर, कैस्केडिंग डिलीट को सक्षम/अक्षम करने के लिए ALTER कथन को SQL कथन की शुरुआत और अंत में निपटाया जा सकता है। </संपादित >

Answer 9

MERGE कोशिश कर रहा लायक जैसे हो सकता है

MERGE INTO cats 
    USING owner_cats 
     ON cats.id_cat = owner_cats.id_cat 
     AND owner_cats.id_owner = 1 
WHEN MATCHED THEN DELETE;