क्या प्रत्येक सूचकांक को व्यक्तिगत रूप से प्रत्येक सूचकांक के पुनर्निर्माण की तुलना में सरल वसूली मॉडल के साथ अधिक लेनदेन लॉग स्थान का उपयोग करता है?

18

SQL सर्वर 2012 पर "ALTER INDEX ALL REBUILD" कार्रवाई विफल रही क्योंकि लेन-देन लॉग अंतरिक्ष से बाहर चला गया। अनुक्रमितों को कभी भी पुनर्गठित या पुनर्निर्माण नहीं किया गया है, इसलिए उन सभी में से लगभग 80% पर विखंडन होता है।

DB सरल पुनर्प्राप्ति मॉडल का उपयोग करता है। मैंने माना कि कमांड के "ALL" फॉर्म द्वारा किए गए प्रत्येक इंडेक्स ऑपरेशन के बाद, ट्रांजैक्शन लॉग डेटा अगले इंडेक्स पुनर्निर्माण से पहले फ्लश हो जाएगा। क्या यह है कि यह वास्तव में कैसे काम करता है, या इंडेक्स रीबिल्ड्स को लॉग इन किया जाता है जैसे कि वे एकल लेनदेन का हिस्सा हैं?

दूसरे शब्दों में, क्या मैं व्यक्तिगत रूप से प्रत्येक पुनर्निर्माण करने के लिए स्क्रिप्ट लिखकर लेन-देन लॉग वृद्धि को कम कर सकता हूं? क्या विचार करने के लिए कोई अन्य कारक हैं?

sql-server index

— Google विफल
स्रोत

2

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

— RDFozz

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

— Google फेल

16

मैंने माना कि कमांड के "ALL" फॉर्म द्वारा किए गए प्रत्येक इंडेक्स ऑपरेशन के बाद, ट्रांजैक्शन लॉग डेटा अगले इंडेक्स पुनर्निर्माण से पहले फ्लश हो जाएगा। क्या यह है कि यह वास्तव में कैसे काम करता है, या इंडेक्स रीबिल्ड्स को लॉग इन किया जाता है जैसे कि वे एकल लेनदेन का हिस्सा हैं?

1) लॉग फ्लशिंग: SIMPLE रिकवरी मॉडल हर लेनदेन के बाद लॉग को साफ़ नहीं करता है, लेकिन चौकियों पर। ( अधिक जानकारी के लिए लिंक )

2a) REBUILD ALL: हाँ, REBUILD ALL एक ही लेन-देन का काम करता है। इस सूचकांक में अपने स्वयं के लेन-देन हैं, लेकिन अंत तक समग्र संचालन पूरी तरह से प्रतिबद्ध नहीं है। तो हाँ, आप व्यक्तिगत अनुक्रमित (और संभवतः CHECKPOINT आदेश जारी) का पुनर्निर्माण करके लॉग फ़ाइल विकास को सीमित कर सकते हैं।

2 बी) प्रमाण! यहाँ, एक डेमो स्क्रिप्ट है। (2016 देव में निर्मित) सबसे पहले, टेबल और इंडेक्स के साथ एक परीक्षण डीबी सेट करें:

USE master
GO

CREATE DATABASE Test_RebuildLog
GO

ALTER DATABASE Test_RebuildLog
SET RECOVERY SIMPLE
GO

USE Test_RebuildLog
GO

CREATE TABLE IndexTest
(ID int identity(1,1),
a char(1),
b char(1))

CREATE CLUSTERED INDEX CIX_IndexTest_ID ON IndexTest(ID)
CREATE INDEX IX_IndexTest_a ON IndexTest(a)
CREATE INDEX IX_IndexTest_b ON IndexTest(b)

INSERT IndexTest
(a,b)
VALUES ('a','b'),('z','y'),('s','r')

अब आप REBUILD ALL और व्यक्तिगत रूप से पुनर्निर्माण के बीच लॉग गतिविधि की तुलना कर सकते हैं

CHECKPOINT
GO
ALTER INDEX ALL ON IndexTest REBUILD

SELECT *
FROM sys.fn_dblog(NULL,NULL)
WHERE Operation = 'LOP_COMMIT_XACT'
OR Operation = 'LOP_BEGIN_XACT'
GO

CHECKPOINT
GO
ALTER INDEX CIX_IndexTest_ID ON IndexTest REBUILD
ALTER INDEX IX_IndexTest_a ON IndexTest REBUILD
ALTER INDEX IX_IndexTest_b ON IndexTest REBUILD

SELECT *
FROM sys.fn_dblog(NULL,NULL)
WHERE Operation = 'LOP_COMMIT_XACT'
OR Operation = 'LOP_BEGIN_XACT'
GO

ध्यान दें कि पहला खुला लेनदेन (मेरे लिए ट्रांजेक्शन आईडी 0000: 000002fa) REBUILD ALL के अंत तक प्रतिबद्ध नहीं है, लेकिन इंडेक्स-बाय-इंडेक्स रीबिल्ड्स के लिए, वे क्रमिक रूप से प्रतिबद्ध हैं।

— फॉरेस्ट
स्रोत

वाह, वास्तव में विस्तृत प्रतिक्रिया के लिए धन्यवाद! यह देखने का एक शानदार तरीका है कि हुड के नीचे क्या हो रहा है, इसलिए बोलने के लिए।

— Google Fail

अच्छी तरह से समझाया।

— रमाकांत दधीचि

4

जैसा कि यह खड़ा है, यह एकल लेनदेन है।

— पेड्रो लोप्स
स्रोत

6

DBA.SE में आपका स्वागत है! सामान्य तौर पर, सबसे अच्छे उत्तर सरल मुखर नहीं होते हैं, लेकिन दस्तावेज़ीकरण या लेखों की जानकारी, या (अक्सर बेहतर भी) व्यक्तिगत अनुभव द्वारा बताए गए उत्तर को सिद्ध करते हुए समर्थित होते हैं। क्या आप अपने उत्तर का विस्तार कर सकते हैं, इस प्रकार का समर्थन प्रदान करने के लिए?

— RDFozz

2

@RDFozz फेयर कमेंट, लेकिन क्या आपने पेड्रो की प्रोफाइल देखी ? स्रोत कोड तक पहुंच को संभवतः व्यक्तिगत अनुभव या प्रलेखन से अधिक आधिकारिक माना जा सकता है। :-)

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

3

@AaronBertrand - मैं स्वीकार करता हूं, मैंने नहीं किया। मैं निश्चित रूप से सोचता हूं कि SQL सर्वर टीम का हिस्सा होना वास्तव में योग्य होगा। फिर भी, यह जवाब में ध्यान देने योग्य है। +1, किसी भी मामले में।

— RDFozz

3

प्रश्न एक ऑफ़लाइन पुनर्निर्माण के लिए तुच्छ है । बेशक एक ही लेन-देन है। कहर की कल्पना कीजिए कि अगर ऑपरेशन प्रत्येक इंडेक्स को अपने लेन-देन में विभाजित करता है, तो यह होगा कि इसे कमिट करते समय ताले को छोड़ना होगा और फिर से उन्हें हासिल करना होगा। जबकि महत्वपूर्ण तालिका SCH-M लॉक जारी किया गया था, इंडेक्स को गिराया जा सकता है और नए इंडेक्स बनाए जा सकते हैं, बयान ऐसे मामलों को कैसे हैंडल करेगा? यह उल्लेख करने के लिए नहीं कि तालिका को गिरा दिया जा सकता है, और यहां तक कि दो लेनदेन के बीच फिर से बनाया जा सकता है! मामले को शामिल करते हुए जब तालिका गिरा दी जाती है और एक ही ऑब्जेक्ट आईडी के साथ एक अलग तालिका बनाई जाती है (हाँ, यह हो सकता है) ...

क्या होगा यदि आप प्रश्न को यह कहने के लिए बढ़ाते हैं कि क्या होता है यदि सूचकांक पुनर्निर्माण एक ऑनलाइन पुनर्निर्माण है? क्या यह एकल लेनदेन है या कई हैं? जवाब जटिल है, क्योंकि वास्तव में कई आंतरिक लेनदेन शामिल हैं । हालाँकि, मुख्य बिंदु यह है कि एक समग्र arching लेनदेन है जो पूरे ऑपरेशन (ALTER स्टेटमेंट) को फैलाता है और यह लॉग को जगह में डालता है (काट नहीं सकता), इस प्रकार ~ 1.6x डेटा के लिए अनुमति देने के लिए ऑपरेशन को तदनुसार नियोजित करने की आवश्यकता होती है पूर्ण पुनर्प्राप्ति मोड के लिए आकार, या BULK_LOGGED / SIMPLE मोड के लिए 0.2x डेटा आकार। अधिक जानकारी के लिए लिंक किया हुआ पेपर देखें।

आप यह तर्क दे सकते हैं कि ऑफ़लाइन निर्माण वही आंतरिक लेन-देन को नियोजित नहीं करता जो ऑनलाइन मोड करता है, और ऑपरेशन को विभाजित करता है? जिन मुद्दों के बारे में मैंने उल्लेख किया है कि तालिका को अलग-अलग इंडेक्स ऑपरेशंस (यानी टेबल 'स्कीमा स्टेबिलिटी') के बीच बदल दिया गया है, के लिए अभी भी यह आवश्यक होगा कि स्टेटमेंट की पूरी अवधि के लिए टेबल पर एक SCH-S मौजूद हो। चूंकि यह लेन-देन SCH-S को पुनर्प्राप्ति के दौरान भी आयोजित करता है, इसे लॉग इन करना होगा, और जैसे कि एक BEGIN XACT लॉग रिकॉर्ड होगा जो लॉग को पिन करेगा और बयान की पूरी अवधि के लिए ट्रंकेशन को रोक देगा। मुझे पता है कि यह विशेष मुद्दा SQL 2016-2017 समय सीमा (SQL Azure लॉग आकार के मुद्दों के कारण) में संबोधित किया जा रहा था, ~~लेकिन मुझे यकीन नहीं है कि प्रगति क्या थी~~ । ऐसा लगता है कि अभी पूर्वावलोकन में है:SQL Server 2017 CTP 2.0 के लिए सार्वजनिक पूर्वावलोकन में पुन: प्रयोज्य ऑनलाइन सूचकांक पुन: निर्माण किया जाता है ।

— रेमस रुसानु
स्रोत

0

हां, मुझे एक बहुत बड़ी तालिका के साथ यही समस्या थी। जब भी मैंने ALTER INDEX ALL जारी किया, लेनदेन लॉग बहुत बढ़ जाएगा, लेकिन यदि व्यक्तिगत रूप से ALTER INDEX जारी किया जाता है, तो लॉग स्पेस का उपयोग छोटा होगा।

— एलटी
स्रोत

0

रेमुस द्वारा पहले की गई अनुक्रिया कि ऑनलाइन अनुक्रमण के लिए 1.6x की आवश्यकता है FULL रिकवरी मोड के तहत अनुक्रमणिका आकार सही नहीं है। FULL के तहत एक इंडेक्स ऑनलाइन के पुनर्निर्माण के लिए आवश्यक लेन-देन लॉगिंग स्पेस का अनुपात बहुत अधिक हो सकता है और हमने इंडेक्स के आकार को कई बार देखा है, खासकर जब इंडेक्स को फिर से बनाया जा रहा है क्योंकि लेन-देन लॉगिंग संकुचित नहीं है। यह अकेले यह स्पष्ट करना चाहिए कि FULL के तहत एक ऑनलाइन पुनर्निर्माण के दौरान लेनदेन लॉगिंग कम से कम सूचकांक के आकार से कुछ गुना हो सकता है। क्लॉग रिकॉर्ड ओवरहेड में जोड़ें जो Microsoft द्वारा पूरी तरह से प्रलेखित नहीं है, लेकिन अक्सर प्रति पंक्ति 60 बाइट्स का अनुमान लगाया जाता है और पूर्ण पुनर्प्राप्ति के तहत एक ऑनलाइन इंडेक्स पुनर्निर्माण के दौरान लॉगिंग का आनुपातिक आकार सूचकांक के पुनर्निर्माण के आकार से कई गुना अधिक हो सकता है, खासकर यदि सूचकांक संकुचित है

— ग्रेग लाइनवुड
स्रोत

-1

Rdfozz सही है कि यह तय करने का सबसे अच्छा तरीका है कि क्या आपके सबसे बड़े सूचकांक को वर्तमान भंडारण के आधार पर फिर से बनाया जा सकता है। बस तब चलाएं dm_exec_requestsजब ऑपरेशन हो रहा हो (या SQL Profiler) यह देखने के लिए कि क्या सभी अनुक्रमित को फिर से बनाया जा रहा है। मैं रिकवरी मॉडल को बल्क लॉग में बदलने पर भी विचार करूंगा। यह वही है जो मैं करता हूं और अभी भी विंडो के दौरान लेन-देन लॉग बैकअप है। नीचे देखें लेख https://technet.microsoft.com/en-us/library/ms191484(v=sql.105).aspx

— ADTJOB
स्रोत

2

ध्यान दें कि ओपी ने कहा कि उनका DB पहले से ही SIMPLE रिकवरी मॉडल का उपयोग कर रहा है; यह केवल लेन-देन को पूरा करने के लिए लंबे समय तक लॉग में रखता है। यदि वे बल्क-लॉग में जाते हैं तो कोई सुधार नहीं होगा।

— RDFozz

आपका बिलकुल सही। मैं क्षमाप्रार्थी हूं।

— ADTJOB