Recent comments

None


İçerik Ara











Yasal Uyarı
Bu sitede sunulan tüm bilgi ve dökümanlar Turgay Sahtiyan tarafından yazılmaktadır. Yazıların kaynak göstermek şartıyla kullanılması serbesttir.

© Copyright 2009-2013
Takvim
<<  Ekim 2017  >>
PaSaÇaPeCuCuPa
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345
Keywords

SQL Server 2011 Denali ile beraber gelen en büyük yenilik gruplarından biri yeni High Availability and Disaster Recovery seçenekleri. Bu yeni seçenekler ile beraber daha yüksek erişebilirlik sunulabilecek ayrıca daha güvenilir disaster recovery çözümleri kullanılabilecektir. Ayrıca yeni gelen bu özellik grubuna Always On’da denilmektedir.

[more]

Hali hazırda SQL Server’ın sunduğu High Availability and Disaster Recovery çözümleri aşağıdaki gibidir.

  • Failover Cluster Instance
  • Database Mirroring
  • Log Shipping

Bu çözümler bir çok işimizi çözmekle beraber sektörde daha iyi bir high availability beklentisi vardı. Microsoft’ta Denali’de sunduğu HADR çözümleri ile bu istekleri karşılamış gibi gözüküyor.

HADR ile gelen çözümleri şu anki klasik mirroring yapısının iyileştirilmesi gibi düşünebiliriz. Şimdi isterseniz HADR ile beraber neler geliyor madde madde bakalım.

HADR Altyapısı

HADR kullanmak için hepinizin tahmin edebileceği gibi birden fazla node gerekmekte. Bu node’lar üzerinde Windows Server Failover Cluster (WSFC) kurulu olmalı.

SQL Server tipi olarak cluster kurulum yapma zorunluluğu yok. Standalone SQL Server kurulumları ile de HADR kullanılabilmekte.

Multi-Database Failover

Şu anki mirror yapısı tek bir database seviyesinde tanımlanmakta. Mirror yapılan bu database’de bir sıkıntı oluştuğunda mirror database’den çalışmalara devam edilebilmekte.

Yani burada tek bir database’in failover yapmasından bahsediyoruz.

HADR ile gelen Availability Groups ile database grupları tanımlayabilir ve bu grubun içinde 1 database fail etse dahi grubun tamamını diğer sunucudan çalışır hale getirebileceğiz. Yani grup’un tamamı failover edebilecek.

Böyle bir ihtiyacın neden olabileceği üzerine konuşalım. Örneğin bir ticari program yaptınız ve müşteri bilgilerini bir database’de, satış bilgilerini de bir başka database’de tutuyorsunuz. Satış bilgilerini tuttuğunuz database’de de bazı SP’ler var ve bu SP’ler müşteri DB’sine giderek müşteri bilgilerini getirmekte. Böyle bir yapıda SP’lerin hata vermemesi için 2 DB’nin de aynı sunucu üzerinde bulunması gerekmekte. İşte böyle bir durumda örneğin müşteri DB’si fail edip diğer server’a giderken satış DB’si eski server’da kalmaya devam ederse bahsettiğimiz bu SP’ler hata verip çalışmayacaktır. İşte HADR ile beraber gelen Availability Groups seçeneği ile bu 2 DB’yi aynı grubun içine koyuyoruz ve bu 2 DB’den hangisi fail ederse etsin 2 sini birden mirror sunucudan kullanmaya başlıyoruz.

Şu anki CTP1 sürümündede Availability Groups içinde sadece 2 server bulundurulabilmekte.

Multiple Secondaries

Klasik mirroring çözümünde bir tane secondary yani mirror database bulundurabiliyorduk. HADR ile beraber gelen özelliklerden biri olan Multiple Secondaries yani birden fazla secondary bulundurabilme özelliği ile daha yüksek bir High Availability çözümü sağlamış olacağız.

Active Secondaries for Reporting

Belkide HADR ile beraber gelen en önemli özelliklerden biride secondary database’leri rapor amacı ile kullanabilmek. Bildiğiniz gibi şu anki klasik mirroring çözümünde mirror database’ler herhangi bir şekilde erişebilir durumda değildi  ve atıl olarak kalmaktaydı. Gerçi synonym ve snapshot ile bazı çözümler sunulmuş olmasına rağmen pek istediğimiz gibi çalışmamaktaydı.

HADR ile beraber artık secondary sunucularımızı kullanabilir yapıdayız. Bu durumda primary sunucuyu OLTP işlemleri için, synchronous yada asynchronous olarak beslenen secondary database’ide reporting amacı ile kullanarak ana server’daki yükü bölmemiz mümkün.

hadr

Bu arada CTP1’de sadece asynchronous mode desteklenmektedir.

Fast Client Connection Redirection

Gene klasik mirror yapısında primary database’den secondary database’e geçiş yapıldıktan sonra webconfig bilgilerimizi yeni sunucuya göre ayarlamamız gerekmekteydi. HADR ile beraber sağlanan virtual network name vasıtasıyla sunucular arasında database geçiş yaptıktan sonra herhangi bir connection string değişikliği yapmamız gerekmemekte. Bu yapıyı failover cluster sistemindeki virtual network name ile aynı şekilde düşünebilirsiniz.

Backup on Secondary Server

Backup’lama işlemi primary sunucudan yapılabileceği gibi secondary sunucudan da yapılabilir. Backup’ları secondary sunucudan alarak backup load’ını primary sunucunuzda kaldırabilirsiniz.

Primary’den alınan backup secondary için kullanılabilir, aynı şekilde secondary sunucudan alınan backup’ın da primary sunucu için kullanılması mümkündür.

AlwaysOn Dashboard

Bu kadar gelen yeni özellikle beraber bu özellikleri monitor etmek amacıyla yeni bir dashboard oluşturulmuş durumda. Tek bir ekrandan yeni HADR seçeneklerini monitor etmemiz mümkün.

 

Denali ile gelen/gelmesi planlanan yeni HADR özellikler bu şekilde. Daha sonraki yazılarımda bu özelliklerin teknik detaylarınada inmeye çalışacağım.

 

İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server 2008 de Snapshot kullanımını konu alan bu video da şu ana başlıklar dikkate alınmıştır.

  • Snapshot nedir?
  • Hangi amaçla kullanılabilir?
  • Nasıl çalışır?
  • Dikkat edilmesi gereken noktalar
  • Örnekler

Snapshot create kodu;

CREATE DATABASE AdventureWorks_dbss ON
( NAME = AdventureWorks_Data, FILENAME = 'd:\Snapshot\AdventureWorks_data.ss' )
AS SNAPSHOT OF AdventureWorks;
GO


Snapshot tan DB restore kodu

restore database AdventureWorks from database_snapshot='AdventureWorks_dbss'

 

İyi seyirler

SQL Server 2008 de Snapshot Kullanımı from Turgay Sahtiyan on Vimeo.

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Bir önceki yazımda SQL Server daki system table larının ne olduklarını ve ne amaçla kullandıklarını anlatmıştım. Bu yazıma aşağıdaki linkten erişebilirsiniz.
http://www.turgaysahtiyan.com/post/SQL-Server-System-Databases-(Sistem-Veritabanlarc4b1).aspx

TempDB Database File larını Taşımak makalemde de bahsettiğim gibi system DB lerinin taşınması normal user DB lerinin taşınmasından farklıdır.

Bu yazımda da master DB nin database file larının nasıl taşınacağını adım adım anlatıyor olacağım.

  1. Start >> Programs >> Microsoft SQL Server 2008 >> Configuration Tool >> SQL Server Configuration Manager ı açalım.
    image
  2. Master DB sinde değişiklik yapmak istediğimiz SQL Server instance ı sağ tıklayıp properties e basalım. (örneğin SQLServer(MSSQLServer)
    image
  3. Advanced tab ında Startup Parameters te oynama yapacağız.
    image
  4. Startup parameters deki yazı herhangi bir değişiklik yapılmadıysa aşağıdaki gibidir.

    -dC:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\master.mdf;
    -eC:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log\ERRORLOG;
    -lC:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\mastlog.ldf

    Master DB nin Data ve Log file larını C:\DATA folder ına taşıdığımızı düşünürsek startup parameters de ki yazı aşağıdaki gibi olmalıdır.

    -dC:\DATA\master.mdf;
    -eC:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log\ERRORLOG;
    -lC:\DATA\mastlog.ldf

    Bu yazıyı alıp startup parameters e paste edip apply diyerek ekranı kapatalım.
  5. Configuration Manager üzerinden SQL Server Service i stop edelim.
  6. Master DB nin data ve log file larını (master.mdf ve mastlog.ldf) bulunduğu yerden alıp C:\Data folder ına taşıyalım.
  7. Configuration Manager dan SQL Server service ini tekrar start edelim.
  8. Kontrol amaçlı Management Studio üzerinden aşağıdaki sorguyu çalıştıralım.
    SELECT name, physical_name AS CurrentLocation, state_desc
    FROM sys.master_files
    WHERE database_id = DB_ID('master');
    GO
  9. Aşağıdaki gibi bir sonuç almamız beklenmektedir.
    image


Bir sonraki makalemde görüşmek üzere.

İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Database in zarar görmesi yada bunun gibi database e erişilemeyen durumlarda backup alınmamış işlemlerin kayıpsız olarak geri alınabilmesi için kullanılan back up tipi Tail-Log Backup tır.

Sistem böyle bir durumda normal backup scriptlerinin kullanılmasına izin vermez ve sadece Tail-Log Backup kullanabilirsiniz.

Tail-Log Backup ile Backup Alma


Tail Log backup ın kullanılabilmesi için database Recovery Model in full yada bulk-logged olması gerekmektedir. Ayrıca bu backup işlemi GUI den yapılamaz. Not düşmekte fayda var. Log file ın zarar gördüğü durumlarda Tail-Log backup alınamaz.

Aşağıdaki durumlarda Tail-Log Backup alarak backup lanmamış işlemlerinizi kurtarabilirsiniz.

  • Eğer database online ise restore işlemlerine başlamadan önce WITH NORECOVERY option ı ile tail-log backup alabilirsiniz.
BACKUP LOG database_name TO  WITH NORECOVERY

 

  • Eğer database offline ise ve start edilemiyor ise Tail-Log Backup alabilirsiniz. WITH NORECOVERY kullanımı opsiyoneldir. Eğer database damaged ise WITH CONTINUE_AFTER_ERROR yada WITH NO_TRUNCATE option ı kullanılabilir. WITH NO_TRUNCATE option ı damaged database ler haricinde kullanılmaması önerilir.
BACKUP LOG database_name TO  [WITH { CONTINUE_AFTER_ERROR | NO_TRUNCATE }

 

Şöyle bir senaryo düşünelim.

Live ortamda kullandığımız bir database var ve belirli aralıklarla bu database i backup lıyoruz. Yeni backup zamanı gelmeden disk te bir problem oldu ve mdf file bozuldu. Şu anda Database e erişemiyoruz ve normal backup lama işlemlerini yapamıyoruz. Eldeki backup lardan dönersekte veri kaybımız olacak. Bizim amacımız log dosyası vasıtasıyla veri kayıpsız mdf file a tekrar ulaşmak.

Şimdi bunun örneğini yapalım.

İşlemlere başlamadan önce C:\Backup klasörünü yaratalım. Çünkü backup lar buraya alınacak.

use master
GO

--yeni bir database create ediyoruz.
create database TailSampleDB
GO

--yeni bir table create ediyoruz.
use TailSampleDB
create table TailSampleTbl (a varchar(10))
GO

--Yeni bir satır insert ediyoruz.
--Amacımız her backup tan evvel bir satır ilave etmek.
--Son satır ilavesinden sonra mdf file ı sileceğiz ve 
--Tail-Log Backup ile bu satırı yani datanın son halini kurtarmaya çalışacağız.
insert TailSampleTbl select '1'
GO

--İlk satır ilavesinden sonra full backup alıyoruz.
BACKUP DATABASE [TailSampleDB] TO  DISK = N'C:\backup\full.bak' WITH NOFORMAT, NOINIT,  NAME = N'TailSample-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

--İkinci satırı insert ediyoruz.
insert TailSampleTbl select '2'
GO

--İkinci satırdan sonra diff backup alıyoruz.
BACKUP DATABASE [TailSampleDB] TO  DISK = N'C:\backup\diff.bak' WITH DIFFERENTIAL, NOFORMAT, NOINIT,  NAME = N'TailSample-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

--Üçüncü satırı insert ediyoruz.
insert TailSampleTbl select '3'
GO

--mdf file ı silebilmek için sql server service ini stop ediyoruz.
--daha sonra mdf file ı bulup siliyoruz.
--service i tekrar start ediyoruz.
--şu anda SSMS ten database bakacak olursanız erişilemez olduğunu göreceksiniz.
--Ayrıca SSMS üzerinden backup alınmadığını görebilirsiniz.

--Restore işlemlerine başlamadan önce data kaybı olmaması için Tail-Log Backup alıyoruz.
BACKUP LOG TailSampleDB TO DISK='C:\backup\tail.bak'

--Restore lere başlıyoruz. Önce Full restore.
--Tail log backup a kadar restore işlemleri WITH NORECOVERY option ı ile
RESTORE DATABASE [TailSampleDB] FROM  DISK = N'C:\backup\full.bak' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  REPLACE,  STATS = 10
GO

--Diff back up restore
RESTORE DATABASE [TailSampleDB] FROM  DISK = N'C:\backup\diff.bak' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  REPLACE,  STATS = 10
GO

--Tail-Log Backup ı restore ediyoruz.
--Bu restore işlemi son adım olduğu için WITH NORECOVERY kullanıyoruz.
RESTORE LOG [TailSampleDB] FROM  DISK = N'C:\backup\tail.bak' WITH  FILE = 1,  NOUNLOAD,  STATS = 10
GO

--Tabloyu kontrol ediyoruz
use TailSampleDB
select * from TailSampleTbl

--bingoo
--Son satır olmak üzere bütün satırlar kurtarıldı.

 

Umarım faydalı bir yazı olmuştur.

İyi çalışmalar

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan