Sql & Veritabanı İle Uygulamalar İçin Veri Kayıt Arşivleme Nasıl Yapılır?

Gereksinimler ve Ön Hazırlık

Bu rehberi uygulamak için temel seviyede SQL bilgisine ve bir veritabanı yönetim sistemine (PostgreSQL, MySQL veya SQL Server) erişiminizin olması gerekmektedir. 2026 standartlarına uygun olarak, işlemlerimizi ACID (Atomiklik, Tutarlılık, İzolasyon, Dayanıklılık) prensiplerine sadık kalarak gerçekleştireceğiz.

• Veritabanı Motoru: PostgreSQL 16+ veya MySQL 8.4+ önerilir.
• Yetkilendirme: Arşivleme işlemi yapacak kullanıcının SELECT, INSERT ve DELETE yetkilerine sahip olması gerekir.
• Strateji: Arşivleme işlemini canlı sistemin yoğun olmadığı saatlerde (off-peak hours) yapmanız, kilitlenme (deadlock) riskini azaltacaktır.

Adım 1: Arşivleme Stratejisini Belirleme

Veri arşivleme işlemine başlamadan önce "ne zaman" ve "hangi verinin" arşivleneceğine karar vermelisiniz. Genellikle "Tarih bazlı arşivleme" en yaygın yöntemdir. Örneğin, 2 yıldan eski olan sipariş kayıtlarını ana tablodan arşiv tablosuna taşımak mantıklı bir başlangıçtır.

Aşağıdaki SQL örneği, arşivlenecek veriyi belirlemek için kullanılan temel bir sorgudur:

-- Arşivlenecek kayıtların sayısını kontrol etme
SELECT COUNT(*) 
FROM siparisler 
WHERE siparis_tarihi < CURRENT_DATE - INTERVAL '2 years';

Bu sorgu, sisteminizdeki "ölü" veya "soğuk" verinin miktarını görmenizi sağlar. Bu adım, sisteminize ne kadar yük bineceğini önceden tahmin etmeniz için kritiktir.

Adım 2: Arşiv Tablosu Oluşturma

Arşivlenecek verileri saklayacağınız tablo, ana tablonun yapısı ile birebir aynı olmalıdır. İndeksleme stratejisini arşiv tablosunda değiştirebilirsiniz; çünkü arşiv tablosunda genellikle okuma (read) işlemi çok az, yazma (write) işlemi ise toplu (batch) yapılır.

-- Arşiv tablosunu ana tablodan kopyalayarak oluşturma
CREATE TABLE siparisler_arsiv (LIKE siparisler INCLUDING ALL);

-- Gereksiz indeksleri arşiv tablosundan kaldırarak yazma performansını artırın
DROP INDEX idx_siparis_tarihi_arsiv;

Bu yöntem, tablonun şemasını (schema) korurken, verinin taşınması için hazır bir alan sağlar. INCLUDING ALL ifadesi, ana tablodaki kısıtlamaları (constraints) ve varsayılan değerleri de kopyalar.

Adım 3: Veri Taşıma (Transfer) İşlemi

Veriyi taşırken INSERT INTO ... SELECT yapısını kullanırız. Ancak, milyonlarca satırı tek bir işlemde taşımak veritabanı log dosyalarınızı şişirebilir ve kilitlenmelere yol açabilir. Bu yüzden veriyi küçük parçalar (batch) halinde taşımak en iyi pratiktir.

-- 5000'er satırlık gruplar halinde veri taşıma
INSERT INTO siparisler_arsiv
SELECT * FROM siparisler
WHERE siparis_tarihi < CURRENT_DATE - INTERVAL '2 years'
LIMIT 5000;

-- Taşınan verileri ana tablodan silme
DELETE FROM siparisler
WHERE id IN (SELECT id FROM siparisler_arsiv);

Bu yöntem, sistemin anlık yükünü dengeler. İşlemi bir döngü içerisinde, veritabanı sunucusunun CPU kullanımını izleyerek çalıştırmalısınız.

Adım 4: Veri Bütünlüğü ve Güvenlik

Veri arşivleme sırasında en büyük risk, veri kaybıdır. İşlem sırasında hata oluşursa, veritabanı tutarsız bir duruma düşebilir. Bu nedenle işlemleri bir TRANSACTION (işlem bloğu) içerisinde gerçekleştirmek zorunludur.

Kritik Uyarı: Arşivleme işlemlerini asla üretim (production) ortamında yedek almadan denemeyin. Her zaman bir "rollback" planınızın olduğundan emin olun.

BEGIN;
-- Veriyi taşı
INSERT INTO siparisler_arsiv SELECT * FROM siparisler WHERE durum = 'tamamlandi' AND tarih < '2024-01-01';
-- Başarılı ise sil
DELETE FROM siparisler WHERE durum = 'tamamlandi' AND tarih < '2024-01-01';
COMMIT;

Eğer bir hata oluşursa ROLLBACK; komutu ile tüm işlemleri geri alabilir ve veritabanını güvenli bir şekilde eski haline döndürebilirsiniz.

Veri Arşivleme Yöntemleri Karşılaştırması

Adım 5: Performans Optimizasyonu ve İndeksleme

Arşivleme sonrası ana tablonuz küçüleceği için sorgularınız hızlanacaktır. Ancak, arşiv tablosunda arama yapmanız gerekiyorsa, arşiv tablosuna özel indeksler eklemeyi unutmayın. "Soğuk veri" dediğimiz bu veriler için genellikle sadece tarih veya kullanıcı ID'si üzerinden arama yapılır.

-- Arşiv tablosu için optimize edilmiş indeks
CREATE INDEX idx_arsiv_tarih ON siparisler_arsiv(siparis_tarihi);

İndeksleri gereğinden fazla oluşturmak, arşivleme işlemini yavaşlatır. Sadece ihtiyaç duyulan alanlara indeks koyun.

Sıkça Sorulan Sorular

Arşivleme işlemi veritabanını ne kadar hızlandırır?

Tablo boyutu küçüldüğünde, veritabanı motoru "full table scan" (tüm tabloyu tarama) yerine indeksleri çok daha verimli kullanır. Bu da sorgu yanıt sürelerini %30 ile %70 arasında iyileştirebilir.

Arşivlenen veriye tekrar ihtiyaç duyarsam ne yapmalıyım?

Arşiv tablosundan veriyi ana tabloya geri taşıyabilir (restore) veya uygulama katmanında her iki tabloyu UNION ALL ile birleştiren bir "View" (Görünüm) oluşturabilirsiniz.

Veri arşivleme ne sıklıkla yapılmalıdır?

Bu, uygulamanızın günlük veri üretim hızına bağlıdır. Çok yoğun sistemlerde aylık, daha küçük sistemlerde yıllık periyotlar idealdir.

Arşivleme sırasında kullanıcılar hata alır mı?

Doğru bir TRANSACTION yönetimi ve batch (küçük gruplar) kullanımı ile kullanıcılar herhangi bir kesinti veya hata ile karşılaşmazlar.

Veri arşivleme yasal zorunluluk mudur?

KVKK ve benzeri regülasyonlar, verilerin belirli bir süre sonra silinmesini veya anonimleştirilmesini gerektirebilir. Arşivleme, bu verileri yasal süre boyunca saklamak için en güvenli yoldur.

Sorumluluk Reddi: Bu rehberdeki kod örnekleri genel bilgilendirme amaçlıdır. Uygulamanızın özel yapısına göre SQL sorgularını uyarlamalı ve üretim ortamında çalıştırmadan önce mutlaka test ortamında doğrulama yapmalısınız. Veri kaybından doğabilecek zararlardan eğitmen sorumlu tutulamaz.

İleri Düzey Strateji: Otomatik Arşivleme İçin SQL Job ve Event Kullanımı

Manuel arşivleme süreçleri, insan hatasına açıktır ve sürekli takip gerektirir. Büyük ölçekli sistemlerde, veritabanı motorunun kendi zamanlanmış görevlerini (SQL Server Agent veya MySQL Event Scheduler) kullanarak bu süreci tamamen otomatize etmek, sistemin yükünü hafifletir. Aşağıda, MySQL üzerinde aylık periyotlarla çalışan bir arşivleme prosedürü örneği yer almaktadır.

MySQL Event Scheduler ile Otomasyon

Veri tabanınızda her ayın ilk günü çalışan bir event tanımlayarak, 1 yıldan eski verileri otomatik olarak orders_archive tablosuna taşıyabilir ve ana tablodan silebilirsiniz. Bu işlem, veritabanı yöneticisinin müdahalesine gerek kalmadan arka planda gerçekleşir.

DELIMITER //
CREATE EVENT archive_old_orders
ON SCHEDULE EVERY 1 MONTH
STARTS '2025-01-01 01:00:00'
DO
BEGIN
    INSERT INTO orders_archive (id, customer_id, total_amount, created_at)
    SELECT id, customer_id, total_amount, created_at
    FROM orders
    WHERE created_at < DATE_SUB(NOW(), INTERVAL 1 YEAR);

    DELETE FROM orders
    WHERE created_at < DATE_SUB(NOW(), INTERVAL 1 YEAR);
END //
DELIMITER ;

Arşivleme Süreçlerinde Hata Ayıklama ve İzleme

Arşivleme işlemi sırasında oluşabilecek kesintiler, veri tutarsızlığına veya kilitlenmelere (deadlock) yol açabilir. Bu nedenle, arşivleme prosedürlerinizi mutlaka bir "Log" tablosu ile takip etmelisiniz. Bir işlem başarısız olduğunda, hangi satırda hata aldığınızı bilmek kurtarma süresini (RTO) önemli ölçüde kısaltır.

Hata İzleme İçin Log Tablosu Yapısı

Aşağıdaki tablo yapısı, arşivleme süreçlerinizin sağlık durumunu izlemek için kullanılabilir:

• log_id: Benzersiz kayıt numarası.
• process_name: Çalışan arşivleme görevinin adı.
• status: İşlem durumu (SUCCESS, FAILED, IN_PROGRESS).
• rows_affected: İşlem gören satır sayısı.
• error_message: Hata oluştuysa detaylı açıklama.
• created_at: İşlemin gerçekleştiği zaman damgası.

İşlem içerisine yerleştireceğiniz TRY...CATCH blokları (SQL Server için) veya hata yönetimi mekanizmaları ile bu tabloyu otomatik güncelleyebilirsiniz. Örneğin, bir hata oluştuğunda şu şekilde loglama yapabilirsiniz:

BEGIN TRY
    -- Arşivleme sorguları buraya
END TRY
BEGIN CATCH
    INSERT INTO archive_logs (process_name, status, error_message, created_at)
    VALUES ('Monthly_Archive', 'FAILED', ERROR_MESSAGE(), GETDATE());
END CATCH

Büyük Veri Setleri İçin İleri İpuçları

Milyonlarca satırlık veriyi tek bir DELETE sorgusu ile silmek, veritabanı log dosyalarınızın (transaction log) aşırı büyümesine ve sistemin kilitlenmesine neden olabilir. Bu durumu engellemek için "Batching" (yığınlama) yöntemini kullanmalısınız.

Batching ile Silme Stratejisi:

1. Verileri 5.000'lik veya 10.000'lik parçalar halinde silin.
2. Her silme işleminden sonra kısa bir bekleme (sleep) süresi ekleyerek veritabanı kaynaklarının nefes almasını sağlayın.
3. İşlemi bir döngü içerisinde, silinecek veri kalmayana kadar devam ettirin.

Bu yaklaşım, yüksek trafikli üretim ortamlarında veritabanı performansının düşmesini engeller ve uygulamanızın kesintisiz çalışmasına olanak tanır.

Sonuç

Veri arşivleme, sürdürülebilir bir veritabanı yönetimi için vazgeçilmez bir disiplindir. Bu rehberde öğrendiğiniz stratejilerle, veritabanı kaynaklarınızı optimize edebilir ve sisteminizin 2026 yılındaki yüksek trafik gereksinimlerine hazır olmasını sağlayabilirsiniz. Bir sonraki adım olarak, veritabanı bölümleme (partitioning) tekniklerini araştırarak arşivleme sürecini tamamen otomatize etmeyi hedefleyebilirsiniz.