Bu yazıda tam bu noktayı konuşmak istiyorum: bir veritabanı değişiklik platformunun değeri, sorun çıktıktan sonra neyi gösterdiğiyle değil, sorun çıkmadan önce neyi gördüğüyle ölçülür.

Şeffaflık bir özellik değil, bir mimari karardır

"Şeffaf sistem" denince akla genellikle güzel bir dashboard gelir. Renkli grafikler, anlık metrikler, belki bir log ekranı. Bunlar şeffaflığın yüzeyidir.

Gerçek şeffaflık, bir değişikliğin fikir aşamasından canlı ortama taşınmasına kadar geçen her adımın kimin ne zaman ne yaptığının, hangi kararın neden alındığının, hangi onayın kimden geldiğinin herhangi bir anda sorgulanabilir ve doğrulanabilir olmasıdır.

SQL Change Guard'ın mimarisini bu anlayış üzerine kurulmuş. Bir değişiklik talebi açıldığı andan itibaren sistem bir zaman damgası basmaya başlıyor: talep kim tarafından açıldı, hangi nesneler dahil, bağımlılık analizi ne gösteriyor, validasyon aşamasından ne çıktı, hangi yetkili hangi saatte onayladı, sandbox'ta nasıl davrandı, canlıya ne zaman taşındı, taşındıktan sonra performans metrikleri ne dedi.

Bu zincir kırılmıyor. Bir halka atlanmıyor. Her adım bir sonrakine bağlanıyor.

Kontrol altında olmak, kısıtlanmak değildir

Kurumsal ortamlarda "kontrollü süreç" kavramı zaman zaman yanlış anlaşılıyor. Geliştiriciler duyduklarında "bürokratik engel" hissedebiliyor. DBA'lar duyduklarında "ek iş yükü" düşünüyor. Yöneticiler duyduklarında "daha yavaş deployment" kaygısı taşıyor.

Ama kontrol, hız düşmanı değildir. Kontrolsüz hız, düzeltme maliyetiyle birlikte hesaplandığında her zaman daha yavaştır.

SQL Change Guard'da her ekip üyesi kendi rolünün gerekliliklerini sistemin içinde buluyor. Geliştirici, değişikliği nasıl tanımlayacağını ve hangi aşamalardan geçireceğini biliyor çünkü platform bunu adım adım gösteriyor. DBA, hangi taleplerin validasyonu geçtiğini ve hangilerinin dikkat gerektirdiğini tek ekranda görüyor. Yönetici, onay süreçlerinin tıkandığı noktaları gerçek zamanlı takip edebiliyor.

Herkes kendi alanında çalışıyor, ama hepsi aynı sistemin parçası. Bu, koordinasyon toplantılarını, "sen ne yaptın, ben ne yapmalıyım" e-postalarını ve kafadan atma kararları azaltıyor. Süreç insanları yönlendiriyor, insanlar süreci yönetiyor.

Hata canlıda değil, daha önce yakalanır

Bir SQL değişikliğinin canlı ortamda sorun çıkarması için mutlaka büyük bir hata yapılmış olması gerekmiyor. Bazen küçük bir gözden kaçma yeterli: bir index eksikliği, bir sorgu planı değişikliği, beklenmedik bir veri hacmiyle karşılaşma.

SQL Change Guard'ın validasyon ve performans analiz katmanları bu küçük ama kritik sorunları erkenden yüzeye çıkarmak için tasarlanmış.

Bir script sisteme yüklendiğinde, validasyon motoru devreye giriyor. Tanımlı kurallara göre analiz yapıyor: bu komut kurum politikasıyla örtüşüyor mu, bu yapıda bilinen bir performans riski var mı, etkilenecek nesne sayısı beklenen sınırlar içinde mi? Bunlar insan gözünden geçmeden önce sistem kendi kontrolünü yapıyor ve işaret ediyor.

Sandbox aşaması ise validasyonun ötesine geçiyor. Değişikliği kontrollü bir ortamda, gerçeğe yakın koşullarda çalıştırıyor. Kaç satır etkilendi, ne kadar sürdü, kaynak tüketimi ne oldu bunlar sayılar halinde geliyor. Canlıya taşımadan önce ekip bir tahminden değil, gerçek bir ölçümden bakıyor.

Risk skoru da bu sürecin bir parçası. Her talep için otomatik olarak üretilen risk değerlendirmesi, onay sürecini de şekillendiriyor: düşük riskli bir değişiklik hızlı ilerleyebilirken, yüksek riskli bir değişiklik daha kapsamlı bir inceleme sürecine giriyor. Bu, DBA zamanını doğru yere harcıyor.

Her şey kayıt altında, sadece neyin kayıt altında olduğu değil

Audit kavramı çoğu zaman dar yorumlanıyor: kimin sisteme girip çıktığı, hangi komutun çalıştığı. Bunlar önemli ama yeterli değil.

SQL Change Guard'ın sağladığı audit, değişiklik yönetiminin tamamını kapsıyor. Kimin hangi talebi açtığı. Talep üzerinde hangi yorumların yapıldığı. Hangi validasyon sonuçlarının üretildiği. Kimin, hangi saatte, hangi yetkiyle onay verdiği. Sandbox'ta ne gözlemlendiği. Canlıya geçişin tam zamanı. Sonrasındaki performans ölçümleri.

Ve bir o kadar önemli: SQL Change Guard dışında yapılan değişiklikler de tespit ediliyor. Birisi doğrudan veritabanına bağlanıp bir nesneyi değiştirdiyse, bu hareket sistem tarafından fark ediliyor ve alarm üretiliyor. Yani "prosedür dışı" hiçbir şey görünmez kalmıyor.

Bu iki taraflı görünürlük hem doğru yoldan gelen değişikliklerin tam kaydı, hem de yanlış yoldan gelen değişikliklerin tespiti gerçek bir audit trail'in temelidir. Kurumunuz bir denetimle karşılaştığında ya da bir soruşturma başlattığında, "ne oldu?" sorusunun cevabı elimizde değil, sistemin içinde zaten var.

Object History: bir nesnenin tüm hayatı tek yerde

Veritabanındaki bir nesneyle ilgili soru sorulduğunda "bu stored procedure ne zamandan beri böyle?", "bu trigger'a en son kim dokundu?", "bu tabloda geçen çeyrek içinde kaç değişiklik yapıldı?" cevap genellikle yoktur. Ya birinin aklındadır ya da eski bir e-postanın derinliklerindedir.

Object History modülü bu boşluğu kapatıyor. Her veritabanı nesnesi için, üzerinde gerçekleştirilen her değişikliğin hangi talebe, hangi kullanıcıya, hangi tarihe ait olduğu görülebiliyor. Bir sorun çıktığında forensik analiz yapılmıyor geçmiş zaten orada, düzenli ve sorgulabilir biçimde duruyor.

Bu özellik özellikle iki durumda kritik öneme sahip: biri canlı ortamda beklenmedik bir davranış gözlemlendiğinde, diğeri yönetimsel veya hukuki bir denetim sürecinde. Her iki durumda da ekip "neyi hatırlıyoruz?" yerine "sisteme bakalım" diyebiliyor.

Rollback: panik değil, prosedür

Canlıya geçen bir değişikliğin geri alınması gerektiğinde ekiplerin yaşadığı stres, çoğu zaman değişikliğin kendisinden değil, geri alma sürecinin belirsizliğinden kaynaklanır. Önceki durum neydi? Tam olarak ne değişmişti? Geri aldığımızda başka bir şey bozulur mu?

SQL Change Guard'da rollback bir prosedürdür, reaktif bir müdahale değil. Değişiklik canlıya taşınmadan önce önceki durum kaydedilmiş olduğu için, geri alma kararı alındığında sistem zaten hazır. Adımlar tanımlı, risk değerlendirilmiş, hareket kontrollü.

Bu, "haydi geri alalım bakalım" ile "rollback prosedürü başlatıyoruz" arasındaki fark. İkincisi hem daha hızlı hem de çok daha güvenli.

Ekipler arası koordinasyon: herkes aynı gerçekliği görüyor

Büyük kurumlarda veritabanı değişikliklerinin en zorlu yanı teknik değildir. Koordinasyondur.

Geliştirici değişikliği hazırladı, DBA inceledi, QA test etti, ops canlıya aldı — ama bu dört adım dört farklı araçta, dört farklı konuşmada, dört farklı zaman çizelgesinde yaşandıysa, ortada tutarlı bir süreç yoktur; sadece bir tesadüfen iş biten bir dizi aktivite vardır.

SQL Change Guard bu ekipleri aynı platform üzerinde buluşturuyor. Herkes kendi rolünden bakıyor ama aynı talebi, aynı durumu, aynı geçmişi görüyor. Bir aşama tamamlandığında bir sonraki sorumluya bildirim gidiyor. Bir talep tıkandığında nerede tıkandığı görünüyor. Kimse "o bana söylemedi" ya da "ben bilmiyordum" diyemiyor.

Koordinasyon, iletişim çabasına değil, sistem tasarımına bırakılmış. Bu ekiplerin işini kolaylaştırmakla kalmıyor, sorumluluk zincirini de netleştiriyor.

Kaygıyla değil, güvenle

Veritabanı yönetiminde kaygı genellikle iki şeyden beslenir: bilmemek ve kontrol edememek. Kim ne yaptı, ne olacak, bir şey ters giderse ne yaparız.

SQL Change Guard her ikisini de adresliyor. Şeffaf süreçler bilmemeyi ortadan kaldırıyor. Validasyon, sandbox ve risk skoru kontrolsüzlüğü azaltıyor. Kapsamlı kayıt ve nesne geçmişi, ters giden her durumda ekibe somut bir zemin sağlıyor.

Sonuçta amaç, veritabanı değişikliklerini heyecan verici olmaktan çıkarmak. Rutin, tahmin edilebilir, denetlenebilir bir süreç haline getirmek.

Sıkıcı bir veritabanı süreci iyi bir veritabanı sürecidir.

SQL Change Guard hakkında daha fazla bilgi almak veya platformu yakından görmek için:

Web: https://sqlchangeguard.com E-posta: info@sqlchangeguard.com

SQL Change Guard; veritabanı değişiklik yönetimini otomatize eden, denetleyen ve ekiplere tam görünürlük sağlayan kurumsal bir platformdur. Sorularınız için her zaman ulaşabilirsini

Bu tip bir kaos, kurumsal ortamlarda şaşırtıcı şekilde yaygın. Araçlar var, süreçler kağıt üzerinde var, ama pratikte ne olduğunu kimse tam olarak bilmiyor.

SQL Change Guard'ı bu sorunla boğuşurken tanıdım. Ve açıkçası, ilk başta "bir araç daha" diye düşündüm. Yanılmışım.

Süreç olmadan otomasyon, düzensizliği hızlandırır

Birçok ekip otomasyon denince hemen script yazmaya başlar. Bir tetikleyici buraya, bir job oraya, belki bir deployment pipeline. Ama hiç kimse şunu sormaz: Bu değişiklik kimin onayıyla gidiyor? Bu scriptin başka bir nesneye bağımlılığı var mı? Prodüksiyona gitmeden önce test ortamında ne oldu?

SQL Change Guard'ın beni en çok etkileyen yanı bu soruları sisteme gömmüş olması.

Bir değişiklik talebi oluşturulduğunda, sistem sizi boş bir form karşılamıyor. Kim etkilenir, hangi nesneler dahil, bağımlı başka talepler var mı — bunlar talep sürecinin bir parçası. Developer sadece SQL yazmıyor; talep nesnesi bir varlık haline geliyor, üzerine inşa ediliyor, onaylanıyor, izleniyor.

Bu fark küçük gibi görünüyor ama pratikte iş yapış biçimini kökten değiştiriyor.

Geliştiriciye "ne yapma" değil, "nasıl yap" demek

Bir geliştiriciye "prodüksiyona doğrudan bağlanma" dediğinizde bu bir politika. Bir geliştiriciye "şu adımları izle, sistem seni yönlendiriyor" dediğinizde bu bir deneyim.

SQL Change Guard tam olarak bunu yapıyor. Sistem, geliştiriciye süreç boyunca rehberlik ediyor: hangi aşamada ne bekleniyor, hangi validasyonlar gerekiyor, onay hiyerarşisi nasıl işliyor. DBA müdahale etmek zorunda kalmıyor çünkü geliştirici zaten doğru yolu izliyor.

Bu özellikle büyük ekiplerde kritik. Kıdemli bir DBA her talebi birebir takip edemez. Ama sistem, o DBA'nın bilgi birikimini kurallara dönüştürüp her talep için uygulayabiliyor.

Bağımlı talepler: görünmez riskin adını koymak

Şunu kaç kez yaşadınız: Bir stored procedure'ü güncellediniz. Tamam görünüyordu. İki gün sonra başka bir modül çöktü çünkü o procedure'e bağımlı bir view vardı ve kimse fark etmemişti.

SQL Change Guard'daki bağımlı talep yönetimi bu senaryo için yapılmış. Bir nesneye dokunmadan önce, o nesneye bağımlı başka nesneler var mı, o nesnelerle ilgili açık talepler var mı — bunlar görünür hale geliyor. Ekip, birbirinden bağımsız gözüken değişikliklerin aslında nasıl iç içe geçtiğini anlıyor.

Bu özellik sayesinde "ben yapmadım ki" tartışmaları da ortadan kalkıyor. Kimin neyi, ne zaman, neyle birlikte değiştirdiği net.

Validasyon: insandan önce makine kontrol etsin

Manuel kod incelemesi değerlidir ama ölçeklenmez. Bir DBA günde kaç tane SQL script okuyabilir? Üstelik yorgunluk, zaman baskısı, dikkat dağınıklığı devreye giriyor.

SQL Change Guard'ın validasyon katmanı, scriptleri prodüksiyona ulaşmadan önce inceliyor. Tanımlı kurallara göre analiz yapıyor; potansiyel performans sorunları, syntax hataları, politikaya aykırı komutlar — bunlar insan gözünden geçmeden önce sistem fark ediyor.

Burada önemli bir nüans var: sistem DBA'nın yerini almıyor. Aksine, DBA'nın dikkatini gerçekten karar gerektiren yerlere yönlendiriyor. Rutin kontroller otomatikleşiyor, insani kapasite gerçek risk noktalarına odaklanıyor.

Object History: geçmiş bir şikayette değil, bir kaynakta

"Bu nesne ne zamandan beri böyle?" sorusunu kaç kez cevapsız bıraktınız?

Veritabanı nesneleri değişir. Trigger'lar güncellenir, stored procedure'ler yeniden yazılır, index yapıları farklılaşır. Ama çoğu ortamda bu değişikliklerin geçmişi yoktur. SSMS'de "son değiştirilme tarihi" görebilirsiniz belki, ama kim değiştirdi, neden değiştirdi, o değişiklikle birlikte başka ne değişti — bunların kaydı genellikle zihinlerde ya da eski e-postalarda yaşar.

SQL Change Guard'ın Object History modülü tam bu boşluğu dolduruyor. Bir nesnenin yaşam döngüsünü, üzerinde yapılan her değişikliği, o değişikliklerin hangi talebe bağlı olduğunu görebiliyorsunuz. Bu özellikle audit süreçlerinde ve sorun tespitinde çok değerli; bir nesneyle ilgili sorun çıktığında doğrudan o nesnenin geçmişine bakıyorsunuz.

Performans Raporu: değişikliğin bedeli görünür hale geliyor

Bir SQL scripti çalışıyor demek, iyi çalışıyor demek değildir.

Pek çok ekip performans sorunlarını ancak prodüksiyonda fark eder. Sorgu yavaşladı, CPU yükseldi, kullanıcılar şikayet etti — sonra geriye dönük araştırma başlar.

SQL Change Guard'daki Performans Raporu modülü bu yaklaşımı tersine çeviriyor. Değişikliğin performans üzerindeki etkisini önceden ve sonrasında ölçülebilir hale getiriyor. Bir deployment sonrasında sistem nasıl davrandı, hangi metrikler değişti, öncekiyle kıyaslandığında ne fark etti — bunları raporlar üzerinden takip edebiliyorsunuz.

Bu özellikle DB ekibinin "bizden kaynaklı değil" savunmasını ya da "sizin değişikliğiniz yaptı bunu" suçlamasını gündemden kaldırıyor. Veriler konuşuyor.

Sandbox: prodüksiyonu korumak için önce oynayın

Bir değişikliği test ortamında çalıştırmak ile gerçek veriyle test etmek çok farklı şeyler.

Sandbox modülü, değişiklikleri kontrollü bir ortamda, gerçek veri setine yakın koşullarda denemenizi sağlıyor. Prodüksiyona gitmeden önce gerçek davranışı görebiliyorsunuz. Ne kadar sürdü, ne kadar kaynak tüketti, beklenmedik bir şey var mı — bunları canlıya geçmeden anlıyorsunuz.

Bu özelliği sunan birçok araç var, ama SQL Change Guard'da Sandbox, değişiklik yönetim süreciyle entegre. Yani sandbox sonuçları, talep üzerindeki bilgiye dönüşüyor. Bir sonraki aşamaya geçmeden önce sandbox testi geçildi mi, sonuçlar ne — bunlar talep geçmişinde görünür.

Rollback: "geri alalım" demek bu kadar kolay

Bir değişikliği geri almak, teoride basit görünür. Pratikte genellikle değildir.

Rollback için önce neyin değiştiğini tam olarak bilmeniz gerekiyor. Sonra o değişikliği güvenle geri alabilmek için önceki durumu elinizdeki bir yerden almanız gerekiyor. Üstelik bu değişiklik başka değişikliklerle iç içe geçmişse ne yapacaksınız?

SQL Change Guard'ın rollback özelliği bu süreci yapılandırılmış hale getiriyor. Deployment sırasında önceki durum kaydediliyor; bir sorun çıktığında rollback adımları zaten tanımlı. Manuel müdahaleye ihtiyaç duymadan, panikle retrospektif aramak zorunda kalmadan, hızlı ve denetimli bir geri alım yapılabiliyor.

Bu özellik tek başına birçok kurumun yaşadığı "prodüksiyona yanlışlıkla gitti ve geri alamadık" senaryosunu ortadan kaldırıyor.

Ekip koordinasyonu: herkes aynı sayfada

Büyük bir değişiklik süreci düşünün. DBA ekibi, geliştirici ekibi, QA ekibi, belki bir ops ekibi. Her birinin ayrı araçları, ayrı iletişim kanalları, ayrı takip yöntemleri var.

SQL Change Guard bu ekiplerin tek bir platform üzerinde buluştuğu bir yapı sunuyor. Kim hangi aşamada, kim ne bekliyor, hangi talep tıkandı — bunlar görünür. Onay süreçleri, bildirimler, durum güncellemeleri hepsinin işini kolaylaştırıyor.

Daha önemlisi: sorumluluk dağıtılıyor. "Kim onayladı bu değişikliği?" sorusunun cevabı sisteminizde var.

Sonuçta ne değişiyor?

SQL Change Guard'ı kullanan ekiplerin anlattığı şey aslında birbirine benziyor: gece 2'de "ne oldu?" sorusuyla uyanmıyor artık. Sabah geldiğinde ne olduğunu biliyor çünkü her şey kayıt altında ve her şey bir süreçten geçerek gelmiş.

Bu güven, teknik bir özellik değil. Organizasyonel bir kazanım.

Araç sizi kurtarmıyor. Ama doğru ortamda, doğru disiplinle birleştiğinde, veritabanı yönetimini tahmin edilebilir hale getiriyor. Ve tahmin edilebilirlik, kurumsal BT'de en değerli şeylerden biri.

SQL Change Guard hakkında daha fazla bilgi almak veya bir demo talep etmek için:

Web: https://sqlchangeguard.com E-posta: info@sqlchangeguard.com

Bu makale SQL Change Guard ekibi tarafından hazırlanmıştır. Veritabanı değişiklik yönetimi, audit süreçleri ve kurumsal BT disiplini konularındaki sorularınız için doğrudan iletişime geçebilirsiniz.

1. Her Geçiş Bir Kumar Geliştirici script'i hazırladı. Test ortamında çalıştı. "Tamam" mesajı gönderdi. DBA production'a aldı. Bu süreçte şu soruların kaçına net cevap var? Script risk analizi yapıldı mı? WHERE koşulsuz bir UPDATE var mıydı, fark edildi mi? Bu değişiklik hangi bağımlı nesneleri etkiliyor, hepsi test edildi mi? Rollback planı yazıldı mı, test edildi mi? Deployment süresi tahmin edildi mi? Çoğu kurumda bu soruların yarısına bile net cevap yok. Her deployment belgelenmiş bir süreç değil, tecrübeli bir kişinin sezgisiyle yönetilen bir kumar. Küçük tablolarda bu kumar genellikle kazanılıyor. Büyük tablolarda, yoğun saatlerde, yeni bir ekip üyesinin elinde kaybediliyor. Görünmez maliyet: Bir production krizinin ortalama çözüm süresi 3-6 saattir. 3-4 kişi dahil olur. Sadece adam-saat maliyeti değil, o sürede duran işlemler, etkilenen müşteriler, yönetim toplantıları, kök neden analizleri. Yılda 3-4 kriz yaşayan bir kurum, bunun maliyetini hiç hesaplamadan "zaten hep böyle oldu" diye geçiştiriyor.

2. Denetim Hazırlığı: Görünmez Bir Proje BDDK denetimi geliyor. Ya da ISO 27001 yenileme. Ya da bir KVKK soruşturması. "Son 6 ayda veritabanlarınızda yapılan değişikliklerin listesini, kim onayladı bilgisiyle verin" deniyor. Manuel sistemlerde bu talep bir projeye dönüşüyor. Biri e-posta arşivini karıştırıyor. Biri Jira'ya bakıyor. Biri DBA'lara soruyor. Biri eski toplantı notlarını açıyor. Veriler çelişiyor. Bazı değişiklikler hiçbir yerde yok. "O dönemde acil yapıldı, not düşülmedi" cümleleri çıkıyor ortaya. Bu hazırlık süreci ciddi kurumsal kurumlarda 2-4 hafta arasında sürüyor. Bir veya iki kişinin neredeyse tam zamanı bu işe gidiyor. Görünmez maliyet: Denetim hazırlığına harcanan adam-günü maliyeti. Eksik belgeler nedeniyle denetim bulgusu alınma riski. Bir dahaki denetim için aynı sürecin tekrarlanacağı gerçeği. Ve en ağır maliyet: tüm bunları bilerek bir sonraki denetime kadar sistemi değiştirmemek.

3. Standart Yok, Kişi Var Manuel değişiklik yönetiminin en büyük açmazı şu: süreç kişiye bağlı. Kıdemli DBA işleri yönetiyor. Her şeyi biliyor. Nelerin riskli olduğunu sezgisiyle anlıyor. Hangi değişikliğin ne kadar süreceğini tahmin ediyor. Bağımlılıkları kafasından biliyor. Sonra o kişi izine çıkıyor. Ya da işten ayrılıyor. Arkasında ne kalıyor? Belgesiz bir sistem. Kafasındaki bilgi onunla gitti. Yeni gelen DBA aynı sistemi anlamak için haftalarca uğraşıyor. Aynı hatalar yeniden yapılıyor. Aynı çözümler yeniden keşfediliyor. Bu sadece verimlilik sorunu değil. Standartsız ortamlarda her değişiklik farklı yapılıyor. Kimi script başına açıklama yazıyor, kimi yazmıyor. Kimi rollback düşünüyor, kimi düşünmüyor. Kimi test ediyor, kimi "çalışır" deyip geçiyor. Zaman içinde bu tutarsızlık birikir. Sistem büyür ama okunaksızlaşır. Her yeni değişiklik öncekinin üstüne eklenir. Anlayabilen kişi sayısı azalır. Görünmez maliyet: Yeni ekip üyelerinin sisteme adaptasyon süresi uzar. Bilgi transferi olmadan yapılan her ayrılık kurumsal hafıza kaybı. Standart yoksa kalite denetimi de yok.

4. Veritabanı Büyüyor, Ama Doğru Büyüyor mu? Bir kurumun veritabanı 5 yılda nasıl büyür? İyi senaryoda: planlı, belgelenmiş, her değişiklik bir ihtiyaca karşılık veren, temiz bir yapı. Kötü senaryoda: üst üste yığılmış geçici çözümler, kullanılmayan tablolar, birbiriyle çelişen stored procedure'ler, kimsenin silmeye cesaret edemediği nesneler, "o ne işe yarıyor bilmiyorum ama dokunmayalım" kültürü. İkinci senaryo rastlantı değil. Sistematik değişiklik yönetimi olmayan her kurumun kaçınılmaz sonu. Her acil değişiklik bir "geçici çözüm" bırakıyor. Geçici çözümler zamanla kalıcı oluyor. Kalıcı olan geçici çözümler üstüne yenileri ekleniyor. 5 yıl sonra o veritabanında değişiklik yapmak neredeyse imkansız hale geliyor. Her değişikliğin neleri kıracağı bilinmiyor. Test kapsamı genişliyor çünkü her şey her şeye bağlı. Deployment süreleri uzuyor. Ekip değişiklik yapmaktan korkuyor. Teknik borç bu şekilde birikilir. Ve teknik borç faizle geri ödenir. Görünmez maliyet: Karmaşıklaşan sistemde her yeni özelliğin geliştirilme süresi uzar. Her deployment riskli hale gelir. En deneyimli ekip üyeleri "bu sisteme dokunmak istemiyorum" demeye başlar.

5. Kim Girdi, Ne Yaptı? Bilmiyoruz. Production veritabanına erişimi olan kaç kişi var? DBA'lar, geliştiriciler, sistem yöneticileri, danışmanlar, dış destek ekipleri. Belki bir önceki projede geçici erişim verilen ama erişimi kaldırılmamış kişiler. Bu kişilerin geçen hafta ne yaptığını biliyor musunuz? Manuel sistemlerde bu sorunun cevabı genellikle "tam olarak hayır." Bağlantı logları var belki. Ama kim hangi tabloyu sorguladı, kim hangi değişikliği yaptı, kim gece bağlanıp ne yaptı — bu detaylar ya hiç tutulmuyor ya da tutulsa bile analiz edilemiyor. Bu durumun üç farklı riski var. Operasyonel risk: Biri yanlışlıkla bir şey değiştirdi. Sorun çıktı. Kim ne yaptı bilinmiyor. Kaynağı bulmak saatler alıyor. Güvenlik riski: Biri kasıtlı olarak veri görüntüledi ya da değiştirdi. Bunu ispat etmek mümkün değil. Bunu önlemek de mümkün olmadı. Uyum riski: KVKK kapsamında kişisel veriye yetkisiz erişim bir ihlal. Bu ihlalin yaşandığını tespit edememek ikinci bir ihlal. Kurumun "bilmiyorduk" savunması yasal koruma sağlamıyor. Görünmez maliyet: Tespit edilemeyen her ihlal potansiyel bir yaptırım. Açıklanamayan her erişim potansiyel bir itibar kaybı. Kontrol edilemeyen her değişiklik potansiyel bir kriz.

6. "Basit Araçlar" Görünmez Karmaşıklık Üretir JIRA, e-posta, Excel, Confluence. Bunlar kötü araçlar değil. Ama veritabanı değişiklik yönetimi için tasarlanmamışlar. Bu araçlarla süreç yönetilmeye çalışıldığında şu tablo oluşuyor: Onay e-postada ama script Jira'da. Deployment log Excel'de ama rollback planı yoktu zaten. Hangi versiyonun onaylandığı belirsiz çünkü mail ekinde iki farklı dosya vardı. Test ortamında çalıştırılan script ile production'a atılan script aynı mı? Bunu doğrulayan bir mekanizma yok. Her araç kendi silo'sunda çalışıyor. Entegrasyon yok. Bütünleşik görünürlük yok. Bir değişikliğin uçtan uca hikayesini tek bir yerden görmek mümkün değil. Ve her yeni kişi bu dağınık yapıyı öğrenmek zorunda. Kendi yorumunu ekliyor. Yapı daha da dağılıyor. Görünmez maliyet: Araçlar arası geçiş süreleri, bilgi kaybı, tutarsız kayıt kalitesi ve en kritik olanı: denetimde bu dağınık yapıyı "süreç" olarak sunmanın yarattığı güven kaybı.

7. Uzun Vadede Tablo Şu Oluyor Tüm bu maliyetler tek tek küçük görünüyor. Ama birlikte değerlendirildiğinde tablo netleşiyor. Yılda 3-4 production krizi: 50-100 adam-saat. Yıllık denetim hazırlığı: 20-40 adam-gün. Teknik borç nedeniyle uzayan development süreleri: %20-30 verimlilik kaybı. Ekip değişimlerinde yaşanan bilgi kaybı: ölçülemeyen ama hissedilen maliyet. Yetkisiz erişim ya da veri ihlali riski: potansiyel yaptırım ve itibar kaybı. Bu maliyetlerin toplamı, sistematik bir değişiklik yönetimi platformunun yıllık maliyetinin çok üzerinde. Ama görünmez oldukları için hiç hesaplanmıyor.

Peki Neden Değiştirilmiyor? Çünkü "şimdiye kadar çalıştı." Bu cümle gerçek. Ama yanıltıcı. Şimdiye kadar büyük bir kriz yaşanmadıysa bu sisteminizin iyi olduğunu göstermiyor. Henüz çarpmadığınızı gösteriyor. Ve her geçen gün, büyüyen sistem ve artan erişimle birlikte çarpma olasılığı artıyor. Değişim genellikle büyük bir krizden sonra geliyor. BDDK denetiminde ciddi bir bulgu alınıyor. Bir veri ihlali yaşanıyor. Bir production krizi saatlerce sistemi durduruyor. O an değişiklik yönetimine yatırım yapmak kararı çok kolay alınıyor. Ama o an iş işten geçmiş oluyor.

Son Söz Bu yazıyı okurken içinizde "bizde de bu riskler var" hissi oluştuysa bu his doğru. Çoğu kurum bu maliyetleri taşıyor. Farkında olmadan, her gün, biraz biraz. Farkındalık ilk adım. İkinci adım, bu maliyetlerin toplamını hesaplamak ve sistematik bir çözümün ne anlama geldiğini görmek. Üçüncü adım ise harekete geçmek. Büyük bir kriz beklenmeden.

SQL Server değişiklik yönetimi hakkında daha fazla bilgi için: sqlchangeguard.com

"Veritabanı değişikliklerine ilişkin tüm işlemler kayıt altına alınır ve düzenli olarak denetlenir."

Şimdi aynı kurumda bir DBA'ya sorun: "Geçen Salı gece 23:00'de production veritabanında ne değişti?"

Sessizlik.

İşte bu iki şey arasındaki uçurum, Türkiye'deki kurumların büyük çoğunluğunun yaşadığı audit problemi.

Audit Ne Demek, Gerçekten?

Audit kelimesi dilden dile dolaşıyor. Herkes "auditimiz var" diyor. Ama audit tam olarak ne?

Gerçek bir veritabanı audit'i şu soruların tamamını yanıtlayabilmek demek:

Kim? Bu değişikliği kim yaptı? Hangi kullanıcı, hangi uygulama üzerinden?

Ne? Tam olarak ne değişti? Hangi nesne, hangi satır, hangi değerden hangi değere?

Ne zaman? Tarihi ve saati. Saniye hassasiyetinde.

Neden? Değişikliğin gerekçesi ne? Hangi iş ihtiyacı?

Kim onayladı? Bu değişiklik onay sürecinden geçti mi? Kim onayladı?

Sonuç ne oldu? Deployment başarılı mıydı? Sistem nasıl etkilendi?

Bu altı sorudan birine bile "bilmiyorum" cevabı veriliyorsa audit eksik demektir.

Türkiye'de Audit'i Zorunlu Kılan Düzenlemeler

Audit artık iyi niyet meselesi değil. Yasal zorunluluk.

KVKK

Kişisel Verileri Koruma Kanunu, kişisel veri barındıran sistemlerde teknik güvenlik tedbirlerinin alınmasını zorunlu kılıyor.

Bu tedbirler arasında erişim loglarının tutulması, değişiklik kayıtlarının saklanması ve bu kayıtların düzenli denetimi açıkça bekleniyor.

Kişisel Verileri Koruma Kurulu bir ihlal soruşturması başlattığında ilk istenen şeylerden biri şu oluyor: "İlgili veritabanında son 6 ayda hangi değişiklikler yapıldı, kim erişti?"

Bu soruyu yanıtlayamayanlar için yaptırım riskinin yanı sıra itibar kaybı da gündemdeki yerini koruyor.

BDDK

Bankacılık Düzenleme ve Denetleme Kurumu'nun bilgi sistemleri yönetmeliği, değişiklik yönetimi süreçlerini açıkça düzenliyor.

Onay zincirleri, test süreçleri, deployment kayıtları — bunların tamamının belgelenmesi zorunlu. BDDK denetçileri artık sadece finansal tabloları değil, IT sistemlerini ve süreçlerini de inceliyor.

"Değişiklik yönetim sürecinizi göster" talebi bankacılık denetimlerinde standart hale geldi.

ISO 27001

A.12.1.2 maddesi: Bilgi işleme olanaklarını etkileyen değişiklikler kontrol altında olmalı.

Bu madde için denetçi kanıt istiyor. Politika belgesi değil, somut kanıt: değişiklik talep kayıtları, onay belgeleri, test sonuçları, deployment geçmişi.

Sertifikasyon yenilemesinde bu kanıtları sunamamak hem sertifikayı tehlikeye atıyor hem de kurumun gerçek güvenlik olgunluğunu sorgulatıyor.

SPK ve Diğerleri

Sermaye Piyasası Kurulu, SEDDK, Hazine ve Maliye Bakanlığı denetimleri — hepsinin ortak noktası şu: IT sistemlerinde ne olduğunu belgeleyebilmek.

Mevcut Audit Yöntemlerinin Kırılgan Yapısı

Kurumların çoğu audit ihtiyacını şu yöntemlerle karşılamaya çalışıyor:

SQL Server Native Audit Teknik olarak var. Ama logları analiz etmek ayrı bir uzmanlık gerektiriyor. Alarm mekanizması yok. Onay süreciyle entegre değil. "Kim onayladı?" sorusunu yanıtlamıyor.

DDL Trigger Hızlı kurulum. Ama sysadmin tarafından devre dışı bırakılabiliyor. Bildirim yok. Onay kaydı yok.

E-posta ve Excel "Onay aldım" diye bir e-posta zinciri. Denetimde bu kabul edilmiyor. Kim gönderdi, kim onayladı, hangi versiyonu onayladı, onay öncesi ne incelendi — bunlar e-postada yok.

Bu yöntemlerin ortak sorunu şu: hepsi reaktif. Bir şey olduktan sonra bakılıyor. Önleme yok, gerçek zamanlı tespit yok, bütünleşik kayıt yok.

Gerçek Audit Trail Nasıl Görünmeli?

Bir denetçinin önüne koyabileceğiniz gerçek bir audit kaydı şöyle görünmeli:

Değişiklik ID: CHG-2024-0847

Talep Eden: Ahmet Yılmaz (Kıdemli Geliştirici) Talep Tarihi: 15 Mart 2024, 14:23

Değişiklik Açıklaması: dbo.SP_SiparisHesapla stored procedure güncelleme — KDV hesaplama mantığı düzeltmesi

Validasyon Sonucu: 12 kural kontrol edildi, 2 uyarı, 0 kritik hata Risk Skoru: 34 / 100 (Orta Risk)

Sandbox Test: 15 Mart 2024, 15:10 — 847 satır etkilendi, sonuçlar beklenen değerlerle eşleşti

Teknik Onay: Mehmet Kaya (DBA) — 15 Mart 2024, 16:45 — "Validasyon sonuçları incelendi, uygun" Yönetici Onay: Elif Demir (IT Müdürü) — 15 Mart 2024, 17:20 — "İş gereksinimi doğrulandı, onaylıyorum"

Deployment: 15 Mart 2024, 22:00 — Otomatik çalıştırma (Auto Execution) Deployment Süresi: 4 dakika 12 saniye Sonuç: Başarılı

Doğrulama: 15 Mart 2024, 22:15 — Kritik sorgular test edildi, performans beklenen aralıkta

Rollback Script: Mevcut (Otomatik üretildi, arşivlendi)

Bu kayıt denetçinin sorduğu her soruyu yanıtlıyor. Kim, ne, ne zaman, neden, kim onayladı, sonuç ne oldu.

Prosedür Dışı Değişiklik: Audit'in En Zor Kısmı

Kontrollü değişiklikleri kayıt altına almak görece kolay. Asıl zor olan şu: ya biri süreci atlayıp doğrudan değişiklik yaparsa?

Sysadmin SSMS'i açar, gece production'a bağlanır, bir şeyler değiştirir, çıkar. Hiçbir platforma kayıt düşülmedi. Sabah kimsenin haberi yok.

Gerçek audit'in bu durumu da kapsaması gerekiyor.

SQL Change Guard'ın External Database Changes Monitoring modülü tam bu boşluğu kapatıyor.

Platform, veritabanı şemasının düzenli anlık görüntülerini alıyor. Her kontrol döngüsünde mevcut durum bir öncekiyle karşılaştırılıyor. Platform üzerinden yapılmamış bir değişiklik tespit edildiğinde ilgili kişilere anında alarm gidiyor.

Bu tespitin denetim değeri çok yüksek. "Prosedür dışı değişiklikleri nasıl yakalıyorsunuz?" sorusuna "otomatik alarm üretiyoruz ve kayıt altına alıyoruz" cevabı vermek, "bilmiyoruz" demekten çok farklı bir konumu ifade ediyor.

Object History: Geçmişi Yeniden Kurmak

Denetçi soruyor: "Bu stored procedure 3 ay önce nasıldı?"

Object History modülü bu soruyu saniyeler içinde yanıtlıyor. Her veritabanı nesnesinin tüm değişim tarihçesi, versiyon bazında saklanıyor. İki versiyon arasındaki fark diff görünümüyle yan yana gösteriliyor.

Hangi satır eklendi, hangisi silindi, hangisi değiştirildi — kelimesi kelimesine görünüyor.

Bu özellik sadece denetim için değil. Bir sorun yaşandığında "bu nesne en son ne zaman değişti" sorusu da aynı ekrandan yanıtlanıyor.

Audit Raporları: Denetim Paketiniz Hazır

SQL Change Guard'ın Reporting modülü denetim gereksinimlerini karşılamak üzere tasarlandı.

KVKK Audit Raporu Kişisel veri içeren tablolarda yapılan değişiklikler, erişim kayıtları, veri maskeleme logları. Kişisel Verileri Koruma Kurulu formatına uygun.

BDDK Değişiklik Geçmişi Raporu Belirli dönemdeki tüm deployment'lar, onay zincirleri, başarı/başarısızlık durumları. BDDK bilgi sistemleri yönetmeliği gereksinimleriyle örtüşen format.

ISO 27001 Kanıt Paketi A.12.1.2 maddesi kapsamında değişiklik kontrolü kanıtları. Talep, onay, test, deployment — eksiksiz belgelenmiş zincir.

Prosedür Dışı Değişiklik Raporu Platform dışından yapılan değişikliklerin dönemi, tespit zamanları, alarm kayıtları ve takip durumları.

Erişim ve Yetki Raporu Platforma erişimi olan kullanıcılar, yetki seviyeleri, son aktivite tarihleri.

Denetim öncesinde "rapor topluyoruz, birkaç güne bakın" dönemi bitiyor. Bu raporlar her an, dakikalar içinde üretiliyor.

Audit'in Görünmez Faydası

Audit genellikle denetim hazırlığı olarak düşünülüyor. Ama gerçek faydası çok daha geniş.

Ekip içi hesap verebilirlik: Herkes yaptığının kaydedildiğini biliyor. Bu bilgi davranışı değiştiriyor. "Birileri bakıyor" hissi disiplin üretiyor.

Hızlı sorun çözümü: Bir şeyler ters gittiğinde "bu ne zaman değişti, kim değiştirdi" sorusu saniyeler içinde yanıtlanıyor. Saatlerce log karıştırmak tarihe karışıyor.

Güvence: DBA veya geliştirici "ben yapmadım" demek istediğinde kanıtı var. Ya da yaptığını doğrulamak istediğinde de kanıtı var. Her iki durumda da sistem kişiyi koruyor.

Kurumsal hafıza: 2 yıl önce yapılan bir değişikliği araştırmak gerekiyor. Kayıt var. Geçmiş erişilebilir.

Başlamak İçin Ne Gerekiyor?

Audit altyapısı kurmak büyük bir proje gibi görünüyor. Aslında değil.

SQL Change Guard kurulum gereksinimleri minimal: DLL ve EXE dosyalarının kopyalanması. Setup paketi yok, ağır bağımlılık yok. Tamamen kurum içi ağda çalışıyor, hiçbir veri dışarıya çıkmıyor.

Kurulum tamamlandıktan sonra her değişiklik otomatik olarak kayıt altına alınmaya başlıyor. Geçmiş inşa ediliyor. Denetim hazırlığı birikmeye başlıyor.

Son Söz

Denetçi kapıdan girdiğinde iki cümleden birini söyleyeceksiniz.

"Raporları hazırlıyoruz, biraz zaman verin."

Ya da:

"Hangi dönemi, hangi sistemi istiyorsunuz? Şu an üretiyorum."

Bu fark bir yazılım farkı. Ama aynı zamanda kurumun veritabanı yönetimine ne kadar hakim olduğunun farkı.

Audit bir zorunluluk. Ama doğru araçla bu zorunluluk yük olmaktan çıkıp kurumsal güce dönüşüyor.

Ücretsiz demo ve daha fazla bilgi için: sqlchangeguard.com

Neden Bu Kadar Zor? Veritabanı değişiklik yönetiminin neden bu kadar çok kurumda eksik kaldığını anlamak için biraz geriye gitmek gerekiyor. DBA bir stored procedure güncelledi. Geliştirici bir tablo değişikliği yaptı. Sistem yöneticisi gece bir şeyler düzeltti. Bunların tamamını kim, ne zaman, hangi onaylayla yaptı? Bu bilgiyi tutmak için sistematik bir yapı gerekiyor. Çoğu kurum bunu e-posta, Excel ya da "ekip biliyor" güvencesiyle yönetmeye çalışıyor. Denetim gelene kadar bu yeterliymiş gibi görünüyor. Denetim gelince değil. SQL Change Guard bu sistematik yapıyı kuruyor. Ama bunu yaparken geliştirici ve DBA akışını boğmadan, hızı koruyarak yapıyor. İşte bu denge en kritik nokta.

Platform Bir Bütün Olarak Nasıl Çalışıyor? Her değişiklik bir talep ile başlar. Bu talep platformda kayıt altına alınır, analiz edilir, onaylanır, test edilir ve production'a alınır. Her adım belgelenir. Platform dışından yapılan bir değişiklik olursa bu da tespit edilir ve alarm üretilir. Kulağa basit geliyor. Ama her adımın arkasında güçlü bir altyapı var. Modül modül açıklayalım.

Modüller Change Management: Sürecin Omurgası Her şey buradan geçiyor. Geliştirici değişiklik talebini oluşturur, script'i platforma yükler, açıklama yazar. Sistem otomatik analizi başlatır. Analiz tamamlandıktan sonra talep onay akışına girer. Onay tamamlandığında deployment gerçekleşir. Her adım zaman damgasıyla kayıt altına alınır. Bu yapı görevler ayrılığı prensibini zorla uygular. Değişikliği yükleyen kişi aynı değişikliği onaylayamaz. Bu teknik bir kısıtlama, politika belgesi değil. BDDK ve COBIT denetimlerinde "değişiklik yönetim sürecinizi gösterir misiniz?" sorusuna cevap bu modülden geliyor. Talep, onay, deployment, kimin ne zaman ne yaptığı — eksiksiz kayıt.

Validation: 65+ Kural, Sıfır Sürpriz Script platforma yüklendiği anda 65'ten fazla kural devreye giriyor. WHERE koşulsuz DELETE veya UPDATE var mı? DROP TABLE içeriyor mu? Büyük tabloda kilit riski taşıyan bir operasyon mu? Naming convention'a uygun mu? Foreign key ihlali yaratıyor mu? Bu kurallar hem teknik hataları hem de yönetişim ihlallerini yakalıyor. Önemli bir detay: kural seti kuruma göre özelleştirilebilir. Bankacılık sektörünün ihtiyaçları farklı, e-ticaretin farklı. Validasyon sonuçları hem geliştirici hem onaylayan için şeffaf. "Neden reddedildi?" sorusu sormak gerekmiyor, sistem gösteriyor.

Risk Scoring: Her Değişiklik Aynı Değil Validasyon sonuçlarına göre 0-100 arası bir risk skoru hesaplanıyor. Bu skor sadece bir sayı değil. Onay akışını şekillendiriyor. Düşük riskli değişiklikler hızlı onay alıyor. Yüksek riskli değişiklikler ek onay seviyelerine gidiyor. Kritik skordaki değişiklikler otomatik olarak engelleniyor, manuel inceleme zorunlu hale geliyor. Denetim açısından bu skor altın değerinde. "Neden bu değişiklik ek onay gerektirdi?" sorusuna sistem kendisi cevap veriyor.

Sandbox: Önce Gör, Sonra Yap Production'a geçmeden önce değişikliği gerçek veriyle test etmek istiyorsunuz ama production'u etkilemek istemiyorsunuz. Sandbox tam bunu yapıyor. BEGIN-ROLLBACK mekanizmasıyla script production verisine karşı çalıştırılıyor, sonuçlar görülüyor, geri alınıyor. Production'da hiçbir iz kalmıyor. Geliştirici şunu görüyor: kaç satır etkilenecek, hangi kayıtlar değişecek, tahmini çalışma süresi ne. Sürpriz yok. KVKK perspektifinden bakıldığında bu özellik kritik. Kişisel veri içeren tablolarda değişiklik yapmadan önce etkinin görülmesi veri ihlali riskini ciddi ölçüde azaltıyor.

Rollback: Her Deployment'ın Güvencesi Değişiklik onaylandı ve production'a alındı. Bir şeyler ters gitti. Rollback modülü bu an için var. Platform her deployment öncesinde otomatik rollback script'i üretiyor. Stored procedure değiştirildiyse eski versiyonu saklıyor. Tablo değişikliği yapıldıysa geri alma adımlarını hazırlıyor. Bir kriz anında "nasıl geri döneceğiz?" sorusu zaten yanıtlanmış oluyor. Panik değil, prosedür. Denetim açısından ise rollback planının varlığı ISO 27001 gereksinimlerinden biri. "Değişiklikleriniz için geri alma prosedürünüz var mı?" sorusu artık "evet, her deployment için otomatik üretiliyor" cevabıyla yanıtlanıyor.

Auto Execution: Onaylı Değişiklik, Otomatik Deployment Onay süreci tamamlandı. Deployment penceresini bekliyorsunuz. Gece 02:00'de biri deployment'ı manuel başlatacak. Auto Execution bu ihtiyacı ortadan kaldırıyor. Onaylanan değişiklik, belirlenen zamanda otomatik olarak çalıştırılıyor. Kimsenin gece bağlanmasına gerek yok. Ama kritik güvence: otomatik çalışacak olan değişiklik onaylı ve kayıtlı. "Otomatik oldu, kontrol edemedik" söylemi tarih oluyor.

Release Package: Toplu Değişiklikleri Düzenli Yönetmek Gerçek hayatta değişiklikler tek gelmez. Bir özellik geliştirmesi 12 script içerebilir. Bu script'lerin doğru sırayla, doğru ortamlara alınması gerekiyor. Release Package bu karmaşıklığı çözüyor. İlgili değişiklikler paket altında gruplanıyor, bağımlılık sırası tanımlanıyor, paket bütünüyle onaylanıyor ve bütünüyle deploy ediliyor. "Şu script atıldı mı? Hangisi önce gitmeliydi?" soruları tarihe karışıyor.

Query Result: Hassas Veri Görünürlüğünü Kontrol Altına Almak DBA platform üzerinden bir sorgu çalıştırdı. Sorgu sonucu TC kimlik numaraları, IBAN'lar, tıbbi kayıtlar içeriyor. Query Result modülü bu sonuçları kullanıcının yetki seviyesine göre maskeleyerek gösteriyor. Ad: ali **** TC: 12345* IBAN: TR33 **** **** **** **** ** Bu özellik KVKK'nın teknik güvenlik tedbirleri yükümlülüğünü doğrudan karşılıyor. "Kişisel verilere yetkisiz erişimi nasıl önlüyorsunuz?" sorusuna somut bir teknik cevap.

Performance Report: Değişiklik Performansı Nasıl Etkiledi? Deployment öncesi kritik sorgular ne kadar sürüyordu? Deployment sonrası ne kadar sürüyor? Performance Report bu karşılaştırmayı görselleştiriyor. Hangi sorgular yavaşladı, hangileri hızlandı, ortalama response time nasıl değişti. Bu modül hem teknik hem yönetim için değerli. Teknik ekip regresyonu erken yakalıyor. Yönetim ise değişikliklerin sistem üzerindeki etkisini somut metriklerle görüyor.

Object History: Geçmişe Tek Tıkla Bakmak Bir stored procedure'ün 8 ay önceki versiyonu ne içeriyordu? Object History modülü her veritabanı nesnesinin tüm değişim tarihçesini tutuyor. Kim değiştirdi, ne zaman, hangi release package içinde, hangi onaylayla. İki versiyon arasındaki fark diff görünümüyle yan yana gösteriliyor. Kelimesi kelimesine ne değişti, görünüyor. Denetimde "bu nesne nasıl evrildi?" sorusu artık saniyeler içinde yanıtlanabiliyor.

External Database Changes Monitoring: En Kritik Özellik Bir gerçeği kabul edelim: sysadmin yetkisine sahip biri SSMS'i açıp doğrudan production'da istediği değişikliği yapabilir. Bunu engellemek SQL Server mimarisi gereği mümkün değil. Ama tespit etmek mümkün. External Database Changes Monitoring, platform dışından yapılan her değişikliği otomatik tespit ediyor. Biri gece SSMS'ten bir stored procedure güncelledi. Platform bunu yakaladı. Sabah ilgili kişilere bildirim gitti: "23:47'de dbo.SP_SiparisHesapla nesnesi platform dışından değiştirildi." Engelleyemediniz. Ama haberdar oldunuz. Ve bu fark, kontrollü yönetim ile kör kalmak arasındaki farktır. Denetim açısından ise bu özellik son derece güçlü bir kanıt: "Sistem dışından yapılan değişiklikleri nasıl tespit ediyorsunuz?" sorusuna verilen yanıt artık "otomatik alarm üretiyoruz ve kayıt altına alıyoruz."

Reporting: Denetim Paketi Hazır Tüm bu modüllerin ürettiği veri Reporting modülünde anlam kazanıyor. KVKK Denetim Raporu Kişisel veri içeren tablolarda yapılan değişiklikler, erişim logları, maskeleme kayıtları. Kişisel Verileri Koruma Kurulu'na sunulmak üzere biçimlendirilmiş. BDDK Değişiklik Yönetim Raporu Belirli bir dönemdeki tüm değişiklikler, onay zincirleri, deployment geçmişi. BDDK bilgi sistemleri yönetmeliği gereksinimlerine uygun format. ISO 27001 Denetim Raporu A.12.1.2 maddesi kapsamında değişiklik yönetimi kanıtları. Talep, onay, test, deployment, doğrulama — her adım belgelenmiş. Prosedür Dışı Değişiklik Raporu Platform dışından yapılan değişikliklerin dönemi ve dağılımı. Tespit zamanları, alarm kayıtları, takip durumları. Risk Dağılımı Raporu Hangi risk seviyesinde kaç değişiklik yapıldı? Kritik değişiklikler nelerdi, nasıl yönetildi? Kullanıcı Aktivite Raporu Kim kaç değişiklik talebi oluşturdu, kaçı onaylandı, kaçı reddedildi? Bir denetimde bu raporları dakikalar içinde üretmek, "elimizde bu kayıtlar yok" demek ile aranızdaki farkı belirliyor.

Türkiye'nin Özgün Gereksinimleri Yabancı araçlar teknik olarak güçlü olabilir. Ama Türkiye'de çalışan kurumların özgün gereksinimleri var. KVKK: Kişisel Verileri Koruma Kanunu sadece bir uyum gerekliliği değil, ihlali halinde ağır yaptırımları olan bir yasal zorunluluk. SQL Change Guard KVKK teknik tedbirlerini karşılamak üzere tasarlandı. BDDK: Bankacılık sektörü bilgi sistemleri yönetmeliği değişiklik yönetimini açıkça düzenliyor. Bu düzenlemeye uyum SQL Change Guard ile belgeli ve kanıtlanabilir. Türkçe Arayüz: Operasyon ekibinin İngilizce bilen uzman olması gerekmiyor. Tüm arayüz Türkçe. Yerel Destek: Türkiye'den, Türkçe teknik destek. Tamamen On-Premise: Hiçbir veri dışarıya çıkmıyor. Kurumun kendi ağında, kendi kontrolünde.

Kim İçin? DBA: Tüm değişiklikleri tek noktadan görme, nesne geçmişine anında erişim, platform dışı değişiklik alarmları. Geliştirici: Sandbox ile güvenli test, otomatik rollback, validasyon geri bildirimi. IT Yöneticisi: Risk bazlı onay mekanizması, deployment görünürlüğü, performans raporları. Compliance Ekibi: KVKK ve BDDK'ya hazır raporlar, prosedür dışı değişiklik geçmişi. Üst Yönetim: Kurumun veritabanı değişiklik riskini özetleyen yönetim raporları.

Sonuç: Denetçi Tekrar Kapıdan Girecek BDDK denetçisi tekrar gelecek. KVKK soruşturması başlayabilir. ISO 27001 sertifikasyon denetimi yaklaşıyor. O an geldiğinde iki kurumdan biri olacaksınız. Birincisi: "Raporları şimdi hazırlıyoruz, birkaç güne bakın." İkincisi: "Hangi dönemi istiyorsunuz? Raporları şu an üretiyorum." Bu fark bir araç farkı. Ama aynı zamanda bir olgunluk farkı, bir hazırlık farkı. SQL Change Guard bu olgunluğu inşa etmek için geliştirildi.

Ücretsiz demo ve daha fazla bilgi için: sqlchangeguard.com

İstatistik Neden Bu Kadar Önemli? Query Optimizer, bir sorgunun nasıl çalıştırılacağına karar verirken istatistiklere bakar. Tablodaki veri dağılımı, satır sayısı, değer tekrar sıklığı — bunların tamamı istatistiklerde tutulur. İstatistikler eskidikçe optimizer yanlış tahminler yapar. Yanlış tahmin yanlış plan. Yanlış plan yavaş sorgu.

İstatistiklerin Durumunu İnceleme sql-- Eskimiş istatistikleri tespit et SELECT OBJECT_NAME(s.object_id) AS TabloAdi, s.name AS IstatistikAdi, sp.last_updated AS SonGuncelleme, sp.rows AS ToplamSatir, sp.rows_sampled AS OrnekSatir, sp.modification_counter AS DegisiklikSayisi FROM sys.stats s CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp WHERE sp.modification_counter > 1000 OR sp.last_updated < DATEADD(DAY, -7, GETDATE()) ORDER BY sp.modification_counter DESC; sql-- Tablo bazında istatistik özeti SELECT t.name AS TabloAdi, COUNT(s.stats_id) AS IstatistikSayisi, MIN(sp.last_updated) AS EnEskiGuncelleme, MAX(sp.modification_counter) AS MaxDegisiklik FROM sys.tables t JOIN sys.stats s ON t.object_id = s.object_id CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp GROUP BY t.name ORDER BY MAX(sp.modification_counter) DESC;

Otomatik İstatistik Güncelleme ve Riskleri SQL Server varsayılan olarak istatistikleri otomatik günceller. Bu genellikle iyi bir şey. Ama bazı durumlarda sorun yaratır. Otomatik güncelleme zamanlaması İstatistik güncelleme tam bir sorgu çalışırken tetiklenirse o sorgu güncelleme tamamlanana kadar bekler. Büyük tablolarda bu bekleme dakikalarca sürebilir. Asenkron güncelleme AUTO_UPDATE_STATISTICS_ASYNC aktif edildiğinde güncelleme arka planda gerçekleşir. Sorgu beklemiyor ama güncel istatistikle başlamıyor. Bu ayarın değiştirilmesi de bir yapılandırma değişikliği.

Manuel İstatistik Güncelleme Stratejisi Kritik tablolar için manuel istatistik güncelleme job'ı kurmak daha kontrollü bir yaklaşım. sql-- Tek tablo tüm istatistiklerini güncelle UPDATE STATISTICS dbo.Siparisler WITH FULLSCAN;

-- Tek istatistiği güncelle UPDATE STATISTICS dbo.Siparisler IX_Siparisler_MusteriID WITH FULLSCAN;

-- Tüm veritabanı istatistiklerini güncelle EXEC sp_updatestats; WITH FULLSCAN tüm veriyi tarar, daha doğru istatistik üretir ama daha uzun sürer. WITH SAMPLE 30 PERCENT örnekleme yapar, daha hızlı ama daha az kesin.

İstatistik Güncelleme Sonrası Plan Değişimi Riski İstatistik güncellendikten sonra Query Optimizer bazı sorgular için farklı execution plan seçebilir. Yeni plan çoğunlukla daha iyi ama her zaman değil. Bu nedenle büyük istatistik güncellemeleri sonrasında kritik sorguların performansı izlenmeli. sql-- İstatistik güncellemesi sonrası plan cache'ini temizle -- DİKKAT: Tüm planlar temizlenir, dikkatli kullanın -- DBCC FREEPROCCACHE;

-- Sadece belirli bir veritabanının planlarını temizle ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

Değişiklik Yönetimiyle İlişkisi İstatistik stratejisinde yapılan değişiklikler değişiklik yönetim kapsamına girmeli:

Otomatik istatistik güncelleme açılıyor/kapatılıyor Asenkron güncellemeye geçiliyor Manuel güncelleme job'u oluşturuluyor veya değiştiriliyor Örnekleme oranı değiştiriliyor

Bunların tamamı performance'ı etkilediğinden test ortamında doğrulanmalı ve onay sürecinden geçmeli.

Sonuç İstatistikler görünmez ama sorgu performansını doğrudan etkileyen kritik yapılar. Güncelleme stratejisi değişiklik yönetiminin bir parçası olarak ele alındığında hem performans hem istikrar korunur. Detaylı bilgi için: sqlchangeguard.com

Collation Neden Önemli? Collation üç şeyi etkiler: büyük/küçük harf duyarlılığı, aksan duyarlılığı ve karakter sıralama düzeni. SQL_Latin1_General_CP1_CI_AS ile Turkish_CI_AS arasındaki fark küçük görünür. Ama Türkçe karakterler içeren veritabanlarında yanlış collation şu sonuçlara yol açar:

"istanbul" ile "İstanbul" eşit sayılmayabilir ORDER BY sıralaması beklenmedik sonuç verir JOIN işlemleri karakter farklılığı nedeniyle başarısız olabilir Full-text search yanlış sonuçlar döndürür

Collation Mevcut Durumu İnceleme sql-- Sunucu collation SELECT SERVERPROPERTY('Collation') AS SunucuCollation;

-- Veritabanı collation SELECT name AS VeritabaniAdi, collation_name AS Collation FROM sys.databases ORDER BY name;

-- Kolon bazında farklı collation kullananlar SELECT t.name AS TabloAdi, c.name AS KolonAdi, c.collation_name AS KolonCollation, DATABASEPROPERTYEX(DB_NAME(), 'Collation') AS VeritabaniCollation FROM sys.tables t JOIN sys.columns c ON t.object_id = c.object_id WHERE c.collation_name IS NOT NULL AND c.collation_name != CAST(DATABASEPROPERTYEX(DB_NAME(), 'Collation') AS NVARCHAR(128)) ORDER BY t.name, c.name; Son sorgu veritabanı varsayılanından farklı collation kullanan kolonları listeler. Bu kolonlar potansiyel uyumsuzluk noktaları.

Collation Değiştirmenin Zorlukları Veritabanı collation değiştirme Veritabanı collation'ını değiştirmek mevcut verileri otomatik dönüştürmez. Sadece yeni oluşturulacak nesnelerin varsayılan collation'ını belirler. Mevcut char, varchar, nvarchar kolonlarının collation'ını değiştirmek için her kolonu ayrı ayrı ALTER TABLE ile güncellemek gerekir. sql-- Tek kolon için collation değiştirme örneği ALTER TABLE dbo.Musteriler ALTER COLUMN Sehir NVARCHAR(100) COLLATE Turkish_CI_AS NOT NULL; Ama bu işlem büyük tablolarda çok uzun sürer ve kilit sorunlarına yol açar. Sistem nesneleriyle uyumsuzluk Geçici tablolar (#temp) sunucu collation'ını kullanır. Veritabanı collation'ı farklıysa geçici tablolarla JOIN yapmak collation uyumsuzluk hatası verebilir.

Collation Değişikliği Neden Değişiklik Yönetiminin En Riskli Konularından Biri? Geri alınması son derece zor: Collation değiştirildikten sonra geri almak neredeyse yeni bir migration yapmak kadar karmaşık. Etki alanı çok geniş: Tüm string kolonlar, tüm sorgular, tüm JOIN işlemleri etkilenebilir. Test edilmesi zor: Test ortamında sorun çıkmayabilir, asıl sorunlar production verisinin çeşitliliğiyle ortaya çıkar.

Collation Değişikliği İçin Minimum Gereksinimler Bu değişiklik yüksek risk kategorisinde değerlendirilmeli ve şunlar zorunlu olmalı: Tüm etkilenen kolonların listesi. Her kolon için dönüşüm ve geri alma script'i. Test ortamında production verisiyle test sonuçları. Uygulama katmanı testi. Onay için teknik ekip ve uygulama geliştiricilerinin birlikte imzası.

Sonuç Collation değişikliği veritabanı değişikliklerinin en karmaşık ve en riskli kategorilerinden biri. "Küçük bir ayar değişikliği" gibi görünse de etkisi tüm sisteme yayılabilir. Bu değişiklik asla hafife alınmamalı. Detaylı bilgi için: sqlchangeguard.com

Database Snapshot Nedir? Database Snapshot, belirli bir anın veritabanı görüntüsüdür. Fiziksel olarak tüm veriyi kopyalamaz. Bunun yerine değişen sayfalar ayrı bir dosyada tutulur, değişmeyen sayfalar kaynak veritabanından okunur. Bu yapı snapshot oluşturmayı son derece hızlı kılar. Büyük bir veritabanının snapshot'ı saniyeler içinde oluşturulur.

Deployment Öncesi Snapshot Oluşturma sql-- Deployment öncesi snapshot oluştur CREATE DATABASE SatisDB_Snapshot_20240315 ON ( NAME = SatisDB, FILENAME = 'D:\Snapshots\SatisDB_20240315_1430.ss' ) AS SNAPSHOT OF SatisDB; Bu snapshot deployment başlamadan hemen önce alınır. Deployment başarısız olursa ya da beklenmedik bir sorun çıkarsa snapshot'tan geri dönülebilir.

Snapshot'tan Geri Dönme sql-- Snapshot'tan veritabanını geri yükle -- Önce tüm bağlantıları kes ALTER DATABASE SatisDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

-- Snapshot'tan geri yükle RESTORE DATABASE SatisDB FROM DATABASE_SNAPSHOT = 'SatisDB_Snapshot_20240315';

-- Çok kullanıcılı moda geri al ALTER DATABASE SatisDB SET MULTI_USER; Geri yükleme çok hızlı. Değişen sayfalar snapshot'tan okunarak geri yazılır.

Snapshot'un Sınırları Sadece tam geri dönüş: Snapshot ya tamamen kullanılır ya da kullanılmaz. Belirli tabloları geri almak için kullanılamaz. Kaynak veritabanına bağımlılık: Snapshot, kaynak veritabanı olmadan anlamsız. Kaynak veritabanı bozulursa snapshot da kullanılamaz. Depolama büyümesi: Kaynak veritabanında değişiklik oldukça snapshot dosyası büyür. Uzun süre açık bırakılan snapshot'lar disk alanı tüketir. Tek yönlü: Snapshot salt okunur. Üzerinde değişiklik yapılamaz.

Snapshot Ne Zaman Yeterli Değil? Snapshot deployment sonrası "anlık geri dönüş" için idealdir. Ama uzun vadeli backup yerine geçmez. Şu durumlarda tam backup gerekir:

Disaster recovery senaryoları Uzun vadeli veri arşivleme Farklı sunucuya taşıma Geçmiş bir tarihe noktasal geri dönüş

Değişiklik Yönetimiyle Entegrasyon Deployment planına snapshot adımını ekleyin:

Deployment penceresi başladı Snapshot alındı (snapshot adı, zamanı kayıt altına alındı) Deployment uygulandı Doğrulama yapıldı Sorun yoksa snapshot silindi Sorun varsa snapshot'tan geri dönüldü

Bu adım özellikle rollback script'i karmaşık olan ya da büyük veri değişikliği içeren deployment'lar için zorunlu olmalı.

Snapshot Maliyeti Snapshot oluşturmak neredeyse ücretsiz. Saniyeler sürer, anlık disk kullanımı minimal. "Snapshot almak zaman alır" gerekçesiyle bu adım atlanmamalı. Risk/fayda dengesi her zaman snapshot lehine.

Sonuç Database Snapshot, deployment sürecinin göz ardı edilen ama son derece değerli bir güvenlik mekanizması. Değişiklik yönetim planına eklenmesi hem geri dönüş süresini kısaltır hem de ekibin deployment sırasındaki güvenini artırır. Detaylı bilgi için: sqlchangeguard.com

Replikasyon Türleri ve Değişiklik Riski Snapshot Replikasyon Periyodik olarak tüm veri kopyalanır. Değişiklik yönetimi açısından en az riskli. Ama schema değişikliği snapshot döngüsünü etkileyebilir. Transactional Replikasyon Publisher'daki her DML değişikliği distribution database üzerinden subscriber'a iletilir. Bu ortamda schema değişikliği en dikkatli yönetilmesi gereken senaryo. Merge Replikasyon Her iki taraf da değişiklik yapabilir. Çakışma yönetimi zaten karmaşık. Üzerine bir de schema değişikliği eklendiğinde risk katlanır.

Transactional Replikasyon'da Schema Değişikliği Transactional replikasyonda publisher'a yapılan DDL değişikliklerinin subscriber'a da uygulanması gerekir. SQL Server bunu otomatik olarak replike eder ama dikkat edilmesi gereken noktalar var. sql-- Replikasyon durumunu kontrol et SELECT pub.name AS YayinAdi, art.name AS NesneAdi, sub.subscriber_db AS AboneVeritabani, sub.subscription_type AS AboneTipi, msd.distributor AS DagiticiSunucu FROM syspublications pub JOIN sysarticles art ON pub.pubid = art.pubid JOIN syssubscriptions sub ON art.artid = sub.artid CROSS JOIN msdb.dbo.MSdistpublishers msd; sql-- Replikasyon log reader gecikmesini kontrol et SELECT agent_id, start_time, time, comments, runstatus FROM distribution..MSlogreader_history WHERE time > DATEADD(HOUR, -1, GETDATE()) ORDER BY time DESC;

Replikasyonlu Ortamda Değişiklik Öncesi Kontroller

1. Replikasyon sağlığını doğrulayın Değişiklik öncesinde replikasyonun sağlıklı çalıştığından emin olun. Bekleyen işlemler, gecikme, hata durumu varsa önce bunlar çözülmeli.

2. Değişikliğin replike edilip edilmeyeceğini belirleyin Tüm DDL değişiklikleri otomatik replike edilmez. Örneğin bazı index değişiklikleri subscriber'a yansımaz. Bu ayrımı önceden bilmek gerekir.

3. Subscriber'da da değişiklik gerekiyor mu? Bazı durumlarda subscriber'da manuel müdahale gerekir. Bu adım deployment planına dahil edilmeli.

Değişiklik Sonrası Doğrulama sql-- Subscriber ile publisher arasındaki satır sayısı karşılaştırması -- Publisher'da SELECT COUNT(*) AS PublisherSatirSayisi FROM dbo.HedefTablo;

-- Subscriber'da aynı sorguyu çalıştırın -- SELECT COUNT(*) AS SubscriberSatirSayisi FROM dbo.HedefTablo; Deployment sonrası en az 15 dakika replikasyon gecikmesini ve hata loglarını izleyin.

Replikasyonu Durdurma Kararı Bazı schema değişiklikleri için replikasyonu geçici durdurmak gerekebilir. Bu karar deployment planında açıkça belirtilmeli: durdurulacak mı, ne kadar süre, yeniden başlatma adımları neler? Bu karar değişiklik yönetim onay sürecinin bir parçası olmalı.

Sonuç Replikasyon ortamlarında değişiklik yönetimi ek kontroller ve koordinasyon gerektirir. Publisher, distribution ve subscriber'ın tamamı deployment planında yer almalı. Detaylı bilgi için: sqlchangeguard.com

SQL Change Guard Nedir? SQL Change Guard, SQL Server ortamlarında veritabanı değişikliklerini uçtan uca yöneten ve denetleyen kurumsal bir platform. Tek cümleyle özetlemek gerekirse: her SQL değişikliği platforma gelir, analiz edilir, onaylanır, test edilir, production'a alınır ve kayıt altında tutulur. Platform dışından yapılan her değişiklik ise otomatik tespit edilir. Ama bu tek cümle platformun gerçek derinliğini anlatmıyor. Katman katman açıklayalım.

Deployment Öncesi: 65+ Otomatik Validasyon Bir geliştirici değişiklik scriptini platforma yüklediği anda otomatik analiz başlar. 65'ten fazla kural devreye girer. Bu kurallar neler? Birkaç örnek: Kritik risk kuralları:

WHERE koşulsuz DELETE veya UPDATE var mı? DROP TABLE içeriyor mu? Büyük tabloda tam tablo taraması zorlayan bir değişiklik mi? Sistem tablolarına dokunuyor mu?

Yüksek risk kuralları:

Büyük tabloda index düşürme/ekleme var mı? Foreign key kısıtlaması değiştiriliyor mu? Stored procedure mantığı köklü biçimde değişiyor mu?

Orta ve düşük risk kuralları:

Yeni kolon NULL mı, NOT NULL mı? Naming convention'a uygun mu? Yorum satırı var mı?

Her kural bir ağırlık taşır ve sonuçta 0-100 arasında bir risk skoru hesaplanır.

Risk Skoru: 0'dan 100'e Risk skoru platformun en kritik çıktılarından biri. Sadece bir sayı değil, bir karar mekanizması. 0-30 arası (Düşük risk): Onay süreci hızlandırılır. Tek seviyeli onay yeterli olabilir. 31-60 arası (Orta risk): Standart onay süreci işletilir. DBA incelemesi zorunlu. 61-80 arası (Yüksek risk): Ek onay seviyesi gerekir. IT yöneticisi dahil edilir. Sandbox testi zorunlu. 81-100 arası (Kritik risk): Değişiklik otomatik olarak engellenir. Manuel inceleme ve üst yönetim onayı gerekir. Bu mekanizma sayesinde tüm değişiklikler aynı ağırlıkla muamele görmez. Düşük riskli değişiklikler hız kazanırken kritik değişiklikler gerekli dikkati çeker.

Sandbox: Production'a Dokunmadan Test Onay sürecine girmeden önce değişiklik sandbox ortamında test edilebilir. Bu özellik özellikle DML değişiklikleri için kritik. Sandbox, BEGIN-ROLLBACK mekanizmasını kullanır. Script production verisine karşı çalıştırılır, sonuçlar görülür ama değişiklik kaydedilmez. Geliştirici şunları görür:

Script kaç satır etkileyecek? Hangi kayıtlar değişecek, örnek verilerle Tahmini çalışma süresi Olası kilit senaryoları

Production'a geçmeden önce gerçek etkiyi görmek, sürprizleri ortadan kaldırır.

Otomatik Rollback Script Üretimi Her deployment için otomatik rollback script üretilmesi SQL Change Guard'ın en beğenilen özelliklerinden biri. Geliştirici bir stored procedure güncellemesi yaptıysa platform otomatik olarak eski versiyonu saklar ve geri alma script'ini hazır tutar. Tablo değişikliği için kolon geri alma adımları, index değişikliği için geri oluşturma script'i, data migration için ters yönde script — bunların tamamı otomatik. Rollback script'i ayrıca saklanır ve her an erişilebilir. Bir kriz anında "nasıl geri alacağız?" sorusu zaten yanıtlanmış olur.

Rol Bazlı Onay Akışı SQL Change Guard'ın onay mekanizması tek boyutlu değil. Risk seviyesine ve organizasyon yapısına göre şekillendirilebilir. Roller:

Talep Eden: Değişikliği oluşturur ve platforma yükler Teknik Gözden Geçiren: DBA ya da kıdemli geliştirici. Teknik doğruluğu değerlendirir Onaylayan: IT yöneticisi veya değişiklik yöneticisi. İş etkisini değerlendirir Deployment Yetkililisi: Onaylanan değişikliği production'a alır

Görevler ayrılığı prensibi sistem tarafından zorlanır: değişikliği yükleyen kişi aynı değişikliği onaylayamaz. Bu kural teknik bir kısıtlama, politika belgesi değil.

Release Package Yönetimi Gerçek dünyada değişiklikler tek tek gelmez. Bir özellik geliştirmesi 15 farklı script içerebilir. Bu script'lerin doğru sırayla, doğru ortamlara alınması gerekir. Release Package bu sorunu çözer. İlgili değişiklikler bir paket altında gruplanır. Paketin bağımlılık sırası tanımlanır: önce tablo değişikliği, sonra stored procedure, sonra data migration. Paket bütünüyle onaylanır, bütünüyle deploy edilir. Böylece "Şu script atıldı mı? Hangisi önce gitmeliydi?" karmaşası ortadan kalkar.

External Database Changes Monitoring: En Kritik Özellik SQL Server mimarisinin gerçeği şu: sysadmin yetkisine sahip biri SSMS'i açar ve doğrudan istediği değişikliği yapabilir. Bunu teknik olarak engellemek mümkün değil. Ama tespit etmek mümkün. External Database Changes Monitoring, platform dışından yapılan her değişikliği otomatik tespit eder ve ilgili kişilere alarm gönderir. Nasıl çalışır? Platform, veritabanı şemasının düzenli anlık görüntülerini alır. Her kontrol döngüsünde mevcut durum bir öncekiyle karşılaştırılır. Fark varsa değişiklik tespit edilir. Bu değişiklik platform üzerinden yapılmış mı? Kayıtlarda var mı? Yoksa alarm üretilir. Sabah 08:00'de gelen bildirim şu olabilir: "Gece 23:47'de dbo.Siparisler tablosunda ALTER TABLE işlemi tespit edildi. Platform kaydı bulunamadı. İlgili kişi: [bağlantı bilgisi]." Engelleyemediniz. Ama haberdar oldunuz. Ve bu fark, kontrollü müdahale ile kör kalmak arasındaki farktır.

Query Result Veri Maskeleme DBA bir sorguyu platformdan çalıştırıyor. Sorgu sonucu müşteri adları, TC kimlik numaraları, kredi kartı bilgileri içeriyor. Maskeleme aktif olduğunda yetkisiz kullanıcı bu sonucu görse de hassas alanlar maskelenmiş görünür. Ad: ali **** TC: 12345* IBAN: TR33 **** **** **** **** ** Bu özellik hem KVKK uyumu hem de iç güvenlik açısından kritik. Platform üzerinden çalıştırılan her sorgu, kullanıcının yetki seviyesine göre filtrelenerek gösterilir.

Object History: Nesne Değişiklik Geçmişi Bir stored procedure'ün tüm versiyon geçmişine tek ekrandan bakabilmek. Object History modülü her veritabanı nesnesinin eksiksiz değişim tarihçesini sunar:

Versiyon 1: Kim oluşturdu, ne zaman Versiyon 2: Kim değiştirdi, ne değişti, hangi onaylayla Versiyon 3: Kim değiştirdi, hangi release package içinde

İki versiyon arasındaki fark diff görünümüyle yan yana gösterilir. "Geçen ay bu procedure neden değişmişti?" sorusu saniyeler içinde yanıtlanır.

Raporlama Modülü SQL Change Guard'ın raporlama altyapısı hem operasyonel hem de denetimsel ihtiyaçları karşılar. Operasyonel Raporlar Deployment Geçmişi Raporu Belirli bir dönemde yapılan tüm deployment'lar. Hangi değişiklik, kim tarafından, hangi tarihte, başarılı mı başarısız mı. Filtreleme: tarih aralığı, kullanıcı, veritabanı, risk seviyesi. Risk Dağılımı Raporu Yapılan değişikliklerin risk seviyelerine göre dağılımı. Kritik ve yüksek riskli değişiklikler ne kadar? Bu oran artıyorsa neden? Onay Süreci Performans Raporu Ortalama onay süresi ne kadar? Hangi onaylayanda tıkanıyor? Hangi tür değişiklikler en uzun bekleme süresine sahip? Kullanıcı Aktivite Raporu Hangi kullanıcı ne kadar değişiklik talebi oluşturdu? Kaçı onaylandı, kaçı reddedildi? Prosedür dışı değişiklik yapan kullanıcılar var mı? Denetim Raporları Full Audit Trail Raporu Belirli bir dönemdeki tüm değişiklikler: talep, onay, deployment, doğrulama — her adım eksiksiz kayıt. KVKK, BDDK, ISO 27001 denetimlerinde sunulmak üzere biçimlendirilmiş. Prosedür Dışı Değişiklik Raporu Platform dışından yapılan değişiklikler. Ne zaman, hangi nesne, tespit yöntemi, takip durumu. Bu rapor hem iç güvenlik denetimleri hem de regülasyon uyumu için kritik. Erişim ve Yetki Raporu Platforma erişimi olan kullanıcılar, yetki seviyeleri, son erişim tarihleri. Ayrılan çalışanların hesapları kapatıldı mı? Deployment Başarı/Başarısızlık Analizi Başarısız deployment'ların kök neden dağılımı. Tekrarlayan hatalar var mı? Hangi değişiklik kategorisi en fazla rollback gerektirdi?

COBIT, ITIL, KVKK ve ISO 27001 Uyumu SQL Change Guard bu çerçeveleri desteklemek üzere tasarlandı. COBIT BAI06: Değişiklik yönetimini tanımlar ve değişikliklerin kontrollü, onaylı ve izlenebilir olmasını gerektirir. SQL Change Guard bu gereksinimlerin tamamını karşılar. ITIL Change Management: Normal, standart ve acil değişiklik kategorileri. SQL Change Guard bu kategorileri destekler, her tip için farklı süreç tanımlanabilir. KVKK Teknik Tedbirler: Kişisel veri içeren veritabanlarında erişim logları, değişiklik kayıtları ve bu kayıtların düzenli denetimi. SQL Change Guard bu kayıtları otomatik tutar ve raporlar. ISO 27001 A.12.1.2: Değişiklik yönetimi prosedürlerinin kurulması ve belgelenmesi. Platform bu prosedürün hem uygulama hem belgeleme aracı. Bir denetimde "değişiklik yönetim sürecinizi gösterir misiniz?" sorusuna cevap vermek SQL Change Guard ile artık birkaç tıklamaya indirgiyor.

Performance Report Değişiklik sonrası performans nasıl etkilendi? Performance Report modülü deployment öncesi ve sonrası sorgu performansını karşılaştırır. Hangi sorgular yavaşladı, hangileri hızlandı, ortalama response time nasıl değişti? Bu bilgi hem mevcut deployment'ın etkisini ölçer hem de gelecekteki benzer değişiklikler için referans oluşturur.

Tamamen On-Premise, İnternet Bağlantısı Gerekmez SQL Change Guard kurum içi ağda çalışır. Herhangi bir veri dışarıya çıkmaz. Bu özellik özellikle şu kurumlar için kritik:

Bankalar ve finans kurumları: yasal düzenlemeler veri lokasyonunu kısıtlıyor Kamu kurumları: hassas veri kurumun kontrolünde kalmalı Savunma ve kritik altyapı: güvenlik gereksinimleri cloud kullanımını engelliyor Sağlık kurumları: hasta verisi dışarıya çıkamaz

Kurulum basit: DLL ve EXE dosyalarının kopyalanması. Setup paketi yok, ağır bağımlılık yok.

Kim İçin? DBA için: Tüm değişiklikleri tek noktadan görme, prosedür dışı değişiklik alarmları, nesne geçmişine anında erişim. Geliştirici için: Deployment öncesi otomatik validasyon, sandbox test imkânı, rollback script'inin hazır olması. IT Yöneticisi için: Deployment sürecinin tam görünürlüğü, risk bazlı onay mekanizması, denetim raporları. Compliance ve Denetim Ekibi için: KVKK/BDDK/ISO 27001 uyumlu raporlar, tam audit trail, prosedür dışı değişiklik geçmişi. Üst Yönetim için: Kurumun veritabanı değişiklik riskinin özetlendiği yönetim raporları.

Rakiplerden Farkı Liquibase, Flyway, Redgate — bunlar geliştirici araçları. Migration yönetimi, şema versiyonlama, DevOps entegrasyonu konusunda güçlüler. SQL Change Guard farklı bir soruyu çözüyor: kurumsal yönetişim, onay akışı, compliance ve denetim. Özellikle Türkiye'ye özgü bir fark: BDDK ve KVKK uyumu, Türkçe arayüz, yerel destek ve on-premise çalışma zorunluluğu. Yabancı araçlar bu ihtiyaçlara yönelik değil.

Sonuç Veritabanı değişiklik yönetimi artık sadece "iyi bir pratik" değil. Regülasyon zorunluluğu, operasyonel olgunluk ve kurumsal risk yönetiminin temel bileşeni. SQL Change Guard bu ihtiyaca tam karşılık veren, Türkiye'nin özel koşullarına uygun, uçtan uca bir platform. Deployment öncesi validasyondan prosedür dışı değişiklik tespitine, rol bazlı onay akışından denetim raporlarına kadar eksiksiz bir döngü. "Kim ne yaptı?" sorusu artık yanıtsız kalmıyor.

Ücretsiz demo ve daha fazla bilgi için: sqlchangeguard.com

View Değişikliğinin Gizli Etki Alanı Bir view değiştirildi. Ne etkilendi?

Bu view'ı kullanan raporlar Bu view'ı kullanan stored procedure'ler Bu view'ın üzerine kurulu başka view'lar (nested view) Bu view'a bağlı uygulama ekranları Bu view'ı kullanan SSIS paketleri

Bunların tamamını bilmeden yapılan bir view değişikliği beklenmedik yerlerde kırılmalara yol açar.

View Bağımlılıklarını Tespit Etmek sql-- Bir view'a bağımlı tüm nesneleri listele SELECT referencing_schema_name AS Sema, referencing_entity_name AS NesneAdi, referencing_class_desc AS NesneTipi FROM sys.dm_sql_referencing_entities('dbo.vw_SatisOzeti', 'OBJECT') ORDER BY referencing_class_desc, referencing_entity_name; sql-- View'ın bağımlı olduğu nesneleri listele SELECT referenced_schema_name AS Sema, referenced_entity_name AS NesneAdi, referenced_class_desc AS NesneTipi FROM sys.dm_sql_referenced_entities('dbo.vw_SatisOzeti', 'OBJECT') ORDER BY referenced_class_desc, referenced_entity_name;

Yaygın View Değişikliği Senaryoları Kolon eklenmesi Görece güvenli. Ama view'ı SELECT * ile kullanan kodlar beklenmedik kolon alabilir. Kolon kaldırılması Yüksek riskli. View'ı kullanan her nesne bu kolona erişemez hale gelir. Sessiz hata ya da açık hata olabilir. Kolon sırası değiştirilmesi SELECT * kullanan kodlarda veriler yanlış eşleşebilir. Tespit etmek çok zor. JOIN veya WHERE mantığı değiştirilmesi Dönen veri seti değişir. Doğru sonuç verip vermediği bağımlı nesneler test edilmeden bilinemez.

Indexed View Değişikliği Indexed view üzerinde index varsa değişiklik daha da kritik. sql-- Indexed view'ları listele SELECT v.name AS ViewAdi, i.name AS IndexAdi, i.type_desc AS IndexTipi FROM sys.views v JOIN sys.indexes i ON v.object_id = i.object_id WHERE i.index_id > 0 ORDER BY v.name; Indexed view değiştirilmek istendiğinde index önce düşürülmeli, view güncellenmeli, index yeniden oluşturulmalı. Bu üç adımlı süreç değişiklik talebinde açıkça belirtilmeli.

View Değişikliklerini Değişiklik Sürecine Dahil Etmek View değişikliği talebinde şu bilgiler zorunlu olmalı: Hangi view değişiyor? Neden değişiyor? Bağımlılık analizi yapıldı mı, sonuçlar neler? Test ortamında bağımlı nesneler test edildi mi? Bu bilgiler olmadan view değişikliği onaylanmamalı.

Sonuç View'lar görünmez bağımlılık ağları oluşturur. Değişiklik yönetimi kapsamında ele alınmadığında küçük bir view güncellemesi onlarca nesneyi etkileyebilir. Bağımlılık analizi bu riski yönetilebilir kılar. Detaylı bilgi için: sqlchangeguard.com

Resource Governor Nedir? Resource Governor, SQL Server'da belirli iş yüklerine CPU ve bellek kaynaklarının ne kadar tahsis edileceğini kontrol eder. Maintenance operasyonlarını, backup işlemlerini ya da büyük değişiklik deployment'larını ayrı bir resource pool'a yönlendirerek production sorgularının kaynak kullanımını güvence altına alırsınız.

Neden Değişiklik Yönetimiyle İlişkili? Bir deployment sırasında çalıştırılan büyük script sistemi yavaşlatırsa bu hem teknik hem operasyonel sorun. Ama aynı zamanda değişiklik yönetimi açısından da sorun: deployment beklenen şekilde tamamlanmadı. Resource Governor ile deployment operasyonlarına kaynak sınırı koyulduğunda hem production etkilenmez hem de deployment kontrollü biçimde tamamlanır.

Temel Kurulum sql-- Maintenance için ayrı resource pool oluştur CREATE RESOURCE POOL MaintenancePool WITH ( MIN_CPU_PERCENT = 0, MAX_CPU_PERCENT = 20, -- CPU'nun max %20'si MIN_MEMORY_PERCENT = 0, MAX_MEMORY_PERCENT = 30 -- Belleğin max %30'u );

-- Workload group oluştur CREATE WORKLOAD GROUP MaintenanceGroup USING MaintenancePool;

-- Classifier function oluştur CREATE FUNCTION dbo.fn_ResourceClassifier() RETURNS SYSNAME WITH SCHEMABINDING AS BEGIN DECLARE @WorkloadGroup SYSNAME = 'default';

-- Maintenance kullanıcısını ayrı gruba yönlendir
IF SUSER_NAME() = 'MaintenanceUser'
    SET @WorkloadGroup = 'MaintenanceGroup';

RETURN @WorkloadGroup;

END; GO

-- Classifier function'ı aktif et ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.fn_ResourceClassifier);

ALTER RESOURCE GOVERNOR RECONFIGURE;

Değişiklik Deployment'larına Uygulama Büyük deployment'lar için ayrı bir servis hesabı oluşturun. Bu hesabı Resource Governor'da MaintenanceGroup'a yönlendirin. Deployment'lar bu hesap üzerinden çalıştırıldığında sistem kaynaklarının %20'sini geçemez. sql-- Mevcut resource pool kullanımını izle SELECT rp.name AS PoolAdi, rp.max_cpu_percent AS MaxCPU, rpsc.used_memory_kb / 1024 AS KullanilanBellek_MB, rpsc.active_workers_count AS AktifCalisanSayisi FROM sys.resource_governor_resource_pools rp JOIN sys.dm_resource_governor_resource_pools rpsc ON rp.pool_id = rpsc.pool_id ORDER BY rp.name;

Ne Zaman Kullanılmalı? Her deployment için Resource Governor kurmak gerekmez. Özellikle şu senaryolarda değerli:

Index rebuild veya reorganize işlemleri Büyük toplu UPDATE/DELETE operasyonları Mesai saatlerinde yapılmak zorunda kalınan schema değişiklikleri Uzun süren migration script'leri

Sonuç Resource Governor deployment'ların sistemi olumsuz etkilemesini önler. Değişiklik yönetim sürecinin teknik altyapısını güçlendiren ve production kalitesini koruyan önemli bir araç. Detaylı bilgi için: sqlchangeguard.com

Ve bu verilerde yapılan bir hata bazen yıllarca fark edilmeden devam edebilir.

Sigortada Verinin Özelliği

Uzun vadeli etkiler: Hayat sigortası poliçeleri onlarca yıl sürer. Veritabanında yapılan bir değişikliğin etkisi yıllarca devam edebilir.

Geriye dönük hesaplama: Aktüeryal hesaplamalar geçmiş veriye dayanır. Veritabanında geçmişe dönük bir değişiklik yapılırsa tüm hesaplama modelleri bozulabilir.

Regülasyon yoğunluğu: Hazine Müsteşarlığı, SEDDK denetimleri. Veri değişikliklerinin izlenebilir olması yasal zorunluluk.

Sigortaya Özgü Riskler

Aktüeryal tablo değişikliği

Hayat tabloları, faiz oranları, hasar frekans tabloları — bunlarda yapılan bir değişiklik prim hesaplamalarını etkiler. Yanlış hesaplanan primler ya gelir kaybına ya da müşteri mağduriyetine yol açar.

Hasar rezerv verisinin değiştirilmesi

Hasar rezervleri sigortacının bilançosunu doğrudan etkiler. Bu veride yapılan yetkisiz bir değişiklik finansal tablo manipülasyonu anlamına gelebilir.

Poliçe koşullarının retroaktif değiştirilmesi

Bir poliçenin başlangıç tarihine, teminat tutarına ya da istisnalarına geçmişe dönük müdahale hem hukuki hem etik açıdan ağır sonuçlar doğurur.

Sigorta Sektörüne Özel Kontroller

Aktüeryal veriler için ek onay

Prim hesaplama modellerini ya da aktüeryal tabloları etkileyen değişiklikler IT onayının yanı sıra aktüeryal birim onayı almalı.

Geçmişe dönük değişiklik yasağı

Geçmiş dönem poliçe ve hasar verisi değiştirilemez olarak işaretlenmeli. Sadece yeni kayıt eklenebilir, mevcut kayıt güncellenmez.

sql

-- Geçmiş poliçe verisine güncelleme engeli
CREATE TRIGGER trg_Police_NoUpdate
ON dbo.Policeler
INSTEAD OF UPDATE
AS
BEGIN
    -- Geçmiş dönem poliçelere dokunulamaz
    IF EXISTS (
        SELECT 1 FROM deleted
        WHERE BaslangicTarihi < DATEADD(YEAR, -1, GETDATE())
    )
    BEGIN
        RAISERROR('Geçmiş dönem poliçe verisi değiştirilemez.', 16, 1);
        RETURN;
    END

    -- Mevcut dönem poliçeler için normal güncelleme
    UPDATE p SET
        p.TeminatTutari = i.TeminatTutari,
        p.DegisiklikTarihi = GETDATE()
    FROM dbo.Policeler p
    JOIN inserted i ON p.PoliceID = i.PoliceID;
END

Finansal tablo dönem sonu kilitlemesi

Dönem kapandıktan sonra o döneme ait finansal veriler salt okunur hale getirilmeli.

Denetim Hazırlığı

Sigorta denetimlerinde sıkça sorulan soru: "Bu veri değişti mi, kim değiştirdi, ne zaman?"

Bunu yanıtlamak için hem DDL hem DML değişikliklerinin eksiksiz kaydı şart. Temporal Table bu ihtiyacı karşılamak için ideal.

Sonuç

Sigorta sektöründe veritabanı değişiklik yönetimi uzun vadeli etkiler ve yüksek regülasyon baskısı nedeniyle diğer sektörlerden daha titiz yönetilmeli. Geçmişe dönük değişiklik koruması ve aktüeryal onay mekanizması bu sektöre özgü temel gereksinimler.

Detaylı bilgi için: sqlchangeguard.com

Naming Convention Neden Değişiklik Yönetimini Etkiler? Bağımlılık analizi zorlaşır Bir tabloyu değiştirmeden önce bağımlı nesneleri bulmak gerekir. İsimlendirme tutarsızsa arama güçleşir. "Musteri" içeren stored procedure'leri ararken "Customer" içerenleri kaçırırsınız. Yeni değişiklikler tutarsızlığı derinleştirir Standart yoksa her yeni geliştirici kendi alışkanlığıyla nesne oluşturur. Zamanla sistem haritalanamaz hale gelir. Denetimde açıklama zorluğu "Bu tablo neden böyle isimlendirilmiş?" sorusuna yanıt verilemiyor. Denetçi kurumun sistem üzerindeki hakimiyetini sorguluyor.

Tutarsız İsimlendirmenin Tespit Edilmesi sql-- Farklı ön ek kullanan tabloları listele SELECT name AS TabloAdi, CASE WHEN name LIKE 'tbl_%' THEN 'tbl_ öneki' WHEN name LIKE 'T_%' THEN 'T_ öneki' WHEN name LIKE '%_T' THEN '_T soneki' ELSE 'Önek/sonek yok' END AS IsimlendirmeModeli FROM sys.tables ORDER BY IsimlendirmeModeli, name; sql-- Türkçe ve İngilizce karışık nesne adları SELECT name AS NesneAdi, type_desc AS NesneTipi FROM sys.objects WHERE type IN ('U', 'P', 'V', 'FN') AND ( name LIKE '%musteri%' OR name LIKE '%customer%' OR name LIKE '%siparis%' OR name LIKE '%order%' OR name LIKE '%urun%' OR name LIKE '%product%' ) ORDER BY type_desc, name;

Naming Convention Standardı Nasıl Belirlenmeli? Mükemmel standart yoktur. Önemli olan tutarlılık. Tablolar için yaygın yaklaşımlar:

PascalCase: MusteriAdresleri snake_case: musteri_adresleri Önek kullanımı: tbl_MusteriAdresleri

Stored procedure'ler için:

İşlem bazlı isimlendirme: usp_Musteri_Ekle, usp_Siparis_Guncelle

Index'ler için:

IX_TabloAdi_KolonAdi UQ_TabloAdi_KolonAdi (unique index) PK_TabloAdi (primary key)

Standardı Değişiklik Sürecine Dahil Etmek Naming convention değişiklik yönetiminin bir parçası olmalı. Yeni nesne talebi geldiğinde isim standardına uygunluk kontrol edilmeli. Uygun değilse onay sürecinde geri çevrilmeli. Bu hem yeni tutarsızlıkları önler hem de ekipte farkındalık oluşturur.

Mevcut Tutarsızlığı Düzeltmek Mevcut isimlendirme tutarsızlığını düzeltmek büyük bir iş. Bir anda yapmak yerine kademeli yaklaşım daha sağlıklı. Yeni oluşturulan her nesne standarda uygun isimlendirilir. Değiştirilen eski nesneler fırsatçı yeniden isimlendirmeyle düzeltilir. Böylece sistem zamanla olgunlaşır.

Sonuç Naming convention teknik estetik değil, operasyonel sağlık meselesi. Değişiklik yönetim sürecine entegre edilmesi hem yeni tutarsızlıkları önler hem de sistemin anlaşılabilirliğini artırır. Detaylı bilgi için: sqlchangeguard.com

Temporal Table Nedir? SQL Server 2016 ile gelen System-Versioned Temporal Table, bir tablodaki her satırın tüm geçmişini otomatik olarak saklar. Bir satır değiştirildiğinde eski değer sistem tarafından tarih damgasıyla ayrı bir history tablosuna yazılır. Manuel trigger yazmaya gerek yok. CDC kurmaya gerek yok. SQL Server her şeyi otomatik yönetiyor.

Nasıl Oluşturulur? sql-- Temporal table oluşturma CREATE TABLE dbo.UrunFiyatlari ( UrunID INT NOT NULL PRIMARY KEY, UrunAdi NVARCHAR(200) NOT NULL, Fiyat DECIMAL(10,2) NOT NULL, KategoriID INT NOT NULL, -- Sistem sütunları GecerlilikBaslangic DATETIME2 GENERATED ALWAYS AS ROW START NOT NULL, GecerlilikBitis DATETIME2 GENERATED ALWAYS AS ROW END NOT NULL, PERIOD FOR SYSTEM_TIME (GecerlilikBaslangic, GecerlilikBitis) ) WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.UrunFiyatlariGecmis)); Bu kadar. Artık tablodaki her INSERT, UPDATE ve DELETE işlemi otomatik olarak geçmiş tablosuna yazılır.

Geçmişe Sorgu Atmak Temporal Table'ın en güçlü özelliği zaman bazlı sorgulama. sql-- Belirli bir andaki veriyi göster SELECT * FROM dbo.UrunFiyatlari FOR SYSTEM_TIME AS OF '2024-06-15 12:00:00';

-- İki tarih arasındaki tüm değişiklikleri göster SELECT * FROM dbo.UrunFiyatlari FOR SYSTEM_TIME BETWEEN '2024-01-01' AND '2024-12-31' ORDER BY UrunID, GecerlilikBaslangic;

-- Belirli bir ürünün fiyat geçmişi SELECT UrunID, Fiyat, GecerlilikBaslangic AS DegisiklikZamani, GecerlilikBitis AS GecerlilikSonu FROM dbo.UrunFiyatlari FOR SYSTEM_TIME ALL WHERE UrunID = 42 ORDER BY GecerlilikBaslangic;

Mevcut Tabloya Temporal Özelliği Eklemek sql-- Mevcut tabloya sistem sütunları ekle ALTER TABLE dbo.Musteriler ADD GecerlilikBaslangic DATETIME2 GENERATED ALWAYS AS ROW START CONSTRAINT df_Musteriler_Baslangic DEFAULT '2000-01-01 00:00:00.0000000' NOT NULL, GecerlilikBitis DATETIME2 GENERATED ALWAYS AS ROW END CONSTRAINT df_Musteriler_Bitis DEFAULT '9999-12-31 23:59:59.9999999' NOT NULL, PERIOD FOR SYSTEM_TIME (GecerlilikBaslangic, GecerlilikBitis);

-- System versioning'i aktif et ALTER TABLE dbo.Musteriler SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.MusterilerGecmis));

Değişiklik Yönetimiyle İlişkisi Temporal Table değişiklik yönetiminin veri katmanını güçlendirir. Kim hangi tabloyu değiştirdi sorusu DDL Trigger ile yanıtlanır. Hangi satır nasıl değişti sorusu ise Temporal Table ile yanıtlanır. İkisi birlikte kullanıldığında hem yapısal hem verisel değişikliklerin tam geçmişi elde edilir.

Dikkat Edilmesi Gerekenler Depolama alanı: Her değişiklik history tablosuna yazıldığından depolama ihtiyacı artar. Büyük ve sık değişen tablolarda bu ciddi boyutlara ulaşabilir. Geçmiş tablosu için uygun bir retention policy tanımlanmalı. Performans etkisi: Her DML işleminde arka planda history tablosuna yazma yapılır. Genellikle kabul edilebilir düzeyde ama yoğun ortamlarda izlenmeli. Temporal table değişikliği: Temporal table'ı değiştirmek (kolon ekleme, silme) sistem versioning'in geçici olarak kapatılmasını gerektirebilir. Bu işlem de değişiklik yönetim sürecine tabi olmalı.

Sonuç Temporal Table, veri geçmişi tutmanın en az maliyetli ve en güvenilir yöntemi. Değişiklik yönetim altyapısının veri katmanına eklenmesi gereken güçlü bir araç. Detaylı bilgi için: sqlchangeguard.com

"Sadece bir baktım."

Nasıl Başlıyor?

Senaryo her zaman aynı.

Bir şikayet geliyor. Müşteri, iş birimi ya da monitoring sistemi. Bir şeyler yanlış. DBA ya da geliştirici sorunu anlamak için production'a bağlanıyor.

"Sadece bir bakacağım."

Baktı. Sorunu buldu. Küçük bir şey. İki satır. Hızlıca düzeltilebilir. Test ortamına geçip değişikliği yapmak, onay almak, deployment süreci başlatmak zaman alacak.

"Zaten küçük bir şey, risk yok."

Düzeltti. Kapattı.

Sonrası

Çoğu zaman gerçekten bir şey olmaz. Bu yüzden alışkanlık pekişir.

"Geçen sefer de yaptım, sorun çıkmadı."

Ve her sorunsuz geçen seferle güven artar. "Ben bunu yapabilirim" duygusu yerleşir. Dikkat azalır. Adımlar daha hızlı atılır.

Ta ki bir gün bir şey ters gidene kadar.

Küçük Şeylerin Büyük Sonuçları

Şunu anlatayım.

Bir e-ticaret şirketinde kıdemli bir DBA. Deneyimli, güvenilir. Production'a defalarca "sadece bakıp düzeltmiş," hiç sorun yaşanmamış.

Bir gün sipariş tablosunda küçük bir index sorunu gördü. "Bunu hemen düzelteyim" dedi. Index'i düşürdü, yeniden oluşturdu.

Tam o sırada bir kampanya maili gönderilmişti. Binlerce kullanıcı aynı anda siteye girdi. Index yeniden oluşturulurken tablo kilitlendi. Sipariş sistemi dondu. 23 dakika.

23 dakikada ne kadar satış kaybedilir bir kampanya döneminde? Rakamı siz hesaplayın.

DBA hatalı mıydı? Evet. Ama asıl sorun sistemin bu hatayı mümkün kılmasıydı. Hiçbir kontrol mekanizması yoktu.

"Sadece Baktım"ın Anatomisi

Bu cümle aslında bir dizi karar zinciri.

İlk karar: "Test ortamına geçmeyeceğim." İkinci karar: "Onay almayacağım." Üçüncü karar: "Kayıt tutmayacağım." Dördüncü karar: "Rollback planı yazmayacağım." Beşinci karar: "Doğrulama yapmayacağım."

Her biri ayrı bir risk. Hepsi birden alındığında risk katlanıyor.

Ve bunların tamamı "sadece bir baktım" cümlesi altında saklanıyor.

Neden Durduramıyoruz?

Çünkü çoğu zaman gerçekten sorun çıkmıyor.

Bu, sigara içip uzun yaşayan biri gibi. "Gördünüz mü, zararı yok." Ama istatistik farklı konuşuyor. Ve zararlı alışkanlıklar uzun vadede faturayı mutlaka çıkarıyor.

Veritabanında da aynı. Her "sadece baktım" anı küçük bir risk. Yüzlerce küçük risk birikince büyük bir kriz kaçınılmaz hale geliyor.

Sistemi Suçlamak mı, İnsanı mı?

İkisini de değil aslında.

İnsan doğası kısa yolu seçer. Bu değiştirilemez. Değiştirilebilecek olan sistemin bu kısa yolu daha zor, doğru yolu daha kolay kılmasıdır.

Eğer test ortamına geçmek zahmetli, onay almak saatler alıyor ve doğrudan production'a bağlanmak tek tıkla oluyorsa insanlar production'u seçer.

Tersini yapın. Doğru yolu kolaylaştırın. Yanlış yolu görünür kılın.

Görünür Kılmak Ne Demek?

Birisi production'a bağlandı ve bir değişiklik yaptı. Sistem bunu tespit etti ve ilgili kişilere bildirdi.

Bu tek mekanizma bile davranışı değiştirir.

"Biri ne zaman bakıyorsa görüyor" bilgisi insanların karar sürecini etkiler. Bu güvensizlik değil. Karayollarındaki kameralar da sürücülere güvensizliği ifade etmez. Hız limiti ihlalini görünür kılar.

Görünürlük davranışı düzenler.

Peki Ya Acil Durumlar?

"Ya gerçekten acil bir şey varsa, onay bekleyemem?"

Bu itiraz meşru. Gerçekten acil durumlar var.

Ama şunu sorun: şu an yaşanan her "sadece bir bakayım" anı gerçekten acil mi? Yoksa "acil gibi hissedilen" mi?

İkisi çok farklı. Gerçek acil sayısı düşündüğünüzden çok daha az. Geri kalan her şey sabırla doğru süreçten geçirilebilir.

Bu Yazıyı Okurken Ne Düşündünüz?

Belki "evet, ben de yapıyorum" dediniz.

Belki "bizim ekipte de var böyle yapanlar" dediniz.

Belki "aslında ben de biliyorum bu yanlış, ama..." dediniz.

O "ama"nın arkası önemli değil. Önemli olan şu: biliyorsunuz. Ve bilmek, değiştirebilmek demek.

Yarın bir şikayet geldiğinde, production'a "sadece bir bakmak" için el uzattığınızda, o an durabilirsiniz.

Onay alabilirsiniz. Kayıt tutabilirsiniz. Doğru yolu izleyebilirsiniz.

Fark yaratmak için büyük bir sistem değişikliğine gerek yok. Bir kişinin bir kararı yeter.

SQL Server değişiklik yönetimi hakkında daha fazla bilgi için sqlchangeguard.com

Kampanya Döneminin Yarattığı Baskı

Yeni bir özellik eklenmesi gerekiyor. Kampanya fiyatları için yeni bir alan. İndirim kuralları için yeni bir tablo. Stok yönetiminde bir güncelleme.

Baskı altında bu değişiklikler hızla production'a atılmak isteniyor. "Kampanya başlamadan yetiştirelim."

Bu baskı doğal ama tehlikeli. Bir e-ticaret platformunda saatlik işlem hacmi kampanya döneminde normalin 10-20 katına çıkabilir. Yanlış bir değişiklik normalden çok daha büyük hasara yol açar.

Kampanya Dönemine Özgü Riskler

Yüksek trafik altında test edilmemiş kod

Test ortamında 100 kullanıcıyla test edilen değişiklik, production'da 10.000 eş zamanlı kullanıcıyla farklı davranabilir. Kilit çakışmaları, deadlock'lar, beklenmedik yavaşlamalar.

Rollback penceresi daralıyor

Normal zamanda bir rollback birkaç saat kesinti demek. Kampanya döneminde aynı süre milyonlarca liralık işlem kaybı.

Ekip yorgunluğu

Kampanya dönemlerinde ekipler zaten yoğun. Yorgun ekip daha fazla hata yapar, daha az dikkatli gözden geçirir.

Kampanya Öncesi Değişiklik Dondurma

En iyi e-ticaret ekipleri kampanya başlamadan belirli bir süre önce "code freeze" ilan eder. Bu süre zarfında kritik sistemlere hiçbir değişiklik yapılmaz.

Veritabanı için de aynı prensibi uygulayın. Kampanyadan bir hafta önce production veritabanına değişiklik penceresi kapanır. Sadece kritik güvenlik yamaları istisna.

Bu kararı değişiklik yönetim politikasına yazın. Sözlü mutabakat değil, yazılı kural.

Kampanya Sonrası Birikim

Code freeze döneminde biriken değişiklikler kampanya sonrasında toplu gelir. Bu toplu deployment da kendi riskini taşır.

Bu riski azaltmak için kampanya öncesinde yapılacak değişiklikleri olabildiğince tamamlayın. Kalanlar önceliklendirilmiş ve hazır olsun, kampanya biter bitmez sıralı ve kontrollü bir şekilde production'a alınsın.

Kampanya İzleme

Kampanya döneminde değişiklik yapmak yasak ama izleme tam tersine artmalı.

Sorgu performansı, deadlock sayısı, hata oranları, response time — bunların tamamı daha sık kontrol edilmeli. Bir anomali oluştuğunda hızlı müdahale için ekip hazır olmalı.

Sonuç

E-ticaret sektöründe değişiklik yönetimi kampanya takvimi ile entegre çalışmalı. Code freeze, hazırlık ve izleme bu entegrasyonun üç temel bileşeni.

Detaylı bilgi için: sqlchangeguard.com

Neden Şema Karşılaştırması Gerekli? Zaman içinde ortamlar kayar. Test'te olan production'da yok. Ya da tam tersi, production'da olan test'te yok. Bu kayma iki kaynaktan gelir: ya değişiklik yönetimi eksik ve bazı değişiklikler sadece bir ortama yapılmış, ya da biri doğrudan production'a müdahale etmiş. Her iki durumda da karşılaştırma farkı ortaya çıkarır.

Basit Şema Karşılaştırma Sorgusu Linked Server varsa iki ortamı doğrudan karşılaştırabilirsiniz. sql-- Production'da olup test'te olmayan tablolar SELECT t.name AS TabloAdi, 'Production''da var, Test''te yok' AS Durum FROM Production_DB.sys.tables t WHERE t.name NOT IN ( SELECT name FROM Test_DB.sys.tables )

UNION ALL

-- Test'te olup production'da olmayan tablolar SELECT t.name, 'Test''te var, Production''da yok' FROM Test_DB.sys.tables t WHERE t.name NOT IN ( SELECT name FROM Production_DB.sys.tables ); sql-- Kolon farklılıklarını tespit et SELECT 'Production' AS Ortam, t.name AS TabloAdi, c.name AS KolonAdi, tp.name AS VeriTipi, c.max_length AS MaxUzunluk, c.is_nullable AS NullIzin FROM Production_DB.sys.tables t JOIN Production_DB.sys.columns c ON t.object_id = c.object_id JOIN Production_DB.sys.types tp ON c.user_type_id = tp.user_type_id

EXCEPT

SELECT 'Production', t.name, c.name, tp.name, c.max_length, c.is_nullable FROM Test_DB.sys.tables t JOIN Test_DB.sys.columns c ON t.object_id = c.object_id JOIN Test_DB.sys.types tp ON c.user_type_id = tp.user_type_id;

Stored Procedure Karşılaştırması sql-- Stored procedure metinlerini karşılaştır SELECT p.name AS ProcedureAdi, CASE WHEN m_prod.definition != m_test.definition THEN 'Farklı' WHEN m_test.definition IS NULL THEN 'Test''te yok' ELSE 'Aynı' END AS Durum FROM Production_DB.sys.procedures p JOIN Production_DB.sys.sql_modules m_prod ON p.object_id = m_prod.object_id LEFT JOIN Test_DB.sys.procedures p_test ON p.name = p_test.name LEFT JOIN Test_DB.sys.sql_modules m_test ON p_test.object_id = m_test.object_id WHERE m_prod.definition != ISNULL(m_test.definition, '') OR m_test.definition IS NULL ORDER BY p.name;

Karşılaştırmayı Otomatikleştirmek Bu sorguları haftalık çalışan bir SQL Agent Job'ına dönüştürün. Fark tespit edildiğinde e-posta bildirimi göndersin. Bu sayede ortamlar arası kayma sürekli izlenir. Fark oluştuğu anda haberdar olunur.

Fark Bulunduğunda Ne Yapılmalı? Her fark hemen sorun değil. Planlı bir deployment yapılmış ve henüz diğer ortama geçmemiş olabilir. Ama farkın kaynağı bilinmiyorsa araştırılmalı. Kayıt dışı bir değişiklik mi? Eksik kalan bir deployment adımı mı? Bu araştırma değişiklik yönetim sürecinin parçası olmalı.

Sonuç Şema karşılaştırması hem ortam kalitesini korur hem de yetkisiz değişiklikleri tespit eder. Düzenli yapıldığında değişiklik yönetiminin en güçlü desteklerinden biri haline gelir. Detaylı bilgi için: sqlchangeguard.com

Ya da süreci hiç yok.

Bu yapıda merkezi bir değişiklik yönetimi nasıl kurulur?

Sorunun Boyutu

Her şirketin kendi IT ekibi var. Belki bazılarında DBA bile yok, geliştirici tüm veritabanı işlerini yapıyor. Standartlar şirketten şirkete farklı.

Holding düzeyinde bir denetim geldiğinde hangi şirkette ne olduğunu anlamak neredeyse imkansız.

Merkezi mi, Federe mi?

İki yaklaşım var.

Merkezi yaklaşım: Tüm değişiklikler tek bir platform üzerinden yönetilir. Her şirket aynı süreci kullanır, kayıtlar merkezi bir noktada toplanır.

Avantaj: tam görünürlük, tutarlı audit trail, kolay raporlama. Dezavantaj: her şirketin kendi ritmi bozulabilir, uyum direnci olabilir.

Federe yaklaşım: Her şirket kendi sürecini yönetir ama aynı standartları kullanır. Merkez standartları belirler, denetler.

Avantaj: esneklik, yerel sahiplenme. Dezavantaj: tutarsızlık riski, merkezi görünürlük eksik.

Holding yapıları için genellikle hibrit model daha gerçekçi: kritik şirketler için merkezi, küçük şirketler için federe.

Standart Minimum Gereksinimler

Hangi model seçilirse seçilsin holding genelinde minimum standartlar tanımlanmalı.

Her değişiklik için: talep kaydı, onay belgesi, deployment kaydı. Her ay için: prosedür dışı değişiklik raporu. Her yıl için: erişim listesi gözden geçirmesi.

Bu minimum standartlar hem denetim hazırlığı sağlar hem de şirketler arası tutarlılığı garanti eder.

Görünürlük Panosu

Holding yönetimi için konsolide bir görünürlük önemli. Hangi şirkette ne kadar değişiklik yapıldı, kaçı onaylıydı, prosedür dışı değişiklik var mıydı?

Bu pano aylık yönetim raporlamasının bir parçası haline getirildiğinde değişiklik yönetimi holding düzeyinde bir yönetişim aracına dönüşür.

Rollout Stratejisi

Tüm şirketlere aynı anda merkezi sistem kurmak gerçekçi değil. Kademeli rollout daha sürdürülebilir.

Önce en kritik ve en büyük şirket. Süreç oturdu, başarı hikayesi oluştu. Sonra diğer şirketler bunu gördükçe direnç azalır ve benimseme hızlanır.

Sonuç

Holding yapılarında değişiklik yönetimi hem teknik hem organizasyonel bir zorluk. Doğru model seçimi ve kademeli rollout bu zorluğu aşılabilir kılar.

Detaylı bilgi için: sqlchangeguard.com

Query Store Nedir? Query Store, SQL Server 2016 ile gelen ve sorgu planlarını ile performans istatistiklerini otomatik olarak kaydeden bir özellik. Önceki versiyonlar dahil her şey kaydediliyor: hangi sorgu hangi planla çalıştı, ne kadar sürdü, kaç kez çalıştı. Zaman içindeki değişim görünür. sql-- Query Store'u etkinleştir ALTER DATABASE VeritabaniAdi SET QUERY_STORE = ON WITH ( OPERATION_MODE = READ_WRITE, CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 90), DATA_FLUSH_INTERVAL_SECONDS = 900, MAX_STORAGE_SIZE_MB = 1000 );

Deployment Sonrası Performans Karşılaştırması Query Store'un en güçlü kullanım alanlarından biri deployment öncesi ve sonrası karşılaştırma. sql-- Deployment sonrası performansı gerileyen sorgular SELECT TOP 20 q.query_id, qt.query_sql_text, rs_before.avg_duration / 1000.0 AS OncekiSure_ms, rs_after.avg_duration / 1000.0 AS SonrakiSure_ms, (rs_after.avg_duration - rs_before.avg_duration) / 1000.0 AS FarkMs, rs_after.avg_duration * 100.0 / NULLIF(rs_before.avg_duration, 0) - 100 AS YuzdeDegisim FROM sys.query_store_query q JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id JOIN sys.query_store_plan p_before ON q.query_id = p_before.query_id JOIN sys.query_store_runtime_stats rs_before ON p_before.plan_id = rs_before.plan_id JOIN sys.query_store_plan p_after ON q.query_id = p_after.query_id JOIN sys.query_store_runtime_stats rs_after ON p_after.plan_id = rs_after.plan_id JOIN sys.query_store_runtime_stats_interval i_before ON rs_before.runtime_stats_interval_id = i_before.runtime_stats_interval_id JOIN sys.query_store_runtime_stats_interval i_after ON rs_after.runtime_stats_interval_id = i_after.runtime_stats_interval_id WHERE i_before.start_time < '2024-03-15 18:00' -- deployment öncesi AND i_after.start_time > '2024-03-15 18:00' -- deployment sonrası AND rs_after.avg_duration > rs_before.avg_duration * 1.2 -- %20 yavaşlama ORDER BY YuzdeDegisim DESC;

Plan Forcing ile Geçici Çözüm Deployment sonrası bir sorgu yavaşladı ve rollback yapılamıyor. Query Store plan forcing ile önceki iyi planı zorla uygulayabilirsiniz. sql-- Önceki iyi planı zorla uygula EXEC sys.sp_query_store_force_plan @query_id = 42, @plan_id = 15; Bu kalıcı çözüm değil. Asıl sorun (neden plan değişti) araştırılmalı ve düzeltilmeli. Ama acil durumda zaman kazandırır.

Query Store ve Değişiklik Yönetimi Entegrasyonu Her deployment öncesinde kritik sorguların performans istatistikleri kaydedilmeli. Deployment sonrasında karşılaştırma yapılmalı. Önemli bir regresyon varsa doğrulama adımı geçilmemeli. Bu adım değişiklik yönetim sürecinin doğrulama fazına eklenmeli: teknik doğrulama değil, performans doğrulaması.

Sonuç Query Store değişiklik yönetiminin görünmez bir katmanını görünür kılar: performans. Deployment öncesi ve sonrası karşılaştırma, regresyonu erken yakalamak için en güçlü araçlardan biri. Detaylı bilgi için: sqlchangeguard.com