डाउनटाइम को कम करना और डेटाबेस उपलब्धता बढ़ाना हर व्यवसाय के आवश्यक उद्देश्य हैं। डेटाबेस एडमिनिस्ट्रेटर (DBAs) हमेशा किसी भी डेटा फ़ाइल या पूर्ण डेटाबेस भ्रष्टाचार विफलता के मामले में तेज़ रिकवरी समाधान प्रदान करने के नए तरीके खोजते रहते हैं। संस्करण 10g से शुरू होकर, Oracle® रिकवरी मैनेजर (RMAN) एक सुविधा प्रदान करता जिसे इंक्रीमेंटल मर्ज बैकअप (IMB) कहा जाता है, जो रिकवरी समय को कम करने का समाधान प्रदान करता है, विशेष रूप से बहुत बड़े डेटाबेस (VLDB) के लिए।
परिचय
यदि इसे सही विकल्पों के साथ कॉन्फ़िगर किया गया है, तो IMB सुविधा डेटाबेस रिकवरी समय को काफी कम कर सकती है। हालांकि व्यापक रूप से उपयोग नहीं की जाती, यह सुविधा VLDB के लिए एक आदर्श बैकअप पद्धति है। डेटा फ़ाइलों की इमेज कॉपी बनाई जाती हैं, और फिर इंक्रीमेंटल बैकअप लागू किए जाते हैं, जो प्रत्येक बैकअप ऑपरेशन के बाद इमेज कॉपी को आगे बढ़ाते हैं।
यह पोस्ट IMB के उपयोग के लिए कुछ विचारों पर प्रकाश डालता है, प्रक्रिया को स्पष्ट करने के लिए नमूना कोड प्रदान करता है, और कई रिकवरी परिदृश्य दिखाता है।
विचार
इमेज कॉपी बैकअप रणनीति का उपयोग करने से पहले, निम्नलिखित विचारों को ध्यान में रखें:
-
ब्लॉक चेंज ट्रैकिंग (BCT) डेटाबेस में सक्षम होना चाहिए।
-
इमेज कॉपी को स्टोर करने के लिए डेटाबेस डेटा फ़ाइलों द्वारा वास्तव में उपयोग किए जा रहे डिस्क स्पेस के समान मात्रा की आवश्यकता होती है।
-
पॉइंट-इन-टाइम रिकवरी (PITR) के लिए, आपके पास कम से कम एक पूर्ण बैकअप होना चाहिए, और डेटाबेस की रिकवरी पूरी होने तक आर्काइव लॉग की आवश्यकता होती है।
-
डेटाबेस की इमेज कॉपी इनपुट और आउटपुट (I/O) के संदर्भ में उसी प्रकार के स्टोरेज पर होनी चाहिए ताकि डेटाबेस कॉपी पर स्विच करते समय प्रदर्शन प्रभावित न हो।
निम्न छवि एक इंक्रीमेंटली अपडेटेड बैकअप दिखाती है:
नमूना कोड
दैनिक इमेज कॉपी लेने और इंक्रीमेंटली अपडेट करने के लिए निम्न कोड चलाएं:
run { allocate channel c1 device type disk format '/home/oracle/backup/%U'; recover copy of database with tag 'IMG_COPY'; backup incremental level 1 for recover of copy with tag 'IMG_COPY' database; release channel c1; } पहले निष्पादन पर, recover copy of database कमांड कुछ नहीं करती। backup incremental कमांड एक नया इंक्रीमेंटल level 0 बैकअप बनाता है जिसे IMG_COPY टैग किया गया है क्योंकि यह इस टैग के साथ बनाया गया पहला बैकअप है।
दूसरे निष्पादन पर, recover copy of database कमांड तब तक कुछ नहीं करती जब तक कि उसे INC 1 बैकअप नहीं मिल जाते। backup incremental कमांड INC 1 बैकअप बनाता है।
तीसरे और बाद के निष्पादन पर, recover command मौजूदा इमेज कॉपी पर अंतिम उपलब्ध INC 1 बैकअप लागू करता है। backup command अगला INC 1 बैकअप बनाता है।
रिकवरी परिदृश्य
निम्न उपयोग के मामले बताते हैं कि इंक्रीमेंटल मर्ज बैकअप विभिन्न रिकवरी स्थितियों में कैसे सहायता करते हैं।
केस 1: भ्रष्ट, हटाई गई, या ओवरराइट की गई डेटा फ़ाइल
निम्न कोड में दिखाए अनुसार परीक्षण के लिए एक टेबल बनाएं, और इमेज कॉपी लेने के लिए पूर्ववर्ती स्क्रिप्ट का उपयोग करें।
SQL> create table ImgCpyTab tablespace tbs2 as select * from dba_objects; Table created. FILE_NAME FILE_ID TABLESPACE_NAME ————————- ——————— ——————————————— /home/oracle/Sw/oradata/test/tbs02.dbf 5 TBS2 SQL> select count(1) from ImgCpyTab; COUNT(1) ———- 72476 इस परिदृश्य का परीक्षण करने के लिए, निम्न कोड में दिखाए अनुसार भौतिक डेटा फ़ाइल को जानबूझकर ले जाएं, और select कमांड अपेक्षित त्रुटि फेंकता है।
mv /home/oracle/Sw/oradata/test/tbs02.dbf /home/oracle/Sw/oradata/test/tbs02.dbf_BKP select count(1) from scott.IMGCPYTAB * ERROR at line 1: ORA-01116: error in opening database file 5 ORA-01110: data file 5: '/home/oracle/Sw/oradata/test/tbs02.dbf' ORA-27041: unable to open file Linux Error: 2: No such file or directory Additional information: 3 इस मामले में, भौतिक फ़ाइल को पुनर्स्थापित करने की आवश्यकता नहीं है। इसके बजाय, बैकअप पर स्विच करें और इसे पुनर्प्राप्त करें। यह बहुत तेज़ है, भले ही डेटा फ़ाइलों या डेटाबेस का आकार टेराबाइट्स में हो।
निम्न कोड डेटाफ़ाइल को ऑफ़लाइन मोड में डालता है:
SQL> alter database datafile 5 offline; Database altered. इसके बाद, डेटा फ़ाइल को कॉपी पर स्विच करें और पुनर्प्राप्त करें:
[oracle@localhost backup]$ rman target / Recovery Manager: Release 11.2.0.2.0 – Production on Thu Jun 5 18:17:15 2014 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: TEST (DBID=2122535405) RMAN> switch datafile 5 to copy; using target database control file instead of recovery catalog datafile 5 switched to datafile copy "/home/oracle/backup/data_D-TEST_I-2122535405_TS-TBS2_FNO-5_6ppa3ev1" RMAN> recover datafile 5; Starting recover at 05-JUN-14 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=19 device type=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: SID=149 device type=DISK starting media recovery media recovery complete, elapsed time: 00:00:01 Finished recover at 05-JUN-14 RMAN> sql 'alter database datafile 5 online'; sql statement: alter database datafile 5 online RMAN> exit निम्न कोड में दिखाए अनुसार, डेटा फ़ाइल वापस आ गई है और टेबल सुलभ है:
FILE_NAME FILE_ID TABLESPACE_NAME ————————- ——————— ——————————————— TBS2 /home/oracle/backup/data_D-TEST_I-2122535405_TS-TBS2_FNO-5_6ppa3ev1 AVAILABLE SQL> select count(1) from scott.IMGCPYTAB; COUNT(1) ———- 72476 नोट: यदि आप file_name कॉलम देखते हैं, तो आप जानते हैं कि डेटाबेस इमेज कॉपी फ़ाइल का उपयोग कर रहा है।
केस 2: पूर्ण डेटाबेस भ्रष्टाचार या डिस्क विफलता
यदि आपके पास पूरी तरह से भ्रष्ट डेटाबेस या डिस्क विफलता है, तो आप निम्न चरणों का उपयोग करके डेटाबेस को कॉपी पर स्विच कर सकते हैं:
- डेटाबेस को शट डाउन करें।
- यदि कंट्रोल फ़ाइल गुम है, तो इसे पुनर्स्थापित करें।
- इमेज कॉपी को कैटलॉग करें।
- डेटाबेस को कॉपी पर स्विच करें।
- आर्काइव उपलब्ध होने तक पुनर्प्राप्त करें और फिर डेटाबेस खोलें।
निष्कर्ष
इस पोस्ट में चर्चा की गई कि RMAN इमेज कॉपी बैकअप और रिकवरी सुविधा का उपयोग कैसे करें। इसने डेटा फ़ाइलों और डेटाबेस के कार्यान्वयन और भौतिक भ्रष्टाचार के मामले में रिकवरी के लिए कुछ उपयोग के मामले भी प्रदान किए। इंक्रीमेंटल मर्ज बैकअप सुविधा डेटाबेस बैकअप को सरल बनाती है और तेज़ और लचीली डेटा रिकवरी सुनिश्चित करती है।
कोई टिप्पणी करने या प्रश्न पूछने के लिए फीडबैक टैब का उपयोग करें।