Etiketler: | Kategoriler: Smart TV Application Development Emrah Uslu | 31.10.2011 15:39

Haftasonu evde internete bağlı Samsung televizyondaki uygulamalardan Youtube ile müzik dinlerken <<Televizyonların uygulama geliştirme ortamları nasıldır acaba>> diye düşündüm. Akşamında beyin takımı ile konuşurken tesadüfen yine bu konu açıldı ve ardından ufak bir deneme yapmak için araştırmaya giriştim.

Literatürü ve platformu farklı olsa da bir web geliştiricisinin kolaylıkla adapte olabileceği bir ortam söz konusu. Buyrun :

  • Mimari, .NET Framework ile benzer rolde bir çatı üzerine kurulu : AppEngine
  • Uygulamaların yüklenmesi, kaldırılması ve diğer işlemler için Application Manager kullanılıyor.
  • Uygulama ile ilgili tüm ayarlar, config.xml dosyasında yer alır. Xml tabanlı bu dosyada yer alan çeşitli xml etiketleri ile uygulamanın tam ekran mı çalıştırılacağı, genişlik ve yüksekliği, versiyonu vb. bilgiler, uygulama bir televizyona kurulurken kullanılır. config.xml, uygulamanın root klasöründe yer almalıdır.
  • Yazılım geliştirme ortamı için Samsung Smart TV Software Development Kit (SDK) indirilip kurulmalıdır. Uygulamanın yapısal görüntüsü için html, görsel dizaynı için css, davranışlarını programlamak için javascript dosyaları hazırlanır.
  • Bir uygulama çalıştırıldığında AppEngine önce config.xml dosyasına bakar ve gerekli konfigürasyon bilgilerini alır, güncel bir versiyon var mı diye kontrol eder. Ardından programın giriş noktası index.html dosyasına bakar.

       

  • SDK'da sunulan hazır javascript plugin kütüphanelerinden faydalanarak televizyon kanalları dışında video yayını yapmak, ses açmak, imaj galerisi hazırlamak, dosya sistemi ile çalışmak, kumadadan yapılan girişleri yakalamak oldukça kolay.
  • Uygulamanın yazılım geliştirme sürecinde test yapmak için internete bağlı bir Samsung Smart TV olması lazım. Lokal yada uzakta yer alan Apache sunucusu üzerine dağıtılan kodları, televizyona geliştirici logini olarak yüklemek mümkün. Bu işlemi 1 defa yaptıktan sonra "Senkronize Et" diyerek kodları doğrudan televizyon üzerinde test edebilirsiniz. Programı televizyona yayınlamadan önce SDK ile gelen ve görsel editörden kullanılabilen Smart TV Emülatör kullanılarak da test yapılabilir.
  • Bir Smart TV uygulaması scene'lerden oluşur. Her scene, bir web sayfası gibi düşünülebilir. Scene üzerinde Button, DatePicker, CheckBox gibi hazır komponentler, görsel editörde Component Library'den sürükle-bırak yöntemiyle kullanılabilir.
  • Bunların haricinde Application Manager ve AppEngine çatısı, üyelik sistemi için Single Sign On (Tek oturum açma) altyapısına destek vermektedir. Bu sayede televizyondan uygulamayı kullanırken bir defa login olup, uygulamayı daha sonra kullandığımızda tekrar login olmamıza gerek kalmamaktadır. Bütün uygulamaların üyelik sistemi Samsung Smart TV'de bağımsız bir ekrandan yönetilir.
  • Uygulama geliştiriciler kaynak olarak SDK'yı kurduktan sonra menüdeki HELP'den faydalanabilirler. Bunun yanında aşağıda paylaştığım Documents linkinde bulabileceğiniz 100 sayfalık App Development Guide for Samsung TV, detaylı başvuru kaynağı olarak kullanılabilir.

Kaynaklar

SDK : http://www.samsungdforum.com/Devtools/Sdkdownload

Documents : http://www.samsungdforum.com/upload_files/files/guide/data/html/documents2.html

Tutorial : http://www.samsungdforum.com/upload_files/files/guide/data/html/tutorials2.html

Developer : http://developer.samsung.com/home.do

Spec & Feature : http://www.samsungdforum.com/Devtools/Spec

Etiketler: , | Kategoriler: Etkinlik Emrah Uslu | 25.10.2011 11:05

Bugün size yeni bir topluluğu tanıtmak istiyorum. Yazarlık, sunumlar vb. yollarla katkı verenlerden birisi olduğum topluluğun İstanbul tanıtım etkinliği, 21 Ekim 2011 Cuma günü Microsoft ofisinde gerçekleştirildi. Veritabanı yöneticisi, iş zekası uzmanı, yazılım geliştirici, proje geliştirme uzmanı, CIO, çözüm mimarı, sistem yöneticisi gibi şirketlerin IT departmanlarında farklı katmanlarda çalışan 120'den fazla katılımcı etkinliği dinlemek üzere hazır bulundu. Toplam 9 sunumun yapıldığı lansman, çıkışta katılımcılardan aldığım geri bildirimlere göre oldukça faydalı geçti.

 

SQL Server Öncüleri, küresel olarak faaliyet gösteren SQL PASS topluluğunun Türkiye şubesi olarak çalışmaktadır. Sql ve çevresindeki teknolojiler için Türkçe içerik üretme hedefinde olan topluluk, bu lansmanda akılları ve kalpleri kazandı. Bu güzel başlangıç, topluluktaki herkese daha güzel işler çıkarmak için güç verdi diyebilirim. Aynı zamanda katkıda bulunmak isteyen birçok uzman olduğunu gördüm. Günümüzün çetin çalışma şartlarında gönüllülük esası ile böyle bir iş çıkaran topluluk liderlerini ve katkıda bulunan herkesi tebrik ediyorum. Linkleri hemen aşağıda paylaşıyorum.

http://www.sqlserveronculeri.com

http://www.facebook.com/sqlserveronculeri

   

Etiketler: , | Kategoriler: Sql Server Emrah Uslu | 06.10.2011 15:48

 

Bu yazı, sql server için yedekleme ve kurtarma konusunda kendim için tuttuğum notlardan oluştuğu ve fazla düzenleme yapmadan burada paylaştığım için yazıdaki dilden dolayı özür dileyerek başlayayım. 

Ayrıca okumadıysanız serinin ilk iki yazısına bu linklerden ulaşabilirsiniz :

Backup Restore Planlaması - I

Backup Restore Planlaması - II

RESTORE ile RECOVERY KAVRAMLARI KARIŞTIRILMAMALI

- Restore, bir db'i geri getirmek için çalıştırılan sql sorgusudur.

- Recovery ise db'i tutarlı bir duruma getirme sürecidir. Bunun anlamı, commit olmuş transaction'lar diske yazılır, başlamış ama bitmemiş transaction'lar rollback edilir. Sonuçta elde sadece commit olmuş transaction'ların olmasıdır.

- Sql Server her yeniden başlatıldığında recovery işlemi otomatik olarak gerçekleşir. Açılırken sql'in son olarak nasıl kapatıldığı bilinmez : Güç kaynağının kesilmesi, sql'in aşırı yüklenmeden kitlenmesi, makinenin restart edilmesi yada normal bir şekilde durdurulmuş olabilir. Mesela elektrik kesilmesinin ardından sql server yeniden başlarken gerçekleşen recovery sürecinde, tamamlanmış transaction'ların dahil edilir, tamamlanmayanların ise remove edilir.

- Aynı zamanda bir restore işleminin son adımı recovery'dir. Restore komutu, recovery'nin gerçekleşip gerçekleşmeyeceğini içerir. Eğer recovery, o restore işlemi için gerçekleşmezse, bir differential backup yada log backup restore edilebilir. Ancak restore komutu ile birlikte recovery çalıştırılırsa artık yeni bir restore işlemi yapılamaz ve database online konuma getirilir. Burada anlatılanlar, Sql Server Management Studio ile restore işlemi yaparken Options - Recovery State kısmında RESTORE WITH RECOVERY ve RESTORE WITH NORECOVERY olarak görülebilir.


RECOVERY MODELLERİ KARŞILAŞTIRMAK

i) Full Recovery Model

- Bütün data modifikasyonlar��nı tutar.

- En yüksek veri korumayı sağlar

- En büyük log dosyası boyutuna sahiptir.

- Bu modelde bütün backup işlemleri kullanılabilir.

- Birçok OLTP sistem ve iş-kritik uygulamaların db'leri Full Recovery Model'i kullanır; çünkü veri kaybına tahammülleri yoktur.

Not : İlk transaction log backup'ı ancak bir tane full database backup alındıktan sonra alınabilir.

ii) Bulk-Logged Recovery Model

- Bazı db işlemleri, log dosyasında minimum yer kaplar. Bu sayede bu işlemler daha performanslı çalışır.

- Bu işlemlere örnek olarak şu sorgular gösterilebilir : BCP, BULK INSERT, SELECT INTO, CREATE INDEX, ALTER INDEX REBUILD, and DBCC, DBREINDEX.

- Mesela büyük miktarda bir data import s��rasında bütün insert/update işlemlerini loga yazmak yerine yeni gelen extent'lerin yerlerini ve değişen extent'lerin adreslerini loga yazar. Sonuç olarak bu bulk import işlemi daha hızlı çalışır. Ne zaman ki bir transaction log backup alınır, log'a yazılan extent başlangıç ve bitiş noktalarına göre sql server data dosyasına gider ve ilgili datayı transaction log'a yazar.

- Aynı zamanda bu durumda restore işlemi için zamanda istenen tarih/saate geri dönne imkanı yoktur.

- Olası bir data dosyasının zarar görmesi senaryosunda transaction-log'dan restore işlemi yapıldığında bulk işlemin datasını data dosyasından alamayacaktır.

- Full backup ve transaction log backup ardından bulk işlem yapılır ve data dosyası bozulursa bulk işlemden sonrasına geri dönmek mümkün değildir. Tail log backup alınamaz; çünkü data dosyasına ihtiyaç vardır ama data dosyası erişilemez durumdadır. Bu tarz veri kayıplarının önüne geçmek için yapılabilecek olan şey, bulk işlemin arkasından transaction log backup almaktır.

- Database Admin (DBA), Full Recovery Model'daki db'de büyük bir bulk işlem yapmak için kısa süreli db'nin durumunu Bulk-Logged'a çekebilir.

- OLAP db'lerinde bu model tercih edilebilir. Sadece geceleri bulk data aktarımı yapılır ve hemen arkasından bir backup alınır ve gün içinde bir daha değişiklik gerçekleşmez. Böylece data bozulursa eldeki backup'dan geri dönülebilir.

iii) Simple Recovery Model

- Bir işlem, transactionlar log'da, sonraki checkpoint işlemi gerçekleşene kadar saklanır, ardından truncate edilir.

- Transaction log-backup alınmaz. Dolayısıyla transactional replication ,mirroring, log shipping gibi işlemlere izin verilmez.

- Test ve development amaçlı kullanılabilir.

 

BACKUP ve RESTORE İŞLEMLERİ İÇİN GEREKLİ İZİNLER

Backup için minimum

Server role: none

DB role: db_backupoperator

restore için minimum

Server role: dbcreater

DB role: db_owner


RESTORE SÜRECİ

Transaction Mark : begin Transaction komutu ile birlikte With Mark TranName kullanılıp transaction-log'da bir nokta işaretlenebilir ve daha sonra Transaction Log'dan restore yapılırken bu noktanın adını vererek geri dönülebilir.

- Bu bilgi msdb veritabanında logmarkhistory tablosunda durur.


Manuel Recovery

RESTORE DATABASE [TestDb2] WITH RECOVERY

Yukarıdaki sql komutu ile restoring modda olup daha fazla restore yapılmayacak olan db'ler recovery edilip tutarlı hale getirilebilir.

 

Restore with standby

Database'i read-only moda al. Uncomitted transaction'ları geri al (undo). Ancak geri alınan bu transaction'ları bir standby dosyasında sakla. Böylece istediğim zaman bu transaction'ları geri yükleyebileyim.

 

Kaynak : Wrox SQL Server 2008 Administration, MSDN

 

Etiketler: , | Kategoriler: Sql Server Emrah Uslu | 06.10.2011 15:27

 

Bu yazı, sql server için yedekleme ve kurtarma konusunda kendim için tuttuğum notlardan oluştuğu ve fazla düzenleme yapmadan burada paylaştığım için yazıdaki dilden dolayı özür dileyerek başlayayım.

Ayrıca okumadıysanız serinin ilk yazısına aşağıdaki linkten ulaşabilirsiniz.

Backup Restore Planlaması - I

Sql Server çok çeşitli backup süreçlerine sahiptir. Bunlar tek başlarına yada bir arada kullanılabilirler. Aynı zamanda backup sırasında database online ve kullanıcılara açık olabilir. Ayrıca sql server eş zamanlı olarak 64 backup device'ını destekler. MS Sql Server'da alternatif olarak şu backup çeşitleri bulunmaktadır :

Full Backup

- Transaction log dahil bütün verinin kopyası alınır.

- Restore edildiğinde backup alınan tarih/saate döner.

- Bütün backup stratejileri için alınması zorunlu olan backup çeşididir.

- En temel backup'dır ve bazen diğer backup'ların restore edilmesinden önce ilk olarak restore edilmesi gerekir.

- Full backup'dan restore yapıldığı zaman bütün database dosyaları (mdf, ldf, ndf's) restore edilir. Ardından database online olur ve transaction'lar açısından tutarlı konumdadır.

 

Partial Backup

- 2005 versiyonunda geldi.

- Veritabanının sadece değişen parçaları için backup alınmasının bir yoludur.

- Bu, backup alınma zamanını ve backup boyutunu düşürür.

- Primary filegroup ve read-write filegroup'ların bir kopyasıdır.

- Bu backup tipinin avantajlarından faydalanmak için değişmeyen referans dataları yada artık arşiv olmuş transactional dataları (partial table mantığı ile) bir filegroup'ta toplamak ve bu filegroup read-only olarak işaretlenmelidir.

- Partial backup sırasında primary filegroup'un ve read/write filegroup'ların backup'ı alınır. Optional olarak read-only filegroup'lar dahil edilebilir. Günde, haftada yada ayda bir kez de olsa, read-only filegroup'ların da backup'larını almak lazım.

- Özellikle read-only datası büyük olan bir db'de backup alınma süresini kısaltır

 

File/FileGroup Backup

- Veritabanındaki file yada filegroup'ların kopyasıdır.

- Çok büyük miktarda veriye sahip ve full backup alınması çok anlamlı olmayan db'ler için kullanılır.

- Eğer read/write files yada filegroups'ların backup'ı alınıyorsa, olası restore işlemi için log backup'da alınmalıdır.

- Bu backup çeşidinin dezavantajı şu olabilir : Büyük miktarda dataya sahip veritabanında çok sayıda file/filegroup olması olasıdır ve bunların bakımları, saklanması sorun teşkil edebilir. Aynı zamanda restore ederken bunların her birini restore etmek gereklidir ki bu da çok sayıda adım sonrasında restore işleminin tamamlanması anlamına gelir.

Not : Bir tablo ve o tabloya ait bütün indeksler aynı backup içerisinde yer almalıdır. Sql Server bunu kontrol eder ve bu kural ihlal edildiğinde hata verir. File/Filegroup backup kullanacaksak, index'lerin lokasyonu için backup plan'ını hesaba katmak gerekir.

 

Differential Backup

 - En son full backup'ın ardından değişen bütün dataların saklandığı kopyadır.

- Bir kayıta ait değişen datanın sadece son versiyonu saklanır. Değeri 5 olan bir veri full backuptan sonra sırasıyla 3,6,9 olarak update edilmişse differential backup içerisinde ilgili kayıtta sadece 9 verisi bulunur.

- En son full backup'a differential'ın base'i denir.

- Base ne kadar önceden alınmışsa, differential'ın boyutu o kadar büyüktür.

- Sql Server 2008 değişen extent'leri takip eder (bitmap page ile) ve bunların backup'ını alır.

Not : Sql server veriyi page'lerde tutar. Page 8k'lık veri saklayan en küçük veri saklama birimidir. Yani 1mb'da 128 page bulunur.

Bununla birlikte extent, 8 tane page'in bir araya gelmesiyle meydana gelen veri saklama birimidir. Yani 1 mb'da 16 extent bulunur.

Yukarıdaki şemada 24 tane extent var. Differential backup alındığı sırada bunların 6'sındaki data değişmiş. Değişmeyen extent'ler 0, değişen extentler 1 ile işaretlenerek bir differential bitmap page oluşturulur. Differential backup sırasında bu bitmap page'e göre hangi extent'lerin backup'ının alınacağına karar verilir.

- Differential backup'lar kümülatiftir.Pazar gecesi full backup aldıktan sonra Pazartesi akşam differential backup alırsak, bu Pazar gecesinden itibaren gerçekleşen bütün değişiklikleri içerir. Salı akşam bir differential backup daha alırsak, bu 2.differential backup yine Pazar gecesinden itibaren meyadana gelen bütün değişiklikleri içerecektir. Restore etme ihtiyacı olduğunda önce en son full backup restore edilir, ardından o full backup'dan sonra alınan en son differential backup restore edilmelidir. Ardından da son differential backup'dan sonra alınmış eldeki transaction log backup’lar restore edilir. Bu şekilde hızlı bir biçimde kurtarma operasyonu tamamlanır.

 - Full database backup'dan sonra ne kadar miktarda datanın değiştiğine göre differential backup'dan faydalanma oranı değişir. Değişen kayıtlar, veritabanındaki kayıt miktarına yaklaşırsa o zaman yeni bir full backup alıp, ardından yeni bir differential ile devam etmek daha sağlıklı olacaktır.

 - Differential'ın bir diğer avantajı ise şöyle açıklanabilir. Bir grup veri, tekrarlayan bir job ile birlikte belirli aralıklarla değişiyorsa transaction log'un içerisinde bu değişikliklerin hepsi saklanır ve olası bir restore ihtiyacında bütün bu değişiklikler arka arkaya çalıştırılarak değişen verilerin en son değerleri elde edilir. Bu uzun süren bir restore süreci gerektirebilir. Eğer elde bu sürece ait differential backup'lar varsa, son diff. backup restore edilerek doğrudan verilerin son hali elde edilmiş olur.

  

Partial Differential Backup

 - Differential backup'la aynıdır. Sadece partial backup'daki datalarla eşleşir ve partial backup içerisindeki değişen verileri takip edip kayıt eder. Restore etmek için partial backup'a ihtiyaç vardır.

 - Sql Server Management Studio ve Maintenance Plan Wizard tarafından desteklenmez; sql script ile gerçekleştirilir.

  

File Differential Backup

- Alınmış en son file yada filegroup backup'dan sonra gerçekleşen değişikliklerin kopyasıdır.

- read/write files yada filegroups için alınan differential backup'dan sonra transaction-log backup alınması gerekir.

- Aynı şekilde file differential backup restore edildikten sonra transaction log backup'ın da restore edilmesi gerekir.

- File backup ve file differential backup, restore sürecinin kompleksliğini artırır.

 

Copy-only Backup

- Genellikle alınan backup'lar sonraki backup/restore serilerini etkiler, başlangıç-bitiş noktaları işaretler. Bunlar gerçekleşmeden mesela test yada uygulama geliştirme amaçlı backup, log backup almak için copy-only backup kullanılabilir.

- Dolayısıyla normal düzendeki sql backup/restore senaryolarının dışında backup çeşididir.

- Full backup ve transaction log backup için kullanılabilir.

- Full backup, differential backup'ları resetlerken copy-only full backup resetlemez.

- Transaction Log Backup, log'u truncate ederken, copy-only transaction log backup log'u truncate etmez ve aynı zamanda sonraki normal transaction log backup'ı etkilemez

 

Log Backup

3 çeşit olarak sayılabilir.

a) Pure Transaction-Log Backup

 - Bütün veri modifikasyonları, burada tutulur.

- En iyi veri koruma şeklidir.

- İstenen ana geri dönebilmeyi sağlar.

- Recovery model, Full yada Bulk-Logged olması durumunda alınabilir. Recovery mode Bulk-logged olarak set edildiyse, bulk işlemler log dosyasına yazılmaz. Simple recovery mode için alınması zaten anlamsızdır.

LSN=Log Sequence Number              SAN=Storage Area Network            WAL=Write Ahead Logging - this is a protocol

 b) Bulk Transaction-Log Backup

 - Recovery model, bulk-logged olduğunda alınan transaction-log backup çeşididir.

 - Syntax olarak pure transaction log backup ile farkı yoktur.

 - Sql server otomatik olarak db'nin o anki recovery model'ini detect eder.

 - Bu şekilde alınan bir log backup, zamanda istenen noktaya geri dönmeyi sağlamaz.

 - Bulk işlemlerin performansını artırmak için kısa süreliğine db'nin recovery modelini Bulk-Logged'a çekmek en doğru tercih olacaktır.

 - Transaction-log backup sırasında eğer bulk-loglanmış data varsa sql server bu datayı backup dosyasına dahil eder, bu yüzden log backup dosyasının boyutu küçük olmayacaktır.

 - Transaction log backup, restore edilmeden önce, eldeki en son full backup, ardından da varsa en son differential backup restore edilir. Bunların ardından full yada varsa differential backup'dan sonra alınmış transaction log backup'lar sırasıyla restore edilebilir.

 c) Tail Transaction-Log Backup

 - Veritabanı bozulduktan sonra alınabilecek transaction-log backup çeşididir.

 - Her gece full backup alınıyor, her saat başı transaction log backup alınıyor. Data dosyası saat 16.30'da bozuldu diyelim. Önceki geceye ait full backup ve ardından eldeki bütün transaction log backup'lar arka arkaya restore edildiğinde db'nin saat 16.00'daki durumuna geri dönülür. Ya 16.00 ile 16.30 arası? Data dosyası bozulmuş olsa da log dosyası hala sağlam. Bu durumda log dosyasından son bir transaction log-backup alınabilir. Bu da tail transaction log backup olur. Bu backup, son alınan transaction log backup'ın ardından gelen transaction'ları içerir. Tail backup'ın da restore edilmesinin ardından db, bozulduğu ana geri dönmüş olur.

 - Buradaki risklerden birisi, restore işlemlerine başlamadan önce tail log backup alınmasının unutulmasıdır. Aksiyon alınmadan önce tail log backup alınması gerekir.

 - Eğer db, bulk-logged recovery model'da ise ve bununla birlikte bulk işlemler gerçekleşmişse , tail transaction-log backup alınamaz. Çünkü bu durumda tail transaction-log backup, bulk işlemler sonucunda gerçekleşen data modifikasyonlarını data dosyasından elde etmek isteyecek; ancak data dosyamız bozuk olduğu için bunu gerçekleştiremeyecektir.

 - Management Studio üzerinden Tail log backup almak için Master db'ine yada başka bir database'e gidip bu işlemi yapmak lazım. Çünkü bizim database'imiz erişilmez durumdadır. Bunu yapmak için transaction-log back seçilir ve ardından aşağıda yer alan

            Backup the tail of the log and leave the database in restoring mode

 checkbox'ı seçilir. Bunun ardından database restoring mode'da bırakılır ve arkasından restore işlemleri sırayla yapılır, son olarak bu alınan tail log backup restore edilir.

 

 Attach/Detach

 Sql server'ı kapatıp, data dosyalarını kopyalamak ve sql server'a bağlanıp bunları ataçlamak.

 

 Backup Compression (Yedek Dosyasını Sıkıştırma)

 - Daha hızlı backup alma süreci ve daha küçük backup dosyası sağlar.

 - Bu işlem ram ve cpu harcar. O yüzden resource governor'dan ilgili administration işlemi için ram ve cpu sınırlaması yapılabilir.

 - Alınmış normal backup rar'landığında da %90'a kadar sıkıştırma yapılır.

 

Bu serinin sonraki yazısına aşağıdaki linkten ulaşabilirsiniz.

Backup Restore Planlaması - III

 

Kaynak : Wrox SQL Server 2008 Administration, MSDN

 

Etiketler: , | Kategoriler: Sql Server Emrah Uslu | 06.10.2011 14:17

 

Bu yazı, sql server için yedekleme ve kurtarma konusunda kendim için tuttuğum notlardan oluştuğu ve fazla düzenleme yapmadan burada paylaştığım için yazıdaki dilden dolayı özür dileyerek başlayayım.

Şirketler iş süreçlerinin devamlılığı için veritabanı yönetim sistemleri üzerinde Yüksek Erişilebilirlik (High Availability) çözümleri uygularlar.

  - Failover Cluster
  - Database Mirroring
  - Transaction Log Shipping
  - Replication

Böylece canlı sql sunucusunun bir sebeple taleplere yanıt verememesinin ardından stand by bir sunucu üzerinde iş süreçlerinin devam etmesi sağlanır. Yüksek erişilebilirlik çözümleri datanın online olmasını sağlamasına rağmen iş verisini korumak için bir backup stratejisinin varlığı zorunludur. Mesela geliştirici yada admin kaynaklı veri hatası, aşırı yüklenmeden dolayı veritabanının erişilemez olması gibi durumlarda admin, backup'dan recover ederek db'nin tutarlı bir konuma geçmesini sağlar.

VERİTABANININ BOZULMA SEBEPLERİ

Hardware failure : High availability çözümleri var; ancak bir diskin I/O failure vermesi ve datayı bozması gibi yüksek erişilebilirlik çözümlerinin devreye giremediği durumlar gerçekleşebilir.

User Error : Yanlışlıkla data silmek, delete'e where eklememek, tabloyu drop etmek, test sunucusunda sanıp, canlıda değişiklik yapmak, transaction kullanmamak.

Not : Bazı tool'lar transaction log'ları okuyup istenen transaction'ları restore edebiliyor (Log Explorer, ApexSQL vb.)

Application Failure : Uygulamadaki bir bug

Software Failure : İşletim sistemi çökebilir. Driver'lardan biri bozulabilir.Bundan korunmak için service pack ve patch'leri takip etmek ve kurmak gerekir. Bu sql yada makineyi restart etmeyi gerektirebilir ancak high availablility çözümünün devreye girmesindense planlanmış kısa bir bakım tercih edilebilir. Desteklenen ve güncellenmiş driver'lar makinenin ve dolayısıyla makine üzerinde çalışan uygulamaların performansını artırır.

Haddinden Fazla Yetki : Sql server login'lerini kullanan uygulamalar ve kişiler, olması gerkenden daha fazla yetkiye sahip olabilirler. Mesela dbowner, sysadmin vb. gibi yetkilerle bug veya free-form sorgu ekranında yanlış tablo silinebilir. DBA'ler de normal kullanıcı ve sysadmin kullanıcısını ayrı ayrı kullanırlarsa onlar da "ahh, yanlış sorguyu yanlış yerde çalıştırdım" dan sakınmış olurlar.

Lokal Felaket : Data Center'ın zarar görmesine sebep olacak deprem, sel vb. felaketler için farklı coğrafyalarda yüksek erişilebilirlik çözümleri ve backup merkezleri olmalıdır. Bütün bu durumlar için kurumsal bir plan yapilmalıdır :

  - High Availability (Yüksek erişilebilirlik)
  - Backup/Restore (Yedekleme/Geri Yükleme)
  - Disaster recovery (Felaket Kurtarma)

Bu planları hayata geçirmek için risk/fayda analizi yapmak lazım. Downtime süresi ve bize potansiyel maliyeti, gerçekleşen olayla ilgili bize diğer potansiyel maliyetleri, üretilecek çözümün bize maliyeti hesaba katılmalıdır. Bunun için riskler, maliyet ve faydalar için araştırma ve ardından dokümantasyon yapılmalıdır. Burada risk yönetiminin karar vericisi DBA (veritabanı yöneticisi) değildir, şirketin yönetimidir. Ardından DBA, oluşturulan planı hayata geçirmeli ve düzenli aralıklarla test etmelidir.

 

BACKUP / RECOVERY PLAN

1. İş Gereksinimlerini Analiz Et

  • Her uygulamanın ve veritabanının sahibi kim
  • Bu veritabanının amacı ne
  • Bu uygulama / veritabanı için kabul edilebilir downtime nedir
  • Değişen veriler hangileridir ve ne sıklıkla değişirler
  • Ne kadarlık bir veri kaybı kabul edilebilir (Bu zamanla değişebilir, o yüzden backup plan ve stratejileri zamanla güncellenmelidir)
  • Veritabanının boyutu ve büyümesi nedir
  • Bu veritabanı için Maintenance Window nedir? (index, dbcc, backup, sistemin online response'unu etkileyebilir. Bunların zamanlarını kontrol et)
  • Bu veritabanı için belli bir bütçe var mı?
  • Bir veritabanı hatası gerçekleştiğinde kimin haberi olacak, nasıl haberi olacak 

 

2. Veritabanlarını Kurtarma Kriterlerine Göre Kategorize Et

Kritiklik : mission-critical (article, statistic, sales tabloları gibi)

Size : Büyük veritabanlarının, küçüklere göre backup ve restore süreleri daha uzun olacaktır. Bu süre filegroup backup'ı ve diğer yöntemlerle azaltılabilir.

Volatility : Büyük miktarda veri değişimi alan veritabanlarının, aktif olmayan veritabanlarına göre farklı bir plana ihtiyaçları vardır.

Bu 3 kritere göre hangi veritabanının, hangi kategoriye gireceğine karar verilir; ardından planlar bu gruplara göre yapılabilir.

 

3. Kategorilere İsim Ver

 Aşağıdakilere benzer, faydalı olabilecek şekilde gruplar isimlendilir.

  • Mission Critical with High Acticity (Yüksek aktiviteli iş kritik)
  • Mission Critical with Low Acticity (Düşük aktiviteli iş kritik)
  • Non-Critical  (Kritik olmayan)  

 

4. Her kategori için aşağıdakilere karar vermek gerekiyor

 a) Recovery Modeli

  • Veri kaybını minimize et (FULL)
  • Bulk load işlemlerinin performansını artır (BULK-LOGGED)
  • Bakım maliyetlerini düşür (SIMPLE)

 b) Backup Planı

Her bir kategoriye giren veritabanı için full backup, belirli periyotlarla alınacaktır. Bunun dışında aşağıdaki kriterler göz önünde bulundurularak diğer yedekleme alternatifleri plana dahil edilmelidir.

  • Belirlenen kategori ve recovery modeline göre
  • İhtiyaç duyulan backup sıklığına göre
  • Backup Güvenlik politikasına göre

 

5. Dokümantasyon yapmak lazım

 Şu ana kadar 2 tane dokümantasyonun hazırlanmış olması gerekiyor.

  • Biri iş gereksinimleri için insanlarla yapılan görüşmelerden ortaya çıkan liste
  • İkincisi ise veritabanı kategorizasyonu ile ilgili olan liste.

Bu 2 doküman haricinde şunların da dokümante edilmesi gerekir :

i) Contact List

Acil durumlarda kimler aranacak, onları kim arayacak, bunların telefon numaraları, mail adresleri, ev adresleri vb. Aynı zamanda ihtiyaç halinde vendor, teknisyen, ulaşım hizmet verenler vb. iletişim bilgileri bulunsa iyi olur.

ii) Karar Ağacı

Hangi durumda ne yapılacağını sırayla ve mantıklı bir şekilde anlatan bir doküman. Stres halindeyken yardımcı olması amacıyla kullanılır.

iii) Recovery'nin Başarılı Kriterleri

Veritabanlarına göre geri dönüşün başarılı olduğundan emin olmak için kullanılır.

iv) Key'ler, backup'lar, yazılım ve donanımların lokasyonu

Makinelerin ip'leri, şifreler, otomatik backup'ların nereye alındığı vb.

v) Infrastructure Dokümantasyonu

İsimlendirme düzeni, dns/network bilgileri vb.

 

6. Planı Onaylamak, Uygulamak ve Test Etmek

Belki işin en zor kısmı budur. Planı hazırlamak yetmez. Çalışmayan bir plan işe yaramayacaktır.

 

7. Backup Hata Alırsa Bundan Haberdar Olun

Düzenli backup alma sürecinin başarılı bir şekilde devam ettiğini, alınan backup'ların kullanılır olduğunu garanti etmek gereklidir.  Eğer süreçte bir hata varsa bundan haberdar olunması gerekir.

Ayrıca dikkat edilmesi gereken bir diğer konu şudur : Db backup işlemi, diğer bakım işlemlerinden sonra alınmalıdır. Index, db shrinking gibi. 

 

Bu serinin sonraki yazılarına aşağıdaki linklerden ulaşabilirsiniz.

Backup Restore Planlaması - II

Backup Restore Planlaması - III

 

Kaynak : Wrox SQL Server 2008 Administration, MSDN