SQL Server 2008 de Database Snaphot Kullanımı

Merhaba Arkadaşlar,

Bu yazımda sizlere SQL Server 2008 de Database Snaphot kullanımını anlatacağım. Bu yazıyı okumadan önce Database Snapshot kavramını anlatan önceki yazımı okursanız sizin açınızdan faydalı olacaktır. Snaphot lar Databases sekmesinin altında aşağıdaki gibi bulunmaktadır. Şuana kadar Hiçbir Veritabanının Snapshot ı alınmadığı için Database Snapshots sekmesi göründüğü gibi boş durumdadır.

SQL Server da Snapshot oluştururken Management Studio da User Interface den değilde aşağıdaki görüntüde bulunan T-SQL koduyla oluşturulmaktadır. Örnek olarak Bir çok örnekte kullanılan ve çok sevdiğim Test database olan AdventureWorks database i kullanılmıştır.

SQL Server Database Snaphot Kodu
CREATE DATABASE AdventureWorksSnaphot  ON
( NAME = AdventureWorks_Data, FILENAME = 'd:\Snapshot\AdventureWorks_SparseFile.ss' )
AS SNAPSHOT OF AdventureWorks;
GO

Script çalıştırıldığı zaman yukarıda sol tarafta göründüğü gibi SQL Server AdventureWorksSnaphot adında bir database Databases Snaphot sekmesinin altında oluşturulmuştur. Bu database AdventureWorks database inin sadece bir görüntüsüdür. Diskte AdventureWorks database inin boyutu kadar bir Sparse file oluşturulmasına rağmen başlangıçta çok küçük bir boyut olarak Create edilmektedir. Aşağıdaki görüntüde AdventureWorksSnaphot database inin Fiziksel disk üzerindeki yeri gösterilmiştir.

Yukarıdaki görüntüde 1 numaralı boyut aslında AdventureWorks Source veritabanının boyutudur. 2 numaralı boyut ise AdventureWorksSnaphot ının Sparsefile dosyasının boyutudur. Önceki yazımda da belirtmiştim Sparse File da Aşağıdaki görüntüdeki gibi sadece Source database de değişen page lerin önceki hali bulunacaktır.

Snapshot veritabanını açtığımız zaman Source da bulunan Table, Views, Stored Procedures vb gibi öğelerin tamamı aynı şekilde bulunmaktadır. Aşağıdaki görüntüde olduğu gibi Source database olan tabloların aynısını Snaphot veritabanınından da görüntülenebilmekte ve Select çekilebilmektedir.

Snapshot lar Administrator hataları konusunda da etkili olduğunu söylemiştim. Örneğin yanlışlıkla bir tabloyu tamamen silme veya tabloyu truncate etme gibi hatalar Administrator hatalarına girmektedir. Örnek olarak AdventureWorks database inden DBO şeması altındaki 1 numaralı karede görünen AWBuildVersion tablosu drop ediliyor. Script çalıştıktan sonra Tables Sekmesi yenilendiği zaman aşağıda 2 numaralı görüntüde göründüğü gibi AWBuildVersion tablosu AdventureWorks Source database inden silinmiştir.

Bu hata kritik veritabanlarında çok su götürür 🙂 Bu hatadan dönmek için Snapshot veritabanını kullanıyoruz. Aşağıdaki gibi Snapshot veritabanında dbo şemasının altında bulunan AWBuildVersion tablosunu kullanarak AdventureWorks database inde dbo şeması altında AWBuildVersion tablosunu oluşturup datasını insert ediyoruz. Select * into komutu create + insert işlevini görüyor. Scripti çalıştırdıktan sonraki ekran görüntüsü aşağıdaki gibidir. Kırmızı çizgiyle belirtildiği gibi Drop edilen Table datasıyla beraber geri döndürülmüştür.

Benzeri bir örnek daha yapalım daha kalıcı olması açısından. Herhangi bir tablonun verilerini silelim ve tekrardan Snapshot dan döndürelim.  Aşağıda 1.1 numaralı görüntüde belirtildiği gibi AdventureWorks database inden Production Şemasının altındaki BillOfMaterials tablosu delete ediliyor. Tabloya aynı anda Select count çektiğimiz zaman yukarıdaki 1.2 numaralı aşağıdaki görüntüden de görüldüğü gibi 0 kayıt çekilmektedir.

Bu Administrator hatasından dönmek için yine Snapshot veritabanını kullanıyoruz. Yukarıda 2.1 numaralı görüntüde olduğu gibi Snapshot veritabanının aynı şema ve tablosunu source database deki ilgili tabloya insert yapıyoruz. Aynı şekilde Select Count çektiğimiz zaman 2.2 numaralı görüntüde göründüğü gibi aynı sayıda satır kayıt insert edilmiştir.

Son olarak Snapshot veritabanından yine bir administrator hatası yapıp bu defa Snaphot veritabanını Restore yapıyoruz. Böylece AdventureWorks database i Snapshot alınırken ki haline geri dönmüş oluyor. Production Şemasının altındaki BillOfMaterials tablosunun datalarını siliyorum aynı anda da Sales şemasının altındaki SalesOrderDetail tablosunu drop ediyorum. Ekran görüntüsü aşağıdaki gibidir. Production Şemasının altındaki BillOfMaterials tablosunun dataları silindiği gibi Sales şemasınun altında da SalesOrderDetail tablosu drop edilmiş görünmemektedir.

Source Veritabanından çok sayıda değişiklik yaptık bu değişiklikler hep Sparse File a yazıldığını söylemiştik. Aşağıdaki görüntüde Sparse file ın son hali görünmektedir. 1. numaralı orjinal boyut değişmemişken 2 numaralı asıl Sparse file ın boyutu artmıştır. Bunun sebebi de dediğim gibi Source database de yapılan tüm değişikliklerin Snaphot alınırken ki halleri buraya yazılır. Böylece Kullanıcı Snapshot dan veri okurken değişmemiş datayı Source dan okurken Değişmiş güncellenmiş data olursa Güncellenmeden önceki halini Sparse File dan okur. Sparse File da her zaman Snapshot alınırken ki datalar tutulur.

Şimdi belli anda aldığımız Snapshot dan geri dönelim. Geri dönerken demin yaptığımız örneğe istinaden Production Şemasının altından BillOfMaterials, Sales Şemasının altındaki SalesOrderDetail tablosuna Select çekiyoruz. Aşağıdaki görüntüdeki gibi bu tablolar eski haline dönmüştür. AdventureWorks database i Snapshot dan Restore edilmiştir.

 

SQL Server 2008 Database Snaphot Restore Kodu
restore database  AdventureWorks from database_snapshot='AdventureWorksSnaphot'

 

Böylece bir yazımın daha sonuna gelmiş bulunmaktayım. Bir sonraki yazıda görüşmek dileğiyle Esen Kalın…

 

Oracle Exadata SQL Server Goldengate Weblogic EBS ve Linux konusunda aşağıdaki konularda 7×24 Uzman Danışmanlara yada Eğitimlere mi İhtiyacınız var [email protected] adresine mail atarak Bizimle iletişime geçebilirsiniz.

– Oracle Veritabanı Danışmanlığı
– Oracle Veritabanı Bakım ve Destek
– Exadata Danışmanlığı
– Exadata Bakım ve Destek
– SQL Server Veritabanı Danışmanlığı
– SQL Server Veritabanı Bakım ve Destek
– Goldengate Danışmanlığı
– Goldengate Bakım ve Destek
– Linux Danışmanlığı
– Linux Bakım ve Destek
– Oracle EBS Danışmanlığı
– Oracle EBS Bakım ve Destek
– Weblogic Danışmanlığı
– Weblogic Bakım ve Destek
– Oracle Veritabanı Eğitimleri
– Oracle VM Server Danışmanlığı
– Oracle VM Server Bakım ve Destek
– Oracle EPPM Danışmanlığı
– Oracle EPPM Bakım ve Destek
– Oracle Primavera Danışmanlığı
– Oracle Primavera Bakım ve Destek
– Oracle Eğitimleri
– SQL Server Eğitimleri
– Goldengate Eğitimleri
– Exadata Eğitimleri
– Linux Eğitimleri
– Oracle EBS Eğitimleri
– Oracle VM Server Eğitimleri
– Weblogic Eğitimleri
– Oracle EPPM Eğitimleri
– Oracle Primavera Eğitimleri

About Mehmet Salih Deveci

I am Founder of SysDBASoft IT and IT Tutorial and Certified Expert about Oracle & SQL Server database, Goldengate, Exadata Machine, Oracle Database Appliance administrator with 10+years experience.I have OCA, OCP, OCE RAC Expert Certificates I have worked 100+ Banking, Insurance, Finance, Telco and etc. clients as a Consultant, Insource or Outsource.I have done 200+ Operations in this clients such as Exadata Installation & PoC & Migration & Upgrade, Oracle & SQL Server Database Upgrade, Oracle RAC Installation, SQL Server AlwaysOn Installation, Database Migration, Disaster Recovery, Backup Restore, Performance Tuning, Periodic Healthchecks.I have done 2000+ Table replication with Goldengate or SQL Server Replication tool for DWH Databases in many clients.If you need Oracle DBA, SQL Server DBA, APPS DBA,  Exadata, Goldengate, EBS Consultancy and Training you can send my email adress [email protected].-                                                                                                                                                                                                                                                 -Oracle DBA, SQL Server DBA, APPS DBA,  Exadata, Goldengate, EBS ve linux Danışmanlık ve Eğitim için  [email protected] a mail atabilirsiniz.

Leave a Reply

Your email address will not be published. Required fields are marked *