Sql Server 2012 Database Maintenance Planları

SQL Server 2012 önceki SQL Server sürümlerinde olduğu veri tabanı bütünlüğünü korumak ve devamlı sağlıklı çalışmayı desteklemek üzere bakım planlarını içerir. Bakım planları hakkında detaylı yapılandırma ve kavramsal bilgileri bulabileceğiniz bu makale aynı zamanda veri tabanı endeks bütünsellik denetimleri için örnek betimleri de içerir. Bu makalede sizlere SQL Server Maintenance Planları hakkında bilgi verip, örnekler ile anlatmaya çalışacağım. İlk önce Database Maintenance kavramı nedir buna bakalım. Maintenance Planı yerine makalenin geri kalan kısmında bakım planları/bakım planı kelimelerini kullanalım. Bakım planları ile sağlamaya çalıştığımız, SQL Serverın daha kararlı ve hatasız çalışmasıdır. Bakım planlarını yapılandırmadan önce neler yapmalıyız ilk önce bunlara bakacağız, sırasıyla iki önemli ön adım var:

  1. SQL Agent yapılandırması
  2. Database mail yapılandırılması

7-1-2014 16-15-55

Bakım Planlarının Temelleri

Bakım planlarına neden ihtiyaç duyulur:

  • Veri tabanının sürekliliğini ve performansını maksimum seviyede tutmak,
  • Bir felaket durumunda, yedekler sayesinde zararı minimum seviyeye indirgemek,
  • Tutarlılık denetimleri (Consistency Checks) ile veri tabanındaki problem ve bozulmaları kontrol ederek veri kaybını en az indirgemek,
  • İndeks Bakımı (Index Maintenance) ile indeksleri yeniden yapılandırmak ve organize etmek, fiziksel parçalanmayı (Fragmentation) indeks sayfa bütünlüğünü (density) iyileştirmek,
  • İstatistiklerin Güncellenmesi (Statistics Updates) ile eski veya bozuk istatistik verilerinin değişmesini önlemek,
  • Temizleme Görevleri (Cleanup Tasks) ile eski backup ve bakım görevi log dosyalarının silinmesi ve msdb’deki geçmiş tabloların temizlenmek,
  • Bakım plan sihirbazı ile bakım yapılandırmasının basitçe yapılması sağlar.
  • Tümleşik destek sunarak, plan oluşturma, düzenleme ve zamanlanmış görev işlemlerinin çok kolayca yapılmasını sağlar.

Kısıtlar Bakım planları ile ilgili aşağıdaki kısıtları göz önünde bulundurmakta fayda var;

  • Her bakım görevi, bakım operasyonlarının düzenli bir parçası değildir. Görevler birbirinden bağımsızdır.
  • Bakım görevlerindeki varsayılan genellikle gerekli olmayabilir. Örnek olarak, tüm veri tabanlarındaki indekslerin analiz edilmeden rebuild edilmesi, gereksiz bir işlem olacaktır.
  • Bakım planları her sunucu için ayrı ayrı düzenlenir. Birden çok sunucuya aktarma yapılamaz. Başka bir sunucuda kullanılamaz.

SSIS Paketleri

SQL Server Integration Server Services (SSIS) paketleri ile de bakım planları yapılandırmak mümkündür. Faydaları

  • Bakım görevlerini basit bir şekilde düzenler.
  • Paket yapılandırmaları birden çok sunucuda kullanılabilir. Tek bir pakete ait uzantılar ve ayar değişiklikleri, birden çok sunucuda kullanılabilir.

Kısıtları

  • Tüm bakım görevleri, bakım operasyonlarının bir parçası olmak zorunda değildir.
  • Bakım görevlerindeki varsayılan genellikle gerekli olmayabilir. Örnek olarak, tüm veri tabanlarındaki indekslerin analiz edilmeden rebuild edilmesi, gereksiz bir işlem olacaktır.
  • SQL Server Agent ile otomatik zamanlanmış görevler oluşturabilir.
  • Paketler Standart Management Studio ile yönetilmez. Paketlerde değişiklik yapmak için Business Intelligence Development Studio’ya ihtiyaç vardır.

Custom Transact Sql Scripts

Özel hazırlanmış Sql scriptleri ile de bakım planları oluşturulabilir. Faydaları

  • Bakım konfigürasyonlarındaki tüm ayarlar özelleştirilebilir.
  • Index fragmentation (parçalanma), page density ve veri değişmesindeki gereksiz işlemler en aza iner veya yok edilir.
  • İnternet ortamında ücretsiz scriptler bulunabilir.
  • Kod içeriği olduğundan, birden çok servera rahatça taşınabilir ve kullanılabilir.

Kısıtları

  • T-Sql dilini ve özelleştirilmiş ayarlar ile bakım planı yapmayı bilmek gerekir.
  • Zamanlanmış görev olarak yapılmak istenirse, Sql Server Agent üzerinde de manuel olarak yapılması gerekmektedir.

Power Shell Scripts

Power shell üzerinden de bakım planları yapmak mümkündür. Faydaları

  • T-Sql scripti destekler, aynı zamanda uzaktan serverlara bakım planlarının uygulanmasını ve yönetilmesini sağlar.

Kısıtları

  • Power shell scripti iyi bilmek gerekir.
  • Sql management nesnelerine ve TSql diline hakim olayı gerektirir.
  • Zamanlanmış görev olarak yapılandırılmak isteniyorsa, Sql server agentta ve Windows görev yöneticisinde manuel olarak yapılması gerekir.

 SQL Server Agent Ayarlarının Yapılandırılması

Bakım planlarının işleyişinde SQL Server Agent’a ihtiyacımız vardır. Şimdi Agent ayarlarının yapılandırılmasına bakalım.

  • SQL Server Agent, bir veya birden çok planı otomatik bir şekilde zamanlanmış görev olarak çalıştırır.
  • SQL Agent’ın, bir bakım planı çalıştığında veya hata verdiğinde uyarı üretilebilmesi için yapılandırılmalıdır.
  • SQL Server Express Edition’da SQL Server Agent özelliği bulunmaz.

SQL Agent ile ilgili konulara aşağıdaki gibi sırasıyla bakacağız.

  • Database Mail
  • SQL Agent Mail ayarları
  • SQL Agent geçmişi kayıtları tutma (History retention)
  • SQL Agent uyarıları (Alerts)

Database Mail Yapılandırılması

SQL Server içinden SMTP ile mail gönderilmesini sağlar. Varsayılan ayarlar içerisinde Database Mail aktif olarak gelmez. Etkinleştirilmesi için, Database Mail Configuration Wizard ile veya TSql Stored Procedure kullanılarak yapılandırılması gerekir. SQL Server Express Edition’da database mail özelliği mevcut olmasına rağmen sihirbaz ile kurulum mümkün değildir, bu sürümde sadece stored procedure’lar kullanılarak yapılandırma gerçekleştirilebilir.

Database Mail yapılandırma adımları şu şekildedir:

  • Database Mail özelliği aktif edilir.
  • Yeni mail profili tanımlanır.
  • Mail profile bir SMTP hesabı tanımlanır.
  • Profil güvenliği yapılandırılır.

Şimdi bu başlıkla ilgili kurulum aşamalarına geçelim, öncelikle Object Explorer’dan Database Maili bulun. Bu nesnenin üzerinde sağ tuşa basarak Configure Database Mail’e menü konutunu seçiyoruz.

Sql1

 

Sql2

 

Yeni bir database mail tanımlamak için ilk seçenekle devam edeceğiz. Varolan mail hesap ve profilleri yönetmek için; Manage Database Mail accounts and profiles profil güvenliğini yönetmek için; Manage profile Security, sistem parametrelerini görmek veya değiştimek içinse; View or change system parameters

Sql3

 

Daha önce hiç aktif edilmemiş ise burada bir uyarı çıkar, bu uyarıya Yes deyip geçiyoruz. Ben daha önce bir kere yapılandırdığımdan bende uyarı çıkmadı. New profile ekranına geldik, Profile Name ismini belirliyoruz ve Add butonuna basarak, SMTP hesabımızı tanımlayacağız.

Sql4

 

Account ismini ve description a açıklamaları giriyoruz. Outgoing Mail Server SMTP, mail sunucu ayarlarımızı giriyoruz. Ben burada kendi hesabımı girdim. SMTP sunucu ayarlarınız farklı kullanıcı ismi formatları ve port numaralı kullanmanızı gerektirebilir.

Sql5

 

Profil güvenliği ekranında, profil için public seçeneğini işaretliyorum ve Default Profile başlığı altında da “Yes”’i seçip “Next” ile ilerliyorum.

Sql6

 

Varsayılan ayarlar karşımıza geliyor, bu ayarları değiştirmeye ilk aşamada gerek yok, Next ile devam ediyoruz.

Sql7

 

Finish ile kurulumu tamamlıyoruz. Dikkat ederseniz, veri tabanı posta tanımında “script” butonu yok, burada yaptığımız işlemleri başka bir servera taşımamıza imkan vermiyor. Birden fazla SQL sunucunuz var ise, bu ayarları tek tek yapmak durumundasınız.

Sql8

 

Kurulum başarılı bir şekilde tamamlandı, herhangi bir uyarı veya hata vermedi.

Sql9

 

Şimdide tanımladığımız mail hesabına bir test maili gönderiyoruz. Database maile sağ tıklayıp, Send test E-mail diyoruz. To kısmına deneme mesajını almak istediğiniz adresi yazıp, Send Test E-Mail butonuna basıyoruz.

Sql10

 

SQL Server Agent Mail Ayarları

Database Mail tanımlarımızı yaptıktan sonra, sıra SQL Server Agent Mail ayarlarına geliyor. SQL Agent üzerinden mail gönderebilmemiz için, mail ayarlarının burada da yapılması gerekiyor. Uyarı ve diğer bilgilendirme posta işlemleri için bir veya birden fazla operatör tanımlayabiliriz. Her operatöre ait bir mail adresi tanımlanması gerekiyor.

SQL Server Agent operatörlere aşağıdaki durumlarda mail gönderebilir:

  • Bir job başarılı olduğunda
  • Bir job başarısızlıkla sonuçlandığında
  • Bir job tamamlandığında

Şimdi nasıl yapıldığına bakalım;

SQL Server Agent bölümünün altında, Operators sağ tıklayıp New Operator diyelim.

Sql11

 

Operatör ismini veriyoruz ve mail adresini yazıyoruz.

Operatöre hangi saatler mail atılmasını istiyorsak aşağıdaki gibi ayarlabiliriz. Haftanın hangi günü veya hangi saatler arası.

Cuma tüm gün mail gelmesini istiyorsak aşağıdaki saat ayarlarını yapmamız gerekiyor.

Birden fazla operatör tanımalamak istersek, sayfanın üst kısmındaki script yardımı ile tanımlayabiliriz.

Sql12

 

Alert System kısmında da tanımlarımızı aktifleştirmemiz gerekiyor. Bunun için Sql Server Agent’a sağ tıklayıp properties kısmından Alert System’a geliyoruz.

Enable Mail Profile kutusunu işaretliyoruz.

Mail system ve mail profile ımızı seçiyoruz.

Ardından fail Safe Operator kısmından tanımladığımız operatörü seçip, Email kutusunu işaretliyoruz.

Sql13

 

Değişikliklerin aktif olabilmesi için Sql Server Agent servisini yeniden başlatıyoruz.

Sql14

 

Sql Server Agent History Retention (Geçmiş Tutma) Ayarları

Sql Server Agent bir görevin ve görev adımlarının geçmiş kayıtlarına bakım yapabilir.

Varsayılan konfigürasyon limitleri, her tekil görev için minimum 100 satır, maksimum 1000 satırdır.

Bir veya birden fazla görev sık sık çalıştırıldığında, görev geçmiş bilgileri temizlenir. Örnek olarak; Transaction log backups veya replication agents.

Satırların maksimum sayısını arttırmak, sık sık Agent jobların geçmişlerini temizlede faydalı olur. Yanlız hatırlatmakta fayda var, bu işlem msdb veritabanının diskteki boyutunu arttırır.

Şimdi History Retention ayarlarına bakalım;

Sql Server Agent, Properties açıyoruz.

Sql15

 

History sekmesine geldiğimizde,

Job geçmiş loglarının satır sayısını “Limit size of job history log” seçeneğini aktif ederek arttırabiliyoruz, örnek olarak 10000 satır yaptım.

“Remove Agent history” seçeneğini seçersek, tarih bazında geçmişi temizleyecektir. Örnek olarak, 4 gün, 4 hafta, 4 ay dan eski geçmişi sil gibi.

Sql16

 

“Remove Agent history” seçeneğini seçersek, tarih bazında geçmişi temizleyecektir. Örnek olarak, 4 gün, 4 hafta, 4 ay dan eski geçmişi sil gibi.

Sql17

 

Bu komutun Scriptine baktığımızda, sp_purge_jobhistory Stored Procudure ünü kullanıdğını görüyoruz. Bir alttaki EXEC’te de, maksimum satırlar sayısını belirtiyor, limit vermeden ayarlamak istiyorsak -1 değerini atıyoruz.

Sql18

 

Retention History’i Job ile Ayarlama:

Retention history’i Job olarak nasıl ayarlayacağımızı göreceğiz şimdi de;

Sql Agent Server – Jobs – New Job diyoruz.

General sekmesinde,

Name: Job’umuza bir isim veriyoruz.

Owner: Bu kısımda “sa” veya sql den bir kullanıcı vermek daha mantıklı, domain accont verdiğimizde, ve bu account ilerki biz zamanda disable edildiğinde, bu job çalışmayacaktır.

Sql19

 

Steps sekmesine geçip, yeni bir adım ekliyoruz. Step Name bir isim veriyoruz.

Type T-SQL olarak kalıyor.

Database’i msdb seçiyoruz.

Command kısmına scriptimizi yazıyoruz.

Sql20

 

Schedules sekmesinde, New butonuna tıklayıp, bu görevin ne zaman yapılacağını belirtiyoruz.

Sql21

 

Notifications sekmesinde, eğer görev başarısızlıkla sonuçlanırsa bize email atmasını belirteceğiz. Daha önce tanımladığımız operatörü burada seçiyoruz, eğer Sql Agent operatörü tanımladıysanız burada gözükmeyecektir.

Sql22

 

Haftalık görevimiz jobs kısmına geldi, her Pazar günü saat 03:00 te geçmiş temizleme işini yapacak şekilde ayarlandı.

Sql23

 

Sql Server Agent Alerts Oluşturma:

Sql Server Agent önemli olayları ve koşulları, alarm özelliğini kullanarak, 3 farklı yöntemle bizlere sunarç

– Windows Application event logları (olay günlüğü)

– Sql Server performans sayaçları

– WMI olayları

Alarmlar oluşturulurken, Severity seviye 19’a eşit veya üzerindekiler seçilmelidir.

Ayrıca Error 825 hatası mutlaka eklenmelidir, error 825 I/O hatalarını kapsamaktadır.

Sql Server üzerinde bu alarmları nasıl oluşturulduğuna bakalım;

Sql Server Agent – Alerts kısmında sağ tıklayıp New Alert diyoruz.

Sql24

 

New Alert – General ekranında, alarmımıza bir isim veriyoruz. Severity kısmından Fatal Error in Resource yani 19 nolu alarmı seçiyoruz.

Sql25

 

New Alert – Response ekranında, Notify operators’ü işaretliyoruz, daha önce tanımladığımız operatörümüz geldi, mail seçeneği ile haber vermesini seçerek devam ediyoruz.

Sql26

 

New Alert – Option sekmesinde de, oluşan alarmın açıklamasını mailin içine alması için E-mail seçeneğini işaretliyoruz.

Sql27

 

New alert menüsünden, yeni bir alarm oluşturmayı gördük, şimdi de Script ile birden fazla alarm nasıl oluşturulur buna bakalım. Yukardaki sayfayı kapatmadan;

General sekmesine geliyoruz, Script butonuna tıklıyoruz.

Sql28

 

Script butonuna bastıktan sonra, aşağıdaki Query penceresi karşımıza geliyor.

Sarı ile seçtiğim alanı kopyalayıp, iki kere alt alta yapıştırıyorum.

Ok ile gösterdiğim yerleri Severity numarasına göre değiştiriyorum.

Düzenlemeleri yaptıktan sonra, F5 veya Execute’a basarak çalıştıyorum.

Mesaj bölümünde “Command(s) completed successfully.” Yazısının gelince, işlem başarılı olmuş demektir.

Sql29

 

Sql Server Agent – Alerts bölümüne gelip, alarmların oluşup oluşmadığına bakalım.

Değişiklerin gelmesi için, Alerts’in üzerinde sağ tıklayıp Refresh yapmak gerekiyor.

Genişlettiğimde script ile oluşturduğum 20 ve 21 nolu severity alarmların geldiğini görüyorum.

Sql30

 

Maintenance Planlarının Kapsamı:

Veritabanı bakım planları aşağıdaki konuları kapsamaktadır;

– Backup görevlerini planlamak

-Tutarlılık kontrolü (Checking consistency)

– Indeks bakımı (Index Maintenance)

– İstatistik bakımı (Statistics Maintenance)

– Bakım sonrası temizlik (Cleaning up after Maintenance)

Bakım görevlerini planlamadan önce aşağıdaki konuların iyi bilinmesi gerekiyor;

RPO (Recovery Point Objectives) ve Recovery Time Objectives. Detaylı bilgi için: http://www.sqlskills.com/blogs/paul/the-accidental-dba-day-6-of-30-backups-understanding-rto-and-rpo/

Recovery modelleri ve yedekleme tipleri. Detaylı bilgi için: http://www.sqlskills.com/blogs/paul/the-accidental-dba-day-7-of-30-backups-recovery-models-and-backup-types/

Recovery strateji planlaması. Detaylı bilgi için: http://www.sqlskills.com/blogs/paul/the-accidental-dba-day-8-of-30-backups-planning-a-recovery-strategy/

 

Back Up Database Görevi (Full):

İstenen veritabanlarında tam yedekleme gerçekleştirir.

Full yedekleme, transaction logların temizlediği boş alanların yeniden kullanımına izin vermez.

Diğer backup türkerini almadan önce, mutlaka bir full backup alınması gerekmektedir.

Backuplar ilk önce yerel bir diske alınmalıdır, eğer daha sonra isteniyorsa farklı lokasyonlara taşınabilir.

Backupların diskteki dosya uzantısı .BAK olmalıdır.

RPO ve RTO gereksinimlerini karşılamalıdırlar.

Günlük full backup alımı için genel bir strateji belirlenmelidir.

Back Up Database Görevi (Transaction Log):

Bir önceki log backup tamamlandıktan sonra, transaction log kayıtları oluşmaya başlar.

Full bakcup almadan, transaction log backup alınamaz.

Log backup tamamlandığında, aktif olmayan kısımdaki log temizlenir ve boş olan kısmın tekrar kullanılmasına izin verir, bu da dosyanın büyümesini engeller.

Log backup almak, veritabanındaki anlık işlemleri yedeklediğinden, geri dönüldüğünde en az veri kaybı ile geri döner. Transaction log backup ta, saat, dakika, hatta saniye olarak veritabanına geri dönülebilmektedir.

Transaction backup logların diskteki dosya uzantısı .TRN olmalıdır.

RPO gereksinimlerini karşılamalıdır.

Genel strateji olarak 15 dakika da bir transaction log backup alınması iyi olacaktır, veri kaybı en fazla 15 dakika olacaktır.

Back Up Database Görevi (Differential):

Full backup aldıktan sonra farkları yedeklerç

Differential backup ile geri dönmek, full backup a göre daha hızlıdır.

Full backup tan sonraki tüm log backupları kapsamına alır, en net etkisi bu diyebiliriz.

Differential backupların diskteki dosya uzantısı .BAK olmalıdır.

RTO gereksinimlerini karşılamalıdır.

Differential backup’ın dosya boyutu, full backup dosya boyutunu geçmiş ise, yeni bir full backup ile yenilenmelidir.

Disk üzerinde, full backup alınan dosyanın üzerine yazılır, transaction log gibi ayrı ayrı dosyalarda tutulmaz.

 

Tanımlar bu şekilde, şimdi Backup Database Task (görevi) bakalım;

Backup Database Task Yapılandırılması:

Maintenance planları sihirbaz (wizard) ile de yapabiliriz, bu konuyu makalemizin ilerki bölümlerinde anlatacağım.

Şimdi sırasıyla planlara göz atacağız. Backup task ile başlıyoruz.

Management – Maintenance Plans sağ tıklayıp New Maintenance Plan diyoruz.

Gelen küçük pencerede maintenance planımıza bir isim veriyoruz.

Sql31

 

Sql32

 

Full backup yapılandırmamızı yapmak için, sağ tıklayıp Edit Settings bölümünü açıyoruz.

Sql33

 

Backup Type kısmında, Full – Differential – Transaction Log seçenekleri mevcut. Full backup alacağımızdan Full’ü seçiyoruz.

Database(s) kısmında;

Tüm databaseleri (All databases)

Sadece sistem databaselerini seçmek için (System databases) master, tempdb, model ve msdb

Tüm kullanıcı databaselerini seçmek için (All user databases) bu seçenek sistem databaselerini kapsamaz.

İsteğe göre databaseleri seçmek için (These databases)

Ignore databases where the state is not online seçeneği, eğer veritabanı yedekleme sırasında online değil ise ilgili veritabanını atlamasını sağlayıp,  yedekleme işlemine hata verdirmeyiz.

İsteğe göre databaselerimizi seçiyoruz.

Sql34

 

Diğer ayarlara baktığımızda;

Backup set will expire: Eğer belli bir zaman sonra yedeklerimizin geçerliğini kaybetmesini istiyorsak, bu alanda süre belirtiyoruz. Son 1 hafta veya belirli bir tarihten sonra gibi.

Back up to: Yedeği disk’e mi yoksa Tape’ye mi alacağımızı belirttiğimiz yer.

Create a backup file for every databse: Bu seçenek ile, her veritabanını ayrı bir dosya olarak yedekleyeceğimizi seçiyoruz.

Create a sub-directory for each database: Her veritabanı yedeğini ayrı ayrı klasörlere koymak istiyorsak bu seçeneğini işaretliyoruz.

Yedeklerimizi hangi klasörde yedekleyeceğimizi belirtiyoruz.

Backup file extension: Yedeklerimizin dosya adı uzantısını belirtiyoruz. Eğer spesifik bir gereksinim yok ise bak olarak bırakıyoruz.

Verify backup integrity: Yedeklemeden sonra veri bütünlüğünü kontrol etmek istiyorsak bu seçeneği işaretliyoruz. Yedeklemeyi uzatan bir işlemdir, yapılması faydalı olur.

Set backup compression: Bu seçeneği varsayılan olarak bırakabiliriz, eğer disk üzerinde fazla alanımız yok ise, Compress backup ile yedeğimizi alabiliriz.

Sql35

 

En aşağıda ise View T-Sql kodunu bize veriyor, bu ne için lazım derseniz, başka bir serverımıza bu kodu kopyalabilir veya backup görevimizde değişiklik yapmak istersek bu scripti kullanabiliriz.

Sql36

 

Check Database Integrity Task:

Veritabanı bütünlüğünü kontrol eden bu görev, DBCC CHECHDB prosedürünü çalıştırıp, seçilmiş veritabanlarında, veri bozulması olup olmadığını kontrol ediyor.

Bilgi mesajı gelmesini istemiyorsak, WITH NO_INFOMSGS seçeneği ile kullanabiliriz.

Genel varsayıma göre, Sql server veritabanı bozulmasını anında algılar gibi yanlış bir varsayım vardır. Aslında database tarafında bozuk olan kısıma erişildiğinde Sql server corruption hatasını verir. Bozulmanın tespit edilmesi. günler belkide haftalar sürebilir, bu da veri kaybına sebep verebilir.

Veritabanındaki bozulmayı tespit edebilmek için, Integrity görevinin yapılması önem kazanmaktadır. Böylelikle veri kaybı riskini en minimum seviyede tutabilirsiniz.

Maintenance planlarda haftada bir yapılması tavsiye edilir. Hatırlatma; Integrity task işlemini başlatmadan önce veritabanlarınızın full backup ını almayı unutmayın.

DBCC CHECKDB Seçenekleri:

NOINDEX – Sadece Database Integrity task’ta kullanılabilen bu özellik ile, bütünlük görevi daha hızlı çalışıyor fakat, tablolardadaki indeksleri içermediğinden önerilmiyor.

ALL_ERRORMSGS – Bu özellik her nesnedeki hatayı göstermek için kullanılıyor. Sql Server 2008R2 de varsayılan olarak gelirken, Sql Server 2005 ve 2008 de varsayılan olarak gelmiyor.

EXTENDED_LOGICAL_CHECKS – Viewlerde, Xml indekslerinde ve büyük yapıdaki indekslerde düzeltmeler yapıyor, 100+ uyumluluğunu istiyor.

PHYSICAL_ONLY – Sayfa ve kayıt başlıklarındaki fiziksel yapının bütünlüğünü kontrol eder.

DATA_PURITY – Kolon değerlerinin geçerli veya belirtilen değerlerin dışında olup olmadığını kontrol eder.

Management Studio da örnek bir Integrity Task yapalım,

Maintenance Plans – New Plan, task imize bir isim veriyoruz.

Sql37

 

Sürükle bırak yaparak, Integrity Check Task’imizi getiriyoruz.

Sql38

 

İsim kısmına çift tıklamadan, edit settings aktif olmuyor. Sağ tıklayıp Edit diyoruz.

Sql39

 

Backup görevindeki gibi çok fazla seçeneğimiz yok. Veritabanlarımızı seçiyoruz, ardından Ok tuşuna basıyoruz.

Include Indexes seçeneğinin kaldırılması tavsiye edilmiyor, indeks bütünlüğünün kontrol edilmediği bir Integrity check tam anlamıyla görevini yerine getirmiyor. Bu seçeneği kaldırırsanız, görevin çok daha hızlı tamamlandığını göreceksiniz.

Sql40

 

Rebuild Index Task:

Veritabanlarındaki indeksleri yeniden oluşturmaya yarayan bir görevdir.

Tek bir task içinde birden çok veritabanı seçilebilir, tüm seçilen veritabanlarının indekslerinin yeniden yapılanması, tek görev içinde olabilir.

Tek bir veritabanı seçilir ise, veritabanı içindeki belirtilen tablolardaki indeksler rebuild yapılabilir.

Full scan yapılırken, aynı zamanda istatistiklerde güncellenir.

Fragmantasyon seviyesi yüzde kaç olursa olsun, rebuild indeks task’i çalıştırdığımızda, seviyesine bakmadan çalışır.

Tablo veya indekslerde partition yapılmış ise, rebuild indeksleme bunu desteklemiyor.

Free space seçeneği ile, page lerdeki boşlukları bularak bir nevi veritabanının alanını düzenliyor.

Şimdi Management Studio üzerinden yapılandırılmasına bakalım;

Maintenance Plans – New Maintenance Plan, task’imize bir isim veriyoruz.

Sql41

 

Toolbox’taki Rebuild Index Task’imizi yan tarafa sürükle bırak yapıyoruz.

Sql42

 

Task’imiz üzerinde sağ tıklayıp Edit ekranını açıyoruz.

Sql43

 

All Databases, System Databases ve All User Databases’lerini seçersek, object (nesneler) ve selection (seçimler) ekranları aktif gelmiyor. Veritabanı bazında ayrı ayrı nesne bazlı seçmemize izin vermiyor.

Sql44

 

Şimdi databases kısmından bir tane veritabanı seçiyorum.

Sql45

 

Object (nesne) kısmı aktif oldu, burada table-view veya table and view seçebilirim. Table and view seçtiğimizde, selection kısmı aktif olmuyor, tüm table ve viewları bütün olarak ele alıyor. Sadece table seçerek devam edelim.

Sql46

 

Selection kısmında sadece Cariler tablosunu seçiyorum.

Sql47

 

Reorganize Index Task:

İndeksleri yeniden organize etme olarak Türkçe’ye çevirebiliriz.

Reorganize Index görevi, Rebuild Index görevi ile aynı zamanlanmış görev içinde kullanılmamalıdr.

Rebuild index görevindeki gibi statisticsleri güncellemez. Bu yüzden, alt içerik olarak Update statistics görevi içine eklenmelidir.

Eğer indekskerin bozulması ile ilgili bir analize yapılmadıysa, reorganize index görevinin çalıştırılması tavsiye edilmez.

Management Studio üzerinde, Maintenance – Maintenance Plans sağ tıklayıp New Maintenance Plan diyoruz. ReorganizeIndex adını yazdım.

Toolbox’tan Reorganize Index’i yan tarafa sürüklüyoruz.

Sql48

 

Reorganize Index Task’imize sağ tıklayıp Edit diyoruz.

Sql49

 

Rebuild Index görevinde olduğu gibi, Alldatabase ve System Databaselerini seçersek, table ve view bazında reorganize yapamıyoruz.

Kullanıcı databaselerini veya belirttiğimiz databaselerini seçtiğimizde, table veya view bazlı seçmemize izin veriyor.

Bir tane veritabanı seçiyorum.

Sql50

 

Obejct kısmında, table seçtiğimizde tablo bazında reorganize indeksleme yapmamızaizin veriyor. Aynı seçenek viewler içinde geçerli. Table and view seçtiğimizde ise tüm tablo ve viewleri kapsıyor.

Sql51

 

Sql52

 

Birden çok serverda bu işlemi yapmak istersek, TSql koduna basıp bu görevi çoğaltabiliriz.

Compact Large Objects seçeneği ile, büyük nesnelere bir nevi birleştirme işlemi yapmaya yarıyor.

Sql53

Update Statistics Task:

Update Statistics Task’e, istatistikleri güncellemede diyebiliriz.

Tüm veritabanları seçildiğinde, veritabanlarındaki tüm nesneler için uygulanır.

Tek bir veritabanı seçildiğinde ise, tablo ve view bazında seçim yapılabiliyor.

Management Studio üzerinde, Maintenance – Maintenance Plans sağ tıklayıp New Maintenance Plan diyoruz. UpdateStatistics ismini verdim.

Toolbox’tan Update Statistics’i sürükleyip yan tarafa bırakıyorum.

Sql54

 

Update Statistics task’imize sağ tıklayıp Edit diyoruz.

Sql55

 

All databases ve System Databases leri seçerksek, tablo ve view bazında seçim yapamıyoruz.

Sql56

 

Diğer seçeneklerine bakalım;

All existing statistics – Tablo üzerindeki tüm istatiskleri günceller

Column statistics ony – Kolonlardaki istatistikleri günceller

Index statistics only- İndekslerdeki istatistikleri günceller

Scan Type – Full Scan – Tablodaki tüm satırların istatistiklerini günceller

Scan Type – Sample by – Bu kısımda belli bir yüzde veya satır adedi seçebiliyoruz.

History Cleanup Task:

Bir sistem veritabanı olan msdb, aşağıdaki olayların geçmişlerini tutar;

Backup ve restore hareketleri

Sql Server Agent’taki görevlerin çalışmalarını

Bakım planlarının çalışmaları

History cleanup görevi, yukardaki işlemlere ait geçmiş kayıtları belli periyodlar arasında yapılmasını sağlar. Msdb veritabanının boyutununda büyümesini engeller.

Haftada bir yapılması önerilir, server yoğunluğuna göre zamanlaması değiştirilebilir.

Management Studio üzerinde, Maintenance – Maintenance Plans sağ tıklayıp New Maintenance Plan diyoruz. HistoryCleanup adını verdim.

Toolbox’tan History Cleanup’ı yan tarafa sürükleyip bırakıyoruz.

Sql57

 

History Cleanup Task’imize sağ tıklayıp Edit’e geliyoruz.

Sql58

 

Hangi datalarla ilgili geçmişin temizleneceğini seçiyoruz.

Remove historical data older than seçeneğiyle de, saat, gün, hafta, ay, yıl olarak geçmişleri temizleyebiliyoruz.

Sql59

 

Maintenance Cleanup Task:

Bu görevi, bakım temizleme olarak da adlandırabiliriz.

Yedekleme dosyalarını, plan raporlarını veya dosya sisteminin oluşturduğu diğer tüleride bu görev ile temizleyebiliyoruz.

Sadece bir dosya uzantısı belirtebiliyoruz, belirttiğimiz dosya uzantısına göre temizleme işlemi yapıyor. Maintenance plan metin belgesi raporlarını .txt veya Backup Files’larımız içinde .bak uzantılı dosyaları temizleyebiliriz.

Management Studio üzerinde, Maintenance – Maintenance Plans sağ tıklayıp New Maintenance Plan diyoruz. Bir isim veriyoruz.

Toolbox’tan Maintenance Cleanup Task görevimizi sürükle bırak ile getiriyoruz. Bu kısımlar yukarıdaki maintenance planlar ile aynı olduğundan ekran görüntülerini eklemeye gerek duymadım.

Backup Files veya Maintenance Plan text reports’u seçebiliyoruz, backup files’ı seçtiğimizde file extension kısmı bak, maintenance plan text reports’u seçtiğimizde ise txt oluyor.

Sql60

 

Transaction Log Backup dosyalarını temizlemek istiyorsak, file extension kısmına trn yazmamız gerekiyor.

Include first – level subsfolders seçeneğiyle de alt klasörleride tarayarak, ilgili tüm dosyaları bulup temizliyor.

File age, kısmında ise, saat, gün, hafta, ay, yıl bazında seçim yaparak, şu tarihten eski dosyaları temizle diyebiliyoruz.

Sql61

 

Shrink Database Task:

Disk üzerindeki databaselerin küçültmeye yarayan bir görevdir. Maintenance planlarda kullanımı yanlış anlaşılmış veya atlanmış olan bir görevdir.

Düzenli olarak shrink database yapılmamalıdır.

Veritabanlarının büyümek için alana ihtiyaç var ise yapılmalıdır.

Shrink işlemi, veritabanındaki sondak pages denen kısımları, data dosyası üzerinde en başa getirir, bu da yüksek seviyede indeks bozulmasına sebep olur.

Shrink database işlemi, Rebuild Index görevinden önce çalıştırılmalıdır. Bu şekilde olursa, index bozulmasının önüne geçilebilir.

Kesinlikle takvimlenmiş bir görev olarak ayarlanmamalıdır.

Management Studio üzerinde, Maintenance – Maintenance Plans sağ tıklayıp New Maintenance Plan diyoruz. Bir isim veriyoruz.

Toolbox’tan Shrink Database Task görevimizi sürükle bırak ile getiriyoruz.

Edit kısmına geliyoruz.

Databases(s) kısmından hangi veritabanında küçültme işlemi yapacaksak onu seçiyoruz, tüm veritabanlarını ya da sadece sistem veritabanlarınıda seçebiliriz.

Sql62

 

Shrink database when it grows beyond; Veritabanımız 50 mb’a ulaştığında küçültme işlemini yap diyor.

Amount of free space to remain after shrink; Küçültme işlemi yüzde 10 seviyesine ulaştığında işlemi durdurur.

Retain freed space in database files; Bu seçenek seçmek pekte doğru değil, küçültülmüş alanı veritabanı dosyasında tut anlamına geliyor, shrink işlemi açısından pekte uygun olmayan bir seçenek.

Return space to operating system; Shrink işleminde amacımız disk üzerinde yer kazanmak, bu yüzden elde edilen boş alanları tekrardan işletim sistemine kazandırmak için bu seçeneği işaretliyoruz.

Sql63

 

Sql Server Agent Job Görevi Oluşturmak:

Sql Server Agent görevlerini birden çok amaç için kullanabiliriz.

Birkaç örnek vermek gerekirse;

Database maintenance görevlerini çalıştırır.

Sql server arşivindeki verileri çıkartmada kullanılabilir.

Network üzerinde dosya transferi yapılabilir.

SSIS (Sql Server Integration Services) package’lerini çalıştırabilir.

PowerShell script’i çalıştırabilir.

Bir Sql Trace (izleme) veya Sql event (olay) lerini izlemek için kullanılabilir.

Maintenance Plan altında, Execute Sql Server Agent Job görevi oluşturmaya bakalım;

Management Studio üzerinde, Maintenance – Maintenance Plans sağ tıklayıp New Maintenance Plan diyoruz. Bir isim veriyoruz.

Toolbox’tan Execute Sql Server Agent Job görevimizi yan tarafa sürükleyip bırakıyoruz.

Sql64

 

Görev üzerinde sağ tıklayıp Edit diyoruz.

Sql65

 

Karşımıza gelen pencerede, kullabileceğimiz Agent job’ları karşımıza geldi. Maintenance planlarda oluşturduğumuz görevlerde buraya geliyor. Sadece tek bir görev seçebiliyoruz.

Sql66

 

Execute T-Sql Statement Task:

T-Sql Statement görevini Maintenance Plan sihirbazından oluşturamıyoruz. Fakat SSIS paketleri ile veya Maintenance Plan Designer ile oluşturabiliyoruz.

Maintenance Planlar altında bir Sql scripti çalıştırmamıza olanak sağlıyor.

İstenen veritabanı için çalıştırılmaya izin vermiyor, fakat script özelleştirilip bu yapılabiliyor.

Sql Server Agent Job’taki ilk adımları yapıyoruz.. Edit ekranına geliyoruz.

Örnek olarak bir store procedure ekleyelim.

Sql67

 

Notify Operator Task:

Maintenance Plan sihirbazı ile oluşturulduğunda etkin olabiliyor.

Bir maintenance planın, başarılı, başarısız veya tamamlandığında, seçilmiş olan operatöre bilgilendirme yapılmasını sağlayan bir görevdir.

Eğer Sql Server Agent üzerinde bir operator tanımınız yok ise, görev ilk açıldığında bir uyarı verecektir. Bir operatör tanımlayıp görevi oluşturmaya devam edebilirsiniz.

Tek başına Notify Operator task oluşturmanın pek bir anlamı yok. Esas maintenance plan sihirbazı ile, bir görevin içine tanımlanması  gerekiyor.

Sql68

 

Maintenance Plan Sihirbazı – Wizard:

Bakım planlarının yapılandırılmasını bir sihirbaz vasıtasyıla yapılmasını sağlıyor. Birden fazla planı tek bir sihirbaz ile konfigüre edebiliyoruz fakat planlardaki tüm detaylar sihirbazda karşımıza çıkmıyor.

Birden fazla bakım planı için bir tane Sql Agent Job oluşturabiliyoruz. Yanlızca bir kereliğine bir job çalıştıracaksak, bakım planlarının sırasını belirtmemiz gerekiyor.

Veritabanlarının yapılarına göre veya isteklere göre, birden fazla bakım planı oluşturabilir, yanlız yönetimsel olarak kontrolü zor olacaktır.

Şimdi maintenance plan wizard ımızı açıyoruz. Object explorer’da Management’ın altında, Maintenance Plans’a sağ tıklıyoruz, Maintenance Plan Wizard’ı açıyoruz.

Sql69

 

Açıklamaların olduğu bir ekran geliyor, Next ile ilerliyoruz.

Sql70

 

Maintenance planımıza bir isim veriyoruz. Run as kısmı olduğu gibi kalıyor. Şimdi görevin çalışacağı zamanlamayı seçeceğiz. İlk önce Single Schedule for the entire plan or no schedule’u göstereceğim. Bu seçenekte, seçtiğiniz görevleri sırasıyla yerine getiriyor. Sadece hangisi önce olsun veya sonrasında olsun diyerek siz sıralama belirtiyorsunuz. Bir maintenance planda 5-6 tane görev ekleyeceğimizi düşünürsek, single schedule seçmek pekte sağlıklı bir yöntem değil.

Sql71

 

Birden fazla görev seçtik, next diyoruz.

Sql72

 

Bu ekranda da, görevlerin sadece sıralamasını değiştiriyoruz.

Sql73

 

Select Plan Properties ekranına geri dönerek, Schedule’umuzu değiştirelim. Separate Schedule for each task seçeneğini seçerek devam ediyoruz.

Sql74

 

Görevlerimizi seçip Next ile devam ediyoruz.

Sql75

 

Task order ekranında, görevleri yukarı veya aşağıya taşıyamıyorum, zamanlamayı sonraki ekranlarda yapacağız.

Sql76

 

Şimdi, her görev için tek tek konfigürasyonlarının ve zamanlamalarının yapılacağı ekranları gelecek.

İlk olarak, Database Check Integrity Task’ı ayarlıyorum. Databases kısmından tüm veritabanlarını seçtim.

Sql77

 

Daha sonra Schedule’a tıklayarak, bu görevin ne zaman çalışacağını belirtiyorum.

Sql78

 

Reorganize Index Task ta, tüm kullanıcı veritabanlarını seçtim, zamanlama olarak da, Çarşamba saat 11:00 olarak ayarladım.

Sql79

 

Rebuild Index Task, tüm kullanıcı veritabanlarını seçtim. Rebuild yaparken mevcut indeksleri de online tutmasını seçtim.

Sql79

 

Backup Database task, tüm veritabanlarının yedeklenmesini seçtim. Her veritabanı için ayrı klasör oluştur seçeneğini ve sıkıştırılmış yedek almasını işaretledim. Schedule dan da, yedeklemelerin ne zaman yapılacağını belirttim, günlük mü, aylık mı, haftalık mı, bu konu sizin yedekleme politikanıza göre değişebilir. Aşağıda yönergelerini takip edebilirsiniz.

Sql80

 

Differential yedeklemede ise, günlük olarak ayarlıyorum. Full backup görevimizi haftalık olarak ayarlamıştık.

Sql81

 

Transaction log backup ı da, saatlik olarak ayarlıyoruz. Differential backup taki gibi ayarlarımızı bırakıyoruz. Schedule kısmından, saatlik olarak seçiyoruz.

Sql82

 

Maintenance planlar için bir rapor istiyorsak, Write a report to a text file seçeneğini seçiyoruz. Text dosyasına maintenance plan için logları getiriyor. Görevlerin durumu için mail istiyorsak, E-mail report seçeneğinden, Sql Server Agent üzerinde daha önceden oluşturduğumuz operatörümüzü seçiyoruz.

Sql83

 

Son olarak, maintenance planımız içindeki görevleri bir özet olarak karşımıza getiriyor.

Sql84

 

Maintenance planımız başarılı bir şekilde oluşturuldu.

Sql85

 

Oluşturduğumuz maintenance plan, Managemanet – Maintenance Plans altında gözüküyor.

Sql86

 

Maintenance Plan Designer – Tasarım:

Maintenance Plan Designer ile, Maintenance Plan Wizard ile oluşturduğumuz planları düzenleyebiliyoruz. Sihirbaz ile oluşturduğumuz planlar, tekrardan sihirbaz ile düzenlenmiyor.

Farklı konfigürasyondaki görevleri çoğaltabiliyoruz.

Benzer konfigürasyondaki görevleri de, eş zamanlı olarak çalıştırabiliyoruz.

Tek bir plan altında, birden çok görevi farklı zamanlarda çalıştırabiliyoruz.

Designerda iş akışı oluşturup, bunların başarılı, başarısız veya tamamladı ayarları yapılabiliyor.

Tek bir görev içinde, birden çok bağlantı yapılandırılması yapılabiliyor.

Tek bir plan içinde, birden çok bildirim ve raporlarma konfigürasyonları yapmak mümkün.

Otomatik olarak, Sql Agent Jobları oluşturup, bu jobların zamanlamasını ve alt planların yapılandırılması designer da yapılabiliyor.

Şimdi yeni bir maintenance plan oluşturalım. Maintenance Plans sağ tıklıyoruz. New Maintenance Plan diyoruz.

Sql87

 

Planımıza bir isim veriyoruz.

Sql88

 

Karşımıza boş bir maintenance plan designer ekranı geliyor. Object explorer’ın altında da, Toolbox, araç kutusu menüsü geldi.

Sql89

 

Soldaki Toolbox menüsünden, Check Database Integrity Task’, designer ekranına sürükleyip bırakalım. Ardından Back Up Database Task’i getirelim.

Sql90

 

Görevlerimizin içindeki kırmızı içindeki beyaz çarpı işareti, bu görevlerin daha yapılandırılmadığını gösteriyor. Check Database Integrity Task imize çift tıklayarak içine giriyoruz. Tüm kullanıcı veritabanlarını seçtim.

Sql91

 

Check database görevimiz başarı ile tamamlandıktan sonra, Back up database görevine geçmesini istiyoruz. Bunun için Check database görevinin altındaki yeşil oku sürükleyip, Backup database görevine tutturuyoruz.

Sql92

 

Bağlantıyı sağladıktan sonra, Backup database görevimize de yapılandıralım.

Tüm kullanıcı veritabanlarını seçtim. Yedeğin nereye alınacağını belirttim. Sıkıştırılmış yedek al diyerek, backup database yapılandırmamı tamamlıyorum.

Sql93

 

Planımızın ne zaman çalışacağını ayarlamak için. Job Schedule kısmına geliyoruz.

Sql94

 

Pazar sabahları saat 11:00 olarak çalışmasını ayarlıyorum.

Sql95

 

Bir Subplan daha ekliyoruz. Add Subplan butonuna tıklıyoruz.

Çıkan pencerede isim vermek istiyorsak, subplanın ismini değiştiriyoruz.

Sql96

 

Bu subplan2 ye Rebuild Index task ve Notify operator task i tanımlıyoruz.

Sql97

 

İlk önce Rebuild Index task imizi yapılandıralım.

Sql98

 

Rebuild index task imiz başarısız olursa, bize mail atsın, bu ayarı yapmak içinde, Rebuil index task in connectorüne sağ tıklayıp Failure’ü seçiyoruz.

Sql99

 

Notify operator task e çift tıklayarak, mail ile bildirim alacak olan operatörü seçiyorum.

Gidecek olan mailin başlık ve içeriğini yazıyorum. Bu gibi tanımlamalar önemli, eğer buraları anlamlı ifadelerle tanımlamaz iseniz, ilerde bir sürü olan görevlerinizden gelen bildirim maillerinin hangi görevden geldiğini anlayamazsınız.

Sql100

 

Eğer görevimizin başarılı bir bir şekilde sonuçlandığında da bildirim almak istiyorsak. Bir tane daha Notify operator task ekliyoruz. Rebuild index task imizden de yeşil ok çekerek operator taskimize bağlıyoruz.

Sql101

 

Görevimizi çarpı ile kapatıp, çıkan ekranda evet diyerek kaydediyoruz.

Sql102

 

Maintenance planımız, Management altında Maintenance Plans lara gelmiş ve Sql Server Agent ta da, subplanlarımız gözüküyor.

Sql103

 

Şimdi wizard yani sihirbaz ile oluştuduğumuz maintenance planımıza bakalım. VeritabanıBakımPlani planımıza sağ tıklayıp Modify diyoruz.

Sql104

 

Designer ekranında, sihirbaz ile oluşturduğumuz planlarımıza ilaveler yapabilir veya planlarımızı düzenleyelebiliriz. Backup database full planımıza notify operator task ekleyelim.

Sql105

 

Notify operator task i diğer tüm planlar için ayrı ayrı tanımlamamız gerekiyor.

Bu makalemde maintenance planlar ile ilgili tüm ayrıntılara girmeye çalıştım. Sorularınız olursa benimle iletişime geçebilirsiniz.

Makale istatistikleri:

Bu makale; Word dosyasında 65 sayfa, 4662 kelime ve 105 ekran görüntüsünden oluşmaktadır.