Milyon Satırlık UPDATE Hattan Geçmiyor: Toplu Veri Düzeltmesi Kimin Kaydında?

Bir kurumun değişiklik sürecini anlatmasını isterseniz genellikle şunu duyarsınız: talep bir talep sisteminde açılır, onaylanır, hat üzerinden geçer, otomatik olarak çalışır. Güzel bir süreç ve çoğu zaman gerçekten de böyle işliyor. Sonra bir soru geliyor: "Üç milyon satırlık bir veri düzeltmesi de bu yoldan mı geçiyor?" Duraklama. Sonra şu cevap: "Onu DBA kontrollü yapıyor." Bu yazı o cümlenin içindeki boşluk hakkında.

En Riskli İş, En Az Kayıtlı İş

Hat, şema değişikliklerini ve uygulama sürümlerini taşımak için kurulmuştur: bir sütun eklemek, bir index oluşturmak, bir prosedürü güncellemek. Bunlar küçük, tekrarlanabilir, test edilebilir işlerdir. Toplu veri düzeltmesi başka bir hayvandır: bir kampanya hatası yüzünden yanlış yazılmış milyonlarca kayıt, bir taşıma sonrası tutarsız kalan bir sütun.

Bu işler genellikle şöyle yapılır: DBA kendi hesabıyla bağlanır, bir döngüyle parça parça günceller, gerekirse zamanlar ve sonucu kendi notlarına yazar. Çoğu zaman doğru ve dikkatli yapılır. Ama üç soru açık kalır:

• Bu işin gerekçesi nerede yazılı?
• Kim onayladı?
• Çalışan komutun onaylanan komut olduğunu nereden bileceğiz?

"Prevention İstemiyoruz" Cümlesi

Bu tür işlerde kurumların çoğu bilinçli bir karar verir: bu işlemde engelleyici mod kapalı olsun. Çünkü DBA ne yaptığını bilir ve bir engelleme yanlış yerde işi yarıda kesip daha büyük bir sorun çıkarabilir. Bu karar doğru. Ama şunu da söylemiş olur: en yüksek riskli işlem, en az kontrol altındaki işlemdir ve telafi edici kontrol "deneyimli DBA ve log" olarak kalır.

Log bir kanıt değildir. DAM gibi bir araç bu işlemi görür; ne zaman, hangi hesap, kaç ifade. Ama bu işlemin neden yapıldığını, kimin izin verdiğini, çalışan metnin onaylanandan farklı olup olmadığını bilmez.

Engellemek Değil, Kaydetmek

Çözüm engellemeyi açmak değil. DBA'nın işi yapmasına izin verip kararı ve kanıtı kayda geçirmektir. Toplu iş bir talep olur:

• Gerekçe yazılır. Bu düzeltme neden yapılıyor, kim istedi.
• Risk bandı belirlenir. Kural kataloğu WHERE'siz UPDATE ve DELETE'i, TRUNCATE'i ve yıkıcı ifadeleri işaretler; WHERE'siz UPDATE ve DELETE kurulum varsayılanında talebin kaydını da engeller. Bant en kötü bulguya göre belirlenir; ortalama alınmaz.
• Geri alma planı çalıştırmadan önce üretilir. Sunucuda "geri alma zorunlu" kuralı açıksa plan eksikken iş çalıştırılamaz. Kural kurumun kararıdır; kapalıysa Yönetişim Kurulum Kontrolü ekranı bunu uyarı olarak gösterir. "Yedek var" cümlesi bir plan değildir.
• İş önce izole denemede sınanabilir. Çalıştır, sonucu gör, geri al.
• Zamanlanabilir. Gece 02:00'de çalışsın, kimse yanında olmasın diye.
• Etkilenen satır sayısı kaydedilir. "Kaç satır güncellendi" sorusunun cevabı tahmin değil kayıttır.

DBA yine işi yapıyor. Ama yaptığı işin kararı, gerekçesi ve sonucu tek yerde duruyor.

DAM Neyi Görür, Neyi Görmez?

Veritabanı etkinlik izleme bu toplu işi elbette görür: başladığını, bittiğini, hesabı, saati. Görmediği şey bağlamdır. Denetçi "geçen yıl toplu olarak kaç veri düzeltmesi yapıldı, hangisi onaylıydı" diye sorduğunda DAM sayıyı verir ama onayı veremez. İki katmanın birleşimi, yani DAM izler, yönetişim kararı tutar, bu açığı kapatır.

İki Rapor, İki Soru

Kurumların çoğu toplu düzeltmelerin ne kadarının sistematik değişiklik olduğunu, ne kadarının elle yapıldığını bilmez. Bu ayrım önemlidir çünkü elle veri düzeltmesi bir sürecin çalışmadığının işaretidir.

• Elle veri değişiklikleri raporu: doğrudan DML ya da prosedür çağrısıyla veri değiştiren talepler. Elle yapılan düzeltmelerin sistematik değişikliklere oranını görürsünüz.
• Veri değişikliği sıklığı raporu: hangi tabloda ne sıklıkla INSERT, UPDATE, DELETE, MERGE çalıştı ve son çalıştırma tarihi.

Bir tabloya ayda on kez elle veri düzeltmesi yapılıyorsa sorun DBA'da değil, o tabloya veri yazan uygulamadadır. Rapor bunu görünür kılar.

Sınır

• Ürün DBA'nın kendi hesabıyla yaptığı bağlantıyı engellemez. Toplu iş yalnız talep üzerinden çalıştırılırsa kayıt altındadır. Kayıt dışı yolun yakalanması için veritabanı etkinlik izleme ve SIEM gerekir; tek kanal olarak talebi seçen kurum kanal dışı erişimi alarm olarak tanımlar.
• Bir talep içinde yüzlerce ifade olabilir; DBA bunları parçalayarak çalıştırmak isterse betiğin döngüsünü kendisi tasarlar. Ürün metni çalıştırır, döngü mantığının doğruluğunu yargılamaz.

Ne Kazanılır?

DBA için bir külfet gibi görünür. Ama ilk toplu iş bir talep olarak kayda geçtiğinde şunlar olur:

• Gece 02:00'de bir şey ters giderse "kim onayladı, hangi metin, geri alma planı nerede" sorusu tek sayfada cevaplanır. DBA suçlanmaz, kayıt konuşur.
• Bir yıl sonra denetçi sorduğunda cevap aramaya gerek kalmaz.
• Aynı tabloya tekrar tekrar yapılan düzeltmeler görünür olur ve kök neden aranır.

Sık Sorulan Sorular

Toplu veri düzeltmesi CI/CD hattından geçmiyorsa nasıl kayıt altına alınır?

Toplu iş bir talep olur: gerekçe, risk bandı, onay, çalıştırılan metnin özeti ve etkilenen satır sayısı tek kayıtta durur. DBA işi yine kendisi yapar; engelleme açılmaz, karar ve kanıt kayda geçer.

Geri alma planı olmadan toplu iş çalıştırılabilir mi?

Sunucuda "geri alma zorunlu" kuralı açıksa çalıştırılamaz. Kural varsayılan olarak kapalıdır ve kurumun kararıdır; kapalıysa Yönetişim Kurulum Kontrolü ekranı bunu uyarı olarak gösterir.

Elle veri düzeltmelerinin sıklığını nasıl ölçerim?

"Elle veri değişiklikleri" ve "veri değişikliği sıklığı" raporları hangi tabloda ne sıklıkla doğrudan DML çalıştığını gösterir. Sık tekrar eden düzeltme, o tabloya yazan uygulamada bir kök neden olduğunu düşündürür.