Online İşlemler
    /uploads/MSSQL_2_K_0efb19642d.png/uploads/MSSQL_Desktop_c69b9fd503.png/uploads/MSSQL_c3c8e83099.png

    MSSQL Veri Kurtarma: Silinen, Bozulan ve Erişilemeyen Veritabanlarınızı Geri Kazanın

    MSSQL, kurumsal ortamlarda büyük miktarda veriyi depolayan bir veritabanı yönetim sistemidir. Veri kaybı donanım arızası, insan hatası veya fidye yazılımı gibi nedenlerle oluşabilir. MSSQL’de veri kurtarma, yedekleme ve geri yükleme, işlem günlüklerinin gönderimi gibi yöntemlerle yapılabilir. DrDisk Lab, MSSQL veri kurtarma alanında uzman bir ekiple çalışarak, veri kaybı durumlarında özelleştirilmiş çözümler sunar ve iş sürekliliğinizi güvence altına alır.

    Microsoft SQL Server (MSSQL), büyük miktarda veriyi depolayan ve yöneten, yaygın olarak kullanılan bir ilişkisel veritabanı yönetim sistemidir. MSSQL genellikle kurumsal ortamlarda kullanılır ve veri kaybı veya bozulmasının ticari operasyonlar üzerinde önemli bir etkisi olabilir. MSSQL’de veri kurtarma, donanım arızası, insan hatası veya fidye yazılımı gibi kötü amaçlı yazılım saldırıları nedeniyle kaybolan veya bozulan verilerin geri yüklenmesini içerir.

    Yedekleme ve geri yükleme: Bu, MSSQL’deki en yaygın veri kurtarma yöntemidir. Yerleşik SQL Server Management Studio aracı veya üçüncü taraf bir yedekleme yazılımı kullanılarak yapılabilen önceki bir yedeklemeden verilerin geri yüklenmesini içerir. Veri kaybı insan hatasından veya küçük bir donanım arızasından kaynaklanıyorsa bu yöntem etkilidir.

    Günlük Gönderimi: Günlük gönderimi, MSSQL’deki başka bir veri kurtarma yöntemidir, işlem günlüklerinin birincil veritabanından ikincil bir veritabanına kopyalanmasını içerir ve ikincil veritabanının olağanüstü durum kurtarma için kullanılmasına izin verir. Bu yöntem, birincil veritabanı arızası durumunda verileri kurtarmanın bir yolunu sağlar ve aynı zamanda verileri belirli bir zamana kurtarmanın bir yolunu da sağlayabilir.

    Bir MSSQL veritabanından veri kurtarmanın karmaşık bir süreç olabileceğini ve bu alanda uzmanlık gerektirdiğini unutmamak önemlidir. DrDisk Lab, MSSQL veri kurtarma teknikleri konusunda bilgili uzmanlardan oluşan bir ekibe sahiptir ve kuruluşunuzun özel ihtiyaçlarını karşılamak için özelleştirilmiş çözümler sağlayabilirler.

    Hizmetler
    Hizmetler
    Database

    Msg 8939, Level 16, State 98 Hatası

    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.

    Database

    Microsoft SQL Server, Error: 945 Hatası

    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.

    Database

    Yaygın Sql Komut Hataları

    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.

    Database

    Veritabanı Yönetim Sistemlerinde SQL Sorgularının Önemi

    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.

    Database

    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