Veritabanı Bakımı Nedir? Database Maintenance Nasıl Yapılır?

Veritabanı sistemleri kurulduktan sonra kendi kendine yıllarca sağlıklı şekilde çalışmaz.

Zaman içerisinde;

veri miktarı artar,

index yapıları değişir,

statistics eskiyebilir,

transaction log büyüyebilir,

disk kapasitesi azalabilir,

backup job’ları hata verebilir,

patch ihtiyacı oluşabilir,

query performansı düşebilir

ve database yapılandırması güncelliğini kaybedebilir.

Bu nedenle kurumsal database sistemlerinde düzenli bakım yapılması gerekir.

Bu süreç genel olarak:

Database Maintenance – Veritabanı Bakımı

olarak adlandırılır.

Database maintenance yalnızca performans artırmak için yapılan teknik işlemlerden oluşmaz.

Aynı zamanda;

availability,

data integrity,

security,

backup reliability

ve business continuity

açısından da kritik bir süreçtir.

Bir database'in bugün çalışıyor olması yarın da sorunsuz çalışacağı anlamına gelmez.

Asıl önemli olan sistemin;

izlenmesi,

kontrol edilmesi,

bakımının yapılması

ve olası sorunların kullanıcıyı etkilemeden önce tespit edilmesidir.

Veritabanı Bakımı Nedir?

Veritabanı bakımı, database sistemlerinin sağlıklı, güvenli, performanslı ve erişilebilir şekilde çalışmasını sağlamak amacıyla düzenli olarak yapılan operasyonel işlemlerin bütünüdür.

Bu işlemler arasında;

backup kontrolü,

restore testleri,

index maintenance,

statistics update,

integrity check,

transaction log kontrolü,

patch management,

capacity monitoring,

slow query analizi,

security log incelemesi

yer alabilir.

Database Maintenance Neden Gereklidir?

Database sürekli değişen canlı bir sistemdir.

Her INSERT,

UPDATE,

DELETE

işlemi database yapısını etkiler.

Zamanla veri büyür.

Kullanım alışkanlıkları değişir.

Yeni uygulamalar eklenir.

Kullanıcı sayısı artar.

Bu değişiklikler database performansını ve stabilitesini etkileyebilir.

Bu nedenle maintenance yapılmayan bir database zaman içerisinde giderek daha fazla risk üretir.

Veritabanı Bakımı Sadece Performans İçin mi Yapılır?

Hayır.

Bu en yaygın yanlış anlaşılmalardan biridir.

Database maintenance;

performans,

güvenlik,

veri bütünlüğü,

yedekleme,

kapasite,

iş sürekliliği

için birlikte yapılmalıdır.

Örneğin database hızlı çalışıyor olabilir ancak backup alınmıyorsa sistem yine yüksek risklidir.

Database Maintenance Plan Nedir?

Database Maintenance Plan, hangi bakım işlemlerinin hangi sıklıkla ve hangi yöntemle yapılacağını belirleyen plandır.

Örneğin:

Günlük → Backup kontrolü

Haftalık → Index ve statistics incelemesi

Aylık → Patch değerlendirmesi

Üç aylık → Restore testi

gibi bir yapı oluşturulabilir.

Ancak bu periyotlar her kurum için aynı olmak zorunda değildir.

Sistem kritikliğine göre belirlenmelidir.

Her Database İçin Aynı Bakım Planı Kullanılmalı mı?

Hayır.

Örneğin:

24x7 çalışan finansal transaction database'i

ile

ayda birkaç kez kullanılan raporlama database'i

aynı maintenance politikasına sahip olmamalıdır.

Sistem kritikliğine göre maintenance sınıflandırması yapılmalıdır.

Kritik Database Nasıl Belirlenir?

Bir database şu sorularla değerlendirilebilir:

Bu database durursa hangi uygulamalar etkilenir?

Ne kadar finansal kayıp oluşur?

Kaç kullanıcı etkilenir?

Ne kadar veri kaybı kabul edilebilir?

Regülasyon açısından kritik mi?

Bu sorular database criticality belirlemede yardımcı olur.

Database Inventory Bakım İçin Neden Önemlidir?

Bakımı yapılacak database’lerin öncelikle envanteri bulunmalıdır.

Envanterde;

server adı,

database adı,

DBMS türü,

version,

owner,

criticality,

backup policy,

RPO,

RTO

bilgileri tutulabilir.

Bilmediğiniz bir database'in bakımını yapamazsınız.

Database Owner Kim Olmalı?

Her database için teknik ve iş sahibi belirlenmelidir.

Teknik owner:

DBA veya IT ekibi olabilir.

Business owner ise database'i kullanan iş birimi olabilir.

Bu ayrım önemlidir.

Çünkü maintenance sırasında kesinti gerektiğinde iş onayı alınması gerekebilir.

Database Maintenance Window Nedir?

Maintenance Window, bakım işlemlerinin kontrollü şekilde yapılabileceği zaman aralığıdır.

Örneğin;

Pazar 02:00–04:00

bakım penceresi olabilir.

Bu sürede;

patch,

index maintenance,

restart,

upgrade

gibi işlemler uygulanabilir.

24x7 Sistemlerde Maintenance Nasıl Yapılır?

Kesintisiz çalışan sistemlerde klasik bakım penceresi olmayabilir.

Bu durumda;

online maintenance,

rolling upgrade,

cluster failover,

replica kullanımı

gibi yöntemler değerlendirilebilir.

Index Nedir?

Index, database sorgularının daha hızlı çalışmasını sağlayan veri yapısıdır.

Bir kitabın sonunda bulunan konu indeksine benzetilebilir.

Kitabın tamamını okumak yerine doğrudan ilgili sayfaya ulaşmayı sağlar.

Database de benzer şekilde index üzerinden veriye daha hızlı ulaşabilir.

Index Maintenance Nedir?

Index Maintenance, index yapılarının düzenli olarak incelenmesi ve gerektiğinde optimize edilmesidir.

Bu işlem platforma göre;

rebuild,

reorganize,

vacuum,

analyze

gibi farklı mekanizmalar içerebilir.

Index Fragmentation Nedir?

Bazı database sistemlerinde yoğun INSERT, UPDATE ve DELETE işlemleri index sayfalarının zaman içerisinde verimsiz hale gelmesine neden olabilir.

Bu duruma genel olarak:

Index Fragmentation

denir.

Fragmentation arttığında daha fazla disk IO oluşabilir.

Fragmentation Her Database'te Aynı Şekilde mi Çalışır?

Hayır.

PostgreSQL,

MSSQL,

Oracle

farklı storage ve index mimarilerine sahiptir.

Bu nedenle tek bir maintenance komutunu tüm database sistemlerine uygulamak doğru değildir.

Index Rebuild Nedir?

Index'in yeniden oluşturulmasıdır.

Bu işlem yüksek fragmentation durumunda performansı iyileştirebilir.

Ancak;

CPU,

IO,

transaction log

yükü oluşturabilir.

Bu nedenle plansız yapılmamalıdır.

Index Reorganize Nedir?

Bazı database sistemlerinde index yapısının daha hafif şekilde düzenlenmesini ifade eder.

Rebuild'e göre daha az kaynak tüketebilir ancak her durumda aynı etkiyi sağlamaz.

Her Gece Tüm Index'leri Rebuild Etmek Doğru mu?

Genellikle hayır.

Bu eski ve fazla agresif maintenance yaklaşımlarından biridir.

Her index’in rebuild edilmesi;

gereksiz IO,

CPU,

log büyümesi,

backup büyümesi

oluşturabilir.

Maintenance veri ve kullanım istatistiklerine göre yapılmalıdır.

PostgreSQL'de Index Bakımı Nasıl Düşünülmelidir?

PostgreSQL’de MVCC yapısı nedeniyle klasik fragmentation yaklaşımından ziyade;

dead tuple,

VACUUM,

ANALYZE,

autovacuum,

bloat

gibi kavramlar önemlidir.

Bu nedenle PostgreSQL bakım planı MSSQL mantığıyla birebir oluşturulmamalıdır.

VACUUM Nedir?

PostgreSQL’de eski transaction versiyonlarının temizlenmesine yardımcı olan bakım mekanizmasıdır.

MVCC nedeniyle silinen veya güncellenen satırların eski versiyonları bir süre sistemde kalabilir.

VACUUM bu alanların tekrar kullanılabilmesini sağlar.

Autovacuum Nedir?

PostgreSQL'in otomatik VACUUM ve ANALYZE işlemlerini gerçekleştiren mekanizmasıdır.

Autovacuum performans ve transaction ID yönetimi açısından kritik öneme sahiptir.

Autovacuum Kapatılmalı mı?

Genel yaklaşım olarak kapatılması önerilmez.

Yanlış yapılandırıldığında performans etkileyebilir.

Ancak çözüm çoğu zaman tamamen kapatmak değil doğru tune etmektir.

Database Bloat Nedir?

Özellikle PostgreSQL gibi MVCC tabanlı yapılarda gereksiz alan büyümesi oluşabilir.

Table veya index fiziksel olarak gereğinden büyük hale gelebilir.

Bu duruma bloat denir.

Statistics Nedir?

Database statistics, optimizer'ın verinin dağılımını anlamasına yardımcı olan bilgilerdir.

Query optimizer hangi execution plan'ın daha hızlı olacağını bu verilere bakarak tahmin eder.

Statistics Update Neden Gereklidir?

Veri önemli ölçüde değiştiğinde eski statistics yanlış tahminlere neden olabilir.

Örneğin optimizer 100 satır beklerken gerçekte 10 milyon satır dönebilir.

Bu durumda yanlış execution plan seçilebilir.

Query Optimizer Nedir?

Query Optimizer, SQL sorgusunun nasıl çalıştırılacağını belirleyen bileşendir.

Örneğin;

hangi index kullanılacak,

hangi tablo önce okunacak,

join nasıl yapılacak

gibi kararları verir.

Execution Plan Nedir?

Execution Plan, database'in sorguyu hangi adımlarla çalıştıracağını gösteren plandır.

Slow query analizinde en önemli araçlardan biridir.

Query Plan Neden Zamanla Değişebilir?

Veri büyüdükçe;

statistics,

index,

data distribution,

parameter values

değişebilir.

Bu nedenle daha önce iyi çalışan sorgu zamanla yavaşlayabilir.

Slow Query Nedir?

Beklenenden uzun süren database sorgusudur.

Örneğin normalde 200 ms çalışan sorgu 30 saniye sürmeye başlayabilir.

Bu durum kullanıcı deneyimini ve application performansını etkiler.

Slow Query Monitoring Nasıl Yapılır?

Database platformunun kendi monitoring araçları veya APM/database monitoring çözümleri kullanılabilir.

İzlenebilecek metrikler:

execution time,

CPU time,

logical reads,

physical reads,

wait time,

lock duration.

Slow Query Her Zaman Database Sorunu mudur?

Hayır.

Sorun;

application code,

network,

storage,

database design,

yanlış index

kaynaklı olabilir.

Bu nedenle end-to-end analiz yapılmalıdır.

N+1 Query Problemi Nedir?

Uygulamanın bir ana sorgu yerine aynı işlemi yüzlerce veya binlerce küçük sorguyla gerçekleştirmesi durumudur.

Özellikle ORM kullanılan uygulamalarda görülebilir.

Bu performansı ciddi şekilde etkileyebilir.

Database Deadlock Nedir?

Deadlock, iki veya daha fazla transaction'ın birbirinin kilitlediği kaynağı beklemesi durumudur.

Örneğin:

Transaction A → Resource 1'i kilitler.

Transaction B → Resource 2'yi kilitler.

A, Resource 2'yi bekler.

B, Resource 1'i bekler.

Bu durumda database bir transaction'ı sonlandırabilir.

Deadlock Normal midir?

Nadiren oluşabilir.

Ancak sürekli yaşanıyorsa application transaction tasarımı veya query yapısı incelenmelidir.

Lock Nedir?

Database'in aynı veri üzerinde eşzamanlı işlemleri kontrol etmek için kullandığı mekanizmadır.

Yanlış veya uzun süren transaction'lar excessive locking oluşturabilir.

Long-Running Transaction Neden Risklidir?

Uzun transaction;

lock,

transaction log büyümesi,

MVCC bloat,

replication lag

gibi sorunlara yol açabilir.

Transaction Log Nedir?

Transaction Log, database üzerinde yapılan işlemlerin kayıt edildiği yapıdır.

Recovery ve consistency açısından kritik öneme sahiptir.

Transaction Log Maintenance Neden Önemlidir?

Log kontrolsüz büyürse disk alanı tükenebilir.

Disk dolduğunda database transaction kabul edemeyebilir.

Transaction Log Shrink Sürekli Yapılmalı mı?

Hayır.

Log dosyasını sürekli büyütüp küçültmek kötü maintenance yaklaşımıdır.

Doğru sizing ve backup stratejisi kullanılmalıdır.

Transaction Log Backup Neden Önemlidir?

Bazı database sistemlerinde transaction log backup;

PITR,

düşük RPO,

log reuse

için önemlidir.

Recovery Model Nedir?

Özellikle MSSQL gibi platformlarda recovery model database'in transaction log ve restore davranışını etkiler.

Örneğin;

Simple,

Full,

Bulk-Logged

gibi modeller bulunabilir.

Recovery Model Yanlış Seçilirse Ne Olur?

İş ihtiyacıyla uyumsuz recovery model;

gereksiz log büyümesi

veya

istenen noktaya restore edememe

sorunu oluşturabilir.

Database Backup Kontrolü Maintenance'ın Parçası mı?

Kesinlikle.

Bakım planının en önemli bölümlerinden biri backup kontrolüdür.

Backup Job Success Yeterli mi?

Hayır.

Backup job başarılı görünse bile;

backup corrupt,

eksik,

şifre çözümü başarısız

olabilir.

Bu nedenle restore testleri yapılmalıdır.

Database Restore Testi Nasıl Planlanmalı?

Risk bazlı olarak;

test environment,

isolated network,

DR environment

üzerinde restore yapılabilir.

Test sonunda database'in gerçekten açıldığı ve application'ın bağlanabildiği doğrulanmalıdır.

Point-in-Time Recovery Test Edilmeli mi?

Evet.

Özellikle transaction log backup kullanan kritik database sistemlerinde PITR ayrıca test edilmelidir.

Backup Retention Maintenance'ın Bir Parçası mı?

Evet.

Çok kısa retention recovery riskini artırır.

Çok uzun retention ise;

storage maliyeti,

privacy,

regulatory risk

oluşturabilir.

Database Integrity Check Nedir?

Database'in fiziksel ve mantıksal veri yapılarında corruption olup olmadığını kontrol etmeyi amaçlar.

Platforma göre farklı araç ve komutlar kullanılır.

Integrity Check Neden Önemlidir?

Storage üzerinde sessiz corruption oluşabilir.

Database normal çalışıyor gibi görünürken bazı page'ler bozuk olabilir.

Sorun ancak o veriye erişildiğinde ortaya çıkabilir.

Silent Data Corruption Nedir?

Verinin fark edilmeden bozulmasıdır.

Bu;

disk,

controller,

memory,

software

problemlerinden kaynaklanabilir.

Corruption Backup'a Girerse Ne Olur?

Backup alınması corruption'ı düzeltmez.

Bozuk veri backup içerisinde de bulunabilir.

Bu nedenle integrity check ile backup birlikte değerlendirilmelidir.

Backup Verification Nedir?

Backup dosyasının okunabilir ve kullanılabilir olduğunun teknik olarak kontrol edilmesidir.

Ancak verification gerçek restore testinin yerini tamamen tutmaz.

Database Patch Management Nedir?

Database yazılımı ve bağlı bileşenlerin security ve bug fix güncellemelerinin kontrollü şekilde uygulanmasıdır.

Patch Management Neden Maintenance'ın Parçasıdır?

Database maintenance sadece performansla ilgili değildir.

Eski versiyonlar güvenlik açıklarına sahip olabilir.

Bu nedenle bakım planı security patch sürecini de içermelidir.

Database Patch Öncesi Ne Yapılmalı?

Genellikle;

release note incelenmeli,

uyumluluk kontrol edilmeli,

test ortamında denenmeli,

backup alınmalı,

rollback planı hazırlanmalı

ve change kaydı oluşturulmalıdır.

Patch Sonrası Ne Kontrol Edilmeli?

Database service çalışıyor mu?

Application bağlanabiliyor mu?

Replication sağlıklı mı?

Backup job çalışıyor mu?

Performance normal mi?

Bu kontroller yapılmalıdır.

Database Version Upgrade ile Patch Aynı mı?

Hayır.

Patch genellikle mevcut sürüm üzerindeki hata veya security fix'idir.

Version upgrade daha büyük değişiklik olabilir.

Örneğin major version geçişi application compatibility testleri gerektirir.

End-of-Life Database Bakım Sorunu mudur?

Evet.

Vendor desteği biten database security patch alamayabilir.

Bu durumda upgrade planı oluşturulmalıdır.

Database Capacity Management Nedir?

Database'in gelecekte ihtiyaç duyacağı;

disk,

CPU,

RAM,

IO,

connection

kapasitesinin planlanmasıdır.

Database Disk Dolmadan Önce Alarm Olmalı mı?

Evet.

%100 dolduktan sonra alarm üretmek geç olabilir.

Örneğin;

%70 warning,

%85 critical

gibi eşikler kullanılabilir.

Bu değerler ortama göre değişmelidir.

Data File Growth İzlenmeli mi?

Evet.

Ani büyüme;

application bug,

bulk import,

log problemi,

security incident

göstergesi olabilir.

Autogrowth Nedir?

Database file'ın ihtiyaç olduğunda otomatik büyümesini sağlayan mekanizmadır.

Yanlış autogrowth ayarları performance veya disk sorunlarına yol açabilir.

Çok Küçük Autogrowth Neden Sorun?

Database sürekli küçük parçalar halinde büyür.

Bu;

çok sayıda growth event,

IO overhead

oluşturabilir.

Çok Büyük Autogrowth Neden Sorun?

Bir anda büyük miktarda disk alanı allocate edilebilir.

Disk kapasitesi beklenmedik şekilde tükenebilir.

Database File Sizing Nasıl Yapılmalı?

Geçmiş büyüme trendleri analiz edilerek kapasite planlanmalıdır.

Proaktif büyütme çoğu zaman sürekli reactive autogrowth'tan daha kontrollüdür.

CPU Monitoring Neden Önemlidir?

Sürekli yüksek CPU;

kötü query,

eksik index,

yüksek concurrency,

configuration problemi

göstergesi olabilir.

Memory Monitoring Neden Önemlidir?

Database sistemleri memory yoğun çalışabilir.

Yanlış memory allocation operating system'i etkileyebilir.

Database Tüm RAM'i Kullanmalı mı?

Platform ve mimariye göre limit belirlenmelidir.

Özellikle işletim sistemi ve diğer servisler için memory ayrılmalıdır.

IO Latency Nedir?

Storage read/write işlemlerinin tamamlanma süresidir.

Database performansı için çok kritiktir.

Yüksek IO Latency Ne Anlama Gelir?

Sorun;

storage,

SAN,

cloud disk,

yüksek workload,

kötü query

kaynaklı olabilir.

Database Wait Statistics Nedir?

Query'lerin hangi kaynakları beklediğini gösteren istatistiklerdir.

Örneğin;

CPU,

disk IO,

lock,

network

beklemeleri görülebilir.

Wait Statistics Neden Önemlidir?

Database yavaş olduğunda doğrudan CPU artırmak yerine gerçek bottleneck belirlenebilir.

Bottleneck Nedir?

Sistemin genel performansını sınırlayan en yavaş bileşendir.

Bu;

CPU,

memory,

disk,

network,

query

olabilir.

Database Connection Monitoring Neden Önemlidir?

Connection sayısı artışı application problemi veya saldırı göstergesi olabilir.

Connection Leak Nedir?

Application'ın açtığı database bağlantılarını düzgün kapatmamasıdır.

Zamanla connection pool tükenebilir.

Connection Exhaustion Nedir?

Database'in kabul edebileceği bağlantı sayısının dolmasıdır.

Yeni kullanıcılar bağlanamaz.

Database Session Monitoring Nedir?

Aktif;

user,

query,

connection,

duration

bilgilerinin izlenmesidir.

Idle Connection Zararlı mı?

Belirli miktarda idle connection normal olabilir.

Ancak çok yüksek sayıda gereksiz connection memory tüketebilir.

Database Security Maintenance Nedir?

Database bakımının güvenlik tarafıdır.

Örneğin;

unused account kontrolü,

permission review,

failed login analizi,

patch,

audit kontrolü,

certificate expiry kontrolü

yapılabilir.

Kullanılmayan Database Account'lar Kapatılmalı mı?

Evet.

Eski çalışan veya kullanılmayan application account'ları saldırgan için fırsat oluşturabilir.

Database Access Review Nedir?

Kullanıcıların mevcut yetkilerinin periyodik olarak yeniden değerlendirilmesidir.

Örneğin üç ayda veya altı ayda bir;

kim hangi role sahip,

gerçekten ihtiyacı var mı

incelenebilir.

Privileged Access Review Neden Daha Kritik?

DBA ve high-privilege account'lar çok geniş erişime sahip olduğundan daha sık kontrol edilebilir.

Service Account Maintenance Nasıl Yapılır?

Service account'larda;

password rotation,

permission review,

last usage,

owner,

application mapping

kontrol edilmelidir.

Orphan Account Nedir?

Artık sahibi veya kullanım amacı bilinmeyen hesaptır.

Bu hesaplar security riskidir.

Database Certificate Expiry Neden İzlenmeli?

TLS veya authentication için kullanılan certificate süresi dolarsa application bağlantıları kesilebilir.

Bu nedenle expiry monitoring önemlidir.

Secret Rotation Maintenance'ın Parçası mı?

Evet.

Database credential ve application connection secret'ları risk bazlı şekilde rotate edilebilir.

Database Audit Log Maintenance Nedir?

Audit log'ların;

aktif,

erişilebilir,

yeterli retention'a sahip

olduğunun kontrol edilmesidir.

Audit Log Disk Doldurabilir mi?

Evet.

Yanlış retention veya logging seviyesi disk tüketebilir.

Bu nedenle log lifecycle planı yapılmalıdır.

Database Logları SIEM'e Gönderilmeli mi?

Kritik sistemlerde güçlü şekilde önerilir.

Merkezi izleme sayesinde;

failed login,

privilege change,

suspicious query,

admin activity

tespit edilebilir.

Failed Login Maintenance Raporunda Olmalı mı?

Evet.

Özellikle ani artışlar;

brute force,

credential problemi,

application configuration hatası

göstergesi olabilir.

Database Backup Failure Güvenlik Olayı Sayılabilir mi?

Kritik sistemlerde evet.

Backup'ın günlerce çalışmaması kurumun recovery kapasitesini düşürür.

Bu nedenle sadece operasyonel ticket olarak değerlendirilmemelidir.

Replication Monitoring Maintenance'ın Parçası mı?

Evet.

Replica görünürde online olabilir ancak ciddi lag oluşmuş olabilir.

Replication Lag Nedir?

Primary ile replica arasındaki veri gecikmesidir.

Örneğin primary 14:00 verisindeyken replica 13:40'ta olabilir.

Bu durumda gerçek RPO 20 dakikadır.

Replication Lag Neden Artar?

Nedenleri;

network,

IO,

CPU,

yüksek transaction hacmi,

slow apply

olabilir.

HA Cluster Maintenance Neleri Kapsar?

Node health,

quorum,

replication,

failover test,

patch seviyeleri

kontrol edilmelidir.

Failover Testi Bakım Sürecine Dahil mi?

Evet.

HA sisteminin gerçekten failover yapabildiği test edilmelidir.

Automatic Failover Her Zaman Güvenilir mi?

Test edilmediyse bilinemez.

Yanlış configuration gerçek arıza sırasında failover'ın çalışmamasına neden olabilir.

Database DR Testi Ne Sıklıkla Yapılmalı?

Sistem kritikliğine göre belirlenmelidir.

Örneğin Tier 1 database'lerde daha sık test yapılabilir.

Database Maintenance ve Change Management

Bakım işlemleri kontrolsüz yapılmamalıdır.

Özellikle production ortamında;

index rebuild,

configuration change,

patch,

restart

change management kapsamında yürütülebilir.

Acil Database Değişikliği Nasıl Yönetilmeli?

Emergency Change prosedürü kullanılabilir.

Ancak acil durum bile audit trail olmadan yapılmamalıdır.

Bakım Öncesi Backup Alınmalı mı?

Riskli değişikliklerden önce güncel backup veya restore point bulunması önemlidir.

Maintenance Sonrası Validation Nedir?

Bakım sonrası sistemin doğru çalıştığının doğrulanmasıdır.

Örneğin;

database online,

application connected,

backup job healthy,

replication synchronized,

performance normal

kontrol edilir.

Maintenance Script Kullanılabilir mi?

Evet.

Rutin bakım otomasyonla yapılabilir.

Ancak script;

test edilmeli,

version control altında tutulmalı,

log üretmeli,

hata yönetimi içermelidir.

Database Maintenance Automation Neden Faydalı?

Manuel işlemler unutulabilir.

Automation;

standardization,

consistency,

auditability

sağlar.

Automation Riski Var mı?

Evet.

Yanlış script aynı hatayı yüzlerce database'e uygulayabilir.

Bu nedenle otomasyon güçlü kontrol gerektirir.

Production'da Script Önce Nerede Test Edilmeli?

Development veya staging ortamında test edilmelidir.

Database Maintenance Checklist Kullanılmalı mı?

Evet.

Checklist operasyon standartlarını artırır.

Örneğin günlük kontrol listesinde:

Backup başarılı mı?

Disk yeterli mi?

Replication healthy mi?

Critical alert var mı?

bulunabilir.

Günlük Database Bakım Kontrolü

Örnek günlük kontroller:

• Database service status
• Backup job status
• Disk capacity
• Replication status
• Failed login
• Critical error log
• CPU ve memory trendi
• Long-running query
• Blocking session

Haftalık Database Bakım Kontrolü

Örnek:

• Index health
• Statistics
• Growth trend
• Slow query review
• Backup verification
• Log review
• Capacity trend

Aylık Database Bakım Kontrolü

Örnek:

• Patch review
• User and role review
• Security configuration review
• Certificate expiry
• Restore test plan
• Performance baseline comparison
• Vulnerability findings

Üç Aylık Database Bakım Kontrolü

Örnek:

• Full restore test
• DR test
• Privileged access review
• Capacity forecast
• Security assessment
• Documentation review

Bu periyotlar yalnızca örnektir.

Database Maintenance Report Nedir?

Yapılan bakım işlemlerinin ve sistem sağlığının raporlandığı dokümandır.

Maintenance Report Neleri İçermeli?

Örneğin;

backup durumu,

storage,

performance,

patch,

security,

open issue,

capacity risk

gösterilebilir.

Yönetim Teknik Rapor mu Görmeli?

Üst yönetime raw database log göstermek çoğu zaman anlamlı değildir.

Yönetim için;

risk,

availability,

capacity,

RPO/RTO,

açık kritik sorun

özetlenmelidir.

Database Health Score Oluşturulabilir mi?

Evet.

Örneğin;

backup,

performance,

capacity,

security,

patch,

HA

başlıkları puanlanabilir.

Database Maintenance ile Database Monitoring Aynı mı?

Hayır.

Monitoring sürekli gözlemdir.

Maintenance ise tespit edilen veya planlanan işlemlerin uygulanmasıdır.

Monitoring:

“Disk %90 oldu.”

der.

Maintenance:

“Disk kapasitesi artırıldı ve growth policy düzeltildi.”

der.

Database Monitoring 7x24 Olmalı mı?

Kritik sistemlerde evet.

24x7 çalışan uygulamanın database monitoring'i sadece mesai saatlerinde olmamalıdır.

Database Alert Her Zaman Incident mı?

Hayır.

Bazı alarmlar warning olabilir.

Severity sınıflandırması yapılmalıdır.

Alarm Fatigue Nedir?

Çok fazla gereksiz alarm nedeniyle ekiplerin kritik alarmı gözden kaçırmasıdır.

Database monitoring'de threshold'lar doğru ayarlanmalıdır.

Performance Baseline Neden Önemlidir?

Normal çalışma seviyeleri bilinmezse anomalileri tespit etmek zorlaşır.

Örneğin %70 CPU normal mi?

Sistemin geçmiş davranışına göre değişir.

Database Maintenance ile Güvenlik Arasındaki Doğrudan İlişki

Bakımı yapılmayan database;

patchsiz,

backup'sız,

disk kapasitesi düşük,

eski account'larla dolu

hale gelebilir.

Bu nedenle maintenance doğrudan security posture'u etkiler.

Ransomware Database Maintenance'ı Nasıl Etkiler?

Ransomware senaryosunda;

backup health,

immutable copy,

restore testing,

credential security

kritik hale gelir.

Düzenli maintenance yapılmayan ortam saldırı sonrası recovery'de başarısız olabilir.

Database Backup Immutable Olmalı mı?

Kritik database'lerde güçlü şekilde değerlendirilmelidir.

Backup administrator hesabı ele geçirilse bile belirli restore point'ler silinememelidir.

Database Maintenance ile RPO İlişkisi

Backup ve replication düzgün çalışmıyorsa hedeflenen RPO kağıt üzerinde kalır.

Örneğin hedef RPO:

15 dakika

ancak transaction log backup son 6 saattir çalışmıyorsa gerçek RPO çok daha kötüdür.

Database Maintenance ile RTO İlişkisi

Restore testi yapılmayan database'in gerçek RTO'su bilinmez.

Bu nedenle maintenance raporu gerçek restore sürelerini içermelidir.

Database Maintenance ve Business Continuity

Database kritik iş süreçlerini desteklediği için bakım doğrudan iş sürekliliğiyle ilişkilidir.

Disk dolması küçük teknik sorun gibi görülebilir.

Ancak ERP database'ini durdurursa iş sürekliliği problemine dönüşür.

Database Maintenance ve ISO/IEC 27001

ISO/IEC 27001 yaklaşımında sistemlerin güvenli işletimi, vulnerability management, backup, logging ve continuity risk bazlı olarak ele alınır.

Database bakım süreçleri bu kontrollerin günlük teknik uygulamasını destekler.

Database Maintenance ve KVKK

Kişisel veri içeren database sistemlerinde;

erişim kontrolü,

loglama,

backup,

security patch,

data retention

bakım süreçlerinin parçası olmalıdır.

Database Maintenance ve PCI DSS

Kart verisi içeren sistemlerde;

security patch,

logging,

access review,

backup security,

vulnerability management

daha kritik hale gelir.

Database Maintenance Outsource Edilebilir mi?

Evet.

Kurum database operasyonunu uzman servis sağlayıcıdan alabilir.

Ancak sorumluluk tamamen ortadan kalkmaz.

SLA ve görev kapsamı net olmalıdır.

Database Managed Service Neleri Kapsayabilir?

Örneğin;

7x24 monitoring,

backup management,

performance tuning,

patch,

capacity management,

incident response,

health check

kapsanabilir.

Database SLA Nasıl Belirlenmeli?

Sistem kritikliğine göre;

response time,

availability,

backup monitoring,

incident resolution

hedefleri tanımlanabilir.

DBA Bakımında Dokümantasyon Neden Önemlidir?

Bir DBA kurumdan ayrıldığında sistem bilgisi kaybolmamalıdır.

Bu nedenle;

architecture,

maintenance plan,

backup policy,

recovery procedure,

critical configuration

dokümante edilmelidir.

Runbook Nedir?

Database operasyonlarında belirli olaylarda uygulanacak adımların dokümante edildiği teknik prosedürdür.

Örneğin:

Transaction log dolduğunda ne yapılacak?

Replica offline olduğunda ne yapılacak?

Backup başarısız olduğunda hangi ekip çağrılacak?

Database Maintenance Runbook Neleri İçerebilir?

• Daily health check
• Backup failure procedure
• Disk full procedure
• Replication lag procedure
• Performance issue procedure
• Deadlock investigation
• Restore procedure
• Emergency access process

Tek Bir DBA'ya Bağımlılık Riskli mi?

Evet.

Critical database bilgisi tek kişide bulunmamalıdır.

Cross-training ve dokümantasyon uygulanmalıdır.

Database Maintenance İçin En Önemli KPI'lar

Örneğin:

Database Availability

Backup Success Rate

Restore Success Rate

RPO Compliance

RTO Compliance

Patch Compliance

Critical Incident Count

Storage Growth

Slow Query Count

Replication Lag

Backup Success Rate Tek Başına Yeterli mi?

Hayır.

Restore Success Rate ile birlikte değerlendirilmelidir.

Patch Compliance Nedir?

Belirlenen security patch seviyesinde bulunan database sistemlerinin oranıdır.

Capacity Forecast Nedir?

Geçmiş büyümeye bakarak gelecekte storage ihtiyacının tahmin edilmesidir.

Örneğin database ayda 500 GB büyüyorsa 12 aylık kapasite ihtiyacı tahmin edilebilir.

Database Bakımında En Sık Yapılan Hatalar

Kurumlarda sık görülen hatalar şunlardır:

• Database sadece sorun çıktığında kontrol etmek
• Her gece tüm index'leri rebuild etmek
• Statistics durumunu izlememek
• Autovacuum'u yanlış yapılandırmak
• Transaction log büyümesini görmezden gelmek
• Backup job success'i restore garantisi sanmak
• Restore testi yapmamak
• Patch'leri sürekli ertelemek
• Disk kapasitesini son anda fark etmek
• Replication lag izlememek
• Slow query trendlerini takip etmemek
• Kullanılmayan account'ları kapatmamak
• Audit log retention'ı planlamamak
• Change management olmadan production değişikliği yapmak
• Maintenance sonucunu raporlamamak

Kurumsal Database Maintenance Kontrol Listesi

Bir kurum şu sorulara net cevap verebilmelidir:

Database envanterimiz güncel mi?

Her database'in owner'ı belli mi?

Backup her gün kontrol ediliyor mu?

Restore testleri yapılıyor mu?

Transaction log sağlıklı mı?

Disk büyümesi izleniyor mu?

Replication lag takip ediliyor mu?

Statistics güncel mi?

Index yapıları analiz ediliyor mu?

Slow query monitoring var mı?

Deadlock kayıtları inceleniyor mu?

Patch seviyesi güncel mi?

Kullanılmayan account'lar kapatılıyor mu?

Privileged access review yapılıyor mu?

Audit loglar izleniyor mu?

Bakım sonrası validation yapılıyor mu?

Bu sorulara net cevap verilemiyorsa database maintenance süreci olgun değildir.

Database Maintenance için Örnek Operasyon Modeli

Kurumsal bir yapı şu şekilde oluşturulabilir:

7x24 Monitoring

↓

Daily Health Check

↓

Backup & Replication Verification

↓

Performance Analysis

↓

Weekly Maintenance

↓

Monthly Security & Patch Review

↓

Quarterly Restore / DR Test

↓

Capacity & Risk Reporting

Bu model database operasyonunu reaktif olmaktan çıkarıp proaktif hale getirir.

Reaktif DBA ile Proaktif DBA Arasındaki Fark

Reaktif yaklaşım:

“Database durdu, müdahale edelim.”

Proaktif yaklaşım:

“Disk büyüme trendine göre 45 gün sonra kapasite riski oluşacak.”

İyi database maintenance ikinci yaklaşımı hedefler.

Database Maintenance Maturity Nasıl Ölçülebilir?

Örnek olgunluk seviyeleri:

Seviye 1 – Reaktif

Sorun olunca müdahale edilir.

Seviye 2 – Temel Bakım

Backup ve bazı rutin işler yapılır.

Seviye 3 – Standart

Maintenance plan ve monitoring bulunur.

Seviye 4 – Ölçülen

RPO, RTO, performance ve capacity KPI'ları ölçülür.

Seviye 5 – Proaktif

Trend analizi, otomasyon ve sürekli iyileştirme uygulanır.

Sık Sorulan Sorular

Database maintenance nedir?

Veritabanının performanslı, güvenli, bütünlüklü ve erişilebilir çalışmasını sağlayan düzenli bakım süreçlerinin tamamıdır.

Veritabanı bakımı ne sıklıkla yapılmalı?

Tek bir süre yoktur. Günlük monitoring ve backup kontrolünden yıllık major review'a kadar farklı periyotlar kullanılabilir.

Index rebuild her gün yapılmalı mı?

Genellikle hayır. Gerçek ihtiyaç analiz edilerek yapılmalıdır.

Statistics neden güncellenir?

Query optimizer'ın daha doğru execution plan seçmesini sağlar.

Database integrity check neden önemlidir?

Data corruption'ın kullanıcıyı etkilemeden önce tespit edilmesine yardımcı olabilir.

Database backup almak yeterli mi?

Hayır. Restore test edilmelidir.

Database transaction log neden büyür?

Yüksek transaction hacmi, backup veya configuration problemleri nedeniyle büyüyebilir.

PostgreSQL VACUUM nedir?

MVCC nedeniyle oluşan eski row version'larının yönetilmesine yardımcı olan temel maintenance mekanizmasıdır.

Database patch ne zaman yapılmalı?

Risk, vendor güncellemeleri, application compatibility ve change süreçleri dikkate alınarak planlanmalıdır.

Database maintenance güvenlikle ilgili midir?

Evet. Patch, user review, backup, audit, credential ve configuration kontrolleri database security'nin önemli parçalarıdır.

Sonuç: Sağlıklı Bir Database Tesadüfen Sağlıklı Kalmaz

Database sistemleri kurumların en kritik teknoloji bileşenlerinden biridir.

Ancak birçok kurum database bakımını yalnızca;

“Database yavaşladığında bakalım.”

yaklaşımıyla yönetmektedir.

Bu yaklaşım yeterli değildir.

Çünkü database problemleri çoğu zaman bir anda ortaya çıkmış gibi görünse de aslında haftalar veya aylar boyunca gelişmiş olabilir.

Örneğin;

disk yavaş yavaş dolar,

transaction log büyür,

statistics eskir,

query süreleri artar,

backup job hata verir,

replication lag büyür,

security patch seviyesi geride kalır.

Bunların tamamı doğru monitoring ve maintenance ile önceden tespit edilebilir.

Bu nedenle iyi bir database bakım modeli;

Backup Management,

Restore Testing,

Index Maintenance,

Statistics Management,

Integrity Check,

Transaction Log Management,

Performance Monitoring,

Capacity Planning,

Patch Management,

Security Review

ve DR Testing

süreçlerini birlikte ele almalıdır.

En önemli prensip şudur:

Database bakımının amacı yalnızca sistemi bugün çalıştırmak değil, yarın da güvenilir şekilde çalışmasını sağlamaktır.

Kurumsal olgunluk şu cümleyle ölçülebilir:

“Database'imiz çalışıyor.”

demek yerine;

“Database'imizin performansını, kapasitesini, backup durumunu, recovery kabiliyetini ve güvenlik seviyesini sürekli ölçüyor ve doğruluyoruz.”

diyebiliyor olmak gerekir.

Gerçek database maintenance budur.