Her Veri Yöneticisinin Sahip Olması Gereken ama Nadiren Sahip Olduğu Oracle DBA Becerileri

Türkiye'deki bankalarda ve sigorta şirketlerinde, bir veri yöneticisinin DBA'in regülatif bir raporun neden üç saat geciktiğini açıklamasına başını sallayarak eşlik ettiği çok fazla toplantıda bulundum. Yönetici anlatılanları anlamıyordu. DBA bunu biliyordu. Masanın karşısında oturan denetçi de biliyordu. Bu teknik bir sorun değildir. Bu, bir bedeli olan bir liderlik başarısızlığıdır.

Bu yazı, o çizginin nerede olması gerektiği hakkında. Her veri yöneticisinin DBA olması gerekmez — yanlış hedef bu. Ama bunun altında bağımlı olduğunuz insanları değerlendiremeyeceğiniz minimum bir teknik taban vardır ve regüle finans alanında bu taban, çoğu yöneticinin kabul ettiğinden daha yüksektir.

Bu Bağımlılığın Size Gerçek Maliyeti

BDDK veya SPK, bir mutabakat raporunun neden zamanında yetişmediğini sorduğunda cevap "DBA veritabanının yavaş olduğunu söyledi" olamaz. Size sorulacaklar şunlardır:

• Hangi sorgu takıldı ve hangi wait event üzerinde?
• Tek seferlik bir sıçrama mıydı yoksa tekrarlayan bir bozulma mı?
• Öncesi ve sonrasındaki execution plan neydi?
• Düzeltme neden daha önce uygulanmadı?

Bu soruların her birini DBA ekibine yönlendirip doğrulayamayacağınız bir cevabı saatlerce bekliyorsanız, denetim yanıt süreniz yapısal olarak bozuktur. Tek bir başarısız gün sonu batch'i için inandırıcı bir kök neden üretmek dört iş gününü bulan kurumlar gördüm. Regülatörün, organizasyon şemanızın veri yönetimini veritabanı yönetiminden ayırmasıyla bir derdi yoktur.

Bir de daha sessiz bir maliyet var: yanlış kişiler tarafından alınan mimari kararlar. Bir DBA size "bu tabloyu şubeye göre değil, aya göre partition'lamamız gerekiyor" dediğinde ve bunun üzerine muhakeme yürütemiyorsanız, ya kabul edersiniz ya da bunu siyasi bir kavgaya dönüştürürsünüz. İkisi de mühendislik değildir.

Sahiplenmek Zorunda Olduklarınız

Bunlar pazarlık konusu değildir. Regüle bir ortamda veri yönetiyorsanız ve bunları yapamıyorsanız, açıktasınız.

Bir execution plan okuyun. Yazmak değil — okumak. Bir plana bakıp 400 milyon satırlık bir transaction tablosunda full table scan'i tespit edebilmeli, hash join'in olması gereken yerde nested loop görüp tanıyabilmeli ve bir index'in neden kullanılmadığını sorabilmelisiniz. Oracle'da EXPLAIN PLAN ve DBMS_XPLAN.DISPLAY_CURSOR DBA araçları değildir. Yönetim araçlarıdır. Birisi "sorgu yavaş" dediğinde ilk sorunuz "düzeltmek ne kadar sürer" değil, "planı göster bana" olmalıdır.

İlk beş wait event'i yorumlayın. db file sequential read, db file scattered read, log file sync, enq: TX - row lock contention ve library cache: mutex X bir finans workload'unu öldüren şeylerin büyük çoğunluğunu kapsar. Gece yapılan poliçe yenileme batch'iniz log file sync üzerinde takılıysa, cevap daha fazla CPU değildir. Row lock contention'da takılıysa, cevap daha hızlı disk değildir. Farkı bilmek, altyapıyla anlamlı bir konuşma ile boş çek arasındaki farktır.

Tablespace baskısı ve büyümesi üzerine muhakeme yürütün. En büyük fact tablolarınızı hangi tablespace'lerin tuttuğunu, büyüme hızlarını ve birinin saat 02:00'de batch sırasında dolması durumunda ne olacağını bilmelisiniz. DBA_TABLESPACE_USAGE_METRICS'e altı ay boyunca kimsenin bakmamış olması nedeniyle çöken bir hasar işleme pipeline'ı izledim. Suç DBA'e atıldı. Aslında veri yöneticisinin olmalıydı.

Undo ve redo davranışını anlayın. Uzun süren bir mutabakat sorgusu ORA-01555 ile başarısız olduğunda, cevabın daha büyük bir undo tablespace mi, daha kısa bir sorgu mu yoksa farklı bir izolasyon yaklaşımı mı olduğunu bilmeniz gerekir. Bu, ETL pencerelerinizi nasıl tasarladığınızı etkiler.

AWR ve ASH raporlarının size ne söylediğini bilin. Bunları üretmeniz gerekmez. Okumanız gerekir. DBA size sorun penceresini kapsayan bir AWR raporu verdiğinde, elapsed time'a göre en üstteki SQL'i bulabilmeli ve onun hakkında akıllı sorular sorabilmelisiniz.

Güvenle Devredebilecekleriniz

Çoğu yöneticinin ya aşırıya kaçtığı ya da yeterince devretmediği yer burasıdır. İkisi de pahalıdır.

• RMAN yedekleme yapılandırması ve recovery testi. Politikayı ve test takvimini sahiplenin. Syntax'ı sahiplenmeyin.
• Data Guard kurulumu ve switchover prosedürleri. RPO ve RTO'yu bilin. Mekaniği DBA sahiplensin.
• Patch uygulaması ve PSU planlaması. Pencereyi onaylayın, rollback planını gözden geçirin, runbook'u yazmayın.
• Storage düzeni, ASM disk group yönetimi ve redo log boyutlandırması. Bunlar veritabanı sonuçları olan altyapı kararlarıdır. Gözden geçirin, tasarlamayın.
• Belirgin olanların ötesindeki parametre tuning. SGA_TARGET ve PGA_AGGREGATE_TARGET farkında olmanız gerekenlerdir. Diğer 400 parametre sizin işiniz değildir.

DBA Olmadan Tabanı Nasıl İnşa Edersiniz

İşe yaradığını gördüğüm en hızlı yol: son altı aydan üç production olayı seçin. Bunları çözen DBA ile oturup teşhisi baştan sona birlikte gözden geçirin. Düzeltmeyi değil — teşhisi. AWR raporunu, execution plan'leri, wait event analizini görmek isteyin. Bunu çeviriye ihtiyacınız kalmayana kadar yapın.

Sonra ortamınızda şu anda yavaş olan bir sorgu seçin. Planını kendiniz okuyun. Bir hipotez kurun. DBA'inkiyle karşılaştırın. İlk birkaç seferde yanılacaksınız. Mesele de bu.

Amaç, DBA ekibinizden iş almak değildir. Amaç, kendi verileriniz hakkındaki teknik konuşmalarda bir denk olmaktır. Her dakika kesintinin regülatif ve itibari bir maliyeti olduğu finans ve sigorta sektöründe, bu denklik statüsü olsa iyi olur kategorisinde değildir. İşin kendisidir.