Arşiv

Yazar Arşivi

12c ASM Veritabanından ASM Olmayan Veritabanına RMAN Restore Yavaşlık Sorunu

12.1 ASM kullananan bir veritabanından aldığımız RMAN yedeği, MOUNT modunda ASM olmayan bir veritabanına geri dönmek istediğimizde uzun bir süre beklediğini gördüm.

RMAN-03090: Starting restore at 2015-11-09 15:01:53
RMAN-08030: allocated channel: ORA_AUX_DISK_1
RMAN-08500: channel ORA_AUX_DISK_1: SID=1 device type=DISK

RMAN-08021: channel ORA_AUX_DISK_1: restoring control file
RMAN-08180: channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
RMAN-08505: output file name=/oradata/C12102/controlfile/control01.ctl

RMAN-03091: Finished restore at 2015-11-09 15:01:55

Control file başarılı restore edildikten sonra veritabanı restore işleminin başlaması 20-30 dk. civarında bekliyor.

RMAN-03090: Starting restore at 2015-11-09 15:21:59
RMAN-12016: using channel ORA_AUX_DISK_1
RMAN-12016: using channel ORA_AUX_DISK_2
RMAN-12016: using channel ORA_AUX_DISK_3
RMAN-12016: using channel ORA_AUX_DISK_4

Bu esnada alert log dosyasına aşağıdaki mesaj ara ara devamlı basıldığını gözlemledim.

WARNING: failed to start ASMB (ASM instance not found)

Errors in file /opt/oracle/diag/rdbms/c12102/C12102/trace/C12102_asmb_24847.trc:
ORA-15077: could not locate ASM instance serving a required diskgroup
ORA-29701: unable to connect to Cluster Synchronization Service
WARNING: ASMB exiting with error

Bu sorunun sebebi 19503821 numaralı BUG ‘dır ve çözümü için 19503821 numaralı patchin yüklenmesi gerekmektedir.

Reklamlar

RMAN Restore Esnasında Karşılaşılan ORA-01180 ve ORA-01110 Hataları

Merhaba,

Canlı veritabanından alınan full veritabanı yedeğini test veritabanına geri dönerken system datafile ‘ı ile ilgili aşağıdaki hata ile karşılaştık. Son control dosyasının restore edildiğinden ve elimizdeki yedeklerin catalog edildiğini kontrol ettikten sonra iki kere daha denedim. Fakat aynı hatayı aldık.

Starting restore at 10-OCT-17
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
using channel ORA_DISK_5
using channel ORA_DISK_6
using channel ORA_DISK_7
using channel ORA_DISK_8

creating datafile file number=1 name=/DATA/alfa/datafile/system01.dbf
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 10/10/2017 01:08:29
ORA-01180: can not create datafile 1
ORA-01110: data file 1: ‘+DATAC1/ALFA/DATAFILE/system.319.922730217’

Oracle Metalink üzerinde hataları arattığınızda aşağıdaki 2 döküman işinizi çözecektir.

RMAN restore fails with ORA-01180: can not create datafile 1 (Doc ID 1265151.1)
RMAN restore of database fails with ORA-01180: Cannot create datafile 1 (Doc ID 1573040.1)

Bir önceki incarnation numarasına reset yapıp, tekrar restore işlemini deneyelim.

SQL> select INCARNATION#, RESETLOGS_TIME from v$database_incarnation order by RESETLOGS_TIME desc;

INCARNATION# RESETLOGS
———— ———
2 22-MAY-17
1 16-SEP-16

rman target /

RMAN> reset database to incarnation 1;

RMAN> restore database;

FRA alanı ile birlikte backup controlfile kullanılırsa, FRA alanı için implicit crosscheck  işlemi yapılır ve controlfile dosyasındaki tüm bilgiler kataloglanır. Resetlogs işlemi sonrasında oluşan arşiv dosyaları yeni bir incarnation oluşturur. Yeni bir incarnation oluşmasından dolayı önceki incarnation ‘a ait yedekleri yeni incarnation üzerinde dönemezsiniz.

 

Reset işlemi sonrası veritabanımızı başarılı bir şekilde geri dönebildik.

Reset ve restore işlemleri öncesi spfile veya pfile dosyasından FRA parametrelerini silerekte sorunu çözebilirdik. FRA parametreleri yerine  log_archive_dest_1 parametresini arşiv lokasyonu olarak set etmemiz yeterli olacaktır.

Oracle OEM 13c Agent Manüel Nasıl Yükleriz?

1- Öncelikle OMS Server üzerinden agent yazılımını indirmemiz gerekiyor. SYSMAN kullanıcı ile login olalım.ysman.

[oracle@isu13c bin]$ ./emcli login -username=sysman
Enter password :

Login successful

[oracle@isu13c bin]$ ./emcli sync
Synchronized successfully

2- Desteklenen platform listesine bakalım.

[oracle@isu13c bin]$ ./emcli get_supported_platforms
———————————————–
Version = 13.1.0.0.0
Platform = Linux x86-64
———————————————–
Platforms list displayed successfully.

3- Agent yazılımını indirelim.

[oracle@isu13c bin]$ ./emcli get_agentimage -destination=/tmp/agentinstaller -platform=”Linux x86-64″
=== Partition Detail ===
Space free : 53 GB
Space required : 1 GB
Check the logs at /u01/app/oracle/gc_inst/em/EMGC_OMS1/sysman/emcli/setup/.emcli/get_agentimage_2018-04-25_12-12-30-PM.log
Downloading /tmp/agentinstaller/13.1.0.0.0_AgentCore_226.zip
File saved as /tmp/agentinstaller/13.1.0.0.0_AgentCore_226.zip
Downloading /tmp/agentinstaller/13.1.0.0.0_Plugins_226.zip
File saved as /tmp/agentinstaller/13.1.0.0.0_Plugins_226.zip
Downloading /tmp/agentinstaller/unzip
File saved as /tmp/agentinstaller/unzip
Executing command: /tmp/agentinstaller/unzip /tmp/agentinstaller/13.1.0.0.0_Plugins_226.zip -d /tmp/agentinstaller
Exit status is:0
Agent Image Download completed successfully.

4- İndirdiğimiz agent yazılımını, yükleyeceğimiz sunucuya kopyalayalım ve unzip edelim.

scp 13.1.0.0.0_AgentCore_226.zip oracle@172.16.3.29:/DATA/install

unzip 13.1.0.0.0_AgentCore_226.zip

5-Agent yazılımını artık yükleyebiliriz.

mkdir /u01/app/oracle/agent
./agentDeploy.sh AGENT_BASE_DIR=/u01/app/oracle/agent \
-force \
-ignorePrereqs \
-invPtrLoc /etc/oraInst.loc \
AGENT_PORT=3872 \
EM_UPLOAD_PORT=4903 \
OMS_HOST=isu13c \
ORACLE_HOSTNAME=oracledrs \
AGENT_INSTANCE_HOME=/u01/app/oracle/agent/agent_inst \
AGENT_REGISTRATION_PASSWORD=xxxxxx \
SCRATCHPATH=/tmp

Yükleme tamamlandıktan sonra root.sh scriptini root kullanıcısıyla çalıştırmayı unutmayınız.

Agent çalışır durumda hazırdır.

/u01/app/oracle/agent/agent_13.1.0.0.0/bin/emctl status agent
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
—————————————————————
Agent Version : 13.1.0.0.0
OMS Version : 13.1.0.0.0
Protocol Version : 12.1.0.1.0
Agent Home : /u01/app/oracle/agent/agent_inst
Agent Log Directory : /u01/app/oracle/agent/agent_inst/sysman/log
Agent Binaries : /u01/app/oracle/agent/agent_13.1.0.0.0
Core JAR Location : /u01/app/oracle/agent/agent_13.1.0.0.0/jlib
Agent Process ID : 64876
Parent Process ID : 64751
Agent URL : https://oracledrs:3872/emd/main/
Local Agent URL in NAT : https://oracledrs:3872/emd/main/
Repository URL : https://isu13c.localdomain:4903/empbs/upload
Started at : 2017-11-21 09:51:57
Started by user : oracle
Operating System : Linux version 4.1.12-37.4.1.el6uek.x86_64 (amd64)
Number of Targets : 7
Last Reload : (none)
Last successful upload : 2018-04-25 13:22:43
Last attempted upload : 2018-04-25 13:22:43
Total Megabytes of XML files uploaded so far : 172.1
Number of XML files pending upload : 0
Size of XML files pending upload(MB) : 0
Available disk space on upload filesystem : 59.73%
Collection Status : Collections enabled
Heartbeat Status : Ok
Last attempted heartbeat to OMS : 2018-04-25 13:23:53
Last successful heartbeat to OMS : 2018-04-25 13:23:53
Next scheduled heartbeat to OMS : 2018-04-25 13:24:53

—————————————————————
Agent is Running and Ready

Veridata ve LinkPlus ile Oracle Sistem Sohbetleri

Ne Zaman Hangisini Kullanmalıyım? LOGGING mi? NOLOGGING mi?

10/04/2018 2 yorum

Ne Zaman Hangisini Kullanmalıyım? LOGGING mi? NOLOGGING mi?

LOGGING kelimesi tablo, index veya tablespace oluştururken kullandığımız anahtar kelimedir. Objeyi oluştururken LOGGING kullanırsak ilgili obje üzerindeki DML işlemleri redo log dosyasında loglanır. NOLOGGING kullanılırsa log üretimi bazı durumlarda yapılmaz. LOGGING/NOLOGGING üzerine forumlarda bir çok soru sorulmaktadır. Sorulardan bazıları şu şekilde: NOLOGGING avantajı nedir? Ne zaman NOLOGGING kullanmalıyız? Tablespace düzeyinde NOLOGGING kullanıldıysa, bu tablespace içindeki tablolarımız LOGGING olabilir mi?

Tablespace seviyesindeki LOGGING/NOLOGGING kelimesi sadece bu tablespace içinde oluşturulacak objelerin varsayılan LOGGING durumunu tablespace ‘den miras (inherit) alması içindir. Şimdi test yaparak tek tek inceleyelim.

Önce NOLOGGING kullanarak NOLOGGING_TS adında bir tablespace oluşturuyorum.

CREATE TABLESPACE NOLOGGING_TS DATAFILE

‘/data_TALIPDB/nologging_ts.dbf’ SIZE 1024M AUTOEXTEND OFF

NOLOGGING

ONLINE

PERMANENT

EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M

BLOCKSIZE 8K

SEGMENT SPACE MANAGEMENT AUTO

FLASHBACK ON;

Şimdi oluşturduğumuz NOLOGGING_TS tablespace içinde aşağıdaki gibi bir tablo oluşturalım ve tablo scriptimizde LOGGING/NOLOGGING ifadesini kullanmayalım;

CREATE TABLE talip_deneme (

id NUMBER

)

TABLESPACE nologging_ts;

Aşağıdaki sorgu ile baktığımızda tablomuzun NOLOGGING (LOGGING=NO) olarak oluşturulduğunu görürüz.

SELECT table_name, logging

FROM dba_tables

WHERE tablespace_name = ‘NOLOGGING_TS’

TABLE_NAME LOGGING

—————————— ——-

TALIP_DENEME NO

Şimdi de tablomuzu aşağıdaki gibi LOGGING ifadesini kullanarak, oluşturduğumuz NOLOGGING_TS tablespace içinde oluşturalım.

CREATE TABLE talip_deneme2 (

id NUMBER

)

TABLESPACE nologging_ts

LOGGING;

Yukarıdaki sorgu ile baktığımızda tablomuzun LOGGING (LOGGING=YES) olarak oluşturulduğunu görürüz.

SELECT tablespace_name, logging

FROM dba_tables

WHERE table_name = ‘TALIP_DENEME2’

TABLE_NAME LOGGING

—————————— ——-

TALIP_DENEME NO

TALIP_DENEME2 YES

O halde tablespace seviyesinde LOGGING/NOLOGGING kelimesinin kullanılması, bu tablespace içinde oluşturulacak objelerin varsayılan loglama durumunu tablespace ‘den alması içindir.

NOLOGGING olarak oluşturulan bir tablo sonradan aşağıdaki gibi LOGGING yapılabilir. Veya tam tersi de olabilir.

ALTER TABLE talip_deneme LOGGING;

ALTER TABLE talip_deneme2 NOLOGGING;

Bu durum tablespace içinde geçerlidir. NOLOGGING olarak oluşturulan bir tablespace sonradan aşağıdaki gibi LOGGING yapılabilir. Veya tam tersi de olabilir.

ALTER TABLESPACE nologging_ts LOGGING;

Bu durumda tablespace içinde önceden oluşturulan NOLOGGING objeler, NOLOGGING olarak devam edecektir. Bu tablespace içinde yeni oluşturulacak objelerin varsayılan loglama durumu LOGGING olacaktır. Yazımın başında NOLOGGING kullanılırsa log üretim işlemi bazı durumlarda yapılmaz demiştim. NOLOGGING kullanılırsa bazı durumlarda log üretimi devam edebilir. Peki bu durumlar nelerdir?

Tablo Log Durumu Insert Modu Arşiv Modu Redo Log üretimi
LOGGING APPEND ARCHIVE LOG REDO Üretilir
NOLOGGING APPEND ARCHIVE LOG REDO Üretilmez
LOGGING No APPEND ARCHIVE LOG REDO Üretilir
NOLOGGING No APPEND ARCHIVE LOG REDO Üretilir
LOGGING APPEND NO ARCHIVE LOG REDO Üretilmez
NOLOGGING APPEND NO ARCHIVE LOG REDO Üretilmez
LOGGING No APPEND NO ARCHIVE LOG REDO Üretilir
NOLOGGING No APPEND NO ARCHIVE LOG REDO Üretilir

SQL*Loader veri yükleme yöntemlerinden birisi olan “Direct Path Load” işlemleri NOLOGGING bir tabloda redo log üretmez. Veritabanında “force logging” yapılmışsa, yani loglamaya zorlanmışsa, her zaman (LOGGING veya NOLOGGING) redo log üretilir. Tablo LOGGING modunda olsa bile veritabanı arşiv modu NO ARCHIVE LOG ise, “Direct Path Load” işlemleri redo log üretmez. Veritabanı arşiv modu ARCHIVE LOG ise, tablomuz LOGGING modunda redo log üretir. Yine böyle bir durumda “Direct Path Load” işlemleri redo log üretir. Veritabanı arşiv modu ARCHIVE LOG olsa bile tablomuz NOLOGGING modunda redo log üretmez. Yine böyle bir durumda “Direct Path Load” işlemleri redo log üretmez.

“Direct Path Load” dediğimiz işlem, buffer cache ‘i geçerek direk disk ile işlem yapar.

Bir tabloyu NOLOGGING oluşturmak LOGGING olarak oluşturmaktan daha kısa sürer. Basit bir test yapalım. Önce “dba_tables” görüntüsünün (view) bir kopyasını oluşturmak isteyelim. Önce LOGGING olarak kopya oluşturalım ve işlem süresini görelim;

SQL> set timing on

SQL> create table talip_logging logging as select * from dba_tables;

Table created.

Elapsed: 00:00:01.20

Şimdi de NOLOGGING olarak kopya oluşturalım ve işlem süresini görelim;

SQL> create table talip_nologging nologging as select * from dba_tables;

Table created.

Elapsed: 00:00:00.60

Süreleri inceledğimizde NOLOGGING işlem daha kısa sürdüğünü görüyoruz.

NOLOGGING yapılacak objeler genelde verisi hiç değişmeyen, sabit objelerdir. Versi hiç değişmeyen parametrik tablolar, doldur/boşalt tablolar örnek olarak verilebilir. Bu tip objelerin mutlaka tam (full) yedeği alınmalıdır. Aksi takdirde kurtarma (recover) işlemini gerçekleştiremezsiniz. Son olarak aklınıza şöyle bir soru gelebilir. NOLOGGING olarak açılan bir tabloda bir kaydı yanlışlıkla silersek artık rollback yapamam gibi bir durum söz konusu değildir. Tablonuz NOLOGGING olsa bile, yanlışlık sildiğiniz bir kaydı rollback ile geri getirebilirsiniz. Çünkü bu işlem UNDO dediğimiz segmentlerle alakalıdır. LOGGING/NOLOGGING tamamen redo ile alakalı bir durumdur. Bu durum ile alakalı da bir örnek yapalım. Önce NOLOGGING bir tablo oluşturalım;

CREATE TABLE talip_deneme3 (

isim varchar2(10)

)

NOLOGGING;

Tablomuza bir kayıt girelim;

insert into talip_deneme3 values(‘talip’);

commit;

Kaydımızı silelim;

delete from talip_deneme3;

rollback;

select * from talip_deneme3;

rollback yaptığımızda tablomuz NOLOGGING olduğu halde verimizin geri geldiğini gördük. Demek ki rollback işlemi LOGGING/NOLOGGING ile alakalı değildir.

Talip Hakan Öztürk

RMAN Block Change Tracking ve “_bct_public_dba_buffer_size” Hidden Parametresi

10g ile gelen önemli özelliklerden biri olan “block change tracking”, alınan son yedekten itibaren değişen bloklar hakkında log tutar. Bir sonraki yedek esnasında değişen blokları tespit etmek için bütün veri dosyalarını taramak yerine “block change tracking” log dosyasını kullanır. Değişen blokların tespit edilmesi ve ilgili log dosyasına yazılması CTWR prosesi tarafından yapılmaktadır. Block change tracking aktif edilmesiyle RMAN daha performanslı çalışır.

Block Change Tracking aşağıdaki gibi aktif veya iptal edilir.

SQL>alter database enable block change tracking using file '/rman_bkups/change.log';

SQL>alter database disable block change tracking;

RMAN ile incremental yedek alma esnasında veritabanı performansına doğrudan etki eden ‘block change tracking buffer space’ beklemelerinin (wait event) olduğunu gözlemleyebilirsiniz. Bu bekleme özellikle büyük hacimli veritabanlarında gözlemlenmiştir. 10.2 ile 11.2 verisyonları arasındaki veritabanlarını etkilemektedir.

Bu problemin çözümü için metalinkde yayınlanan [ID 1311518.1] nolu dökümana göre aşağıdaki işlemler yapılmalıdır.

1- Block Change Tracking log dosyası çok fazla I/O gören verilerin bulunduğu diskde olmamalıdır.

2- Large_pool_size değeri gözden geçirilmeli, düşük ise artırılmalıdır.

3- Oracle ın gizli (hidden) parametresi “_bct_public_dba_buffer_size” set edilmeli.

Change tracking için ayrılmış olan memory alanı aşağıdaki sorgu ile bulabilirsiniz.

select dba_buffer_count_public*dba_entry_count_public*dba_entry_size
from  x$krcstat;

Elde edilen değer 2 ile çarpılarak “_bct_public_dba_buffer_size” parametresinin alacağı değer hesaplanabilir.

Obsolete Yedekler Silinirken RMAN-03002 ve RMAN-06091 Hatalarının Alınması

RMAN üzerinden obsolete yedekler silinilirken aşağıdaki hatalar alınabilir. Bunun sebebi disk yedeklerinin yanında tape yedeklerininde olması.

RMAN> delete obsolete;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of delete command at 02/04/2018 20:28:22
RMAN-06091: no channel allocated for maintenance (of an appropriate type)

Tape üzerindeki yedeklerin silinebilmesi için tape ‘e kanal açamamasından kaynaklı bir problemdir.

Çözüm için aşağıdaki gibi kanal açılması gerekmektedir. Hem tape hem de disk yedeklerini aynı anda silmek istiyorsak, aşağıdaki gibi ayrı ayrı kanal açmamız gerekir.

RMAN> allocate channel for maintenance type disk;
RMAN> allocate channel for maintenance device type ‘sbt_tape’ PARMS ‘…’;
RMAN> delete obsolete;

Sadece disk üzerindeki obsolete yeddekleri silmek istiyorsak, komutumuz aşağıdaki gibi olacaktır.

RMAN> allocate channel for maintenance type disk;
RMAN> delete obsolete device type disk;

%d blogcu bunu beğendi: