रोलबैक एक तेजी से ऑपरेशन है?

Question

क्या यह सच है कि RDBMS सिस्टम COMMITसंचालन के लिए अनुकूलित हैं ? ROLLBACKऑपरेशन कितने धीमे / तेज़ हैं और क्यों?

Answer 1

SQL सर्वर के लिए, आप तर्क दे सकते हैं कि लॉग फ़ाइल में LOP_COMMIT_XACT लिखने और लॉक जारी करने के अलावा एक प्रतिबद्ध ऑपरेशन कुछ भी नहीं है, जो निश्चित रूप से आपके द्वारा BEGIN TRAN द्वारा किए गए प्रत्येक लेनदेन के ROLLBACK से तेज़ होने वाला है।

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

एक रोलबैक परिवर्तनों की एक अनुक्रमिक फ़ाइल पढ़ रहा है और उन्हें इन-मेमोरी डेटा पृष्ठों पर लागू कर रहा है। मूल "काम" को एक निष्पादन योजना उत्पन्न करनी थी, पृष्ठों को प्राप्त करना, पंक्तियों को जोड़ना आदि।

संपादित करें: यह बिट पर निर्भर करता है ...

@JackDouglas ने इस लेख की ओर इशारा किया जो उन स्थितियों में से एक का वर्णन करता है जहां रोलबैक मूल ऑपरेशन की तुलना में अधिक समय ले सकता है। एक 14 घंटे के लेन-देन का उदाहरण है, अनिवार्य रूप से समानता का उपयोग करते हुए, रोलबैक में 48+ घंटे लगते हैं क्योंकि रोलबैक ज्यादातर एकल थ्रेडेड है। आप बहुधा बार-बार बफ़र पूल का मंथन कर रहे होंगे, इसलिए अब आप इन-मेमोरी पन्नों में बदलावों को उलट नहीं रहे हैं।

तो, मेरे पहले उत्तर का एक संशोधित संस्करण। रोलबैक कितना धीमा है? अन्य सभी चीजों पर विचार किया जाता है, एक विशिष्ट ओएलटीपी लेनदेन के लिए यह नहीं है। ठेठ की सीमाओं के बाहर, "डू" की तुलना में "पूर्ववत" करने में अधिक समय लग सकता है लेकिन (क्या यह एक संभावित जीभ ट्विस्टर है?) इस बात पर निर्भर करेगा कि "कैसे" किया गया था।

Edit2: टिप्पणियों में चर्चा के बाद, यहां यह प्रदर्शित करने के लिए एक बहुत ही विवादित उदाहरण है कि किए जा रहे कार्य संचालन के रूप में प्रतिबद्ध बनाम रोलबैक के सापेक्ष व्यय का निर्धारण करने में प्रमुख कारक है।

दो तालिकाएँ बनाएँ और उन्हें अक्षम रूप से पैक करें (प्रति पृष्ठ व्यर्थ स्थान):

SET STATISTICS IO OFF;
SET STATISTICS TIME OFF;
SET NOCOUNT ON;
GO

CREATE TABLE dbo.Foo
(
    col1 INT IDENTITY(1,1) PRIMARY KEY CLUSTERED
    , col2 CHAR(4000) NOT NULL DEFAULT REPLICATE('A', 4000)
)

CREATE TABLE dbo.Bar
(
    col1 INT IDENTITY(1,1) PRIMARY KEY CLUSTERED
    , col2 CHAR(4000) NOT NULL DEFAULT REPLICATE('A', 4000)
)
GO

INSERT dbo.Foo DEFAULT VALUES
GO 100000

INSERT dbo.Bar DEFAULT VALUES
GO 100000

"खराब" अपडेट क्वेरी चलाएँ, काम करने में लगने वाले समय और कमिट को जारी करने में लगने वाला समय।

DECLARE 
    @StartTime DATETIME2
    , @Rows INT

SET @Rows = 1

CHECKPOINT
DBCC DROPCLEANBUFFERS

BEGIN TRANSACTION

SET @StartTime = SYSDATETIME()

UPDATE
    dbo.bar
SET
    col2 = REPLICATE('B', 4000)
FROM
    dbo.bar b
INNER JOIN
    (
    SELECT TOP(@Rows)
        col1
    FROM
        dbo.foo
    ORDER BY
        NEWID()
    ) f
ON  f.col1 = b.col1
OPTION (MAXDOP 1)

SELECT 'Find and update row', DATEDIFF(ms, @StartTime, SYSDATETIME())

SET @StartTime = SYSDATETIME()

COMMIT TRANSACTION

SELECT 'Commit', DATEDIFF(ms, @StartTime, SYSDATETIME())
GO

फिर से वही करें लेकिन रोलबैक जारी करें और मापें।

    DECLARE 
    @StartTime DATETIME2
    , @Rows INT

SET @Rows = 1

CHECKPOINT
DBCC DROPCLEANBUFFERS

BEGIN TRANSACTION

SET @StartTime = SYSDATETIME()

UPDATE
    dbo.bar
SET
    col2 = REPLICATE('B', 4000)
FROM
    dbo.bar b
INNER JOIN
    (
    SELECT TOP(@Rows)
        col1
    FROM
        dbo.foo
    ORDER BY
        NEWID()
    ) f
ON  f.col1 = b.col1
OPTION (MAXDOP 1)

SELECT 'Find and update row', DATEDIFF(ms, @StartTime, SYSDATETIME())

SET @StartTime = SYSDATETIME()

ROLLBACK TRANSACTION

SELECT 'Rollback', DATEDIFF(ms, @StartTime, SYSDATETIME())
GO

@ पंक्तियों = 1 के साथ मुझे यथोचित संगत मिलती है:

• खोजने / अद्यतन के लिए 5500ms
• 3ms प्रतिबद्ध है
• 1ms रोलबैक

@ पंक्तियों के साथ = 100:

• 8500ms / अपडेट ढूंढें
• 15ms प्रतिबद्ध
• 15ms रोलबैक

@ पंक्तियों के साथ = 1000:

• 15000ms / अद्यतन खोजें
• 10ms प्रतिबद्ध
• 500ms रोलबैक

मूल प्रश्न पर वापस जाएं। यदि आप कार्य करने के लिए लगने वाले समय को माप रहे हैं और कमिट कर रहे हैं, तो रोलबैक हाथों से जीत रहा है क्योंकि उस काम का अधिकांश हिस्सा अपडेट करने के लिए पंक्ति खोजने में खर्च होता है, वास्तव में डेटा को संशोधित करने में नहीं। यदि आप अलगाव में प्रतिबद्ध ऑपरेशन को देख रहे हैं, तो यह स्पष्ट होना चाहिए कि प्रतिबद्ध बहुत कम "काम" करता है जैसे कि। कमिट "मैं कर रहा हूँ" है।

Comments

'कम काम' जरूरी 'तेज' नहीं है

— जैक डगलस

मुझे पता था कि begin tranसिर्फ लेनदेन का काउंटर बढ़ता है। अगर मैं तुम्हें समझ गया, rdbms सभी कार्य कर रहा है (पंक्तियों को जोड़ता है, COMMIT में निष्पादन योजनाएं बनाता है ...)?

— गरिक

नहीं, सभी काम प्रतिबद्ध होने से पहले किए जाते हैं। प्रतिबद्ध संचालन स्वयं तुलनात्मक रूप से बहुत कम करता है।

— मार्क स्टोरी-स्मिथ

@ मर्क मैंने 2 मीटर पंक्तियों को सम्मिलित करते हुए कुछ मोटे और तैयार परीक्षण किए हैं और या तो वापस आ रहा है या रोलिंग कर रहा है। कुल मिलाकर रोलबैक सहित कुल समय 10 से 30 के बीच, बनाम 6 और 14 के बीच समग्र समय सहित। YMMV बेशक लेकिन यह इंगित करता है कि बॉलपार्क रोलबैक लगभग लंबे या लंबे समय तक है जो कि मूल लेनदेन कम से कम मेरे वातावरण में है।

— जैक डगलस

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

— मार्क स्टोरी-स्मिथ

Answer 2

ओरेकल के लिए, रोलबैक में बदलाव करने में लगने वाले समय की तुलना में कई गुना अधिक समय लग सकता है। यह अक्सर मायने नहीं रखता क्योंकि

1. लेन-देन वापस होने पर कोई लॉक नहीं होता है
2. इसे कम प्राथमिकता वाली पृष्ठभूमि प्रक्रिया द्वारा नियंत्रित किया जाता है

SQL सर्वर के लिए मुझे यकीन नहीं है कि स्थिति समान है, लेकिन कोई और कहेगा कि यह नहीं है ...

"क्यों" के रूप में, मैं कहूंगा कि मुझे दुर्लभrollback होना चाहिए , आमतौर पर केवल अगर कुछ गलत हो गया है, और निश्चित रूप से बहुत अधिक सामान्य होने की संभावना है - तो यह समझ में आता हैcommitcommit

Answer 3

रोलबैक सिर्फ "ओह, माइंड माइंड" नहीं है - बहुत सारे मामलों में इसे वास्तव में पूर्ववत करना पड़ता है। इस बात का कोई नियम नहीं है कि रोलबैक ऑपरेशन हमेशा धीमा होगा या हमेशा मूल ऑपरेशन की तुलना में तेज होगा, हालांकि भले ही मूल लेनदेन समानांतर में चलता हो, रोलबैक सिंगल-थ्रेडेड है। यदि आप प्रतीक्षा कर रहे हैं तो मेरा सुझाव है कि यह केवल प्रतीक्षा करना सबसे सुरक्षित है।

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

Comments

और हम सभी ने कहा है कि "यह रोलबैक के लिए उम्र ले रहा है, चलो इसे रीबूट करें" कुछ बिंदु पर बातचीत सही है?

— मार्क स्टोरी-स्मिथ

मैंने कई ग्राहकों को ऐसा करते देखा है। कुछ अपेक्षाकृत असंतुष्ट हैं, अन्य बहुत कम भाग्यशाली हैं।

— हारून बर्ट्रेंड

@ MarkStorey-Smith - यदि आप मिड-रोलबैक को रीबूट करते हैं, तो क्या SQL सर्वर को स्टार्टअप पर अपने रोलबैक को जारी नहीं रखना है?

— निक चामास

@ यह निर्भर करता है - अगर रोलबैक को रिबूट से पहले ब्लॉक किया गया था, उदाहरण के लिए, यह सेवा के पुनरारंभ के बाद बहुत तेज व्यवहार कर सकता है क्योंकि यह अन्य प्रक्रिया सिर्फ मार दी गई थी। इस परिदृश्य में "क्या होगा" का एक बहुत कुछ है - जब भी आप किसी सर्वर को रिबूट करते हैं या किसी समस्या को "ठीक" करने के लिए सेवा को पुनरारंभ करते हैं, तो संभवतः खेलने में कुछ अधिक गंभीर समस्याएं हैं।

— हारून बर्ट्रेंड

@ अच्छा, हाँ ठीक ऐसा ही होता है। मेरी टिप्पणी "गाल में जीभ" होने का इरादा था, इतने में कि आप अनिवार्य रूप से यह समझाने के लिए समाप्त हो गए कि खुश लोक को ट्रिगर करना है जो कि रिबूट को हिट करना चाहते हैं जब भी कुछ उम्मीद के मुताबिक व्यवहार नहीं कर रहा हो।

— मार्क स्टोरी-स्मिथ

Answer 4

सभी लेन-देन में उनकी प्रतिबद्ध गतिविधि उनके रोलबैक की तुलना में बेहतर प्रदर्शन नहीं करेगी। ऐसा ही एक मामला SQL में डिलीट ऑपरेशन है। जब कोई लेन-देन पंक्तियों को हटाता है, तो इन पंक्तियों को भूत रिकॉर्ड के रूप में चिह्नित किया जाता है। एक बार जब कोई कमिट जारी किया जाता है और एक भूत रिकॉर्ड सफाई कार्य शुरू होता है, तो केवल ये रिकॉर्ड 'डिलीट' हो जाते हैं।

यदि इसके बजाय एक रोलबैक जारी किया गया था, तो यह इन अभिलेखों से भूत के चिह्नों को हटाता है, न कि गहन सम्मिलित विवरण।

Comments

रोलबैक के लिए कुछ निश्चित कार्यों को कैसे अनुकूलित किया जाता है, इसका अच्छा उदाहरण है।

— मार्क स्टोरी-स्मिथ

Answer 5

सभी नहीं हैं। PostgreSQL को वापस रोल करने में अधिक समय नहीं लगता है क्योंकि डिस्क I / O के संदर्भ में दो ऑपरेशन प्रभावी रूप से समान हैं। मैं वास्तव में यह नहीं सोचता कि यह कमिटमेंट के लिए अनुकूलित होने का सवाल है, क्योंकि यह एक सवाल है कि अन्य प्रश्न किसके लिए अनुकूलन कर रहे हैं।

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

PostgreSQL के लिए, सभी टेबल हीप टेबल हैं और इंडेक्स अलग हैं। इसका मतलब यह है कि जब वापस लौटते हैं या कमिट करते हैं, तो किसी भी डेटा को फिर से व्यवस्थित नहीं करना पड़ता है। इससे कमिटमेंट और रोलबैक दोनों तेजी से होता है।

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

हालाँकि यहाँ गति पोस्टग्रेएसक्यूएल में ऑप्टिमाइज़ेशन का सवाल नहीं है जो लिखने के काम के लिए है। यह दूसरों के ऊपर कुछ पढ़ने के संचालन को विशेषाधिकार देने की अनिच्छा है। नतीजतन PostgreSQL औसत के साथ-साथ अन्य डीबी के बारे में भी प्रदर्शन करता है। यह सिर्फ कुछ ऑपरेशन हैं जो तेज या धीमे हो सकते हैं।

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

Comments

अच्छा जवाब है, लेकिन एक मामूली वक्रोक्ति: "PostgreSQL के लिए, सभी टेबल हीप टेबल हैं और इंडेक्स अलग-अलग हैं। इसका मतलब है कि जब वापस रोल करना या कमिट करना है, तो किसी भी डेटा को दोबारा व्यवस्थित नहीं करना होगा" यह कारण नहीं है कि कोई डेटा नहीं है। फिर से व्यवस्थित किया जाए, बल्कि इसलिए क्योंकि "प्रमुख डीबी जो डेटा को स्थानांतरित करने के लिए प्रतिबद्ध होने की तुलना में अधिक धीरे-धीरे रोल करता है", और जैसा कि आपने उल्लेख किया है, पीजी नहीं करता है। ओरेकल स्टोरेज को भी डिफॉल्ट करता है: मुख्य अंतर यह है कि ओरेकल 'पूर्ववत' का उपयोग करता है और 'वैक्यूम' रूट पर जाने के बजाय कमिट / रोलबैक पर सभी जगह को पुनः प्राप्त करता है।

— जैक डगलस