Instance_Number is busy Message during Standby Instance Startup - Funkysst.com

Thursday, February 1, 2018

Instance_Number is busy Message during Standby Instance Startup

Avertisement
Avertisement
Baru saja saya mengalami situasi yang menunjukkan bagaimana, dalam sebuah database Oracle, kesalahan mungkin berasal dari penyebab yang sangat tidak berhubungan. Sebuah DBA sedang membangun database siaga fisik untuk pelatihan upcominmg. Dua server ia menggunakan bagian dari cluster RAC; sehingga binari Oracle sudah berada di sana. Dia memutuskan untuk menggunakan oracle sama untuk database baru juga - keputusan yang cukup logis untuk savbe pada isu-isu ruang dan administrasi. Dia menciptakan sebuah database utama pada server n1 dan database siaga pada n2 Server. Follooing prosedur pengguna biasa dalam membangun database siaga, ia menyalin pfile dari database utama, memodifikasi parameter dan dibesarkan contoh siaga dalam mode nomount pada n2 Server.






SQL> startup nomount pfile = initSTBY.ora

Tapi itu menolak untuk datang, dengan error berikut:

ORA-00.304: diminta INSTANCE_NUMBER sibuk

log peringatan menunjukkan:

PENGGUNA (ospid: 14.210): mengakhiri contoh karena kesalahan 304
Misalnya diakhiri oleh USER, pid = 14.210

Ini sangat tidak biasa. Primer dan standby keduanya non-RAC; tidak ada konsep jumlah contoh dalam database non-RAC. By the way, RAC contoh pada server (atau pada n1 server) tidak berjalan; jadi tidak ada pertanyaan tentang konflik dengan contoh RAC baik. Database utama disebut PRIM sementara siaga itu disebut STBY - menghilangkan kemungkinan bentrokan nama contoh juga. Dan kesalahan ini datang ketika hanya mencoba untuk memulai contoh, bahkan saat mounting - menghilangkan controlfile siaga sebagai penyebab.

Kesalahan 304 menunjukkan:

00.304, 00.000, "diminta INSTANCE_NUMBER sibuk"
// * Penyebab: Sebuah contoh mencoba untuk memulai dengan menggunakan nilai
// parameter inisialisasi INSTANCE_NUMBER yang sudah digunakan.
// * Aksi: Entah
// a) tentukan INSTANCE_NUMBER lain,
// b) menutup contoh berjalan dengan nomor ini
// c) menunggu pemulihan misalnya untuk menyelesaikan pada contoh dengan
// nomor ini.

Tak perlu dikatakan, menjadi untuk database non-RAC tidak ada "instance_number" parameter dalam inisialisasi file parameter primer atau standby. Jadi, saran untuk resolusi tampak aneh. MetaLink yang disediakan tidak ada bantuan. Semua ORA-304 kesalahan yang terkait dengan RAC dengan ketidakcocokan instance_number.

Seperti yang selalu terjadi, itu jatuh di pangkuan saya saat ini. Dengan hanya beberapa hari untuk pergi hidup, saya harus menemukan solusi cepat. berjam-jam pemecahan masalah, menelusuri proses dan pemeriksaan jejak file sesekali tidak menghasilkan petunjuk apapun. Semua petunjuk tampaknya menunjuk ke RAC, yang database ini tidak. Oracle Rumah adalah rumah RAC, yang berarti biner oracle dikaitkan dengan "rac" pilihan.

Jadi, langkah logis selanjutnya adalah untuk menginstal Oracle Rumah baru tanpa pilihan rac. Setelah melakukannya, saya mencoba untuk membuka contoh, menggunakan oracle baru dan variabel LD_LIBRARY_PATH; tapi, sayangnya, kesalahan yang sama muncul.

Hanya untuk menghilangkan kemungkinan beberapa bug yang tidak diketahui, saya memutuskan untuk menempatkan parameter instance_number, pengaturan untuk "1", dari default "0". Kesalahan yang sama. Aku berubah ke "2", sekali lagi, hasilnya adalah kesalahan yang sama.

Meskipun ini tidak membantu, setidaknya itu memberi petunjuk bahwa kesalahan tidak terkait dengan instance_number. Pesan kesalahan itu jelas salah. Dengan pemikiran ini, saya kembali ke dasar-dasar. Aku pergi melalui log peringatan dengan baik bergigi sisir, scanning dan menganalisis setiap baris.

Baris berikut menarik perhatian saya:

DB_UNQIUE_NAME STBY tidak dalam konfigurasi Data Guard

Ini adalah aneh; yang STBY db_unique_name tidak didefinisikan dalam konfigurasi DG. [BTW, perhatikan ejaan "unik" dalam pesan di atas. Itu bukan apa yang saya ketik; itu copy dan paste dari pesan yang sebenarnya di log peringatan. Seseorang dalam Pembangunan Oracle harus benar-benar membayar atytention untuk kesalahan ketik dalam pesan. Ini jelas lebih dari gangguan; bagaimana jika beberapa scan proses kesalahan db_unique_name terkait? Ini tidak akan menemukan pesan sama sekali!]

Memeriksa konfigurasi dg, saya menemukan bahwa DBA telah benar mendefinisikan nama primer dan standby. Dalam kasus apapun, Data Guard belum dimulai belum; ini hanya pada contoh startup - mengapa mengeluh untuk konfigurasi penjaga data pada saat ini.

Bingung, saya terpaksa pendekatan yang berbeda. Aku berganti nama menjadi pfile dan semua file terkait lainnya. Lalu aku dibangun standby sendiri, dari awal - menggunakan nama yang sama - PRIM dan STBY. Dan kali ini, semuanya bekerja dengan baik. Contoh STBY tidak datang.

Sementara ini solvbed masalah urgensi, semua orang, inclduing sendiri, ingin tahu apa masalah itu dalam kasus sebelumnya di mana DBA telah gagal untuk membawa contoh. Untuk mendapatkan jawabannya, saya membandingkan file yang saya buat dengan DBA dibuat ketika mencoba dan gagal. Voila! Penyebabnya adalah segera jelas - DBA lupa untuk menempatkan parameter penting dalam pfile dari contoh siaga:

db_unique_name = 'STBY'

Parameter ini tidak hadir; jadi butuh nilai default sebagai DB_NAME, yang "PRIM". Hal ini menyebabkan misalnya gagal dengan pesan yang tampaknya tidak berhubungan - "ORA-304 Instance_number sibuk"!

belajar Poin
  1. Dalam Oracle, sebagian besar kesalahan yang jelas; tapi ada juga yang tidak. Jadi, jangan menganggap pesan kesalahan akurat. Jika semua logika gagal, menganggap messsage kesalahan yang salah, atau setidaknya tidak akurat.
  2. Alih-alih over-menganalisis proses sudah diikuti, mungkin masuk akal untuk mengambil nafas, menghapus segala sesuatu dan mulai fropm awal. Ini evben mor efektif ketika orang lain melakukannya, menawarkan pendekatan yang segar dan mungkin tidak mengulangi kesalahan yang sama.
  3. Akhirnya, masalah di tangan: jika Anda tidak mendefinisikan db_unique_name parameter dalam contoh standnby, Anda akan menerima ORA-304 selama misalnya startup.

Semoga ini membantu. Selamat Tahun Baru semuanya.
Avertisement
Comments


EmoticonEmoticon