Pages

16 Temmuz 2011 Cumartesi

Standby veritabanında “ORA-02290: check constraint (RMAN.AL_C_STATUS) violated” hata mesajı


Bu hata mesajı ile birkaç hafta önce uzun bir tatil dönüşü sonunda bir yedekleme sorunu üzerinde çalışırken karşılaştım. Yedek, standby veritabanında alınmakta ve recovery katalog kullanılmaktaydı. Oracle sürümü ise Oracle 10.2.0.4

Stanby veritabanında RMAN operasyonu ile katalog veritabanı bağlantı denemeleri aşağıdaki hata mesajı ile sonlandırılmaktaydı:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of list command at 06/27/2011 09:01:57
RMAN-03014: implicit resync of recovery catalog failed
RMAN-03009: failure of partial resync command on default channel at 06/27/2011 09:01:57
ORA-02290: check constraint (RMAN.AL_C_STATUS) violated

Görünüşe göre hiçbir yedek yok! Halbuki primary veritabanında aynı işlemi yaptığımda bir hata ile karşılaşmıyorum, ancak primary üzerinde ise yedek almak için yeterli boş alan yok.

Problemin altında yatan gerçek
Standby veritabanının arşiv log destinasyonu dolduğundan ve ben tatildeyken outsource firma bazı arşiv dosyaları başka yere taşıdığından ve bir kısmınıda sildiğinden bu problem meydana gelmekteydi.

Bu sebeple standby veritabanı kontrol dosyası bu arşiv dosyalarının hala aynı yerde bulunduğunu zannetmekteydi. Primary kontrol dosyasında sorun yoktu. Bu sorun üzerine biraz araştırma yapınca bunun çözülmüş bir bug olduğnu öğrendim (Metalink note 740801.1).

RMAN katalog içindeki kısıtlama(constraint) üzerine bazı analizler bu kısıtlamanın tanımını aşağıdaki gibi göstermekte:

Owner: RMAN (not surprisingly)
Type: C (check constraint)
Table: AL
Condition: “status in (‘A’,'U’,'D’,'X’)”

Bu metalink notu, kataloğun yeniden senkronizasyonu esnasında V$ARCHIVED_LOG.STATUS sorgusunda cf hata mesajının alınmasının bu problemin kaynağı olduğunu belirtmektedir. Belirli arşivlenmiş logun durumu “?” ile belirtilmesi sebebiyle sorgu çakılmakta ve kısıtlama ihlal edilmekte. Standby veritabanında sorgu aşağıdaki sonucu vermekte:

SQL> select distinct status from v$archived_log;

S
-
?
A
D

Halbuki primary veritabanında aynı sorgu çalıştırıldığında böyle bir sorun ile karşılaşmıyorum:

SQL> select distinct status from v$archived_log;

S
-
A
D

Bu noktada standby kontrol dosyasının arşiv logların son durumunu algılaması için standby kontrol dosyası tekrardan oluşturulmalıdır.Böylece bu sorun ile artık karşılaşılmaz.

ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/u05/xxxx/stdarch/controlfile.ctl’;   


0 yorum:

Yorum Gönder