Solaris 10 platformunda Oracle 10g Real Application Clusters(RAC) Kurulumu - Adım adım

Senaryomuzda, Oracle 10g R2 RAC çalışacak her bir düğüm aşağıdaki donanımsal gereksinimlere ihtiyaç duymaktadır;

• OCR, Voting Disk dosyası ve veritabanı dosyalarını depolamak üzere SAN depolama ünitesi (her bir düğüm bu paylaşımlı SAN ünitesine bağlı olmalı)
• iSCSI arayüzü
• Her bir sunucu için 2 adet Ethernet kartı(NIC). Bir NIC public olarak lokal networke ait switche bağlanacak, diğer NIC ise private olarak cluster switchine bağlanarak Virtual Ip address ataması ile istemci bağlantılarında ve bağlantı düşmelerinde kullanılmak üzere diğer düğüm ile veri alışverişini sağlayacak. Her bir düğümde private, public ve Virtual IP adresleri diğer düğümlerden farklı olacaktır.

Oracle Real Application Cluster mimarisinde depolama seçenekleri

         

NFS dosya sistemi veya raw device(partition) Oracle Clusterware dosyaları için kullanılabilir. Veritabanı veya recovery dosyası olarak ASM kullanılabilir, ancak recovery dosyasını tutmak için raw devicelar kullanılamaz.

Ne zaman multiple buffer pool kullanılmalıdır?

Sistem performansını gözden geçirirken şemayı analiz etmeli ve multiple buffer  pool(çoklu tampon havuzu) kullanılıp kullanılmayacağıni belirlemelisiniz. Eğer hızlı cevap gerektiren küçük ve sık erişilen tablolar mevcutsa “keep” belleği değerlendirmeye alın. Rastgele I/O olan çok büyük tablolar için ise “recycle” bellek idealdir.
Belirli bir zamanda bireysel obje tarafından yüzdesel olarak ne kadar bellek kullanıldığını belirlemek için alttaki adımları uygulamanız yeterli olacaktır.

Fiziksel standby sunucuya primary rolünü switch etme

Primary veritabanın rolünü standby sunucuya olağan durumlarda devretme olayına switchover denir. Genellikle primary veritabanında işletim sistemi güncellemesi veya donanım yükseltmesi gibi planlanan kesintiler olacağı zaman meydana gelir. Switchover esnasında herhangi bir veri kaybı yaşanmaz. Switchover sonrasında her veritabanı yeni rolünde görev yapmaya başlar. Standby veritabanına primary rolününe switchover yapma adımları aşağıda yer almaktadır.

Primary/Standby veritabanı ortamında failover işlemi

Dataguard ortamında failover primary veritabanının erişilemez olduğu durumlarda kullanılır. Belirli bir sure zarfında servisi geri yükleme imkanı olmaz. Failover durumu meydana geldiğinde eğer primary veritabanı “maksimum koruma” modunda çalışıyorsa, öncelikle standby veritabanı “maksimum performans” moduna geçirilmelidir.

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE

PERFORMANCE;

Standby veritabanı maksimum performans moduna geçtikten sonra aşağıdaki adımlar ile failover işlemi gerçekleşir.

Primary veritabanında en uygun veri koruma yönteminin seçimi

Standby veritabanında redo boşluklarının olmaması için primary veritabanı üzerinde uygun veri koruma modunun seçimi gerekmektedir. Oracle Dataguard mimarisinde üç çeşit veri koruma modu vardır.

• Maksimum uygunluk

Bu koruma modu primary veritabanının erişilebilirliğinde taviz vermeden en yüksek seviyede veri koruma seviyesini belirtir. İşlemler, herhangi bir çökmede geri kurtarmayı sağlayacak verinin online redo log dosyalarına yazılmadan ve bu redo log dosyalarının en azından bir standby veritabanına senkronize olmadan COMMIT işlemine izin vermez. Bu mod sıfır veri kaybı sağlar, ancak birkaç saniyelik düşmeler redo veri setlerinin standby veritabanına taşınmasını engellemez ve bu birkaç saniyelik düşmelerin olduğu zaman zarfında veri kaybı yaşanma ihtimali yüksektir.

• Maksimum performans

Bu koruma modu primary veritabanının performansını etkilemden un yüksek seviyede veri koruma seviyesini belirtir. İşlemler, online redo log dosyasına yazılır yazılmaz COMMIT olur. Redo verisi daha sonra eşzamanlı olmadan standby veritabanına yazılır. Böylece bu mod aktifken, primary veritabanı eşzamanlı redo taşıması esnasındaki gecikmelerden kaynaklanan performans sıkıntısını yaşamaz. Bu mod varsayılan koruma modudur ve primary veritabanı performansı üzerinde etkisi sınırlıdır.

• Maksimum koruma

Bu koruma modu primary veritabanı çöktüğü zaman sıfır veri kaybını sağlar. İşlem commit olmadan önce aynı maksimum uygunluk modunda olduğu gibi hem primary redo log dosyalarına yazılmalı hemde en az bir standby veritabanına yazılması gerekmektedir. Veri kaybının yaşanmaması eğer redo dosyalarını en az bir standby veritabanına yazamazsa primary veritabanı kendini kapatır, böylece veri kaybı ihtimalini ortadan kaldırır. En az 2 standby veritabanı kullanıldığı Dataguard mimarilerinde bu modun seçimi tavsiye edilir.

Primary veritabanında veri koruma modunu değiştirmek için aşağıdaki adımları izleyebilirsiniz.

DUPLICATE komutu ile Oracle 11g Fiziksel Standby Veritabanı Yapılandırması

Bu yazıda, Oracle 11g ile birlikte gelen RMAN servisinden çalıştırılan DUPLICATE ... FROM ACTIVE DATABASE komutunu kullanarak, primary veritabanının herhangi bir yedeğini almadan ve ayrıca yedeğede ihtiyaç duymadan, primary veritabanı açıkken fiziksel bir standby veritabanı oluşturmasını adım-adım uygulayacağız. Senaryomda her iki sunucuda aynı Oracle dizin lokasyonlarını kullanmaktadır.

Senaryoda kullanılan sistem

Primary veritabanı DB_UNIQUE_NAME: orclprm

Standby veritabanı DB_UNIQUE_NAME: orclstdby

ORACLE_SID: orcl

Primary hostname: linux1 (OEL Linux 5.3)

Standby hostname: linux2 (OEL Linux 5.3)

Oracle software versiyonu: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 

1. Primary veritabanından fiziksel standby yapılandırmasına başlamadan once, veritabanına loglanmamış direkt yazma işlemlerini engellemek için primary veritabanında “Force Logging” özelliğini etkinleştiriyoruz.

SQL> alter database force logging;

Database altered.

2. Standby veritabanına primary veritabanındaki password dosyasını kopyalıyoruz.

$ scp $ORACLE_HOME/dbs/orapworcl.ora linux2:$ORACLE_HOME/dbs/

3. Network yapılandıma dosyalarında standby için gerekli güncellemeleri yapıyoruz.

Hem primary hemde standby veritabanı üzerindeki tnsnames.ora dosyasında aşağıdaki güncellemeleri yapıyoruz.

orclprm =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = linux1)(PORT = 1521))

    )

    (CONNECT_DATA =

      (SERVICE_NAME = orclprm)

    )

  )

orclstdby =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = linux2)(PORT = 1521))

    )

    (CONNECT_DATA =

      (SERVICE_NAME = orclstdby)

    )

  )

Bu dosyada gerekli değişiklikleri yaptıktan sonra standby sunucudaki aynı lokasyona kopyalıyoruz.

Bozuk veya kayıp arşiv log dosyası sonrası standby veritabanını geri kurtarma

Fiziksel standby veritabanı, primary veritabanından kendisine arşivlenmiş logların sürekli uygulanması ve bu senkronizasyonun sürekli devam etmesi esasına dayanmaktadır. Oracle 10g öncesinde arşivlenmiş loglardan birinin kaybolması veya bozulması durumunda standby veritabanının yeniden inşa edilmesi gerekmekteydi.

Ancak, Oracle 10g sürümünden itibaren kayıp veya bozulmuş arşiv loglarla karşılaşıldığında artalan yedekten standby veritabanını geri kurtarabilmekteyiz.

Aşağıdaki senaryoda uygulanacağı üzere standby veritabanına senkronize edilmesi gereken 234 ve 235 sıra numaralı arşivlenmiş loglar primary veritabanından kazara silinmiştir. Şimdi bu durumda standby veritabanını geri yükleme ve çalışmaya devam etmesini adım adım inceleyelim.

Primary veritabanı “row cache enqueue lock “ bekleme olayı hatası ve çözümü

Oracle 10.2.0.3.0 Data Guard with Broker konfigürasyonunda herhangi bir şekilde standby veritabanını READ ONLY modda yeniden başlatmayı denediğinizde aşağıdaki hata mesajını alırsınız.

ERROR: WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
ORA-12170: TNS:Connect timeout occurred
PING[ARC6]: Error 3113 when pinging standby
ARC6: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (1089)

“ORA01665 control file is not a standby control file” hata mesajı

Standby veritabanını geri yüklerken alter database recover managed standby database disconnect from session komutu sonucunda “ORA-01665: control file is not a standby control file” şeklinde hata mesajı alınabilir.

SQL> alter database recover managed standby database disconnect from session;
alter database recover managed standby database disconnect from session
*
ERROR at line 1:
ORA-01665: control file is not a standby control file

Standby veritabanı tarafından henüz alınmayan logların bulunması

Standby veritbanı tarafından hangi logların henüz alınmadığını bulmak için primary veritabanı üzerinde aşağıdaki sorguyu çalıştırabilirsiniz.

SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM
          (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE

          DEST_ID = (SELECT DEST_ID FROM V$ARCHIVE_DEST) LOCAL
          WHERE LOCAL.SEQUENCE# NOT IN
         (SELECT SEQUENCE# FROM V$ARCHIVED_LOG

         WHERE DEST_ID=(SELECT DEST_ID FROM V$ARCHIVE_DEST)  AND
         THREAD# = LOCAL.THREAD#);

THREAD#      SEQUENCE#
----------         ----------
1                      12
1                      13

1                     14

Yukardaki sonuca gore 12,13 ve 14 numaralı loglar henüz standby veritabanı tarafından alınmamıştır.

Linux | Unix sistemlerde açılış esnasında veritabanını ve listener’ı otomatik olarak başlatma

Linux ve UNIX sistemlerde veritabanını ve listener’ı boot esnasında açılış scripti ile başlatabiliriz. Bunun için bazı yollar vardır. Birinci yol, veritabanını başlatmak için kullanılan dbstart scripti içine ilgili listeneri eklemek ve değerini Y olarak değiştirmektir. Ancak bazı durumlarda bu başlatmada sıkıntı yaratabilmektedir.

Diğer en uygun yol ise hem veritabanını hemde listener’ı başlatıp durduracak bir script oluşturmak ve runlevel dizinlerinden birine bu scripti iliştirmektir.

Bu script, başlat ve durdur olmak üzere 2 arguman içerecek ve /etc/rc.d/init.d dizininde yer alacaktır. Alttaki komut dbora adlı dosya içerisinden listener’ı ve veritabanını başlatıp durdurmak için eklenmiştir.

Oracle veritabanının DBID sini değiştirme

Oracle veritabanının DBID sini değiştirmek zorunda kaldığımızda alttaki adımları uygulamak yeterli olacaktır.