Oracle Data Guard Mimarisi

Merhaba Arkadaşlar,

Bu yazımda veritabanlarımızın olası Felaket senaryolarından korumak için  çokça ihtiyaç duyduğumuz ve kullandığımız Oracle Data Guard teknolojisini ve mimarisini anlatacağım.

Oracle Data guard ı anlatmaya başlamadan önce veritabanlarımız için Felaket durumlarının neler olduğunu belirtelim. Günlük hayatta felaket denilince akla 17 Ağustos depremi gibi Erzincan Depremi gibi depremler, Seller, Patlamalar, Tsunami gibi Çok sayıda mal ve can kaybına sebeb veren olaylar bilinir. Bu felaket durumlarını Şirketler için düşünürsek Şirketler açısından en önemli felaket durumlarından biriside İş kritik verilerin yer aldığı Veritabanlarındaki verilerin herhangi bir sebebten ötürü kaybedilmesidir. Günümüzde eski usul bakkal defterlerinin artık bittiğini düşünürsek Bankalar, Holdingler,Telekomünikasyon Şirketleri vb.. bilgilerini ve kritik verilerini veritabanlarında sakladıkları için bu verileri korumak çok önemli duruma gelmiştir.

Bunu günlük hayatta en çıplaklığıyla ortaya dökersek siz bir müşteri olarak x bankasıyla parasal yönde işlemlerinizi yapıyorsunuz. X bankasının tüm bankacılık veritabanları çökse ve hiçbir şekilde veriye ulaşma imkanları olmazsa ne olur ? X bankasındaki her bir müşteriye ait ne kadar para,altın, dolar olduğunu gösteren veriler olmazsa banka bu için içinden nasıl çıkar ? İşte bahsettiğim bu senaryo bankacılık için ve diğer bir çok şirketler için Felaket durumudur. Şirketler bu tip felaketlere maruz kaldığı zaman felaketten kurtulmak için veritabanlarının sunduğu Disaster Recovery diye bilinen Felaket kurtarma çözümlerini mutlaka kullanırlar ve kullanmak da zorundadırlar.

Şirketler Disaster Recovery çözümlerini uygulamadan önce şu 2 soruya cevap bulmalılar ve bu cevapların şirketin gereksinimini karşıladığından emin olmalılar.

1. İlgili İş kritik verileri olmadan ne kadar süre durumu kurtarabiliriz yada ayakta kalabiliriz ?

2. Felaket durumunda ne kadar veri kaybetmeyi göze alabiliriz ?

Bir bankacılık uygulamasının veritabanı için yukardaki soruların cevabı mümkün olduğunca en kısa süre ve hiç veri kaybetmeme şeklinde olacaktır.

İşte yukarda bahsettiğim felaket durumlarına karşı her Veritabanı yönetim Sistemi (Oracle, SQL Server,MySQL,Sybase vb) bir felaket kurtarma (Disaster Recovery) çözümü ortaya koymuştur. Oracle Corporation ise ilk olarak Oracle 7 sürümü ile Disaster Recovery çözümü olarak manuel standby veritabanı oluşturulmasına imkan tanıyarak ortaya koymuştur. Daha sonra Oracle 8i ile beraber disaster recovery çözümünü Oracle, Data Guard olarak tanıttı ve hemen hemen her sürümde bir çok özellik eklenerek Oracle 12c ile beraber Far Sync gibi özellikler eklenerek güncel halini almıştır.

Oracle Data Guard ile çok süratli bir şekilde veritabanımızın canlı verilerle beslenen bir Yedek Veritabanını oluşturabiliriz. Böylece ana veritabanında herhangi bir sıkıntı yaşandığı anda çok hızlı bir şekilde Yedek veritabanından devam edebiliriz. Burada Dataguard ın en önemli rollerinden birisi ana veritabanının sadece bir Yedek veritabanını oluşturması değil aynı zamanda canlı verilerle yedeği beslediği için oluşturulan konfigürasyona göre anlık yedeğini oluşturmasıdır.

Data Guard ın çalışma yapısını şöyle özetleyebiliriz. Dataguard, Canlı veritabanı dediğimiz Primary veritabanında oluşan Redo kayıtlarını Yedek veritabanı dediğimiz Standby veritabanına taşır ve taşınan bu Redo verileri Standby veritabanına apply edilerek Primary veritabanının Güncel yedeğini oluşturur. Redo Verisi dediğimiz veri Primary veritabanında meydana gelen Transactionlar bütünüdür.(İnsert,Update,Delete,Create,Alter vb..) Primary veritabanına gelen Transactionların Standby a taşınıp apply edilmesi demek aynı transactionların Standby tarafında da çalışması demektir. Data Guard taşıdığı  Redo verilerini Standby veritabanına apply etmeden önce aynı zamanda Block Corruption (Blok bozulması) sorunlarına karşı kontrol eder.

Data Guard ın Synchronous ve Asynchronous olmak üzere 2 farklı çalışma şekli vardır.

Yukardaki mimariye göre Data Guard ın 2 farklı çalışma şeklini bir Transaction üzerinden aşağıdaki gibi maddeler halinde şöyle açıklayabiliriz.

Synchronous Data Guard

1. Veritabanında bir Transaction başlatıldığı zaman bu işlem öncellikle Redo Buffer alanına yazılır. Kullanıcı ilgili Transaction ı commit ettiği zaman LGWR process i  Redo Buffer alanındaki redo verilerini Online Redo Logs lara yazar ve LNS process i redo verilerinin Standby veritabanına yazıldığına ilişkin doğrulama bekler.
2. LNS (Log Network Service) process i ise aynı Redo verilerini Redo Buffer alanından okur ve ONS (Oracle Net Service) üzerinden RFS (Remote File Service) process ine bildirir. LNS process i ilgili Redo verilerine Redo Buffer dan erişemezse otomatik olarak Primary veritabanının Online redo logs larını okur.
3. RFS Process i ise aldığı Redo verilerini Standby Redo Logs larına yazar.
4. MRP (Managed Recovery Process) process i Standby Redo Logs larındaki Redo verilerini Standby veritabanına Apply eder.
5. Son olarak RFS process i gönderilen redo verilerinin başarılı bir şekilde Standby a yazıldığının bilgisini LNS işlemine gönderir, LNS ise bu mesajı LGWR process ine aktarır ve artık kullanıcıya Commit işleminin başarılı olduğu bilgisi dönülür.

Asynchronous Data Guard

1. Veritabanında bir Transaction başlatıldığı zaman bu işlem öncellikle Redo Buffer alanına yazılır. Bu Transaction commit edildiği zaman LGWR process i  Redo Buffer alanındaki redo verilerini Online Redo Logs lara yazar.
2. LNS (Log Network Service) process i ise aynı Redo verilerini Redo Buffer alanından okur ve ONS (Oracle Net Service) üzerinden RFS (Remote File Service) process ine bildirir. LNS process i ilgili Redo verilerine Redo Buffer dan erişemezse otomatik olarak Primary veritabanının Online redo logs larını okur.
3. RFS Process i ise aldığı Redo verilerini Standby Redo Logs larına yazar.
4. Son aşamada ise MRP (Managed Recovery Process) process i Standby Redo Logs larındaki Redo verilerini Standby veritabanına Apply eder.

Asenkron Data guard yönteminde RFS işleminin başarılı bir şekilde redo verilerini işlendiği bilgisi LNS e gönderilmez bu yüzden bu yöntemde Sıfır veri kaybı yoktur en az veri kaybı ile verilerin kurtarılması sağlanır. Senkron Dataguard yönteminde ise commit edilen tüm verilerin Standby tarafına gönderildiği ve apply edildiği garanti edildiği için bu yöntemde sıfır veri kaybı durumu vardır. Ancak Senkron un Asenkrona göre bazı sıkıntıları vardır Senkron Data Guard, Asenkron Data Guard yöntemine göre daha az performanslı çalışır çünkü Senkron Data guard yönteminde LGWR process i her zaman için LNS process inden doğrulama bilgisi bekler buda süre kaybına yol açar. Ancak çok kritik verilerin bulunduğu veritabanlarında da Sıfır Veri kaybı çözümüylede Asenkron yönteme göre avantajlıdır.

Oracle Dataguard teknolojisi bize verilerimizin korunması için farklı seçeneklere göre 3 koruma modu sunar. Bunların neler olduğunu aşağıdaki gibi açıklayabiliriz.

1.Maksimum Performans: Bu mod Dataguard için ilk kurulumda default olarak gelen bir moddur. Bu modda Primary veritabanının performansı çok önemli olduğu için ASYNC (Asenkron) Dataguard yöntemi kullanılır. Yani LGWR processi standby veritabanından gönderilen Redo verilerinin apply edildiği bilgisini beklemeden kullanıcıya commit bilgisini gönderir.

2.Maksimum Erişim yada Kullanılabilirlik (Availability): Dataguard Bu modda kullanıcıya sıfır veri kaybı (Zero Data loss) özelliği sağlar. Sıfır veri kaybını sağlayan konfigürasyon ise yukarıda da belirttiğim gibi SYNC (Senkron) Dataguard konfigürasyonudur. Bu modda kullanıcı başlattığı bir transaction için commit koyduğu anda başlatılan transaction Standby a apply edilmeden kullanıcıya Commit edildiği bilgisi dönmez. Bu modda Primary veritabanı ile Standby veritabanı arasında Networksel yada herhangi bir iletişim sorunu yaşandığında belirli bir süre beklenir bu süre zarfında iletişim sağlanamazsa LGWR process i LNS process i ile olan connection ı keser ve kullanıcıya commit edildiği bilgisini döner. Belirli bir süre için veritabanının belirlediği parametre ise NET_TIMEOUT parametresidir. Bu parametre sayesinde Veritabanının hang olmaması sağlanır.

3.Maksimum Koruma: Bu modda 2.madde de anlattığım Maksimum Kullanılabilirlik özelliği gibidir ve SYNC Dataguard konfigürasyonunu kullanır. Aralarında tek bir fark vardır o da bu modda NET_TIMEOUT parametresi kullanılmaz yani LGWR process i LNS process inden Redo verilerinin Standby a Apply edildiği bilgisini bekler eğer Apply edilmemişse kullanıcıya Commit bilgiside dönmez. Bu modda primary veritabanı sürekli olarak Standby dan bilgi beklediği için bir süre sonra hang durumuna düşebilir bu durumu önlemek için genellikle bu modu kullananlar birden fazla Standby veritabanı oluştururlar. Primary veritabanı göndermiş olduğu Redo verilerinin herhangi bir tane veritabanına ulaştığının ve apply edildiğinin bilgisini alması yeterlidir. Bu yöntemde Birden fazla Standby kullanılması Primary açısından önemlidir çünkü Hang olma olasılığı böylece azaltılmış olur.

Dataguard kurulumuna geçmeden önce Dataguard için Oracle veritabanının bizlere sunmuş olduğu parametreleri tanıyalım. Hem primary hemde Standby da ortak kullanılan parametreler ve işlevleri aşağıdaki gibidir.

• DB_UNIQUE_NAME: Veritabanımızın benzersiz yani veritabanının unique namedir. DB_NAME parametresi her iki taraf için aynı olacaktır fakat DB_UNIQUE_NAME ler farklı olmalıdır. Benim örnek kurulumumda Primary veritabanının DB_UNIQUE_NAME i TESTDB ve Standby Veritabanının DB_UNIQUE_NAME i TESTDBFKM olacaktır. Fakat her iki veritabanının DB_NAME değeri TESTDB olacaktır.
• CONTROL_FILES: Veritabanlarımızın beyni olan Control file larının yerini gösteren parametredir. Bu değer Primary de Primary veritabanının, Standby da Standby veritabanın Control file Location ını gösterir. Örneğin Primary veritabanında Control Dosyamın yeri bu parametre ile aşağıdaki gibi belirtilir.
  control_files=’/oracle/data/TESTDB/control01.ctl’
• LOG_ARCHIVE_CONFIG: Dataguard konfigürasyonu için seçilen veritabanlarının DB_UNIQUE_NAME lerinin belirtildiği parametredir. İlk olarak Primary veritabanı DB_UNIQUE_NAME i yazılır ardından standby lar dizilir. Benim kuracağım örnek kurulumda bu parametre aşağıdaki gibi olacaktır.
  log_archive_config= ‘dg_config=(TESTDB,TESTDBFKM)’
• LOG_ARCHIVE_MAX_PROCESSES: Dataguard konfigürasyonu için önemli parametrelerden birisidir. Adındanda anlaşıldığı gibi Veritabanının bu işlem sırasında kullanabileceği maksimum ARCH process inin sayısını belirler. Default olarak ilk kurulumda bu sayı 2 dir yani 2 adet ARCH process i aktif olarak çalışır ve bu process lerden 1 tanesi sadece ve sadece dolan Online Redolog dosyalarının Arşivlemesini sağlar ve bunun için assign edilmiştir. Bundan dolayı ilk kurulumda gelen 2 adet ARCH process i Canlıdaki veritabanımız için çok yetersizdir. Yetersiz olmasının nedeni ARCH process i hem Dolan Online Redo logların Arşivler hemde Primary ve Standby arasında Redo Gap oluştuğu zaman ARCH process i Primary veritabanının Arşiv log larını kullanarak Standby veritabanını besler. Bu parametrenin maksimum değeri 30 dur fakat çok ihtiyacınız olmadığı müddetçe bu kadar fazlada kullanmanızı önermem ben genellikle ilk kurulumda bu parametrenin sayısını 4 olarak güncelleyip ardından sistemi izleyip duruma göre ihtiyaç olursa tekrar değiştiririm.

Yukarda anlattığım parametreler dışında dataguard için kullanılan bir çok parametre daha vardır bunlardan bazıları sadece Primary de bazılarıda sadece Standby veritabanı için kullanılır bunlardan önemlileri ve işlevleri aşağıdaki gibidir.

• LOG_ARCHIVE_DEST_n: Bu parametre Primary veritabanı için kullanılan önemli bir parametredir. Primary veritabanından Standby (lar)a Redo verisi göndermek için gerekli bir parametredir. n değeri bu parametre için 0-31 e kadardır. Log_archive_dest_1 parametresi Primary veritabanının Arşiv loglarının yerini gösterir bundan sonraki Log_archive_dest_2 den sonra gelen parametreler Standby için konfigüre edilir.
• DB_FILE_NAME_CONVERT: Standby tarafında kullanılan önemli bir parametredir. Standby tarafında Datafile ların Primary tarafındaki location ları eğer farklı ise Convert edebilmesi için set edilen parametredir. Bu parametre özellikle Switchover işlemi gerektiği zaman önem kazanır switchover olması durumunda her iki tarafın Control ve Datafile ların header bilgileri buna göre değiştirilir.
• LOG_FILE_NAME_CONVERT: Bir üstteki parametre ile aynı olan parametredir sadece yukarda Datafile lar için yapılanlar bu parametre ile Online Redolog dosyaları için yapılır.
• FAL_SERVER: Bu parametrede Standby tarafı için önemli bir parametredir. Burdaki FAL ın açılımı Fetch Archive Log şeklindedir. Adındanda anlaşılabileceği üzere Primary ile Standby arasında Redo GAP oluştuğu zaman Arşiv log larının hangi Server dan alınacağını bu parametre ile belirleriz.

Böylece bu yazının da sonuna gelmiş bulunmaktayız 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 mehmet.deveci@gridgroup.com.tr 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