Ola SQL server üzerinde DBA’lerin veri tabanlarını daha rahat yönetmesini sağlar, bunları nasıl yapar aslında Ola Hallengren bir SQL server da oluşturulmuş Script’tir. Bu Script’e şu şekilde ulaşabilirsiniz.
https://ola.hallengren.com/ sitesine girip MaintenanceSolution.sql dosyasını indirmeniz gerekmektedir. Bu dosyayı Not Defterinde açıp script’ine ulaşabilirsiniz.
Bu script’i çalıştırdığınız zaman SQL Server Backup, DatabaseIntegrityCheck,IndexOptimize bakımlarını kontrol edebileceğimiz bir sistem kütüphanesi oluşturmaktadır. Bu konulara daha detaylı giriş yapacağız.
DatabaseBackup : SQL Server Yedekleme
DatabaseIntegrityCheck: SQL Server Bütünlük Kontrolü
IndexOptimize: SQL Server İndex ve İstatistik Bakımı
Ola Hallengren script’ini çalıştırdıktan sonra bağzı Joblarımız’ da oluşacaktır.
İlk olarak System ‘de oluşturduğumuz parametreler Store Prodcedures’lerin içinde görebiliriz.
Tabiki bunların hepsini öğrenmemize gerek yok bizim için önemli olanların kullanımını ve ne işe yaradıklarını bakalım. Gerek oldukça bu parametreleri bilmemiz bizim işlerimizi rahatlatacaktır.
Öncelikle DatabaseBackup job’ı inceliyeceğiz ve nasıl kullanılacağınıza bakalım. Job’ incelemeden önce Backup Parametrelerini öncelikle bilmemiz gerekmektedir.
@Databases Bu parametremiz Backup’ı alınacak Veri tabanlarımızın yazıldığı alandır.
| SYSTEM_DATABASES | Tüm sistem veritabanları (ana, msdb ve model) |
| USER_DATABASES | Tüm kullanıcı veritabanları |
| ALL_DATABASES | Tüm veritabanları |
| AVAILABILITY_GROUP_DATABASES | Kullanılabilirlik gruplarındaki tüm veritabanları |
| USER_DATABASES, -AVAILABILITY_GROUP_DATABASES | Kullanılabilirlik gruplarında olmayan tüm kullanıcı veritabanları |
| Db1 | Db1 veritabanı |
| Db1, Db2 | Db1 ve Db2 veritabanları |
| KULLANICI_DATABASES, -Db1 | Db1 hariç tüm kullanıcı veritabanları |
| %Db% | Adında “Db” olan tüm veritabanları |
| %Db%, -Db1 | Db1 hariç adında “Db” olan tüm veritabanları |
| ALL_DATABASES, -%Db% | Adında “Db” olmayan tüm veritabanları |
@Directory Adındanda anlaşılacağı üzere backup’ın alınacağı yerimizi seçiyoruz. Ayrıca
Burada büyük databaselerimizin yedeklerini alırken parçalara bölebiliriz bu işlem aslında \\Sunucu1\Yedekleme, \\Sunucu2\Yedekleme
Bu aslında hem backup boyutumuzun büyük olmasından dolayı disk boyutlarımızı yüksek tutmamak bize avantaj sağlayacaktır ve en güzel yanıda backup alma süresine etkisi fark edecektir.
| Değer | Tanım |
| NULL | SQL Server varsayılan yedekleme dizinine yedekleyin. Bu varsayılandır. |
| C:\Yedekleme | C:\Backup dizinine yedekleyin. |
| C:\Yedek, D:\Yedek | C:\Backup ve D:\Backup dizinlerine yedekleyin. |
| \\Sunucu1\Yedekleme | \\Sunucu1\Yedekleme ağ paylaşımına yedekleyin. |
| \\Sunucu1\Yedekleme, \\Sunucu2\Yedekleme | \\Sunucu1\Yedekleme ve \\Sunucu2\Yedekleme ağ paylaşımlarına yedekleyin. |
| HİÇ | NUL’a yedekleyin. |
@Execute Parametremiz ayarlamaları yapıldıktan sonra işlemi kontrol etmemizi sağlar sağlıklı çalışıp çalışmayacağını bize gösterir. Şu şekilde anlatmak isterim FULL backup alacağımız zaman bu parametre ile önce script doğru olup olmadığını ayrıca allocated edeceği alanın yeterli olup olmadığını gösterir.
| Değer | Tanım |
| Y | Yedeklemeyi doğrulayın. |
| N | Yedeklemeyi doğrulamayın. Bu varsayılandır. |
Burada kontrol edilmek istenir ise ‘N’ Seçeneği ile kontrol yapılması gerekir ‘Y‘ yaparsak direk script çalışmaya başlar.
@BackupType Yedekleme türünü belirtin: FULL, Differential, or Transaction log.
| Değer | Tanım |
| FULL | Full backup |
| DIFF | Differential backup |
| LOG | Transaction log backup |
@Verify Yedeklemeyi doğrulayın.
| Değer | Tanım |
| Y | Yedeklemeyi doğrulayın. |
| N | Yedeklemeyi doğrulamayın. Bu varsayılandır. |
@CleanupTime Yedekleme dosyalarının silineceği süreyi saat cinsinden belirtin. Zaman belirtilmezse, hiçbir yedekleme dosyası silinmez.
@CleanupMode Eski yedekleme dosyalarının yedekleme gerçekleştirilmeden önce mi yoksa sonra mı silineceğini belirtin.
| Değer | Tanım |
| BEFORE_BACKUP | Yedekleme gerçekleştirilmeden önce eski yedekleme dosyalarını silin. |
| AFTER_BACKUP | Yedekleme ve doğrulama işlemi gerçekleştirildikten sonra eski yedekleme dosyalarını silin. Yedekleme veya doğrulama başarısız olursa, hiçbir yedekleme dosyası silinmez. Bu varsayılandır. |
@Compress Yedeklemeyi sıkıştırın. Herhangi bir değer belirtilmezse, sys.configurations’daki yedek sıkıştırma varsayılanı kullanılır.
| Değer | Tanım |
| NULL | Sys.configurations’da yedek sıkıştırma varsayılanını kullanın. Bu varsayılandır. |
| Y | Yedeklemeyi sıkıştırın. |
| N | Yedeklemeyi sıkıştırmayın. |
@CopyOnly Salt kopya yedekleme gerçekleştirin
| Değer | Tanım |
| Y | Salt kopya yedekleme gerçekleştirin. |
| N | Normal bir yedekleme gerçekleştirin. Bu varsayılandır. |
@ChangeBackupType Fark veya işlem günlüğü yedeği gerçekleştirilemiyorsa yedekleme türünü değiştirin. Kullanımını tavsiye etmiyorum backuplarımızı ayrı ayrı aldırdığımız için
| Değer | Tanım |
| Y | Yedekleme yapılamıyorsa yedekleme türünü değiştirin. |
| N | Yedekleme yapılamıyorsa yedeklemeyi atlayın. Bu varsayılandır. |
@Description Yedekleme için bir açıklama girin.
@Encrypt Yedeklemeyi şifreleyin.
| Değer | Tanım |
| Y | Yedeklemeyi şifreleyin. |
| N | Yedeklemeyi şifrelemeyin. Bu varsayılandır. |
@BackupSoftware Üçüncü taraf yedekleme yazılımını belirtin; aksi takdirde, SQL Server yerel yedeklemesi gerçekleştirilir. Yani Yazılımlar tarafından gerçekleşen şifreleme yöntemleridir.
| Değer | Tanım |
| NULL | SQL Server yerel yedeklemesi (varsayılan) |
| DATA_DOMAIN_BOOST | DELL EMC Veri Etki Alanı Yükseltme |
| LITES HIZI | SQL Server için LiteSpeed’i Arayın |
| SQLYEDEKLEME | Red Gate SQL Yedekleme Pro |
| SQLGÜVENLİ | Idera SQL Güvenli Yedekleme |
@EncryptionAlgorithm Şifreleme türünü belirtin.
| Value | Description |
| NULL | No encryption (the default) |
| RC2_40 | RC2 40-bit encryption (LiteSpeed) |
| RC2_56 | RC2 56-bit encryption (LiteSpeed) |
| RC2_112 | RC2 112-bit encryption (LiteSpeed) |
| RC2_128 | RC2 128-bit encryption (LiteSpeed) |
| TRIPLE_DES_3KEY | Triple DES encryption (SQL Server native encryption or LiteSpeed) |
| RC4_128 | RC4 128-bit encryption (LiteSpeed) |
| AES_128 | AES 128-bit encryption (SQL Server native encryption, LiteSpeed, Red Gate SQL Backup Pro, or Idera SQL Safe Backup) |
| AES_192 | AES 192-bit encryption (SQL Server native encryption or LiteSpeed) |
| AES_256 | AES 256-bit encryption (SQL Server native encryption, LiteSpeed, Red Gate SQL Backup Pro, or Idera SQL Safe Backup) |
@NoRecovery Günlüğün kuyruğunu yedekleyin ve veritabanını RESTORING durumunda bırakın. Kullanılmasını önermiyorum.
@URL DatabaseBackup’taki URL seçeneği, SQL Server BACKUP komutundaki URL seçeneğini kullanır.
@AvailabilityGroups Burası AlwaysOn mimarisinde Bulunan Sistemler için kullanılmaktadır.
| Değer | Tanım |
| ALL_AVAILABILITY_GROUPS | Tüm müsaitlik grupları |
| AG1 | Kullanılabilirlik grubu AG1 |
| AG1, AG2 | AG1 ve AG1 kullanılabilirlik grupları |
| ALL_AVAILABILITY_GROUPS, -AG1 | AG1 hariç tüm kullanılabilirlik grupları |
| %AG% | Adında “AG” bulunan tüm kullanılabilirlik grupları |
| %AG%, -AG1 | AG1 hariç, adında “AG” bulunan tüm kullanılabilirlik grupları |
| ALL_AVAILABILITY_GROUPS, -%AG% | Adında “AG” olmayan tüm kullanılabilirlik grupları |
Parametreleri öğrendikten sonra artık oluşan joblarımızı inceleyelim ve nasıl kullanabileceğimize hep beraber bakalım.
Öncelikle backup için oluşan joblarımızı inceleyeceğiz.
Oluşan backup joblarımızın içerik olarak aynı olduğunu söyleyebilirim. Bu yüzden tek bir Backup job’ı üzerinden sizlere anlatmaya çalışacağım. Bunun için şu sıralamayı izlemeniz gerekmektedir.
Backup jobımızın propertiesine girdiğimiz zaman bizim için önemli olan 2 alan var bunlar STEP ve Schedules
İlk olarak STEP kısmını inceliyelim.
Steps kısmına geldiğimiz zaman oluşturulan görevi göreceksiniz ve bu görevi inceleyelim.
Karşımıza bu şekilde bir script oluştuğunu göreceğiz ve bu script aslında jobda çalışmasını istediğimiz parametrelerdir. Bu parametreleri yukarıda işimize yarayacak olanları açıklamaya çalıştım.
Biz bu Parametrelerin ne işe yaradığını ve nasıl bir yapı oluşturmanız gerektiğini açıklayacağım. Sql Server’da backup jobı oluşturacağımız için CMD kısmını kaldırıp şu şekilde düzenli yapı oluşturuyoruz.
Bu yapıyı oluşturduktan sonra artık içerik kısmını inceleyelim ve bizim için ayarlamak istediğimiz backup programlamasını yapalım.
@Databases parametresini göreceğiz ve bu parametre hangi veri tabanının backup alınacaksa onu buraya oluşturmanız gerekmektedir.
@Directory parametremiz backup dosyasının tutulacağı yeri göstermektedir.
@BackupType parametremiz alınacak olan Backup türünü ifade etmektedir.
@Verify parametremiz ise alınan backup düzgün alınıp alınmadığını gözden geçirir. Verify ile alınan backuplar daha güvenilir diyebiliriz.
@CleanupTime parametremiz alınan backup dosyasının tutulacağı zaman miktarını gösterir.
@CleanupTime parametremiz alınan backup dosyasının tutulacağı zaman miktarını gösterir. Bu miktar saat olarak yazmanız gerekmektedir. Burası önemlidir, sebebine en son yapacağımız FULL, DİFF, TRAN backup joblarının birlikte nasıl kullanacağını ve herhangi bir kriz anında backup dosyalarınızın kaç gün geriye dönebileceğinizi bu parametremiz belirler diyebiliriz.
Burada bilmemiz gereken bir parametremizde bizim kendimizin ekleyeceği @CleanupMode parametremizdir. Burada BEFORE_BACKUP yada AFTER_BACKUP olacağını belirlemeniz gerekir önerim AFTER_BACKUP sebebi yeni Backup işlemi tamamlandıktan sonra silme işlemini gerçekleştirmesidir.
Step kısmında bulunan Parametrelerin ne işe yaradığını öğrendikten sonra jobımızda bulunan Schedules kısmına bakacağız.
Burada önemli olan Steps kısmında BackupType Parametremiz‘de belirttiğimiz FULL, DİFF, TRAN backup türüne göre alınacağı zamanı belirleyebiliriz. Burada Günlük haftalık ve Aylık seçeneklerini görmekteyiz.
Duration kısmında ise Başlama tarihi ve bitiş tarihi seçebiliriz. Bitiş tarihi oluşturmak önermiyorum.
ŞİMDİ yapılması gereken FULL—-DİFF—TRAN backupların joblarının birbiri ile nasıl düzenli çalışacağını bir uygulama yaparak görelim.
Öncelikle backup türlerinin arasındaki bağlantıları bilmeniz gerekmekte geri dönüş işlemlerinde bunları bilmezseniz aldığınız backuplarınız bir manası kalmaz çünkü backuplar birbiri ile ilişkili olmak zorundadır bu konuya çok fazla detaylı girmeyeceğim. Backup türlerimize kısaca değineceğim.
FULL: Tam Yedek manasına gelir full backubımız olmadan geri dönüş işlemi olmaz. Kısaca FULL backup olmadan RESTORE işlemi gerçekleştiremezsiniz. FULL backup olmadan DİFF ve TRAN backuplarınızla herhangi bir geri dönüş yapamazsınız.
DİFF: FULL backup dan sonra değişen işlem günlüklerinin son halini tutar. DİFF backup FULL olmadan bir işe yaramaz DİFF backup bizim için geri dönüşlerin hızlı olması ve RESTORE işleminde FULL backup üzerine işlem yapılır.
TRAN: TRAN backup zincir yapısına sahiptir bu yapı aslında şu manaya gelir TRAN backuplar sırası ile RESTORE işlemine girer FULL backupdan sonra TRAN Backuplar ile istenilen saat dakikaya dönüş yapmanın tek yoludur.
Şimdi bizim içim önemli olan FULL, DİFF ve TRAN backuplarımızın birbiri ile nasıl çalışacağıdır. Benim çalıştığım şirkette backuplarımı şu şekilde tutmaktayım.
NOT: Backuplarım 15 GÜNLÜKTÜR. Bu şu manaya gelir herhangi bir sıkıntı halinde en fazla 15 gün geriye dönüş yapabilirim ve bu 15 günlük geri dönüşte istenilen saat ve dakikaya dönüş yapabilirim manasına gelmektedir.
FULL JOB STEP
EXECUTE [dbo].[DatabaseBackup] @Databases = 'Databasesname', @Directory = N ‘//İp Adresi/databasesname_FULL_Klasor’, @BackupType = 'FULL', @Verify = 'Y', @CleanupTime = 336, @CleanupMode=’AFTER_BACKUP’, @Compress= 'Y', @CheckSum = 'Y', @LogToTable = 'Y'
FULL backup jobımızı haftada 2 gün alıp toplamda 15 günlük süreçte elimizde 4 adet olacaktır.
DİFF JOBS STEP
EXECUTE [dbo].[DatabaseBackup]@Databases = 'Databasesname', @Directory = N ‘//İp Adresi/databasesname_DİFF_Klasor’, @BackupType = 'DİFF', @Verify = 'Y', @CleanupTime = 336, @CleanupMode=’AFTER_BACKUP’, @Compress= 'Y', @CheckSum = 'Y', @LogToTable = 'Y'
DİFF backuplarımız haftada 4 gün alınması ve 15 günlük planlamada elimizde 8 adet bulunacaktır.
TRAN( LOG ) JOB STEP
EXECUTE [dbo].[DatabaseBackup] @Databases = 'Databasesname', @Directory = N ‘//İp Adresi/databasesname_LOG_Klasor’, @BackupType = 'LOG', @Verify = 'Y', @CleanupTime = 336, @CleanupMode=’AFTER_BACKUP’, @Compress= 'Y', @CheckSum = 'Y', @LogToTable = 'Y'
TRAN backuplarımız 20 dakikada bir kaydedilip 15 gün boyunca tutulmaktadır.
Backup Joblarımızı bu şekilde ayarladığımız zaman NOT bölümündede söylediğim gibi 15 günlük geri dönüş sağlayabiliriz.
Unutmayalım tutulan adet alınan disk boyutlarını belirlemenizi sağlar Joblarımızın çalışıp çalışmadığını Job’a sağ tıklayıp Wiew History kısmından kontrol edebilirsiniz.
0 Yorum