Bozuk veya kayıp arşiv log dosyası sonrası standby veritabanını geri kurtarma

Fiziksel standby veritabanı, primary veritabanından kendisine arşivlenmiş logların sürekli uygulanması ve bu senkronizasyonun sürekli devam etmesi esasına dayanmaktadır. Oracle 10g öncesinde arşivlenmiş loglardan birinin kaybolması veya bozulması durumunda standby veritabanının yeniden inşa edilmesi gerekmekteydi.

Ancak, Oracle 10g sürümünden itibaren kayıp veya bozulmuş arşiv loglarla karşılaşıldığında artalan yedekten standby veritabanını geri kurtarabilmekteyiz.

Aşağıdaki senaryoda uygulanacağı üzere standby veritabanına senkronize edilmesi gereken 234 ve 235 sıra numaralı arşivlenmiş loglar primary veritabanından kazara silinmiştir. Şimdi bu durumda standby veritabanını geri yükleme ve çalışmaya devam etmesini adım adım inceleyelim.

Primary veritabanı “row cache enqueue lock “ bekleme olayı hatası ve çözümü

Oracle 10.2.0.3.0 Data Guard with Broker konfigürasyonunda herhangi bir şekilde standby veritabanını READ ONLY modda yeniden başlatmayı denediğinizde aşağıdaki hata mesajını alırsınız.

ERROR: WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
ORA-12170: TNS:Connect timeout occurred
PING[ARC6]: Error 3113 when pinging standby
ARC6: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (1089)

“ORA01665 control file is not a standby control file” hata mesajı

Standby veritabanını geri yüklerken alter database recover managed standby database disconnect from session komutu sonucunda “ORA-01665: control file is not a standby control file” şeklinde hata mesajı alınabilir.

SQL> alter database recover managed standby database disconnect from session;
alter database recover managed standby database disconnect from session
*
ERROR at line 1:
ORA-01665: control file is not a standby control file

Standby veritabanı tarafından henüz alınmayan logların bulunması

Standby veritbanı tarafından hangi logların henüz alınmadığını bulmak için primary veritabanı üzerinde aşağıdaki sorguyu çalıştırabilirsiniz.

SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM
          (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE

          DEST_ID = (SELECT DEST_ID FROM V$ARCHIVE_DEST) LOCAL
          WHERE LOCAL.SEQUENCE# NOT IN
         (SELECT SEQUENCE# FROM V$ARCHIVED_LOG

         WHERE DEST_ID=(SELECT DEST_ID FROM V$ARCHIVE_DEST)  AND
         THREAD# = LOCAL.THREAD#);

THREAD#      SEQUENCE#
----------         ----------
1                      12
1                      13

1                     14

Yukardaki sonuca gore 12,13 ve 14 numaralı loglar henüz standby veritabanı tarafından alınmamıştır.

Linux | Unix sistemlerde açılış esnasında veritabanını ve listener’ı otomatik olarak başlatma

Linux ve UNIX sistemlerde veritabanını ve listener’ı boot esnasında açılış scripti ile başlatabiliriz. Bunun için bazı yollar vardır. Birinci yol, veritabanını başlatmak için kullanılan dbstart scripti içine ilgili listeneri eklemek ve değerini Y olarak değiştirmektir. Ancak bazı durumlarda bu başlatmada sıkıntı yaratabilmektedir.

Diğer en uygun yol ise hem veritabanını hemde listener’ı başlatıp durduracak bir script oluşturmak ve runlevel dizinlerinden birine bu scripti iliştirmektir.

Bu script, başlat ve durdur olmak üzere 2 arguman içerecek ve /etc/rc.d/init.d dizininde yer alacaktır. Alttaki komut dbora adlı dosya içerisinden listener’ı ve veritabanını başlatıp durdurmak için eklenmiştir.

Oracle veritabanının DBID sini değiştirme

Oracle veritabanının DBID sini değiştirmek zorunda kaldığımızda alttaki adımları uygulamak yeterli olacaktır.

SQLNET.EXPIRE_TIME parametresi ile inaktif bağlantıların sonlandırılması

Sqlnet.expire_time parametresi  istemci/sunucu arasındaki bağlantıların aktif olup olmadığını anlamak için hangi sıklıkta yoklayıcının gönderileceğini belirtmekte kullanılır ve dakika değerini temsil eder. Bağlantıların süresiz olarak açık bırakılmadığından emin olmak için bu parametresinin değerini 0 üzerinde belirtmeniz gerekmektedir. Oracle 10 dakikayı ideal olarak tavsiye etmektedir. Böylece 10 dakikaya erişen inaktif istemci bağlantıları sunucu prosesi tarafından otomatik olarak sonlandırılacaktır.

sqlnet.ora dosyası içine SQLNET.EXPIRE_TIME = 10 şeklinde eklenir.

sqlnet.expire_time parametresi kullanımı ile ilgili kısıtlamalar ise aşağıda yer almaktadır.

• sqlnet.expire_time parametresi IPC protokolü kullanan bağlantılarda çalışmaz.
• sqlnet.expire_time yoklayıcı paketi ilave network trafiği oluşturacağından dolayı bağlantı sayısına bağlı olarak network performansında düşüşler meydana getirebilecektir.
• Bağlantı yoklayıcısının ayırt edilmesi için muhtemelen ilave sunucu prosesleri devreye girecek ve böylece ilave bekleme olayları meydana gelebilecektir.

Standby veritabanına en son hangi redo logların uygulandığının gözlenmesi

Standby veritabanı üzerinde V$LOG_HISTORY görünümüne sorgu çekerek en son log sıra numarasındaki hangi kayıtların standby’a uygulandığını gözlemleyebiliriz.

SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG"
2> FROM V$LOG_HISTORY
3> GROUP BY THREAD#;

THREAD#    LAST_APPLIED_LOG
------------     ----------- ----------------
1                    745
Yukardaki örnekte 745 log sıra numarasına sahip arşiv redo log dosyası en son uygulanan kayıttır. Bunun yanında standby veritabanında V$ARCHIVED_LOG görünümünün APPLIED kolonu hangi logun standby’a uygulandığını listelemektedir.

Adım adım yeni voting disk ilavesi

1. RAC veritabanını durdurun

$ srvctl stop database -d RACDB

2. Tüm düğümlerdek, nodeapps servisini durdurun

$ srvctl stop nodeapps -n rac1

$ srvctl stop nodeapps -n rac2

3. Tüm düğümlerde Oracle Clusterware servisini root hesabından oturum açarak durdurun

# crsctl stop crs

RAC mimarisinde zamanlanmış görevler ile servisleri bağlama

Oracle 10g Scheduler servisi, görevlerin görev sınıflarına(job classes) bağlanabilmesine ve bununla beraber RAC içindeki tanımlanan düğümlerdeki servislerede bu görevlerin çalışması için bağlanabilmesine imkan vermektedir.  Görevler ve ilgili RAC servislerinin ilişkilendirilmesinde uygulanacak adımlar alttaki senaryoda yer almaktadır.

"ORA-32004 obsolete and/or deprecated parameter(s) specified" hata mesajı

"ORA-32004 obsolete and/or deprecated parameter(s) specified" hata mesajı ile karşılaşırsanız bunun sebebi spfile dosyanızda geçerli olmayan ve kullanılmayan başlangıç parametresinin olmasıdır.

Bu hata mesajından kurtulmak için önce hangi parametrelerin sistem tarafından kullanılmadığını görmemiz gerekmektedir.

SQL> select name, isspecified from v$obsolete_parameter where isspecified='TRUE';

RAC veritabanında kontrol dosyası oluştururken ORA-01503 ve ORA-12720 hataları

RAC veritabanında kontrol dosyasını oluştururken alttaki hata mesajı alınabilir.

CREATE CONTROLFILE REUSE SET DATABASE "RACDB" RESETLOGS FORCE LOGGING ARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-12720: operation requires database is in EXCLUSIVE mode

Çözümü: alter system set cluster_database=false scope=spfile;