agen piala dunia daftar poker poker domino poker online

Cara Mengonfigurasi Data Guard Menggunakan Database Siaga Fisik

Saya baru-baru ini memutuskan untuk menguji strategi rollback yang kami pikirkan untuk digunakan saat meningkatkan database kami ke Oracle 11g. Kami menggunakan Oracle 10g pada saat itu dan kami memiliki pengaturan data guard berikut:

  • DB Utama, 10.2.0.4
  • Siaga fisik DB 1, 10.2.0.4
  • Siaga fisik DB 2, 10.2.0.4

CATATAN: Sistem operasi yang kami jalankan adalah Windows Server 2003, SP2. Meskipun petunjuk ini untuk lingkungan Windows mereka juga akan bekerja pada lingkungan lain, satu-satunya perbedaan adalah beberapa konfigurasi khusus Windows, seperti pembuatan layanan Windows.

Rencana Untuk Meningkatkan Data Guard

Rencananya adalah untuk meng-upgrade kedua DB penjaga data ke 11g pada saat yang sama sebagai primer. Sebagai bagian dari peningkatan, kami perlu memiliki rencana kegagalan sehingga jika pemutakhiran gagal kami akan dapat mengembalikan basis data utama dan siaga kembali ke titik waktu sebelum pemutakhiran dilakukan. Kami tidak ingin membangun kembali database siaga jika pemutakhiran gagal karena itu akan sangat memakan waktu dan membutuhkan lebih banyak pekerjaan. Paket rollback database utama relatif mudah:

  • Matikan database
  • Ambil "snap" dari Luns di tingkat SAN
  • Bawa database dan jalankan di upgrade
  • Jatuhkan jepitkan jika peningkatan berhasil
  • Kembalikan ke snap jika pemutakhiran gagal

Pertanyaan awal?

Masalah yang kami hadapi dengan database siaga adalah bahwa kami tidak memiliki kemampuan untuk mem-snap disk di SAN yang mereka jalankan karena teknologi SAN lebih tua dan kami tidak memiliki lisensi untuk itu. Kami juga memiliki beberapa pertanyaan tentang konfigurasi data guard dan bagaimana cara kerjanya:

  • Jika kita mengembalikan DB primer, bagaimana kita mengembalikan DB siaga fisik jika mereka telah menerapkan log selama pemutakhiran?
  • Bisakah kita menghentikan DB siaga yang menerapkan log, mengembalikan DB primer ke versi snap dan mulai mengirim log lagi?
  • Apakah DB siaga fisik akan mengambil dari tempat yang ditinggalkannya jika kami menghapus log yang dibuat saat pemutakhiran berjalan?
  • Jika DB primer berada di urutan archivelog 100 pada saat snap dan itu menciptakan 50 log sepanjang proses upgrade dan kami snap kembali akan melanjutkan dari urutan 100 lagi?

Kami membuat dugaan terpelajar tentang apa yang kami pikirkan tetapi pertanyaan di atas seharusnya dapat memberi Anda beberapa gagasan tentang jenis pertanyaan yang kami tidak yakin sebelum kami menyelesaikan pengujian apa pun. Cara terbaik untuk membuktikan apa pun adalah benar-benar mengujinya sehingga saya mulai menguji teori kami. Apa teorinya? Yah, kami pikir (maksud saya berharap …) bahwa jika kami membatalkan pengiriman log saat peningkatan sedang berjalan (DEFER tujuan arsip log), gulung DB primer kembali ke versi sekejap dari disk, hapus semua log yang diproduksi saat pemutakhiran berjalan dan kemudian memungkinkan tujuan arsip log lagi bahwa data guard database fisik siaga akan mengambil dari tempat mereka tinggalkan, tidak ada yang bijak untuk gagal meng-upgrade pada database primer.

Apa yang akan kami uji

Berikut ini adalah daftar persis apa yang akan saya lalui dalam contoh di bawah ini:

  • Konfigurasi penjaga data pada versi 10.2.0.4 (meskipun ini akan berlaku untuk penjaga data 11g, juga)
  • Buat cadangan DB primer Anda dalam persiapan untuk memulihkannya untuk membuat database siaga fisik Anda
  • Proses pemulihan untuk mengatur database siaga fisik Anda
  • Cara mendapatkan pengiriman log bekerja dari basis utama ke database siaga
  • Mengkonfigurasi strategi rollback di atas
  • Simulasi upaya peningkatan gagal
  • Mengembalikan ke versi snap dari database (pada level SAN)
  • Tes untuk melihat apakah semuanya berfungsi sebagaimana mestinya sebelum peningkatan

Database SAN Vs Flashback – Tampilan Pribadi …

Saya harus menunjukkan bahwa untuk tes ini saya telah bekerja dengan tim penyimpanan untuk mendapatkan snapshot dari disk (s) sebelum pekerjaan upgrade selesai. Secara pribadi, saya menemukan bahwa ini adalah solusi yang jauh lebih baik untuk jenis pekerjaan ini daripada menggunakan teknologi flashback Oracle karena beberapa alasan:

  1. Flashback membutuhkan banyak ruang untuk menyimpan perubahan apa pun
  2. Saya mengalami masalah ketika menggunakan teknologi flashback Oracle saat melakukan upgrade yang merusak titik pemulihan terjamin saya. sangat buruk!
  3. Snapshot SAN sangat cepat, bersih dan tidak memerlukan perubahan konfigurasi dari sudut pandang Oracle – hanya shutdown bersih dari DB saat snapshot diambil

Jadi, dalam tes ini saya menunjukkan kepada Anda cara membuat DB siaga dari DB primer Anda dengan semua perintah yang perlu saya gunakan. Semoga semuanya sudah cukup jelas untuk DBA Oracle yang berpengetahuan luas. Jika tidak, silakan ajukan pertanyaan di bagian bawah halaman di bagian komentar atau kirim email dan saya akan melakukan yang terbaik untuk membantu.

Panduan Langkah demi Langkah untuk Membuat dan Mengonfigurasikan Data Guard Siaga Fisik

Pada DB primer Anda, mengecilkan ukuran DB sebanyak mungkin sehingga cadangan, salin, dan kembalikan ke database siaga lebih cepat. Saya sering menggunakan skrip kecil ini untuk melakukannya secara dinamis untuk tablespace tertentu. Ini akan mencoba untuk mengurangi setiap tablespace oleh 500MB, tetapi Anda dapat mengkonfigurasi itu untuk apa pun yang Anda inginkan dan melakukannya untuk setiap tablespace dengan menghapus bagian "where tablespace_name =" dari pernyataan.

</p><p>spool shrink.out<br /> atur serverout aktif<br /> mulai<br /> untuk saya di (pilih &#39;ubah database datafile&#39; || file_id || &#39;ubah ukuran&#39; || TRUNC (byte &#8211; 512000000) || &#39;;&#39;<br /> sebagai cmd dari dba_data_files di mana tablespace_name = &#39;DW3_L1_X128K&#39;) lingkaran<br /> dbms_output.put_line (i.cmd);<br /> lingkaran akhir;<br /> akhir;<br /> /</p><p>spool off</p><p>@ shrink.out</p><p>

RMAN Level0 dan Mode Log Arsip

Tahap pertama adalah mengambil backup level 0 RMAN yang akan Anda gunakan nanti untuk memulihkan dan membuat database siaga fisik Anda. Saya berasumsi bahwa Anda tidak ingin mengambil database untuk menyelesaikan cadangan jadi semoga database Anda sudah berjalan dalam mode ARCHIVELOG? Anda dapat memeriksa dengan kueri ini:

</p><p>Pilih log_mode<br /> DARI v $ database;</p><p>

Jika basis data primer Anda tidak dalam mode ARCHIVELOG Anda dapat mengambil cadangan dingin, yaitu saat database sedang down, atau memasukkannya ke database dalam mode ARCHIVELOG. Untuk melakukan ini, konfigurasikan parameter log_archive_dest_1 Anda dan aktifkan sebagai berikut:

</p><p>ALTER SYSTEM SET log_archive_dest_1 = &#39;LOCATION = D: TEMP TESTDB ARCHLOGS&#39; SCOPE = SPFILE;</p><p>SHUTDOWN SEGERA<br /> STARTUP GUNUNG<br /> ALTER DATABASE ARCHIVELOG;<br /> ALTER DATABASE OPEN;<br /> ALTER SYSTEM SWITCH LOGFILE;</p><p>

Sekarang periksa bahwa log pengarsipan arsip muncul di lokasi yang ditentukan oleh parameter log_archive_dest_1.

Paksa Pencatatan Basis Data

Jika Anda membuat database siaga fisik adalah persyaratan bahwa untuk tidak ada transaksi yang belum terinstal dalam database Anda, seperti pemuatan jalur langsung dan transaksi yang tidak menghasilkan REDO karena database Anda adalah salinan fisik yang sama dari yang utama maka semua transaksi harus diterapkan dalam urutan yang benar. Untuk menegakkan ini, Anda perlu menjalankan perintah berikut:

</p><p>ALTER DATABASE FORCE LOGGING;</p><p>

Oke, jadi sekarang kami aktif dan berjalan dalam mode ARCHIVELOG dan kami selalu mencatat semua transaksi dalam aliran REDO, kami dapat mengambil cadangan level 0 menggunakan perintah berikut:

</p><p>target rman sys /<pwd>@<SID><br /> menjalankan<br /> {<br /> backup sebagai tingkat inkompemental backupset terkompresi = 0 database ditambah archivelog;<br /> }</p><p>

Lamanya waktu pencadangan akan bergantung pada ukuran basis data Anda. Jika Anda menggunakan tingkat kompresi normal untuk RMAN, cadangan Anda akan menjadi sekitar 20% dari ukuran basis data Anda.

Setelah level 0 cadangan selesai Anda perlu menyalin file ke host siaga siap untuk memulihkan untuk membuat database siaga fisik.

Konfigurasi Parameter Inisialisasi

Sebelum melakukan pemulihan database siaga fisik kita perlu mengkonfigurasi beberapa parameter tambahan pada database utama untuk penjaga data untuk bertindak sebagai database utama ketika dalam konfigurasi penjaga data. Saya telah membuat daftar di bawah parameter yang perlu saya ubah untuk mengkonfigurasi DB primer untuk Data Guard:

CATATAN: Saya juga mengkonfigurasikan beberapa parameter yang hanya diperlukan jika database primer menjadi database siaga, dengan kata lain jika skenario failover atau peralihan akan terjadi.

CATATAN: Dalam contoh di bawah ini TEST adalah DB primer dan TESTDG adalah basis data siaga fisik

CATATAN: Lokasi file untuk database Data Guard hanya akan berbeda dengan nama DB. Misalnya, jalur 'D: ORADATA TEST ' akan menjadi 'D: ORADATA TESTDG '.

</p><p>alter system set log_archive_config = &#39;DG_CONFIG = (TEST, TESTDG)&#39; scope = keduanya;<br /> &#8211; Ini menunjukkan bahwa ada dua database dalam konfigurasi Data Guard</p><p>alter system set LOG_ARCHIVE_DEST_STATE_1 = ENABLE scope = keduanya;<br /> &#8211; Mengaktifkan tujuan log arsip pertama</p><p>alter system set log_archive_dest_2 = &#39;SERVICE = TESTDG ASYNC VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE)<br /> DB_UNIQUE_NAME = lingkup TESTDG &#39;= keduanya;</p><p>&#8211; mengonfigurasi pengiriman log REDO yang diarsipkan sementara database berjalan dalam peran utama ke Data Guard DB (TESTDG)</p><p>alter system set LOG_ARCHIVE_DEST_STATE_2 = cakupan DEFER = keduanya;<br /> &#8211; Mengaktifkan tujuan log arsip kedua</p><p>alter system set remote_login_passwordfile = Cakupan EKSKLUSIF = spfile;<br /> &#8211; Nilai ini harus sama pada kedua basis data agar log dapat dikirimkan</p><p>ubah sistem set LOG_ARCHIVE_FORMAT =% t_% s_% r.arc scope = keduanya;<br /> &#8211; Mengonfigurasi format untuk nama log redo yang diarsipkan</p><p>alter system set LOG_ARCHIVE_MAX_PROCESSES = 4 scope = keduanya;<br /> &#8211; Ini adalah jumlah maksimum proses yang dapat mengirim log.<br /> Menambahkan lebih banyak dapat meningkatkan penggunaan CPU jika ada sejumlah besar log untuk dikirimkan</p><p>alter system set FAL_SERVER = TESTDG scope = keduanya;<br /> &#8211; Menetapkan server Log Arsip Ambil sebagai TESTDG, basis data siaga<br /> &#8211; Hanya diperlukan ketika primary switch untuk standby</p><p>ubah sistem set DB_FILE_NAME_CONVERT = &#39;TESTDG&#39;, &#39;TEST&#39; scope = spfile;<br /> &#8211; Ini mengkonversi semua jalur file data di mana ada TESTDG dalam nama dan menggantikannya dengan TEST<br /> &#8211; Hanya diperlukan ketika primary switch untuk standby</p><p>alter system set LOG_FILE_NAME_CONVERT = &#39;TESTDG&#39;, &#39;TEST&#39; scope = spfile;<br /> &#8211; Ini mengkonversi semua path file log di mana ada TESTDG dalam nama dan menggantikannya dengan TEST<br /> &#8211; Hanya diperlukan ketika primary switch untuk standby</p><p>alter system set STANDBY_FILE_MANAGEMENT = AUTO scope = keduanya;<br /> &#8211; Memastikan bahwa ketika file ditambahkan dan dihapus bahwa mereka juga ditambahkan dan dihapus dari database Data Guard</p><p>

Kontrol File dan PFILE Creation

Sekarang bahwa parameter inisialisasi telah dikonfigurasi pada database primer saatnya untuk membuat file kontrol siaga dan file parameter database Data Guard.

</p><p>ALTER DATABASE CREATE STANDBY CONTROLFILE SEBAGAI &#39;C: temp TEST.ctl&#39;;</p><p>CREATE PFILE = &#39;C: temp initTEST.ora&#39; DARI SPFILE = &#39;G: Oracle oradata TEST admin pfile spfileTEST.ora;</p><p>&#8211; Buat file parameter untuk DB siaga</p><p>&#8211; Saya selalu secara eksplisit menentukan di mana lokasi PFILE dan SPFILE untuk menghindari masalah di mana file yang salah digunakan</p><p>&#8211; Salin file ini bersama dengan file kontrol siaga ke server Data Guard DB siap untuk mengembalikan</p><p>

Anda sekarang harus mengambil file parameter initTEST.ora dan mengubah pengaturan sehingga dapat digunakan untuk database siaga fisik.

</p><p>DB_NAME = TEST<br /> &#8211; DB_NAME tetap sama dengan DB primer, saya hanya ingin menunjukkannya kepada Anda di sini</p><p>DB_UNIQUE_NAME = TESTDG<br /> &#8211; Ubah ini untuk mencerminkan nama database Data Guard Anda, saya menggunakan TESTDG di sini</p><p>CONTROL_FILES = &#39;D: ORADATA TESTDG CONTROL01.CTL&#39;, &#39;D: ORADATA TESTDG CONTROL02.CTL&#39;, &#39;D: ORADATA TESTDG CONTROL03.CTL&#39;<br /> &#8211; Setidaknya harus dua dari ini, saya menggunakan tiga, dan satu-satunya perbedaan di jalur adalah bahwa saya telah mengubah TEST menjadi TESTDG</p><p>DB_FILE_NAME_CONVERT = &#39;TEST&#39;, &#39;TESTDG&#39;<br /> &#8211; Konfigurasi yang sama seperti sebelumnya, tetapi yang ini mengubah nama file data primer menjadi nama Data Guard</p><p>LOG_FILE_NAME_CONVERT = &#39;TEST&#39;, &#39;TESTDG&#39;<br /> &#8211; Seperti sebelumnya, nama file log di jalur diubah untuk mencerminkan lokasinya di disk</p><p>LOG_ARCHIVE_DEST_1 = &#39;LOCATION = O: flash_recover_TEST ArchLogs VALID_FOR = (ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME = TESTDG&#39;<br /> &#8211; Di sinilah log REDO yang diarsipkan akan ditempatkan saat dalam posisi siaga dan utama</p><p>LOG_ARCHIVE_DEST_2 = &#39;SERVICE = TEST ASYNC VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME = TEST&#39;<br /> &#8211; Ini menentukan parameter yang digunakan untuk saat database berjalan dalam peran utama<br /> &#8211; Hanya diperlukan ketika siaga beralih ke utama</p><p>LOG_ARCHIVE_DEST_STATE_1 = AKTIFKAN<br /> LOG_ARCHIVE_DEST_STATE_2 = AKTIFKAN<br /> &#8211; Pastikan bahwa kedua tujuan pengarsipan di-ENABLED</p><p>FAL_SERVER = TEST<br /> &#8211; Ini menunjuk ke nama database Primer</p><p>

OK, jadi kami telah mengonfigurasi semua parameter inisialisasi untuk database siaga utama dan fisik, dan kami telah menambahkan parameter yang sesuai jika kami memutuskan untuk gagal atau mengganti peran utama dan siaga dalam konfigurasi Data Guard.

Layanan Windows, Pendengar, TNSNames, dll

Langkah selanjutnya adalah mengkonfigurasi layanan Windows di server, pendengar, TNSNames file, file kata sandi dan membuat SPFILE untuk database siaga. Mari kita lihat bagaimana kita akan melakukannya.

1. Tambahkan entri TNSNames ke klien Oracle yang ada di server basis data primer dan siaga

Mengikuti penggunaan nama database TEST dan TESTDG seperti yang telah kami lakukan di bagian awal artikel ini, berikut adalah entri TNSNames untuk DB tersebut:

</p><p>TEST.DEV.INT.COM =<br /> (DESCRIPTION =<br /> (ADDRESS_LIST =<br /> (ADDRESS = (PROTOCOL = TCP) (Host = TESTlistener) (Port = 1521))<br /> )<br /> (CONNECT_DATA =<br /> (SERVICE_NAME = TEST.DEV.INT.COM)<br /> (SERVER = DEDICATED)<br /> )<br /> )</p><p>TESTDG.DEV.INT.COM =<br /> (DESCRIPTION =<br /> (ADDRESS_LIST =<br /> (ADDRESS = (PROTOCOL = TCP) (Host = TESTDGListener) (Port = 1521))<br /> )<br /> (CONNECT_DATA =<br /> (SERVICE_NAME = TESTDG.DEV.INTCOM)<br /> (SERVER = DEDICATED)<br /> )<br /> )</p><p>

CATATAN: Saya menggunakan entri DNS untuk parameter HOST. Jika Anda menggunakan DNS, pastikan bahwa nama DNS diselesaikan dengan benar menggunakan perintah NSLOOKUP dari kedua server.

CATATAN: Anda harus memastikan bahwa lalu lintas SQLNet diizinkan di kedua arah sehingga pengiriman log dapat dilakukan.

2. Tambahkan entri pendengar ke server Data Guard DB dan server DB primer

Anda dapat membuat pendengar baru jika Anda belum menginstalnya atau hanya menambahkan konfigurasi ke yang sudah Anda instal, terserah Anda. Ini adalah entri yang saya miliki untuk TEST dan TESTDG DB:

</p><p>&#8211; Konfigurasi Pemelihara Data Guard</p><p>11GDGLIST =<br /> (DESCRIPTION_LIST =<br /> (DESCRIPTION =<br /> (ADDRESS = (PROTOCOL = TCP) (HOST = 10.63.41.57) (PORT = 1521))<br /> )<br /> )</p><p>SID_LIST_11GDGLIST =<br /> (SID_LIST =<br /> (SID_DESC =<br /> (GLOBAL_DBNAME = TESTDG.DEV.INT.COM)<br /> (ORACLE_HOME = D: oracle product.2.0 dbhome_11203)<br /> (SID_NAME = TEST)<br /> )<br /> )</p><p>&#8211; Konfigurasi Pendengar DB Utama<br /> 11GLIST =<br /> (DESCRIPTION_LIST =<br /> (DESCRIPTION =<br /> (ADDRESS = (PROTOCOL = TCP) (HOST = 10.60.41.57) (PORT = 1521))<br /> )<br /> )</p><p>SID_LIST_11GLIST =<br /> (SID_LIST =<br /> (SID_DESC =<br /> (GLOBAL_DBNAME = TEST.DEV.INT.COM)<br /> (ORACLE_HOME = D: oracle product.2.0 dbhome_11203)<br /> (SID_NAME = TEST)<br /> )<br /> )</p><p>

CATATAN: Mudah-mudahan Anda akan menyadari bahwa dalam konfigurasi untuk pendengar Data Guard, SID_NAME = TEST dan bukan TESTDG. Ini karena jika Anda mengingat DB_NAME yang sebenarnya sama dengan yang utama (TEST) tetapi DB_UNIQUE_NAME adalah TESTDG.

3. Buat Layanan Windows pada Server DB Data Guard

Kami akan menggunakan utilitas ORADIM untuk membuat layanan Windows di server Data Guard DB

</p><p>D: oracle product.2.0 dbhome_11203 oradim &#8211; BARU -SID TESTDG -STARTMODE m</p><p>

CATATAN: Saya menetapkan path lengkap ke utilitas oradim karena server multi-homed dan saya ingin menghindari potensi kebingungan yang dapat dieksekusi. Itu selalu paling aman untuk secara eksplisit menentukan yang dapat dieksekusi / file / etc yang ingin Anda gunakan. Kemudian Anda tahu persis apa yang akan Anda dapatkan.

CATATAN: Anda dapat mengubah pengaturan untuk layanan Windows ini kapan saja dengan membuka pengaturan registri (start-> run-> regedit HKEY_LOCAL_MACHINE-> software-> Oracle-> your_oracle_home_name)

4. Buat File Sandi untuk Data Guard DB

D: oracle product 11.2.0 dbhome_11203 orapwd file = 'D: ORADATA TESTDG pwdTEST.ora' kata sandi = change_on_install

5. Buat SPFILE untuk Database Data Guard

</p><p>SET ORACLE_SID = TEST<br /> SQLPLUS &quot;sys / change_on_install sebagai sysdba&quot;<br /> STARTUP NOMOUNT PFILE = &#39;D: ORADATA TESTDG ADMIN PFILE initTEST.ora&#39;<br /> BUAT SPFILE = &#39;D: ORADATA TESTDG ADMIN PFILE SPFILETEST.ora&#39; DARI PFILE = &#39;D: ORADATA TESTDG ADMIN PFILE initTEST.ora&#39;</p><p>

Hampir di sana … Kami membuat kemajuan yang baik sejauh ini. Kami telah melakukan banyak konfigurasi, sekarang saatnya untuk mengetahui apakah itu benar! Tahap selanjutnya adalah memulihkan backup levelan RMAN yang diambil dari database utama dan disalin.

</p><p>SET NLS_DATE_FORMAT = YYYY-MM-DD: HH24: MI: SS</p><p>RMAN TARGET sys / change_on_install @ TESTDG</p><p>ALTER DATABASE MOUNT; &#8211; Ingat bahwa Anda sudah menamai database</p><p>KATALOG MULAI DENGAN &#39;O: Oracle flash_recover_TESTDG flashback TEST BACKUPSET12_05_29&#39;;<br /> &#8211; Katalog file level RMAN 0 sehingga database menyadari keberadaan file</p><p>PILIH &#39;set newname untuk datafile&#39; &#39;&#39; || file_name || &#39;&#39; &#39;to&#39; &#39;&#39; || ganti (file_name, &#39;TEST&#39;, &#39;TESTDG&#39;) || &#39;&#39; &#39;;&#39;<br /> sebagai datafile dari dba_data_files;<br /> &#8211; Perintah yang digunakan untuk mendapatkan nama file untuk switch / set operasi newname<br /> &#8211; Untuk dijalankan terhadap basis data primer dan digunakan dalam blok RUN di bawah ini</p><p>menjalankan<br /> {<br /> ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT &#39;O: Oracle flash_recover_TEST flashback TEST BACKUPSET12_05_29 &#39;;<br /> ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT &#39;O: Oracle flash_recover_TEST flashback TEST BACKUPSET12_05_29 &#39;;<br /> set newname untuk datafile &#39;D: ORADATA TEST DATA SYSTEM01.DBF&#39; menjadi &#39;D: ORADATA TESTDG DATA SYSTEM01.DBF&#39;;<br /> set newname untuk datafile &#39;D: ORADATA TEST DATA UNDOTBS01.DBF&#39; menjadi &#39;D: ORADATA TESTDG DATA UNDOTBS01.DBF&#39;;<br /> set newname untuk datafile &#39;D: ORADATA TEST DATA SYSAUX01.DBF&#39; menjadi &#39;D: ORADATA TESTDG DATA SYSAUX01.DBF&#39;;<br /> set newname untuk datafile &#39;D: ORADATA TEST DATA USERS01.DBF&#39; menjadi &#39;D: ORADATA TESTDG DATA USERS01.DBF&#39;;<br /> KEMBALIKAN DATABASE DARI TAG &#39;TAG20120529T110507&#39;;<br /> DATABASE PEMULIHAN;<br /> DATA DATA SWITCH SEMUA;<br /> }</p><p>&#8211; Blok RUN ini mengalokasikan dua saluran untuk digunakan untuk memulihkan dan memulihkan operasi.<br /> Anda dapat menggunakan lebih banyak saluran jika Anda memiliki lebih banyak tenaga kuda!<br /> &#8211; Perintah &quot;set newname&quot; berasal dari skrip SQL dinamis sebelumnya. Salin dan tempel<br /> &#8211; Perintah RESTORE menentukan TAG untuk backup level0 RMAN<br /> &#8211; Perintah kemudian RESTORE database dan SWITCH semua nama file data sesuai dengan perintah nama baru</p><p>

Itu dia! Diperlukan waktu untuk memulihkan file data. Semakin besar DB semakin besar waktu pengembaliannya.

Sekarang saatnya untuk memastikan DB primer diaktifkan untuk mengirim log REDO:

</p><p>ALTER SYSTEM SET log_archive_dest_state_2 = ENABLE SCOPE = keduanya;<br /> &#8211; Pada DB Utama</p><p>ALTER DATABASE RECOVER MANAGED DATABASE DISCONNECT DARI SESI;<br /> &#8211; Pada Standby DB</p><p>

Semoga Anda telah mengonfigurasi semuanya dengan benar dan itu akan bekerja pertama kali … Bagi sebagian besar dari mereka yang belum, berikut beberapa saran untuk membantu Anda:

Kemungkinan Masalah Konfigurasi Garda Data

</p><p>Kesalahan 1017 menerima masuk ke siaga<br /> &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8211; &#8212;&#8212;&#8212;-<br /> Periksa bahwa primer dan siaga menggunakan file kata sandi<br /> dan remote_login_passwordfile diatur ke SHARED atau EKSKLUSIF,<br /> dan bahwa kata sandi SYS sama dalam file kata sandi.<br /> mengembalikan kesalahan ORA-16191<br /> &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8211; &#8212;&#8212;&#8212;-</p><p>

Pastikan Anda telah melakukan hal-hal berikut:

1. Menambahkan entri TNS di kedua DB primer dan siaga. Jika Anda memiliki banyak rumah, pastikan Anda telah mengubah yang benar

2. Periksa bahwa entri telah ditambahkan untuk pendengar di kedua server DB

3. Periksa SQL Plus log on dari primary DB to standby dan sebaliknya

4. Salin file kata sandi dari utama dan gunakan untuk DB siaga

5. Periksa konektivitas jaringan ke host siaga pada port yang benar (1521 secara default)

Sekarang kita harus memiliki database Data Guard dikonfigurasi dan senang bahwa log pengiriman dari primer ke database siaga – periksa ini terlebih dahulu dengan beralih log pada primer beberapa kali. Anda dapat memeriksa apakah log diterapkan ke siaga fisik menggunakan kueri ini:

</p><p>mengatur garis 120<br /> mengatur halaman 1000<br /> mengubah sesi set nls_date_format = &#39;DD-MM-YYYY HH24: MI: SS&#39;;</p><p>PILIH SEQUENCE #, DITERAPKAN, FIRST_TIME, NEXT_TIME<br /> DARI V $ ARCHIVED_LOG<br /> DI MANA FIRST_TIME&gt; SYSDATE -3<br /> ORDER BY SEQUENCE #;</p><p>

Tahap selanjutnya dari percobaan adalah mengambil foto, mensimulasikan upgrade yang gagal dan kemudian menguji rollback. Itulah yang akan saya jalani sekarang.

Pengujian Rollback Menggunakan Snaps

1. Ganti logfile di primary

ALTER SYSTEM SWITCH LOGFILE;

2. Pastikan diterapkan ke standby

</p><p>mengatur garis 120<br /> mengatur halaman 1000<br /> mengubah sesi set nls_date_format = &#39;DD-MM-YYYY HH24: MI: SS&#39;;</p><p><xmp></p><p>PILIH SEQUENCE #, DITERAPKAN, FIRST_TIME, NEXT_TIME<br /> DARI V $ ARCHIVED_LOG<br /> DI MANA FIRST_TIME&gt; SYSDATE -3<br /> ORDER BY SEQUENCE #;</p><p>3. Tunda archivelog 2 dest</p><p>ALTER SYSTEM SET log_archive_dest_state_2 = DEFER SCOPE = keduanya;</p><p>4. Matikan DB primer</p><p>SHUTDOWN SEGERA;</p><p>5. Jepret drive DB primer (s)</p><p>Mintalah insinyur penyimpanan untuk melakukan ini</p><p>6. Bawa DB primer ke atas</p><p>MEMULAI</p><p>7. Jalankan dalam beberapa contoh skrip / pekerjaan DB. Ini bisa menjadi apa pun tetapi saya menggunakan contoh sederhana di sini hanya untuk menaruh beberapa<br /> tindakan melalui database.</p><p><xmp></p><p>buat tabel rj_test (<br /> ID NUMBER (10),<br /> NAME VARCHAR2 (25));</p><p>mulai<br /> untuk saya di loop 1..100000<br /> masukkan ke nilai rj_test (1, &#39;Rob&#39;);<br /> lingkaran akhir;<br /> akhir;<br /> /</p><p>

MELAKUKAN;

8. Shutdown DB (rollback palsu diperlukan)

SHUTDOWN SEGERA

9. Kembalikan kembali ke drive yang dibentak

Mintalah teknisi penyimpanan untuk kembali ke snap drive

*** Hapus semua archivelog yang dibuat saat ini ***

Jika Anda tidak melakukan ini, mungkin ada semacam konflik ketika database mencoba untuk membuat archivelog lain dengan nama yang sama. Juga, Anda tidak ingin pengarsipan pengarsipan log yang diarsipkan ke database siaga Anda, jadi pindahkan / hapus untuk berada di sisi aman.

10. Bawa database ke atas

MEMULAI

11. AKTIFKAN archivelog 2 dest

</p><p>ALTER SYSTEM SET log_archive_dest_state_2 = ENABLE SCOPE = keduanya;</p><p>

12. Aktifkan kembali pengiriman archivelog dengan menjalankan perintah ini pada database Data Guard

ALTER DATABASE RECOVER MANAGED DATABASE DISCONNECT DARI SESI;

13. Periksa archivelogs adalah pengiriman dan berlaku untuk DB siaga

</p><p>mengatur garis 120<br /> mengatur halaman 1000</p><p>mengubah sesi set nls_date_format = &#39;DD-MM-YYYY HH24: MI: SS&#39;;</p><p>PILIH SEQUENCE #, DITERAPKAN, FIRST_TIME, NEXT_TIME<br /> DARI V $ ARCHIVED_LOG<br /> DI MANA FIRST_TIME&gt; SYSDATE -3<br /> ORDER BY SEQUENCE #;</p><p>

Sekarang Anda telah menyelesaikan semua langkah-langkah ini semestinya Anda dapat melihat bahwa log pengarsipan arsip dikirim sekali lagi ke database siaga fisik data guard Anda. Dan, yang paling penting, tes ini telah menegaskan bahwa teori saya benar dan Anda dapat menggunakan snaps untuk mengembalikan pembaruan yang gagal pada basis data primer dan memungkinkan database siaga fisik untuk melanjutkan pemulihan dari tempat mereka tinggalkan sebelum peningkatan.

Saya harus menunjukkan di sini bahwa itu juga mungkin jika Anda ingin menjalankan upgrade berjalan lama ke database utama Anda dan tidak menghentikan pengiriman log yang Anda bisa mengambil buncis dari disk pada database siaga fisik pada saat yang sama. Melakukannya dengan cara ini berarti Anda harus mengembalikan database Data Guard jika upgrade gagal tetapi jika itu berhasil, maka ini sudah diperbarui dengan yang utama sehingga tidak perlu mengikuti log REDO.

Pilihan apa yang Anda putuskan untuk diambil terserah Anda dan akan tergantung pada persyaratan khusus Anda dan apa yang Anda anggap dapat diterima dan diperlukan.

Leave a Reply

Your email address will not be published. Required fields are marked *