इतिहास को ट्रैक करने के लिए सीडीसी का उपयोग कब करें?


26

SQL सर्वर चेंज डेटा कैप्चर एक विशेषता है जो SQL सर्वर ट्रांजेक्शन लॉग से ऐतिहासिक डेटा को पढ़ता है और उन्हें एक विशेष तालिका में संग्रहीत करता है।

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

सीडीसी के कुछ फायदे हैं

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

इसके कुछ नुकसान भी हैं:

मैंने सीडीसी के बारे में काफी पढ़ा है और जब मैं जानता हूं कि इसका उपयोग कैसे करना है, तो मुझे अभी भी यकीन नहीं है कि यह मेरे लिए सही उपकरण है।

  1. CDC किन कार्यों / परिदृश्यों के लिए सही उपकरण है? (जैसे किसी निश्चित समय में डेटा ऑब्जेक्ट को पुनर्स्थापित करने के लिए उपयोगकर्ताओं को अनुमति देना? ऑडिट करना? डेटा का पूरा इतिहास दिखा रहा है?)
  2. जब आपको सीडीसी का उपयोग नहीं करना चाहिए, लेकिन कस्टम ट्रिगर-आधारित समाधान का सहारा लेना चाहिए?
  3. क्या ऑपरेशनल डेटाबेस में सीडीसी का उपयोग करना और ऑपरेशनल एप्लिकेशन के भीतर सीडीसी डेटा का उपयोग करना ठीक है? (जैसे इसे अंतिम उपयोगकर्ता को दिखा रहा है) या यह स्पष्ट रूप से इस सुविधा का दुरुपयोग है?

मैं आमतौर पर सुनता हूं कि सीडीसी एक ऑडिट टूल है, लेकिन यह नहीं है कि SQL सर्वर ऑडिट किस लिए है? क्या वे दोनों एक ही कार्य के लिए अलग-अलग उपकरण हैं? या सीडीसी अन्य चीजों के लिए इस्तेमाल किया जा सकता है?

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

जब मैं अपने विशिष्ट परिदृश्य के लिए सलाह की सराहना करता हूं, तो उत्तर को डेटा कैप्चर का उपयोग कब या कब नहीं करना चाहिए, इस बारे में सामान्य सलाह देनी चाहिए।


1
आदर्श रूप में, एक "ढांचा" इस तरह का निर्णय नहीं करेगा; इसे व्यक्तिगत परियोजनाओं पर छोड़ दिया जाएगा। लेकिन जब से आपको ऐसा करने के लिए कहा जा रहा है, मैं कम से कम उस बिंदु को बनाऊंगा जिसे आप ये आवश्यकताएं दे रहे हैं: इसे पूरा करने के लिए अलग-अलग तरीके हैं, और सबसे अच्छा विकल्प सटीक उपयोग और जरूरतों पर बहुत अधिक निर्भर है। पूछें कि क्या वे आपको कोई स्पष्टीकरण दे सकते हैं जो आपको निर्णय लेने में मदद कर सकता है (जैसे प्रदर्शन या लचीलापन अधिक महत्वपूर्ण है)। विचार करने के लिए एक अन्य विकल्प "रूपरेखा" के हिस्से के रूप में दोनों विकल्पों को विकसित करना है और वास्तविक परियोजनाओं को चुनने देना है जो एक को सक्षम करना है।
jpmc26

@ jpmc26, इस तरह के प्रश्न को तय करते हुए प्रत्येक परियोजना के खर्च को रोकने के लिए रूपरेखा की आवश्यकता हो सकती है।
इयान रिंगरोस

@IanRingrose मेरी बात यह है कि लंबे समय में, किसी परियोजना की विशिष्ट आवश्यकताओं पर विचार किए बिना उस निर्णय को करने की कोशिश करना, इससे अधिक समस्याओं का कारण बनता है (और इस तरह वास्तव में उस समय को खर्च करने की तुलना में अधिक महंगा हो सकता है)। यह एक ऐसा निर्णय है जिसे एक सामान्य मामले में प्रभावी ढंग से नहीं किया जा सकता है। परियोजना की बारीकियों पर विचार किया जाना चाहिए। एक कंबल निर्णय का उपयोग करते हुए, समय का चयन चुने हुए समाधान का उपयोग करके किया जाएगा और इसके आसपास की धारणाओं को केवल उन मान्यताओं का उल्लंघन करने के लिए किया जाएगा जब यह पता चला कि यह एक उपयुक्त समाधान नहीं था। तब सिस्टम को फिर से डिज़ाइन करने की आवश्यकता होगी।
jpmc26

1
@ jpmc26 मैं वास्तव में आपके द्वारा प्रस्तावित समाधान के साथ जा सकता हूं, अगर मुझे इसे बंद करने का एक तरीका मिल जाए: ट्रिगर-आधारित और सीडीसी-आधारित इतिहास ट्रैकिंग, switchable और एक सामान्य इंटरफ़ेस के पीछे दोनों का विकास करना। अनुप्रयोग तब अपनी आवश्यकताओं के आधार पर एक या दूसरे को चुन सकते हैं, लेकिन इसे स्वयं लागू करने के बारे में चिंता करने की ज़रूरत नहीं है। निश्चित रूप से मैं अभी भी अपने उपरोक्त प्रश्न का एक अच्छा उत्तर प्राप्त करना चाहूंगा, क्योंकि अगर सीडीसी को इस तरह के कार्य के लिए वैसे भी नहीं काटा जाता है (जैसे कि यह केवल ऑडिटिंग के लिए कोई अच्छा है) तो मैं खुद को परेशानी से बचा सकता हूं और हमेशा ट्रिगर का उपयोग कर सकता हूं ।
मैग्नेटिक

"यदि एजेंट नहीं चल रहा है या क्रैश हो रहा है, तो किसी भी इतिहास को ट्रैक नहीं किया जा रहा है" - लेकिन अगर इसे फिर से शुरू किया गया, तो कोई भी बदलाव नहीं होगा, है ना?
एंडी जॉइनर

जवाबों:


12

पहले तो,

परिवर्तन डेटा कैप्चर केवल SQL सर्वर के एंटरप्राइज़, डेवलपर और मूल्यांकन संस्करणों पर उपलब्ध है।

यदि आपके किसी ग्राहक के पास उद्यम संस्करण नहीं होंगे, या आप अभी तक यह नहीं जानते हैं कि आप उद्यम संस्करणों का उपयोग करेंगे। (जैसा कि कल्पना में "भविष्य के कई अनुप्रयोग शामिल हैं" यह आपके लिए एक वास्तविक मुद्दा हो सकता है)

ट्रिगर्स के विपरीत यह वास्तविक समय नहीं है, यह एक फायदा और नुकसान दोनों है। ट्रिगर्स का उपयोग करना हमेशा एक अपडेट को धीमा करता है।

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

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


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

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

@atticae, आपका ढांचा डेटाबेस तक सीमित नहीं है, इसमें वह कोड शामिल हो सकता है जो डेटाबेस के बाहर चलता है।
इयान रिंगरोज

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

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

12

यहाँ एक बहुत अच्छी तरह से लिखा गया 9 भाग श्रृंखला है जो SQL सर्वर डेटा परिवर्तनों के ऑडिटिंग के विभिन्न तरीकों की समीक्षा करता है। भाग 3, 4 और 5 सीडीसी पर केंद्रित हैं। यह सभी लेखों के माध्यम से पढ़ने के लायक है क्योंकि यह आपके प्रश्नों का उत्तर देगा, विभिन्न परिदृश्यों की तरह जहां सुविधाएँ उपयुक्त होंगी और ओवरहेड होंगी। http://solutioncenter.apexsql.com/tag/methods-for-auditing-sql-server


1
लेख के माध्यम से स्किमिंग के बाद, मैं अभी भी ज्यादा चालाक नहीं हूं। अधिकांश लेखों के रूप में यह विस्तार से जाना जाता है कि सीडीसी का उपयोग कैसे किया जाता है और इसकी तुलना ट्रैकिंग कैसे की जाती है। हालांकि वास्तव में मेरे उपरोक्त सवालों का जवाब नहीं है।
22

9

CDC किन कार्यों / परिदृश्यों के लिए सही उपकरण है? (जैसे किसी निश्चित समय में डेटा ऑब्जेक्ट को पुनर्स्थापित करने के लिए उपयोगकर्ताओं को अनुमति देना?

शायद, यह निर्भर करता है।

लेखा परीक्षा?

हाँ।

डेटा का पूरा इतिहास दिखा रहा है?)

हाँ।

जब आपको सीडीसी का उपयोग नहीं करना चाहिए, लेकिन कस्टम ट्रिगर-आधारित समाधान का सहारा लेना चाहिए?

जब परिवर्तन तालिका में डेटा आपकी आवश्यकताओं को पूरा नहीं करता है।

क्या ऑपरेशनल डेटाबेस में सीडीसी का उपयोग करना और ऑपरेशनल एप्लिकेशन के भीतर सीडीसी डेटा का उपयोग करना ठीक है? (इसे अंतिम उपयोगकर्ता को दिखा रहा है)

हाँ।

या यह स्पष्ट रूप से इस सुविधा का दुरुपयोग है?

नहीं, यह इस सुविधा का दुरुपयोग नहीं है।

मैं आमतौर पर सुनता हूं कि सीडीसी एक ऑडिट टूल है, लेकिन क्या यह SQL सर्वर ऑडिट के लिए नहीं है?

हाँ।

क्या वे दोनों एक ही कार्य के लिए अलग-अलग उपकरण हैं?

नहीं।

या सीडीसी अन्य चीजों के लिए इस्तेमाल किया जा सकता है?

सीडीसी का उपयोग अन्य चीजों के लिए किया जा सकता है।

चेंज ट्रैकिंग है और चेंज डेटा कैप्चर है। दोनों की जड़ें प्रतिकृति में हैं।

परिवर्तन ट्रैकिंग एक तालिका में शुद्ध परिवर्तन प्रदान करने का एक तरीका प्रदान करती है। उपयोग का एक उदाहरण एक हाथ से आयोजित डिवाइस सिंक होगा।

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


2

सुधार का एक बिंदु। एक समय में, परिवर्तन डेटा कैप्चर केवल ऊपर सूचीबद्ध संस्करणों में उपलब्ध था। हालाँकि, परिवर्तन डेटा कैप्चर मानक संस्करण में 2016 SP1 के रूप में उपलब्ध हो गया। इस प्रकार, 2016 के SP1 से पहले लिखे गए कई लेख यह ध्वनि करते हैं जैसे कि सीडीसी हम में से उन लोगों के लिए पहुंच से बाहर है जो मानक संस्करण का उपयोग कर रहे हैं। यह अब मामला ही नहीं है। Microsoft डॉक सीडीसी की उपलब्ध रूपरेखा को नीचे दिए लिंक में है।

https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2016?view=sql-server-2017#DW

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.