Microsoft SQL Server 2005, günümüzde veritabanları için en yüksek seviye yüksek erişilebilirlik standartları olan clustering cervices, database mirroring, database snapshots, log shipping ve replication özelliklerini standart ve enterprise versiyonlarında herhangi ek bir ücret ödemeye gerek kalmadan sunmasıyla ilk beta versiyonundan beri stabil bir ürün olacağını ispatlamıştı.
Yüksek erişilebilirlik konusunda Oracle tarafında Real Application Clusters (RAC) teknolojisi uygulanabiliyor. Fakat RAC sadece Oracle 10g Standard Edition'da var (Enterprise edition da bu özellik yer almıyor). RAC, otomatik failover özelliğini desteklemesinin yanında, Database Mirroring ile benzeri bir failover senaryosunu 5 saniyeden daha az zamanda gerçekleştiren SQL Server 2005'den daha yavaş kalıyor. Bunun yanında, Oracle 10g'nin bir başka yüksek erişilebilirlik özelliği olan Flashback and Data Guard özelliği 10g Standard edition'da mevcut değil ; bu özelliğe sahip olmak için çok daha fazla para verip Oracle 1g Enterprise Edition satın almalısınız.
SQL Server 2005, veriyi birden fazla sunucuya bölerek erişilebilirliği arttıracak bir başka özellik sunarken Oracle 10g'ye benzeri bir özellik eklemek istediğinizde, opsiyonel olarak sunulan Oracle Partitioning ürününü satın almanız gerekiyor.
Günümüz veritabanı yöneticililerinin en önemli ve belki de birinci görevleri kullanıcıların ve müşterilerin veriye kesintisiz erişimini sağlamaktır. Eğer uygulamaların arkasındaki veritabanları erişilemez duruma gelirse, bu sadece para değil, aynı zamanda itibar kaybı anlamına da gelebilir.
Firmanızın yapısına ve uygulamalarınızın tipine gore değişmek üzere, bu tip servislerin kesintiye uğramasının bedeli çok ağır olabilir. Forrester Research'ın bir çalışması online bir borsa / komisyoncu firması olan eTrade'in 1 saatlik servis kesintisine uğramasının bedelinin 8 milyon dolar olduğunu göstermiştir. DELL'deki 10 saatlik bir kesinti 83 milyon dolara mal olurken, Intel'in 33 saatlik servis kesintisi 275 milyon dolara mal olmuştur. Bu rakamlar sadece maddi kayıplardır, bunların yanında müşteri memnuniyeti ve itibar kaybının değeri bundan çok daha yüksek olabilir.
Çok kritik uygulamaları çalıştıran firmalarda, uygulamalar ve uygulamaları destekleyen veritabanları ve sunucular kullanıcıların uygulamayı kullanmaya ihtiyacı olduğu sürelerde erişilebilir olmak zorundadırlar. Günümüzde büyük şirketlerin hem iş sürekliliği çok daha fazla online işlemlere bağımlı olduğu için birçok firmanın günün 24 saati, haftanın 7 günü ve yılın 365 günü servis erişilebilirliğine ihtiyacı olduğu bilinen bir gerçektir.
İş devamlılığı için yüksek erişilebilir sistemler tasarlamak çok kolay gerçekleştirilebilecek bir hedef değildir, çünkü yüksek erişilebilirliği etkileyen birçok faktör bulunmaktadır. Sadece gerekli yüksek erişilebilirlik teknolojisine sahip olmak yeterli değildir, insan faktörü, organizasyonel faktörler gibi diğer etkenler de yüksek erişilebilirlik senaryolarını etkilemektedir.
Bu yazıda Oracle 10g ve Microsoft SQL Server 2005'in yüksek erişilebilirlik konusunda sunduğu teknolojileri karlılaştıracağız.
Erişilebilirlik Nedir?
Erişilebilirlik, bir sistemin kullanıma açık olduğu zamandır. Erişilebilirlik değeri, % ile ifade edilir. Devamlı, kesintisiz bir şekilde kullanıcılara hizmet verebilen sistemler %100 erişilebilir sistemler olarak anılabilir. Bunun yanında, %100 erişilebilirlik yakalanması çok zor olan bir değerdir ve bu yüzden en yakın pratik değer %99,999'dur. Matematiksel olarak, erişilebilirlik = ((toplam zaman - toplam servis kesintisi zamanı) / toplam zaman)) şeklinde hesaplanabilir.
|
9 sayısı |
Erişilebilirlik Yüzdesi |
Senelik Kesinti |
Bazı firmalar erişilebilirliği "sunucunun erişilebilirliği" şeklinde hesaplasalar da, erişilebilirlik aslında "sunulan servisin kullanıcıların erişimine ve kullanımına açık olduğu zaman" şeklinde hesaplanmalıdır. Bir sunucu servis veremiyorsa, ama kurduğunuz sistemde bu sunucunun rölünü bir başka sunucu karşılayıp operasyonun devamlılığını sağlayabiliyorsa, sistem "erişilebilir" olarak adlandırılmalıdır. Bunun yanında, sunucular hizmet sunmasına rağmen kullanıcılar farklı bir sebepten (ağ sorunları v.b.) dolayı erişim sağlayamıyorlarsa sistem "erişilemez" olarak adlandırılmalıdır.
Erişilebilirliği Etkileyen Faktörler
Kesintisiz erişilebiliriiği etkileyen birçok etken bulunmaktadır. Yüksek erişilebilir operasyonel sistemlerin önündeki en büyük 3 engel, insan, yöntem ve teknoloji faktörüdür.
Kesintisiz iletişim sadece kullanılan teknoloji ile ilgili bir durum değil, aynı zamanda firma hem firmada hem de uzak lokasyonlarda görev yapan çalışanlarınız ile ilgilidir. İş operasyonlarını yürütmek için doğru kişiler ile çalışmak maksimum hizmet erişimlerinde çalışmak için çok önemli bir faktördür. İnsan faktörünü, çalışanlarınızın optimal seviyede uzmanlıkta çalışabilecekleri doğru prosedürler ve kurallar ile birleştirmek, erişilebilrliği arttırmakta diğer bir önemli faktördür.
Erişilebilirlikte İnsan Faktörü
David Patterson'un "A Simple Way to Estimate Downtime" isimli çalışması bizlere servis aksama sürelerinin %53'ünün insan hatası yüzünden olduğunu göstermektedir. "Disaster Recovery Journal" adlı bir diğer araştırma göstermektedir ki, bir firmada oluşan veri kayıplarının %36'sı insan hataları sayesinde olmaktadır.
İnsanlar hata yapabilrler, fakat bu hataları ve hata sonucunda oluşabilecek servis aksamalarını minimize etmek için bir takım prosedürler mevcuttur. İnsanların yaptıkları hatalar temel olarak ikiye ayrılırlar, "kullanıcı hataları" ve "operatör hataları". Eğitim, uygulamalar ile ilgili dökümantasyon ve yazılı prosedürler kullanıcı hatalarını engellemenin en önemli faktörleri arasındadır. Bunun yanında operatör hataları kullanıcılardan çok daha büyük felaketlere sebep açabilir. Örneğin, yanlışlıkla bir tablodan verileri silmek ya da verileri yanlış bir döngü ile hatalı güncellemek tüm servislerin durmasına sebep olabilir. Bu tip operatör hatalarını engellemenin en önemli adımlarından biri yönetimsel kadroları yüksek erişilebilik sağlamanın sorumlulukları ve karmaşıklığı hakkında bilinçlendirmektir. Bunu sağlamanın en temel yolları, eğitim için ayrılan bütçenin arttırılması, operasyonel kılavuzların hazırlanması ve felaketten kurtarma planlarının oluşturulması olarak sayılabilir.
Erişilebilirlikte Yöntem Faktörü
Erişilebilirliği etkileyen bir diğer faktör ise iç operasyonlarımızda kullandığımız yöntemlerdir. Doğru dökümante edilmiş yöntemler sayesinde kesinti zamanını azaltmakla kalmazsınız, aynı zamanda olası bir kesinti durumunda sisteminizi daha hızlı operasyonel hale döndürebilirsiniz.
Doğru yöntemlerle çalışmanın en önemli kurallarından biri yazılı prosedürlerle sistemlerinizi yönetmektir. Rutin operasyonel işlemler için ve farklı felaket senaryoları için kurtarma prosedürleri için yazılı prosedürler oluşturulmalıdır.
Yetersız problem çözüm dökümanı ise erişilebilirliği etkileyebilecek bir başka husustur. Çok genel ortaya çıkan ya da çıkması muhtemel problemler ile iligli adım adım çözüm kılavuzları oluşturulmalıdır. Problem çözüm standartları ilgili dökümantasyon eksikliğinde, firmanızın operasyonlar ve teknik destek bölümleri aynı problem üzerinde tekrar zaman kaybı yaşayacakları gibi, çözüm geliştirmek için izledikleri yolun hatalı olma ihtimali de artar.
Değişiklik yönetimi prosedürleri firmalarda bir uygulamanın yaşam sürecince hem uyguladaki hem de veritabanı şemasındaki değişikliklerini takip etmek için kullanılırlar. Yapılan bir diğer yöntemsel hata da firmaların değişiklik yönetimi prosedürlerindeki ya da bu prosedürlerin işletilmesindeki eksikliklerden kaynaklanan sorunlardır. Değişiklik yönetimi prosedürlerinin bir diğer faydası da yapılacak değişikliklerin test ortamında denenip daha sonra çalışan sistemlere uygulanmasına olanak tanımasıdır.
Yöntemsel hataları elimine etmek için tavsiye edilen adımlardan bir diğeri ise yazılım ve donanımda standardızasyondur. Elinizden geldiğince veri merkezinizde standart donanım ve yazılımlar kullanın. Standart donanım kullanmanız olası bir donanım sorununda sorunlu donanımı benzeri ile çok daha hızlı değiştirmenize yardımcı olacaktır. Benzeri şekilde yazılımlardaki standardizasyon yazılımlara vereceğiniz teknik desteğin ve sorun giderme prosedürlerinin standardizasyonunda önem taşımaktadır.
Planlanan Servis Aksamaları
SQL Server 2005 ve Oracle 10g'nin yüksek erişiliebilirlik alanında sunduğu çözümler ruitn, planlanan sistem bakımları ve planlanmayan sorunlar oluşturğunda servislerin kısa sürede çalışır hale getirilmesi olarak ikiye ayrılabilir.
Sunucu Bakımı İçin Veritabanı Yüksek Erişilebilirlik Çözümleri
Günümüzde sunucular için özel üretilmiş donanımlar güvenilir olmasına ve donanım üreticisi firmaların temel sistem bileşenleri için birçok yedeklemeli sistemler sunmalarına rağmen donanım ve işletim sistemi bakımı ve yükseltmesi kaçınılmazdır.
- Donanım Yükseltmesi ve Bakımı
Microsoft Server 2003'ün RAM ve RAID sürücüleri için hot-swap desteği en temel donanım yükseltmesi senaryolarını destekler : sisteminiz çalışırken sisteminize bellek ve disk ekleme ihtiyacı. Buna rağmen system log'unuzda bir sürücünün çalışmadığı konusunda aldığınız bir uyarıdan sonra işletim sistemi ya da uygulama düzeyinde bir service pack yükleyip sistemi yeniden başlatmanız gerekebilir. Tek sunuculu sistemlerde bu tip bir servis kesintisi "Planlanan servis aksamaları" grubuna girer ve kullanıcılara en az etkisi olacak bir zaman diliminde planlanabileceği için planlanmayan bir servis aksamasından çok daha az rahatsızlık yaratır.
Bununla birlikte, planlamış servis aksamalarının bile büyük sorun yaratabileceği seviyede erişilebilirliğe ihtiyacı olan sistemlerde donanım yükseltmesi ve bakımı, Microsoft Windows Clustering Services ve Oracle'ın RAC servisi ile iş yükü cluster'daki diğer bir sunucuya aktarılarak yapılabilmektedir.
- Veritabanı Bakımı
Yüksek erişilebilir ve etkili veritabanı sistemleri için veritabanı bakımı çok önemlidir. Index'lerin bakımı yapılmalı, performans arttırıcı rutin adımlar atılmalı, yedekler alınmalıdır.
Veritabanı çalışırken veritabanının bakımı yapabilmeniz için SQL Server 2005 birçok SQL Server sistem özelliklerinin, veritabanı çalışrıken (online iken) dinamik olarak değiştirilmesine olanak tanır. Aşağıdaki tabloda online olarak yapılabilecek değişikliklerin bir listesi sunulmaktadır :
|
allow updates |
network packet size |
|
cost threshold for parallelism |
query governor cost limit |
|
cursor threshold |
query wait |
|
default full-text language |
recovery interval |
|
default language |
remote login timeout |
|
index create memory |
remote proc trans |
|
max degree of parallelism |
remote query timeout |
|
max server memory |
show advanced options |
|
max text repl size |
two digit year cutoff |
|
min memory per query |
user options |
|
min server memory |
network packet size |
|
using nested triggers |
query governor cost limit |
Hem SQL Server 2005 hem Oracle 10g ilgili tablo sorgulanırken ya da güncellenirken, indexlerin online olarak yaratılabileceği, yeniden oluşturulabileceği ya da defrag edilebileceği ortamı sunar. Her iki ürün de çalıştırıldıktan sonra sorguları, disk kullanımı gibi verileri inceleyerek veritabanı hakkında bilgi toplayan ve veritabanı yöneticilerine veritabanını nasıl daha performanslı kullanabileceklerine dair tavsiverde bulunan veritabanı iyileştirme araçları sunmaktadır.
Planlanmayan Servis Aksamaları
Hem SQL Server 2005 hem Oracle 10g kendi metodları ve teknolojilerini kullanarak benzer seviyede yüksek erişilebilirlik sunabilmektedir. İki ürünün sunduğu farklı yüksek erişilebilirlik çözümleri, sunucu sorunları ya da veri kayıplarından farklı seviyede koruma sağlarken ürünlerin fiyatları çözümü satın almak, uygulamak ve işletmek için gereken teknoloji anlamında değişiklik göstermektedir.
Veritabanı Kurtarma İçin Yüksek Erişilebilirlik Çözümleri
Veritabanı erişilebilirliği sadece veritabanına bağlantı sağlanması demek değil, aynı zamanda doğru veriilere erişmek demektir. Eğer veritabanındaki veriler zarar görmüşse (örneğin bir kullanıcının bir tabloyu yanlış verilerle güncellemesi sebebiyle), hatayı tanımlayıp orijinal verileri geri yüklemek için gerekli prosedürlerin var olması gerekmektedir.
- SQL Server 2005 - Backup / Point-in-Time Recovery
Yüksek erişilebilirliğin temel bileşenlerinden biri yedekleme ve geri yükleme planına sahip olmaktır. SQL'deki farklı kurtarma modelleri (Recovery Model) loglamanın sunucuya getirdiği yük ile verinin tamamının kurtarılabilmesi arasındaki dengeyi kurmanıza yardımcı olur. SQL Server 2005, 3 değişik kurtarma modeli sunar : Simple, Full ve Bulk-Logged.- Simple Recovery Model : Bu modelde loglamanın getirdiği yük minimumdur. Bunun yanında, bu modelde son yedeğinizden bu yana yapılan değişiklikleri kurtarmanız imkansız hale gelir.
- Full Recovery Model : Simple Recovery Model'in tam tersine, bu modelde veri üzerinde yapılan tüm değişiklikler kaydedilir. Bu model sayesinde yapılan değişiklikler son ana kadar kurtarılabilir. SQL Server varsayılan olarak Full Recovery Model kullanır.
- Bulk-Logged Recovery Model : Bu model yukarıdaki iki modelin arasında yer alır. Bulk operasyonlar (bulk copy ya da SELECT INTO gibi) dışındaki tüm işllemleri kaydeder ve bu tip işlemler haricindeki tüm verinin son ana kadar geri döndürülmesine olanak tanır.
Bir veritabanı kurtarma modeli seçildikten sonra veritabanı yedekleme planına karar vermeniz gerekmektedir. Diske, teybe ya da desteklenen farklı bir cihaza yedek alabilirsiniz. Diske yedek almak, en hızlı yedek alma ve geri yükleme çözümüdür. Sürücü hatalarından korunmak amacıyla yedekler her zaman farklı bir sürücüye alınmalıdır, tercihen veritabanın saklandığı sürücünün bağlı olduğu controller'dan farklı bir denetleyiciye.
SQL Server üç temel tip yedeklemeyi destekler : full, differential ve log backup.
o Full Backup : Bu yedek tipi veritabanın tamamının bir kopyasıdır. Diğer yedekleme modellerini geri yüklemek için de bir başlangıç noktasıdır.
o Differential Backup : Bu yedekleme tipi sadece en son full backup'tan beri değişen veritabanı sayfalarını yedeklemek için kullanılır. Sık differential backup alınması veritabanınızı son haline getirmek için gereken transactional backup'ların sayısını azaltacaktır.
o Log Backup : Bu yedek tipi sadece transaction log (işlem günlüğü)'un yedeğini alır. En son differential backup yüklendikten sonra veritabanını son ana döndürmek için transaction log yedekleri yüklenmelidir.
Transactional point-in-time geri yükleme sayesinde veritabanı herhangi bir zamana geri döndürülebilmektedir. SQL Server 2005 transaction log'u, en son transactional log yedeği alındığı andan itibaren veritabanına yapılan bütün değişikliklerin kaydını tutar. Transactional log'ları kullanarak SQL Server veritabanını herhangi spesifik bir zamana döndürebilirsiniz. Örneğin, saat 04:00'da bir uygulama hatası oluşup veritabanındaki verilerin bozulmasına sebep olduysa, SQL Server 2005 transactional log yedeğini kullanarak veritabanını saat 03:59'daki veriler bozulmadan hemen önceki durumuna geri yükleyebilirsiniz. SQL Server transactional log geri yüklendiğinde, transaction log'daki bütün işlemler tekrar çalıştırılır.
Bütün bunların yanında SQL Server 2005 sayfa seviyesi geri yüklemeye de izin verir. SQL Server 2005 kullanarak veritabanındaki sadece bir sayfayı ya da bir grup sayfayı geri yükleyebilirsiniz.
- SQL Server 2005 - Log Shipping With Delay (Geciktirilmiş Log Shipping)
Log shipping transaction log'larının yedeği bir veritabanı sunucusundan bir (ya da birden fazla) başka yedek sunuculara gönderilmesi ile çalışan bir veritabanı erişilebilirlik teknolojisidir. Birincil sunucuda ya da veritabanında ortaya çıkacak olası bir sorunda yedek sunuculara gönderilen transaction log'lar yedek sunucuya yüklenir ve servisin yedek sunucudan devam etmesi sağlanır.
Birincil sunucunun transaction log'ları istenildiği takdirde yedek sunucuya gönderilmeden once belirli sure aralıklarla yedek alınabilir. Örneğin, transactional log'ları yedek sunucuya direk olarak yazmak yerine, log shipping, yedek sunucuya "her 5 dakikada bir" yazmak üzere ayarlanabilir. Eğer bu 5 dakikalık zaman içinde herhangi bir sorun ortaya çıkarsa, yedek sunucudaki transactional log, veritabanını 5 dakika öncesine geri yüklemek için kullanılabilir.
- SQL Server 2005 - File Group Restore
SQL Server 2005'in bu yeni özelliği sayesinde, veritabanında sadece zarar gören objeler geri yüklenebilmektedir. SQL Server 2000'de erişilen en küçük kullanılırlık birimi veritabanının kendisidir. Bu sebeple, veritabanı tekrar kullanıma açılmadan once, o veritabanındaki tüm bileşenler sağlam çalışıyor olmalıdır. SQL Server 2005'te erişilen en küçük kullanılırlık birimi filegroup (dosya grubu)'dur. Bu erişilebilirliği arttırmaktadır, çünkü sadece geri yüklenilen filegroup'daki veriye erişilemez, geri kalan filegroup'larda kalan verilere erişilebilir. SQL Server 2005 aynı anda sadece filegroup'u (hatta eğer birincil filegroup erişilebilirse, sayfa ya da sayfa gruplarıları) geri yüklemeye izin verir.
- SQL Server 2005 - Hızlı Geri Yükleme
Oracle'ın "FastStart Fault Recovery" ?sine benzer olarak, SQL Server 2005'in "Fast Recovery - Hızlı Geri Yükleme" özelliği truncation log ileri doğru yüklendiği anda kullanıcıların "geri yükleme" durumundaki bir veritabanına bağlanabilmelerine olanak sağlar. SQL Server'ın daha önceki versiyonlarında kullanıcılar ilgili bölgelere erişmeseler bile yarım kalmış işlemler geri alınana kadar beklemek zorunda kalırlardı.
- SQL Server 2005 - Database Snapshots
SQL Server 2005, zarar görmüş verilerin çok hızlı ve kolay geri alınabilmesi için database snapshots özelliği ile beraber gelir. Veritabanı snapshotları veritabanı kopyasından farklıdır. Veritabanı snapshot'ları sadece veritabanında değişiklik yapılan alanlar kadar alana ihtiyaç duyar.
Bir veritabanının snapshot'unu oluşturduğunuz anda veritabanı ile aynı boyutta fakat içinde herhangi bir veri bulunmayan bir başka veritabanı (dosyası) oluşturulur. Başlangıçta snapshot veritabanında hiçbir veri yoktur. Orijinal veritabanındaki sayfa(lar) güncellendiği anda, güncellenen sayfa(lar) snapshot'a kopyalanır. Sonuçta orijinal veritabanında yeni (güncel) sayfa, snapshot veritabanında ise orijinal veritabanındaki eski sayfa(lar) bulunmaktadır. Herhangi bir sorun anında snapshot veritabananındaki eski sayfalara geri dönülebilir (Şekil 1)
Şekil 1a. Database snapshot'un çalışma prensibi
Yeni bir snapshot veritabanı oluşturduğunuzda ve birincil veritabanında henüz herhangi bir değişiklik yoksa, snapshot veritabanı dosyasının içeriği boş demektir. Eğer kullanıcı snapshot'dan veri okumaya çalışırsa okuma isteklerinin tamamı orijinal veritabanına yönlendirilecektir. Kaynak veritabanı güncellendikçe güncellenen sayfalar snaphot veritabanına kopyalanır. Snapshot veritabanına okuma isteği geldiğinde ilgili sayfa snapshot veritabanında mevcutsa (kaynak veritabanında değişmisse) istek snapshot veritabanından karşılanır, mevcut olmayan sayfalar kaynak veritabanından karşılanır.
Şekil 1b. Zamanla snapshot veritabanı dolar ve kendisine gelen sorguları kendi sayfalarından karşılamaya başlar
Oracle 10g - Recovery Manager (RMAN)
Oracle 10g'de Recovery Manager (RMAN) isimli araç yedek alma ve geri yükleme işlemlerini kontrol eder. RMAN aracı RMAN çalıştırılabilir fonksyonları, yedek alınacak hedef veritabanı ve opsiyonel geri yükleme kataloğundan oluşur. Eğer geri yükleme kataloğu belirtilmezse, alınan yedek ile ilgili bilgiler bir kontrol dosyasında saklanır.
RMAN'ın birçok özelliği bozulmuş verileri kurtarmak için kullanılabilir. Kontrol dosyası veri dosyası oluşturulmasından geri yükleme zamanına kadarki zaman dilimindeki arşiv log dosyaları ve veri dosyası ile ilgili bilgiyi içerir.
Standart bir RMAN yedeği belirli bir veri dosyası (datafile) ile ilgili veri bloklarından oluşur. Veri dosyaları özel, sıkıştırılmış bir formatta saklanır. Bir veri dosyasının geri yüklenmesi gerektiğinde tüm veri dosyasının, veritabanı birimlerinden yeniden oluşturulması gerekmektedir. Oracle 10g ile, imaj kopyaları veritbanı, tablo ya da veritabanı dosyası seviyesinde alınabilir. Veri dosyasının imaj kopyasını geri yüklemek her zaman daha hızlıdır, çünkü veri dosyasının gerçek yapısı zaten sağlanmaktadır.
RMAN'ın "Incrementally Updated Backups / Artarak Güncellenen Yedekler" özelliği sayesinde veri dosyası imajı incremental yedeklerle güncellenerek, veri dosyasının imajının güncel tutulması sağlanabilir, bu da geri yükleme zamanını azaltır. Bu aynı zamanda SQL Server 2005'de olduğu gibi belirli bir zamana geri dönülebilmesine olanak verir.
Değişiklik izleme, Oracle 10g ile gelen opsiyonel bir komponenttir ve incremental yedeklerin peformansını arttırır. Oracle'ın eski versiyonlarında veri dosyalarındaki tüm bloklar son incremental yedekten bu zamana olan değişiklikler için taranmaası gerekirdi. Değişiklik izleme özelliği ile birlikte, değişen blokların numaraları değişiklik izleme dosyasına yazıldığı için, sadece ilk incremental yedeğin bloklarının taranması yeterlidir. Daha sonraki incremental yedekler değişiklik izleme dosyasını tarayarak yedek alınacak değişikliğe uğramış blok olup olmadığını kontrol ederler.
- Oracle 10g - Flashback
Oracle 10g'nın Flashback özelliği SQL Server 2005'in database snapshots özelliğine çok benzerdir. Bir flashback veritabanı, standart yedek yerine Flash Geriyükleme Alanı'nı kullanarak orijinal veritabanının belirli bir zamana geri döndürülmesini sağlar. Flashback özelliği basit tablo ya da satır verilerini geri yüklemek için kullanılırken, az önce bahsettiğim RMAN özelliği daha büyük verilerin geri yüklenmesi için kullanılabilir.
Flashback'in önemli bir limitasyonu, referential integrity (referansiyel bütünlük) desteği olmamasıdır. Eğer Flashback kullanarak diğer tablolarla ilişkisi olan bir tabloyu geri yüklerseniz, ve diğer tablolardaki veriler değişikse, veritabanı bütünlüğünüze zarar verebilirsiniz.
Bu özellik sadece Oracle 10g Enterprise Edition'da bulunmaktadır.
Sunucu Sorunlarına Karşı Veritabanı Yüksek Erişilebilirlik Çözümleri
Yüksek erişilebilirlik çözümlerini tasarlarken düşünülmesi gereken bir diğer çok önemli konu ise sunucularda oluşabilecek sorunlara karşı çözüm üretebilmektir. Sunucu sorunları CPU, RAM, depolama birimi gibi temel donanımsal sorunlar olabileceği gibi, işletim sistemi, donanım sürücüsü ya da veritabanı sunucusu sorunları da olabilir.
Sunucu sorunlarından korunmak için atmamız gereken ilk adım, temel bileşenler için yüksek erişilebilirlik sağlayan donanımsal çözümler uygulamaktır. Örneğin, dahili kesintisiz güç kaynağı (UPS), hot swap özelliği olan RAM ve disk sürücüleri gibi.
Yazılım tarafında ise işletim sisteminizin ve donanım sürücülerinin güncelleştirmelerini ve service pack'lerini güncel tutmaktır. Microsoft SMS (Systems Management Server) ürünü sayesinde sunucularınız kaç tane olursa olsun tüm sunucularınızın güncelleştirmelerini ve service pack'lerini güncel tutabileceğiniz ve envanter takibini yapabileceğiniz gibi orta ölçekli firmalar için WSUS ( Windows Server Update Services) ürününü aynı amaç için kullanabilirsiniz. Küçük ölçekli firmalat için Windows Update ürününü kullanmanız tavsiye edilir.
Yukarıda saydığım adımlar servislerinizin erişilebilirliğini arttırmalarının yanında, bütün bir yüksek erişilebilirlik çözümü için yeterli değildir. Clustering ve log shipping teknolojileri kullanarak, yüksek erişilebilirliğe sahip bir veritabanı platformu sunmanız için doğru teknolojik yaklaşımı yakalamış olursunuz.
Clustering, bir servisi sunan aktif sunucu ile birlikte, aktif sunucuda herhangi bir sorun oluşup sunucu servisi sağlayamaz duruma geldiğinde otomatik olarak yerine geçebilecek sunucu ya da sunuculardan oluşan bir teknolojidir. Clustering'e ek olarak, günümüzde veritabanı platformları sunucu hatalarına karşı log shipping ve replication (replikasyon) gibi birçok farklı teknolojileri de destekler durumdadırlar
