Standalone Oracle 10g veritabanının 10g RAC veritabanına dönüştürülmesi

Standalone Oracle 10g veritabanın Oracle 10g RAC veritabanına dönüştürülmesi işlemi öncesinde tüm düğümlerde clusterware yazılımının kurulmuş olması ve sunucuların RAC yapısında hizmet verecek şekilde fiziksel olarak yapılandırılmış olması gerekmektedir. Bu kurulum öncesi işlemlerin tamamlandığından emin olunduktan sonra daha önceden stand alone olarak hizmet veren bir Oracle 10g veritabanının RAC veritabanına dönüştürme işlemi için aşağıdaki adımların uygulanması yeterli olacaktır.

Oracle 11.2.0.2 Clusterware ortamında kayıp OCR ve voting disklerin yedekten geri yüklenmesi

Bu yazıda Oracle 11.2.0.2 Clusterware platformunda OCR ve voting diskin kaybedildiği durumda sisteme nasıl geri yükleneceği anlatılmaktadır. Ocssd.bin başlatıldığında, GPnP profili, network ve voting disklerde var olmalıdır. Eğer minimum sayıda gereksinim duyulan voting dosyaları varolmazsa , bu durumda ocssd.bin başlatılamaz.  

OCR varolmadan crsd prosesi başlatılamaz ve ocssd.bin de aktif olmaz.  OCR, CRS tarafından kullanılır, bu da OCR kayıp olduğunda crsd.bin in aktif olamayacağı anlamına gelmektedir. CRSD aktif olmazsa, bu sorunlu düğüm kümeye dahilde olamaz.

Oracle Clusterware her 4 saatte bir OCR'nin yedeğini almaktadır. OCR içinde voting diskin yedeği bulunmaktadır. Bu sebeple voting diski geri yüklemek için var olan bir OCR yedeği yeterlidir. Şimdi bu geri yükleme olayını, OCR'nin yer aldığı ASM disk grubundaki(senaryomda +DATA) disklerde fiziksel bir çökme nedeniyle erişilemez olduğu senaryo çerçevesinde adım adım işleyelim. İlk etapta küme katmanını çalıştırarak sorunun olduğunu gözlemleyelim.

[root@rac1 ~]# crsctl start cluster

CRS-2672: Attempting to start ‘ora.cssdmonitor’ on ‘rac1′

CRS-2676: Start of ‘ora.cssdmonitor’ on ‘rac1′ succeeded

CRS-2672: Attempting to start ‘ora.cssd’ on ‘rac1′

CRS-2672: Attempting to start ‘ora.diskmon’ on ‘rac1′

CRS-2676: Start of ‘ora.diskmon’ on ‘rac1′ succeeded

CRS-2674: Start of ‘ora.cssd’ on ‘rac1′ failed

Bu adımda neyin yanlış olduğunu teyit etmek için log dosyalarına bakılması gerekmektedir.  Clusterware'nin alert.log dosyasında aşağıdaki gibi bir hata mesajına rastlanılacaktır.

Oracle 11.2 Grid mimarisinde RAC düğümlere ilave SCAN listener ekleme

Geçenlerde test ortamda yapılandırdığım Oracle11gR2 grid yapılandırması aşağıdaki loglarda görüldüğü gibi sadece tek bir SCAN listener ile tamamlandı. Oracle 11.2 RAC yapılandırması iki düğümden(rac01 ve rac02) oluşan bir test platformunda yapıldı. Bu yazıda Oracle 11.2 Grid ortamında RAC düğümlere nasıl ilave iki SCAN listener daha eklenecek, onu inceleyeceğiz.

[grid@rac01 grid]$ srvctl config scan
SCAN name: rac-scan, Network: 1/192.168.38.0/255.255.255.0/eth2
SCAN VIP name: scan1, IP: /rac-scan.bugra.com/192.168.67.192

[grid@rac01 grid]$ srvctl config scan_listener
SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521

[grid@rac01 grid]$ ping rac-scan.bugra.com
PING rac-scan.bugra.com(192.168.67.193) 56(84) bytes of data.
From rac01.test.ant(192.168.38.50) icmp_seq=2 Destination Host Unreachable
From rac01.test.ant(192.168.38.50) icmp_seq=3 Destination Host Unreachable
From rac01.test.ant(192.168.38.50) icmp_seq=4 Destination Host Unreachable

— rac-scan.bugra.com ping istatistikleri —

6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5000ms
, pipe 3

Maksimum Erişilebilirlik Mimarisinde OCI bağlantılarında SCAN kullanımı

Bu konuyu anlatmak için geniş yelpazade dağıtık bir maksimum erişilebilirlik mimarisi senaryosu üzerinden gitmek daha faydalı olacak diye düşünüyorum, şöyleki...

Yukardaki örnekte primary sitede 6 düğüm, standby sitedede 6 düğüm mevcut. Toplamda 6 servis oluşturulacak. 3 servis primary site üzerinde yazma amaçlı, 3 serviste raporlama amaçlı standby site üzerinden kullanılacak. Server pools teknolojisi kullanarak servislerin işyüküne uygun olarak donanımsal kaynak tahsisi yapacağız. Dataguard broker gözlemcisi primary siteyi izleyecek ve servislerden birinde düşme meydana gelirse otomatik olarak failover işlemini tetikleyecek.

Primary sitede;

3 sunucu havuzu olacak. Öncelik sırası ise SALES>CRM>MRP

MRP servisi için à En az 1, en fazla 2 server tahsisi gerekli

SALES servisi için à En az 2, en fazla 3 server tahsisi gerekli

CRM servisi için à En az 2, en fazla 3 server tahsisi gerekli

1 sunucu boşta olacak ve gerektiğinde devreye girecek…

Standby sitede;

3 sunucu havuzu olacak. Öncelik sırası ise MRP>CRM>SALES

MRP_READ servisi için à En az 2, en fazla 2 server tahsisi gerekli

SALES_READ servisi için à En az 1, en fazla 3 server tahsisi gerekli

CRM_READ servisi için à En az 2, en fazla 3 server tahsisi gerekli

1 sunucu boşta olacak ve gerektiğinde devreye girecek…

Bu senaryoyu gerçeğe dönüştürürken 3 aşamalı bir iş akışı üzerinden gideceğim.

1. İlgili servislerin ve TAF işlevinin eklenmesi
2. tnsnames.ora dosyalarında gerekli değişikliklerin yapılması
3. Server pools oluşturulması ve ilgili servislerin eklenmesi

Sonraki yazılarımda her üç aşamayı teker teker açacağız…

Oracle 11.2 Dataguard Broker ile RAC kümelerine JDBC bağlantılarında kusursuz application failover yapılandırması

Oracle 11.2 sürümü ile gelen SCAN(Single Class Access Name), küme içindeki her bir düğüm isminin istemciler tarafından bilinmesine gerek kalmadan, en optimal iş yükünün otomatik olarak DBA'ye ihtiyaç duymadan hesaplanarak, istemcinin en uygun düğüme yönlendirilmesini sağlayan bir prosesdir. Bu sayede istemci tarafındaki yük dengelemesi yönetimi DBA ler için ızdırap olmaktan çıkıp, clusterware tarafından otomatik olarak yönetilmektedir. Sunucu tarafındaki yük dengelemesi ise, talep edilen servis için en az yüklü instance bulmak amacıyla SCAN tarafından kontrol edilir ve bu düğümün lokal listenerına bu talep yönlendirilir. Rol bazlı veritabanı servisleri, Oracle Clusterware veya Oracle Restart içerisinden yapılandırılır. Oracle Dataguard,  Oracle Clusterware veya Oracle Restart ile etkileşime geçerek primary-standby rol değiş tokuşu sonunda gerekli servislerin aktif olmasını sağlar, böylece sistemi başlatma olayı için herhangi bir trigger yazılmasınada gerek kalmaz. Yapılandırma adımları için daha önceki yazılarıma bakabilirsiniz.

Aşağıdaki örnekte 2 düğümlü RAC adlı primary veritabanında “HR_APP” adlı servis primary rolde aktiftir. 2 düğümlü RACSTD adlı standby veritabanında da “HR_REPORT” adlı servis ise raporlama hizmetleri yapmak üzere fiziksel standby rolünde aktiftir.

[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_APP -l PRIMARY -q TRUE -e SELECT –m BASIC -w 10 -z 150

[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_REPORT -l PHYSICAL_STANDBY -q TRUE –e SELECT -m BASIC -w 10 -z 150

Herhangi bir switchover/failover durumunda HR_APP servisinin primary olarak hizmet vermeye devam etmesi için RACSTD adlı standby veritabanındada aşağıdaki gibi servisler eklenmiştir.

Oracle 11g R2 (11.2.0.2) RAC mimarisinde Data Guard kurulumu ve yönetimi

Bu yazıda Oracle 11g R2 RAC mimarisini hem primary hemde standby veritabanı olarak kullanarak, cluster çapında Data Guard yapılandırmasını ve yönetim tekniklerini inceleyeceğiz. Aslında bu incelemeyi migration testleri kapsamında 2010 Temmuz ayında Hollanda’da datacenterımızda yapmıştım, bu sebeple o zamanki test sonuç analiz notlarımı bulup harmanlayarak bu yazıyı hazırladım. Ancak unutmadan belirtmek isterim, Swingbench adlı stres testi aracı ile 1,000 kadar sanal kullanıcıya oturum açtırıp eşzamanlı hem primary siteden INSERT-UPDATE işlemleri  yapıp hemde standby siteden SELECT  sorgularını sorunsuz yapabildiğimi söyleyebilirim ve bu sürede cluster CPU, bellek ve I/O performanslarıda oldukça iyiydi.

Bu inceleme için o tarihte kullandığım fiziksel kaynaklar; 4 adet Sun SPARC Enterprise M3000 Server ve 1 adet Sun Storage 6180 Array ünitesinden oluşmaktadır. Sunucularda, Oracle Enterprise Linux 5.4 ve Oracle 11.2 Grid Infrastructure yazılımı kurulu ve Oracle depolama sistemi olarak Oracle ASM kullanılmaktadır.

RAC kullanılacak olan primary ve standby sitelerindeki sunuculara Oracle 11gR2 GI ve RDBMS yazılımlarının kurulmuş olmalıdır. Primary sitede ayrıca bir RAC veritabanının hizmet veriyor olması gerekmektedir. Daha önce yayınlanan Oracle 11g R2 RAC kurulum adlı yazıyı referans alarak clusterware kurulumunu 2 farklı sitede ve 2 ayrı yapıda aşağıdaki mimaride gerçekleştiriyoruz.

Benim yukardaki sistemimde;

LINUX1_RACPRIM à RAC1 adlı instance içermektedir

LINUX2_RACPRIM à RAC2 adlı instance içermektedir

-----------------------------------------------------------------------------------

Primary site içerisinde RAC adlı cluster primary veritabanını bulunur ve SCAN adresi rac-scan olmuştur. DATA ve DGSTDBY adlı ASM diskgruplar mevcuttur.

LINUX1_RACSTD à RACSTD1 adlı instance içerecektir.

LINUX2_RACSTD à RACSTD2 adlı instance içerecektir.

----------------------------------------------------------------------------------------------

Standby site içerisinde RACSTD adlı cluster standby veritabanını bulunacaktır ve SCAN adresi racstd-scan olacaktır. DATA adlı disk grubu önceden mevcuttur.

Önce isterseniz RAC ve Dataguard ne anlama gelmekte ve her ikisi birlikte kullanıldığında ne gibi avantajlar sağlanmaktadır.

Oracle 11g R2 RAC yapısında düğümlerin birinde oluşan “CRS-0184 Cannot communicate with the CRS daemon” hatası ve çözümü

Oracle Grid Infrastructure ve Oracle yazılım kurulumu başarılı şekilde tamamlandı ve Oracle RAC veritabanı oluşturuldu. Kurulumdan CRS hizmetlerini kontrol ederken servislerin başarılı şekilde online durumda olduğunuda görmekteyiz.

# crsctl check crs

CRS-4638: Oracle High Availability Services is online

CRS-4537: Cluster Ready Services is online

CRS-4529: Cluster Synchronization Services is online

CRS-4533: Event Manager is online

Ancak, ne oluyorsa cluster içindeki ikinci düğümü yeniden başlattıktan sonra oluyor. Birinci düğümde cluster hazır servisi(crs) başarıyla çalışmasına rağmen ikinci düğümde bir türlü başlayamıyor. Aşağıda örnekte 2. düğümün CRS durumu yer alıyor.

# crs_stat -t

CRS-0184: Cannot communicate with the CRS daemon.

Oracle 11g R2 RAC mimarisinde "server pools"

Sunucu havuzları(server pools) Oracle 11g R2 ile yeni gelen özelliklerden bir tanesidir ve cluster ortamında iş yükünün mantıksal dağıtımı ile ilgili clouding(bulut) teknolojisi hizmetleri getirmektedir. Sunucu havuzlarının kullanımının sağlanması, ilke bazlı(policy based) cluster yönetimi adı altında bir metot ile sağlanmaktadır.Hem uygulamaları, hemde veritabanları ilke bazlı yönetilebilmektedir. Bunun için RDBMS sürümünün 11.2.0 veya üzeri olması gereklidir.

Sunucu havuzu, aslında RAC ortamında clusterware hizmetinde arzu edilen mantıksal işyükünü sağlayacak olan düğüm sayısını optimal seviyede tutarak(aktif/aktif), varsa diğer düğümleride yedekte bekleterek(pasif), bir felaket anında <- havuz içindeki düğümlerden birisi erişilemez olursa -> bu yedekteki düğümü havuza dahil ederek mantıksal işyükünü her daim optimal seviyede bulundurmayı sağlamaktadır. Bu şekilde, havuzlar mantıksal olarak işlevsellik yapmakta olup, aslında kümelerin cluster içindeki yönetimini sağlamaktadır.

Sunucu havuzu mimarisi 4 bölümden oluşmaktadır;

-  Sunucu havuz ismi

-  Havuz içinde bulunacak minimum sunucu sayısı

-  Havuz içinde bulunacak maksimum sunucu sayısı (varsayılan değer 0’dır)

-  Sunucu havuzları arasındaki öncelik oranı (varsayılan değer 0’dır)

Sunucu havuzu mimarisinde yukardaki bölümlerin ne anlama geldiğine bakalım.Farzedinki, 6 düğümlü cluster sisteminizde 2 tane farklı RAC veritabanı vardır, her zaman 1 düğümün pasif olarak yedekte beklemesini ve düğümlerden birisi down olduğu zaman bu boştaki düğümün havuza dahil olmasını istiyoruz. Birinci RAC veritabanında arzu edilen işyüküne cevap vermesi için en fazla 3 düğümün işleme girmesini, ikinci RAC veritabanında arzu edilen işyükü 2 düğümle karşılanabilecektir. Bu maksatla sunucu havuzları aşağıdaki gibi düzenlenmektedir.

Sunucu havuzu adı= POOL1               Sunucu havuzu adı= POOL2
MIN_SERVERS = 2                              MIN_SERVERS = 2
MAX_SERVERS=3                               MAX_SERVERS= 2
ÖNCELİK=3                                         ÖNCELİK=2

Yukardaki iki sunucu havuzunda önceliği yüksek olan sunucu havuzu POOL1 olduğundan dolayı(değeri yüksek olan yüksek önceliklidir) cluster hizmet sırasındaki ilk 2 düğüm POOL1 sunucu havuzuna kayıt olacak, sonraki 2 düğüm POOL2 sunucu havuzuna kayıt olacaktır. Cluster öncelik listesindeki 5. düğüm MAX_SERVER değeri 3 olan POOL1 havuzuna kayıt olacaktır. 6. düğüm ise boşta bekleyecektir.

rac1, rac2,rac5 --> POOL1
rac3, rac4 --> POOL2
rac6 --> free

Oracle 11g RAC mimarisinde GCS ve GES performansını izleme ve iyileştirme tavsiyeleri

Oracle 11g RAC mimarisinde performans izleme ve iyileştirme noktasında GCS ve GES servislerinin iyileştirilmesi, private bağlantının(interconnect) network performansının artırılması önem kazanmaktadır. Bunları detaylı olarak aşağıda incelemeye başlayalım.

Global Cache Services(GCS) kalıcı okumalarının(cr) izlenmesi

Kalıcı okumaların(consistent read-cr) performansını izlemek için alttaki formül kullanılır.

 (gc cr block receive time × 10) / (gc cr blocks received)

Yukardaki formulün sonucunda instance için milisaniye değerinde kalıcı blok okuması taleplerinin ortalama zamanı dönmektedir ve Enterprise Manager RAC performans görünümlerinde gözlemlediğimiz global bellek blok transfer oranı (Global Cache Block Transfer Rate) metrikidir. Bu değer interconnect performansını belirlemek için kullanılan en önemli değerdir.

Veri blokları için global kaynak talepleri, talep eden instance’ın ön belleği içinde meydana gelir. Talep, GCS talep kuyruğuna girmeden önce Oracle, SGA içinde talebin durumunu izleyecek ve bu kaynak yapıları üzerinde istatistik toplayacak veri yapılarını tahsis eder.

SQL> SELECT

> gc_cr_block_receive_time AS "Receive Time",

> gc_cr_blocks_received AS "Blocks Received",

> (gc_cr_block_receive_time * 10) /

> gc_cr_blocks_received AS "Average Latency (MS)"

> FROM

> (

> SELECT value AS gc_cr_block_receive_time FROM v$sysstat

> WHERE name = 'gc cr block receive time'

> ),

> (

> SELECT value AS gc_cr_blocks_received FROM v$sysstat

> WHERE name = 'gc cr blocks received'

> );

Alttaki sonuç yukardaki raporun çalışması sonucu alınan bir örnek sonuçtur:

Receive Time   Blocks Received          Average Latency (MS)

--------------         --------------------           --------------------

5405                    3869                            23.9681803

Oracle 11g RAC "Cache Fusion" Teknolojisi

Oracle RAC veritabanı sisteminde iki önemli servis vardır. Bunlar  Global Cache Service (GCS) ve Global Enqueue Service (GES) dir. Bu ikisi temelde arkaplan proseslerinin koleksiyonudur. Her iki proses birlikte toplam "cache fusion" prosesini, kaynak transferlerini ve instancelar üzerinden kaynak tırmanmasını kapsar ve yönetir.

Global Kaynak Dizini (Global Resource Directory)

GES ve GCS prosesleri beraberce, kaynak ve kuyruğa ekleme bilgilerini kaydetmek için Global Kaynak Dizinini(GRD) oluştururlar. GRD, bellek içinde yer alır ve tüm instanceler üzerinde saklanır. Her instance dizinin bir parçasını yönetir.Bu dağıtık sadelik, RAC’ın fault tolerance yapısı için anahtar noktayı oluşturmaktadır.

Global Kaynak Dizini (GRD), veri bloklarının mevcut durumunu kaydeden ve saklayan dahili bir veritabanıdır. Bir blok, bulunduğu instance içindeki lokal bellekten diğer instance’ların belleğine transfer olur olmaz GRD güncellenir. GRD içinde aşağıdaki kaynak bilgileri yer almaktadır.

OE Linux 5.3 üzerine iki düğümlü Oracle 11g R2 RAC kurulumu - adım adım

OE Linux 5.3 üzerine iki düğümlü Oracle 11g R2 Real Application Clusters(RAC) kurulumu 4 safhaya ayırmaktayım.

A. Linux üzerinde kurulum öncesi yapılandırma.

B. Oracle Grid Infrastructure yazılımının kurulumu.

C. Oracle Database yazılımının kurulumu.

D. Oracle veritabanı oluşturma.

Her bir adımın uygulamasına geçmeden önce Oracle 11g R2 RAC konseptine kısa bir göz atalım.

Oracle 11g R2 RAC mimarisi konsepti ve gelen yenilikler

Oracle Database 11g Release 2 itibariyle, Oracle Clusterware ve Oracle ASM, grid home olarak adlandırılan aynı tekil dizine kurulmaktadır. Oracle grid mimarisi kombine ürünlerin kurulumuyla adlandırılmaktadır. Ancak, Oracle Clusterware ve Oracle ASM ayrı ürünlerdir.

Oracle Clusterware sunuculara host veya düğümler olarak bakarak birden fazla sunucunun tek bir sunucu gibi işlev görmesine imkan vermektedir. Halbuki sunucular bağımsızdır ve her bir sunucunun diğer sunucular ile iletişimini sağlamak için ilave prosesleri vardır. Bu şekilde tek bir veritabanı birden fazla sunucunun üzerinde düğümler olarak adlandırılan yapıda çalışırken her bir sunucunun donanım kaynakları ayrı ayrı paylaşımda olmaktadır. Böylece birden fazla sunucudan oluşan düğümlerde paylaşımlı bellek ve prosesleri için tahsis edilen kaynaklar düğüm sayısına parallel arttığından bellek ile proses tahsis ve kullanım performanslarındada iyileşmeler meydana gelmektedir. Oracle Clusterware yazılımı Oracle Real Application Clusters hizmetinin çalışması için gerekli mimariyi desteklemektedir.

Oracle 11g R2 RAC veritabanının başka bir sunucuya single instance veritabanı olarak kopyalanması

Oracle 11g sürümü herhangi bir yedek kullanmadan Oracle Net yoluyla veritabanın kopyalanmasına imkan vermektedir. Bunun için kaynak veritabanının açık ve arşiv log özelliği etkin olmalıdır veya temiz bir kapatma sonrasında MOUNT modda açık tutulmalıdır.

Bu yazıda çift düğümlü Oracle 11.2 RAC veritabanının, başka bir sunucuda tekil instance olarak çalışmak üzere kopyalanması işlemini adım adım yapılandıracağız.

$ olsnodes -n
rac1    1
rac2    2

RAC veritabanında iki tane ASM disk grubu vardır;

Verilerin tutulduğu diskgrubu:+DATA

flash recovery alanı: +FLASH

1. Kopyalanacak veritabanın bulunacağı sunucu üzerinde Oracle yazılımı (Enterprise veya Standard, kaynak ile aynı olmalı) yüklenmelidir. Yükleme için blogta yazılarım mevcuttur. Aynı zamanda audit trail (adump dizini) ve kontrol dosyalarının tutulacağı fiziksel dizinin oluşturulması gerekmektedir.

RAC veritabanına yeni bir ASM disk eklerken karşılaşılan sorunlar

Solaris 10 üzerinde çalışan bir RAC veritabanına yeni bir ASM disk eklemeye çalışıldığında aşağıdaki gibi hata mesajları ile karşılaşabilir ve muhtemelen bu yeni ASM diski ekleyemeyiz.

ORA-15075 “disk(s) are not visible cluster-wide”

ORA-15020 “discovered duplicate ASM disk “DISK1″ and

ORA-15054 “disk “ORCL:DISK1″ does not exist in diskgroup “DG1″.

Disk grubunu yeniden dengelemek(rebalance) veya nomount-mount işlemi yapmak veya FORCE takısını kullanarak bu yeni diski ilave etmekte sonuç vermeyebilir. Bu durumu bir senaryoda uygulayarak nasıl çözüme kavuşturacağımıza bir göz atalım.

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.

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)

Adım adım yeni voting disk ilavesi

1. RAC veritabanını durdurun

$ srvctl stop database -d RACDB

2. Tüm düğümlerdek, nodeapps servisini durdurun

$ srvctl stop nodeapps -n rac1

$ srvctl stop nodeapps -n rac2

3. Tüm düğümlerde Oracle Clusterware servisini root hesabından oturum açarak durdurun

# crsctl stop crs

RAC mimarisinde zamanlanmış görevler ile servisleri bağlama

Oracle 10g Scheduler servisi, görevlerin görev sınıflarına(job classes) bağlanabilmesine ve bununla beraber RAC içindeki tanımlanan düğümlerdeki servislerede bu görevlerin çalışması için bağlanabilmesine imkan vermektedir.  Görevler ve ilgili RAC servislerinin ilişkilendirilmesinde uygulanacak adımlar alttaki senaryoda yer almaktadır.

RAC veritabanında kontrol dosyası oluştururken ORA-01503 ve ORA-12720 hataları

RAC veritabanında kontrol dosyasını oluştururken alttaki hata mesajı alınabilir.

CREATE CONTROLFILE REUSE SET DATABASE "RACDB" RESETLOGS FORCE LOGGING ARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-12720: operation requires database is in EXCLUSIVE mode

Çözümü: alter system set cluster_database=false scope=spfile;

RAC mimarisinde Transparent Application Failover (TAF)

Bu yazı "Oracle 10g RAC mimarisinde gelişmiş yük dengeleme" adlı yazımın devamıdır. TAF(şeffaf uygulama yük devri), OCI sürücüsünün çalışma süresi özelliğidir. Çalıştırdığınız uygulamanın başlangıç bağlantısı düştüğü zaman otomatik olarak servise yeniden bağlanmasını sağlar. Yeniden bağlanırken, işlemlerin geri alınmasına rağmen, o an işlem gören SELECT işleminin çalışmasını opsiyonel olarak kaldığı yerden devam ettirir. TAF iki şekilde yük devreder:

•       BASIC metodu ile yeniden bağlantı yük devri süresinde saptanır. Servis tüm düğümlerde başladıktan sonra başlangıç bağlantısı sağlanır. Listener bağlantıyı saplar ve herhangi bir sebepten dolayı bağlantı düşene kadar çalışan uygulama Oracle 10g veritabanına erişir. Çalışan uygulama bir sonraki sefer veritabanına erişmeyi deneyene kadar hata alır. Sonra, OCI sürücüsü aynı servise tekrar bağlanmayı dener, uygulama bir sonraki sefer veritabanına erişmeyi denerken şeffaf olarak yeni oluşturulan bağlantıyı kullanır. TAF, çok hızlı şekilde düşme olaylarını tespit ederek yük devrinde FAN olaylarının alımını etkinleştirebilir.

•        PRECONNECT metodu BASIC metodu ile benzerlik gösterir. Tek farkı; PRECONNECT'in gölge bağlantının aynı zamanda yük devrini önceden kestirmek için oluşturduğu başlangıç bağlantısı esnasında olmasıdır. TAF, otomatik olarak oluşturulan ve sürdürülen gölge servisi kullanarak gölge bağlantının her zaman servisinizin en uygun instancelarında oluşturulmasını garanti altına alır.

Oracle 10g RAC mimarisinde gelişmiş yük dengeleme

Oracle 10g RAC mimarisinde yük dengeleme 2 farklı yoldan yapılandırılabilir. Bunlar;

1. İstemci tarafında bağlantıları dengeleme
2. Sunucu tarafında bağlantıları dengeleme

Şimdi bu her iki yük dengeleme metodunun farklılıkları ve performans üzerindeki etkilerini örneklerle inceleyelim.