Cevap.

Herhangi bir SQL endüstriyel çözümü, hataların işlenmesi için doğru bir mimari gerektirir. Günümüz özellikleri (T-SQL, PL/pgSQL, PL/SQL vb.) tam hata işleme yapılarına (TRY/CATCH, EXCEPTION) sahipken, standart SQL minimum hata işleme kabul eder (örneğin, RETURN ve işlemi sonlandırma).

Soru geçmişi: Hataların açık bir şekilde işlenmediği durumlarda, sorunlar "batıyor" ve yöneticinin arızanın nedenini belirlemesi zorlaşıyor — özellikle kitlesel değişiklikler veya dış sistemlerle çalışırken. Genel olarak, hataları sonraki analiz için ayrı bir tabloda kaydetmek önemli bir ihtiyaç haline geliyor.

Çözüm: TRY/CATCH (T-SQL) veya EXCEPTION (PL/pgSQL) kullanın ve ayrıca kendi kayıt tablolarınızı oluşturun. Log kaydına tanı bilgilerini (hata kodu, hata metni, istek parametreleri ve zaman) göndermeyi unutmayın.

Kod örneği (T-SQL, MS SQL Server):

CREATE TABLE ErrorLog (
    ErrorId INT IDENTITY PRIMARY KEY,
    ErrorTime DATETIME,
    ProcedureName NVARCHAR(128),
    ErrorMessage NVARCHAR(MAX),
    ErrorNumber INT,
    ErrorState INT,
    ErrorSeverity INT
);

CREATE PROCEDURE usp_ProcessOrders
AS
BEGIN
    BEGIN TRY
        -- İş mantığı
        UPDATE Orders SET Status = 'PROCESSED' WHERE Status = 'NEW';
    END TRY
    BEGIN CATCH
        INSERT INTO ErrorLog
        (
            ErrorTime, ProcedureName, ErrorMessage, ErrorNumber, ErrorState, ErrorSeverity
        )
        VALUES
        (
            GETDATE(),
            ERROR_PROCEDURE(),
            ERROR_MESSAGE(),
            ERROR_NUMBER(),
            ERROR_STATE(),
            ERROR_SEVERITY()
        );
        THROW;
    END CATCH
END

Kod örneği (PL/pgSQL, PostgreSQL):

BEGIN
    -- Kodunuz
EXCEPTION WHEN OTHERS THEN
    INSERT INTO error_log(ts, proc_name, err_text)
    VALUES(now(), 'my_proc', SQLERRM);
    RAISE;
END;

Anahtar özellikler:

Hata detaylarına anlık erişim.
Sürecin tüm aşamalarında tam izlenebilirlik.
Açık bir dönüş ve merkezi log toplama olmadan yürütmeyi durdurmayın.

Yanıltıcı sorular.

Sadece hatayı yakalayıp prosedürü dışarı bilgi vermeden sonlandırmak yeterli mi?

Hayır. Açık bir loglama veya hatayı yayma olmadan, arızanın nedenlerini yakalayıp analiz etmek mümkün değil. Hatanın logda ayrıntılandırılması veya en azından ileriye iletilmesi (THROW/RAISE) önemlidir.

Sadece yerleşik SQL Server/DBMS logları kullanarak kullanıcı prosedürlerindeki tüm hataları tespit etmek mümkün mü?

Kısmen. Birçok hata, eğer uygulamada veya prosedürlerde "yakalanır" ve işlenirse, sunucu loglarına düşmez. İş mantığı için olayların detaylarıyla kaydedildiği bir log tutmak faydalıdır.

Prosedürlerde sadece basit DML işlemleri kullanılıyorsa, TRY/CATCH (veya EXCEPTION) kullanmak zorunlu mu?

Evet, eğer prosedür önemli verilere etki ediyorsa, kritik zincirlerde yer alıyorsa ve anormal durumları kaydetmesi gerekiyorsa. Hatta "güvenli" işlemler, dış kısıtlamalardan (eşsizlik, FOREIGN KEY, deadlock vb.) kaynaklanan hatalara yol açabilir.

Yaygın hatalar ve anti-paternler

Uygulama seviyesinde ayrı bir hata kaydı tutmamak.
Hatanın yakalanması, ancak kullanıcıya/yöneticilere bilgi verilmemesi.
Şablonlar olmadan karmaşık işleme blokları yazmak — okunabilirliği azaltır.

Gerçek yaşam örneği

Olumsuz durum

Projede hatalar kaydedilmiyor, sadece kullanıcıya gösteriliyor. Kitlesel bir arıza durumunda, yönetici saatlerce "görünmeyen" bir problemi arıyor.

Artıları:

Basit çözüm, daha az kod.

Eksileri:

Tanımlama imkânı yok.
Denetim ve veri kalitesi analizi için hiçbir temele sahip değil.

Olumlu durum

Herhangi bir kritik hata, ayrıntılarla (zaman, prosedür, parametreler, hata kodu) log tablosuna kaydedilir ve buna sistemin bir ticket'i referans verir.