Arşiv

Archive for the ‘Oracle Araçlar’ Category

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.

Reklamlar

SQL Server Veritabanının Oracle Veritabanına SQL Developer ile Taşınması (Migration)

29/11/2012 3 yorum

Veritabanının taşınması (Migration), şema objeleri ve verinin üçüncü parti yani Oracle olmayan veritabanından (MySQL, Microsoft SQL Server, Sybase Adaptive Server, Microsoft Access, IBM DB2) Oracle veritabanına kopyalanması işlemidir.

MySQL, Microsoft SQL Server, Sybase Adaptive Server, Microsoft Access veya IBM DB2 veritabanlarından Oracle veritabanına taşıma işlemi SQL Developer ile aşağıdaki seçeneklerle kolay bir şekilde yapılabilmektedir.

– Migration Wizard ile taşıma

– İstenilen tabloların Oracle veritabanına kopyalanması

Migration Wizard ile Taşıma İşlemi

Migration Wizard, üçüncü parti veritabanının Oracle’a taşınması için gereken adımları tek bir ekran üzerinden yönetilmesini sağlar. Bu adımlar aşağıdaki gibidir;

– Kaynak veritabanının (MySQL, Microsoft SQL Server, Sybase Adaptive Server, Microsoft Access, IBM DB2) capture edilmesi,

– Oracle veritabanı formatına dönüştürülmesi,

– DDL scriptinin çıkarılması,

– Dönüştürme işleminin gerçekleştirilmesi.

Kısaca taşıma işlemi hakkında bilgi sahibi olduktan sonra birlikte basit bir taşıma işlemi yapalım.

1-   TALIPTEST adında örnek bir SQL Server veritabanı oluşturdum.

2-   İlk olarak taşıma işlemi için repository oluşturmamız gerekiyor.

Migration repository, SQL Developer ‘ın taşıma işlemi için gerekli metadata verisini yönetmek için kullandığı şema objeleri topluluğudur. Migration repository için uygun bir Oracle veritabanında aşağıdaki gibi bir şema oluşturmamız ve bu şemayada aşağıdaki yetkileri vermemiz yeterlidir.

CREATE USER MIGRATIONS IDENTIFIED BY “migration”

DEFAULT TABLESPACE USERS

TEMPORARY TABLESPACE TEMP;

grant create session to migrations;

grant resource to migrations;

grant create view to migrations;

Çoklu şema taşımaları için yetkiler WITH ADMIN seçeneği ile aşağıdaki gibi verilmeli.

grant resource to migrations with admin option;

grant create role to migrations with admin option;

grant alter any trigger to migrations with admin option;

grant create user to migrations with admin option;

3- SQL Developer uygulamasını http://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html adresinden indirelim.

4- sqldeveloper-3.2.20.09.87.zip adı ile zipli olarak indirilen dosyayı extract edelim ve sqldeveloper.exe dosyasına çift tıklayalım.

5- Connections üzerine sağ tıklayıp “New Connections” menüsüne tıklayalım.

6-  Migration_Repository adından yeni bir bağlantı oluşturalım. Bu bağlantı veritabanına daha önce oluşturduğumuz MIGRATIONS kullanıcısı ile bağlanacaktır.

7- Migration Repository oluşturmak için Migration_Repository bağlantısına sağ tıklayıp, “Migration Repository” menüsü altındaki “Associate Migration Repository” menüsüne tıklayalım.

8- MIGRATIONS şeması altında gerekli şema objeleri oluşturulacak.

9- Üçüncü parti (MySQL, Microsoft SQL Server, Sybase Adaptive Server, Microsoft Access, IBM DB2) veritabanına SQL Developer ile bağlanabilmemiz için ilgili veritabanı için JTDS sürücüsüne ihtiyacımız var. SQL Server için gerekli olan jTDS sürücüsünü http://sourceforge.net/projects/jtds/files/jtds/1.2/jtds-1.2-dist.zip/download adresinden indirelim. İndirdiğimiz jtds-1.2-dist.zip isimli zipli dosyayı extract edelim.

10- “Tools” menüsünden “Preferences” menüsüne tıklayalım.

11- Sol taraftaki panelden “Third Party JDBC Drivers” seçeneğini seçelim ve sağ taraftan “Add Entry” butonuna tıklayalım.

12- İndirdiğimiz sürücü klasöründeki jar dosyasını seçelim.

13- “Tamam” butonuna tıklayalım.

14- Artık SQL Developer ile SQL Server veya Sybase bağlantısı yapabiliriz. SQL Server veritabanımıza aşağıdaki gibi bağlanalım.

 15- Ve son olarak taşıma yapacağımız veritabanı bağlantımızı oluşturalım.

16- Migration Wizard değişik şekillerde çalıştırılabilir. “Connections” altında bulunan üçüncü parti veritabanına sağ tıklayıp “Migrate to Oracle” menüsünü tıklayabileceğimiz gibi “Tools>Migration>Migrate…” menüsünü de tıklayabiliriz.

17- “Next” butonu ile devam edelim.

18- Migration repository veritabanı bağlantımızı seçelim.

19- Taşıma projemize bir isim verelim ve çıktı dosyaları için bir dizin seçelim.

20– Üçüncü parti veritabanı bağlantımızı seçelim. Bizim örneğimizde SQL Server veritabanı bağlantısını seçelim. Online ve Offline taşıma yapabiliriz.Online seçersek herşey Migration Wizard ekranı ile yapılır. Offline seçersek dönüştürme işlemi için gerekli DDL scriptler çıkarılır. Ve proje çıktı klasörümüze kaydedilir.

21- Taşınacak SQL Server veritabanımızı seçelim.

22- Dönüştürme seçeneklerini belirleyelim. Ve “Advanced Options” linkine tıklayarak “Microsoft SQL Server : Is quoted identifier on” seçeneğinin işaretli olduğundan emin olalım.

23- Hedef veritabanı (Oracle) bağlantısını seçelim.

24- Offline seçecek olursak, önceki adımda belirttiğim gibi taşıma işlemi için gerekli işlemlerin DDL scripti proje çıktı klasörüne kaydedilir.

25- Online veri taşıma için kaynak ve hedef veritabanı bağlantılarını seçelim.

26- “Finish” butonu ile taşıma işlemini başlatalım.

27- Taşıma ve dönüştürme işlemi başlayacaktır.

Artık SQL Server veritabanımız Oracle ‘da.

İstenilen tabloların Oracle veritabanına kopyalanması

Üçüncü parti veritabanındaki kopyalacanak tablonun üzerine sağ tıklayalım ve “Copy To Oracle” menüsüne tıklayalım.

Hedef  (Oracle) veritabanı bağlantısını seçelim. “Include Data” seçeneğini seçersek hem tablo yapısı hemde tablo verisi taşınır.

Oracle veritabanına tablo koyalama işlemi tamamlanmıştır.

Not: Bu yöntemle sadece table yapısı ve verisi taşınır. Tablo üzerindeki indeks, trigger v.s. taşınmaz.

Migration projelerinizde gönlünüz ferah bir şekilde kullanabilirsiniz 😉 Keyifli taşımalar diliyorum 🙂

Talip Hakan Öztürk

Oracle Veritabanına Arka Kapıdan Giriş

11/06/2012 5 yorum

Merhaba Arkadaşlar,

Birkaç gün önce başıma gelen bir durumdan bahsetmek istiyorum. Veritabanlarımdan birisine login olurken asılı (hang) kaldım. Veritabanım yeni bağlantı kabul etmiyordu. Hemen veritabanı sunucusuna bağlandım ve listener durumunu kontrol ettim.

# lsnrctl status

Herşey normaldi. Listener veritabanımı dinliyordu. Zaten dinleyiciden gelen herhangi bir hata da almamıştım.

Busefer sunucu üzerinden “sqlplus / as sysdba” ile giriş yapmaya çalıştım ve yine başarısız oldum. Veritabanım bir problemden dolayı hiçbir bağlantıyı kabul etmiyordu. İşletim sistemi üzerinden çalışan arka plan işlemlerini kontrol ettim.

# ps -ef | grep ora_

Herşey normaldi. Ve o güne kadar bilmediğim birşey öğrendim. Oracle veritabanının bir arka kapı girişinin olduğunu! SQL*Plus aracının “prelim” parametresi ile veritabanına arka kapıdan girebiliyorsunuz 🙂 Prelim, direk SGA alanına bağlanır. Veritabanında herhangi bir oturum başlatmaz. Bundan dolayıda “Connected to:” şeklinde bir mesaj almayız. Doğrudan SQL promptuna düşeriz.

Prelim ile aşağıdaki gibi bağlanabiliriz.

# sqlplus -prelim / as sysdba
SQL>

Veya aşağıdaki gibide bağlanabilmekteyiz.

# sqlplus /nolog
SQL> set _prelim on
SQL> conn / as sysdba
Prelim connection established

Artık oradebug aracı ile SGA alanımızda analiz yapabiliriz.

SQL> oradebug setmypid
SQL> oradebug hanganalyze 12

Veritabanımızın user_dump_dest parametresi ile belirtilen dizin altında bir trace dosyası oluşturulur. Dosyaları zamana göre sıralayacak olursak en son üretilen dosyadır.

# ls -ltrh

Veya oradebug komutu ile trace dosyasının adını da öğrenebiliriz

SQL> oradebug TRACEFILE_NAME
/oracle/diag/rdbms/dbtalip/TALIPDB/trace/TALIPDB_ora_32739.trc

Trace dosyasını incelediğimizde aşağıdaki gibi başlayan satırların olduğunu görürüz.

*** 2012-06-11 12:14:02.870
================================================
HANG ANALYSIS:
  instances (db_name.oracle_sid): dbtalip.talipdb
  oradebug_node_dump_level: 12
  analysis initiated by oradebug
=================================================

İncelemeye devam ettiğimizde aşağıdaki probleme sebep olan oturum detaylarını görebiliriz.

os id: 981
process id: 29, oracle@dbtalip (TNS V1-V3)
session id: 74
session serial #: 47681

İlgili oturum sonlandırıldığında herşey normale dönecektir.

# kill -9 981

Talip Hakan Öztürk

ORADEBUG Nedir?

ORADEBUG Nedir?

ORADEBUG, SQL*Plus üzerinden icra edilen ve işlemlerin (process) internal bilgilerini dışarı almak için kullandığımız bir araçtır.

ORADEBUG komutlarının listesini aşağıdaki gibi görebiliriz. Şimdi en çok kullandığımız oradebug komutlarına göz atalım.

SQL> oradebug help

Bind değişkenlerle birlikte SQL cümlelerin trace ini oluşturmak;

1- Önce izlenilecek işlemin (process) PID numarası set edilir.

SQL> oradebug setospid 32318 Oracle pid: 29, Unix process pid: 32318, image: oracle@dbarge (TNS V1-V3)

veya kendimizide izlemek isteyebiliriz

SQL> oradebug setmypid

2- 10046 trace başlatılır.

SQL> oradebug EVENT 10046 trace name context forever, level 12

3- Trace dosyası incelenir.

# vi /oracle/diag/rdbms/dbarge/TEST11G/trace/TEST11G_ora_32318.trc

İşlem (Process) istatistiklerini izlemek;

1- V$PROCESS görüntüsü içinde PID alanı 11 olan LGWR işleminin istatistiklerini izlemek için setorapid komutu ile işlem set edilir.

SQL> oradebug setorapid 11 Oracle pid: 11, Unix process pid: 16944, image: oracle@dbarge(LGWR)

2- LGWR işlemi için istatistikler toplanır.

SQL> oradebug procstat

3- Toplanan istatistikler trace dosyasına yazılır.

SQL> oradebug TRACEFILE_NAME /oracle/diag/rdbms/dbarge/TEST11G/trace/TEST11G_lgwr_16944.trc

Kullanılan semaforları ve paylaşımlı bellek segmentlerini listelemek;

SQL> oradebug ipc

Bir işlemin hata kümesinin dump dosyasını oluşturmak;

SQL> oradebug setospid 11301

SQL> oradebug event immediate trace name errorstack level 3

 

Talip Hakan Öztürk

Veritabanı Host Adı / IP Adresi Değiştiğinde OEM Konfigürasyonu

Veritabanı host adı ve/veya ip adresi değiştiğinde, Enterprise Manager konsolunuz çalışmayacaktır. Çalışabilmesi için EMCA aracı ile repository oluşturma komutuyla OEM veritabanı konsolunu yeniden yapılandırmanız gerekmektedir.Bunun için aşağıdaki komutları kullanabiliriz.

emca -deconfig dbcontrol db -repos drop

emca -config dbcontrol db -repos create

veya

emca -deconfig dbcontrol db

emca -config dbcontrol db -repos recreate

TNS konfigürasyonumuz değişir ise (Örneğin dinleyici(listener) portumuz değişirse), bu durumda yine EMCA aracı ile aşağıdaki gibi tekrar konfigürasyonumuzu yapabiliriz.

emca -config dbcontrol db

Örnek: Repository silme (drop) ve oluşturma (create) işlemi sırasında bizden Veritabanı SID, dinleyici portu, SYS ve SYSMAN şifreleri gibi bilgileri isteyecektir. İstediği değerler, koyu renk ile yazdığım satırlardır. Repository silme (drop) işlemi yapıyorsak,veritabanı SID, dinleyici portu, SYS ve SYSMAN şifrelerini girdikten sonra emin olup olmadığımızı soracaktır. “y” diyerek silme işlemini gerçekleştirebiliriz. Aynı şekilde repository oluşturma (create) işlemi yapıyorsak,veritabanı SID, dinleyici portu, SYS ve SYSMAN şifrelerini girdikten sonra emin olup olmadığımızı soracaktır. “y” diyerek oluşturma işlemini gerçekleştirebiliriz.

talip /oracle/ora11gR2> emctl stop dbconsole

Oracle Enterprise Manager 11g Database Control Release 11.2.0.2.0 Copyright (c) 1996, 2010 Oracle Corporation.  All rights reserved.

http://dbtalip:1158/em/console/aboutApplication Stopping Oracle Enterprise Manager 11g Database Control …  …  Stopped.

talip /oracle/ora11gR2> emca -deconfig dbcontrol db -repos drop

STARTED EMCA at Nov 29, 2011 9:16:31 AM

EM Configuration Assistant, Version 11.2.0.0.2 Production Copyright (c) 2003, 2005, Oracle.  All rights reserved.

Enter the following information:

Database SID: TEST11GR2

Listener port number: 1521

Password for SYS user:

Password for SYSMAN user:

———————————————————————- WARNING : While repository is dropped the database will be put in quiesce mode. ———————————————————————-

Do you wish to continue? [yes(Y)/no(N)]: y

Nov 29, 2011 9:16:53 AM oracle.sysman.emcp.EMConfig perform

INFO: This operation is being logged at

/oracle/cfgtoollogs/emca/TEST11GR2/emca_2011_11_29_09_16_30.log.

Nov 29, 2011 9:16:53 AM oracle.sysman.emcp.util.DBControlUtil stopOMS

INFO: Stopping Database Control (this may take a while) …

Nov 29, 2011 9:16:55 AM oracle.sysman.emcp.EMReposConfig invoke

INFO: Dropping the EM repository (this may take a while) …

Nov 29, 2011 9:19:15 AM oracle.sysman.emcp.EMReposConfig invoke

INFO: Repository successfully dropped Enterprise Manager configuration completed successfully FINISHED EMCA at Nov 29, 2011 9:19:18 AM

talip /oracle/ora11gR2> emca -config dbcontrol db -repos create

STARTED EMCA at Nov 29, 2011 9:19:25 AM

EM Configuration Assistant, Version 11.2.0.0.2 Production Copyright (c) 2003, 2005, Oracle.  All rights reserved.

Enter the following information:

Database SID: TEST11GR2

Listener port number: 1521

Listener ORACLE_HOME [ /oracle/ora11gR2 ]:

Password for SYS user:

Password for DBSNMP user:

Password for SYSMAN user:

Email address for notifications (optional):

Outgoing Mail (SMTP) server for notifications (optional):

—————————————————————–

You have specified the following settings

Database ORACLE_HOME ……………. /oracle/ora11gR2

Local hostname ……………. dbtalip

Listener ORACLE_HOME ……………. /oracle/ora11gR2

Listener port number ……………. 1521

Database SID ……………. TEST11GR2

Email address for notifications ……………

Outgoing Mail (SMTP) server for notifications ……………

—————————————————————–

Do you wish to continue? [yes(Y)/no(N)]: y

Nov 29, 2011 9:19:46 AM oracle.sysman.emcp.EMConfig perform

INFO: This operation is being logged at

/oracle/cfgtoollogs/emca/TEST11GR2/emca_2011_11_29_09_19_24.log.

Nov 29, 2011 9:19:47 AM oracle.sysman.emcp.EMReposConfig createRepository

INFO: Creating the EM repository (this may take a while) …

Nov 29, 2011 9:26:16 AM oracle.sysman.emcp.EMReposConfig invoke

INFO: Repository successfully created

Nov 29, 2011 9:26:22 AM oracle.sysman.emcp.EMReposConfig uploadConfigDataToRepository

INFO: Uploading configuration data to EM repository (this may take a while) …

Nov 29, 2011 9:27:19 AM oracle.sysman.emcp.EMReposConfig invoke

INFO: Uploaded configuration data successfully

Nov 29, 2011 9:27:21 AM oracle.sysman.emcp.util.DBControlUtil secureDBConsole

INFO: Securing Database Control (this may take a while) …

Nov 29, 2011 9:27:31 AM oracle.sysman.emcp.util.DBControlUtil secureDBConsole

INFO: Database Control secured successfully.

Nov 29, 2011 9:27:31 AM oracle.sysman.emcp.util.DBControlUtil startOMS

INFO: Starting Database Control (this may take a while) …

Nov 29, 2011 9:28:09 AM oracle.sysman.emcp.EMDBPostConfig performConfiguration

INFO: Database Control started successfully

Nov 29, 2011 9:28:09 AM oracle.sysman.emcp.EMDBPostConfig performConfiguration

INFO: >>>>>>>>>>> The Database Control URL is https://dbtalip:1158/em <<<<<<<<<<<

Nov 29, 2011 9:28:13 AM oracle.sysman.emcp.EMDBPostConfig invoke

WARNING:

************************  WARNING  ************************

Management Repository has been placed in secure mode wherein Enterprise Manager data will be encrypted.  The encryption key has been placed in th file:

/oracle/ora11gR2/dbtalip_TEST11GR2/sysman/config/emkey.ora. Ensure this file is backed up as the encrypted data will becom unusable if this file is lost.

***********************************************************

Enterprise Manager configuration completed successfully

FINISHED EMCA at Nov 29, 2011 9:28:13 AM

talip /oracle/ora11gR2> emctl status dbconsole

Oracle Enterprise Manager 11g Database Control Release 11.2.0.2.0

Copyright (c) 1996, 2010 Oracle Corporation.  All rights reserved. https://dbtalip:1158/em/console/aboutApplication

Oracle Enterprise Manager 11g is running. ——————————————————————

Logs are generated in directory /oracle/ora11gR2/dbtalip_TEST11GR2/sysman/log talip /oracle/ora11gR2>

Talip Hakan Öztürk

Oracle veritabanı yazılımına (rdbms) patch uygulama (OPatch) – Interim Patches

01/11/2011 1 yorum

Opatch, veritabanı yazılımına (rdbms) patch uygulamak için kullanılan bir araçtır. Bu araç oracle home dizini altında buluna “Opatch” klasörü altındadır. Örneğin 10.2.0.5 veritabanımız için 8943287 id numaralı patch uygulamak isteyelim;

Patch uygulama:

1- Oracle Home dizini yedeği alınır.

$ tar -cf ora10g.tar ora10g

2- Patch dosyası p8943287_10205_Linux-x86-64.zip metalink üzerinden indirilir. Ve sunucu üzerine kopyalanır.

3- Zipli dosya unzip edilir.

$ unzip p8943287_10205_Linux-x86-64.zip

4- Açılan klsörün içine girilir ve patch aşağıdaki gibi uygulanır.

$ cd 8943287

$ ORACLE_HOME/OPatch/opatch apply

Uygulanan patchlerin listesini görme:

$ORACLE_HOME/OPatch/opatch lsinventory

Örnek çıktı:

$ORACLE_HOME/OPatch/opatch lsinventory

Invoking OPatch 10.2.0.4.9

Oracle Interim Patch Installer version 10.2.0.4.9

Copyright (c) 2009, Oracle Corporation. All rights reserved.

Oracle Home : /oracle/ora10g

Central Inventory : /oracle/oraInventory

from : /etc/oraInst.loc

OPatch version : 10.2.0.4.9

OUI version : 10.2.0.5.0

OUI location : /oracle/ora10g/oui

Log file location : /oracle/ora10g/cfgtoollogs/opatch/opatch2011-10-28_12-14-12PM.log

Patch history file: /oracle/ora10g/cfgtoollogs/opatch/opatch_history.txt

Lsinventory Output file location : /oracle/ora10g/cfgtoollogs/opatch/lsinv/lsinventory2011-10-28_12-14-12PM.txt

——————————————————————————–

Installed Top-level Products (3):

Oracle Database 10g 10.2.0.1.0

Oracle Database 10g Release 2 Patch Set 3 10.2.0.4.0

Oracle Database 10g Release 2 Patch Set 4 10.2.0.5.0

There are 3 products installed in this Oracle Home.

Interim patches (2) :

Patch 8943287 : applied on Fri Oct 21 20:39:46 EEST 2011

Unique Patch ID: 12722995

Created on 23 Aug 2010, 11:45:16 hrs PST8PDT

Bugs fixed:

8943287

——————————————————————————–

Uygulanan patchi geri alma:

Bazen uygulanan bir patchin sisteme etkisinden dolayı geri almamız gerekebilir. Bu durumda aşağıdaki gibi rollback işlemi yapılır.

$ORACLE_HOME/OPatch/opatch rollback -id 8943287

Talip Hakan ÖZTÜRK

RMAN Konfigürasyonları

Merhaba Arkadaşlar,

Bu yazımda RMAN in önemli konfigürasyonlarını sizlere açıklıyor olacağım. Bu konfigürasyonları bir kere yapıp yedeklerimizi bu konfigürasyon ayarları  ile alabileceğimiz gibi, yedek scriptimiz içinde de bu konfigürasyonları scriptimize özel set edebiliriz.

CONFIGURE RETENTION POLICY

2 farklı seçenek ile kullanılır. Recovery Window veya Redundancy

Redundancy: CONFIGURE RETENTION POLICY TO REDUNDANCY 1;

Redundacy 1 set edildiğinde, RMAN geçmişe yönelik 1 yedek saklar. 2. Yedek alındığında 1. Yedeği obsolete olarak işaretler. Şayet FRA da yer kalmazsa RMAN bunu otomatik algılar ve obsolete yedeği siler. Veya biz “delete obsolete” ile manuel silebiliriz.

Recovery Windows: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

Recovey windows 3 gün set edildiğinde 3 günden eski yedekler obsolete olarak işaretlenir.  Recovery window da özel bir durum vardır. RMAN 3 günlük geri dönmeyi garanti eder. Bunu bir örnekle açıklamak gerekirse;

Elimizde 4 yedeğimiz olsun. Ve yedek alınma tarihleri 16 mayıs, 18 mayıs, 21 mayıs ve 23 mayıs olsun. Recovery window 3 set edildiğinde normalde 16 mayıs ve 18 mayıs ın obsolete olması gerekir. (23-3=20 yani 20 mayıs ve öncekiler obsolete olmalı).Ama 20 mayıs a geri dönülmesi gerektiğinde 18 mayıs yedeğinin gerekli olmasını RMAN otomatik algılar ve 18 mayısı obsolete olarak set etmez.

CONFIGURE DEFAULT DEVICE TYPE

2 farklı lokasyona yedek alınabilir. Tape ve Disk

Diske yedek: CONFIGURE DEFAULT DEVICE TYPE TO DISK;

Tape kartuşa yedek: CONFIGURE DEFAULT DEVICE TYPE TO SBT;

CONFIGURE CONTROLFILE AUTOBACKUP ON/OFF

Controlfile ın her yedek almada otomatik yedeklenip yedeklenmeyeceği buradan set edilir. On ise otomatik yedek alınır, off ise yedek alınmaz.

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’;

Controlfile yedeği varsayılan FRA alanına unique bir isimde alınacağını bildirir. %f nin karşılığı c-‘IIIIIIIIII-YYYYMMDD-QQ’ şeklindedir . Burada ‘IIIIIIIIII’ DBID yi ‘YYYYMMDD’ tarihi ve ‘QQ’ ise hex decimal bir yedek idsidir. Biz istersek aşağıdaki gibi farklı yerlere alabiliriz.

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘ora_home/oradata/cf_%F’;

Ve aşağıdaki gibi konfigürasyonumuzu resetleyebiliriz.

CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK CLEAR;

Aşağıdaki gibi RUN scriptinin içerisinde yazıldığında varolan konfigürasyonu ezdirebiliriz

RMAN> SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt TO 'controlfile_%F';
RMAN> BACKUP AS COPY DATABASE;
RMAN> RUN {
       SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F.bck';
       BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE;
      }
Format Açıklaması
%a Varolan veritabanı aktivasyon idsi
%A 0 ile tamamlanmış aktivasyon idsi
%c Maksimum değeri 256 olan backup piece kopya numarası
%d Veritabanı adı
%D DD formatında gün bilgisi
%e Arşiv log dosyası sıra numarası
%f Absolute dosya numarası
%F DBID, gün ay, yıl ve benzersiz bir sıra numarası içerir.
%h Arşiv redo log thread numarası
%I DBID
%M MM formatında ay bilgisi
%n Veritabanı adı
%N Tablespace adı. Veri dosyası ve image copy yedekle set edilebilir.
%p Backup set içindeki backup piece numarasıdır
%r Resetlogs ID
%s Backup set numarası
%S 0 ile tamamlanmış sıra numarası
%t Backup set zaman bilgisidir. Saniye bilgiside içeren 4 byte lık bir değerdir.
%T Gregorian takviminde YYYYMMDD formatında olan yıl, ay ve gün bilgisidir
%u Backup set veya image copy yedeğin numarası ve oluşturulma zamanını içeren 8 karakterlik bir bilgidir.
%U Sistem tarafından üretilen benzersiz bir numaradır.
%Y YYYY formatındaki yıl bilgisidir

CONFIGURE BACKUP OPTIMIZATION OFF/ON

On olması halinde daha önce yedeği alınmış ve herhangi bir değişikliğe uğramamış objeler yedeklenmez. Bunun için aşağıdaki kriterleri göz önünde bulundurur

Dosya tipi Aynı dosya olup olmadığını anlama kriteri
Datafile Aynı DBID, checkpoint SCN, ilk oluşturulma SCN,  resetlogs SCN ve zaman.
Arşiv redo log Aynı thread, sıra (sequence) numarası, resetlogs SCN ve zaman.
Backup set Aynı backup set recid si ve  izidir.

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET
Alınan yedeklerin kaç paralel olarak kaç kanaldan yazılacağını belirlediğimiz konfigurasyondur. Device type oalrak disk veya sbt olduğunu belirtmeliyiz.

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 3

Datafile yedeklerinin kopya adedi olarak kaç tane alınacağı bu konfigürasyonla belirlenir. Yukarıdaki örneğime göre 3 kopya alınacaktır. Mirror yedek olarak bilinir. FORMAT opsiyonu ile 3 farklı lokasyon verilebilir. 3 yedeğin id side aynı olacaktır.
BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7 FORMAT
‘/tmp/%U’,’?/oradata/%U’,’?/%U’;
 
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1
 
Arşiv dosya yedeklerinin kopya adedi olarak kaç tane alınacağı bu konfigürasyonla belirlenir. 2 ve daha çok kopya için ayrı ayrı lokasyon verilmelidir yoksa yedek hata alır.(Yukarıdaki gibi FORMAT opsiyonu ile)

CONFIGURE MAXSETSIZE TO UNLIMITED
 
Normal backup size maximum FRA alanı kadar olabilmektedir. İstenirse maxsetsize verilerek yedeğin bu boyutta olması sağlanabilir. Bu kiritik bir değerdir. Maxsetsize ım yedek aldığım data file ın size ından küçükse yedek hatalı sonuçlanmaktadır. Varsayılan ‘UNLIMITED’ olarak gelmektedir.

CONFIGURE ENCRYPTION FOR DATABASE OFF/ON

Encryption kullanılıp kullanılmayacağına karar verilir. Encryption kullanılacaksa hangi algoritmanın kullanılacağı ise aşağıdaki konfigürasyon ile belirtilir.

CONFIGURE ENCRYPTION ALGORITHM ‘AES128’

Encryption kullanılacaksa hangi algoritmanın kullanılacağı ise aşağıdaki konfigürasyon ile belirtilir.

CONFIGURE COMPRESSION ALGORITHM ‘BASIC’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE

11g ile gelen bir özelliktir. 2 Farklı zipleme metodu mevcuttur. ZLIB ve BZIP2. ZLIB daha az cpu tüketir ama sıkıştırma oranı düşüktür. BZIP2 ise cpu kullanımı fazladır ama sıkıştırma oranı yüksektir. Aşağıdaki gibi kullanılabilir.

CONFIGURE COMPRESSION ALGORITHM ‘ZLIB’;

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET;

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE

Arşiv yedeği alındıktan sonra obsolete olup olmayacağı set edilir. Varsayılan None dur. “APPLIED ON STANDBY” set edilebilir.

10g de aşağıdaki gibi set edilebilir.

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO {ARCHIVERETENTION};

11g de aşağıdaki gibi set edilebilir.

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK;

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE

 Yedek dosyasının MAXPIECESIZE kadar parçalar halinde alınmasını sağlar. Örneğin aşağıdaki konfigürasyonla alınan yedek 2GB lık parçalar halinde alınır.

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 2G;

CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/oracle/ora10g/dbs/snapcf_test10g.f’

Controlfile ın snapshot ının lokasyonunun set edildiği konfigürasyondur. Controlfile ın kopyasıdır. RMAN özellikle catalog db ile kullanılırken resync için snapshot controlfile a ihtiyaç duyar.

Kaynak:
http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/rcmconfb.htm#i1014902

Talip Hakan ÖZTÜRK

%d blogcu bunu beğendi: