# Database Performans ve Güvenlik Bakımı: Index, Query, Patch ve Kapasite Yönetimi **URL:** https://securesys.com.tr/tr/bilgi-merkezi/veritabani-guvenligi/database-performans-ve-guvenlik-bakimi ![Database Performans ve Güvenlik Bakımı: Index, Query, Patch ve Kapasite Yönetimi](/images/bilgi-merkezi/covers/cover-veritabani-11.webp) Bir veritabanı güvenli olabilir ancak yavaşsa iş süreçlerini aksatabilir. Aynı şekilde yüksek performanslı bir database yanlış yapılandırılmışsa ciddi güvenlik riski taşıyabilir. Bu nedenle kurumsal database yönetiminde performans ve güvenlik birbirinden tamamen ayrı düşünülemez. Örneğin; disk dolarsa database durabilir, transaction log büyürse servis kesilebilir, CPU sürekli %100 çalışırsa saldırı ile normal yoğunluk ayırt edilemeyebilir, uzun süren query'ler diğer işlemleri bloklayabilir, patch uygulanmazsa bilinen zafiyetler açık kalabilir, index bakımı yapılmazsa response time artabilir, backup süresi uzarsa recovery hedefleri bozulabilir. Bu nedenle modern database maintenance yaklaşımı şu dört alanı birlikte ele almalıdır: #### Performance #### Security #### Availability #### Capacity Veritabanı performans yönetimi yalnızca “query daha hızlı çalışsın” konusu değildir. Asıl hedef; database'in öngörülebilir, istikrarlı, güvenli ve sürdürülebilir şekilde çalışmasıdır. ### Database Performance Nedir? Database Performance, veritabanının sorguları ve transaction'ları kabul edilebilir sürede ve kaynak tüketimiyle işleyebilme yeteneğidir. Performans değerlendirilirken; response time, throughput, CPU, memory, disk IO, query duration, connection count gibi göstergeler izlenebilir. ### Database Performance ile Güvenlik Arasında Nasıl Bir İlişki Var? Kötü performans doğrudan vulnerability olmayabilir. Ancak birçok güvenlik ve iş sürekliliği riskini büyütebilir. Örneğin database kaynakları sürekli sınırda çalışıyorsa küçük bir saldırı veya beklenmeyen workload bile outage oluşturabilir. ### Yavaş Database Güvenlik Riski midir? Dolaylı olarak evet. Çünkü; availability azalır, DoS etkisi kolaylaşabilir, backup penceresi uzar, patch süreci ertelenebilir, monitoring sistemleri daha fazla false positive üretebilir. ### Database Maintenance Neden Performans İçin Kritiktir? Database sürekli değişir. Veri büyür. Index'ler değişir. Statistics eskiyebilir. Query pattern'leri farklılaşabilir. Bu nedenle ilk kurulumda hızlı çalışan database yıllar sonra aynı performansı göstermeyebilir. ### Performance Baseline Nedir? Database'in normal çalışma davranışının ölçülerek referans oluşturulmasıdır. Örneğin: CPU: %30–40 Average Query Time: 120 ms Active Connections: 150 Disk Latency: 4 ms gibi değerler baseline olabilir. ### Baseline Neden Önemlidir? Normal davranış bilinmeden anomaly tespit etmek zorlaşır. CPU %80 yüksek görünebilir. Ancak bazı sistemlerde bu normal olabilir. ### Baseline Security İçin de Kullanılabilir mi? Evet. Normal query hacmi veya connection davranışı biliniyorsa anormal durumlar daha kolay tespit edilir. ### Database Monitoring Nedir? Database sağlık ve performans göstergelerinin sürekli izlenmesidir. ### Monitoring Hangi Metrikleri İçermeli? Örneğin: CPU Memory Disk Usage IO Latency Query Duration Connection Count Locks Deadlocks Replication Lag Backup Status ### Monitoring ile Maintenance Aynı mı? Hayır. Monitoring problemi görür. Maintenance problemi azaltmaya veya önlemeye çalışır. ### Index Nedir? Index database'in belirli kayıtları daha hızlı bulmasını sağlayan veri yapısıdır. Bir kitabın indeksine benzetilebilir. ### Index Neden Performansı Artırır? Database milyonlarca satırın tamamını okumak yerine uygun index üzerinden ilgili kayıtlara ulaşabilir. ### Her Kolona Index Eklemek İyi mi? Hayır. Fazla index; storage tüketir, INSERT/UPDATE performansını düşürür, maintenance süresini artırır. ### Index Maintenance Nedir? Index yapılarının düzenli olarak incelenmesi ve gerekli bakım işlemlerinin yapılmasıdır. ### Index Fragmentation Nedir? Index sayfalarının zaman içinde optimal olmayan fiziksel veya mantıksal düzene gelmesidir. ### Fragmentation Neden Oluşur? Sık; INSERT, UPDATE, DELETE işlemleri nedeniyle oluşabilir. ### Fragmentation Her Database Platformunda Aynı mı? Hayır. Index mimarisi ve maintenance yaklaşımı PostgreSQL, MSSQL ve Oracle arasında farklılık gösterebilir. ### Index Rebuild Nedir? Index'in yeniden oluşturulmasıdır. ### Index Reorganize Nedir? Bazı platformlarda index yapısının daha hafif bir maintenance işlemiyle düzenlenmesidir. ### Her Index Düzenli Rebuild Edilmeli mi? Hayır. Gereksiz rebuild; IO, CPU, transaction log yükü oluşturabilir. ### Risk-Based Index Maintenance Nedir? Index boyutu, fragmentation ve workload dikkate alınarak maintenance yapılmasıdır. ### PostgreSQL Index Maintenance Nasıl Ele Alınır? PostgreSQL'de MVCC mimarisi nedeniyle vacuum, autovacuum, analyze ve bloat gibi kavramlar performans için önemlidir. ### PostgreSQL MVCC Nedir? MVCC: #### Multi-Version Concurrency Control eş zamanlı transaction'ların birbirini mümkün olduğunca az bloklamasını sağlayan bir mimaridir. ### PostgreSQL'de Dead Tuple Nedir? UPDATE veya DELETE sonrası eski row version'larının bir süre fiziksel olarak kalmasıdır. ### Dead Tuple Neden Problem Olabilir? Büyüdükçe; storage, query performance, maintenance etkilenebilir. ### VACUUM Nedir? Artık gerekli olmayan row version'larının temizlenmesine ve database'in sağlıklı çalışmasına yardımcı olan PostgreSQL maintenance işlemidir. ### Autovacuum Nedir? PostgreSQL'in vacuum ve analyze işlemlerini otomatik gerçekleştiren mekanizmasıdır. ### Autovacuum Kapatılmalı mı? Genellikle hayır. Yanlış tuning yapılabilir ancak tamamen devre dışı bırakılması ciddi sorunlara yol açabilir. ### PostgreSQL Bloat Nedir? Table veya index'in kullanılmayan alanlar nedeniyle gereğinden fazla büyümesidir. ### Bloat Performansı Etkiler mi? Evet. Disk IO ve cache verimliliğini etkileyebilir. ### ANALYZE Nedir? Database optimizer'ın query plan oluşturmak için kullandığı statistics bilgisini günceller. ### MSSQL Statistics Neden Önemlidir? Query Optimizer hangi execution plan'ın daha uygun olduğunu statistics üzerinden değerlendirir. ### Statistics Eski Olursa Ne Olur? Optimizer yanlış cardinality tahmini yapabilir. Sonuçta kötü query plan seçilebilir. ### Oracle Statistics Neden Önemlidir? Oracle optimizer da table ve index statistics üzerinden execution plan oluşturur. ### Statistics Maintenance Otomatik Olabilir mi? Evet. Ancak çok kritik workload'larda otomatik işlemlerin davranışı izlenmelidir. ### Query Optimization Nedir? SQL sorgularının daha az kaynak tüketerek ve daha hızlı çalışmasını sağlamaya yönelik iyileştirme sürecidir. ### Slow Query Nedir? Beklenen süreden daha uzun çalışan query'dir. ### Her Uzun Query Kötü müdür? Hayır. Örneğin aylık finansal rapor doğal olarak uzun sürebilir. Context gereklidir. ### Slow Query Log Nedir? Belirli sürenin üzerinde çalışan query'lerin kayıt altına alınmasıdır. ### Slow Query Monitoring Neden Faydalıdır? Performance regression'ı erken tespit etmeye yardımcı olur. ### Execution Plan Nedir? Database optimizer'ın query'yi nasıl çalıştıracağını gösteren plandır. ### Execution Plan Neleri İçerebilir? Örneğin: Index Scan Table Scan Join Sort Aggregate gibi adımlar. ### Full Table Scan Her Zaman Kötü mü? Hayır. Küçük tabloda full scan index kullanmaktan daha hızlı olabilir. ### Query Plan Neden Değişebilir? Statistics, data volume, parameter, index değişiklikleri nedeniyle optimizer farklı plan seçebilir. ### Query Plan Regression Nedir? Daha önce hızlı çalışan query'nin yeni execution plan nedeniyle yavaşlamasıdır. ### Performance Regression Nasıl Tespit Edilir? Baseline ve historical monitoring ile. ### Query Store Nedir? Bazı database platformlarında query performansı ve execution plan geçmişini saklayan mekanizmadır. ### Query Store Ne İşe Yarar? Bir query'nin hangi plan değişikliğinden sonra yavaşladığını anlamayı kolaylaştırabilir. ### N+1 Query Problemi Nedir? Application'ın tek sorguyla yapılabilecek işi çok sayıda küçük query ile gerçekleştirmesidir. ### N+1 Database'i Nasıl Etkiler? Connection ve query sayısını artırarak database yükünü büyütür. ### N+1 Security Sorunu mudur? Doğrudan değil. Ancak resource exhaustion ve availability riskini artırabilir. ### Query Timeout Nedir? Bir sorgunun maksimum çalışma süresini sınırlayan mekanizmadır. ### Query Timeout Faydalı mı? Yanlış veya çok ağır query'nin sistemi uzun süre kilitlemesini önlemeye yardımcı olabilir. ### Timeout Çok Kısa Olursa Ne Olur? Normal işlemler başarısız olabilir. ### Long-Running Transaction Nedir? Uzun süre açık kalan transaction'dır. ### Long-Running Transaction Neden Risklidir? Lock, transaction log growth, vacuum delay, replication lag oluşturabilir. ### Idle Transaction Nedir? Transaction açık olduğu halde uzun süre işlem yapılmamasıdır. ### PostgreSQL Idle in Transaction Neden Önemlidir? Uzun süre açık kalırsa vacuum ve resource kullanımını olumsuz etkileyebilir. ### Lock Nedir? Aynı veriye eş zamanlı erişimde consistency sağlamak için kullanılan mekanizmadır. ### Lock Security Problemi mi? Normal database davranışıdır. Ancak aşırı lock availability problemi oluşturabilir. ### Blocking Nedir? Bir transaction'ın diğer transaction'ın tuttuğu lock nedeniyle beklemesidir. ### Blocking Chain Nedir? Bir session başka session'ı, o da başka session'ı bloklayabilir. Bu zincir database'i ciddi şekilde yavaşlatabilir. ### Deadlock Nedir? İki veya daha fazla transaction'ın birbirlerinin tuttuğu kaynağı beklemesi durumudur. ### Database Deadlock'u Nasıl Çözer? Genellikle transaction'lardan birini sonlandırarak deadlock'u kırar. ### Deadlock Loglanmalı mı? Evet. Sürekli deadlock application veya query design problemi gösterebilir. ### Deadlock Saldırı Göstergesi Olabilir mi? Çoğunlukla application problemi olsa da unusual workload veya resource abuse kapsamında incelenebilir. ### Connection Management Nedir? Database'e açılan client connection'ların kontrollü yönetilmesidir. ### Çok Fazla Connection Neden Problem? Her connection memory ve diğer kaynaklar tüketebilir. ### Connection Exhaustion Nedir? Database'in yeni client kabul edemeyecek kadar fazla connection'a ulaşmasıdır. ### Connection Exhaustion DoS Etkisi Oluşturabilir mi? Evet. ### Connection Limit Security Kontrolü Olabilir mi? Evet. Belirli user veya application için connection limit kaynak tüketimini sınırlandırabilir. ### Connection Pool Nedir? Application'ın sürekli yeni connection açmak yerine mevcut connection'ları tekrar kullanmasıdır. ### Connection Pool Avantajı Nedir? Connection overhead'i azaltır. ### Connection Pool Yanlış Ayarlanırsa Ne Olur? Her application instance çok büyük pool açarsa toplam connection sayısı database kapasitesini aşabilir. ### Pool Size Nasıl Belirlenmeli? Application instance sayısı ve database kapasitesi birlikte değerlendirilmelidir. ### Connection Leak Nedir? Application'ın açtığı connection'ı geri kapatmaması veya pool'a döndürmemesidir. ### Connection Leak Nasıl Tespit Edilir? Connection sayısının sürekli yükselmesi ve idle session'ların artmasıyla görülebilir. ### CPU Database Performance İçin Ne İfade Eder? Query execution, encryption, compression ve transaction işlemlerinde kullanılır. ### Sürekli %100 CPU Problem midir? Evet. Sistem yeni workload'a cevap veremeyebilir. ### CPU Spike Saldırı Olabilir mi? Olabilir. Ancak kötü query veya batch job da neden olabilir. ### CPU Alarmı Tek Başına Yeterli mi? Hayır. Query, user ve application context'iyle değerlendirilmelidir. ### Memory Database İçin Neden Önemlidir? Database engine data ve execution plan'ları memory'de cache edebilir. ### Buffer Cache Nedir? Diskten okunan data page'lerinin memory'de tutulduğu alandır. ### Cache Hit Ratio Nedir? İhtiyaç duyulan verinin ne kadarının disk yerine memory'den karşılandığını gösteren göstergelerden biridir. ### Cache Hit Ratio Tek Başına Performance KPI mı? Hayır. Diğer metriklerle birlikte değerlendirilmelidir. ### Memory Pressure Nedir? Database'in ihtiyaç duyduğu memory miktarının available memory'yi aşmasıdır. ### Memory Pressure Ne Oluşturur? Daha fazla disk IO ve query slowdown. ### Swap Kullanımı Database İçin Riskli mi? Aşırı swap ciddi performance problemi oluşturabilir. ### Disk IO Database İçin Neden Kritik? Database büyük miktarda data file ve log okuma/yazma işlemi yapar. ### IOPS Nedir? Saniyede gerçekleştirilebilen input/output operation sayısıdır. ### Throughput Nedir? Belirli sürede taşınabilen veri miktarıdır. ### Latency Nedir? IO işleminin tamamlanması için geçen süredir. ### Yüksek Disk Latency Ne Yapar? Query ve transaction sürelerini artırır. ### Database Data File ile Log File Aynı Diskte Olmalı mı? Mimariye göre ayrılması performance ve failure domain açısından avantaj sağlayabilir. ### Temp Storage Nedir? Sort ve temporary operation'ların kullandığı geçici disk alanıdır. ### Temp Storage Dolarsa Ne Olur? Query failure veya database performance problemi oluşabilir. ### MSSQL TempDB Neden Kritik? Birçok temporary operation ve versioning işlemi TempDB kullanır. ### Oracle TEMP Tablespace Neden Kritik? Sort ve temporary workload'larda kullanılır. ### PostgreSQL Temporary File Monitoring Neden Önemlidir? Aşırı temp file üretimi insufficient memory veya kötü query göstergesi olabilir. ### Disk Capacity Management Nedir? Database storage büyümesinin sürekli izlenmesi ve gelecekteki ihtiyacın planlanmasıdır. ### Disk Dolarsa Database Ne Olur? Transaction'lar başarısız olabilir. Database servis kesintisi yaşayabilir. Bazı durumlarda recovery karmaşıklaşabilir. ### Disk Full Güvenlik Riski midir? Availability açısından evet. Ayrıca saldırgan log veya storage tüketerek DoS etkisi oluşturabilir. ### Capacity Alert Kaçta Verilmeli? Kurum workload'una göre belirlenmelidir. Amaç %100 dolmadan operasyon ekibine yeterli müdahale süresi sağlamaktır. ### Storage Growth Trend Nedir? Database'in günlük, haftalık veya aylık ne kadar büyüdüğünün izlenmesidir. ### Capacity Forecasting Nedir? Mevcut büyüme hızına göre storage'ın ne zaman dolacağını tahmin etmektir. ### Örnek Capacity Forecast Mevcut boş alan: 2 TB. Aylık büyüme: 400 GB. Yaklaşık beş ay içinde storage kapasitesi sınırına yaklaşılabilir. Bu bilgi proaktif kapasite planlaması sağlar. ### Auto-Growth Nedir? Database file'ın ihtiyaç olduğunda otomatik büyümesidir. ### Auto-Growth Güvenlik Çözümü müdür? Hayır. Sadece operasyonel mekanizmadır. ### Auto-Growth Yanlış Ayarlanırsa Ne Olur? Çok küçük growth; sürekli file expansion. Çok büyük growth; ani disk tüketimi. ### Transaction Log Growth Neden Kritik? Transaction log kontrolsüz büyürse disk dolabilir. ### MSSQL Transaction Log Neden Büyür? Örneğin; log backup alınmaması, uzun transaction, replication problemi neden olabilir. ### Log Shrink Sürekli Yapılmalı mı? Hayır. Sürekli shrink/grow cycle performans problemi oluşturabilir. ### PostgreSQL WAL Büyümesi İzlenmeli mi? Evet. Replication veya archiving problemi WAL storage büyümesine yol açabilir. ### Oracle Archive Destination Dolarsa Ne Olur? Database transaction işlemleri etkilenebilir ve kritik outage oluşabilir. ### Capacity Planning Backup'ı Etkiler mi? Evet. Database büyüdükçe backup süresi ve storage ihtiyacı artar. ### Backup Window Capacity Planning'e Dahil mi? Evet. 10 TB database zamanla 40 TB'a çıkarsa eski backup mimarisi RTO hedefini karşılamayabilir. ### Database Growth RTO'yu Nasıl Etkiler? Restore edilecek veri miktarı büyüdükçe recovery süresi artabilir. ### Performance ve RTO Birbirine Bağlı mı? Evet. Yavaş storage recovery sırasında RTO breach oluşturabilir. ### Patch Management Nedir? Database ve ilgili bileşenlerin güvenlik ve bug fix güncellemelerinin kontrollü uygulanmasıdır. ### Database Patch Neden Kritik? Bilinen security vulnerability'leri kapatabilir. ### “Çalışıyor, Dokunmayalım” Yaklaşımı Riskli mi? Evet. Yıllarca patch uygulanmayan database sistemleri bilinen zafiyetlere açık kalabilir. ### Patch Uygulamak Availability Riski Oluşturur mu? Evet. Bu nedenle change management ve test gerekir. ### Patch Uygulamamak Daha mı Güvenli? Hayır. Amaç patch riskini yönetmek, patch'i tamamen ertelemek değildir. ### Patch Management Süreci Nasıl Olmalı? Örnek akış: Vendor Advisory ↓ Risk Assessment ↓ Test ↓ Change Approval ↓ Backup ↓ Patch ↓ Validation ↓ Monitoring ### Security Patch ile Feature Update Aynı mı? Hayır. Security patch zafiyet düzeltmeye odaklanabilir. Feature update daha geniş değişiklik içerebilir. ### Critical Database Patch Önceliği Nasıl Belirlenir? Vulnerability severity, exploitability, internet exposure, database criticality birlikte değerlendirilmelidir. ### CVE Nedir? CVE: #### Common Vulnerabilities and Exposures bilinen güvenlik açıklarının standart kimliklendirme sistemidir. ### CVSS Nedir? Vulnerability severity değerlendirmesinde kullanılan puanlama sistemidir. ### Yüksek CVSS Her Zaman Acil Patch Demek mi? Business context de değerlendirilmelidir. Ancak kritik ve exploit edilebilir zafiyetler öncelikli ele alınmalıdır. ### Internet-Facing Database Patch Önceliği Daha Yüksek mi? Genellikle evet. Ancak production database'in doğrudan internet exposure'ı zaten minimize edilmelidir. ### Patch Öncesi Backup Gerekli mi? Evet. Rollback veya recovery için doğrulanmış backup önemlidir. ### Patch Öncesi Restore Testi Gerekir mi? Kritik sistemlerde recovery kabiliyetinin doğrulanması faydalıdır. ### Patch Sonrası Ne Test Edilmeli? Database service Application connectivity Authentication Replication Backup Audit Performance ### Patch Sonrası Audit Çalışıyor mu Kontrol Edilmeli mi? Evet. ### Patch Sonrası Encryption Çalışıyor mu? TLS veya encryption configuration etkilenmiş olabilir. Kontrol edilmelidir. ### Patch Sonrası Execution Plan Değişebilir mi? Evet. Database engine davranışı değişebilir. Bu nedenle performance baseline önemlidir. ### Patch Sonrası Performance Regression Nasıl Tespit Edilir? Patch öncesi ve sonrası metrikler karşılaştırılabilir. ### Unsupported Database Version Nedir? Vendor'ın artık security fix sağlamadığı sürümdür. ### EOL Nedir? #### End of Life ürünün destek yaşam döngüsünün sona ermesidir. ### EOL Database Kullanmak Neden Risklidir? Yeni zafiyetler için patch alınamayabilir. ### Database Version Inventory Gerekli mi? Kesinlikle. Hangi server'da hangi version çalıştığı bilinmelidir. ### Patch Compliance KPI Nedir? Database'lerin ne kadarının security baseline ile uyumlu patch seviyesinde olduğunu gösterir. ### Patch SLA Nedir? Security severity'ye göre patch uygulanması gereken maksimum süreyi tanımlar. ### Emergency Patch Nedir? Kritik vulnerability durumunda normal maintenance cycle beklenmeden uygulanan patch'tir. ### Emergency Patch'te Change Management Atlanmalı mı? Hayır. Daha hızlı ancak kontrollü emergency change süreci uygulanabilir. ### Vulnerability Scanner Database'i Tarayabilir mi? Evet. Credentialed veya network-based assessment yapılabilir. ### Credentialed Scan Neden Daha İyi Görünürlük Sağlar? Database version ve configuration daha detaylı analiz edilebilir. ### Vulnerability Scan Production'ı Etkileyebilir mi? Bazı yoğun kontroller risk taşıyabilir. Bu nedenle safe scanning policy kullanılmalıdır. ### Database Security Assessment ile Performance Assessment Birlikte Yapılabilir mi? Evet. Çünkü bazı configuration'lar hem security hem performance etkisi taşır. ### Unused Database Feature Neden Kapatılmalı? Attack surface'i azaltır. Aynı zamanda gereksiz resource kullanımını azaltabilir. ### Excessive Logging Performance'ı Etkileyebilir mi? Evet. Çok detaylı query logging storage ve IO yükü oluşturabilir. ### Logging Kapatılmalı mı? Hayır. Risk bazlı ve optimize edilmiş logging uygulanmalıdır. ### Audit ile Performance Dengesi Nasıl Kurulur? Kritik event'ler detaylı; düşük riskli ve yüksek hacimli event'ler daha kontrollü izlenebilir. ### DAM Database Performance'ı Etkiler mi? Deployment yöntemine göre etkileyebilir. Bu nedenle POC ve performance test yapılmalıdır. ### Encryption Performance'ı Etkiler mi? Evet. TDE, TLS veya field encryption belirli overhead oluşturabilir. ### Security Nedeniyle Encryption Kapatılmalı mı? Hayır. Architecture ve hardware uygun tasarlanmalıdır. ### Performance için Security Kapatmak Doğru mu? Genellikle hayır. Sorunun kaynağı optimize edilmelidir. ### Database Resource Governor Nedir? Bazı database platformlarında workload'un kullanabileceği kaynakları sınırlayan mekanizmadır. ### Resource Limiting Güvenlik İçin Faydalı mı? Evet. Bir user veya workload'un tüm kaynakları tüketmesini önleyebilir. ### Workload Management Nedir? Farklı application ve query workload'larına kaynak önceliği verilmesidir. ### Critical Transaction ile Reporting Aynı Öncelikte Olmalı mı? Her zaman değil. Reporting query production transaction'ları engellememelidir. ### Read Replica Performans İçin Kullanılabilir mi? Evet. Read-heavy workload secondary replica'ya dağıtılabilir. ### Read Replica Security Nasıl Olmalı? Primary kadar güçlü korunmalıdır. Çünkü aynı hassas veriyi içerebilir. ### Reporting Replica Daha Az Güvenli Olabilir mi? Hayır. Data classification açısından aynı veriyi taşıyorsa aynı seviyede korunmalıdır. ### Replica Patch Edilmeli mi? Evet. ### Replica Backup Gerekli mi? Mimariye göre backup source olarak kullanılabilir. Ancak replication backup yerine geçmez. ### Replication Lag Performance Göstergesi midir? Evet. Ayrıca DR readiness açısından kritiktir. ### Replication Lag Alarmı Olmalı mı? Evet. ### Replication Lag Neden Artar? Network, IO, heavy query, resource shortage neden olabilir. ### Performance Sorunu Güvenlik Alarmını Gizleyebilir mi? Evet. Sürekli yüksek CPU olan sistemde saldırı kaynaklı CPU spike fark edilmeyebilir. ### Noisy Baseline Nedir? Sürekli dalgalanan ve öngörülemeyen normal davranıştır. ### Stabil Performance Security Detection'ı Güçlendirir mi? Evet. Normal sistem davranışı ne kadar istikrarlıysa anomaly detection o kadar anlamlı olabilir. ### Database Observability Nedir? Metric, log ve trace bilgilerinin birlikte kullanılarak database davranışının anlaşılmasıdır. ### Monitoring ile Observability Farkı Nedir? Monitoring bilinen metrikleri izler. Observability karmaşık problemlerin kök nedenini anlamaya yardımcı olur. ### Database Metrics Nedir? Sayısal sağlık ve performance göstergeleridir. ### Database Logs Nedir? Database olaylarının metinsel veya yapılandırılmış kayıtlarıdır. ### Tracing Database İçin Kullanılabilir mi? Application transaction'ın hangi database query'de yavaşladığını görmek için distributed tracing kullanılabilir. ### APM Nedir? Application Performance Monitoring, uygulamanın performansını uçtan uca izler. ### APM ile Database Monitoring Birlikte Kullanılabilir mi? Evet. Application response time'ın database kaynaklı olup olmadığı anlaşılabilir. ### Example Performance Investigation Application yavaş. ↓ APM transaction süresi yüksek. ↓ Database query 8 saniye. ↓ Execution plan inceleniyor. ↓ Missing index / bad statistics tespit ediliyor. ↓ Optimization yapılıyor. Bu root cause yaklaşımıdır. ### Database Performance Incident Nedir? Database response time veya availability'nin kabul edilebilir seviyenin dışına çıkmasıdır. ### Performance Incident ile Security Incident Aynı Anda Olabilir mi? Evet. Örneğin saldırgan çok ağır query'ler çalıştırarak database kaynaklarını tüketebilir. ### Database DoS Nedir? Database'in aşırı query, connection veya resource tüketimi nedeniyle hizmet verememesidir. ### SQL Injection DoS Oluşturabilir mi? Bazı durumlarda ağır query'ler veya resource abuse ile availability etkilenebilir. ### Rate Limiting Database'i Koruyabilir mi? Doğrudan database'de veya application/API katmanında resource abuse sınırlandırılabilir. ### Query Cost Limiting Nedir? Aşırı pahalı sorguların sınırlandırılması veya kontrol edilmesidir. ### Database Performance Testing Nedir? Beklenen workload altında database'in nasıl davrandığının ölçülmesidir. ### Load Test Nedir? Beklenen kullanıcı veya transaction yükünü simüle eder. ### Stress Test Nedir? Sistemin kapasite sınırlarını görmek için normalden daha yüksek yük uygulanır. ### Load Test Production'da Yapılmalı mı? Kontrolsüz yapılmamalıdır. Staging veya özel performance ortamı tercih edilir. ### Capacity Test Neden Gerekli? Sistemin kaç transaction veya kullanıcıya kadar stabil çalıştığını gösterir. ### Performance Test Security İçin Faydalı mı? Evet. DoS resilience ve resource limitation hakkında bilgi sağlar. ### Database Performance SLO Nedir? Sistem için hedeflenen service level objective'dir. Örneğin: %95 query < 500 ms gibi. ### SLA ile SLO Farkı Nedir? SLO iç hedef olabilir. SLA müşteri veya taraflarla sözleşmesel taahhüt olabilir. ### Performance Alert Threshold Nasıl Belirlenmeli? Statik threshold yanında dynamic baseline kullanılabilir. ### Dynamic Threshold Nedir? Normal geçmiş davranışa göre otomatik değişen alarm seviyesidir. ### Alert Fatigue Performance Monitoring'de de Olur mu? Evet. Her küçük CPU spike için alert üretilirse önemli olaylar gözden kaçabilir. ### Performance Alertleri SOC'a mı Gitmeli? Her event değil. Security ile ilişkili veya kritik availability olayları SIEM/SOC'a iletilebilir. ### DBA ile SOC Nasıl İş Birliği Yapmalı? DBA performance context sağlar. SOC security context sağlar. ### Örnek Ortak Investigation SOC: Gece database CPU %100. DAM: Unusual bulk query. DBA: Query normal batch job değil. Bu durumda security incident ihtimali artar. ### Database Performance Dashboard Neler Göstermeli? Örneğin: CPU Memory IO Latency Active Sessions Slow Queries Locks Deadlocks Storage Usage Replication Lag Backup Duration ### Security Dashboard ile Performance Dashboard Birleştirilmeli mi? En azından critical event korelasyonu yapılabilir. ### Database Health Score Nedir? Birden fazla metric'in tek health göstergesinde birleştirilmesidir. ### Health Score Örneği Performance Capacity Backup Security Patch alanlarının birleşik değerlendirmesi yapılabilir. ### Database Maintenance Window Nedir? Planlı bakım işlemlerinin yapılacağı zaman aralığıdır. ### Maintenance Window'da Neler Yapılabilir? Patch Index Maintenance Statistics Update Configuration Change Backup Validation ### 24x7 Database'de Maintenance Nasıl Yapılır? HA/failover mimarisi, rolling maintenance veya online operasyonlar kullanılabilir. ### Rolling Maintenance Nedir? Cluster node'larının sırayla bakıma alınmasıdır. ### Zero Downtime Patch Gerçekten Sıfır Kesinti mi? Mimariye göre çok düşük kesinti sağlanabilir ancak bağımlılıklar dikkatle test edilmelidir. ### Maintenance İşlemleri Change Management'e Dahil mi? Evet. ### Database Change Risk Assessment Nedir? Değişikliğin; availability, security, performance, recovery etkilerinin önceden değerlendirilmesidir. ### Rollback Plan Nedir? Değişiklik başarısız olursa eski duruma dönüş planıdır. ### Backup Rollback Plan Yerine Geçer mi? Tek başına değil. Bazı configuration change'ler için config rollback daha hızlı olabilir. ### Maintenance Sonrası Validation Nedir? Bakım tamamlandıktan sonra; service, query, replication, backup, security kontrollerinin doğrulanmasıdır. ### Database Maintenance Automation Nedir? Periyodik bakım işlemlerinin otomatik script veya platformlarla yapılmasıdır. ### Automation Güvenli mi? Doğru control ile evet. Ancak automation account'un yetkileri minimum olmalıdır. ### Automation Script Hard-Code Password İçermeli mi? Hayır. Secret manager kullanılmalıdır. ### Maintenance Automation Audit Edilmeli mi? Evet. Hangi script'in ne zaman ne yaptığı bilinmelidir. ### Automation Failure Alarm Üretmeli mi? Evet. ### Database Capacity Management ve Cloud Cloud database'lerde storage ve compute daha hızlı artırılabilir. Ancak bu otomatik maliyet riski oluşturabilir. ### Auto-Scaling Database İçin Faydalı mı? Workload'a göre kaynak artırabilir. ### Auto-Scaling Güvenlik Sorununu Çözer mi? Hayır. Saldırı kaynaklı yükte yalnızca daha fazla kaynak tahsis ederek maliyeti artırabilir. ### Cost Anomaly Security Sinyali Olabilir mi? Cloud ortamında beklenmeyen resource tüketimi compromise göstergesi olabilir. ### Database FinOps ile Security Birlikte Düşünülebilir mi? Evet. Ani compute veya storage artışı hem maliyet hem security açısından incelenebilir. ### PostgreSQL Performans Bakım Checklist - Autovacuum sağlıklı mı? - Dead tuple/bloat izleniyor mu? - Statistics güncel mi? - Slow query izleniyor mu? - Long transaction var mı? - Connection sayısı normal mi? - WAL büyümesi kontrol altında mı? - Replication lag normal mi? - Storage capacity yeterli mi? - Patch seviyesi güncel mi? ### MSSQL Performans Bakım Checklist - Index health izleniyor mu? - Statistics güncel mi? - Long-running query var mı? - Blocking/deadlock izleniyor mu? - TempDB sağlıklı mı? - Transaction log büyümesi normal mi? - Backup süresi uygun mu? - Disk latency normal mi? - Patch/CU seviyesi güncel mi? - Query regression izleniyor mu? ### Oracle Performans Bakım Checklist - Optimizer statistics güncel mi? - Long SQL izleniyor mu? - Tablespace capacity yeterli mi? - TEMP kullanımı normal mi? - Archive destination doluyor mu? - Session/lock problemi var mı? - Backup süresi uygun mu? - Patch seviyesi güncel mi? - Listener/database health izleniyor mu? - Recovery alanı kapasitesi yeterli mi? ### Kurumsal Database Maintenance Checklist - Performance baseline var mı? - Slow query monitoring aktif mi? - Index maintenance planı var mı? - Statistics yönetiliyor mu? - Lock/deadlock izleniyor mu? - Connection limitleri belirlenmiş mi? - Capacity forecast yapılıyor mu? - Disk threshold alarmı var mı? - Transaction log/WAL/archive alanı izleniyor mu? - Backup duration takip ediliyor mu? - Patch inventory var mı? - Unsupported version var mı? - Patch SLA tanımlı mı? - Maintenance change management'e bağlı mı? - Maintenance sonrası validation yapılıyor mu? ### Database Performance ve Security KPI'ları Örneğin: Average Query Response Time Slow Query Count Deadlock Count Storage Utilization Capacity Forecast Patch Compliance Unsupported Database Count Replication Lag Backup Duration Database Availability ### Patch Compliance KPI Neden Özellikle Önemli? Database performansı iyi olabilir. Ancak kritik security patch'leri eksikse sistem yine yüksek risklidir. ### Unsupported Database Count Hedefi Ne Olmalı? Kritik production ortamlarında hedef mümkün olduğunca: **0** olmalıdır. ### Performance SLA Karşılanırken Güvenlik İhmal Edilebilir mi? Hayır. Performance hedefleri security baseline'ı bozmadan karşılanmalıdır. ### Database Maintenance'de En Sık Yapılan Hatalar Kurumlarda sık görülen hatalar: - Yalnızca sistem yavaşlayınca bakım yapmak - Performance baseline tutmamak - Her index'i sürekli rebuild etmek - Statistics bakımını ihmal etmek - Uzun transaction'ları izlememek - Deadlock'ları normal kabul etmek - Connection limit belirlememek - Disk %95 olduğunda kapasite düşünmeye başlamak - Transaction log/WAL/archive alanını izlememek - Patch'leri yıllarca ertelemek - EOL database sürümü kullanmak - Patch sonrası security configuration doğrulamamak - Backup süresinin sürekli uzamasını görmezden gelmek - Performance için logging veya encryption'ı kapatmak - Maintenance script'lerinde hard-coded credential kullanmak ### Database Bakımı İçin Günlük Kontroller Günlük olarak; database availability, backup status, critical alerts, disk capacity, replication lag, failed job kontrol edilebilir. ### Haftalık Database Kontrolleri Örneğin: Slow query trend Lock/deadlock Storage growth Backup duration Failed login trend ### Aylık Database Kontrolleri Örneğin: Index/statistics health Capacity forecast Patch status User/role review Security configuration ### Üç Aylık Database Kontrolleri Örneğin: Restore test Access review Baseline review Performance trend Version lifecycle ### Database Maintenance Raporu Neler İçermeli? Executive Summary Database Availability Performance Findings Capacity Risks Patch Status Backup Status Security Findings Action Plan ### Yönetim İçin Database Maintenance Raporu Teknik Olmalı mı? Çok detaylı SQL bilgisi yerine iş riski görünür olmalıdır. Örneğin: “Disk %92.” yerine: **“Mevcut büyüme trendine göre kritik ERP database storage kapasitesi yaklaşık 35 gün içinde dolabilir.”** ifadesi daha anlamlıdır. ### Database Performance ve Güvenlik İçin Yönetimin Sorması Gereken Sorular Yönetim şu soruların cevabını alabilmelidir: Database'lerimizin hangileri kapasite sınırına yaklaşıyor? Hangi sistemlerde sürekli slow query var? Kaç database destek dışı sürümde? Kritik security patch eksik sistem var mı? Backup süremiz RTO hedefini etkiliyor mu? Disk dolarsa ne kadar önceden alarm alıyoruz? Performance problemi ile saldırıyı ayırt edebiliyor muyuz? ### Sık Sorulan Sorular #### Database maintenance nedir? Veritabanının performans, güvenlik, kapasite ve availability açısından düzenli olarak kontrol edilmesi ve iyileştirilmesidir. #### Index maintenance nedir? Index yapılarını workload ve fragmentation durumuna göre optimize etme sürecidir. #### Her index düzenli rebuild edilmeli mi? Hayır. Gereksiz rebuild ciddi kaynak tüketebilir. #### Database statistics neden önemlidir? Query optimizer'ın doğru execution plan seçmesine yardımcı olur. #### Slow query güvenlik riski midir? Doğrudan vulnerability değildir ancak availability ve resource exhaustion riskini artırabilir. #### Deadlock nedir? Transaction'ların birbirlerinin kaynaklarını bekleyerek ilerleyemediği durumdur. #### Disk database'te tamamen dolarsa ne olur? Transaction ve servis hataları oluşabilir, hatta database erişilemez hale gelebilir. #### Database patch neden önemlidir? Bilinen güvenlik açıklarını ve yazılım hatalarını kapatabilir. #### EOL database nedir? Vendor tarafından artık destek veya security update almayan database sürümüdür. #### Performance için audit kapatılmalı mı? Hayır. Audit yapısı performansa uygun şekilde optimize edilmelidir. ### Sonuç: Database Performansı Güvenlik ve İş Sürekliliğinin Bir Parçasıdır Database performansı çoğu kurumda yalnızca kullanıcıların ekranlarının hızlı açılmasıyla ilişkilendirilir. Oysa gerçekte performans çok daha geniş bir konudur. Yavaş bir database; backup süresini artırabilir, RTO hedefini bozabilir, application timeout oluşturabilir, replication lag yaratabilir, monitoring görünürlüğünü bozabilir ve resource exhaustion saldırılarının etkisini büyütebilir. Aynı şekilde security maintenance eksikliği; bilinen vulnerability, EOL version, aşırı privilege, yanlış configuration gibi risklerin uzun süre sistemde kalmasına neden olabilir. Bu nedenle kurumsal database bakımının dört temel sütunu bulunmalıdır: #### Performance Management #### Capacity Management #### Patch Management #### Security Monitoring Index ve query tuning yalnızca hız içindir. Patch yalnızca güvenlik içindir. Capacity yalnızca storage içindir. şeklinde düşünmek doğru değildir. Bu alanların tamamı birbirine bağlıdır. Örneğin database'in hızla büyümesi; storage riskini artırır, backup süresini uzatır, restore süresini artırır, RTO'yu etkiler. Aynı şekilde patch uygulanması; security vulnerability'yi kapatırken execution plan davranışını değiştirebilir. Bu nedenle database operasyonları silo halinde değil, bütünsel ele alınmalıdır. Kurumsal olarak doğru soru: **“Database şu anda hızlı mı?”** değil; şu olmalıdır: **“Database önümüzdeki altı ay boyunca güvenli, hızlı, kapasitesi yeterli ve geri döndürülebilir şekilde çalışabilecek mi?”** Gerçek database maintenance olgunluğu günlük problemi çözmek değil; **problemi oluşmadan öngörebilmektir.** Bu yaklaşım: **Monitor → Baseline → Analyze → Optimize → Patch → Validate → Forecast** döngüsüyle sürdürülebilir hale gelir.