ओरेकल में ऑनलाइन फिर से लॉग या चेकपॉइंट इवेंट

बहुत बार, ऐसा उपद्रव होता है कि "चेकपॉइंट पूरा नहीं" जैसे संदेश एक के बाद एक अलर्ट.लॉग डेटाबेस में स्ट्रीमिंग कर रहे हैं। इस मामले में मानक सलाह है: "लाल लॉग की संख्या और / या आकार बढ़ाएं।" और फिर सवाल यह है कि ये रेड लॉग कौन हैं और वे क्या खाते हैं।

सिद्धांत की बिट

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

एक विशेष पृष्ठभूमि DBWn डेटाबेस प्रक्रिया बफर कैश को आवश्यकतानुसार मुक्त करती है, और एक चेकपॉइंट इवेंट भी निष्पादित करती है। एक चेकपॉइंट एक ऐसी घटना है जिसके दौरान गंदे (संशोधित) ब्लॉक डेटा फ़ाइलों को लिखे जाते हैं। CKPT (चेकपॉइंट प्रक्रिया) प्रक्रिया चेकपॉइंट ईवेंट के लिए ज़िम्मेदार है, जो चेकपॉइंट के बारे में कंट्रोल फ़ाइल (एक कंट्रोल फ़ाइल क्या है, दूसरी बार) और डेटा फ़ाइल हेडर के बारे में जानकारी लिखती है।

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

कई प्रकार के नियंत्रण बिंदु हैं।

• धागा चौकियां एक निश्चित बिंदु तक एक निश्चित बिंदु के भीतर होने वाले सभी परिवर्तनों को एक पंक्ति में डेटा फ़ाइल पर लिखा जाता है। वे निम्नलिखित स्थितियों में होते हैं:
  • आधार का पूर्ण विराम;
  • सिस्टम चेकपॉइंट बदलना;
  • ऑनलाइन redo लॉग स्विच करना;
  • परिवर्तन डेटाबेस बैकअप शुरू करते हैं।
• डेटा फ़ाइलों और टेबल स्पेस के लिए चेकप्वाइंट। यह तब होता है जब टेबल स्पेस और डेटा फ़ाइलों के साथ संचालन होता है (टेबलस्पेस ऑफ़लाइन में परिवर्तन करें, केवल पढ़ने के लिए टेबलस्पेस में बदलाव करें, डेटा फ़ाइल सिकुड़ना, आदि)
• वृद्धिशील नियंत्रण अंक। उदाहरण के नियंत्रण बिंदु का एक सबसेट, जो डिस्क को फिर से लोड करने के दौरान भारी संख्या में डिस्क को लिखने से बचने के लिए डिज़ाइन किया गया है। DBWn प्रक्रिया हर तीन सेकंड में कम से कम एक बार जांच करती है कि क्या डिस्क पर लिखने के लिए नए "गंदे" ब्लॉक हैं। यदि वहाँ हैं, तो उन्हें डेटा फ़ाइलों में दर्ज किया जाता है, फिर से लॉग इन में चेकपॉइंट लेबल को स्थानांतरित किया जाता है (ताकि अगली बार आपको कम लॉग को देखना पड़े), लेकिन डेटा फ़ाइलों के हेडर नहीं बदलते हैं।

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

पैरामीटर जिस पर नियंत्रण बिंदु घटनाओं की आवृत्ति निर्भर करती है और जो वांछित होने पर कॉन्फ़िगर किया जा सकता है:

• FAST_START_MTTR_TARGET (क्रैश के बाद डेटाबेस को पुनर्स्थापित करने में सेकंड में कितना समय लगेगा? अगर मैं कुछ समझता हूं, तो हम उस समय के बारे में बात कर रहे हैं जो उपलब्ध ऑनलाइन रीडो लॉग का उपयोग करने में लगता है)।
• LOG_CHECKPOINT_INTERVAL (चेकपॉइंट ईवेंट फ़्रीक्वेंसी ऑनलाइन रीडो लॉग फ़ाइल के ब्लॉक की अनुमत संख्या है जो पिछले चेकपॉइंट के बाद भरे गए थे; ब्लॉक ऑपरेटिंग सिस्टम के संदर्भ में ब्लॉक हैं, डेटाबेस नहीं)।
• LOG_CHECKPOINT_TIMEOUT (दो चेकपॉइंट घटनाओं के बीच अधिकतम सेकंड की अनुमति)।
• LOG_CHECKPOINTS_TO_ALERT (सत्य / असत्य; निर्धारित करता है कि चेकपॉइंट के स्विच को अलर्ट में फेंकना है या नहीं। एक उपयोगी चीज, इसे सही पर सेट करना बेहतर होगा)।

यह स्पष्ट करने के लिए समझ में आता है कि FAST_START_MTTR_TARGET और LOG_CHECKPOINT_INTERVAL पैरामीटर, यदि आप दस्तावेज़ को मानते हैं, तो पारस्परिक रूप से अनन्य हैं।

आइए अब हमारे आधार को देखें

जैसा कि पहले ही उल्लेख किया गया है, चेकपॉइंट घटना तब होती है जब ऑनलाइन फिर से लॉग इन किया जाता है। एक अच्छा अभ्यास, अगर आपको लगता है कि मेटलवेयर, हर बीस मिनट में लॉग स्विच कर रहा है। बहुत छोटे ऑनलाइन रीडो लॉग चेकपॉइंट घटनाओं की आवृत्ति बढ़ा सकते हैं और प्रदर्शन को कम कर सकते हैं। ओरेकल अनुशंसा करता है कि ऑनलाइन रीडो लॉग फ़ाइलों का आकार समान हो और डेटाबेस के प्रत्येक उदाहरण के लिए कम से कम दो लॉग समूह मौजूद हों।

स्विचिंग लॉग की आवृत्ति को ट्रैक करने के लिए, आप अलर्ट लॉग में देख सकते हैं।
ऑनलाइन फिर से लॉग ऑन करने का एक उदाहरण।

 Wed Nov 02 17:51:20 2011 Thread 1 advanced to log sequence 83 (LGWR switch) Current log# 2 seq# 83 mem# 0: D:\ORACLE\ORADATA\ORADB\REDO02.LOG Thread 1 advanced to log sequence 84 (LGWR switch) Current log# 3 seq# 84 mem# 0: D:\ORACLE\ORADATA\ORADB\REDO03.LOG 

कभी-कभी अलर्ट में। आपको निम्न त्रुटियां मिल सकती हैं।

 Wed Nov 02 17:51:53 2011 Thread 1 cannot allocate new log, sequence 87 Checkpoint not complete Current log# 2 seq# 86 mem# 0: D:\ORACLE\ORADATA\ORADB\REDO02.LOG 

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

रसोई की किताब से। ऑनलाइन फिर से लॉग के आकार और / या संख्या को कैसे बदलें

1. सबसे पहले, केवल लॉग की स्थिति देखें।

 SQL> select group#, bytes, status from v$log; GROUP# BYTES STATUS ---------- ---------- ---------------- 1 52428800 ACTIVE 2 52428800 ACTIVE 3 52428800 CURRENT 

आइए लॉग के आकार को 100M तक बढ़ाने का प्रयास करें।

2. चलो सीधे redo लॉग फ़ाइलों को देखते हैं।

 SQL> select group#, member from v$logfile; GROUP# MEMBER ---------- ---------------------------------------- 3 D:\ORACLE\ORADATA\ORADB\REDO03.LOG 2 D:\ORACLE\ORADATA\ORADB\REDO02.LOG 1 D:\ORACLE\ORADATA\ORADB\REDO01.LOG 

3. 100M प्रत्येक के लॉग के तीन नए समूह बनाएं।

 SQL> alter database add logfile group 4 'D:\ORACLE\ORADATA\ORADB\REDO04.LOG' size 100M; Database altered. SQL> alter database add logfile group 5 'D:\ORACLE\ORADATA\ORADB\REDO05.LOG' size 100M; Database altered. SQL> alter database add logfile group 6 'D:\ORACLE\ORADATA\ORADB\REDO06.LOG' size 100M; Database altered. 

आइए देखें क्या हुआ

 SQL> select group#, bytes, status from v$log; GROUP# BYTES STATUS ---------- ---------- ---------------- 1 52428800 INACTIVE 2 52428800 INACTIVE 3 52428800 INACTIVE 4 104857600 INACTIVE 5 104857600 ACTIVE 6 104857600 CURRENT 

4. अब आप पुराने (बहुत छोटे) लॉग को हटा सकते हैं। ऐसा करने के लिए, नए बनाए गए समूहों से लॉग सक्रिय होना चाहिए। यदि वर्तमान स्थिति में ऐसा नहीं है, तो आप कमांड का उपयोग कर सकते हैं

 SQL> alter system switch logfile; 

अब, एक स्पष्ट विवेक के साथ, अनावश्यक लॉग को हटा दें

 SQL> alter database drop logfile group 1; Database altered. SQL> alter database drop logfile group 2; Database altered. SQL> alter database drop logfile group 3; alter database drop logfile group 3 * ERROR at line 1: ORA-01624: log 3 needed for crash recovery of instance oradb (thread 1) ORA-00312: online log 3 thread 1: 'D:\ORACLE\ORADATA\ORADB\REDO03.LOG' 

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

 SQL> alter system checkpoint; System altered. 

फिर हम साहसपूर्वक प्रयास को दोहराते हैं।

 SQL> alter database drop logfile group 3; Database altered. 

5. जाँच करें कि क्या हम सफल हुए।

 SQL> select group#, bytes, status from v$log; GROUP# BYTES STATUS ---------- ---------- ---------------- 4 104857600 ACTIVE 5 104857600 ACTIVE 6 104857600 CURRENT 

6. अब डेटाबेस बैकअप करने का समय है। तो, बस मामले में।

7. अब आप ऑपरेटिंग सिस्टम की अनावश्यक फाइलों को हटा सकते हैं।

 D:\> del D:\oracle\oradata\oradb\REDO01.LOG D:\> del D:\oracle\oradata\oradb\REDO02.LOG D:\> del D:\oracle\oradata\oradb\REDO03.LOG 

अगर हमारे पास Oracle RAC स्थापित है तो क्या करें।

सिद्धांत रूप में, एक ही बात। इस तथ्य को देखते हुए कि प्रत्येक उदाहरण के लिए अलग-अलग रेडो लॉग्स का एक सेट है और उन्हें अलग से संचालित करना होगा।

ALTER SYSTEM CHECKPOINT LOCAL कमांड केवल उस उदाहरण के साथ काम करता है जो आप वर्तमान में जुड़े हुए हैं। पूरे डेटाबेस के लिए एक चेकपॉइंट इवेंट को ट्रिगर करने के लिए, आपको ALTER SYSTEM CHECKPOINT या ALTER SYSTEM CHECKPOINT GLOBAL पर कॉल करना होगा।

ALTER SYSTEM SWITCH LOGFILE कमांड केवल उस उदाहरण को प्रभावित करता है जिसे आप वर्तमान में कनेक्टेड हैं। संपूर्ण सिस्टम के लिए ऑनलाइन रीडो लॉग्स स्विच करने के लिए, आप ALTER SYSTEM ARCHIVE LOG CURRENT कमांड का उपयोग कर सकते हैं।

प्रत्येक उदाहरण के लिए अलग से नए ऑनलाइन रीडो लॉग बनाना आवश्यक है।

 ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 4 '+ASMGRP/ORADB/REDO04.LOG' SIZE 100M; ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 4 '+ASMGRP/ORADB/REDO04.LOG' SIZE 100M; 

वैसे, फ़ाइल नाम को छोड़ा जा सकता है। आधार खुद को सुंदर के बारे में अपने विचारों के अनुसार कहेगा।

वैसे। आप ऑनलाइन रीडो लॉग फाइल का प्रचार कर सकते हैं।

 ALTER DATABASE ADD LOGFILE GROUP 7 ('D:\ORACLE\ORADATA\ORADB\REDO07.LOG','C:\ORACLE\ORADATA\ORADB\REDO07.LOG') SIZE 100M; 

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

___________________________
साहित्य
ओरेकल डेटाबेस 11.2 आधिकारिक दस्तावेज।
Oracle सपोर्ट नोड 147468.1 और 1035935.6
थॉमस Kyte, विशेषज्ञ ओरेकल डेटाबेस आर्किटेक्चर: 9i और 10g प्रोग्रामिंग तकनीक और समाधान