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

Historydeki İstatistikleri Tekrar Nasıl Kullanabiliriz

Database’ inizde örneğin gather_stats_job’ ınız disable değil ise database’ in istatistikleri belli aralıklarla güncelleniyor demektir. Alınan her bir istatistik belli bir süre boyunca history’ de saklanır. Aslında bu özellik çok sık kullanılmamakla birlikte bazen çok işimize yarayabilmektedir.

Örneğin, çok büyük bir tablonuz var ve bir gün önce bu tablo üzerindeki tüm sorgularınızın performans şikayeti olmadan çalıştığını ancak şu anda sorguların büyük bir çoğunluğunun index kullanmadığını yani full table scan yaptığını farkettiniz. Bu durumun bir çok nedeni olabilir. Biz bunun nedenin istatistiklerde yaşanan bir problem den dolayı kaynaklandığını düşünelin veya bu ihtimal üzerinde duralım ve neler yapabiliriz onlar üzerinde konuşalım.
Continue reading

İstatistiklerin Test Edildikden Sonra Yayınlanması

Burada bahsedeceğimiz bu özellik 11g ile beraber gelen zaman zaman dayanlış yapmamızın önüne geçen güzel bir özellik aslında ama yeteri kadar bilinmediği kaanatindeyim.

Önce kısaca ne olduğundan bahsedelim. Kimi zaman aktif olarak çalışan bazı sql’ lerin performanslarında ciddi yavaşlamalar görürüz. Bunu ya biz farkederiz yada kullanıcılardan gelen şikeyetler doğrultusunda farkederiz. Bu tarz durularda öncelikle sorgunun execution planını incelemekle işe başlarız sonrasında select edilmeye çalışılan data miktarı, sorgu içerisindeki where conditionları olmak üzere bazı noktaları gözden geçiririz. İşte bunlardan biride ki çoğu zaman aldığımız ilk aksiyon da budur diyebiliriz, istatistiklerin güncel olup olmadığını kontrol etmek veya hemen bir istatistik alıp sorgunun performansına ondan sonra bakmak oluyor. İşte tam bu noktada özelliklede üzerinde çalıştığınız tablolar çok büyük ise istatistikleri güncelenin etkilerini önce siz gördükden sonra ve sorgunun performansına olumlu etkileri test ettikten bu istatistikleri diğer kullanıcılarında kullanımına sunmak sizi oluşabilecek daha kötü bir senaryodan koruyacaktır.
Continue reading

TROUG – DBA SIG Toplantısı

Merhaba Arkadaşlar,

Troug’ un ilk DBA SIG toplantısı 31 Mayıs 2012 Perşembe günü Bilginç Akademide düzenleniyor. Bu etkinlikde bende Partitioning kullanımı ve performans üzerine etkilerini anlatan bir sunum yapıyor olacağım.

Dba’ ler için çok faydalı bir etkinlik olacağını düşünüyorum. Katılım sınırlı olacağından dolayı öncesinde mutlaka kayıt yaptırmanız gerekiyor.

31 mayıs da görüşmek üzere…

Detayları;

http://www.troug.org/?p=203

linkinden takip edebilirsiniz.

DBA SIG Toplantısı
Continue reading

System Partitioning …

System partitioning şimdiye kadar benim hiç kullanmadığım ve 11g ile birlikte gelen yeni bir özellik, öncesinde özetle ne olduğundan bahsedelim, sonrasında kullanılması durumunda ne gibi avantajları olduğu üzerinde konuşuruz.

System partitioning data’ nın tablespace’lere yerleşiminde, veritabanını kontrolü olmadan tamamen uygulamanın kontrolünde datanın dağıtılmasını sağlar. Bu işlemi çok basitçe şöyle anlatabiliriz, database sadece tablonun partitionlara ayrılmasında yardımcı oluyor ama datanın hangi partitiona gideceğini bilmiyor ve dolayısıyla da yönetmiyor, bu kısım sadece uygulamanın kontrolünde gerçekleşiyor. Bu işlemin gerçekleşmesi içinde parititoning’in tümüyle uygulama tarafından kontrol edilmesi gereksinimini doğuruyor. Yani system partitioning yapılmış olan bir tabloya bir kayıt insert etmeye çalışıldığında eğer insert statementı içerisinde hangi partitiona insert edileceği açıkca belirtilmediği süre insert işlemi hata alacaktır.
Continue reading