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.

SQLNET.EXPIRE_TIME parametresi ile inaktif bağlantıların sonlandırılması

Sqlnet.expire_time parametresi  istemci/sunucu arasındaki bağlantıların aktif olup olmadığını anlamak için hangi sıklıkta yoklayıcının gönderileceğini belirtmekte kullanılır ve dakika değerini temsil eder. Bağlantıların süresiz olarak açık bırakılmadığından emin olmak için bu parametresinin değerini 0 üzerinde belirtmeniz gerekmektedir. Oracle 10 dakikayı ideal olarak tavsiye etmektedir. Böylece 10 dakikaya erişen inaktif istemci bağlantıları sunucu prosesi tarafından otomatik olarak sonlandırılacaktır.

sqlnet.ora dosyası içine SQLNET.EXPIRE_TIME = 10 şeklinde eklenir.

sqlnet.expire_time parametresi kullanımı ile ilgili kısıtlamalar ise aşağıda yer almaktadır.

• sqlnet.expire_time parametresi IPC protokolü kullanan bağlantılarda çalışmaz.
• sqlnet.expire_time yoklayıcı paketi ilave network trafiği oluşturacağından dolayı bağlantı sayısına bağlı olarak network performansında düşüşler meydana getirebilecektir.
• Bağlantı yoklayıcısının ayırt edilmesi için muhtemelen ilave sunucu prosesleri devreye girecek ve böylece ilave bekleme olayları meydana gelebilecektir.

Standby veritabanına en son hangi redo logların uygulandığının gözlenmesi

Standby veritabanı üzerinde V$LOG_HISTORY görünümüne sorgu çekerek en son log sıra numarasındaki hangi kayıtların standby’a uygulandığını gözlemleyebiliriz.

SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG"
2> FROM V$LOG_HISTORY
3> GROUP BY THREAD#;

THREAD#    LAST_APPLIED_LOG
------------     ----------- ----------------
1                    745
Yukardaki örnekte 745 log sıra numarasına sahip arşiv redo log dosyası en son uygulanan kayıttır. Bunun yanında standby veritabanında V$ARCHIVED_LOG görünümünün APPLIED kolonu hangi logun standby’a uygulandığını listelemektedir.

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.

"ORA-32004 obsolete and/or deprecated parameter(s) specified" hata mesajı

"ORA-32004 obsolete and/or deprecated parameter(s) specified" hata mesajı ile karşılaşırsanız bunun sebebi spfile dosyanızda geçerli olmayan ve kullanılmayan başlangıç parametresinin olmasıdır.

Bu hata mesajından kurtulmak için önce hangi parametrelerin sistem tarafından kullanılmadığını görmemiz gerekmektedir.

SQL> select name, isspecified from v$obsolete_parameter where isspecified='TRUE';

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.

Paylaşımlı bellek ve semaforlar – Oracle

Veritabanı bazı durumlarda düzgün bir şekilde kapatılmadığında paylaşımlı bellek serbest bırakılmayabilir. Bu durumda oturum açmak istediğinizde veritabanı açılışında aşağıdaki hatayı alırsınız.

$ sqlplus /nolog
SQL> connect / as sysdba
ERROR:
ORA-03113: end-of-file on communication channel

Bu gibi sorunları çözmek için geçersiz Oracle prosesleri tarafından kilitlenmiş veya bloklanmış paylaşımlı bellek ve semaforları kontrol edebilirsiniz. Ancak bundan önce UNIX mimarisinde paylaşımlı bellek segmentlerinin ve semaforların ne olduğunu kısaca anlamak gerekiyor.

Oracle RAC mimarisinde public ve virtual IP adreslerinin değiştirilmesi

Mevcut konfigürasyon                                         Sonraki konfigürasyon
============================================================
Birinci düğüm:

Public IP:        216.160.37.154                              192.168.10.11
VIP:                216.160.37.153                              192.168.10.111
Subnet   :        216.160.37.159                               192.168.10.0
Netmask:        255.255.255.248                             255.255.255.0
Interface adı:   eth0                                                 eth0
Hostname:       rac1                                                rac1
============================================================
İkinci düğüm:

Public IP:         216.160.37.156                              192.168.10.22
VIP:                216.160.37.157                              192.168.10.222
subnet:             216.160.37.159                              192.168.10.0
Netmask:         255.255.255.248                           255.255.255.0
Interface adı:   eth0                                                 eth0
Hostname:       rac2                                                rac2

=============================================================

SRVCTL komutları ile Oracle RAC yönetimi

Server Control Utility(SRVCTL) komutları ile Oracle 10.1 RAC sürümünden itibaren alttakileri yapabiliriz.

• ASM instance işlemleri
• Veritabanını başlatmak ve durdurmak
• Veritabanının konfigürasyonunu kontrol etmek
• Veritabanının durumunu kontrol etmek
• Mevcut veritabanı konfigürasyonunu değiştirmek veya kaldırmak
• Yeni bir veritabanı konfigürasyonu eklemek
• Veritabanını etkinleştirmek veya devredışı bırakmak

Linux’ta “Huge Pages” yapılandırması

“Big/Huge pages” özelliği Oracle SGA gibi paylaşımlı bellekler için ne kadar fiziksel ardışık büyük bellek sayfalarının tahsis edilebileceğini ve RAM ‘e iliştirileceğini tanımlayan bir özelliktir. Örneğin,  her biri 2GB SGA’ya sahip 3 tane Oracle instance için en azından 6GB büyük sayfa(large pages) tahsis edilmelidir. Böylece, 3 SGA da büyük sayfa kullanacak ve ana fiziksel bellek içinde kalacaktır. Bununla beraber aynı sistem içinde eğer ASM kullanılırsa ilave olarak 200MB paylaşımlı belleğe ihtiyaç olacaktır. Tabi bunun yanında başka Oracle prosesleride ilave paylaşımlı belleğe ihtiyaç duyacaktır.

Dataguard mimarisinde redo log taşıma hizmetlerinin iyileştirilmesi

Redo taşıması için ne kadar bant genişliği yeterlidir?

Dataguard 3 çeşit redo taşıma metodu sunmaktadır: ARCH, LGWR ASYNC ve LGWR SYNC

Dataguard yapılandırmalarının amacı redo verisinin uzak siteye veritabanında bir felaket durumunda en kısa zamanda ve en son güncel durumdan eksiksiz geri kurtarma hizmeti vermektir. Eğer gerekli yoğunluğu ele alabilecek yeterli bant genişliği mevcut değilse hiç bir iyileştirme hizmeti sonuç vermez. Ne kadar bant genişliği kullanılacak sorusuna cevap vermek için ise, önce primary veritabanından ne kadar redo yoğunluğu olduğunun incelenmesi gerekmektedir.

Önbellekte gereksiz blok işgal eden indeksler

SQL cümlesinde kullanılan indeks tarafından çağrılan bloklar gerçekten SQL performansını iyileştirmektemi? Buna kesin olarak evet demek mümkün değil. Önbellekte blok işgal eden segmentlerin sahiplerini, tiplerini ve isimlerini bilmek SQL iyileştirme çalışmalarında oldukça kullanışlıdır. Bunun yanında hangi objelerin en fazla önbelleği işgal ettiğini yüzdesel olarak bilmekte SQL iyileştirme çalışmalarında nereye öncelikli olarak odaklanmamız gerektiğini bize gösterecektir. Bu sebeple öncelikle önbellekte o an bulunan indeksleri gözlemlemek gerekir. Burdaki soru, bu indeksler ilişkli tablo tarafından gerçekten kullanılmaktamıdır?

Oracle 10g veritabanı için Solaris sistemde TLB/TSB Misses ve Pages Fault oranlarının iyileştirmesi

TLB ve TSB terminolojisi 

Bir proses bellek talep ettiğinde bu talep için sadece sanal bellek ayrılılır. Fiziksel bellek henüz ayrılmamıştır. Bir proses bu ayrılan sanal bellek içindeki sayfaya(page)  erişim talep ettiğinde, sayfa hatası(page fault) oluşur. Sonuçta, bu prosesin sanal sayfasına boş listeden bir fiziksel sayfa ile eşleştirilir.

Bu eşleşme yazılım içindeki sanal bellek sistemi tarafından oluşturulur ve HAT Mapping Entries(HME) formunda HPT(Hash Page Tables) içinde saklanır. Ayrıca bunun bir kopyasıda TLB ve TSB içine Translation Table Entries(TTE) olarak girilir.

Solaris 10 üzerinde host ismi ve ip adresini değiştirme

Oracle 10g RAC(Real Application Clusters) kurulumunda, eğer Solaris 10 yüklü düğümlerin host isimlerini büyük harfle girmişseniz Oracle Clusterware yazılımı yüklemesinde hata mesajı alırsınız. Bu hata mesajından tek kurtuluş düğümün host ismini küçük harfli olarak alttaki gibi değiştirmektir. Bunun yanında, network adresini değiştirmek gerektiğindede bu düğümün ip adresini değiştirmek için alttaki adımları izleyebilirsiniz.

RMAN-03002, RMAN-03015, RMAN-06053,RMAN-06025 hata mesajları

Sorun:
RMAN-03002: failure of Duplicate Db command at 12/25/2010 04:15:24
RMAN-03015: error occurred in stored script Memory Script
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 21 lowscn 674529 found to restore
RMAN-06025: no backup of log thread 1 seq 20 lowscn 674626 found to restore
Sebebi: RMAN arşiv log geri yüklemesini varsayılan istikamete yapamıyor.

Çözümü:
DUPLICATE komutu kullanılırken NOFILENAMECHECK parametresini ekleyin.
DUPLICATE TARGET DATABASE TO "clonedb" NOFILENAMECHECK;

Oracle çalışan Linux/UNIX sistemlerde “Out of memory” hatası

Linux veya UNIX sistemlerde çalışan Oracle tabanlı uygulama için işletim sisteminde paylaşımlı belleğin serbest bırakılıp bırakılmadığını kontrol etmek için alttaki programı derleyin ve çalıştırın.