एक बार फिर ओरेकल स्टैंडबाय के बारे में

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

भविष्य में, जब पाठ में आदेशों और प्रश्नों के उदाहरण दिए जाएंगे, तो मैं निम्नलिखित संकेतन का उपयोग करूंगा:
$ - कमांड को ऑपरेटिंग सिस्टम की कमांड लाइन में यूजर ऑरेकल के तहत दर्ज किया जाता है।
SQL> - कमांड को sqlplus में दर्ज किया गया है। इस लेख में, जहां यह स्पष्ट रूप से परिभाषित नहीं है, यह माना जाता है कि sqlplus को प्रशासनिक मोड ( sqlplus / as sddba ) में शुरू किया गया है, और डेटाबेस उदाहरण $ ORACLE_SID चर के माध्यम से सेट किया गया है।
RMAN> - कमांड को rman में दर्ज किया जाता है। यहाँ भी, जब तक कि किसी अन्य चीज़ को स्पष्ट रूप से परिभाषित नहीं किया जाता है, यह माना जाता है कि रमन को लक्ष्य लक्ष्य / कमांड के साथ शुरू किया गया है, और डेटाबेस उदाहरण $ ORACLE_SID चर के माध्यम से सेट किया गया है।

इससे पहले कि हम शुरू करें, यह ओरेकल डेटाबेस संगठन के सिद्धांतों के बारे में थोड़ा कहने लायक है कि हमें ओरेकल डीबीएमएस में बैकअप और डेटा रिकवरी के तंत्र को समझने की आवश्यकता होगी।

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

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

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

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

हम मानते हैं कि हमारे डेटाबेस को परीक्षण कहा जाता है । हम मुख्य और स्टैंडबाय डेटाबेस के कॉन्फ़िगरेशन को समायोजित करेंगे ताकि किसी भी समय हम उनकी भूमिकाओं (स्विचओवर) को स्विच कर सकें। हमारी योजना है कि हमारा सिस्टम MAXIMUM PERFORMANCE नामक डेटा गार्ड सुरक्षा मोड का उपयोग करेगा।

तो चलिए चलते हैं।
शुरू करने के लिए, हम यह सत्यापित करते हैं कि हमारा डेटाबेस आवश्यक आवश्यकताओं को पूरा करता है।

1. हम देखते हैं कि हमारा मुख्य DB किस मोड में काम करता है:

SQL> select name, open_mode, log_mode from v$database;

NAME OPEN_MODE LOG_MODE
--------- ---------- ------------
TEST READ WRITE ARCHIVELOG

यदि आप LOG_MODE फ़ील्ड में ARCHIVELOG मान नहीं देखते हैं, तो निम्न आदेश निष्पादित करें:

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;

2. पासवर्ड फ़ाइल की जाँच करें:

एसक्यूएल> वी $ pwfile_users से * का चयन करें;

USERNAME SYSDB SYSOP
------------------------------ ----- -----
SYS TRUE TRUE

यदि आप यह परिणाम नहीं देखते हैं, तो आवश्यक फ़ाइल बनाएँ:

$ orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=xxxxxxxx force=y

'Xxxxxxxx' के बजाय, आपको SYS उपयोगकर्ता के लिए वर्तमान पासवर्ड डालना होगा।

3. फोर्स लॉगिंग मोड चालू करें:

SQL> alter database force logging;

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

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

SQL> select bytes from v$log;

BYTES
----------
52428800
52428800
52428800

हम देखते हैं कि हमारे डेटाबेस में फिर से लॉग के लिए कौन से समूह हैं:

SQL> select group# from v$logfile;

GROUP#
----------
1
2
3

स्टैंडबाय फिर से लॉग बनाएं:

SQL> alter database add standby logfile group 4 '/oradata/test/stnbylog01.log' size 50m;
Database altered.

SQL> alter database add standby logfile group 5 '/oradata/test/stnbylog02.log' size 50m;
Database altered.

SQL> alter database add standby logfile group 6 '/oradata/test/stnbylog03.log' size 50m;
Database altered.

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

SQL> create pfile='/data/backup/pfilePROD.ora' from spfile;

हमें परिणामी फ़ाइल में कुछ पैरामीटर जोड़ने की जरूरत है, अगर वे वहां नहीं हैं:

db_name = 'परीक्षण' हमारे डेटाबेस का नाम है (मुख्य और अतिरिक्त उदाहरणों के लिए समान)।
db_unique_name = 'testprod' - और यह प्रत्येक उदाहरण के लिए एक अनूठा नाम है, यह जब स्टैंडबाय से उत्पादन तक भूमिका बदल रहा है तो यह नहीं बदलेगा।
l og_archive_config = 'dg_config = (testprod, teststan)' - उन उदाहरणों के नामों को परिभाषित करते हैं जिनके बीच लॉग का आदान-प्रदान होगा।
log_archive_dest_1 = 'सेवा = परीक्षणकर्ता LGWR ASYNC VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE) db_unique_name =' teststan ' - जब उदाहरण मुख्य आधार (PRIMARY_ROLE) है, तो हम LGWRR प्रक्रिया का उपयोग करके स्टैंडबाय सर्वर में संग्रह लॉग को स्थानांतरित करेंगे। ASYNC पैरामीटर इंगित करता है कि लेन-देन से उत्पन्न डेटा को लेनदेन पूरा होने से पहले स्टैंडबाय पर प्राप्त करने की आवश्यकता नहीं है - इससे स्टैंडबाय के साथ कोई संबंध नहीं होने पर मुख्य डेटाबेस को रोकना नहीं होगा।
log_archive_dest_2 = 'LOCATION = / oradata / परीक्षण / संग्रह VALID_FOR = (ALL_LOGFILES, ALL_ROLES) db_unique_name = testprod' - यहां हम उस निर्देशिका को इंगित करते हैं जहां संग्रहीत लॉग स्थानीय रूप से संग्रहीत किए जाएंगे (मुख्य डेटाबेस के लिए) या मुख्य डेटाबेस से आने वाले लॉग। स्टैंडबाय आधार)।
l og_archive_dest_state_1 = सक्षम - log_archive_dest_1 में संग्रह लॉग को सक्षम करें। जब तक हमने एक स्टैंडबाय डेटाबेस नहीं बनाया है, तब तक यह पैरामीटर DEFER पर सेट किया जा सकता है यदि हम अलर्ट_लॉग में स्टैंडबाय डेटाबेस की अनुपलब्धता के बारे में अनावश्यक संदेश नहीं देखना चाहते हैं।
log_archive_dest_state_2 = सक्षम - log_archive_dest_2 में संग्रह लॉग दर्ज करने में सक्षम करें ।
fal_client = 'testprod' - यह पैरामीटर निर्धारित करता है कि जब उदाहरण स्टैंडबाय मोड में प्रवेश करता है, तो यह आर्काइव लॉग्स (फ़ुटबॉल आर्काइव लॉग) प्राप्त करने के लिए एक क्लाइंट होगा।
fal_server = 'teststan' - FAL (लाने का संग्रह लॉग) सर्वर को परिभाषित करता है जिससे संग्रह लॉग को स्थानांतरित किया जाएगा। डेटाबेस को स्टैंडबाय मोड में शुरू करने पर ही fal_client और fal_server पैरामीटर काम करते हैं।
स्टैंडबाय_फाइल_मनरेशन = 'ऑटो' - स्टैंडबाय मोड में स्वचालित फ़ाइल प्रबंधन मोड सेट करें। पैरामीटर के इस मान के साथ, मुख्य डेटाबेस द्वारा बनाई गई या हटा दी गई सभी फाइलें स्वचालित रूप से स्टैंडबाय डेटाबेस पर बनाई या हटा दी जाएंगी।

यदि हम अभी भी अपने स्टैंडबाय डेटाबेस को उन निर्देशिकाओं के अलावा रखना चाहते हैं जिनमें मुख्य डेटाबेस स्थित है, तो हमें अतिरिक्त मापदंडों की आवश्यकता होगी:

db_file_name_convert = '/ oradata_new / test', '/ oradata / test' - यह पैरामीटर इंगित करता है कि स्टैंडबाय डेटाबेस (यानी जब हमारा मुख्य उदाहरण स्टैंडबाई मोड में काम करना शुरू करता है) में बनाई जाने वाली डेटा फ़ाइलों के नामों में परिवर्तन करना आवश्यक है। '/ oradata_new / test' से '/ oradata / test' तक के पथ।
log_file_name_convert = '/ oradata_new / test / आर्काइव', '/ oradata / test / आर्काइव' - यह पैरामीटर इंगित करता है कि स्टैंडबाय डेटाबेस में बनाई जाने वाली लॉग फ़ाइलों के नामों में, आप 'oradata_new / परीक्षण / संग्रह' से पथ बदल सकते हैं। '/ oradata / परीक्षण / संग्रह'।

नतीजतन, मुख्य डेटाबेस के लिए पैरामीटर फ़ाइल, अन्य बातों के अलावा, निम्नलिखित प्रविष्टियां होनी चाहिए:

# PRIMARY STANDBY
db_name='test'
db_unique_name='testprod'
log_archive_config='dg_config=(testprod,teststan)'
log_archive_dest_1='SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name='teststan' log_archive_dest_2='LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=testprod'
log_archive_dest_state_1=ENABLE
log_archive_dest_state_2=ENABLE
# STANDBY
fal_client='testprod'
fal_server='teststan'
standby_file_management='AUTO'

यदि ऐसा कोई अवसर है, तो मुख्य डेटाबेस को नए मापदंडों के साथ पुनः आरंभ करें और हमारे द्वारा संसाधित किए गए pfile के आधार पर एक नया spfile बनाएं:

SQL> shutdown immediate;
SQL> startup nomount pfile='/data/backup/pfilePROD.ora';
SQL> create spfile from pfile='/data/backup/pfilePROD.ora';
SQL> shutdown immediate;
SQL> startup;

यदि हमारे पास हमारे जोड़तोड़ के दौरान मुख्य आधार को रोकने का अवसर नहीं है, तो हमें ALTER SYSTEM का उपयोग करके वर्तमान कॉन्फ़िगरेशन में परिवर्तन करना होगा।
यह ध्यान में रखा जाना चाहिए कि हम कार्यशील आधार पर db_unique_name नहीं बदल पाएंगे । इसलिए, हमें उस नाम का उपयोग करना होगा जो वर्तमान में कॉन्फ़िगरेशन में है। आप इसे कमांड का उपयोग करके देख सकते हैं:

SQL> show parameter db_unique_name
NAME TYPE VALUE
------------------------------------ ----------- --------------------------
db_unique_name string test

हम आवश्यक पैरामीटर सेट करते हैं:

SQL> alter system set log_archive_config='dg_config=(test,teststan)';
System altered.

हम संग्रहीत पत्रिकाओं की रिकॉर्डिंग के लिए स्थान निर्धारित करते हैं। कार्य आधार पर, हम log_archive_dest_1 पैरामीटर को समायोजित करने में सक्षम नहीं होंगे यदि यह सेट है। इसलिए, हम बस स्टैंडबाय डेटाबेस में कॉपी दिशा जोड़ते हैं:

SQL> alter system set log_archive_dest_2='SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=teststan';
System altered.

SQL> alter system set log_archive_dest_state_2=ENABLE;
System altered.

SQL> alter system set FAL_SERVER=teststan;
System altered.

SQL> alter system set FAL_CLIENT=test;
System altered.

SQL> alter system set standby_file_management='AUTO';
System altered.

स्टैंडबाय डेटाबेस के बारे में tnsnames.ora पर एक रिकॉर्ड जोड़ें:

TESTSTAN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = teststan)
)
)

यह बैकअप बनाने का समय है (यदि कोई नहीं हैं)। इसके लिए हम रमन उपयोगिता का उपयोग करेंगे।
यह आवश्यक है कि जिस स्थान पर बैकअप स्थित है, जहां से हम स्टैंडबाय बेस को तैनात करेंगे, ठीक उसी स्थान पर है जहां हमने इस बैकअप को सहेजा है। यानी अगर हम बैकअप को '/ data / backup' डायरेक्टरी में रखते हैं, तो स्टैंडबाय सर्वर पर डेटाबेस को रिस्टोर करते समय, rman उसी डाइरेक्टरी में बैकअप डेटा की तलाश करेगा। इस समस्या को हल करने के दो स्पष्ट तरीके हैं: बैकअप डेटा को मुख्य सर्वर से स्टैंडबाय में बनाए गए सटीक उसी निर्देशिका में कॉपी करें, या बैकअप के लिए एक नेटवर्क संसाधन का उपयोग करें जो दोनों सर्वरों पर समान रूप से माउंट किया गया हो।

मुख्य सर्वर पर रनमैन:
$ rman target /

केस के लिए एक दिलचस्प बिंदु जब ओरेकल लिनक्स पर स्थापित होता है। यदि आपने PolyglotMan पैकेज (RosettaMan) स्थापित किया है, तो जब आप चलाने का प्रयास करते हैं
$ rman target /
एक त्रुटि हो सकती है:
rman: can't open target
यह स्थिति तब होती है जब वातावरण चर में इस पैकेज (उदाहरण के लिए, / usr / X11R6 / bin / rman) के rman निष्पादन योग्य फ़ाइल का पथ $ PATH Oracle rman के पथ से पहले स्थित है। यानी हम PolyglotMan पैकेज से रमन को चलाने और इसके लिए एक पैरामीटर के रूप में लक्ष्य फ़ाइल को पास करने की कोशिश कर रहे हैं, जिसे यह स्वाभाविक रूप से नहीं खोल सकता है।

स्टैंडबाय डेटाबेस के लिए एक नियंत्रण फ़ाइल बनाएँ:

RMAN> backup current controlfile for standby format '/data/backup/standbycontrol.ctl';

हम अपने मुख्य डेटाबेस और संग्रह पत्रिकाओं का बैकअप बनाते हैं:

RMAN> run
2> {
3> allocate channel c1 device type disk format '/data/backup/%u';
4> backup database plus archivelog;
5> }

यहां, मुसीबत हमें इंतजार कर सकती है अगर किसी कारण से हमारे पास संग्रहीत पत्रिकाओं का पूरा सेट नहीं है (उदाहरण के लिए, उन्हें हटा दिया गया है)। फिर एक त्रुटि फेंक देंगे:

RMAN-20242: Specification does not match any archivelog in the recovery catalog

स्थिति को मापने के लिए, रमन रिपॉजिटरी में संग्रह लॉग की स्थिति को जांचना और बदलना आवश्यक है। ऐसा करने के लिए, निम्नलिखित कमांड चलाएँ:

RMAN> change archivelog all crosscheck;

यदि बैकअप सफल था, तो / डेटा / बैकअप / निर्देशिका की सामग्री को स्टैंडबाय सर्वर पर कॉपी करें (यदि हमने बैकअप के लिए नेटवर्क शेयर का उपयोग नहीं किया है) और स्टैंडबाय सर्वर पर उदाहरण बनाने के लिए आगे बढ़ें।

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

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /oracle)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = teststan)
(ORACLE_HOME = /oracle)
(SID_NAME = test)
)
)

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
)

यह ध्यान दिया जाना चाहिए कि इस मामले में पैरामीटर SID_NAME मामला संवेदनशील है, जैसा कि श्रोता एक पासवर्ड फ़ाइल की तलाश करेगा जिसका नाम orapw $ SID_NAME होगा।

वैसे, अब मुख्य सर्वर से स्टैंडबाय तक पासवर्ड फ़ाइल ($ ORACLE_HOME / dbs / orapw $ ORACLE_SID) को कॉपी करने का समय है।

हमें tnsnames.ora में अपने मुख्य और अतिरिक्त आधारों को भी पंजीकृत करना चाहिए:

TEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = teststan)
)
)

TESTPROD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = productionsrv)(PORT = 1521))
)
(CONNECT_DATA =
(SID = test)
)
)

क्योंकि यह समझा जाता है कि एप्लिकेशन नाम परीक्षण के तहत हमारे डेटाबेस को "जानते हैं", फिर स्टैंडबाय डेटाबेस के लिए हमने SID परीक्षण सेट किया।

श्रोता को पुनरारंभ करना न भूलें:

$ORACLE_HOME/bin/lsnrctl stop
$ORACLE_HOME/bin/lsnrctl start

अब हमारे डेटाबेस के लिए एक निर्देशिका संरचना बनाएं। यह भूलना महत्वपूर्ण नहीं है कि आपको डेटा और लॉग फ़ाइलों को संग्रहीत करने के लिए सभी निर्देशिकाओं को बनाने की आवश्यकता है, साथ ही साथ adump , bdump , cdump , dpdump , udump निर्देशिकाएं , आमतौर पर $ ORACLE_HIN / व्यवस्थापक / $ ORACLE_SID में स्थित होती हैं।
यदि आप मुख्य डेटाबेस की निर्देशिका संरचना को स्टैंडबाय पर सहेजना नहीं चाहते हैं, तो आपको db_file_name_convert और log_file_name_convert मापदंडों के मूल्यों के अनुसार निर्देशिका बनाने की आवश्यकता है।

हमें मुख्य डेटाबेस के मापदंडों के आधार पर स्टैंडबाय के लिए एक पैरामीटर फ़ाइल बनाने की भी आवश्यकता है। ऐसा करने के लिए, स्टैंडबाय सर्वर पर pfilePROD.ora फ़ाइल को फिर से लिखें , इसका नाम बदलकर pfileSTAN.ora करें , और उस हिस्से के लिए आवश्यक सुधार करें जो हमने पहले संपादित किया था:

# PRIMARY STANDBY
db_name='test'
db_unique_name='teststan'
log_archive_config='dg_config=(testprod,teststan)'
log_archive_dest_1='SERVICE=testprod LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name='testprod' log_archive_dest_2='LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=teststan'
log_archive_dest_state_1=ENABLE
log_archive_dest_state_2=ENABLE
# STANDBY
fal_client='teststan'
fal_server='testprod'
standby_file_management='AUTO'

स्टैंडबाय डेटाबेस को अन्य निर्देशिकाओं में रखने पर, हम आवश्यक पैरामीटर भी जोड़ते हैं:

db_file_name_convert='/oradata/test','/oradata_new/test'
log_file_name_convert='/oradata/test/archive','/oradata_new/test/archive'

स्टैंडबाय आधार उदाहरण शुरू करने का समय आ गया है:

SQL> startup nomount pfile='/data/backup/pfileSTAN.ora';
SQL> create spfile from pfile='/data/backup/pfileSTAN.ora';
SQL> shutdown immediate;
SQL> startup nomount;

बैकअप से स्टैंडबाय डेटाबेस का विस्तार करें। ऐसा करने के लिए, मुख्य सर्वर पर जाएं और रमन चलाएं ।

हम भविष्य के स्टैंडबाय डेटाबेस से जुड़ते हैं और दोहराव करते हैं (हमें याद है कि डेटा बैकअप और कंट्रोल फ़ाइल निर्देशिका में है, जो मुख्य सर्वर से और स्टैंडबाय के रूप में / डेटा / बैकअप के रूप में दिखाई देता है):

RMAN> connect auxiliary sys@teststan
RMAN> duplicate target database for standby nofilenamecheck dorecover;

हमें nofilenamecheck पैरामीटर की आवश्यकता है ताकि rman डुप्लिकेट फ़ाइल नामों पर शपथ न लें (यदि हम मुख्य और स्टैंडबाय सर्वर पर समान निर्देशिका संरचना का उपयोग करते हैं)।

यदि सबकुछ ठीक हो गया, तो हम सिस्टम को स्टैंडबाय आधार पर लेनदेन के स्वचालित अनुप्रयोग में स्थानांतरित कर देते हैं।

लॉग फ़ाइल को स्विच करें और मुख्य डेटाबेस पर संग्रह लॉग के अंतिम नंबर को देखें:

SQL> alter system switch logfile;
System altered.

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
205

अब स्टैंडबाय सर्वर पर जाएं।

डेटाबेस की स्थिति की जाँच करें:

SQL> select name,open_mode,log_mode from v$database;

NAME OPEN_MODE LOG_MODE
--------- ---------- ------------
TEST MOUNTED ARCHIVELOG
SQL> select recovery_mode from v$archive_dest_status;

RECOVERY_MODE
-----------------------
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE

11 rows selected.

SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)
--------------
202

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

स्टैंडबाय फिर से लॉग के लिए जाँच करें:

SQL> select * from v$standby_log;

यदि वे नहीं हैं, तो बनाएं:

SQL> alter database add standby logfile group 4 '/oradata/test/stnbylog01.log' size 50m;
Database altered.

SQL> alter database add standby logfile group 5 '/oradata/test/stnbylog02.log' size 50m;
Database altered.

SQL> alter database add standby logfile group 6 '/oradata/test/stnbylog03.log' size 50m;
Database altered.


हम अपने स्टैंडबाय बेस को रियल-टाइम अप्लाई रिड्यू मोड में ट्रांसफर करते हैं:

SQL> alter database recover managed standby database using current logfile disconnect;

हम देखते हैं कि क्या हुआ:

SQL> select recovery_mode from v$archive_dest_status;

RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY

11 rows selected.

SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)
--------------
205

जैसा कि आप देख सकते हैं, सब कुछ काम करता है।

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

SQL> alter database recover managed standby database disconnect;

यदि कुछ गलत हुआ, तो समस्या को हल करने के लिए, सबसे पहले, आपको लॉग के "रोलिंग" को रोकने की आवश्यकता है:

SQL> alter database recover managed standby database cancel;

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

SQL> recover standby database;

और उसके बाद वास्तविक समय फिर से लागू करें:

SQL> alter database recover managed standby database using current logfile disconnect;

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