Sql & Veritabanı İle Veri Tabanı İçin Otomatik Hata Bildirim Sistemi Nasıl Yapılır?

Gereksinimler ve Ön Hazırlık

Otomatik hata bildirim sistemi kurmak için belirli bir teknik altyapıya sahip olmanız gerekir. 2026 yılı standartlarında, veritabanı yönetim sisteminizin (DBMS) güncel sürümlerini kullanmanız güvenlik ve performans açısından zorunludur.

• DBMS: PostgreSQL 16+ veya MySQL 8.4+ (Örnekler her iki sistemle uyumlu standart SQL içermektedir).
• Uygulama Katmanı: Hataları işleyecek ve bildirim gönderecek bir backend dili (PHP 8.3+ önerilir).
• Bildirim Kanalı: SMTP sunucusu veya Slack/Telegram API entegrasyonu.
• Yetkilendirme: Hata loglarını okuyabilen ve yazabilen kısıtlı bir veritabanı kullanıcısı (Principle of Least Privilege - En az yetki prensibi).

Adım 1: Hata Loglama Tablosunun Tasarımı

Hataları yakalamadan önce, bu verileri saklayacağımız bir yapıya ihtiyacımız var. Veritabanı seviyesinde oluşacak hataları merkezi bir tabloda toplamak, analiz süreçlerini kolaylaştırır. Aşağıdaki SQL kodu, hata kayıtlarını tutacak tabloyu oluşturur.

CREATE TABLE system_error_logs (
    id SERIAL PRIMARY KEY,
    error_code VARCHAR(20),
    error_message TEXT,
    severity_level INT DEFAULT 1,
    query_text TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    is_notified BOOLEAN DEFAULT FALSE
);

Bu tablo, hatanın kodunu, mesajını, şiddet seviyesini ve hataya neden olan sorguyu saklar. is_notified sütunu, sistemin aynı hatayı tekrar tekrar bildirmesini engellemek için kritik bir "bayrak" (flag) görevi görür.

Adım 2: Veritabanı Seviyesinde Hata Yakalama (Stored Procedures)

Uygulama kodunuzda her sorguyu try-catch blokları ile sarmalamak bazen yetersiz kalabilir. Veritabanı seviyesinde hata yakalamak için "Stored Procedure" (Saklı Yordam) yapısını kullanmalıyız. Bu, veritabanı işlemlerini bir kapsül içine alarak hata durumunda otomatik loglama yapmamızı sağlar.

DELIMITER //
CREATE PROCEDURE ExecuteSafeQuery(IN query_text TEXT)
BEGIN
    DECLARE EXIT HANDLER FOR SQLEXCEPTION
    BEGIN
        GET DIAGNOSTICS CONDITION 1 @sqlstate = RETURNED_SQLSTATE, @msg = MESSAGE_TEXT;
        INSERT INTO system_error_logs (error_code, error_message, query_text)
        VALUES (@sqlstate, @msg, query_text);
    END;
    
    SET @stmt = query_text;
    PREPARE stmt FROM @stmt;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END //
DELIMITER ;

Bu prosedür, çalıştırılan sorguda bir hata oluştuğunda otomatik olarak SQLEXCEPTION bloğuna düşer ve hatayı system_error_logs tablosuna yazar. Bu, uygulamanızın veritabanı ile olan iletişimini standartlaştırır.

Adım 3: Bildirim Mekanizmasının Uygulama Katmanında Kurulması

Veritabanı hataları logladıktan sonra, bu hataların yöneticiye bildirilmesi gerekir. PHP gibi bir dil kullanarak, veritabanını belirli aralıklarla kontrol eden bir "Cron Job" (Zamanlanmış görev) oluşturmalıyız.

// Örnek: Bildirilmeyen hataları kontrol eden PHP betiği
$pdo = new PDO('mysql:host=localhost;dbname=db', 'user', 'pass');
$stmt = $pdo->query("SELECT * FROM system_error_logs WHERE is_notified = FALSE");

while ($error = $stmt->fetch()) {
    $message = "Hata Tespit Edildi: " . $error['error_message'];
    // Burada SMTP veya Slack API ile bildirim gönderilir
    sendNotification($message);
    
    $update = $pdo->prepare("UPDATE system_error_logs SET is_notified = TRUE WHERE id = ?");
    $update->execute([$error['id']]);
}

Bu betik, bildirilmemiş hataları bulur, bildirim gönderir ve ardından is_notified değerini TRUE yaparak aynı bildirimin tekrar gönderilmesini engeller.

Hata Yönetim Yöntemlerinin Karşılaştırılması

Adım 4: Güvenlik ve Performans Optimizasyonu

Otomatik hata bildirim sistemleri, dikkatli tasarlanmadığında bir "Denial of Service" (DoS) saldırısına dönüşebilir. Eğer veritabanınız sürekli hata veriyorsa, sisteminiz sürekli bildirim göndermeye çalışarak sunucuyu yoracaktır.

Kritik Uyarı: Hata loglarını asla kullanıcıya doğrudan göstermeyin. Veritabanı şeması veya tablo isimleri gibi bilgilerin sızması, SQL Injection saldırıları için bir harita görevi görür. Hataları her zaman sunucu tarafında (backend) loglayın ve son kullanıcıya sadece genel bir "İşlem başarısız oldu" mesajı verin.

Performans için system_error_logs tablosuna mutlaka created_at sütunu üzerinden bir indeks ekleyin. Ayrıca, eski logları temizlemek için bir "Partitioning" (Bölümleme) stratejisi uygulayın.

CREATE INDEX idx_created_at ON system_error_logs(created_at);
-- Eski kayıtları temizlemek için (Ayda bir çalıştırılmalı)
DELETE FROM system_error_logs WHERE created_at < NOW() - INTERVAL 30 DAY;

Sıkça Sorulan Sorular

Hata bildirimleri neden anlık değil de Cron ile gönderilmeli?

Anlık bildirimler, veritabanı bağlantılarını darboğaza sokabilir. Cron ile belirli aralıklarla (örneğin 1 dakikada bir) kontrol etmek, sistem kaynaklarını daha verimli kullanmanızı sağlar.

SQL Injection saldırılarına karşı sistemim güvende mi?

Evet, eğer "Prepared Statements" kullanıyorsanız veritabanı katmanınız güvendedir. Hata loglama sistemimiz, sorgu metnini doğrudan değil, parametreli olarak işlediği sürece güvenlidir.

Hata logları veritabanını şişirirse ne yapmalıyım?

Log tablosunu düzenli olarak arşivleyin veya "Log Rotation" (Log döndürme) tekniklerini kullanarak belirli bir boyuta ulaşan verileri dış bir dosyaya (JSON/CSV) aktarın.

Hangi hata seviyeleri bildirilmelidir?

Sadece "Critical" (Kritik) ve "Warning" (Uyarı) seviyeleri bildirilmelidir. "Info" seviyesindeki loglar sadece veritabanında tutulmalı, bildirim gönderilmemelidir.

Bu sistem NoSQL veritabanlarında çalışır mı?

Mantık aynıdır ancak uygulama yöntemi değişir. NoSQL veritabanlarında "Middleware" veya "Interceptor" yapıları kullanılarak benzer bir akış oluşturulabilir.

Sorumluluk Reddi: Bu rehberde sunulan kod örnekleri eğitim amaçlıdır. Üretim ortamında kullanmadan önce mutlaka bir güvenlik testinden geçirin ve hata loglarınızın GDPR/KVKK uyumlu olduğundan (kişisel veri içermediğinden) emin olun.

Hata Yönetiminde İleri Seviye Stratejiler: Veri Görselleştirme ve Analiz

Hata loglarını veritabanında toplamak, sistemin sağlığı için ilk adımdır. Ancak, binlerce satırlık bir log tablosu içerisinde kaybolmamak için bu verileri anlamlı hale getirmelisiniz. Hataların hangi saat dilimlerinde yoğunlaştığını, hangi kullanıcıların veya hangi modüllerin daha fazla hata tetiklediğini anlamak, proaktif bir bakım süreci sağlar.

Bu verileri görselleştirmek için basit bir SQL sorgusu ile hata frekansını gruplandırabilir ve bir dashboard aracında kullanabilirsiniz:

SELECT 
    DATE_FORMAT(error_time, '%Y-%m-%d %H:00:00') AS error_hour,
    error_code,
    COUNT(*) AS error_count
FROM error_logs
WHERE error_time >= NOW() - INTERVAL 24 HOUR
GROUP BY error_hour, error_code
ORDER BY error_count DESC;

Bu sorgu, son 24 saat içerisindeki hataları saatlik bazda gruplandırarak, sisteminizdeki "hata patlamalarını" (error spikes) tespit etmenize olanak tanır. Eğer belirli bir saatte hata sayısında ani bir artış varsa, o saatte yapılan bir deployment veya yoğun trafik artışı incelenmelidir.

Hata Loglarının Yaşam Döngüsü ve Arşivleme (Partitioning)

Sisteminiz büyüdükçe error_logs tablosu milyonlarca satıra ulaşabilir. Bu durum, hem sorgu performansını düşürür hem de veritabanı yedeği alma süresini uzatır. Bu sorunu çözmek için "Table Partitioning" (Tablo Bölümleme) yöntemini kullanmak en profesyonel yaklaşımdır.

Verilerinizi aylık veya haftalık bölümlere ayırarak, eski logların sorgulanmasını hızlandırabilir ve çok eski verileri tek bir komutla silebilirsiniz:

-- MySQL için örnek partition yapısı
ALTER TABLE error_logs
PARTITION BY RANGE (TO_DAYS(error_time)) (
    PARTITION p2023_10 VALUES LESS THAN (TO_DAYS('2023-11-01')),
    PARTITION p2023_11 VALUES LESS THAN (TO_DAYS('2023-12-01')),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

Log Temizleme Stratejisi

Loglarınızı sonsuza kadar saklamanıza gerek yoktur. KVKK uyumluluğu ve depolama maliyetleri açısından 3 veya 6 aylık bir saklama politikası belirlemelisiniz. Aşağıdaki prosedür, belirlenen süreden eski logları otomatik olarak temizler:

DELIMITER //
CREATE PROCEDURE CleanupOldLogs()
BEGIN
    -- 90 günden eski logları sil
    DELETE FROM error_logs 
    WHERE error_time < DATE_SUB(NOW(), INTERVAL 90 DAY);
END //
DELIMITER ;

Bu prosedürü bir Event Scheduler (Zamanlanmış Görev) ile haftada bir kez çalışacak şekilde ayarladığınızda, veritabanınızın şişmesini engellemiş olursunuz.

Özetle, hata yönetimini sadece "hatayı yakalamak" olarak değil, "hatadan öğrenmek" olarak kurguladığınızda, uygulamanızın hata toleransı ve kararlılığı ciddi oranda artacaktır.

Sonuç

Veritabanı için otomatik hata bildirim sistemi kurmak, projenizin sürdürülebilirliği için atacağınız en önemli adımlardan biridir. Bu rehberde, SQL prosedürleri ile hata yakalamayı, bu hataları bir tabloda merkezileştirmeyi ve uygulama katmanında bildirim göndermeyi öğrendiniz. Bir sonraki adım olarak, bu hata loglarını görselleştiren bir "Dashboard" (Yönetim Paneli) oluşturarak hataların hangi saatlerde ve hangi sorgularda yoğunlaştığını analiz edebilirsiniz.