# SQL Server'da Değişiklik Yönetimi: Baştan Sona Eksiksiz Rehber

Bir veritabanı yöneticisi olarak kariyerinizde mutlaka şu anı yaşamışsınızdır: sabah işe geldiniz, bir şeyler yanlış. Bir sorgu beklenmedik sonuçlar döndürüyor, bir servis hata veriyor ya da bir tablo bambaşka bir görünüm almış. Ekibe soruyorsunuz. Herkes birbirine bakıyor. "Ben dokunmadım" deniyor.

O an, değişiklik yönetiminin neden var olduğunu en net biçimde anlıyorsunuz.

Bu rehber, SQL Server ortamlarında değişiklik yönetimini sıfırdan kurmak isteyenler için yazıldı. Kavramsal çerçeveden teknik araçlara, süreç tasarımından denetim gereksinimlerine kadar her şeyi ele alıyoruz.

* * *

## Değişiklik Yönetimi Nedir ve Neden Gereklidir?

Değişiklik yönetimi, bir IT sisteminde yapılacak her türlü değişikliğin kontrollü, onaylı ve izlenebilir biçimde gerçekleştirilmesini sağlayan süreçler bütünüdür.

Veritabanı özelinde konuşursak: bir tablo oluşturulması, bir stored procedure'ün güncellenmesi, bir index'in kaldırılması, bir kullanıcıya yetki verilmesi — bunların tamamı birer değişiklik. Ve bu değişikliklerin her biri, kontrol edilmediğinde risk taşır.

Değişiklik yönetiminin olmadığı ortamlarda şu soruların yanıtı yoktur:

*   Bu değişikliği kim yaptı?
    
*   Ne zaman yapıldı?
    
*   Neden yapıldı, kim onayladı?
    
*   Değişiklikten önce durum nasıldı?
    
*   Bir sorun çıkarsa nasıl geri alınır?
    

Bu sorular yanıtsız kaldığında operasyonel risk artar, denetim geçmek güçleşir ve ekip içi güven sarsılır.

* * *

## Değişiklik Türleri: Ne İzlenmeli?

SQL Server'da izlenmesi gereken değişiklikler üç ana kategoriye ayrılır.

### DDL Değişiklikleri

Veri Tanımlama Dili işlemleri. Veritabanının yapısını etkiler.

*   CREATE: Yeni nesne oluşturma (tablo, view, stored procedure, index...)
    
*   ALTER: Mevcut nesneyi değiştirme
    
*   DROP: Nesne silme
    
*   TRUNCATE: Tablo içeriğini toplu silme
    

DDL değişiklikleri genellikle en kritik olanlar. Bir tabloya kolon eklenmesi zararsız görünebilir ama bağımlı uygulamaları, raporları ya da diğer nesneleri etkileyebilir.

### DML Değişiklikleri

Veri İşleme Dili işlemleri. Tablolardaki veriyi etkiler.

*   INSERT: Yeni kayıt ekleme
    
*   UPDATE: Mevcut kaydı güncelleme
    
*   DELETE: Kayıt silme
    

DML değişikliklerinin tamamını loglamak her ortam için pratik değil. Ancak kritik tablolarda — müşteri bilgileri, finansal kayıtlar, yetki tabloları — DML izleme önemli.

### DCL Değişiklikleri

Veri Kontrol Dili işlemleri. Yetkileri etkiler.

*   GRANT: Yetki verme
    
*   REVOKE: Yetki alma
    
*   DENY: Yetki engelleme
    

Yetki değişiklikleri güvenlik açısından kritik. Bir kullanıcıya yanlışlıkla ya da kasıtlı olarak fazla yetki verilmesi ciddi riskler doğurabilir.

* * *

## SQL Server'ın Yerleşik İzleme Mekanizmaları

SQL Server değişiklikleri izlemek için birkaç farklı mekanizma sunar. Her birinin güçlü ve zayıf yönleri var.

### DDL Trigger

En hızlı kurulabilen yöntem. Veritabanı ya da sunucu düzeyinde DDL olaylarını yakalar ve tanımladığınız işlemleri çalıştırır.

sql

```sql
CREATE TRIGGER trg_DDL_Log
ON DATABASE
FOR DDL_DATABASE_LEVEL_EVENTS
AS
BEGIN
    INSERT INTO DDL_Log (
        EventType,
        ObjectName,
        ObjectType,
        LoginName,
        HostName,
        ApplicationName,
        EventDate,
        EventData
    )
    SELECT
        EVENTDATA().value('(/EVENT_INSTANCE/EventType)[1]', 'NVARCHAR(100)'),
        EVENTDATA().value('(/EVENT_INSTANCE/ObjectName)[1]', 'NVARCHAR(100)'),
        EVENTDATA().value('(/EVENT_INSTANCE/ObjectType)[1]', 'NVARCHAR(100)'),
        SYSTEM_USER,
        HOST_NAME(),
        APP_NAME(),
        GETDATE(),
        EVENTDATA()
END
```

**Avantaj:** Basit, hızlı, ücretsiz.

**Dezavantaj:** Sysadmin tarafından devre dışı bırakılabilir. Bildirim mekanizması yok. Onay süreci entegre edilemez.

### SQL Server Audit

Daha kurumsal bir yaklaşım. Server Audit ve Database Audit Specification tanımlanarak belirli olaylar dosyaya veya Windows Event Log'una yazılır.

sql

```sql
-- Server Audit oluştur
CREATE SERVER AUDIT DatabaseAudit
TO FILE (FILEPATH = 'C:\AuditLogs\')
WITH (ON_FAILURE = CONTINUE);

ALTER SERVER AUDIT DatabaseAudit WITH (STATE = ON);

-- Database Audit Specification oluştur
CREATE DATABASE AUDIT SPECIFICATION DatabaseChanges
FOR SERVER AUDIT DatabaseAudit
ADD (DATABASE_OBJECT_CHANGE_GROUP),
ADD (SCHEMA_OBJECT_CHANGE_GROUP),
ADD (DATABASE_PERMISSION_CHANGE_GROUP)
WITH (STATE = ON);
```

**Avantaj:** Kapsamlı, manipüle edilmesi daha zor, compliance için daha uygun.

**Dezavantaj:** Logları analiz etmek emek ister. Bildirim yok. Onay süreci yok.

### Change Data Capture (CDC)

Tablo bazında satır değişikliklerini transaction log'dan okuyarak yakalar. DDL değil, DML izleme için kullanılır.

sql

```sql
-- CDC'yi veritabanında etkinleştir
EXEC sys.sp_cdc_enable_db;

-- Belirli tablo için CDC'yi etkinleştir
EXEC sys.sp_cdc_enable_table
    @source_schema = 'dbo',
    @source_name = 'KritikTablo',
    @role_name = NULL,
    @supports_net_changes = 1;
```

**Avantaj:** Performans etkisi düşük, eski ve yeni değerleri saklar.

**Dezavantaj:** Şema değişikliklerini izlemez. Yönetim gerektiren arka plan job'ları.

### Extended Events

SQL Server'ın en güçlü izleme altyapısı. Yüzlerce farklı olayı filtreleyerek yakalayabilirsiniz.

**Avantaj:** Düşük overhead, çok zengin veri.

**Dezavantaj:** Kurulumu ve analizi karmaşık. Bildirim yok. Onay süreci entegre edilemez.

* * *

## Yerleşik Araçların Ortak Sorunu

Bu dört mekanizmanın hepsi reaktif çalışır. Değişiklik önce olur, sonra kaydedilir.

Kurumsal değişiklik yönetiminde ihtiyaç duyulan şey farklı:

1.  Değişiklik olmadan önce onay süreci
    
2.  Değişiklik sırasında otomatik risk analizi
    
3.  Değişiklik sonrası tam kayıt
    
4.  Süreç dışı değişiklikte anında bildirim
    

Bu döngünün tamamını native araçlarla kurmak mümkün ama ciddi geliştirme ve bakım yükü gerektirir.

* * *

## İdeal Değişiklik Yönetimi Süreci

Kurumsal bir ortamda değişiklik yönetimi süreci şu adımlardan oluşmalıdır.

### 1\. Talep

Her değişiklik bir talep ile başlar. Kim istiyor, hangi veritabanı, hangi nesne, ne değiştirilecek, neden?

Bu adım kritik çünkü "neden" sorusu değişikliğin gerekliliğini sorgulatır. Aceleyle yapılmak istenen, gerekçelendirilemeyen değişiklikler bu aşamada süzülür.

### 2\. Otomatik Analiz

Değişiklik scripti sisteme yüklendiğinde otomatik analiz başlamalıdır:

*   WHERE şartsız UPDATE veya DELETE var mı?
    
*   DROP TABLE içeriyor mu?
    
*   Büyük tablolarda index operasyonu mu?
    
*   Yetki değişikliği içeriyor mu?
    
*   Kritik nesnelere dokunuyor mu?
    

Bu analizin sonucunda bir risk skoru üretilmeli. Düşük riskli değişiklikler hızlı onaya giderken yüksek riskli değişiklikler daha dikkatli incelenmeli.

### 3\. Sandbox Test

Production ortamına geçmeden önce değişiklik test ortamında çalıştırılmalı. Eğer test ortamı yoksa BEGIN-ROLLBACK bloğu içinde önizleme yapılabilir:

sql

```sql
BEGIN TRANSACTION

-- Değişiklik scripti buraya
ALTER TABLE Siparisler ADD TeslimTarihi DATE NULL;

-- Etkilenen satır sayısı kontrol et
SELECT @@ROWCOUNT AS EtkilenenSatir;

-- Production'a geçmeden önce geri al
ROLLBACK TRANSACTION
```

### 4\. Onay Akışı

Risk seviyesine göre farklı onay seviyeleri tanımlanmalı.

Düşük risk: DBA onayı yeterli. Orta risk: DBA + IT yöneticisi onayı. Yüksek risk: DBA + IT yöneticisi + ilgili birim müdürü onayı.

Her onay adımı kayıt altına alınmalı: kim onayladı, saat kaçta, hangi notla.

### 5\. Deployment

Onay tamamlandıktan sonra deployment yapılır. Bu adımda şunlar kayıt altına alınmalı:

*   Deployment zamanı
    
*   Kim çalıştırdı
    
*   Hangi script, hangi versiyon
    
*   Deployment süresi
    
*   Sonuç: başarılı mı, hata mı?
    

### 6\. Rollback Planı

Her deployment için rollback script'i önceden hazır olmalı. "Gerekirse bakarız" yeterli değil. Kriz anında sakin kalmak zordur, o an için yazılmış bir rollback planı hayat kurtarır.

### 7\. Doğrulama

Deployment sonrası sistem beklenen şekilde çalışıyor mu? Kritik sorgular test edilmeli, servisler kontrol edilmeli. Bu adım da kayıt altına alınmalı.

* * *

## Yetkisiz Değişiklik Tespiti

Sürecin en kritik ama en çok atlanan parçası bu.

Yukarıdaki adımların tamamını kusursuz kurmuş olsanız bile birisi SSMS'i açıp doğrudan değişiklik yapabilir. Sysadmin yetkisine sahip biri için hiçbir uygulama katmanı bariyer oluşturamaz. Bu SQL Server'ın mimarisi gereği böyle.

Ama tespit etmek mümkün.

Sistem dışından yapılan değişiklikleri tespit etmek için iki yöntem kullanılabilir:

**Periyodik snapshot karşılaştırması:** Veritabanı şemasının düzenli anlık görüntüleri alınır ve önceki versiyonla karşılaştırılır. Fark varsa alarm üretilir.

**Real-time izleme:** DDL Trigger veya Extended Events ile yapılan değişiklikler anında izlenir. Sistem dışından geldiği tespit edilen değişiklikler için bildirim gönderilir.

Her iki yöntemin de kurulumu için geliştirme gerekir. Ama sonuç kritik: biri gece 02:00'de SSMS'ten bir şey yapmış olsa bile sabah siz haberdar olursunuz.

* * *

## Denetim Gereksinimleri

Türkiye'deki kurumlar için değişiklik yönetimi artık yasal bir gereksinim haline geldi.

### KVKK

KVKK, kişisel verilerin işlendiği sistemlerde teknik güvenlik tedbirlerinin alınmasını zorunlu kılıyor. Erişim logları, değişiklik kayıtları ve bu kayıtların düzenli denetimi açıkça bekleniyor.

Bir veri ihlali yaşandığında Kişisel Verileri Koruma Kurulu'na yapılan bildirimde "hangi sistem değişikliği bu ihlale yol açtı" sorusunu yanıtlayabilmek gerekiyor.

### BDDK

Bankacılık sektöründe BDDK'nın bilgi sistemleri yönetmeliği, değişiklik yönetimi süreçlerini açıkça düzenliyor. Onay akışları, test süreçleri ve deployment kayıtları belgelenmek zorunda.

### ISO 27001

A.12.1.2 maddesi doğrudan değişiklik yönetimini kapsıyor. Bilgi işleme olanaklarını etkileyen değişiklikler kontrol altında olmalı. Denetimde bu kontrolü kanıtlayan belgeler sunulmalı.

### COBIT ve ITIL

Her iki çerçeve de değişiklik yönetimini temel bir IT süreç alanı olarak tanımlıyor. COBIT'in BAI06 alanı ve ITIL'in Change Management süreci bu konuyu detaylıca ele alıyor.

* * *

## Küçük Ekipler İçin Pratik Başlangıç

Büyük kurumsal süreçler küçük ekipler için ağır gelebilir. Ama başlamak için mükemmel olmak zorunda değilsiniz.

Şu üç şeyi yaparak başlayabilirsiniz:

**Birinci adım:** Her değişiklik için bir kayıt oluşturun. Basit bir tablo yeterli: değişiklik tarihi, kimin yaptığı, ne değiştirildiği, neden. Bu bile çoğu kurumun şu anki durumundan çok daha iyidir.

**İkinci adım:** DDL Trigger kurun. Yukarıdaki örnek kodu kullanın. En azından değişikliklerin otomatik kaydedilmesini sağlayın.

**Üçüncü adım:** Rollback rutini oluşturun. Her deployment öncesi "bunu nasıl geri alırım" sorusunu sorun ve cevabı yazın.

Bu üç adım 1-2 hafta içinde hayata geçirilebilir ve başlangıç için yeterli bir temel oluşturur.

* * *

## Olgun Bir Değişiklik Yönetimi Sürecinin Göstergeleri

Sürecinizin ne kadar olgun olduğunu değerlendirmek için şu sorulara bakın:

Herhangi bir değişikliğin kim tarafından, ne zaman, hangi gerekçeyle yapıldığını 5 dakika içinde bulabiliyor musunuz? Evet ise temel seviyedesiniz.

Deployment öncesi otomatik risk analizi yapılıyor mu? Evet ise orta seviyedesiniz.

Sistem dışından yapılan değişiklikler anında tespit ediliyor ve bildiriliyor mu? Evet ise ileri seviyedesiniz.

Tüm bu süreç KVKK/BDDK/ISO 27001 gereksinimlerini karşılayacak biçimde belgeleniyor ve raporlanıyor mu? Evet ise kurumsal olgunluk seviyesindesiniz.

* * *

## Araç mı, Manuel Süreç mi?

Bu soruyu "ikisi de gerekli ama farklı amaçlarla" diye yanıtlamak en doğrusu.

Manuel süreç politikayı ve kültürü belirler. Hangi değişiklikler nasıl onaylanacak, kimler yetkili, prosedür dışı davranışın sonuçları ne olacak. Bunlar araçla değil, kurumsal kararla şekillenir.

Araç ise bu politikanın tutarlı biçimde uygulanmasını sağlar. İnsan hatası ve unutkanlığını minimize eder. Onay e-posta yerine sistem üzerinden alınır, deployment manuel değil kayıt altında çalışır, yetkisiz değişiklik manuel arama yerine otomatik tespit edilir.

Birlikte çalıştıklarında hem disiplin hem de verimlilik sağlanır.

* * *

## Sonuç

SQL Server'da değişiklik yönetimi bir lüks değil. Ekibiniz büyüdükçe, müşteri tabanınız genişledikçe ve regülasyon baskısı arttıkça bu süreç kaçınılmaz hale gelir.

Başlamak için büyük bir bütçeye ya da mükemmel bir plana gerek yok. Önemli olan başlamak. Küçük adımlarla kurulan bir süreç, zamanla kurumun en değerli operasyonel altyapılarından biri haline gelir.

Kimin ne yaptığını her zaman biliyor olmak, bir DBA için en büyük güvence. Bu güvenceyi sistematik olarak inşa etmek ise değişiklik yönetiminin özü.

* * *

*SQL Server değişiklik yönetimi hakkında daha fazla bilgi için* [*sqlchangeguard.com*](http://sqlchangeguard.com) *adresini ziyaret edebilirsiniz.*