SQL Server'da Profesyonel Yedekleme Stratejileri

Günümüz dijital ekosisteminde, veriler bir organizasyonun en değerli varlığıdır. Her saniye milyonlarca veri noktası üretilirken, tek bir veri kaybı felaketi tüm bir organizasyonun operasyonlarını durdurabilir. SQL Server yedekleme stratejisi, sadece bir BT prosedürü değil, aynı zamanda iş sürekliliğinin temel bir güvencesidir.

Potansiyel veri kaybı senaryoları:

• Donanım arızaları
• Yazılım hataları
• İnsan kaynaklı hatalar
• Siber güvenlik tehditleri
• Doğal afetler
• Kötü niyetli saldırılar

1.1 Full (Tam) Backup

• Tanım: Veritabanının tamamının yedeğini alır
• Frekans: Genellikle günlük veya haftalık
• Boyut: En büyük yedekleme türü
• Kurtarma Maliyeti: Düşük
• Kullanım Senaryoları:
  • Kritik sistemler
  • Veri bütünlüğü önemli uygulamalar

1.2 Differential (Fark) Backup

• Tanım: Son full backup'tan sonraki değişikliklerin yedeği
• Frekans: Günlük veya 12 saatte bir
• Boyut: Full backup'a göre daha küçük
• Kurtarma Maliyeti: Orta
• Kullanım Senaryoları:
  • Orta ölçekli sistemler
  • Sık değişen veriler

1.3 Transaction Log Backup

• Tanım: Veritabanındaki işlem günlüklerinin yedeği
• Frekans: Saatlik veya dakikada bir
• Boyut: En küçük yedekleme türü
• Kurtarma Maliyeti: Yüksek hassasiyet
• Kullanım Senaryoları:
  • Finansal sistemler
  • Reel zamanlı veri güncellemeleri

-- Gelişmiş yedekleme politikası için dinamik yapılandırma
DECLARE @BackupStrategy TABLE (
    DatabaseName NVARCHAR(255),
    BackupType NVARCHAR(50),
    Frequency INT,
    RetentionDays INT,
    CompressionLevel INT
);

INSERT INTO @BackupStrategy 
(DatabaseName, BackupType, Frequency, RetentionDays, CompressionLevel)
VALUES 
('MainDatabase', 'FULL', 1, 30, 5),
('TransactionDB', 'TRANSACTION_LOG', 4, 7, 7),
('ArchiveDatabase', 'DIFFERENTIAL', 2, 14, 3);

• Minimum yetki prensibi
• Dinamik rol atamaları
• Sürekli yetki izleme

-- Gelişmiş backup kullanıcısı oluşturma
CREATE LOGIN BackupManagerAdvanced 
WITH PASSWORD = 'Komp13xG&venlikP@rolu2024!',
CHECK_POLICY = ON,
CHECK_EXPIRATION = ON;

-- Rol ataması
ALTER SERVER ROLE [dbcreator] ADD MEMBER [BackupManagerAdvanced];
ALTER SERVER ROLE [sysadmin] ADD MEMBER [BackupManagerAdvanced];

• Compression Level
• Parallel Backup
• Buffer Management
• I/O Optimization

-- Yedekleme performans izleme
CREATE VIEW BackupPerformanceMetrics AS
SELECT 
    database_name,
    backup_start_date,
    backup_finish_date,
    DATEDIFF(SECOND, backup_start_date, backup_finish_date) AS backup_duration_seconds,
    backup_size_bytes / 1024 / 1024 AS backup_size_mb
FROM msdb.dbo.backupset;

• Minimum veri kaybı
• Hızlı kurtarma
• Kesintisiz operasyon

• Hızlı sistemsel geri dönüş
• Minimum kesinti süresi
• Yedek sistemler

• GDPR
• KVKK
• Sektörel düzenlemeler

-- Yasal uyumluluk için otomatik arşivleme
CREATE PROCEDURE AutoArchiveOldBackups
AS
BEGIN
    DECLARE @RetentionPeriod INT = 365;
    
    DELETE FROM msdb.dbo.backupset
    WHERE backup_finish_date < DATEADD(DAY, -@RetentionPeriod, GETDATE());
END

• Lokal sunucular
• Uzak veri merkezleri
• Bulut depolama (Azure, AWS)

-- Azure Blob Storage'a yedekleme
BACKUP DATABASE [MainDatabase]
TO URL = 'https://mystorageaccount.blob.core.windows.net/backups/MainDatabase.bak'
WITH COMPRESSION, STATS = 10;

• Anlık durum raporları
• Performans metrikler
• Otomatik uyarılar

CREATE PROCEDURE GenerateBackupHealthReport
AS
BEGIN
    SELECT 
        database_name,
        MAX(backup_finish_date) AS last_backup_time,
        COUNT(*) AS total_backups,
        SUM(backup_size) / 1024 / 1024 / 1024 AS total_backup_size_gb
    FROM msdb.dbo.backupset
    GROUP BY database_name;
END

Başarılı bir yedekleme stratejisi, statik bir yapı değil, sürekli adapte olan dinamik bir sistemdir. Teknolojinin hızla değiştiği günümüzde, yedekleme yaklaşımlarınızı da sürekli güncellemek ve optimize etmek kritik önem taşımaktadır.

• Düzenli test ve simülasyonlar
• Sürekli teknoloji takibi
• Esnek ve ölçeklenebilir mimari
• Güvenlik odaklı yaklaşım

Veritabanları, günümüzde bilgi depolamanın temel yapı taşlarından biri haline geldi. Büyük veri hacimlerini düzenli bir şekilde yönetmek ve gerektiğinde hızlı erişim sağlamak, işletmelerin etkinliği için kritik önem taşıyor. Veri tabanlarını yönetmek için kullanılan SQL (Structured Query Language – Yapılandırılmış Sorgu Dili), veri işleme ve yönetme süreçlerinde temel bir role sahip.

SQL sorguları, veritabanları üzerinde çeşitli işlemleri gerçekleştirmek için kullanılır. Veri ekleme, veri güncelleme, veri silme ve veri sorgulama gibi temel veritabanı işlemleri, SQL’in fonksiyonel yapısı sayesinde gerçekleştirilir. Özellikle büyük ölçekli sistemlerde, veri tabanlarını etkin bir şekilde yönetebilmek için optimize edilmiş SQL sorguları kullanmak büyük önem taşır.

SQL sorgularının doğru ve etkin bir şekilde yazılması, performansın yanı sıra veri bütünlüğünü de sağlar. İyi tasarlanmış bir sorgu, veri tabanının hızlı çalışmasını ve gereksiz yere kaynak tüketimini önler. Aynı zamanda, veri tabanı yöneticilerinin ve veri analistlerinin veriye daha kolay ve verimli bir şekilde erişmesini sağlar.

SQL sorguları, farklı veritabanı sistemlerinde de kullanılabilir. Bu da yazılımcıların ve veri uzmanlarının farklı platformlarda aynı dil yapısını kullanarak çalışmasına imkan tanır. Bu da veri yönetimi süreçlerinde esneklik ve standartlaştırma sağlar.

SQL Server’daki sistem tablolarından bazı bilgileri çekmeye yönelik bir içerik hazırladık. Bu SQL sorgusu, SQL Server’daki sistem tablolarından bazı bilgileri çekmeyi hedeflemek amacıyla yazılmıştır. SQL Server’daki kullanıcı tablolarının adını, kayıt sayısını, fiziksel boyutunu, oluşturulma ve son güncelleme tarihlerini ve bu tabloların indeks sayısını gösterecek örnek çalışma yapacağız. Öncelikle kodumuzun tamamını yazıp daha sonra adım adım neler yaptığını açıklayacağız

Kodumuz:

SELECT
t.name AS TABLO_ADI,
SUM(p.rows) AS KAYIT_SAYISI,
SUM(a.total_pages) * 8 AS FIZIKSEL_BOYUT_KB,
t.create_date AS OLUSTURULMA_TARIHI,
t.modify_date AS SON_GUNCELLEME_TARIHI,
COUNT(i.index_id) AS INDEKS_SAYISI

FROM
sys.tables t
INNER JOIN
sys.partitions p ON t.object_id = p.object_id
INNER JOIN
sys.allocation_units a ON p.partition_id = a.container_id
LEFT JOIN
sys.indexes i ON t.object_id = i.object_id
WHERE
t.type_desc = ‘USER_TABLE’
GROUP BY
t.name, t.create_date, t.modify_date
ORDER BY
KAYIT_SAYISI DESC;

Kodu adım adım inceleyelim:

_ SELECT:_ Sorgu sonucunda hangi sütunların gösterileceğini belirtir.

• t.name AS TABLO_ADI: sys.tables tablo isimlerini TABLO_ADI olarak adlandırır.

• SUM(p.rows) AS KAYIT_SAYISI: sys.partitions her bir tablodaki toplam kayıt sayısını KAYIT_SAYISI olarak adlandırır.

• SUM(a.total_pages) * 8 AS FIZIKSEL_BOYUT_KB: Fiziksel boyutu kilobyte cinsinden hesaplar ve FIZIKSEL_BOYUT_KB olarak adlandırır.

• t.create_date AS OLUSTURULMA_TARIHI: Her bir tablonun oluşturulma tarihini OLUSTURULMA_TARIHI olarak adlandırır

• t.modify_date AS SON_GUNCELLEME_TARIHI: Her bir tablonun son güncellenme tarihini SON_GUNCELLEME_TARIHI olarak adlandırır.

• COUNT(i.index_id) AS INDEKS_SAYISI: Tablolardaki indeks sayısını _INDEKS_SAYISI _olarak adlandırır.

FROM: Hangi tabloların kullanılacağını belirtir.

• sys.tables t: Tablo bilgilerini içeren sys.tables içeriğinit olarak adlandırır.

• INNER JOIN sys.partitions p ON t.object_id = p.object_id: sys.tables ve sys.partitions arasında object_id ile birleştirme yapar.

• _INNER JOIN sys.allocation_units a ON p.partition_id = a.container_id: sys.partitions _ve sys.allocation_units arasında partition_id ile birleştirme yapar.

• LEFT JOIN sys.indexes i ON t.object_id = i.object_id: sys.tables ve sys.indexes arasında object_id ile birleştirme yapar.

WHERE: Hangi koşulların geçerli olacağını belirtir.

• t.type_desc = 'USER_TABLE': Sadece USER_TABLE tipindeki tabloları filtreler.

GROUP BY: Hangi sütunların gruplanacağını belirtir.

-t.name, t.create_date, t.modify_date: TABLO_ADI, OLUSTURULMA_TARIHI ve SON_GUNCELLEME_TARIHI‘ne göre gruplar.

ORDER BY: Sonuçların nasıl sıralanacağını belirtir.

• KAYIT_SAYISI DESC: KAYIT_SAYISI‘na göre azalan sırada sıralama yapar.

Bu analizde, veritabanları ve SQL sorgularının önemine dair temel bilgileri inceledik. Veritabanları, günümüzde bilgi depolamanın temel yapı taşlarından biri olup, büyük veri hacimlerini etkili bir şekilde yönetmek ve hızlı erişim sağlamak işletmeler için kritik bir unsurdur. İyi tasarlanmış SQL sorguları, performansın yanı sıra veri bütünlüğünü de sağlayarak veritabanlarının etkin bir şekilde çalışmasını sağlar.

SQL Server’daki sistem tablolarından bilgi çekmeye yönelik örnek bir SQL sorgusu üzerinden adım adım bir analiz gerçekleştirdik. Bu analiz, SQL sorgularının nasıl yapılandırıldığını ve hangi verileri çektiğini anlamak açısından faydalı bir örnek sundu.

Veritabanları ve SQL sorguları, günümüz teknolojisinin vazgeçilmez bir parçası olarak iş dünyasında önemli bir rol oynamaya devam ediyor. Bu temel bilgiler, veri yönetimi ve bilgi depolama konularında çalışan profesyonellerin etkili ve verimli çözümler üretmelerine katkı sağlar.

SQL hataları, veritabanı işlemleri sırasında ortaya çıkabilen sorunlardır. Bu hatalar genellikle veritabanı sorgularının, tabloların veya ilişkilerin yanlış kullanımından kaynaklanır. İşte sık karşılaşılan SQL hataları ve olası sebepleri:

Syntax Error (Syntax Hatası):

• Sebep: SQL sorgusu yazım hatası içeriyor olabilir.
• Çözüm: Sorguyu dikkatlice kontrol edin ve doğru syntax kullanımına uygun olduğundan emin olun.

SELECT * FROM Users WHERE Name = John; -- Hatalı
SELECT * FROM Users WHERE Name = 'John'; -- Doğru

Table Not Found (Tablo Bulunamadı):

• Sebep: Belirtilen tablo adı mevcut değil veya yanlış yazılmış olabilir.
• Çözüm: Tablo adını kontrol edin ve varsa doğru şekilde yazdığınızdan emin olun.

SELECT * FROM UserTable; -- Hatalı
SELECT * FROM UsersTable; -- Doğru

Column Not Found (Sütun Bulunamadı):

• Sebep: Sorguda kullanılan sütun adı yanlış yazılmış olabilir.
• Çözüm: Kullanılan sütun adını kontrol edin ve varsa doğru şekilde yazdığınızdan emin olun.

SELECT Name, Email, Age FROM Users WHERE Ad = 'John'; -- Hatalı
SELECT Name, Email, Age FROM Users WHERE Name = 'John'; -- Doğru

Duplicate Entry (Çift Kayıt Hatası):

• Sebep: Bir PRIMARY KEY veya UNIQUE kısıtlamasına sahip bir sütuna aynı değeri eklemeye çalışmak.
• Çözüm: Ekleme işleminden önce varolan kayıtları kontrol edin veya benzersiz değerler kullanın.

INSERT INTO Users (ID, Name) VALUES (1, 'John');
INSERT INTO Users (ID, Name) VALUES (1, 'Jane'); -- Hatalı

Foreign Key Constraint Violation (Foreign Key Kısıtlama İhlali):

• Sebep: İlgili FOREIGN KEY’ler arasında uyumsuzluk.
• Çözüm: Bağlantılı tablolardaki verileri kontrol edin veya uygun değerleri kullanarak veri ekleyin.

CREATE TABLE Orders (
OrderID INT PRIMARY KEY,
ProductID INT,
FOREIGN KEY (ProductID) REFERENCES Products(ProductID)
);INSERT INTO Orders (OrderID, ProductID) VALUES (1, 100); — Hatalı

Bu örnekler, SQL sorguları sırasında karşılaşılabilecek yaygın hatalardan sadece birkaçını içermektedir. Her durumda, hata mesajlarını dikkatlice okuyarak ve sorguları inceleyerek sorunları tespit etmek önemlidir. Ayrıca, veritabanı yönetim sistemine (DBMS) özgü hata mesajlarına dikkat etmek de faydalı olacaktır.

SQL Server 2005’te karşılaştığınız “Microsoft SQL Server, Error: 945” hatası, veritabanının dosyalarının diskte yeterli boş alan olmadığından kaynaklandığını gösterir. Bu durumda, aşağıdaki adımları deneyebilirsiniz:

• Veritabanınızı Kontrol Etme: SQL Server Management Studio (SSMS) üzerinden veritabanınızı kontrol edin. Veritabanı hala “Recovery Pending” durumundaysa, bu durumu çözmek için aşağıdaki adımları takip edebilirsiniz:

SSMS’de sağ tıklayarak “Tasks” ve ardından “Bring Online” seçeneğini kullanın.

• Veritabanınızı Detaylı Kontrol Etme: SSMS üzerinden veritabanına sağ tıklayarak “Properties” seçeneğine gidin. Buradan “Files” sekmesine geçin ve dosyaların yolunu kontrol edin. Veritabanı dosyaları farklı bir diskte bulunuyor ve bu diskte hala yeterli boş alan olmayabilir.
• DBCC CHECKDB Komutunu Kullanma: SSMS’de bir yeni sorgu açın ve aşağıdaki sorguyu çalıştırarak veritabanınızı kontrol edin:

DBCC CHECKDB('TESTDB') WITH ALL_ERRORMSGS;

Bu sorgu, veritabanındaki bütünlük sorunlarını kontrol edecektir.

• Olay Günlüklerini Kontrol Etme: SQL Server’ın olay günlüklerini kontrol edin. Bu günlüklerde daha fazla hata ayrıntısı olabilir. SSMS’de “Management” altında “SQL Server Logs” bölümünden olay günlüklerine ulaşabilirsiniz.
• Geçici Dosyaları Kontrol Etme: SQL Server’ın geçici dosyalarının bulunduğu diskte yeterli boş alan olduğundan emin olun. SQL Server, geçici dosyalarını oluşturmak için geçici bir alana ihtiyaç duyar.
• SQL Server Servisini Yeniden Başlatma: Yeterli boş alan olduğundan emin olduktan sonra SQL Server servisini yeniden başlatmayı deneyin.

Eğer yukarıdaki adımlar sorunu çözmezse, daha fazla ayrıntı için olay günlüklerini kontrol etmeye devam edin ve gerekirse SQL Server topluluğu veya destek kaynaklarından yardım almak faydalı olacaktır.

Msg 8939, Level 16, State 98 Hatası

Bu hatanın, SQL Server veritabanında bir tablo hatası olduğunu göstermektedir. Hatanın düzeltilmesi için aşağıdaki adımları takip edebilirsiniz:

DBCC CHECKDB ile Detaylı Kontrol: DBCC CHECKDB komutunu kullanarak veritabanınızı detaylı bir şekilde kontrol edebilirsiniz. Bu komut, veritabanındaki bütünlük sorunlarını belirleyebilir ve bazı durumlarda otomatik olarak düzeltebilir.

DBCC CHECKDB(‘TESTDB’) WITH ALL_ERRORMSGS, NO_INFOMSGS

Bu komut sonucunda başka hatalar tespit edilirse, öncelikle bu hataları düzeltmeniz gerekebilir.

Onarım İşlemi: Hata belirli bir sayfa (page) üzerinde olduğu için, bu sayfanın onarılması gerekebilir. Ancak, önceki adımda tespit edilen diğer hataların düzeltilmesi gerekebilir.

USE [master];
GO

-- Veritabanını tek kullanıcı moduna al
ALTER DATABASE TESTDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

-- Veritabanını kontrol et ve onar
DBCC CHECKDB('TESTDB', REPAIR_ALLOW_DATA_LOSS);

-- Veritabanını çok kullanıcılı moduna geri al
ALTER DATABASE TESTDB SET MULTI_USER;

*Not: REPAIR_ALLOW_DATA_LOSS kullanımı, veritabanındaki bazı veri kayıplarına neden olabilir. Bu nedenle, bu adımı atlamadan önce dikkatlice değerlendirmeniz önemlidir.

Backup ve Restore: Veritabanınızın en son yedeklemesini bulabiliyorsanız, bir geri yükleme işlemi düşünebilirsiniz. Ancak, bu durumda veritabanındaki güncel veriler kaybolabilir.

Profesyonel Yardım Alın: Eğer yukarıdaki adımlar sonuç vermezse veya bu işlemleri yapmak konusunda emin değilseniz, bir uzmandan yardım almanız önemlidir. Özellikle onarım işlemleri sırasında dikkatli olunmalı ve gerekirse uzmanlardan yardım alınmalıdır.

Önemli: Onarım işlemleri, veri kaybına neden olabilir, bu nedenle işlemleri gerçekleştirmeden önce mutlaka veritabanınızın yedeğini almalısınız.