SQL Server Ola Hallengren Nedir? Nasıl Kullanılır?

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’ […]

SQL Server Ola Hallengren Nedir? Nasıl Kullanılır?

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.

Benzer Yazılar

WINDOWS CLUSTER VE SQL ALWAYS ON İLİŞKİSİ

SQL Server 2 hafta önce

Bu yazımızda sql always always on yapısında önemli bir yere sahip olan Windows cluster ile always on arasındaki ilişkiyi ele alacağız. Öncelikle şunu bilmeliyiz. SQL Always On mimarisi Windows cluster üzerinde koşar. Basit bir örnekle anlatacak olursak; 2 katlı bir ev düşünün. 1. katı WindowS Failover Cluster 2. katı sql Always On. 1.katı inşa etmeden 2. katı çıkamazsınız değil mi? O sebeple önce WSCF sonra SQL Always on kurulur. Pekii… Birinci ve ikinci katı çıktık. 1. kat(WSFC) yıkılırsa 2. katta(ALWAYS ON) doğal olarak çöker değil mi. Ancak ikinci kat yıkılırsa 1. Kat çökmez. Yani; Windows cluster devre dışı kalırsa always on’da devre dışı kalacaktır, ancak always on düşerse Windows Cluster devre dışı kalmaz. Başımıza always on haberleşmesi üzerine bir sıkıntı gelirse; Önce 2. Katta yani always on üzerinde bir sorun var mı ona bakacağız. Always on taraflı bir problem olmadığından emin olduktan sonra 1. Kata yani Windows failover cluster tarafını […]

SQL Server ‘da Detach-Attach İşlemleri Nasıl Yapılır?

SQL Server 3 hafta önce

SQL Server’ da  Detach – Attach İşlemleri. Merhaba, bu yazımda SQL Serverda veri tabanımızı farklı sunuculara taşımamız gerektiğinde ya da farklı sunuculardaki veri tabanlarını listemize almak istediğimizde nasıl bir yol izlememiz gerektiğini anlatacağım.İçindekilerDETACH İşlemiATTACH İşlemi Öncelikle bir veri tabanını taşımanın birden fazla yolu var. Bunlar: Detach-Attach, Restore, Backup yöntemleridir. Neden Veri Tabanını Taşırız? Sunucularımızda kaynak yetersizliğimiz olabilir. Sürüm yükseltmemiz gerekebilir. Domain değişikliği olabilir. İlk olarak “Uygulama” isimli bir veri tabanı oluşturalım. İşlemlerimizi bu veri tabanı üzerinden yürüteceğiz. CREATE DATABASE Uygulama Sorgumuz ile veri tabanımızın nerede tutulduğunu bulalım. USE Uygulama GO EXEC sp_helpfile DETACH İşlemi Detach İşlemi, ilgili veri tabanımızı listeden çıkarmak yani taşımak istediğimizde Detach bize yardımcı oluyor. Soldaki veri tabanı listemizden Uygulama isimli veri tabanımızın üzerine gelip sağ tık >Tasks >Detach yolunu izleyeceğiz.   Karşımıza gelen panelde Message alanında “Active Connections” yazıyor. Yani bir aktif bağlantı olduğunu söylüyor. Biz de DropConnections alanındaki tiki işaretleyeceğiz ki bu aktif bağlantıyı silsin. […]

SQL SERVER SERViS RESTART HATASI

SQL Server 3 ay önce

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

0 Yorum

Yorum Yaz

Rastgele