ORA-12838: cannot read/modify an object after modifying it in parallel

Bir  migration  çalışması  sırasında kullanılacak  olan scriptleri  tun ederken, insertler i Append hinti vererek yapmaya karar verdim. Bir tablo için peşpeşe birkaç tane insert scripti olanlar da vardı. Append  hintinin çalışma mantığını düşünmeden insertler arasına hintleri vererek geçtim.  Sabahın 05’ inde migration çalışmasını başlattığımda (bir gözü açık bir gözü kapalı durumda J)  scriptler patlamaya başlayınca (tabi bu arada gözlerim açıldı J)  farkettimki Append  hinti ile bir tabloya peşpeşe insert yapıyorsan iki insert arasında mutlaka transactionı sonlandırmalısın yani commit veya rollback yapmalısın.  Appent hinti redo üretimi minumum düzeyde tuttuğundan dolayı bir sonraki insert ile ilgili  yeteri kadar data bilgisi sistemde yer almamış oluyor.  Dolayısıyla  (ORA-12838: bir nesne değiştirildikten sonra paralel olarak okunamaz / değiştirilemez)  verdiği bu hatada bir o kadar anlamlı oluyor.
Continue reading

ORA-01122: database file 9 failed verification check (ora-01110 – ora-01208)

Arkadaşlar, bugün şirkette yaşadığımız bir disaster probleminin ortaya çıkışından ve soruna nasıl bir çözüm bulduğumuza varan uzun bir operasyonun üzerimizde yarattığı stresden bahsetmek istiyorum. Aslına haftaya güzel başlamıştık taki disaster tarafındaki standby database’ lerimizin kurulumu ile ilgilenen bir arkadaşımızın bizim için çok kritik olan bir production database’ ine ait 3 datafile’ i olduğu lokasyonda ziplemeye başlamasına kadar 🙂 Sorunlar silsilesi tam bu noktada başlıyor, 3 tane dbf file’ ınız .gz olduğundan artık yok, ayrıca disk üzerinde aynı partitionda çalışan bir gzip procesi’ nin düzgün kill edilememesinden dolayı diskin doluluk oranı %100 olmuş durumda, kullanılabilir alan sıfır 🙂 Database açık, database’ in toplam buyutu 500 gb (aslında bu tarz kritik database’ lerimiz arasında en ufak olanı bu olduğundan dolayıda biraz şanslıyız 🙂 ziplenen 3 dbf’ in bağlı bulunduğu tablespace’ in büyüklüğü 260 gb, ve tablespace’ a ait tüm datafile’ ler begin backup modda. Aslında tüm niyetimiz database’ i kapatmadan soruna çözüm üretmekti ancak arka tarafda neler yapıldığınıda tam olarak kestiremiyorduk yani disk full dolu tam bu esnada yapılan gzip operasyonu, gzip bile düzgün tamamlanmış olmayabilirdi, byte mertebesinde dosyada olabilecek bir corruption tüm senaryonuyu değiştirmek için yeterli bir nedendi. Yaptığımız bir takım tespitlerden sonra system admini arkadaşlardan disk üzerinde yeterli büyüklükte bir partition alarak gece alınmış olan rman backupdan dönmeye karar verdik. (%100 dolmuş olan alanı farklı bir isimle unmount ettik, yeni aldğımız alanıda kullanılan eski isimle mount ettik) 500 gb backupın 480 gb okuduğu esnada (ki bu süreç tam 01:50 dak. kadar sürdü) yani sonuna gelmişken restore operasyonumuz HPUX-ia64 Error: 27: File too large hatasıyla fail oldu 🙂 (system admini arkadaşımız diski verirken large file parametresine dikkat etmeden verdiği için yüksek size’ lı dbf’ leri kopyalarken hata fail oldu) Sonrasında yeni bir rman restore işine girişmeden tüm archive loglarımız olduğundan dolayı archive logları kullanarak ilgili datafile’ leri recover etmeye karar verdik. Ve bu şekilde tüm datafile’ lerimizi recover etmeyi başardık. Sonuç bizim açımızdan başarılıydı. Bunu aslında biraz da bu tarz operasyonların kritikliğinden bahsetmek için yazdım. Yapmış olduğumuz işlemlerin veya kontrollerin bir kısmından burda bahsettim. Asıl zor olan, bir disaster durumunda başınızda onlarca kişi toplanmışken ve her bir kafadan ayrı bir ses çıkıyorken sorunu iyi analiz edip, en kısa yoldan çözüm üretebilen bu işde ciddi şekilde başarılı oluyor diye düşünüyorum. Bu tarz koşullarda soğukkanlılığınızı, sakinliğinizi kaybetmeden paniklemeden çalışabiliyorsanız, bence bir dba’ in mutlaka sahip olması gereken bu vasıflarına sahipsiniz demektir. Bunların üzerine deneyim ve tecrübelerinizi de eklediğinizde işte o zaman ortaya kaliteniz çıkıyor. Disaster’ sız günlerde görüşmek üzere 🙂

Flashback drop ile devam etmeye çalışacağım. 
İyi geceler.

ORA-03297: file contains used data beyond requested RESIZE value

Ora-03297 hatası datafile resize etmeye çalışırken alınan bir hata mesajıdır. Hatanın nasıl çözülebileceğine geçmeden önce bu hatayı neden alındığı üzerine biraz duralım.

Database içerisinde daha önceden oluşturulmuş ve kullanılmış olan bazı tabloların drop veya truncate edilmesinden dolayı datafile’ in kullanılan alanı küçülmüş olabilir. Dba’ ler için yer sıkıntısı sanıyorum en fazla karşılaştıkları sorunlardan biridir desek yanlış olmaz.  Hata tam bu esnada, kullanılmayan alanın fiziksel olarak operating sisteme geri kazandırılmaya çalışdığı esnada alınıyor. Şimdi bir örnek üzerinden gidelim.
Continue reading

ORA-01552: cannot use system rollback segment for non-system tablespace USERS

Bugün test ortamlarımızdan birinde ora-01552 hatası almaya başladık. Hata undo tablespace’ i altında oracle tarafından manage edilen rollback segmentlerini işaret ediyordu.

Öncelikle hali hazırda mevcut olan rollback segmentlerin durumun kontrol ettiğimde ;

select segment_name, status from dba_rollback_segs;
Continue reading

Sequencelerle İlgili Birkaç Not …

Sequence’ ler için sayaç tabloları denilebilir. Sequence’ ler sizin belirlediğiniz bir noktadan istediğiniz oranda bir artış hızıyla, istediğiniz bir değere kadar sayı üretirler.

Create sequence komutunun full syntax’ ı ;

CREATE SEQUENCE [schema.]sequencename

[INCREMENT BY number]

[START WITH number]

[MAXVALUE number | NOMAXVALUE]

[MINVALUE number | NOMINVALUE]

[CYCLE | NOCYCLE]

[CACHE number | NOCACHE]

[ORDER | NOORDER] ;
Continue reading