Failed Logonları Nasıl Tespit Edebiliriz …

Daha önce yine bu konuyla bağlantı olduğunu düşündüğüm 2 tane yazı yazmıştım.

http://www.kamilturkyilmaz.com/2011/01/21/bilinen-adiyla-logon-trigger/
http://www.kamilturkyilmaz.com/2011/01/22/sisteme-connect-olan-%E2%80%93-olmayan-kullanicilari-tespit-etme/

Bugün sisteme girmeyi deneyip, bir şekilde giremeyen hata alan sessionları nasıl tespit edebiliriz ondan bahsetmek istiyorum. Öncelikle hata alan sessionlar ile ilgili 2 farklı durum karşımıza çıkabilir. Birincisi sisteme girmeyi deneyen user ora-01017 (invalid username/password) hatası alabilir, ikinci olarak ora-01031 (insufficient privilige) hatası alabilir. Bu tarz durumlarda hangi userın bu hatayı aldığını tespit etmek içinde aşağıdaki trigger’ ı kullanabilirsiniz ;
Continue reading

ORA-04031:unable to allocate xxxx bytes of shared memory ….

Bu konuya nereden geldik öncelikle biraz ondan bahsetmek istiyorum. 11gr2 upgrade’ lerimiz sonrasında kimi test ortamlarımızdan aşağıdaki alert logda detayını görebileceğiniz gibi sıkça ORA-04031 hataları görmeye başlamıştık. Sorunu aslında ilk başlangıçda utlrp’ yi çalıştırdığımızda aldığımızı farkettik. Aslında hatada kendi içerisinde problemin kaynağını işaret ediyordu. Shared memoryde bir darboğaz yaşanıyor ama neden utlrp çalışırken bu hatayı alıyorduk ?

Biraz araştırınca problemin utlrp ile ilişkisinide bulmuş olduk. Problemin asas kaynağı large pool’ daki memory problemi idi. Utlrp’ yi çalıştırdığınızda aslında oracle arka tarafda (database’nizin kaynaklarına bağlı olarak) bu işlemi parallel process ler çalıştırarak yapmaya çalışıyor. Parallel processler de large pool’ dan beslendiği için buradaki bir memory problemide bizi aşağıdaki gibi bir hataya götürüyordu.
Continue reading

Transparent Data Encryption Opsiyonun Kullanımı (11gR2)

Transparent Database Encrytion (TDE) oracle’ ın 10gR2 versiyonu ile tanışmış olduğumuz bir opsiyondur. Temelde database içerisinde store edilen verilenen kolon, tablo veya tablespace bazında şifrelenmek suretiyle verinin istenmeyen kişiler tarafından veriye erişimin önlenerek veri güvenliğinin sağlanmasını amaçlamaktadır.

Öncelikle Oracle’ ın Wallet kullanımı ile ilgili birkaç önerisinden bahsetmek istiyourum. TDE’ i production ortamına implente edecekler için bu önerileri dikkate alarak ilerlemelerinde ciddi fayda olacaktır diye düşünüyorum. Birincisi Wallet nerde saklanacak veya saklanmalı, öncelikle kesinlikle ORACLE_BASE veya ORACLE_HOME altında olmamalıdır, çünkü zaman zaman bu path’ lerin backupı alındığında Walletında backupı alınacağından bu risk oluşturacaktır. Bunun yerine root userı ile farklı bir directory altında bir dizin create edilerek oracle userına yetki verilmesi güvenlik açısından daha faydalı olacaktır. Örneğin;
Continue reading

Standby Database’ i Nasıl Activate Edebiliriz

Standby database’ lerimizi doğası gereği bir disaster durumu yaşadığımızda ve artık bir primary database’ imiz olmadığında zor günler için sakladığımız bu database’ leri primary yapmak isteyebiliriz. Bu tarz durumlarda nasıl standby database’ imizi primary yapabiliriz biraz bundan bahsetmek istiyorum.

Öncelikle eğer dataguard’ ınızın type’ ı maximum protection ise hiçbir data kaybınız olmadan güvenle açabileceğiniz ve senkron olduğundan %100 emin olduğunuz bir dataguardını var demektir. Eğer maxiumum performance kullanıyorsunuz redo’ nun en son switch olduğu aralığa da bağlı olarak redonun içerisindeki data kadar bir kaybınız olma ihtimali olacaktır. Varsayalımki böyle bir case ile karşılaştık, standbyımızı nasıl activate edecez;

Öncelikle standby’ımızın şu anki durumuna bakalım ;
Continue reading

ORA-01154: database busy. Open, close, mount, and dismount not allowed now

Bu hata ile daha önce hiç karşılaşmamış olanlarımız var ise öncelikle shutdown immediate komutunu database’i nasıl kapatamıyor diye düşünebilir. Ancak hemen belirteyimki kendi içinde tutarlı bir açıklaması var 🙂

Bu durum öncelikle eğer physical standby database’ iniz varsa ve protection mode’ da çalışıyor ise database’ i kapatmaya çalıştığınızda bu hayatı alırsınız. Çünkü protection mode NO DATA LOSS yani sıfır data kaybı mantığına göre çalıştığından dolayı eğer siz database’ i kapatabilseydiniz ve o esnada primary database’ inizde bir crash durumu yaşanması durumunda buda veri kaybını olacağı anlamına gelecektiki buda maximum protection mode’ ın doğasına aykırı bir durum oluştururdu. Bu yüzden sistem size bu mode geçerli olduğu sürece database’ i kapatmanıza izin vermeyecektir. Peki database’ imizi kapatmamız gerekiyor, nasıl kapatabiliriz.

Öncelikle primary database’ imizin protection mode’ unu kontrol edelim;
Continue reading