Kamil TURKYILMAZ || Oracle Blog

Dataguard Tarafındaki Datafile ler Nasıl Rename Edilir

2011-06-24T23:56:00.000+03:00

Dataguard ortamları çoğu zaman donamım gereksinimleri bakımından production ile birebir olamıyabiliyor (ki uygulamaların birçoğuda bu şekilde) gerek memory gerekse disk kapasiteleri bakımından dataguardın bağlı bulunduğu sunucular productiondan geride oluyor. Durum böyle olunca dataguard tarafını kontrol etmeden production ortamına eklenen datafile’ ler, DG tarafında create edilemediğinden hata alınıyor, sonrasında MRP processesi artık DG tarafında çalışmadığından senkronizasyon duruyor. Bu tarz bir durumla karşılaştığımızda neler yapmamız gerekeceğinden bahsetmek istiyorum.

Öncelikle böyle bir durumla karşılaştığımızda alert logda alacağımız hatayı görelim ;

Thu Jun 16 12:08:18 2011

MRP0: Background Managed Standby Recovery process started (test)

Managed Standby Recovery not using Real Time Apply

MRP0: Background Media Recovery terminated with error 1111

Thu Jun 16 12:08:23 2011

Errors in file /u01/oracle/test/bdump/test_mrp0_8661.trc:

ORA-01111: name for data file 32 is unknown – rename to correct file

ORA-01110: data file 32: /oracle/10g/dbs/UNNAMED00032′

ORA-01157: cannot identify/lock data file 32 – see DBWR trace file

ORA-01111: name for data file 32 is unknown – rename to correct file

ORA-01110: data file 32: /oracle/10g/dbs/UNNAMED00032′

Logdan da görüleceği üzere 32 nolu dbf, prod ortamına create edilmiş ancak ordaki dizin DG tarafında olmadığı için (benim örneğimde dizin var ama klasör yoktu) bu datafile’ i dbf altına UNNAMED olarak atayarak MRP processesini sonlandırmış. Burada yapmamız gereken bu datafile’ leri prod ortamdan bağlı bulunduğu tablespace’ leri backup moda alarak DG tarafına kopyalamak ve rename etmek olacak. Adım adım gidelim ;

Production ortamda ;

Datafile’ in hangi tablespace’ e ait ise o tablespace’ i backup moda alıyorum.

ALTER TABLESPACE deneme BEGIN BACKUP;

Sonra ilgili dbf’ i DG tarafına scp (rcp veya ftp) ile DG tarafına kopyalalıyoruz. Primary tarafındaki işlemlerin aksamaması için kopyalama biter bitmez Production da tablespace’ i backup moddan çıkartıyoruz.

ALTER TABLESPACE deneme END BACKUP;

Primary tarafındaki işimiz bu kadar, sonrasında DG tarafında recover işlemini durduruyoruz;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

DG’ da file management parametresini manual olacak şekilde set ediyoruz.

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;

Database mount modda değilse, kapatıp mount modda açıyoruz;

STARTUP MOUNT;

Hatalı olan dbf’i rename ediyoruz;

ALTER DATABASE RENAME FILE ‘/u01/ oradata/test01.dbf’ TO ‘/u01/oradata/standby/test01.dbf’;

Ve apply işlemini başlatabiliriz artık ;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

BU şekilde hatalı olarak oluşturulmuş başka datafile’ ler var ise sırası ile tüm datafile’ ler için aynı işlemler tekrar edilmelidir. Sorunlu datafile’ lerin listesi DG tarafına

Select name from v$datafile ;

Sorgusu ile select edildiğinde ilk hata veren dbf ‘ e ait bilgiler görüntülenecektir. Birini düzelttikden sonra apply başlatıldığında bu sefer diğeri için aynı hatayı verecek dolayısıyla yukarıdaki script artık ikinci hatalı olan datafile’ i gösteriyor olacaktır.

Production tarafında herhangi bir rename işlemi yapmadık , ki bunun nasıl yapılması gerektiğinden daha önce bahsetmiştim.

http://www.kamilturkyilmaz.com/2010/10/03/datafile-%E2%80%98-in-adini-rename-etme-pathini-degistirme/

Kamil TÜRKYILMAZ

http://www.kamilturkyilmaz.com/

CRONTAB: You are not Authorized to Use Cron. Sorry.

2011-06-09T23:55:00.000+03:00

Crontab dba’ lerin kimi zaman eli ayağı olmaktadır. Crontab, windows’ daki schedule task gibi düşünülebilir, OS seviyesinde, bir takım işlerimizi joblara bağlamak istersek crontab’ dan faydalanırız. Crontab ile ilgili sık kullanılan komutların bazıları ve açıklamaları aşağıdaki gibidir;

crontab -e = Crontab dosyasını editlemenizi yani joblarınızı tanımlamanızı sağlar, Eğer daha önce hiç tanımlanmamışsa bu bu komutla create edebilirsiniz.

crontab -l          = Crontab içerisine tanımlanmış olan tüm jobları görüntüleminizi sağlar.
crontab -r         = Crontab dosyasını tamamiyle siler.
crontab -v         = Crontab dosyasını en son hangi userın editlediğini gösterir.

Crontab –e dediğinizde aşağıdaki bir hata mesajı alırsanız, bu bulunduğunuz userın crontab’ ı editlemesine yetkisi olmadığı anlamına gelir.

”crontab: you are not authorized to use cron. Sorry.”

Hangi user için crontab’ a yetki vermek istiyorsanız, yapmanız gerekenler;

Root userı ile sisteme bağlanıyoruz,

vi komutu ile /usr/lib/cron/cron.allow dosyasını editleyip içerisine istediğimiz kullanıcı adını yazıp kaydedip çıkıyoruz.

Dosya yok ise create edilmelidir. Sonrasında ilgili user ile sisteme giriş yapıp crontab’ ı kullanabilirsiniz. Bu aşamadan sonra crontab –l ile crontabı görüntülemeye çalışmak istediğinizde aşağıdaki gibi bir mesaj alırsanız ;

crontab: can’t open your crontab file

Henüz oluşturulmuş bir crontabınız olmadığı anlamına gelirki crontab –e ile dosyayı editleyebilirsiniz.

Kimi sistemler de

/etc/cron.allow

Dosyasına ilgili userı eklemeniz gerekebilir bilginiz olsun.

Kamil TÜRKYILMAZ

http://www.kamilturkyilmaz.com/

ORA-12519:TNS:no appropriate service handler found

2011-05-20T23:49:00.000+03:00

Merhaba,

Herhangi bir tool ile database’ e connect olmaya çalışırken tns-12518 gibi bir hata ile karşılaşırsanız bunun iki nedeni olabilir;

Birincisi, database’e yeni start komutu verilmiş veya shutdown komutu ile down olma sürecinde iken bağlanmaya çalışırsanız,

İkincisi database’ de initial parametresi olarak tanımlı olan processes değerine ulaşılmış ve siz üzerine yeni bir connection sağlamaya çalışır iseniz bu şekilde bir hata ile karşılaşırsınız.

Bu hatayı aldığınızda listener loglarına bakacak olursanız hatayı şu şekilde görebilirsiniz;

15-MAY-2011 09:00:00 * (CONNECT_DATA=(SID=test01)(CID=(PROGRAM=c:\oracle\product\11.2.0\bin\sqlplus.exe)(HOST=CLBINFAPP02)(USER=TEST))) * (ADDRESS=(PROTOCOL=tcp)(HOST =turkyilmaz)(PORT=4487)) * establish * test01 * 12519

TNS-12519: TNS:no appropriate service handler found

15-MAY-2011 09:00:15 * (CONNECT_DATA=(SID=test01)(CID=(PROGRAM= c:\oracle\product\11.2.0\bin\emagent.exe)(HOST=turkyilmaz)(USER=SYSTEM))) * (ADDRESS=(PROTOCOL=tcp)(HOST=turkyilmaz)(PORT=50057)) * establish * test01 * 12519

TNS-12519: TNS:no appropriate service handler found

Bu hatanın procesess parametresinden kaynaklanıp kaynaklanmadığını aşağıdaki sorgu ile test edebilirsiniz ;

SQL> select * from v$resource_limit where resource_name='processes';

RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_AL LIMIT_VALU

processes 177 200 200 200

Yukarıda bizim örneğimizdeki durum şu şekilde process parametremiz 200 olarak set edilmiş durumda, şu anda 177 procesess var ve max proceses limitine ulaşıldığını görüyoruz.

Son olarak eğer bir startup veya shutdown sürecine denk gelmediyseniz, çözüm olarak procesess limit değerini artırabiliriz. Tabi artırmak istiyorsanız, özellikle database’ de belirlediğiniz procesess değerinin üzerine çıkılmasını istemiyor iseniz, hata alan kullanıcıların beklemekden başka bir seçenekleri yok J

Processes değeri artırmak için ;

alter system set processes=150 scope=spfile;

komutunu kullanabilirsiniz. Bu parametre dinamik bir parametre olmadığından dolayı, yeni değerin etkin olabilmesi için database’ in restart edilmesi gerekecektir.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Maximum Datafile Size Nasıl Hesaplanır

2011-05-04T23:46:00.000+03:00

Database’ de eklemiş olduğunuz datafile’ lerin aslında bir max size’ ı var. Yani isteseniz de belli bir değerin üstünde bir datafile create edemezsiniz. Bu maximum değer kullandığınız db_block_size parametresi ile doğru orantılıdır.

Örneğin db_block_size’ ınız 8 kb ise oluşturabileceğiniz maximum datafile size limitiniz

= ((4096*1024)-1))*8196 = 34376507388 bytes = 33570807,99 kb = 32783,99 mb ‘ dır.

Kendi ortamlarınız için aşağıdaki formülü kullanarak datafile’ leriniz alabileceği maximum size’ ı hesaplayabilirsiniz.

Hesaplanışı = ((4096*1024)-1)) *db_block_size

Data detaylı bilgi için;

What is the Maximum Datafile Size Limit In an Oracle Database? [ID 804733.1]

dökümanını okuyabilirsiniz.

Maximum datafile size for a SmallFile Tablespace based on 10gR2 documentation would be:

Block Size    Maximum Datafile File Size
-----------     ---------------------------
2k                4194303 * 2k     = 8 GB
4k                4194303 * 4k     = 16 GB
8k                4194303 * 8k     = 32 GB
16k          4194303 * 16k   = 64 GB
32k              4194303 * 32k   = 128 GB

Maximum datafile size for a BigFile Tablespace based on 10gR2 documentation would be:

Block Size    Maximum Datafile File Size
-----------     ---------------------------
2k                 4294967295 * 2k     = 8 TB
4k                 4294967295 * 4k     = 16 TB
8k                 4294967295 * 8k     = 32 TB
16k               4294967295 * 16k = 64 TB
32k               4294967295 * 32k   = 128 TB

804733.1

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Windows Security Log Analizi Eğitimi

2011-05-01T23:53:00.000+03:00

Merhabalar,

Güvenliğin artık şirketler için vazgeçilemez bir noktada olduğunu biliyoruz.
Şirket içi çalışanlarının yapmış oldukları işlemlerin loglanması, kontrolüde bu kapsamda zaman zaman ciddi bir güvenlik açığı oluşturabiliyor. Bugün bu bahsetmiş olduğum güvenlik konusu ile ilgili olarak bir eğitim duyurusu yapmak istiyorum. Windows security log eğitimi, eğitim içeriğini aynı www.logyonetimi.com sitesinin kurucusu da olan Osman Bey organize ediyor. Konuyla ilgilenen veya ilgilenmek isteyen meraklı arkadaşlarımıza duyurulur.

Konuyla ilgili detaylı bilgiye aşağıdaki linkden ulaşabilirsiniz.

http://www.logyonetimi.com/web/Makaleler/11-05-27/Windows_Security_Log_Analizi_E%c4%9fitimi_-_3-146012777.aspx

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

TURKCEORACLE.COM

2011-05-01T23:52:00.000+03:00

Merhabalar,

Yazılarımı bundan böyle turkceoracle.com adresinden de sizlerle paylaşıyor olacağım.

Yardımların dan ötürü Ümit (Karaoğul) ve Emre ‘ ye (Baransel) teşekkür ederim.

Bu arada yoğunluk dan dolayı bir süredir ara verdiğim yazılarıma en kısa zamanda tekrar başlamayacağım.

Görüşmek üzere …

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Step by Step creating a Physical Standby Database on 11gR2

2011-04-10T23:41:00.000+03:00

10gR2 için dataguard kurulumundan bahsetmiştik, şimdi aynı işlemleri 11gR2 için yapıp bir sonraki adımda da dgmgrl ile switcover failover işlemlerinden bahsetmeyi planlıyorum. İlk yazımda bahsetmiş olduğum bazı tanım ve ön gereksinimler kısmına artık burada değinmiyorum. 10gR2 için dataguard kurulumundan bahsederken manuel kurulum yapmıştık. Dbf’ leri biz taşımıştık, initfile’ deki parametreleri biz edit ederek üzerinde değişiklikler yapmıştık. 11gR2 için dataguard kurulumunda bu adımların hiçbirini yapmayacağız. Rman’ i kullanarak tüm işi oracle’ a bırakarak nasıl yapacağımız üzerinde konuşacağız.

Kurulumuna başlamadan önce elimizdekilere bir bakalım. 2 tane işletim sistemi linux 5.5 olan sunucumuz, sunucuların birinde oracle 11gR2 database kurulu diğerinde ise sadece software kurulu durumda. Primary sunucumuzun SID=dg1, dataguard olacak olan database’ imizin SID’si dg2.

Bu özet bilgilerden sonra physical standby database’ imizi create etmeye başlayabiliriz ;

· Primary database’ imizi force logging moda alıyoruz;

Alter database force logging

· Primary database’ in archive modda olması gerekiyor.

Aşağıdaki script ile kontrol edebilirsiniz. Sonuç NOARCHIVELOG dönerse aşağıdaki adımları takip ederek archive moda alabilirsiniz.

select log_mode from v$database ;

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

-- archive ile ilgili iki önemli parametreyi set ediyoruz.

ALTER SYSTEM SET log_archive_format='arch_%t_%s_%r_.arc' SCOPE=spfile

ALTER SYSTEM SET log_archive_dest_1='location=D:\arch' SCOPE=spfile

· Primary database’ inde yok ise bir password file create edilir;

orapwd file=PWDist.ora password=oracle entries=5 force=Y

· Primary Database’ ine Standby Redo logların create ve configure edilmesi ;

Burada önerilen, primary database’ deki redo logların size’ ı ile standby için create edilecek redo log’ ların size’ larının aynı olmasıdır. Kaç tane oluşturulacağını şu şekilde hesaplayabiliriz ;

Create Edilecek Standby Redo Log Sayısı = (maximum number of logfiles for each thread + 1) * maximum number of threads

Bir örnekle açıklayalım ;

Primary database’ indeki redo loglarımız,

SQL> select group#,THREAD#,BYTES,status from v$log;

GROUP# THREAD# BYTES STATUS

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

1 1 52428800 INACTIVE

2 1 52428800 INACTIVE

3 1 52428800 CURRENT

thread başına düşen log sayısı = 3

maximum number of thread = 1

Dolayısıyla create edilecek log sayısı = (3+1)*1 = 4

Bu örnek benim primary database’ im deki ile aynı dolayısıyla bende 4 tane standby redo logları create ediyorum.

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('c:\oracle10g\standby_redo\standby_redo04.log') SIZE 50M

Database altered

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ('c:\oracle10g\standby_redo\standby_redo05.log') SIZE 50M

Database altered

ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ('c:\oracle10g\standby_redo\standby_redo06.log') SIZE 50M

Database altered

ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 ('c:\oracle10g\standby_redo\standby_redo07.log') SIZE 50M

Database altered

Buradaki Group noları önemli, sıra ile devam etmesi gerekiyor, aralarda atlamalar olmayacak şekilde create ediyoruz.

Primary database’ ine standby redolog ları neden oluşturuyoruz sorusuna, dataguard kurulumunda aslında buna gerek yok ama kurulumdan sonra herhangi bir zamanda

gereklidir.

Standby redologlar create edildikden sonra aşağıdaki sorgu ile kontrol edebiliriz ;

SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG

GROUP# THREAD# SEQUENCE# ARCHIVED STATUS

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

4 0 0 YES UNASSIGNED

5 0 0 YES UNASSIGNED

6 0 0 YES UNASSIGNED

7 0 0 YES UNASSIGNED

4 rows selected

· Primary database’ in initial parametrelerinin düzenlenmesi ;

Redo logların transferi için primary database üzerinde bazı initial parametrelerinin düzenlenmesi gerekmektedir. Bunun yanısıra yine olası bir switchover durumunda hata alınmaması için (standby gibi davranabilmesi için) bazı eklemelerinde yapılması faydalı olacaktır.

Bilmemiz gerekenler şunlar;

Primary database’ imin db_unique_name = dg1

Net_service_name = dg1

Standby database’ imin db_unique_name = dg2

Net_service_name = dg2

Pfile’ de yapılacak olan değişiklerin bir kısmı zaten şu anki pfile’ inizde olan parametreler, kontrol etmeniz yeterli olacaktır.

DB_NAME, CONTROL_FILES, REMOTE_LOGIN_PASSWORDFILE (exclusive olması gerekiyor), LOG_ARCHIVE_FORMAT (db archive modda olduğunda bu parametrede pfile’ inizde olacaktır.)

Aşağıdaki parametreleri ekliyoruz.

*.control_files='/data/oracle/oradata/dg1/control01.ctl','/data/oracle/flash_recovery_area/dg1/control02.ctl'

*.db_name='dg1'

*.DB_UNIQUE_NAME=dg1

*.log_archive_dest_1='location=/data/oracle/arch'

*.log_archive_dest_state_1='ENABLE'

*.log_archive_dest_state_2='ENABLE'

*.log_archive_format='arch_%t_%s_%r_.arc'

*.remote_login_passwordfile='EXCLUSIVE'

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(dg1,dg2)'

*.LOG_ARCHIVE_DEST_1='LOCATION=/data/oracle/arch/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=dg1'

*.LOG_ARCHIVE_DEST_2='SERVICE=dg2 ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dg2'

*.LOG_ARCHIVE_DEST_STATE_1=ENABLE

*.LOG_ARCHIVE_DEST_STATE_2=ENABLE

*.LOG_ARCHIVE_MAX_PROCESSES=30

*.FAL_SERVER=dg2

*.DB_FILE_NAME_CONVERT='dg2','dg1'

*.LOG_FILE_NAME_CONVERT='/data/oracle/arch_dis/','/data/oracle/arch','/data/oracle/arch_dis/','/data/oracle/arch'

*.STANDBY_FILE_MANAGEMENT=AUTO STANDBY_FILE_MANAGEMENT=AUTO

Log_archive_process’ si 30 olarak set ettim ben, oracle’ ın standby için önermiş olduğu process sayısı 30’ dır. Daha azda yapabilirsiniz.

· Hem primary sunucuda hemde standby tarafındaki listener ve tnsnames.ora dosyalarında aşağıdaki eklemeleri yapıp, listener servisini stop – start ediyoruz.

Tnsnames.ora doyasında her iki instance’ a ait bilgiler yer alacak şekilde düzenliyoruz.

DG2 =

(DESCRIPTION =

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

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = dg2)

)

DG1 =

(DESCRIPTION =

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

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = dg1)

)

Listener.ora dosyasınıda aşağıdaki satırları ekliyoruz.

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(SID_NAME = dg1)

(GLOBAL_DBNAME = dg1)

(ORACLE_HOME = /data/oracle/11.2.0/dbhome_1)

)

(SID_DESC =

(SID_NAME = dg2)

(GLOBAL_DBNAME = dg2)

(ORACLE_HOME = /data/oracle/11.2.0/dbhome_1)

)

· Standby tarafına profile dosyası üzerinde oracle_home, sid gibi değişiklikleri yaptıkdan sonra, orapwd dosyasını primary db’ olduğu sunucudan buraya kopyalıyoruz. Burada orapwdg1 ve orapwdg2 olacak şekilde iki tane passord file oluşturuyoruz. (orapwdg1 dosyası, switchover durumunda problem olmaması için)

· Standby sunucuda $ORACLE_HOME/dbs klasörü altına manuel olarak (vi editörü ile) initdg2.ora dosyası create edip içerisine sadece DB_NAME=DG2 parametresini ekleyip kaydediyoruz.

· Standby tarafında $ORACLE_BASE altına /admin/SID/admin klasörünü create ediyoruz.

(rman komutunu çalıştırdığınızda eksik create edilmiş olan bir lokasyon var ise hata verecektir, böyle bir durumda standbydaki oradata lokasyonu silip primary tarafında rman’ e tekrar connect olup komutu tekrar başlatabilirsiniz.)

· Yine standby tarafında $ORACLE_BASE altına /oradata/SID klasörünü create ediyoruz.

· Standby database’ ini nomount moda alıyoruz.

[oracle@betadataguard2 admin]$ sqlplus "/as sysdba"

SQL*Plus: Release 11.2.0.1.0 Production on Sun Apr 17 00:26:05 2011

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

SQL> startup nomount pfile=$ORACLE_HOME/dbs/initdg2.ora;

ORACLE instance started.

Total System Global Area 217157632 bytes

Fixed Size 2211928 bytes

Variable Size 159387560 bytes

Database Buffers 50331648 bytes

Redo Buffers 5226496 bytes

SQL>

· Primary sunucusu üzerinden Rman’ e connect olup komutumuzu çalıştırıyoruz.

[oracle@betadataguard1 standby_kurulum]$ rman

Recovery Manager: Release 11.2.0.1.0 - Production on Sat Apr 16 19:45:51 2011

RMAN> connect target sys

target database Password:

connected to target database: DG1 (DBID=1729884635)

RMAN> connect auxiliary sys@dg2

auxiliary database Password:

connected to auxiliary database: DG2 (not mounted)

Çalıştıracağımız komutumuz ;

run {

allocate channel prmy1 type disk;

allocate channel prmy2 type disk;

allocate channel prmy3 type disk;

allocate channel prmy4 type disk;

allocate auxiliary channel stby type disk;

duplicate target database for standby from active database

spfile

parameter_value_convert 'dg1','dg2'

set db_unique_name='dg2'

set db_file_name_convert='/dg1/','/dg2/'

set log_file_name_convert='/dg1/','/dg2/'

set control_files='/data/oracle/oradata/dg2/dg2.ctl'

set log_archive_max_processes='5'

set fal_client='dg2'

set fal_server='dg1'

set standby_file_management='AUTO'

set log_archive_config='dg_config=(dg1,dg2)'

set log_archive_dest_2='service=dg1 ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=dg1'

;

}

Scriptin outputu ;

RMAN> run {

2> allocate channel prmy1 type disk;

3> allocate channel prmy2 type disk;

4> allocate channel prmy3 type disk;

5> allocate channel prmy4 type disk;

6> allocate auxiliary channel stby type disk;

7> duplicate target database for standby from active database

8> spfile

9> parameter_value_convert 'dg1','dg2'

10> set db_unique_name='dg2'

11> set db_file_name_convert='/dg1/','/dg2/'

12> set log_file_name_convert='/dg1/','/dg2/'

13> set control_files='/data/oracle/oradata/dg2/dg2.ctl'

14> set log_archive_max_processes='5'

15> set fal_client='dg2'

16> set fal_server='dg1'

17> set standby_file_management='AUTO'

18> set log_archive_config='dg_config=(dg1,dg2)'

19> set log_archive_dest_2='service=dg1 ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=dg1'

20> ;

21> }

using target database control file instead of recovery catalog

allocated channel: prmy1

channel prmy1: SID=34 device type=DISK

allocated channel: prmy2

channel prmy2: SID=1169 device type=DISK

allocated channel: prmy3

channel prmy3: SID=33 device type=DISK

allocated channel: prmy4

channel prmy4: SID=1167 device type=DISK

allocated channel: stby

channel stby: SID=10 device type=DISK

Starting Duplicate Db at 16-APR-11

contents of Memory Script:

{

backup as copy reuse

targetfile '/data/oracle/11.2.0/dbhome_1/dbs/orapwdg1' auxiliary format

'/data/oracle/11.2.0/dbhome_1/dbs/orapwdg2' targetfile

'/data/oracle/11.2.0/dbhome_1/dbs/spfiledg1.ora' auxiliary format

'/data/oracle/11.2.0/dbhome_1/dbs/spfiledg2.ora' ;

sql clone "alter system set spfile= ''/data/oracle/11.2.0/dbhome_1/dbs/spfiledg2.ora''";

}

executing Memory Script

Starting backup at 16-APR-11

Finished backup at 16-APR-11

sql statement: alter system set spfile= ''/data/oracle/11.2.0/dbhome_1/dbs/spfiledg2.ora''

contents of Memory Script:

{

sql clone "alter system set audit_file_dest =

''/data/oracle/admin/dg2/adump'' comment=

'''' scope=spfile";

sql clone "alter system set db_unique_name =

''dg2'' comment=

'''' scope=spfile";

sql clone "alter system set db_file_name_convert =

''/dg1/'', ''/dg2/'' comment=

'''' scope=spfile";

sql clone "alter system set log_file_name_convert =

''/dg1/'', ''/dg2/'' comment=

'''' scope=spfile";

sql clone "alter system set control_files =

''/data/oracle/oradata/dg2/dg2.ctl'' comment=

'''' scope=spfile";

sql clone "alter system set log_archive_max_processes =

5 comment=

'''' scope=spfile";

sql clone "alter system set fal_client =

''dg2'' comment=

'''' scope=spfile";

sql clone "alter system set fal_server =

''dg1'' comment=

'''' scope=spfile";

sql clone "alter system set standby_file_management =

''AUTO'' comment=

'''' scope=spfile";

sql clone "alter system set log_archive_config =

''dg_config=(dg1,dg2)'' comment=

'''' scope=spfile";

sql clone "alter system set log_archive_dest_2 =

''service=dg1 ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=dg1'' comment=

'''' scope=spfile";

shutdown clone immediate;

startup clone nomount;

}

executing Memory Script

sql statement: alter system set audit_file_dest = ''/data/oracle/admin/dg2/adump'' comment= '''' scope=spfile

sql statement: alter system set db_unique_name = ''dg2'' comment= '''' scope=spfile

sql statement: alter system set db_file_name_convert = ''/dg1/'', ''/dg2/'' comment= '''' scope=spfile

sql statement: alter system set log_file_name_convert = ''/dg1/'', ''/dg2/'' comment= '''' scope=spfile

sql statement: alter system set control_files = ''/data/oracle/oradata/dg2/dg2.ctl'' comment= '''' scope=spfile

sql statement: alter system set log_archive_max_processes = 5 comment= '''' scope=spfile

sql statement: alter system set fal_client = ''dg2'' comment= '''' scope=spfile

sql statement: alter system set fal_server = ''dg1'' comment= '''' scope=spfile

sql statement: alter system set standby_file_management = ''AUTO'' comment= '''' scope=spfile

sql statement: alter system set log_archive_config = ''dg_config=(dg1,dg2)'' comment= '''' scope=spfile

sql statement: alter system set log_archive_dest_2 = ''service=dg1 ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=dg1'' comment= '''' scope=spfile

Oracle instance shut down

connected to auxiliary database (not started)

Oracle instance started

Total System Global Area 471830528 bytes

Fixed Size 2214456 bytes

Variable Size 268436936 bytes

Database Buffers 192937984 bytes

Redo Buffers 8241152 bytes

allocated channel: stby

channel stby: SID=9 device type=DISK

contents of Memory Script:

{

backup as copy current controlfile for standby auxiliary format '/data/oracle/oradata/dg2/dg2.ctl';

}

executing Memory Script

Starting backup at 16-APR-11

channel prmy1: starting datafile copy

copying standby control file

output file name=/data/oracle/11.2.0/dbhome_1/dbs/snapcf_dg1.f tag=TAG20110416T194634 RECID=4 STAMP=748640795

channel prmy1: datafile copy complete, elapsed time: 00:00:01

Finished backup at 16-APR-11

contents of Memory Script:

{

sql clone 'alter database mount standby database';

}

executing Memory Script

sql statement: alter database mount standby database

contents of Memory Script:

{

set newname for tempfile 1 to

"/data/oracle/oradata/dg2/temp01.dbf";

switch clone tempfile all;

set newname for datafile 1 to

"/data/oracle/oradata/dg2/system01.dbf";

set newname for datafile 2 to

"/data/oracle/oradata/dg2/sysaux01.dbf";

set newname for datafile 3 to

"/data/oracle/oradata/dg2/undotbs01.dbf";

set newname for datafile 4 to

"/data/oracle/oradata/dg2/users01.dbf";

backup as copy reuse

datafile 1 auxiliary format

"/data/oracle/oradata/dg2/system01.dbf" datafile

2 auxiliary format

"/data/oracle/oradata/dg2/sysaux01.dbf" datafile

3 auxiliary format

"/data/oracle/oradata/dg2/undotbs01.dbf" datafile

4 auxiliary format

"/data/oracle/oradata/dg2/users01.dbf" ;

sql 'alter system archive log current';

}

executing Memory Script

executing command: SET NEWNAME

renamed tempfile 1 to /data/oracle/oradata/dg2/temp01.dbf in control file

executing command: SET NEWNAME

Starting backup at 16-APR-11

channel prmy1: starting datafile copy

input datafile file number=00001 name=/data/oracle/oradata/dg1/system01.dbf

channel prmy2: starting datafile copy

input datafile file number=00002 name=/data/oracle/oradata/dg1/sysaux01.dbf

channel prmy3: starting datafile copy

input datafile file number=00003 name=/data/oracle/oradata/dg1/undotbs01.dbf

channel prmy4: starting datafile copy

input datafile file number=00004 name=/data/oracle/oradata/dg1/users01.dbf

output file name=/data/oracle/oradata/dg2/users01.dbf tag=TAG20110416T194641

channel prmy4: datafile copy complete, elapsed time: 00:00:03

output file name=/data/oracle/oradata/dg2/undotbs01.dbf tag=TAG20110416T194641

channel prmy3: datafile copy complete, elapsed time: 00:00:36

output file name=/data/oracle/oradata/dg2/system01.dbf tag=TAG20110416T194641

channel prmy1: datafile copy complete, elapsed time: 00:00:56

output file name=/data/oracle/oradata/dg2/sysaux01.dbf tag=TAG20110416T194641

channel prmy2: datafile copy complete, elapsed time: 00:00:56

Finished backup at 16-APR-11

sql statement: alter system archive log current

contents of Memory Script:

{

switch clone datafile all;

}

executing Memory Script

datafile 1 switched to datafile copy

input datafile copy RECID=4 STAMP=748640857 file name=/data/oracle/oradata/dg2/system01.dbf

datafile 2 switched to datafile copy

input datafile copy RECID=5 STAMP=748640857 file name=/data/oracle/oradata/dg2/sysaux01.dbf

datafile 3 switched to datafile copy

input datafile copy RECID=6 STAMP=748640857 file name=/data/oracle/oradata/dg2/undotbs01.dbf

datafile 4 switched to datafile copy

input datafile copy RECID=7 STAMP=748640857 file name=/data/oracle/oradata/dg2/users01.dbf

Finished Duplicate Db at 16-APR-11

released channel: prmy1

released channel: prmy2

released channel: prmy3

released channel: prmy4

released channel: stby

RMAN>

Artık dataguardımız hazır sayılır. Bize kalan sadece apply başlatmak için komutumuzu çalıştırmak. Standby sunucusu üzerine gidip komutumuzu başlatalım;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

Database altered.

Artık dataguardımız hazır sayılır. Şimdi primary ile karşılaştırıp kontrol edelim.

-- Çıkan logları kontrol etmek için;

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

2 FROM V$ARCHIVED_LOG

3 ORDER BY SEQUENCE# desc;

SEQUENCE# FIRST_TIM NEXT_TIME

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

98 16-APR-11 16-APR-11

97 16-APR-11 16-APR-11

96 16-APR-11 16-APR-11

95 16-APR-11 16-APR-11

94 16-APR-11 16-APR-11

93 16-APR-11 16-APR-11

-- Standby tarafında çıkan logların durumunu kontrol etmek için;

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

FROM V$ARCHIVED_LOG

ORDER BY SEQUENCE# desc ;

SEQUENCE# FIRST_TIM NEXT_TIME

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

98 16-APR-11 16-APR-11

97 16-APR-11 16-APR-11

96 16-APR-11 16-APR-11

95 16-APR-11 16-APR-11

94 16-APR-11 16-APR-11

93 16-APR-11 16-APR-11

92 16-APR-11 16-APR-11

91 16-APR-11 16-APR-11

90 16-APR-11 16-APR-11

89 16-APR-11 16-APR-11

88 16-APR-11 16-APR-11

-- Standbyda hangilerinin apply olduğunu görebilmek içinse;

SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE# desc ;

SEQUENCE# APPLIED

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

98 IN-MEMORY

97 YES

96 YES

95 YES

94 YES

93 YES

92 YES

91 YES

90 YES

89 YES

88 YES

Çıkan tüm archiveların apply olduğunu görebiliyoruz. 11gR2 için dataguard kurulumunun adım adım nasıl yapabileceğimizi ifade etmeye çalıştım.Umarım faydalı olmuştur.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Step by Step creating a Physical Standby Database on 10gR2

2011-04-10T23:38:00.000+03:00

Oracle’ ın dataguard ürünü disaster recovery senaryolarında önemli bir yer tutmaktadır. Dataguard basit mantıkla sizin productiondaki database’ inizin (belli kriterler altında) birebir eşleniğinin tutulmasını sağlar. Buda size production database’inizde bir problem olduğunda veya productionda yapacağınız bir patch geçişi veya upgrade operasyonunda kesintiye gerek bırakmadan işlem yapabilme imkanı sağlar. Dataguard kurulumlarında oracle versiyonlarındaki farklardan kaynaklanan bir takım farklılıklar olabilmektedir. Dolayısıyla bu tarz installion guide’ ları oluştururken versiyon bilgisi önemlidir. Bu yazımda 10gR2 kurulu bir production sistemimiz üzerine physical standby database’ i nasıl kurabileceğimizden bahsedeceğim. Sonrasında da ayrı bir yazı ile aynı işlemi 11gR1 ve 11gR2 de yapmak istediğimizdeki farklara değinmeyi planlıyorum.

Öncelikle dataguard kurabilmemiz için (10g için kıstlardan bahsediyoruz, 11g için kısıtlarda ciddi değişimler oldu) ön koşullar nedir ondan biraz bahsedelim. Kısıtlarımızı iki başlık altında toplayabiliriz. Hardware and Operating sistem & Software açısından kısıtlar.

Sunucu ve İşletim Sistemi Öngereksinimleri ;

· Production ve standby ortamların operating sistemleri aynı olmadır. Örneğin production 32 bit linux ise, dataguard kurulması planlanan ortamda 32 bit Linux olmalıdır.

· Her iki sunucu arasında donanım farklılıkları olabilir. (cpu sayısı, disk büyüklükleri, ram sayıları farklı olabilir) Burada şöyle bir problem olabilir, standby tarafındaki donanımlar primary sunucundan daha düşük kalır ise, herhangi bir failover durumunda standby tarafına geçilmesi gerektiğinde, performans anlamında bir sıkıntı yaşanabilir.

· Her iki sunucu üzerindeki işletim sistemi directory’ i yapısı aynı olmalıdır. İşletim sistemleri versiyonlarının aynı olması gerekmez. Ek olarak, standby database’ inin veritabanı na ait directory yapısı primary database’ den farklı olabilir.

Oracle Software Gereksinimleri ;

· Dataguard kurulumun yapılabilmesi için primary sunucu mutlaka enterprise edition olmalıdır. Standart edition dataguardı desteklememektedir. Aynı oracle versiyonları her iki tarafa da kurulmuş olmalıdır.

· Compatible parametresi tüm database’ lerde aynı olmalıdır.

· Primary dayabase’ imiz mutlaka arhive modda olmalıdır.

· Primary database single instance olabileceği gibi Rac’ da olabilir.

· Her primary ve standby database’ in kendi control file’ i olmalıdır.

· Primary ve standby database’ lerini yönetmek için sysdba yetkilerine sahip olmalıdır.

Dataguard recovery operasyonlarında online redo log, archive log ve standby redo loglar kritik önem taşırlar. Primary database den iletilen redo dataları, standby da çalışan RFS process’i tarafından log arşiv dosyalarına veya standby redo log dosyalarına yazılmak üzere alınır. Bunlardan biraz bahsedetmek gerekirse;

Online Redo Logs;

Tüm primary ve logical standby database kurulumu, olası bir kurulum bozulmasına karşı korumak için online redo logları vardır. Fiziksel standby database kurulumları; I/O yu okuma veya yazma modunda açılmadığından online redo logları kullanmazlar. Değişimler physical standby database’ inde uygulanmaz dolayısıyla redo datası oluşturmazlar.

Archive Redo Logs;

Redo log arşivleri, standby ve primary databaseleri işlem (transaction) bazında tutarlı tutabilmek için gereklidir. Primary database’ ler, physical ve logical standby databaseler arşiv redo loglarını kullanırlar. Defaultta oracle database’leri Archive modda çalışacak şekilde set edilmelidir böylece archiver processleri arşivlenmesi gereken redo datalarının kopyasını alarak arşive çıkartırlar.

Standby Redo Logs;

Standby redo loglar, online redo loglara sadece başka bir database’in redo datalarını tutmaları dışında benzerdirler.

Physical ve Logical olmak üzere iki farklı şekilde Dataguard kurulumu bulunmaktadır. Bu yöntemler ve yapabilirlikleri ;

Physical Standby Database ;

Physical Standby database, primary database’ in fiziksel olarak aynısıdır. Disk üzerindeki database yapılarıda primary database ile block bazında aynıdır. Database schema’ ları indexleri içerir ve bunlarda primary ile aynıdır.Dataguard, Physical standby database’ in performansını Redo Apply ile sağlar. Primary database’ inden gelen redo bilgileri mount modda apply edilir. Bu database’ i read only modda açmak isterseniz redo apply’ ini durdurmanız gerekmektedir. Physical standby’ı read write açmak isterseniz de database in Flashback modda olması gerekmektedir ki, sonrasında flashback database ile açıldığı noktaya tekrar dönmeniz gerekecektir.

Physical standby database, tüm data type’ larını , ddl ve dml komutlarını desteklediğinden kullanımda en çok tercih edilen yöntem olduğunu söyleyebiliriz.

Physical standby database, sağlam ve verimli bir disaster recovery imkanıyla birlikte yüksek kullanılabilirliğe sahip olduğunu söyleyebiliriz.

Physical standby database, Primary ve physical standby database’ i arasında switchover ve failover operasyonlarını kolaylıkla yöneterek planlı ve plansız kesinti sürelerini en aza indirir.

Physical standby database, primary database’ i üzerindeki iş yükünü azaltmak amacıyla da kullanılabilir. Rman’ le alınan online backuplar buradan alınabilir. Read only açılabildiği durumlarda çok fazla cpu ve i/o kullanan query’ ler buraya kayrılabilir.

Logical Standby Database ;

Logical standby database, başlangıçta primary database’ in birebir kopyası olarak oluşturulur, fakat sonra farklı bir yapıda olacak şekilde değiştirilebilir. Logical standby database sql komutlarının (primary den gelen) çalıştırılması ile update olur. Sql apply işlemi veritabanı açıkken yapılamaktadır. Dolayısıyla buda kullanıcılara standby database’ den query ve raporlarlarını alabilmeleri için olanak sağlar. Logical standby database tüm data type’ larını desteklememektedir. Support etmediği data type’ları ; BFILE, Collections (including VARRAYS and nested tables), Encrypted columns, Multimedia data types (including Spatial, Image, and Context), ROWID, UROWID, User-defined types, XMLType.

Dataguard kurulumu ile birlikte seçmemiz gereken bir data protection metodu olacaktır. Data protection mode 3 tanedir. Bundan da kısaca bahsettikden sonra kuruluma geçebiliriz.

· Maximum Protection ;

Bu modde sıfır veri kaybı hedeflenmektedir. Şöyleki primary database’ inde yapılan her bir değişilik standby tarafına anında uygulanır ve commit edilinceye kadar beklenilir. Primary tarafında atılan her commit aynı anda standby tarafında atılmış demektir, primary tarafındaki commit’ in succes olması standby tarafında da succes olmasına bağlıdır. Eğer herhangi bir problem dolayı standby tarafında işlem başarısız olursa primary database’ i otomatik olarak down olur. Performans anlamında standby’ a bağlı olduğundan zaman zaman sıkıntılar yaşanması olası bir mode’ dur. Ancak verileriniz sizin için son derece kritik ise bu mode kullanılabilir.

· Maximum Availability ;

Bu mode aslında maximum protection ve maximum performance’ ın birleşimi gibi düşünülebilir. Burada da hedef öncelikli olarak sıfır veri kaybıdır. Ancak maximum protection’ dan farkı standy tarafında herhangi bir neden den dolayı problem çıkarsa primary kapanmıyor, protection mode’ ı değiştiriyor ve maximum performance’ a geçiyor.

· Maximum Performans ;

Her iki mode’ dan farklı olarak burada asıl önemli olan performans’ dır. Varsayılan pretection mode’ da maximum performansdır. Primary database tarafında yapılan işlemlerin sonrasında standby tarafındaki durumu ile ilgilenilmez. Yani iki sunucu veya database arasındaki problemlerden primary sunucu etkilenmez. Standby tarafında bir problem olsa dahi sorun giderildiğinde kaldığı yerden archive’ ları apply işlemine devam eder.

Bu özet bilgilerden sonra physical standby database’ imizi create etmeye başlayabiliriz ;

· Primary database’ imizi force logging moda alıyoruz;

Alter database force logging

Database altered

Bu komut ile daha önce nologging moda alınmış olan bir nesne var ise (log üretilmeyen) onlar geçerliliğini yitirecektir. Böylelikle yapılan her işleme ait log üretilmesi sağlanmaktadır. Kontrol etmek için ;

select force_logging from v$database;

· Primary database’ in archive modda olması gerekiyor.

Aşağıdaki script ile kontrol edebilirsiniz. Sonuç NOARCHIVELOG dönerse aşağıdaki adımları takip ederek archive moda alabilirsiniz.

select log_mode from v$database ;

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

-- archive ile ilgili iki önemli parametreyi set ediyoruz.

ALTER SYSTEM SET log_archive_format='arch_%t_%s_%r_.arc' SCOPE=spfile

ALTER SYSTEM SET log_archive_dest_1='location=D:\arch' SCOPE=spfile

· Primary database’ inde yok ise bir password file create edilir;

orapwd file=PWDist.ora password=oracle entries=5 force=Y

· Primary Database’ ine Standby Redo logların create ve configure edilmesi ;

Create Edilecek Standby Redo Log Sayısı = (maximum number of logfiles for each thread + 1) * maximum number of threads

Bir örnekle açıklayalım ;

Primary database’ indeki redo loglarımız,

SQL> select group#,THREAD#,BYTES,status from v$log;

GROUP# THREAD# BYTES STATUS

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

1 1 52428800 INACTIVE

2 1 52428800 INACTIVE

3 1 52428800 CURRENT

thread başına düşen log sayısı = 3

maximum number of thread = 1

Dolayısıyla create edilecek log sayısı = (3+1)*1 = 4

Bu örnek benim primary database’ im deki ile aynı dolayısıyla bende 4 tane standby redo logları create ediyorum.

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('c:\oracle10g\standby_redo\standby_redo04.log') SIZE 50M

Database altered

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ('c:\oracle10g\standby_redo\standby_redo05.log') SIZE 50M

Database altered

ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ('c:\oracle10g\standby_redo\standby_redo06.log') SIZE 50M

Database altered

ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 ('c:\oracle10g\standby_redo\standby_redo07.log') SIZE 50M

Database altered

Buradaki Group noları önemli, sıra ile devam etmesi gerekiyor, aralarda atlamalar olmayacak.

Primary database’ ine standby redolog ları neden oluşturuyoruz sorusuna, dataguard kurulumunda aslında buna gerek yok ama kurulumdan sonra herhangi bir zamanda switchover yapılmasında bu tarafında standby olarak hayatına devam edebilmesi için gereklidir.

Standby redologlar create edildikden sonra aşağıdaki sorgu ile kontrol edebiliriz ;

SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG

GROUP# THREAD# SEQUENCE# ARCHIVED STATUS

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

4 0 0 YES UNASSIGNED

5 0 0 YES UNASSIGNED

6 0 0 YES UNASSIGNED

7 0 0 YES UNASSIGNED

4 rows selected

· Primary database’ in initial parametrelerinin düzenlenmesi ;

Bilmemiz gerekenler şunlar;

Primary database’ imin db_unique_name = dguard

Net_service_name = dguard

Standby database’ imin db_unique_name = dguard1

Net_service_name = dguard1

Pfile’ de yapılacak olan değişiklerin bir kısmı zaten şu anki pfile’ inizde olan parametreler, kontrol etmeniz yeterli olacaktır.

DB_NAME, CONTROL_FILES, REMOTE_LOGIN_PASSWORDFILE (exclusive olması gerekiyor), LOG_ARCHIVE_FORMAT (db archive modda olduğunda bu parametrede pfile’ inizde olacaktır.)

Aşağıdaki parametreleri ekliyoruz.

DB_UNIQUE_NAME=dguard

LOG_ARCHIVE_CONFIG='DG_CONFIG=(dguard,dguard1)'

LOG_ARCHIVE_DEST_1='location=D:\arch\ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=dguard'

LOG_ARCHIVE_DEST_2='SERVICE=dguard1 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dguard1'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

LOG_ARCHIVE_MAX_PROCESSES=30

FAL_SERVER=dguard1

FAL_CLIENT=dguard

DB_FILE_NAME_CONVERT='dguard1','dguard'

LOG_FILE_NAME_CONVERT=' D:\arch\standby_arch',' D:\arch '

STANDBY_FILE_MANAGEMENT=AUTO

Log_archive_process’ si 30 olarak set ettim ben, oracle’ ın standby için önermiş olduğu process sayısı 30’ dır. Daha azda yapabilirsiniz.

· Primary database’ indeki dbf’ leri standby tarafına kopyalıyoruz. (bu işlemi rman’ i kullanarakda yapabilirsiniz veya primary database’ i shutdown edip OS komutları ile diğer standby tarafına taşıyabilirsiniz. Sadece datafile’ leri taşımanız yeterli olacaktır.

· Standby tarafına da standby redologları eklememiz gerekiyor.

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('c:\oracle10g\standby_redo\standby_redo04.log') SIZE 50M

Database altered

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ('c:\oracle10g\standby_redo\standby_redo05.log') SIZE 50M

Database altered

ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ('c:\oracle10g\standby_redo\standby_redo06.log') SIZE 50M

Database altered

ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 ('c:\oracle10g\standby_redo\standby_redo07.log') SIZE 50M

Database altered

· Standby’ da kullanılmak üzere Primary database’ den standby control file create ediyoruz.

Shutdown immediate;

Startup mount

ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'c:\dguard1.ctl';

ALTER DATABASE OPEN;

· Standby database’ i için primary database’ inden pfile create ediyoruz.

CREATE PFILE='c:\initdguard1.ora' FROM SPFILE;

· Standby tarafı için oluşturmuş olduğumuz pfile’ imizi aşağıdaki şekilde düzenliyoruz.

LOG_ARCHIVE_CONFIG='DG_CONFIG=(dguard,dguard1)'

LOG_ARCHIVE_DEST_1='LOCATION=D:\arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=dguard1'

LOG_ARCHIVE_DEST_2='SERVICE=dguard LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dguard'

STANDBY_FILE_MANAGEMENT='AUTO'

remote_login_passwordfile='EXCLUSIVE'

LOG_ARCHIVE_MAX_PROCESSES=30

LOG_FILE_NAME_CONVERT='D:\arch','D:\arch\standby_arch'

LOG_ARCHIVE_DEST_STATE_1='ENABLE'

LOG_ARCHIVE_DEST_STATE_2='ENABLE'

log_archive_format='arch_%t_%s_%r_.arc'

DB_UNIQUE_NAME='dguard1'

FAL_CLIENT='dguard1'

FAL_SERVER='dguard'

DB_FILE_NAME_CONVERT='dguard','dguard1'

db_name='dguard'

· Primary ve standby sunucuların tns’ lerine her iki database’ in tns bilgilerinide ekliyoruz. (primary de standby’ ın tns bilgiside olması gerekiyor) Listener dosyasına da primary için, standby database’ inin bilgilerini, standby içinde primary db’ in bilgilerini ekliyoruz. Sonrasında her iki node üzerindeki listerları restart ediyoruz.

lsnrctl stop

Lsnrctl start

· Eğer windows bir sunucu üzerine dataguardımızı kurmaya çalışıyor isek, servis olarak yeni SID’ yi aşağıdaki gibi tanıtmamız gerekiyor. Diğer işletim sistemlerinde bu tarz bir işleme gerek yok.

oradim -NEW -SID DGUARD1 -INTPWD oracle1 -STARTMODE manual

· Standby sunucu üzerinde password file create ediyoruz.

orapwd file=PWDdguard1.ora password=oracle entries=5 force=Y

· Standby sunucumuz üzerinde üzerinde değişilik yapmış olduğumuz pfile’ den spfile create ediyoruz.

CREATE SPFILE FROM PFILE='initDGUARD1.ora';

Standby database’ imizi artık açabiliriz.

Startup mount

Apply’ ı başlatmak için;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Disconnect from session komutu tekrar sql satırına düşmenizi ve apply işleminin arka tarafda çalışmasını sağlar.

Aslında dataguard kurulumlarında bizim örneğimizde olduğu gibi standby database’ in SID’ si genelde primary ile aynı verilir. (ki bir disaster durumunda tekrar tüm kullanıcıların tns dosyalarını değiştirmeleri gerekmesin diye, sadace standby’ ın ip’ si farklı olduğundan network ekibi tarafından ip yönlendirmesi –natlama- yapılır. )

Create ettiğimiz dataguardın çalışıp çalışmadığını test etmemiz gerekiyor. Bunun için primary database’i ndeki archive loglara bakıp, bunların standby tarafındaki durumlarını kontrol edebiliriz.

-- Çıkan logları kontrol etmek için;

SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

FROM V$ARCHIVED_LOG

ORDER BY SEQUENCE#;

-- Standby tarafında çıkan logların durumunu kontrol etmek için;

SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

Bu sorgu sonucunda Applied alanı YES olanlar primary database’ inden çıkmış olan o archive’ in standby’ a apply edildiği anlamına gelmektedir.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Rman Restore – Recover Operasyonuna Canlı Bir Ornek (restore – recover – resetlogs)

2011-04-08T23:36:00.000+03:00

Birkaç gün önce production database’ lerinden birinde tablonun biri yanlışlıkla silinmişti. Kayıtları farklı bir ortamdan getirecekleri veya aynı kayıtları bir şekilde tekrar oluşturacakları düşüncesiyle aksiyon almamıştık. Ancak bugün, belirttiğim bu işlemlerin yapılamadığı ve ayın 07’ sindeki kayıtlara mutlaka ulaşılması gerektiği söylenildi. Database’ in protection’ ı 7 gün olduğu için rman backuplarımız vardı. Yaklaşık 600 gb’ lık bir db için farklı bir ortam oluşturarak buraya backupı döndük ve verileri kurtardık. Aslında bununla ilgili olarak geçen sene Aralık ayında bu işlemin nasıl yapılması gerektiği ile ilgili bir yazı yazmıştım. Dolayısıyla konuya antremanlı olduğumuzdan çok sürpriz olmadı. (http://www.kamilturkyilmaz.com/2010/12/07/rman-catalog-database%e2%80%99-i-kullanarak-kartusa-alinan-backupi-farkli-bir-sunucuya-donme-1/)

Örnek olması açısından bugün yaptığımız işlemleride anlatacağım. Başlamadan önce elimizdekilere bir bakalım, 5 gün öncesine ait kartuşda rman backupımız var, bu backupı döneceğimiz farklı bir sunucumuz var ve database’ imizin versiyonu 10.1.0.5 , OS hp-ux.

Önce 5 gün önceki backupı kullanacağımız için onun hangisi olduğunu tespit etmemiz gerekiyor, sonrada restore yaparken tag etiketi ile birlikte döneceğiz.

ORACLE_SID değerini Production SID ile aynı olacak şekilde set ediyoruz.

export ORACLE_SID=PRODDB

Production database’ inin backuplarını sorgulamak için caratalog database’ ine bağlanıyoruz.

prd1:RMAN:./home/oracle>rman catalog rman_cat_user/password@RMAN_CAT_TNS

Recovery Manager: Release 10.1.0.5.0 - 64bit Production

connected to recovery catalog database

RMAN> connect target ibm_rmanuser/password@PRODDB

connected to target database: PRODDB (DBID=9999999999)

RMAN> list backup;

……..

S Key Type LV Size Device Type Elapsed Time Completion Time

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

838735 Incr 0 117G SBT_TAPE 03:20:02 07-APR-11

BP Key: 838749 Status: AVAILABLE Compressed: NO Tag: TAG20110407T015841

Handle: PRODDB_HP_Database_rman.dbf Media:

List of Datafiles in backup set 838735

File LV Type Ckp SCN Ckp Time Name

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

6 0 Incr 3283930085917 07-APR-11 /dizin1/PRODDB/ibank02.dbf

11 0 Incr 3283930085917 07-APR-11 /dizin2/PRODDB/ibankidx02.dbf

16 0 Incr 3283930085917 07-APR-11 /dizin2/PRODDB/ibankhist03.dbf

18 0 Incr 3283930085917 07-APR-11 /dizin2/PRODDB/aurora01.dbf

22 0 Incr 3283930085917 07-APR-11 /dizin1/PRODDB/ibank09.dbf

25 0 Incr 3283930085917 07-APR-11 /dizin1/PRODDB/users02.dbf

26 0 Incr 3283930085917 07-APR-11 /dizin2/PRODDB/FOREKS_TS01.dbf

27 0 Incr 3283930085917 07-APR-11 /dizin2/PRODDB/ibank12.dbf

……..

Ayın 07’ sine ait backupı buldum ve etiketini burdan alıyorum.

Şimdi restore işlemi için test sunucusu üzerinden rman catalog database’ ine bağlanıp işlemlerime başlıyorum. Öncesinde ufak bir bilgi ilk denememde hata aldım sebebide profile dosyasında NLS_LANG parametresi set edilmemiş olmasından dolayı idi. Aldığım hatayı da ekte veriyorumki benzer bir durumla karşılaşan olabilir.

executing command: SET NEWNAME

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of set command at 04/12/2011 17:06:47

ORA-06550: line 1, column 7:

PLS-00553: character set name is not recognized

ORA-06550: line 0, column 0:

PL/SQL: Compilation unit analysis terminated

Profile dosyasına NLS_LANG parametresini ekledikden sonra problem düzeldi. (mevcut ssh sessionlarınızı restart etmemiz unutmayın)

Adımlarımızdan biri pfile, pwd file, tns.ora gibi dosyalarımızı test sunucumuz üzerine taşıyoruz. Lokasyonları oracle software altındaki dizinleri olacak şekilde, pfile’ in içeriği değiştirilmeli tüm lokasyon, memory parametreleri ….

Sqlplus’ a bağlanıp database’i (instance yok, sadece software kurulu ancak pfile’ i okuduğu için) nomount modda açıyorum.

SQL> startup nomount

ORACLE instance started.

Total System Global Area 629145600 bytes

Fixed Size 1299912 bytes

Variable Size 260844088 bytes

Database Buffers 360710144 bytes

Redo Buffers 6291456 bytes

SQL>

Rma’ bağlanıyoruz;

oracle@hpkrttst:/data2/admin/arch2> rman target /

Recovery Manager: Release 10.1.0.5.0 - 64bit Production

connected to target database: PRODDB (DBID=9999999999)

RMAN> connect catalog rman_cat_user/password@RMAN_CAT_TNS

connected to recovery catalog database

RMAN>

Catalog database’ ine bağlandık. Database hala nomount modda dbid’ yi set ediyoruz. (production sistemin dbid değeri ile)

RMAN> set dbid=9999999999

executing command: SET DBID

database name is "PRODDB" and DBID is 9999999999

Öncelikle Control file’ leri restore ediyoruz;

run {

allocate channel dev_1 type 'sbt_tape';

restore controlfile from TAG 'TAG20110407T015841';}

(bu kısmın outputunu alamadığım için buraya koyamıyorum)

Bu kısmıda problemsiz geçtikden sonra database’ i artık mount moda alabiliriz.

SQL> alter database mount ;

Database altered.

Sıra datafile’ leri restore etmeye geldi,

Benim örneğimde 70 tane dbf olduğu için komutun hepsini buraya koymayacağım, tek datafile varmış gibi komutu kısaltarak buraya ekliyorum, sonuçda 1000 tanede olsa komut aynı komut sadece satır sayısı değişiyor;

run {

allocate channel dev_0 type 'sbt_tape';

allocate channel dev_1 type 'sbt_tape';

set newname for datafile 1 to '/data2/oradata/system01.dbf';

set newname for datafile 2 to '/data2/oradata/undotbs01.dbf';

set until time "to_date('07-04-2011 06:00:00','dd-mm-yyyy hh24:mi:ss')";

restore database from TAG 'TAG20110407T015841' ;

switch datafile all;

recover database;

}

Until time benim dönmek istediğim zamanım, tag benim dönmek istediğim backupımın etiketi ve yaklaşık 4 saat sonra bu kısımda tamamlanmıştı.

Restore-recover operasyonuna ait outputuda sadeleştirerek ekliyorum ;

allocated channel: dev_0

channel dev_0: sid=1094 devtype=SBT_TAPE

channel dev_0: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

allocated channel: dev_1

channel dev_1: sid=1093 devtype=SBT_TAPE

channel dev_1: Data Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_

executing command: SET NEWNAME

executing command: SET until clause

Starting restore at 12-APR-11

channel dev_2: starting datafile backupset restore

channel dev_2: specifying datafile(s) to restore from backup set

restoring datafile 00001 to /data2/oradata/system01.dbf

restoring datafile 00002 to /data2/oradata/undotbs01.dbf

[Normal] From: OB2BAR_Oracle8@hpkrttst "PRODDB" Time: 04/12/11 17:25:58

Starting OB2BAR Restore: hpintdb:PRODDB_HP_Database_rman.dbf

[Normal] From: OB2BAR_Oracle8@hpkrttst "PRODDB" Time: 04/12/11 17:26:06

Starting OB2BAR Restore: hpintdb:PRODDB_HP_Database_rman.dbf

channel dev_0: restored backup piece 1

piece handle=PRODDB_HP_Database_rman.dbf tag=TAG20110407T015841

channel dev_0: restore complete

[Normal] From: OB2BAR_Oracle8@hpkrttst "PRODDB" Time: 04/12/11 20:10:59

Completed OB2BAR Restore: hpintdb:PRODDB_HP_Database_rman.dbf

channel dev_1: restored backup piece 1

piece handle=PRODDB_HP_Database_rman.dbf tag=TAG20110407T015841

channel dev_1: restore complete

[Normal] From: OB2BAR_Oracle8@hpkrttst "PRODDB" Time: 04/12/11 20:11:44

Completed OB2BAR Restore: hpintdb:PRODDB_HP_Database_rman.dbf

channel dev_3: restore complete

Finished restore at 12-APR-11

datafile 1 switched to datafile copy

input datafilecopy recid=757 stamp=748296730 filename=/data2/oradata/system01.dbf

datafile 2 switched to datafile copy

input datafilecopy recid=758 stamp=748296730 filename=/data2/oradata/undotbs01.dbf

Starting recover at 12-APR-11

starting media recovery

channel dev_0: starting archive log restore to default destination

channel dev_0: restoring archive log

archive log thread=1 sequence=6460

channel dev_0: restoring archive log

archive log thread=1 sequence=6461

channel dev_0: restoring archive log

archive log thread=1 sequence=6462

channel dev_0: restoring archive log

archive log thread=1 sequence=6463

channel dev_0: restoring archive log

archive log thread=1 sequence=6464

[Normal] From: OB2BAR_Oracle8@hpkrttst "PRODDB" Time: 04/12/11 20:16:20

Starting OB2BAR Restore: hpintdb:PRODDB_HP_Archive_rman.dbf

[Normal] From: OB2BAR_Oracle8@hpkrttst "PRODDB" Time: 04/12/11 20:17:26

Completed OB2BAR Restore: hpintdb:PRODDB_HP_Archive_rman.dbf

channel dev_0: restored backup piece 1

piece handle=PRODDB_HP_Archive_rman.dbf tag=TAG20110408T000521

channel dev_0: restore complete

archive log filename=/data2/admin/arch2/arch_1_6460_738713429.arc thread=1 sequence=6460

archive log filename=/data2/admin/arch2/arch_1_6461_738713429.arc thread=1 sequence=6461

archive log filename=/data2/admin/arch2/arch_1_6462_738713429.arc thread=1 sequence=6462

archive log filename=/data2/admin/arch2/arch_1_6463_738713429.arc thread=1 sequence=6463

archive log filename=/data2/admin/arch2/arch_1_6464_738713429.arc thread=1 sequence=6464

media recovery complete

Finished recover at 12-APR-11

released channel: dev_0

released channel: dev_1

RMAN>

Bundan sonraki adımımız redologlarımızında yeni pathlerini vermek, logların listesini production dan v$log, v$logfile viewlerinden alabilirsiniz. Ben yine kısaltarak ekliyorum komutlarımı;

alter database rename file '/dizin1/PRODDB/redo11m1.log' to '/data2/oradata/redo11m1.log';

Database altered.

alter database rename file '/dizin2/PRODDB/redo11m2.log' to '/data2/oradata/redo11m2.log';

Database altered.

Resetlog ile database’ imizi açıyoruz;

alter database open resetlogs ;

Database altered.

Ve sistemiz ayın 07’ sindeki sabah 06:00 daki haline dönmüş oldu.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Data Guard Broker Konfigurasyonu ve Switchover Operasyonu

2011-04-06T23:31:00.000+03:00

Bir önceki yazımda physical standby database’ in 10g ve 11g sürümleri için ayrı ayrı nasıl create edileceğinden bahsetmiştim. Şimdi oluşturmuş olduğumuz data guardımızı yönetmek için kullanabileceğimiz bir yöntemden bahsetmek istiyorum. Dataguardı enterprise manager konsoldan veya dataguardın yönetim paneli olan Dataguard broker’ dan yöntebiliriz. Bugünde bu yönetim panelinin (DGMGRL) konfigurasyonundan bahsedeceğiz.

Dg broker konfigurasyonu ;

· Primary ve standby sunucularında dgmgrl için listener.ora dosyasını aşağıdaki şekilde düzenliyoruz.

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(SID_NAME = dg1)

(GLOBAL_DBNAME = dg1)

(ORACLE_HOME = /data/oracle/11.2.0/dbhome_1)

)

(SID_DESC =

(SID_NAME = dg2)

(GLOBAL_DBNAME = dg2)

(ORACLE_HOME = /data/oracle/11.2.0/dbhome_1)

)

(SID_DESC =

(SID_NAME = dg1)

(GLOBAL_DBNAME = dg1_DGMGRL)

(ORACLE_HOME = /data/oracle/11.2.0/dbhome_1)

)

(SID_DESC =

(SID_NAME = dg2)

(GLOBAL_DBNAME = dg2_DGMGRL)

(ORACLE_HOME = /data/oracle/11.2.0/dbhome_1)

)

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

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

)

ADR_BASE_LISTENER = /data/oracle

· Hem primary hemde standby database’ imizde dg_broker_start parametresini TRUE’ ya çekiyoruz. Böylelikle “DMON” adıyla yeni bir background processimiz daha doğmuş oluyor.

ALTER SYSTEM SET DG_BROKER_START=TRUE scope=spfile

Parametreyi değiştirdikden sonra aşağıdaki gibi sorgulandığında dg_broker_config_file1 ve file2 parametrelerininde geldiğini göreceksiniz.

SQL> show parameter dg_broker_start

NAME TYPE VALUE

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

dg_broker_config_file1 string C:\...\DR1DGUARD.DAT

dg_broker_config_file2 string C:\...\DR2DGUARD.DAT

dg_broker_start boolean TRUE

DGMGRL’ ye bağlanmaya çalışırken aşağıdaki gibi bir hata ile karşılaşırsanız sebebi, dg_broker_start parametresinin TRUE olmamasındandır. Dolayısıyla öncelikle bu parametreyi kontrol etmeniz gerekir.

DGMGRL> connect sys/oracle@dguard

Connected.

Error:

ORA-16525: the Data Guard broker is not yet available

ORA-06512: at "SYS.DBMS_DRS", line 124

ORA-06512: at line 1

· Dgmgrl ile komut satırına düşüyoruz.

Burada sırası ile primary ve standby sunucuyu data guard broker’ a tanıtıyoruz, configurasyonunu kontrol edip gerekiyorsa değişikliklerimizi yapıp, her iki database’ i enable hale geitirip switchover’ a hazırlıyoruz.

Bu örnekde son durum şu şekilde primary database’ imizin versiyonu 11gR2, linux 5.5 64 bit üzerinde ve sid’ si dg1, standby olan sunucumuz yine 11gR2, linux 5.5 64 bit üzerinde ve sid’ si dg2 şu anda da active standby dataguard olarak çalışıyor.

DGMGRL tarafında yapılan işlemler ;

-- primary database' i eklemek için ;

CREATE CONFIGURATION DG1 as

PRIMARY DATABASE IS DG1

CONNECT IDENTIFIER IS DG1 ;

DGMGRL> CREATE CONFIGURATION dg1 as

> PRIMARY DATABASE IS dg1

> CONNECT IDENTIFIER IS dg1 ;

Configuration "dg1" created with primary database "dg1"

DGMGRL>

-- standby database' i eklemek için ;

ADD DATABASE dg2 AS

CONNECT IDENTIFIER IS dg2

MAINTAINED AS PHYSICAL ;

DGMGRL> ADD DATABASE dg2 AS

> CONNECT IDENTIFIER IS dg2

> MAINTAINED AS PHYSICAL ;

Database "dg2" added

-- son durmu görüntülemek için ;

SHOW CONFIGURATION

DGMGRL> SHOW CONFIGURATION

Configuration

Name: dg1

Enabled: NO

Protection Mode: MaxPerformance

Fast-Start Failover: DISABLED

Databases:

dg1 - Primary database

dg2 - Physical standby database

Current status for "dg1":

DISABLED

-- tanitilmis olan bir database' in ayarlarini CHECK etmek için ;

SHOW DATABASE VERBOSE dg1;

DGMGRL> SHOW DATABASE VERBOSE dg2;

Database

Name: dg2

Role: PHYSICAL STANDBY

Enabled: NO

Intended State: OFFLINE

Instance(s):

dg2

Properties:

InitialConnectIdentifier = 'dg2'

LogXptMode = 'ARCH'

Dependency = ''

DelayMins = '0'

Binding = 'OPTIONAL'

MaxFailure = '0'

MaxConnections = '1'

ReopenSecs = '300'

NetTimeout = '180'

LogShipping = 'ON'

PreferredApplyInstance = ''

ApplyInstanceTimeout = '0'

ApplyParallel = 'AUTO'

StandbyFileManagement = 'AUTO'

ArchiveLagTarget = '0'

LogArchiveMaxProcesses = '10'

LogArchiveMinSucceedDest = '1'

DbFileNameConvert = 'dg1, dg2'

LogFileNameConvert = 'D:\arch, D:\arch\standby_arch'

FastStartFailoverTarget = ''

StatusReport = '(monitor)'

InconsistentProperties = '(monitor)'

InconsistentLogXptProps = '(monitor)'

SendQEntries = '(monitor)'

LogXptStatus = '(monitor)'

RecvQEntries = '(monitor)'

HostName = 'WINTEST_PC'

SidName = 'dg2'

LocalListenerAddress = '(ADDRESS=(PROTOCOL=tcp)(HOST=WINTEST_PC)(PORT=1521))'

StandbyArchiveLocation = 'D:\arch'

AlternateLocation = ''

LogArchiveTrace = '0'

LogArchiveFormat = 'arch_%t_%s_%r_.arc'

LatestLog = '(monitor)'

TopWaitEvents = '(monitor)'

Current status for "dg2":

DISABLED

DGMGRL>

-- tanitilmis olan bir database' in ayarlarini update etmek için (örnek olarak dg1’ in SidName değerinin nasıl değiştirilebildiğini örnekledim) ;

EDIT DATABASE dg1 SET PROPERTY 'SidName'='dg1' ;

DGMGRL> EDIT DATABASE dg2 SET PROPERTY 'SidName'='dg2' ;

Property "SidName" updated

-- dataguard broker' i enable etmek için ;

ENABLE CONFIGURATION;

DGMGRL> enable configuration;

Enabled.

-- son durmu görüntülemek için ;

SHOW CONFIGURATION

DGMGRL> show configuration;

Configuration

Name: dg1

Enabled: YES

Protection Mode: MaxPerformance

Fast-Start Failover: DISABLED

Databases:

dg1 - Primary database

dg2 - Physical standby database

Current status for "dg1":

SUCCESS

DGMGRL>

-- failover operasyonunda geçis için standby database' i hazirlamak (enable etmek) ;

ENABLE DATABASE dg2;

DGMGRL> ENABLE DATABASE dg2;

Enabled.

DGMGRL>

ENABLE DATABASE dg1;

DGMGRL> ENABLE DATABASE dg1;

Enabled.

DGMGRL>

Switchover test ;

Switchover testine başlamadan önce primary ve standby sunucularının statülerini kontrol ediyoruz. Show database komutu ile database’ lerimizi sorguladığımızda mutlaka SUCCES mesajını almamız gerekiyor. Eğer alamıyorsak konfigurasyonla ilgili bir problem var demektir.

DGMGRL> show database dg1

Database - dg1

Role: PRIMARY

Intended State: TRANSPORT-ON

Instance(s):

dg1

Database Status:

SUCCESS

DGMGRL>

DGMGRL> ENABLE DATABASE dg2

Enabled.

DGMGRL> show database dg2

Database - dg2

Role: PHYSICAL STANDBY

Intended State: APPLY-ON

Transport Lag: 0 seconds

Apply Lag: 0 seconds

Real Time Query: ON

Instance(s):

dg2

Database Status:

SUCCESS

Switchover işlemi için bir problem gözükmüyor. Operasyona başlamadan önce sql’ den database’ lerin statüsünü kontrol ediyorum.

(sorgu sonuçları select le seçilen alanlar biraz kalabalık olduğundan dolayı net anlaşılamayabilir. )

Primary database ‘i;

select name, controlfile_type, open_mode, protection_mode,

protection_level, database_role, switchover_status,

dataguard_broker, guard_status, current_scn, db_unique_name,

fs_failover_status

from v$database

NAME CONTROLFILE_TYPE OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE SWITCHOVER_STATUS DATAGUARD_BROKER GUARD_STATUS CURRENT_SCN DB_UNIQUE_NAME FS_FAILOVER_STATUS

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

DG1 CURRENT READ WRITE MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PRIMARY TO STANDBY ENABLED NONE 890056 dg1 DISABLED

1 row selected

Standby database ‘i;

select name, controlfile_type, open_mode, protection_mode,

protection_level, database_role, switchover_status,

dataguard_broker, guard_status, current_scn, db_unique_name,

fs_failover_status

from v$database

NAME CONTROLFILE_TYPE OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE SWITCHOVER_STATUS DATAGUARD_BROKER GUARD_STATUS CURRENT_SCN DB_UNIQUE_NAME FS_FAILOVER_STATUS

DG1 STANDBY READ ONLY WITH APPLY MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PHYSICAL STANDBY NOT ALLOWED ENABLED NONE 890091 dg2 DISABLED

1 row selected

Switchover öncesi durumlarınıda baktıkdan sonra, operasyona başlayabiliriz ;

İlk denememde aşağıdaki gibi bir hata aldım. Hatayı dg2 instance’ ını başarıyle primary yaptıkdan sonra dg1’ i

standby’ a dönüştürürken verdi, hata mesajı ve logu aşağıdaki gibi,

DGMGRL> switchnover to dg2;

Unrecognized command "switchnover", try "help"

DGMGRL> switchover to dg2

Performing switchover NOW, please wait...

New primary database "dg2" is opening...

Operation requires shutdown of instance "dg1" on database "dg1"

Shutting down instance "dg1"...

ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.

Operation requires startup of instance "dg1" on database "dg1"

Starting instance "dg1"...

Unable to connect to database

ORA-12545: Connect failed because target host or object does not exist

Failed.

Warning: You are no longer connected to ORACLE.

Please complete the following steps to finish switchover:

start up instance "dg1" of database "dg1"

DGMGRL>

Hatayı biraz araştırdıkdan sonra problemin sunucuların hostlarında karşılıklı olarak ip ve hostname’ leri olmadığından verdiğini gördüm, karşılıklı olarak ip ve host’ ları /etc/hosts dosyasına ekledikden sonra (root userı ile eklenmesi gerekiyor) tekrar denedim ;

DGMGRL> switchover to dg2

Performing switchover NOW, please wait...

New primary database "dg2" is opening...

Operation requires shutdown of instance "dg1" on database "dg1"

Shutting down instance "dg1"...

ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.

Operation requires startup of instance "dg1" on database "dg1"

Starting instance "dg1"...

ORACLE instance started.

Database mounted.

Database opened.

Switchover succeeded, new primary is "dg2"

DGMGRL>

Hatasız olarak swicth operasyonunu tamamladık. Şu anda artık primary database’ imiz dg2 oldu, standby sunucumuz da dg1 oldu. Kontrol edelim ;

Dg1 üzerinde ;

select name, controlfile_type, open_mode, protection_mode,

protection_level, database_role, switchover_status,

dataguard_broker, guard_status, current_scn, db_unique_name,

fs_failover_status

from v$database

NAME CONTROLFILE_TYPE OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE SWITCHOVER_STATUS DATAGUARD_BROKER GUARD_STATUS CURRENT_SCN DB_UNIQUE_NAME FS_FAILOVER_STATUS

DG1 STANDBY READ ONLY WITH APPLY MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PHYSICAL STANDBY NOT ALLOWED ENABLED NONE 887698 dg1 DISABLED

1 row selected

Dg1’ in artık Standby olduğunu doğruladık. Dg2’ yi kontrol edelim ;

select name, controlfile_type, open_mode, protection_mode,

protection_level, database_role, switchover_status,

dataguard_broker, guard_status, current_scn, db_unique_name,

fs_failover_status

from v$database

NAME CONTROLFILE_TYPE OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE SWITCHOVER_STATUS DATAGUARD_BROKER GUARD_STATUS CURRENT_SCN DB_UNIQUE_NAME FS_FAILOVER_STATUS

DG1 CURRENT READ WRITE MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PRIMARY TO STANDBY ENABLED NONE 887765 dg2 DISABLED

1 row selected

Read write, database rolü primary olarak çalışmakta, şimdide dg2 üzerinde yapılan bir değişikliğin dg1’ e yansıyıp yansımadığını kontrol edelim (dikkat ettiyseniz switcover dışında hiçbirşey yapmadık yani rollerin değişimi operasyonunu dgmgrl kendisi yapıyor ve diğer tarafda );

Dg2’ de tablo create ediyorum ;

create table deneme4 as select * from tab

Table created

Dg1’ de select ediyoruz, bakalım bu tarafa yansıdımı ;

select count(*) from deneme4

COUNT(*)

----------

4653

1 row selected

Herşey çalışıyor J

Sanırım tüm adımlar üzerinden geçmiş olduk, umarım faydalı olmuştur.

Kamil TÜRKYILMAZ
www.kamilturkyilmaz.com

Oracle İnitial Parametreleri

2011-03-30T00:07:00.000+03:00

Oracle da database’ ini startup ile açmaya kalktığımız da instance ilk iş olarak parametre dosyasını okumaya çalışacaktır. Dolayısıyla temel initial parametrelerinden bahsederken bizim için çok kritik file’ lerimizden biri olan spfileSID.ora dosyasından da kısaca bahsedeceğiz.

Parametre dosyaları Linux’ da; $ORACLE_HOME/dbs, Windos’da $ORACLE_HOME/database altında bulunur. Database create edilmesiyle birlikte spfileSID.ora dosyamızda oluşur. Bunun yanısıra parametre değişikliğini database içirisinden Alter system veya Alter database ile yapmak istemediğimiz veya yapamadığımız durumlarda ise kullandığımız birde pfileSID.ora dosyamız olacaktır. Bu dosya db create operasyonu sonrasında oluşmaz, bunu create etmek için sql satırında;

Create pfile from spfile;

Komutunu çalıştırmamız yeterli olacaktır. Hazır yeri gelmişken bu iki dosya arasındaki farklardan bahsedelim;

Pfile, bir metin dosyasıdır ve edit edilebilir. Spfile direk olarak düzenlenemez.

Pfile’ de yapılan değişikliklerin etkin hale gelmesi için database’ i restart etmek gerekir. Spfile üzerinde yapılan değişikliklerin birçoğu hemen etkin hale gelir.

Pfile’ den spfile, spfile’ den pfile oluşturulabilir. Pfile create etmek için; create pfile from spfile, spfile create etmek içinse create spfile from pfile komutunu kullanabiliriz.

Bir farkda dosya isimlerinde var, pfile’ in ismi init(instane_name).ora, spfile’ in ismi ise spfile(instance_name).ora ‘ dır.

Çok kullanılan bazı başlangıç parametrelerinin ne olduğunu açıklamaya çalışalım. Aşağıdaki parametrelerin bazıları 11g ile yeni gelmiş olan parametrelerdir. Dolayısıyla 10g versiyonlarında göremiyor olabilirsiniz.

(Aşağıdaki notlarım uzun bir zaman aralığında oluşmuştur, bir çoğu oracle dökümantasyonlarından, kişisel tecrübelerden bir kısmı ise kimi net sayfalarından derlenmiştir.)

Cluster_database : Real Application Clusterı etkin belirten Real Application Clusters parametresidir. Default değeri false’ dir. True yada False olarak 2 değer alabilir. Modify edilemez.

Compatible : Size Oracle’ ın yeni sürümünü kullanmaya izin verir, aynı zamanda geriye doğru bir önceki sürümü ile uyumluluk sağlar. Eğer daha önceki sürümden geri dönmek gerekirse bu parametre gerekli ve yeterli olacaktır.

Control_files : Database’ in yapısını veritabanı adını, create edilme zamanını, redologların ve datafile’ lerin adını ve lokasyonunu tutan kontrol dosyaları vardır. Control file denetim dosyaları bir veya daha fazla olabilirler, virgülle birbirinden ayrılarak belirtilirler. Minumum 1 ile 8 tane arasında olabilirler. Control file’ lerin lokasyonunu belirtir.

Db_create_file_destination: Data file’ lerin varsayılan konumunu belirtir. Bu lokasyon DB_CREATE_ONLINE_LOG_DEST_n parametresi set edilmemişse control files ve redo log larında lokasyonunu belirtir. Dizinin, Oracle kulanıcısının dosyalarını oluşturması için gerekli izinlere sahip olması gerekir. Oracle create edilirken file isimleri belirtilmez ise, uniqe nameler ile dosyaları create eder.

Alter system set db_create_file_dest = ‘/u01/oradata’;

Create tablespace tbs_1;

Db_create_online_log_dest_n: DB_CREATE_ONLINE_LOG_DEST_n (burada = 1, 2, 3, ...

5)varsayılan default konumu, control files ve redo logların konumunu belirler.

Db_domain : Dağıtılmış bir veritabanı sisteminde, DB_DOMAIN ağ yapısı içinde

veritabanının mantıksal konumu belirtir.

Nls_language : NLS_LANGUAGE veritabanının varsayılan dilini belirtir. Bu dil mesajları,

gün ve ay adları, AD, BC, am, pm ve semboller için kullanılır. Bu parametre de

parametreleri NLS_DATE_LANGUAGE ve NLS_SORT varsayılan değerler belirler.

Open_cursors : (özel SQL alanlara) Bir defada sahip olabilecek açık imleçler sayısını

belirtir. Size, cursors sayısının fazla oturum açmasını engellemek için bu parametreyi

kullanabilmenize olanak sağlar. OPEN_CURSORS değeri yüksek olması, uygulamaların out

of open cursor hatası almasını engeller.

Job_queue_processes : JOB_QUEUE_PROCESSES bu işlerin yürütülmesi için

oluşturulabilir süreçlerinin sayısını belirtir. Bu iş sıra sayısını belirtir örneği (her J000, J999 ...)

işler. Çoğaltma veri yeniler için iş kuyruklarını kullanır. Gelişmiş kuyruk mesaj yayılması için

iş kuyruklarını kullanır. DBMS_JOB paketi üzerinden kullanıcı jobları,oluşturulabilir. Bazı

iş kuyruğu kişi, otomatik olarak oluşturulur. materialized views için örnek yenileme

desteklemektedir. Eğer materialized views otomatik olarak güncellemek istersen, bir veya

daha yüksek bir değere JOB_QUEUE_PROCESSES ayarlamanız gerekir.

Processes : İşletim sistemi kullanıcı sayısını belirtir aynı anda oracle’a

bağlanabilecek sayıyı ifade eder.

Remote_listener : REMOTE_LISTENER ağ adı bir adres veya Oracle Net uzak dinleyici

adresini listesine çözümler belirtir. Adresi veya adres listesi sistem için yapılandırılmış olarak

TNSNAMES.ORA dosyasında belirtilir.

Rollback_segments: ROLLBACK_SEGMENTS adıyla bir veya daha fazla rollback

segmentini allocate eder. Eğer bu parametre set edilirse, instance rollback_segments adıyla

tüm segmentleri kazanır. Dinamik olarak bu parametrenin değerini değiştirmek mümkün

değil, ancak değerini değiştirebilir ve sonra instance’ ı yeniden başlatabilirsiniz.

Undo_management : Alan yönetimi konusunda hangi sistemi kullanmalıyımı belirtir.

Parametre Auto olarak set edildiğinde, instance start olduğunda undo management modu

atomatic olarak devreye girer. Mauel olarak set edildiğinde ise, rollback segment alanları

harici olarak tahsis edilir.

Undo_tablespace: Undo Tablespace’ i, instance start oldukdan sonra, kullanılmak üzere

ayırır. Bu parametre, instance’ da manuel undo management modda ise, sonrasında hata

oluşur ve startup işlemi başarısızlıkla sona erer. Kullanılabilir bir Undo Tablespace’ I yoksa,

instance undo tablespace alanı olmadan start olur. Bu gibi durumlarda, user

transactionları sistem rollback segmentini kullanarak çalışırlar. Normal şartlar altında bu

modda çalışmakdan kaçınmalısınız. Database çalışırken undo tablespace’ ini başka bir

undo tablespace ile replace edebilirsiniz.

Undo_guarantee : Undo tablespace içerisinde belli bir süre mutlaka dataların tutulmasını

sağlar.

Alter tablespace undo_guarantee retention guarantee;

Alter system set undo_tablespace = undo_noguarantee ;

Alter system set undo_tablespace = undo_ guarantee ;

ALTER SYSTEM SET UNDO_RETENTION = 3600

Db_block_size : Database create edilirken set edilir. Sonradan değiştirilemez. Database’

deki blockların size’ ını ifade eder.

Db_create_online_redo_dest_n: Redologların create ederken default olarak nereye

oluşturulacağının bilgisi yer alır.

Control_file_record_keep_time : Control filede dosyaların saklanma süresini belirtir.Bu

parametre 7 ile 365 arasında bir değer alabilir. (default değeri 7’ dir)

remote_os_authent : Bu parametre FALSE ise uzaktan password file dosyası olmadan

sysdba ile bağlanamazsın demek.

Remote_login_password_file : Uzakdan bağlanmak için gereken parametre Default değeri EXCLUSIVE dir. Parametre dosyası kaybolduğunda bu değer NONE’ a çekilip dosya create edilip tekrar EXCLUSIVE’ e alınması gerekmektedir.

Alter system set remote_login_password_file=EXCLUSIVE scope=spfile;

Background_dump_dest : Alert logun pathini verir.

alter system set background_dump_dest = 'D:\orcl rman backup\' scope=both

(alert logun adı = alert_(db_sid).log şeklinde oluşur.)

07_dictionary_accessibility : Select any table yetkisi olan userın data dictionaryi

görmemesi için bu parametre = FALSE olmaldır.

Log_archive_dest_1 (dest) : Archive logların nerede tutulacağının bilgisinin set edildiği

parametre.

log_archive_start : Otomatik arşivlemenin doğrudan yapılıp yapılmayacağını gösterir. Buna

true demezseniz zaman zaman svrmgrl’ye bağlanarak log archive start diyerek, arşiv

dosyalarını yazma işlemini elle kontrol etmeniz gerekir ki bu genelde önerilmez. Ama tape

gibi farklı bir yere zaman zaman arşivlemek için bu yöntemi kullanabilirsiniz. B u parametre

oracle 10g ile birlikte deprecated olmuştur.

log_archive_format : Üretilecek arşiv dosyalarının yazılma biçimini gösteriyor.%s ile logların

sıra numarasını .arc ile de uzantısı belirlenebilir. (%s.arc) 

· %s: log sequence number

· %S: log sequence number, zero filled

· %t: thread number

· %T: thread number, zero filled

· %d: DBID

Log_archive_max_processes : Archive process sayısı bu parametre ile set edilir.

ALTER SYSTEM SET log_archive_max_processes = 4 SCOPE=SPFILE

Db_flashback_retention_target : Veritabanını kaç dakika geriye alabileceğinizin set edildiği

parametre.

alter system set db_flashback_retention_target=60 scope=memory;

Db_recovery_file_dest_size : Yedek işlemleri için ayrılan alanının size’ nın set edildiği

parametre.

ALTER SYSTEM SET Db_recovery_file_dest_size = 35G SCOPE=SPFILE

Db_recovery_file_dest : Flashback bilgisinin nerede tutulacağı bilgisinin set edildiği

parametre. Aynı zamanda default backup dizinidir.

alter system set db_recovery_fıle_dest ='d:/orcl_backup' scope=both;

select * from v$recovery_fıle_dest;

Db_block_checking : Db data blocklarında corruption oluşmasını önler.(değer true yapılırsa

%10’ lar civarında memory kaybı oluşur)

Db_block_checksum : Db corruption oluşmasını engeller, veriyi datafile’ e yazarken çift

kontrol yapar. (değer true yapılırsa I/O da %1-2 civarında artış olur.)

Db_keep_cache_size : Buffer cache’ in keep alanının size’ ı set edilir.

alter system set db_keep_cache_size = 50M scope=MEMORY;

Db_recycle_cache_size : Buffer cache’ in recyclebin alanının size’ ı set edilir.

alter system set db_recycle_cache_size= 10M scope=MEMORY;

Db_cache_size : Buffer cache’ in default alanının size’ ı set edilir.

Shared_pool_size : Shared pool’ un size’ ı set edilir.

Large_pool_size : Large pool’ un size’ ı set edilir.

Java_pool_size : Java pool’ un size’ ı set edilir.

Streams_pool_size : Streams pool’ un size’ ı set edilir.

Sga_max_size : Sga atanmış olan kullanılabilecek alanı ifade eder.

Sga_target : Sga’ nın kullanılabileceği alanı ifade edebilir. Bu değer sga_max_size değerinden büyük olamaz.

ALTER SYSTEM SET sga_max_size = 16000M SCOPE=SPFILE;

ALTER SYSTEM SET sga_target = 15000M SCOPE=SPFILE ;

Pga_aggregate_target : Pga alanına atanan memory alanını ifade eder.

Statistics_level : Sistem tarafından toplanan istatistiklerin nasıl toplanacağının set edildiği

parametredir. 3 değer alabilir. BASIC; Datanın istatistiğini almaz. Dolayısıyla bu değer set

edilmişken ADDM çalışmaz. TYPICAL; default değerdir.segment seviyesinde istatistikleri alır.

ALL; operating systeminde istatistiğini alır. Sisteme yük getirir.

ALTER SYSTEM SET statistics_level=all

Open_cursors : Bir sessionın aynı anda kaç tane select çalıştırabileceğini belirtir. (default değeri 300)

Alter system set open_cursors=350;

User_dump_dest : user trace dosyalarının pathi burda yer alır.

fast_start_mttr_target : Database’ e checkpoint attırma zamanı (değer saniye cinsinden)

ALTER SYSTEM SET fast_start_mttr_target = 900

db_writer_processes : Databasede ki db writer procecessinin kaç adet olduğunu bilgisini bu parametreden alır.

*.db_writer_processes=1

audit_sys_operations : Database’ in izlenmesi sürecinde Sys userının da denetlenip

denetlenmeyeceğini gösteren parametredir. Defaultu FALSE’ dir.

audit_file_dest : sysnin auditlenmesi durumunda sys audit kayıtlarının yerini belirtir.

Windows da windows application log’ larda, linuxda audit_file_dest parametresine bakar.

log_archieve_start : otomatik archive alma parametresidir. İnit.ora dosyasında değeri

log_archieve_start=true şeklinde set edilmelidir. Noarchivelog modunda çalışan bir db

için bu parametre init.ora dosyasında olmaması gerekmektedir.

open_links : OPEN_LINKS uzak veritabanlarına tek oturumda aynı anda açık bağlantı

sayısını belirtir. (deafult’ u 4. static bir parametre olduğundan değiştirildiğinde db restart

etmek gerekir.)

Statistic_level : AWR’ ın çalışmasını sağlayan parametredir. 3 değer alabilir. Defaultu Typical’ dır. All ve Basic’ de olaiblir. Basic olduğunda AWR devredışı kalır.

alter system set statistics_level = all;

Control_management_pack_acces : Addm’ in çalışması için gereken parametredir. Diadnostic+ tuning default değeridir.Diagnostic veya None olarak da set edilebilir. None olması durumunda ADDM devredışı kalır.

remote_dependencies_mode ; İki değer alabilir. timestamp, Clientın istediği procedure ancak serverdaki kayıt tarihi ile, localdeki şimdiki tarih ile uyuşursa çalıştırılır. signature, oracle, bir procedure'nin imzalarının güvenli olarak göz önüne alınmış olması durumunda çalıştırılmasına müsade eder. Bu ayar, PLSQL uygulamalarının tekrar compile edilmeden çalıştırılmasını sağlar.

Alter session SET REMOTE_DEPENDENCIES_MODE = ( SIGNATURE / TIMESTAMP )

Alter system SET REMOTE_DEPENDENCIES_MODE=( SIGNATURE / TIMESTAMP )

Ddl_lock_timeout : Ddl işlemlerinde oluşaacak lock’ lardaki bekleme süresini ifade eder. Defaultu “0”. Bu parametre 0 ile 100.000 arasında değer alabilir. system ve session bazında değiştirilebilir.

Alter system set ddl_lock_timeout = 10 scope = SPFILE

max_dump_file_size : Oluşan trace dosyalarının maximum ne kadar boyutta olacağını belirtir. (bu maximum size sınırlaması alert logu kapsamaz.)

alter system set max_dump_file_size = ‘5m’;

aq_tm_processes : Parametre enable edildiğinde queue mesajlarının monitör edilmesini

sağlar. 0 – 10 arasında değer alır. 0 olduğunda disable olur. Eğer oracle stream

kullanılıyorsa bu parametrenin 0 olarak set edilmesi başka problemlere yol açılacaktır. Oracle

bu değerin 0’ dan bir değer olarak set edilmesini öneriyor.

alter system set aq_tm_processes=0

cursor_sharing : Shared pool içerisinde tutulan sqllerin benzerleri geldiğinde aynı plan ile

diğerlerininde çalışıp çalışmayacağının set edildiği parametredir. SIMILAR = Çalışan sql'

lerin birebir aynı olmasa da benzeyenler için (execution planlarına da bakar) cache den

çalıştırmaya yönlendirir. EXACT = Çalışan sqlerin cache' den çalışması için sorguların

birebir aynısı olması gerekmektedir. FORCE = Cache de Çalışan sql lerin benzeri varsa

mevcut execeution plan kullanılmasını zorlar

ALTER SYSTEM SET cursor_sharing = FORCE SCOPE=MEMORY

Utl_file_dir : Bu parametre bir veya daha fazla lokasyonun, oracle tarafından PL/SQL ile

kullanılmasını sağlar. Bu parametre ile tüm userlar bu lokasyonlardaki bütün file’ leri okuyup

azabilirler.

Alter system set url_file_dir=’/u01/file1/’, ‘/u02/file2/’, ‘/tmp’ scope =SPFILE

CREATE DIRECTORY log_dir AS '/appl/gl/log';

GRANT READ ON DIRECTORY log_dir TO DBA;

CREATE DIRECTORY out_dir AS '/appl/gl/user'';

GRANT READ ON DIRECTORY user_dir TO PUBLIC;

Transportable Tablespace Yöntemi ile Taşınamayan Nesneler İle İlgili Bir Test

2011-03-24T00:09:00.000+02:00

Bu aralar yaklaşık 19 tb büyüklüğündeki bir production database’ imizi farklı bir sunucu üzerine migration yapacağımız için kullanacağımız muhtemel yöntemleri ve bu yöntemlerin artılarını ve eksiklerini test etmekle uğraşıyorum. Transportable tablespace bu yöntemlerin en başında geliyor aslında, burdaki en büyük problemlerimizden biride database içerisindeki materialized views’ lerin durumu, zira transportable tablespace bu nesneleri taşımıyor. Bununla ilgili bugün yapmış olduğum bir testi sizlerle paylaşmak istedim.
Transportable tablespace yöntemi ile ilgili olarak daha önce ayrıntılı bir yazı yazmıştım zaten dolayısıyla burda yöntem ile ilgili detaya girmeyeceğim. (http://www.kamilturkyilmaz.com/2010/10/22/transportable-tablespace-yontemi-ile-database-tasimak/)
Testi yaptığım her iki database’ inde Endian formatları aynı olduğundan dolayı rman tarafında herhangi bir convert işlemi yapmayacağım.

SELECT a.platform_name, endian_format
FROM v$transportable_platform b, v$database a
WHERE b.platform_name = a.platform_name

PLATFORM_NAME                                             ENDIAN_FORMAT
————————————————————— ————–
Linux x86 64-bit                                                    Little
1 row selected

Bu testi yaparken kapsamı biraz daha genişletip public synonym, dblink’ lerin de bu yöntemle taşınamadığını göstermek istedim. Şimdi ilk database’ imizde bu nobjeleri oluşturalım sonrasında taşıyıp sonucuna bakalım.

– public sysnonym’ mizi oluşturalım

create public synonym tester FOR kamil.test
Synonym created

– dblinkimizi oluşturalım

create database link test
connect to KAMIL
identified by xxxxxxx
using ‘alfa’
External database created

– materialized view’ imizi oluşturalım

CREATE MATERIALIZED VIEW kamil.session_log NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
REFRESH COMPLETE
START WITH TO_DATE(’10-Mar-2011 15:50:37′,’dd-mon-yyyy hh24:mi:ss’)
NEXT SYSDATE + 360/1440
AS
select * from v$session
Snapshot created
– MV create ettikden sonra oluşan tabloya bir bakalım
select count(*) from kamil.session_log
COUNT(*)
———-
460
1 row selected

Buraya kadar herşey normal, devam ediyoruz,

– bu test için oluşturmuş olduğumuz tbs_mvtest tablespace’ inin diğer tablespace’ ler ile bir ilişkisi olup olmadığını kontrol edelim.

begin
DBMS_TTS.TRANSPORT_SET_CHECK(‘TBS_MVTEST’,TRUE);
end;
PL/SQL procedure successfully completed
– sonucu select ediyoruz
SELECT * FROM TRANSPORT_SET_VIOLATIONS
0 rows selected

– hiçbir bağımlılığı yok, read only moda alıp meta datanın backupını alalım

alter tablespace TBS_MVTEST read only
Tablespace altered

– expdp için directory create ediyoruz

CREATE DIRECTORY expdp AS ‘/oradata/export/expdp’
Directory created

– exportu alacak user için gerekli yetkilendirmeyi yapalım

GRANT READ,WRITE ON DIRECTORY expdp TO system
Grant succeeded

– çok gerekli değil ama yinede kontrol amaçlı directory’ e bakalım

SELECT * FROM dba_directories where directory_name = ‘EXPDP’
OWNER     DIRECTORY_NAME  DIRECTORY_PATH
SYS           EXPDP              /oradata/export/expdp                                            1 row selected

– expdp ile transportable exportumuzu alalım.

expdp system/oracle DIRECTORY=expdp TRANSPORT_TABLESPACES=TBS_MVTEST TRANSPORT_FULL_CHECK=y DUMPFILE=tbs_mvtest.dmp logfile=tbs_mvtest.log
[oracle@testdb1 expdp]$ expdp system/oracle DIRECTORY=expdp TRANSPORT_TABLESPACES=TBS_MVTEST TRANSPORT_FULL_CHECK=y DUMPFILE=tbs_mvtest.dmp logfile=tbs_mvtest.log
Export: Release 11.2.0.1.0 – Production on Thu Mar 10 16:33:55 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting “SYSTEM”.”SYS_EXPORT_TRANSPORTABLE_01″: “********” DIRECTORY=expdp TRANSPORT_TABLESPACES=TBS_MVTEST TRANSPORT_FULL_CHECK=y DUMPFILE=tbs_mvtest.dmp logfile=tbs_mvtest.log
Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
Processing object type TRANSPORTABLE_EXPORT/TABLE
Processing object type TRANSPORTABLE_EXPORT/COMMENT
Processing object type TRANSPORTABLE_EXPORT/MATERIALIZED_VIEW
Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
Master table “SYSTEM”.”SYS_EXPORT_TRANSPORTABLE_01″ successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_TRANSPORTABLE_01 is:
/oradata/export/expdp/tbs_mvtest.dmp
******************************************************************************
Datafiles required for transportable tablespace TBS_MVTEST:
/oradata/SET/TBS_MVTEST_01.dbf
Job “SYSTEM”.”SYS_EXPORT_TRANSPORTABLE_01″ successfully completed at 16:35:04

[oracle@testdb1 expdp]$ ls -lrt
Test için bu database’ imizdeki tüm dataları oluşturduk ve exportunu aldık, buradaki işimiz TBS_MVTEST tablespace’ ine ait dbf ile alınan exportun dmp file’ ini testin ikinci aşamasını yapacağımız sunucuya taşıdıkdan sonra burayla işimiz kalmıyor.

– Yeni ortamda expdp dizininioluşturalım

CREATE OR REPLACE DIRECTORY expdp AS ‘/oradata/export/expdp’ ;

– yetkilerini verelim

GRANT READ,WRITE ON DIRECTORY expdp TO system;

– dbf’ i ait olduğu dizine OS komutları ile taşıdığımızdan dolayı artık meta datayı import edebiliriz

impdp system/oracle TRANSPORT_DATAFILES=’/oradata/export/expdp/TBS_MVTEST_01.dbf’ DIRECTORY=expdp DUMPFILE=tbs_mvtest.dmp LOGFILE=imp_tbs_mvtest.log

– hata aldık, çünkü burada test nesnelerimi oluşturduğumuz KAMIL schemasını create etmeyi unuttuk.(hata aldığım noktaları özellikle belirtmek istiyorum ki aslında bu kısımların hepsinden daha önemli olduğunu düşünüyorum)

[oracle@testdb2 expdp]$ impdp system/oracle TRANSPORT_DATAFILES=’/oradata/export/expdp/TBS_MVTEST_01.dbf’ DIRECTORY=expdp DUMPFILE=tbs_mvtest.dmp LOGFILE=imp_tbs_mvtest.log
Import: Release 11.2.0.1.0 – Production on Thu Mar 10 16:49:57 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_01″ successfully loaded/unloaded
Starting “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_01″: system/******** TRANSPORT_DATAFILES=/oradata/export/expdp/TBS_MVTEST_01.dbf DIRECTORY=expdp DUMPFILE=tbs_mvtest.dmp LOGFILE=imp_tbs_mvtest.log
Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
ORA-39123: Data Pump transportable tablespace job aborted
ORA-29342: user KAMIL does not exist in the database
Job “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_01″ stopped due to fatal error at 16:50:02

– userı create edip importu tekrar deniyoruz
create user KAMIL identified by oracle
User created

– user ile ilgili bir yetki problemine takılmamak için dba yetkisi veriyorum
grant dba to kamil
Grant succeeded

– import ediyoruz

[oracle@testdb2 expdp]$ impdp system/oracle TRANSPORT_DATAFILES=’/oradata/export/expdp/TBS_MVTEST_01.dbf’ DIRECTORY=expdp DUMPFILE=tbs_mvtest.dmp LOGFILE=imp_tbs_mvtest.log
Import: Release 11.2.0.1.0 – Production on Thu Mar 10 16:52:03 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_01″ successfully loaded/unloaded
Starting “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_01″: system/******** TRANSPORT_DATAFILES=/oradata/export/expdp/TBS_MVTEST_01.dbf DIRECTORY=expdp DUMPFILE=tbs_mvtest.dmp LOGFILE=imp_tbs_mvtest.log
Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
Processing object type TRANSPORTABLE_EXPORT/TABLE
Processing object type TRANSPORTABLE_EXPORT/COMMENT
Processing object type TRANSPORTABLE_EXPORT/MATERIALIZED_VIEW
Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
Job “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_01″ successfully completed at 16:52:16

Aslında tüm işimiz bitti, şimdi kontrol edebiliriz.

select owner,segment_name, tablespace_name from dba_segments
where owner = ‘KAMIL’
OWNER               SEGMENT_NAME                           TABLESPACE_NAME
KAMIL                  SESSION_LOG                                    TBS_MVTEST
1 rows selected

Yukarıdaki script ile MV’ ye ait tablo geldi ancak hemen belirteyimki refresh statüleri update olmadığından yani onlar tablo ile taşınmadığından güncellenmeyecek, dolayısıyla buna artık MV demek yanlış olacaktır.

– synonym’ e bakalım, oda yok.

select * from dba_synonyms
where synonym_name = ‘TESTER’
0 rows selected

– dblink control ediyorum, maalesef oda yok J

SELECT
‘create ‘||DECODE(U.NAME,’PUBLIC’,'public ‘)||’database link ‘||CHR(10)
||DECODE(U.NAME,’PUBLIC’,Null, U.NAME||’.')|| L.NAME||chr(10)
||’connect to ‘ || L.USERID || ‘ identified by ”’
||L.PASSWORD||”’ using ”’ || L.host || ””
||chr(10)||’;’ TEXT
FROM sys.link$ L,
sys.user$ U
WHERE L.OWNER# = U.USER#
and u.name = ‘KAMIL’
0 rows selected

Tabi ben burda zaten transportable tablespace’ in olumsuz yönlerini belirtmek istediğim için seçerek bunları gösterdim. Zira kafanızda bu yöntem zaten hiç birşeyi taşımıyormuş gibi algı oluşturmak istemem.
Testin yöntem ile ilgili bazı soru işaretlerini umarım silmenize yardımcı olmuştur.
Bir başka yazıda görüşmek dileğiyle,

ORA-39125: Worker unexpected fatal error in KUPW$WORKER.UNLOAD_METADATA

2011-03-21T00:02:00.000+02:00

Bir proje için database’ lerin birinden no rows backup almam gerekiyordu.

expdp “‘/ as sysdba’” DIRECTORY=expdp DUMPFILE= metadata_15032011.dmp LOGFILE=metadata_15032011.log CONTENT=METADATA_ONLY FULL=Y

Yukarıdaki script ile almaya çalıştığımda ;

Processing object type SCHEMA_EXPORT/VIEW/GRANT/OBJECT_GRANT

Processing object type SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY

Processing object type SCHEMA_EXPORT/TYPE/TYPE_BODY

Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT

Processing object type SCHEMA_EXPORT/TABLE/TRIGGER

Processing object type SCHEMA_EXPORT/JOB

ORA-39125: Worker unexpected fatal error in KUPW$WORKER.UNLOAD_METADATA while calling DBMS_METADATA.FETCH_XML_CLOB [JOB]

ORA-04030: out of process memory when trying to allocate 281280 bytes (callheap,temporary memory)

----- PL/SQL Call Stack -----

object line object

handle number name

7000003852a3c60 13615 package body SYS.KUPW$WORKER

7000003852a3c60 5898 package body SYS.KUPW$WORKER

7000003852a3c60 2090 package body SYS.KUPW$WORKER

7000003852a3c60 6417 package body SYS.KUPW$WORKER

7000003852a3c60 1264 package body SYS.KUPW$WORKER

70000037dd83788 2 anonymous block

Job "SYS"."DWDATA_METADATA_EXPORT" stopped due to fatal error at 12:59

ORA-39125: Worker unexpected fatal error in KUPW$WORKER.UNLOAD_METADATA while calling DBMS_METADATA.FETCH_XML_CLOB [JOB]

ORA-04030: out of process memory when trying to allocate 281280 bytes (callheap,temporary memory)

Hatası aldım. Hatanın içeriğinde zaten JOB’ lar ile ilgili bir problem olduğunu gösteriyor. Sorun yaratan jobları bulmak için ;

------------------------ problemli nesneyi bulmak için

connect / as sysdba

select object_id, owner, object_name, object_type

from all_objects

where object_id not in (select distinct obj# from source$) and

object_type = 'JOB'

order by owner;

OBJECT_ID OWNER OBJECT_NAME

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

1448959 KAMIL ADV_SHRINK_1567422

1448962 KAMIL SQLSCRIPT_7073194

1448961 KAMIL ADV_MIZANIDX_seg_adv

1047787 ORACLE_OCM MGMT_STATS_CONFIG_JOB

1047786 ORACLE_OCM MGMT_CONFIG_JOB

5 rows selected.

Problem çıkaran jobları buldum. Sonrasında artık kullanılmayacak olan joblar olduğundan hepsini drop etmeye karar verdim. (ki metalinkde de hatanın çözüm yolu olarak önce drop edip no rows backupı başarılı olarak alıp, ihtiyaç var ise tekrar create etmek şeklinde ifade edilmiş, yani gerekiyorsa ddl’ ini alıp sonrasında tekrar create edebilirsiniz)

Drop scripti için aşağıdaki sql’ i kullanabilirsiniz;

select 'execute DBMS_SCHEDULER.DROP_JOB('||owner||'.'||object_name|| ');' drop_komut

from all_objects

where object_id not in (select distinct obj# from source$) and

object_type = 'JOB'

order by owner;

DROP_KOMUT

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

execute DBMS_SCHEDULER.DROP_JOB(KAMIL.ADV_SHRINK_1567422);

execute DBMS_SCHEDULER.DROP_JOB(KAMIL.ADV_MIZANIDX_seg_adv);

execute DBMS_SCHEDULER.DROP_JOB(KAMIL.SQLSCRIPT_7073194);

execute DBMS_SCHEDULER.DROP_JOB(ORACLE_OCM.MGMT_STATS_CONFIG_JOB);

execute DBMS_SCHEDULER.DROP_JOB(ORACLE_OCM.MGMT_CONFIG_JOB);

5 rows selected.

Hazırladığımız drop komutlarını çalıştıralım ;

execute DBMS_SCHEDULER.DROP_JOB(KAMIL.ADV_SHRINK_1567422);

Job Dropped

execute DBMS_SCHEDULER.DROP_JOB(KAMIL.ADV_MIZANIDX_seg_adv);

Job Dropped

execute DBMS_SCHEDULER.DROP_JOB(KAMIL.SQLSCRIPT_7073194);

Job Dropped

execute DBMS_SCHEDULER.DROP_JOB(ORACLE_OCM.MGMT_STATS_CONFIG_JOB);

Job Dropped

execute DBMS_SCHEDULER.DROP_JOB(ORACLE_OCM.MGMT_CONFIG_JOB);

Job Dropped

Tekrar kontrol edelim;

select object_id, owner, object_name, object_type

from all_objects

where object_id not in (select distinct obj# from source$) and

object_type = 'JOB'

order by owner;

0 rows selected.

Artık backupımızı alabiliriz.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Canlı Bir Transportable Tablespace Operasyonu

2011-03-19T23:54:00.000+02:00

Yazılarımdan da anlaşılacağı üzere bu aralar transportable tablespace’ le yakından ilgileniyorum. Bu konudaki yapmış olduğum tüm testleri ve production ortamlarımızda yapmış olduğumuz operasyonlarla ilgili detaylarıda sizinle buradan paylaşmaya çalışıyorum. Şimdiye kadar tranportable tablespace ile ilgili çalışma mantığından, kıstlarından bahsettik. Neden bu konu üzerine bu kadar yoğunlaştığımdan bahsedeyim, ileride sizlerde benzer bir durumla karşılaşırsanız diğer yöntemler ile karşılaştırmada yardımcı olacaktır. Production ortamda kullandığımız bazı database’ lerimizi yeni alınmış olan (yeni sunucu ibm p795 serisi) sunucular üzerine taşımaya çalışıyoruz. İlk taşınacak olan database yaklaşık 3 tb büyüklüğündeki bir database, bu database’ i migrate etme işini bitirdik. Bugün bu taşıma işlemini transportable tablespace yöntemi kullanarak nasıl yaptığımızdan step by step bahsedeceğim ; (Şunu belirtmemde fayda aşağıdaki stepler bizim taşımış olduğumuz database’ in özellikleri ile şekillenmiş adımlar yani bu database’ de materialized view yoktu, eğer olsaydı bir stepde bunun için olacaktı)

· Öncelikle yeni sunucu üzerine db block size, nls ayarları ve sid’ i eski sunucu ile aynı olacak şekilde boş bir instance create edilir. (transportable tablespace gereği)

· Sys, ve system dışında SYSTEM tablespace’ inin altında user nesnesi olmaması gerekiyor. (system, sysaux, undo, temp gibi tbs’ ler taşınmayacağından dolayı)

select owner,segment_name,segment_type, tablespace_name,bytes/1024/1024 boyut from dba_segments where tablespace_name = 'SYSTEM'

and owner in (

select distinct(owner) from dba_segments where tablespace_name = 'SYSTEM' and owner not in('SYS','SYSTEM','OUTLN') )

· Taşınacak olan database’ deki tüm tablespace’ lerin aralarındaki ilişkiler check edilir. Database’ i full olarak taşıdığımızdan dolayı UNDO, TEMP, SYS, SYSAUX şemalarını hariç geri kalan tüm schemaları taşıyoruz. (Ben tüm örneklerdeki tablespace isimlerini değiştirerek yazıyorum) Buradaki amaç bu tablespace’ lerin taşınmayacak olan yukarıda belirtilen diğer tablespace’ ler ile herhangi bi rilişki olmaması.

EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK('USERS,DENEME,PROD', TRUE);

Procedur çalıştıkdan sonra aşağıdaki select ile kontrol ediyoruz. Sonucun no rows dönmesi gerekiyor. Eğer kayıt dönerse farklı tablepsace’ lerdeki nesneler olması gereken tablespace üzerine taşınır. (nesnelerin nasıl taşınabileceğini daha önceki yazılarından bulabilirsiniz)

· İlişkileri test ettikden sonra transportable backup’ a hazırlık için expdp alınacağı directory

oluşturulur.

CREATE DIRECTORY expdp AS '/s4/META_DATA_ISLEM';

GRANT READ,WRITE ON DIRECTORY expdp TO SYSTEM;

· Atlanmaması gereken bir önemli nokta transportable backup alınmadan önce mutlaka dba_recyclebin purge edilmelidir.

Sql>Purge dba_recyclebin;

· Backup öncesinde taşınacak olan tüm tablespace’ ler read only moda alınır.

select 'alter tablespace '||name|| ' read only;' from v$tablespace

where name not in('SYS','SYSTEM','UNDOTBS1','TEMP','SYSAUX')

· Transportable export backupı alınır.

expdp "'/ as sysdba'" directory=DWDATA_TT_EXPORT dumpfile=DWDATA_TT_EXPORT.dmp logfile=DWDATA_TT_EXPORT.log transport_tablespaces=USERS,DENEME,PROD

· Package, sysnonym, link vs gibi nesnelerin diğer ortama taşınması içinde (bunların scriptleride alınıp manuel diğer tarafa atılabilir ancak private linkleri create edebilmek için private linki olan userların şifrelerini bilmeniz gerekir) no rows dump alıyoruz. (burada no rows tablolarında ddl exportunu alacaktır, bunlar için bir aksiyon almazsanız TABLE ACTION EXIST opsiyonu skip olduğundan var olan tabloyu görüp hata verip devam edecektir. Şunu da yapabilirsiniz EXCLUDE=TABLE derseniz tablolara hiç bakma geri kalanı import et de diyebilirsiniz ki bu mantıklı bir seçim diye düşünüyorum )

Bununla ilgili bir not, exportu schema vermeyip full alıp diğer tarafa schema bazında atabilirsiniz. Atlama olma ihtimalini ortadan kaldırmak için faydası olacaktır. Böylelikle ihtiyaç halinde exportu sonrasında tekrar kullanabilirsiniz.

expdp "'/ as sysdba'" DIRECTORY=expdp DUMPFILE= metadata_15032011.dmp LOGFILE=metadata_15032011.log CONTENT=METADATA_ONLY FULL=Y

· Yine bir not, eski ortamda datafile’ lerinizi yeni ortamdaki path’ e taşırken datafile isimlerinizi mutlaka kontrol etmelisiniz, farklı dizinlerde aynı isimle yer alan datafile’ leriniz olabilir, Bunları migration öncesinde rename ile düzeltmeniz faydanıza olacaktır. (eğer tüm datafile’ leri diğer tarafda aynı lokasyonda tutacaksanız)

· Datafile’ lerin taşınması için OS tarafı için CP scriptlerini oluşturmamız gerekiyor.

V$datafile’ den name kolonundan datafile’ lerin adı ve pathleri alındıkdan sonra yazılacak bir scp veya rcp komutu ile bu adım yapılabilir.

· Oracle’ ın internel userları haricindeki tüm userlara ait create scriptleri, role’ lerin create scriptleri oluşturulacak. (Buradan alınacak olan userların default tablespace’ leri not alınır, diğer tarafa create edildiği aşamada tablespace ‘ ler olmayacağı için tüm userların default tablespace’ ini USERS yapıp, işlem bittikden sonra eski haline geri alabilirsiniz.

Create scriptleri için toad’ ın generate schema script menüsünü kullanabilirsiniz. Deafult tablespace’ leri değiştirmek ve eskisinin backupını almak içinse aşağıdaki scriptleri kullanabiliriz.

Default tablespace’ leri değiştirmek için;

select 'alter user '||username|| ' default tablespace USERS;' from dba_users;

Eskisindeki durumu backuplamak için (diğer tarafda işlem bittikden sonra userların default tablespace’ leri orijinal hallerine çevrilmelidir);

select 'alter user '||username|| ' default tablespace '||default_tablespace|| ';' from dba_users

· Eski sistemdeki public dblinkler ile public synonym’ lere ait create scriptleri oluşturulacak. (toad burda da kullanılabilir)

· Eski sunucudaki tnsnames.ora dosyasındaki diğer database’ lere ait aliaslar değiştirilmeden diğer tarafa da kopyalanacak. (dblinklerde problem çıkmaması için)

Buraya kadar ki olan kısımlar, yapılacak migration öncesinde yapmamız gereken ön hazırlıklardı. Şimdi operasyona başlıyoruz ;

· Yeni ortama role’ leri (içleri boş olacak şekilde oluşturuyoruz. Burada henüz hiçbir obje olmadığı için zaten oluşturamayız, ancak create user scriptlerinde role’ lerde olduğundan hata vermemesi için bunları baştan oluşturuyoruz)

· Profile’ leri create ediyoruz.

· Userları create ediyoruz.

· Datafile’ leri taşıyoruz.

· Datafile taşımaları bittikden sonra almış olduğumuz transportable exportu yeni ortama import ediyoruz.

impdp system directory=META_DATA_ISLEM dumpfile=DWDATA_TT_EXPORT.dmp logfile=IMP_DWDATA_TT_EXPORT.log transport_datafiles=/s1/users01.dbf,test01.dbf,prod01.dbf

· İmport bittikden sonra no rows exportun importuna geçmeden önce public db linkler ile public synonym’ leri burada create ediyoruz.

· No rows exportu import ediyoruz.

· Artık tablespace’ lerimizi read write moda geri alabiliriz.

Normal şartlar altında işimiz bu kadar, artık kontrollerimize başlıyabiliriz.

· Yeni sunucunun ip’ si farklı olacağından (tabi diğer sunucuyu kapatıp onun ip’ sini yeni sunucuya vermediyseniz) diğer sunuculardaki tnsnames.ora dosyalarındaki taşıdığımız instance’ a ait ip (veya hostname hangisini kullanıyor iseniz) bilgisini yenisi ile değiştirmemiz gerekecektir.

· Tüm userların eski ortamda default tablespace’ i ne ise burada da aynısı yapılır. (yukarıda bunun backup scriptini oluşturmuştuk zaten)

· Grantlar kontrol edilir. Eski ortam ile karşılaştırılır.

· User create aşamasından hata almamak için rolleri boş olarak create etmiştik, şimdi o rollerin içini dolduruyoruz.

· Burada yapılacak en önemli testi en sona sakladım. Önce user bazında nesne sayılarını her iki ortamda karşılaştırıyoruz. Yenisinde eksik olmamalı.

select owner, count(*) from dba_objects group by owner order by 1 ;

· User bazında yaptığımız karşılaştırmada nesne sayıları eksik çıkan user var ise sadece bu userlar için object type’ ı bazında hangi nesnelerin eksik olduğuna bakılmalıdır. Neden o objenin eksik olduğu araştırılabilir. Eski ortamdan create scripti hazırlanıp yeni ortamda basılarak eksik nesneler tamamlanır.

select object_type,count(*) from dba_objects

where owner = ‘NESNESI_EKSIK_OLAN_USER' group by object_type

order by 1 ;

Aslında kontroller sonrasında problem olmadığını düşündüğünüz anda artık yeni sunucu üzerinden database’ imizi diğer kullanıcılara açabiliriz.

Bu işlemin süresini etkileyen en önemli kriter database’ inizin büyüklüğü ve iki sunucu arasındaki network bağlantısı olduğunu söyleyebilirim. Zira biz yaklaşık 3 tb’ lik bir database’i bu yöntemle (kontroller dahil) 2,5 saat gibi bir sürede bitirebildik.

Mihration çalışmalarımız son hızıyla devam ediyor, taşınacak bir sonraki database’ imiz yaklaşık 6 tb, en son Prod database’ imiz ise 19 tb büyüklüğünde, orda da farklı bir durumla karşılaşır isem buradan sizlerle paylaşacağım.

Kamil TÜRKYILMAZ
www.kamilturkyilmaz.com

Oracle Certified Professional 10G :)

2011-03-19T00:06:00.000+02:00

Çok uzun zamandır ertelemiş olduğum oracle certifikasyon sınavlarına girmeye karar verdim ve 2011 yılını kendi adıma sertifikasyon yılı ilan etmiştim. Henüz sona gelmemiş olsamda yolun yarısını bitirdim sayılır. 2011 yılının İlk 3 ayı içerisinde sırası ile ;

Oracle 11g SQL Expert,

Oracle Certified Associate 10g,

Oracle Certified Associate 11g,

Oracle Certified Professional 10g

Sertifikalarını aldım. Oracle 10g OCP ile yola devam ederken Mart ayının sonunda bir aksilik çıkmazsa 11g

OCP sınavına girmiş olmayı planlıyorum. Gelişmeleri paylaşmaya devam edeceğim.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Global Temporary Table Oluşturmak

2011-03-18T23:56:00.000+02:00

Oracle’ da tablo create ederken eğer tablonun tipini belirtmez iseniz default olarak ilişkisel ve kalıcı olarak tablonuzu oluşturacaktır. Create table komutunuz içerisinde global temporary ifadesini kullanırsanız temporary segmentlerde tutacağınız geçici bir tablo create etmiş olursunuz. Temporary tabloları normal tablolardan çok farklı olarak düşünmemek gerekir, bildiğimiz yöntem (create table ile ) ile create etmiş olduğunu tablolar üzerinde neler yapabiliyorsanız burada da yapabilirsiniz. Temporary olmasından kaynaklı olarak, temporary olarak create edilmiş bir tablo tüm sessionlar tarafından görülebilir ve sadece o session içerisinde varlığını idame ettirir, session sonlandığında temporary table’ da otomatik olarak drop olacaktır.

Temporary table’ ın sytanx’ ından biraz bahsedelim;

CREATE [ GLOBAL TEMPORARY ] TABLE [ schema. ]table

[ (relational_properties) ]

[ ON COMMIT { DELETE | PRESERVE } ROWS ]

[ physical_properties ]

[ table_properties ] ;

Aslında standartın dışında çokm fazla bişey yok, sadece create komutunun başında global temporary ifade var, sonunda iki farklı opsiyonu olan ON COMMIT PRESERVE ROWS veya ON COMMIT DELETE ROWS komutu yer alıyor. Bunların ne ifade ettiğinden bahsedeceğiz. Burada şunu hemen belirtelim temporary tablolar üzerinde yapılan DML işlemleri (yani özellikle update, insert, delete operasyonları) normal tablo üzerinde yapılan DML işlemlerine göre gayet hızlı olacaktır. Çünkü temp tablolar üzerinde yapılan işlemler (temp tablolar yapısı gereği nologging create edilirler) log üretmezler (yani burada yapılan işlemlere ait redo kaydı oluşmaz) dolayısıyla da daha hızlı transactionlar olacaktır. Baştada belirttiğim gibi bu tabloları çalışma mantığı açısından (session bazında olduğunu saymazsak) çok da bir fark yok aslında, temp tablolar üzerinde index create edebilirsiniz. Eğer bir yazılımcı olsaydım elimden geldiğince transactionım içerisinde temp tabloları kullanmaya çalışırdım. Eğer bir sürü join ile bir tablodan veri almak benim işimi çok uzatıyor ise, aynı transaction ile bu veriyi daha basit bir query ile temp bir tabloda oluşturup, sonrasında ihtiyacım varsa indexlerini create edip burdan kullanmak zaman ve performans açısından çok daha verimli olabilir.

Tablomuzu create ederken, create komutumuzun sonunda iki farklı komut eklememiz gerektiğinden bahsettik, şimdi bunu açıklayalım ;

ON COMMIT DELETE ROWS ; Bu komutu kullanırsanız oluşturduğunuz temp tablo içerisindeki verileriniz gönderdiğiniz her COMMIT’ de otomatik olarak silicek demektir.

ON COMMIT PRESERVE ROWS ; Eğer bu komutu kullanırsanız açtığınız session boyunca temp tablo kalıcı olarak duracaktır, sessionı sonlandırdığınız anda tüm verilerinizi kaybedeceksiniz demektir.

Temp tabloyu create ederken bu iki komutu da kullanmaz iseniz tablonuz default olarak ON COMMIT DELETE ROWS ile create edilecektir. (ki default opsiyonu budur)

Bunlarla ilgili bir örnek yapalım ;

DROP TABLE KAMIL.TEST;

Table dropped.

CREATE GLOBAL TEMPORARY TABLE KAMIL.TEST

(

AD VARCHAR2(20 BYTE),

NO NUMBER(5),

ADRES VARCHAR2(30 BYTE)

)

ON COMMIT DELETE ROWS ;

Table created.

insert into test values ('ahmet',15,'istanbul') ;

1 row created.

insert into test select * from test ;

1 row created.

select count(*) from test ;

COUNT(*)

----------

1 row selected.

commit;

Commit complete.

select count(*) from test ;

COUNT(*)

----------

1 row selected.

Commit ile birlikte tüm data silinmiş oldu. PRESERVE seçeneği create edilmiş olduğunda commit de herhangi bir data kaybı yaşanmıyor ancak session sonlandığında datalarda otomatik olarak siliniyor.

DROP TABLE KAMIL.TEST;

Table dropped.

CREATE GLOBAL TEMPORARY TABLE KAMIL.TEST

(

AD VARCHAR2(20 BYTE),

NO NUMBER(5),

ADRES VARCHAR2(30 BYTE)

)

ON COMMIT PRESERVE ROWS ;

Table created.

insert into test values ('ahmet',15,'istanbul') ;

1 row created.

insert into test select * from test ;

1 row created.

select count(*) from test ;

COUNT(*)

----------

1 row selected.

commit;

Commit complete.

select count(*) from test ;

COUNT(*)

----------

1 row selected.

Yine bir ekleme yapmak istiyorum. Temp tablolar parallel transactionlar ile select edilebilirler. (Bunu şu yüzden yazmak istedim, oracle 8i’ de bu özellik yoktu)

Bir sessionda aşağıdaki query’ i çalıştırıp;

select /*+ parallel (test,16) */ count(*) from test

order by 1,2 desc

Diğer bir sessionda da aşağıdaki query ile parallel sessinoları select ettiğimde ;

QCSID COUNT(SID)

125 17

125 nolu sid’ ye ait kendisi ile bilikte 16 tane parallel sesisonda bu sorguyu çalıştığını görebiliyorum. Aynı koşullar tüm DML işlemleri içinde geçerlidir.

Kamil TÜRKYILMAZ
www.kamilturkyilmaz.com

2011’ in İlk TROUG Etkinliği

2011-03-05T00:14:00.000+02:00

Merhaba, arkadaşlar TROUG grubumuzun 2011 yılı ilk aktivitesi Nisan ayında gerçekleştirilecek. Aktivite ile ilgili olarak gelişmeleri http://www.troug.org/ sitesinden takip edebilirsiniz. Etkinliğide bir problem olmazsa bende katılmayı planlıyorum.

Kamil TÜRKYILMAZ
www.kamilturkyilmaz.com

ORA-12838: cannot read/modify an object after modifying it in parallel

2011-03-05T00:00:00.000+02:00

Bir migration çalışması sırasında kullanılacak olan scriptleri tun ederken, insertler i Append hinti vererek yapmaya karar verdim. Bir tablo için peşpeşe birkaç tane insert scripti olanlar da vardı. Append hintinin çalışma mantığını düşünmeden insertler arasına hintleri vererek geçtim. Sabahın 05’ inde migration çalışmasını başlattığımda (bir gözü açık bir gözü kapalı durumda J) scriptler patlamaya başlayınca (tabi bu arada gözlerim açıldı J) farkettimki Append hinti ile bir tabloya peşpeşe insert yapıyorsan iki insert arasında mutlaka transactionı sonlandırmalısın yani commit veya rollback yapmalısın. Appent hinti redo üretimi minumum düzeyde tuttuğundan dolayı bir sonraki insert ile ilgili yeteri kadar data bilgisi sistemde yer almamış oluyor. Dolayısıyla (ORA-12838: bir nesne değiştirildikten sonra paralel olarak okunamaz / değiştirilemez) verdiği bu hatada bir o kadar anlamlı oluyor.

Bir örnekle test senaryomuzu oluşturalım ;

Test tablomuzu create edelim.

create table test(no number )

Table created

Appent hinti ile insert başlatalım.

insert /*+ append */ into test select rownum from dba_objects where rownum< 5

4 rows inserted

Şimdi transactionı sonlandırmadan yine bir insert deneyelim.

insert /*+ append */ into test select rownum from dba_objects where rownum<5

ora-12838: cannot read/modify an object after modifying it in parallel

Hatamızı aldık, insertten vazgeçip select etmeye çalışalım;

select * from test

ora-12838: cannot read/modify an object after modifying it in parallel

yine hata alıyoruz. Sorunu gidermek ve inserte kaldığımız yerden devam etmemiz için transactionı sonlandırıp yeni bir transaction ile devam etmemiz gerekiyor.

commit

Commit complete

insert /*+ append */ into test select rownum from dba_objects where rownum<5

4 rows inserted

commit

Commit complete

select count(*) from test

COUNT(*)

----------

1 row selected

Apend hinti kullanmıyorsak,tabi tahmin edeceğiniz üzere problem yok istediğiniz kadar sıra ile insert edebilirsiniz.

drop table test

Table dropped

create table test as select * from dba_tables where rownum < 5

Table created

insert into test select * from test

4 rows inserted

insert into test select * from test

8 rows inserted

select count(*) from test

COUNT(*)

----------

1 row selected

commit

Commit complete

drop table test

Table dropped

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

LOBINDEX ve LOBSEGMENT’ lerin create, move, rebuild edilmesi

2011-02-25T23:46:00.000+02:00

Tablo ve indexler üzerinde DDL işlemlerinin nasıl yapılacapı konsunda zaman zaman yazılar yazıyoruz. Örneğin tablo ve indexlerin farklı bir tablespace taşınması ile ilgili

(http://kamilturkyilmaz.blogspot.com/2010/10/tablo-ve-indexlerin-tasnmas_25.html) bir yazı yazmıştım. Burada ise logsegment ve logindexleri anlatmaya çalışacağım.

Aslında burada bahsedilmesi gereken en önemli konu lobs ların taşınması olduğunu düşünüyorum. Dolayısıyla naşıl taşıyabiliriz sorusuna cevap ararken diğer yapılacak işlemlerinde sırasıyla üzerinden geçmeyi planlıyorum.

Öncelikle üzerinde çalışabileceğimiz lob alan içeren bir tablo create edelim.

CREATE TABLE deneme_lob (

ad VARCHAR2(30),

soyad VARCHAR2(30),

resim1 BLOB,

resim2 BFILE,

resim3 clob);

Table created

Create edilen her lob alanı için otomatik olarak bir logsegmenti ile lobindexi create edilir. Create etmiş olduğumuz tabloya ilişkin lob alanları sorguladığımızda da bunları görebiliyor oluruz.

SELECT segment_name ,

segment_type ,

tablespace_name tbs_name

FROM user_segments

WHERE segment_name like 'SYS_LOB%'

OR segment_name like 'SYS_IL%'

SEGMENT_NAME SEGMENT_TYPE TBS_NAME

SYS_IL0000051350C00005$$ LOBINDEX TEST1

SYS_LOB0000051350C00005$$ LOBSEGMENT TEST1

SYS_IL0000051350C00003$$ LOBINDEX TEST1

SYS_LOB0000051350C00003$$ LOBSEGMENT TEST1

Bu örneğimizde create edilen tablomuz test1 tablespace2 inde yer alıyor. Şimdi tablo üzerinde oynamadan son durumda hangi nesnenin nerde saklandığını tekrar kontrol edelim ;

SELECT owner, segment_name seg_name,

segment_type seg_type,

tablespace_name tbs_name

FROM dba_segments

WHERE owner = 'KAMIL'

OWNER SEG_NAME SEG_TYPE TBS_NAME

KAMIL DENEME_LOB TABLE TEST1

KAMIL SYS_IL0000051350C00005$$ LOBINDEX TEST1

KAMIL SYS_LOB0000051350C00005$$ LOBSEGMENT TEST1

KAMIL SYS_IL0000051350C00003$$ LOBINDEX TEST1

KAMIL SYS_LOB0000051350C00003$$ LOBSEGMENT TEST1

Tüm nesnelerimiz TEST1 tablesspace’ inde.

Tablomuza yeni bir lob alan ekleyelim;

alter table deneme_lob

add (resim4 blob)

ekledik, şimdi bir tane alan ekleyelim ancak bu farklı bir tablespace’ de store ediliyor olsun ;

alter table deneme_lob

add (resim5 blob)

lob (resim5) store as resim5_seg

(tablespace test2)

Kontrol ediyorum ;

SELECT owner,

segment_name seg_name,

segment_type seg_type,

tablespace_name tbs_name

FROM dba_segments

WHERE owner = 'KAMIL'

OWNER SEG_NAME SEG_TYPE TBS_NAME

KAMIL DENEME_LOB TABLE TEST1

KAMIL SYS_IL0000051350C00005$$ LOBINDEX TEST1

KAMIL SYS_LOB0000051350C00005$$ LOBSEGMENT TEST1

KAMIL SYS_IL0000051350C00003$$ LOBINDEX TEST1

KAMIL SYS_LOB0000051350C00003$$ LOBSEGMENT TEST1

KAMIL SYS_IL0000051350C00006$$ LOBINDEX TEST1

KAMIL SYS_LOB0000051350C00006$$ LOBSEGMENT TEST1

KAMIL SYS_IL0000051350C00007$$ LOBINDEX TEST2

KAMIL RESIM5_SEG LOBSEGMENT TEST2

Tamam yeni alanımız istediğimiz gibi test2 tablespace’ inde store edilecek şekilde create edilmiş oldu.

Şimdi test1 tablespace' inde yer resim1 alanına ait lob segmentlerini test3 tablespace' ine taşıyalım.

ALTER TABLE deneme_lob

MOVE LOB(resim1) STORE AS (TABLESPACE test3)

Table altered.

SELECT owner,

segment_name seg_name,

segment_type seg_type,

tablespace_name tbs_name

FROM dba_segments

WHERE owner = 'KAMIL'

OWNER SEG_NAME SEG_TYPE TBS_NAME

KAMIL DENEME_LOB TABLE TEST1

KAMIL SYS_IL0000051350C00005$$ LOBINDEX TEST1

KAMIL SYS_LOB0000051350C00005$$ LOBSEGMENT TEST1

KAMIL SYS_IL0000051350C00003$$ LOBINDEX TEST3

KAMIL SYS_LOB0000051350C00003$$ LOBSEGMENT TEST3

KAMIL SYS_IL0000051350C00006$$ LOBINDEX TEST1

KAMIL SYS_LOB0000051350C00006$$ LOBSEGMENT TEST1

KAMIL SYS_IL0000051350C00007$$ LOBINDEX TEST2

KAMIL RESIM5_SEG LOBSEGMENT TEST2

Evet, resim alanına ait tüm lob segmentler test3 tablespace’ ine taşınmış oldu. Yukarıdaki örneklerde tablo’ nun tablespace’ ine dokunmadan sadece lob alanlarının tablespace’ lerini değiştirmiştik. Şimdi resim4 alanı ile beraber tablonun tablespace’ inide değiştirellim ;

ALTER TABLE deneme_lob

MOVE TABLESPACE test4 LOB (resim4) STORE AS (TABLESPACE test4)

Kontrol edelim ;

SELECT owner,

segment_name seg_name,

segment_type seg_type,

tablespace_name tbs_name

FROM dba_segments

WHERE owner = 'KAMIL'

OWNER SEG_NAME SEG_TYPE TBS_NAME

KAMIL DENEME_LOB TABLE TEST4

KAMIL SYS_IL0000051350C00005$$ LOBINDEX TEST1

KAMIL SYS_LOB0000051350C00005$$ LOBSEGMENT TEST1

KAMIL SYS_IL0000051350C00003$$ LOBINDEX TEST3

KAMIL SYS_LOB0000051350C00003$$ LOBSEGMENT TEST3

KAMIL SYS_IL0000051350C00006$$ LOBINDEX TEST4

KAMIL SYS_LOB0000051350C00006$$ LOBSEGMENT TEST4

KAMIL SYS_IL0000051350C00007$$ LOBINDEX TEST2

KAMIL RESIM5_SEG LOBSEGMENT TEST2

Resim4 alanı ile birlikte tablonun tablespace’ inide değiştirmiş olduk.

Lobindexlerin nasıl rebuild edilebileceğinden bahsedelim, bilindik rebuild index komutu ile lobindexleri rebuild etmek istediğimizde aşağıdaki gibi hata alırız. Lobindexleri rebuild etmek istiyorsak (bulundukları tablespace’ e) move komutu

taşımak suretiyle rebuild etmiş oluruz.

Alter index SYS_IL0000051350C00005$$ rebuild tablespace test1

Error at line 1

ORA-02327: LOB veri türündeki ifade için dizin yaratılamaz

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Automatic Workload Repository (AWR) Raporlarının Compare Edilmesi

2011-02-23T23:43:00.000+02:00

Bundan önceki yazımda AWR’ ın kullanımı ile giriş yaparak, AWR aracılığı ile snaphotları nasıl create, drop ederizden bahsettik. Şimdi alınan bu snaphotlara ait raporları nasıl compare ederiz buna bakacağız. Özetle şunu yapmaya çalışıyoruz aslında database’ de yaşanan bir performans probleminin ne boyutta olduğuna veya aynı dönemi kapsayan başka bir aralığa göre problemin neden kaynaklandığını, yoğunluk olarak hangi alanlarda artış olduğunu görebilmek ve içinde bulunduğumuz durumu daha iyi yorumlayabilmek için karşılaştırma yapabiliriz.

Şöyle bir problem olduğunu varsayalım. Her gün saat 09:00 ile 11:00 arasında database’ imizin performansı stabil iken, gün içerisinde bu saatler aralığında performansın ciddi bir şekilde düştüğünü varsayalım. Buradaki sorunu tespit içinde dün ile bugün aynı saatler aralığını gösteren AWR raporlarını compare etmeye çalışalım. (bu işlemi konsol üzerinden grafik ekranda çok rahatlıkla yapabilirsiniz ancak biz ortada bir problem var iken konsolun çalışmama riskini gözönünde bulundurarak komut satırından yapmaya çalışacağız)

Bu işlemler için dba yetkisi gerektiğini tekrar hatırlatalım.

Komut satırından scriptimizin yer aldığı awrddrpt.sql dosyasını çalıştırıyoruz.

@$ORACLE_HOME/rdbms/admin/awrddrpt.sql

Sonrasında yapılan işlemlerle ilgili loglarıda ekliyorum ;

SQL> @$ORACLE_HOME/rdbms/admin/awrddrpt.sql

Current Instance

~~~~~~~~~~~~~~~~

DB Id DB Id DB Name Inst Num Inst Num Instance

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

2656835042 2656835042 TEST 1 1 TEST

Specify the Report Type

~~~~~~~~~~~~~~~~~~~~~~~

Would you like an HTML report, or a plain text report?

Enter 'html' for an HTML report, or 'text' for plain text

Defaults to 'html'

Enter value for report_type: text

Type Specified: text

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id Inst Num DB Name Instance Host

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

* 2656835042 1 TEST TEST tester

Database Id and Instance Number for the First Pair of Snapshots

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Using 2656835042 for Database Id for the first pair of snapshots

Using 1 for Instance Number for the first pair of snapshots

Specify the number of days of snapshots to choose from

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Entering the number of days (n) will result in the most recent

(n) days of snapshots being listed. Pressing without

specifying a number lists all completed snapshots.

Enter value for num_days: 2

Listing the last 2 days of Completed Snapshots

Snap

Instance DB Name Snap Id Snap Started Level

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

TEST TEST 6480 22 Feb 2011 00:00 1

6481 22 Feb 2011 01:00 1

6482 22 Feb 2011 02:00 1

6483 22 Feb 2011 03:00 1

6484 22 Feb 2011 04:00 1

6485 22 Feb 2011 05:00 1

6486 22 Feb 2011 06:00 1

6487 22 Feb 2011 07:00 1

6488 22 Feb 2011 08:00 1

6489 22 Feb 2011 09:00 1

6490 22 Feb 2011 10:00 1

6491 22 Feb 2011 11:00 1

6492 22 Feb 2011 12:00 1

6493 22 Feb 2011 12:48 1

6494 22 Feb 2011 12:48 2

6496 22 Feb 2011 14:00 1

6497 22 Feb 2011 15:00 1

6498 22 Feb 2011 16:00 1

6499 22 Feb 2011 17:00 1

6500 22 Feb 2011 18:00 1

6501 22 Feb 2011 19:00 1

6502 22 Feb 2011 20:00 1

6503 22 Feb 2011 21:00 1

6504 22 Feb 2011 22:00 1

6505 22 Feb 2011 23:00 1

6506 23 Feb 2011 00:00 1

6507 23 Feb 2011 01:00 1

6508 23 Feb 2011 02:00 1

6509 23 Feb 2011 03:00 1

6510 23 Feb 2011 04:00 1

6511 23 Feb 2011 05:00 1

6512 23 Feb 2011 06:00 1

6513 23 Feb 2011 07:00 1

6514 23 Feb 2011 08:00 1

6515 23 Feb 2011 09:00 1

6516 23 Feb 2011 10:00 1

6517 23 Feb 2011 11:00 1

6518 23 Feb 2011 12:00 1

6519 23 Feb 2011 13:00 1

6520 23 Feb 2011 14:00 1

6521 23 Feb 2011 15:00 1

6522 23 Feb 2011 16:00 1

Specify the First Pair of Begin and End Snapshot Ids

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Enter value for begin_snap: 6489

First Begin Snapshot Id specified: 6489

Enter value for end_snap: 6491

First End Snapshot Id specified: 6491

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id Inst Num DB Name Instance Host

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

* 2656835042 1 TEST TEST tester

Database Id and Instance Number for the Second Pair of Snapshots

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Using 2656835042 for Database Id for the second pair of snapshots

Using 1 for Instance Number for the second pair of snapshots

Specify the number of days of snapshots to choose from

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Entering the number of days (n) will result in the most recent

(n) days of snapshots being listed. Pressing without

specifying a number lists all completed snapshots.

Enter value for num_days2: 2

Listing the last 2 days of Completed Snapshots

Snap

Instance DB Name Snap Id Snap Started Level

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

TEST TEST 6480 22 Feb 2011 00:00 1

6481 22 Feb 2011 01:00 1

6482 22 Feb 2011 02:00 1

6483 22 Feb 2011 03:00 1

6484 22 Feb 2011 04:00 1

6485 22 Feb 2011 05:00 1

6486 22 Feb 2011 06:00 1

6487 22 Feb 2011 07:00 1

6488 22 Feb 2011 08:00 1

6489 22 Feb 2011 09:00 1

6490 22 Feb 2011 10:00 1

6491 22 Feb 2011 11:00 1

6492 22 Feb 2011 12:00 1

6493 22 Feb 2011 12:48 1

6494 22 Feb 2011 12:48 2

6496 22 Feb 2011 14:00 1

6497 22 Feb 2011 15:00 1

6498 22 Feb 2011 16:00 1

6499 22 Feb 2011 17:00 1

6500 22 Feb 2011 18:00 1

6501 22 Feb 2011 19:00 1

6502 22 Feb 2011 20:00 1

6503 22 Feb 2011 21:00 1

6504 22 Feb 2011 22:00 1

6505 22 Feb 2011 23:00 1

6506 23 Feb 2011 00:00 1

6507 23 Feb 2011 01:00 1

6508 23 Feb 2011 02:00 1

6509 23 Feb 2011 03:00 1

6510 23 Feb 2011 04:00 1

6511 23 Feb 2011 05:00 1

6512 23 Feb 2011 06:00 1

6513 23 Feb 2011 07:00 1

6514 23 Feb 2011 08:00 1

6515 23 Feb 2011 09:00 1

6516 23 Feb 2011 10:00 1

6517 23 Feb 2011 11:00 1

6518 23 Feb 2011 12:00 1

6519 23 Feb 2011 13:00 1

6520 23 Feb 2011 14:00 1

6521 23 Feb 2011 15:00 1

6522 23 Feb 2011 16:00 1

Specify the Second Pair of Begin and End Snapshot Ids

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Enter value for begin_snap2: 6515

Second Begin Snapshot Id specified: 6515

Enter value for end_snap2: 6517

Second End Snapshot Id specified: 6517

Specify the Report Name

~~~~~~~~~~~~~~~~~~~~~~~

The default report file name is awrdiff_1_6489_1_6515.txt To use this name,

press to continue, otherwise enter an alternative.

Enter value for report_name: 22-23_compare_awr

Using the report name 22-23_compare_awr

WORKLOAD REPOSITORY COMPARE PERIOD REPORT

Snapshot Set DB Id Instance Inst Num Release Cluster Host Std Block Size

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

First (1st) 2656835042 TEST 1 11.2.0.1.0 NO tester 8192

Second (2nd) 2656835042 TEST 1 11.2.0.1.0 NO tester 8192

Report written to 22-23_compare_awr

Sql>

Rapor çıktısı çok uzun ve çok detaylı olduğu için maalesef buraya ekleyemiyorum. (sadece ilk satırını ekledim) Burada scripti çalıştırdığımızda neleri set ettiğimize bakalm;

Enter value for report_type: text

(raporun çıktı formatını belirledim, html de seçebilirdim)

Enter value for num_days: 2

(karşılaştırma yapmak için ilk döneme ait değerleri seöçebilmek için son 2 günlük snapshotları listelemesini istedim)

Enter value for begin_snap: 6489

(listelenen bu snapshotlardan 22 Şubatın sabah 09:00 aralığına denk gelen ilk snapshot aralığını seçtim)

Enter value for end_snap: 6491

(listelenen bu snapshotlardan 22 Şubatın sabah 11:00 aralığına denk gelen son snapshot aralığını seçtim)

Buraya kadar compare edeceğim iki dönemden ilkine ait tüm bilgileri girmiş oldum, sıra ikinci dönemimi belirlemeye geldi,

Enter value for num_days2: 2

(karşılaştırma yapmak için ilk döneme ait değerleri seöçebilmek için son 2 günlük snapshotları listelemesini istedim)

Enter value for begin_snap2: 6515

(listelenen bu snapshotlardan 23 Şubatın sabah 09:00 aralığına denk gelen ilk snapshot aralığını seçtim)

Enter value for end_snap2: 6517

(listelenen bu snapshotlardan 23 Şubatın sabah 11:00 aralığına denk gelen son snapshot aralığını seçtim)

Enter value for report_name: 22-23_compare_awr

(ortaya çıkacak olan text dökümanına isim verdim)

Hepsi bu kadar, sonrasında iş ortaya çıkan bu dökümanı incelemeye ve yorumlamaya kaldı. (aslında snapshot create etmekteki adımları sadece peşpeşe 2 defa yaptığımızı düşünebilirizde başka hiçbir fark yok, fark rapor çıktısında göze çarpıyor, tüm sonuçlar 1st period, 2st period başlığı altında teker teker karşılaştırılıyor)

Buraya kadar olan kısım single instance kullanıyor iseniz yapacaklarınızı ifade ediyor,peki RAC kullanılıyor iseniz bu işlemleri nasıl yapacaksınız?

Değişen pek bişey yok, yapılacak olan işlemler hemen hemen aynı, çalıştırılacak olan dosya awrgdrpt.sql isimli file olacaktır.

@$ORACLE_HOME/rdbms/admin/awrgdrpt.sql

Rac’ ın kurulu olduğu instance’ lardan spesifik olarak biri üzerinde almak isterseniz, awrddrpi.sql dosyasını çalıştırmanız yeterli olacaktır.

@$ORACLE_HOME/rdbms/admin/awrddrpi.sql

Umarım faydalı olmuştur.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Automatic Workload Repository (AWR) Nedir, Nasıl Alınır ?

2011-02-23T23:40:00.000+02:00

Bugün database' in performansı ile ilgili belli aralıklarla alınmakta olan snapshotların, bizler için ne ifade ettiğinden, nasıl alınabileceğinden, çalışma şeklinden ve nasıl configure edileceğinden bahsetmek istiyorum.

Automatic Workload Repository (AWR), problemi tespit etmek ve self-tuning yapabilmek amacıyla istatistik toplar. Toplanan bu istastikler ise hem memoryde hem de veritabanında saklanır.

AWR istatistikleri neleri içerir, nelerden oluşur ;

* Erişim ve kullanım istatistiklerini belirlemek için Object İstatistikleri,

* Session bazında, zaman modelli istatistikleri (ki alınan bu istatistikleri V$SYS_TIME_MODEL ve V$SESS_TIME_MODEL viewlerinden görebiliriz.)

* Bazı system ve session istatistiklerini, (bu istatistikleride V$SYSSTAT and V$SESSTAT viewlerinden izleyebiliriz)

* System üzerinde çalışma süresi ve CPU kullanımında top olan sql statmentları ile ilgili istatistikleri,

* ASH istastikleri, son sesessionlara ait işlemler ile ilgili istastikleri

İçerir.

Database istatistikleri AWR aracılığıyla toplanır ve defaultunda enable olarak gelir ve bu opsiyon Statistics_level inital parametsiyle kontrol edilir. Awr’ ın çalışabilmesi için statistic_level parametresi mutlaka TYPICAL veya ALL olarak set edilmelidir. Defaultunda Typical olarak geldiği içinde AWR’ ın defaultu enable’ dır. Bu değer BASIC olarak set edildiğinde artık database’ in istatistikleri toplanmayacağı anlamına gelmektedir. (AWR disable olacağından) Bu parametrenin BASIC olması performans açısından da (tabloların zaman içerisinde structure’ ları, size’ ları, indexleri değişeceğinden, çalışan sql’ lere ait execution planları da zamanla yanlış ve yavaş çalışmaya başlayacağından) olumsuz sonuçlar doğuracaktır. Dolayısıyla bu önerilen bir durum değildir. AWR, database’ in istatistiklerini belirli periyodlarda otomatik olarak alır, eğer statistics_level parametresi BASIC ise yani AWR disable ise, manuel olarak DBMS_WORKLOAD_REPOSITORY package’ ı kullanılarak AWR istatistikleri alabilirsiniz. Ancak system istatistiklerinin büyük bir kısmı (segment istatistikleri ve memory advisor bilgileri gibi) disable olacağından anlık olarak alınmaya çalışılan istatistikler tam olmayabilir.

Ne olduğundan bahsettik, şimdi biraz da Automatic Workload Repository ile ilgili kavramlar üzerinde duralım biraz, sonrasında yönetimi ile devam edeceğiz ;

* Snapshots ;

Snapshots, ADDM tarafından performans karşılaştırmaları yapmak için kullanılan, belirli bir zaman aralığına ait verilerin history bilgisini turarlar. Oracle’ ın kurulumu ile birlikte default olarak her saat başında otomatik olarak çalışır ve saat başında alınan bu snapshot’ larıda 8 gün boyunca saklar. Saat başında otomatik olarak alınmasının yanında, istenildiği anda manuel olarak da snapshot alınabilir. AWR tarafından alınan snapshotlar, Automic Database Diagnostic Monitor (AADDM) tarafında da otomatik olarak incelenmektedir.

AWR raporları, iki dönem arasındaki performansı karşılaştırarak, performans kaybına yol açan sql statementlarının tespit edilmesine yardımcı olur. Oracle 10g ile birlikte tanışmış olduğumuz AWR ve ADDM, kullanıcılardan performans ile ilgili şikayetlerin arttığı zamanlarda sorunun tespiti açısından ciddi rol oynamaktadırlar.

* Baselines ;

Baseline, belli bir zaman aralığındaki performans ile ilgili dataları içerir.

* Adaptive Thresholds

Adaptive thresholds’ lar performans ile ilgili sorunları tespit ve monitor etmeye yardımcı olur. Bunu, tanımlayacağınız thresholdlar da otomatik olarak warning/critical alert seviyeleri bazında yapabiliriz.

Atomatic Workload Repository Yönetimi

* Snapshot Yönetimi

Oracle database kurulumu ile birlikte default olarak her saat başı otomatik olarak snaphot’ ların alınmaktadır. Alınan bu snapshotların saklanmasıda default olarak 8 gün dür. İhtiyaç halinde DBMS_WORKLOAD_REPOSITORY package’ı ile manuel olarak snapshot create, drop veya edit edebiliriz. Bu package kullanabilmek için user’ ın DBA yetkisine sahip olmalıdır. Manuel olarak snapshot create – drop edilmesi işlemi özellikle enterprise manager konsolu kullanamadığımız durumlarda (ki kimiz zaman sistemde yaşanan problemlerden dolayı zaman zaman konsolu kullanamayabiliyoruz) ciddi önemli olduğu durumlarla karşılaşabiliriz. Dolayısıyla sadece bu işlem için değil, database seviyesinde yapacağımız tüm işlemlerin sql komutları ile nasıl yapıldıklarını bilmemiz zaman zaman hayati önem taşıyabiliyor.

Manuel olarak bahsettiğimiz bu işlemleri şimdi sırası ile nasıl yapabileceğimize bakalım;

(aşağıda belirtilen işlemlerin aynısı konsol üzerinden de yapılabilir ben burada sadece konsolu kullanmadan nasıl yapabileceğimiz üzerinde duracağım)

Manuel Snapshot create etmeye çalışalım;

BEGIN

DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();

END;

PL/SQL procedure successfully completed

Yukarıdaki scriptte snapshot kısmında sonraki “()” alanı doldurmadan direk çalıştırdık. Buraya TYPICAL veya ALL da yazabilirdik. Null olarak gönderdiğimizde statistic_level parametreniz ne olarak set etmişseniz onu dikkate alıyor.

Şimdi almış olduğum son snapshot’ ı drop etmek isteyelim ;

BEGIN

DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id => 6495,

high_snap_id => 6495, dbid => 2656835042);

END;

PL/SQL procedure successfully completed

Bu şekilde sadece seçmiş olduğunuz snapshotı drop edebileceğiniz gibi bir aralık içerisindeki tüm snapshotlarıda drop edebilirsiniz.

Snapshot ayarlarını modify etmeye çalışalım ;

BEGIN

DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200,

interval => 30, topnsql => 100, dbid => 3310949047);

END;

PL/SQL procedure successfully completed

Yapılan bu değişikliği şöyle tanımlayabiliriz; retention parametresi ile alınan snapshotların saklanma süresi 43200 dakikaya yani 30 güne, interval 30 ile snapshot alınma sıklığı 30 dak’ ya, topnsql 100 ile snapshotlara dikkate alınanacak top sql sayısı 100’ e set edilmektedir. Dbid parametresi ise üzerinde işlem yapmakta olduğunuz database’ in dbis’ sini ifade etmektedir. (select dbid from v$database ile bulunabilir)

Snapshot ayarları ile ilgili yapmış olduğunuz bu değişiliklerin history’ si neDBA_HIST_WR_CONTROL view’ ini select ederek görebilirsiniz.

select * from sys.DBA_HIST_WR_CONTROL

DBID SNAP_INTERVAL RETENTION TOPNSQL

2040370613 +00 01:00:00.000000 +07 00:00:00.000000 DEFAULT

AWR ile tüm testleri 11gR2 ortamında yaptığımdan dolayı farklı versiyonlarda bu selectin sonuçu farklı çıkacaktır. (örneğin 10gR2 de topnsql alanı olmayacaktır)

* Baseline Yönetimi

Baseline’ lar sistemin optimum olarak çalıştığı bir dönemde create edilip problem oluştuğu dönemde nelerin problem teşkil ettiğini yani iki dönem arasındaki farkı ne olarak görebilmek için alınır. (veya yoğun dönemlerde oluşturulup başka bir aralık ile karşılaştırmamıza olanak sağlar) Baseline’ da iki şekilde create edebiliriz. Konsol üzerinden ve DBMS_WORKLOAD_REPOSITORY package’ ını kullanarak. Package ile nasıl create, drop veya modify baseline yapabiliriz bunlara bakalım kısaca;

create etmek için ;

öncelikle hangi aralığa ait snapshotları kullanarak baseline create edeceğiz buna kara veriyoruz. Aşağıdaki sql’ den mevcut snapshotlara bakabiliriz;

select * from DBA_HIST_SNAPSHOT ;

sonra ;

BEGIN

DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE (start_snap_id => 6517,

end_snap_id => 6518, baseline_name => 'deneme baseline',

dbid => 2656835042, expiration => 30);

END;

PL/SQL procedure successfully completed

Artık oluşturmuş olduğumuz yeni baseline’ nıda ;

select * from DBA_HIST_BASELINE

view’ inde görebiliyoruz.

Create scriptinde expiration parametresini null gönderirseniz asla expire olmayacak demiş olursunuz.bizim bu örneğimizde 30 olarak set etmiş olduk.

Drop etmek için ;

Aynı mantıkda, hangi baseline’ i drop etmek istediğimize DBA_HIST_BASELINEtablosundan bakıp karar veriyoruz. (tabi eğer bilmiyorsak)

Sonra;

BEGIN

DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => 'deneme baseline',

cascade => FALSE, dbid => 2656835042);

END;

PL/SQL procedure successfully completed

Ile drop edebiliriz.

Daha önce alınmış olan bir baseline’ nın adını rename etmek için ;

BEGIN

DBMS_WORKLOAD_REPOSITORY.RENAME_BASELINE (

old_baseline_name => 'deneme baseline',

new_baseline_name => 'dene baseline',

dbid => 2656835042);

END;

PL/SQL procedure successfully completed

Ile yapabiliriz.

İşinize yarayacağını düşündüğüm bazı Automatic Workload Repository ile ilgili wievler ;

V$ACTIVE_SESSION_HISTORY = Database’ deki active sessionlara ait bilgilerin turulduğu view,

DBA_HIST_ACTIVE_SESS_HISTORY = memorydeki en son system aktivitelerine ait bilgileri içerir,

DBA_HIST_BASELINE = database’ deki baseline’ leri listeler,

DBA_HIST_BASELINE_DETAILS = baseline’ lar hakkında detaylı bilgileri içerir,

DBA_HIST_BASELINE_TEMPLATE = system tarafından generate edilen baseline template’ leri hakkında bilgiler içerir,

DBA_HIST_DATABASE_INSTANCE = database environment’ ları hakkında bilgileri içeir,

DBA_HIST_SNAPSHOT = database’deki snapshotlar hakkında bilgileri içerir,

DBA_HIST_WR_CONTROL = AWR’ ın kontrol ayarları ile ilgili bilgileri içerir.

AWR raporu create etmek için ;

Yine konsolu kullanmadan awr raporu create etmek için aşağıdaki adımları izleyebiliriz. Tabi bunları yapan kullanıcının dba yetkisine sahip olması gerektiğini de unutmayalım.

Sql komut satırıdan aşağıdaki sql dosyasını çağırıyoruz;

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

[oracle@tester1 admin]$ sqlplus "/as sysdba"

SQL*Plus: Release 11.2.0.1.0 Production on Wed Feb 23 14:43:32 2011

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql;

Current Instance

~~~~~~~~~~~~~~~~

DB Id DB Name Inst Num Instance

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

2656835042 TEST 1 TEST

Specify the Report Type

~~~~~~~~~~~~~~~~~~~~~~~

Would you like an HTML report, or a plain text report?

Enter 'html' for an HTML report, or 'text' for plain text

Defaults to 'html'

Enter value for report_type: html

Type Specified: html

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id Inst Num DB Name Instance Host

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

* 2656835042 1 TEST TEST tester1

Using 2656835042 for database Id

Using 1 for instance number

Specify the number of days of snapshots to choose from

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Entering the number of days (n) will result in the most recent

(n) days of snapshots being listed. Pressing without

specifying a number lists all completed snapshots.

Enter value for num_days: 1

Listing the last day's Completed Snapshots

Snap

Instance DB Name Snap Id Snap Started Level

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

TEST TEST 6506 23 Feb 2011 00:00 1

6507 23 Feb 2011 01:00 1

6508 23 Feb 2011 02:00 1

6509 23 Feb 2011 03:00 1

6510 23 Feb 2011 04:00 1

6511 23 Feb 2011 05:00 1

6512 23 Feb 2011 06:00 1

6513 23 Feb 2011 07:00 1

6514 23 Feb 2011 08:00 1

6515 23 Feb 2011 09:00 1

6516 23 Feb 2011 10:00 1

6517 23 Feb 2011 11:00 1

6518 23 Feb 2011 12:00 1

6519 23 Feb 2011 13:00 1

6520 23 Feb 2011 14:00 1

Specify the Begin and End Snapshot Ids

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Enter value for begin_snap: 6519

Begin Snapshot Id specified: 6519

Enter value for end_snap: 6520

End Snapshot Id specified: 6520

Specify the Report Name

~~~~~~~~~~~~~~~~~~~~~~~

The default report file name is awrrpt_1_6519_6520.html. To use this name,

press to continue, otherwise enter an alternative.

Enter value for report_name: deneme_awr

Using the report name deneme_awr

…

Report written to deneme_awr

SQL>

awrrpt.sql’ i komut satırından başlatııkdan sonra sırası ile istenilen bilgileri giriyoruz. Bu bilgileri sırasıyla açıklayalım ;

Enter value for report_type: html

(rapor çıktısının formatını belirliyoruz, text veya html giriyoruz)

Enter value for num_days: 1

(snapshot id’ si seçmek için kaç günlük snapshotları görmek istediğimizi söylüyoruz)

Enter value for begin_snap: 6519

Enter value for end_snap: 6520

(alacağımız raporun hangi snapshotları dikkate alması gerektiğini söylüyoruz)

Enter value for report_name: deneme_awr

(raporun ismini set ediyoruz. Hangi dizinde çalıştırdıysanız o dizin altına belirlediğiniz isimle dosyayı create ediyor)

RAC kullanıyorsanız çalıştıracağınız file’ in ismi awrgrpt.sql olacaktır. (@$ORACLE_HOME/rdbms/admin/awrgrpt.sql)

Spesifik bir instance için AWR raporu create etmek için çalıştırılması gereken file awrrpti.sql olacaktır.

(@$ORACLE_HOME/rdbms/admin/awrrpti.sql)

Bu awrrpti.sql çalıştırıldığından yukarıdakinden farklı olarak sizden hangi instance için almanız gerekiyor ise o instance ait dbis bilgisini girmenizi isteyecektir.

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id Inst Num DB Name Instance Host

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

3309173529 1 MAIN main examp1690

3309173529 1 TINT251 tint251 samp251

Rac kullanıpda, spesifik bir instance için AWR raporu create etmek için çalıştırılması gereken file awrgrpti.sql olacaktır.

(@$ORACLE_HOME/rdbms/admin/awrgrpti.sql)

Burada da istenilen bilgiler yukarıdaki örnekdeki gibi girilmesi gerekmektedir.

Şimdi işi biraz daha detaylandırıp snapshot içerisinde bizim için problemli olduğunu düşündüğümüz sadece bir sql için awr raporu almaya çalışalım. Bunun için kendi test ortamımda şöyle bir case oluşturdum. 06y3gf61vurz7 id’ li bir sql’ im var ve sabah 08 – 09 arasında sistemde kaynaklanan yoğunluğun bu sql’ den kaynaklandığını düşünelim ve araştıralım ;

Yaptığım işleme ait log ;

[oracle@tester1 admin]$ sqlplus "/as sysdba"

SQL*Plus: Release 11.2.0.1.0 Production on Wed Feb 23 15:20:14 2011

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> @$ORACLE_HOME/rdbms/admin/awrsqrpt.sql

Current Instance

~~~~~~~~~~~~~~~~

DB Id DB Name Inst Num Instance

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

2656835042 TEST 1 TEST

Specify the Report Type

~~~~~~~~~~~~~~~~~~~~~~~

Would you like an HTML report, or a plain text report?

Enter 'html' for an HTML report, or 'text' for plain text

Defaults to 'html'

Enter value for report_type: text

Type Specified: text

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id Inst Num DB Name Instance Host

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

* 2656835042 1 TEST TEST tester1

Using 2656835042 for database Id

Using 1 for instance number

Specify the number of days of snapshots to choose from

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Entering the number of days (n) will result in the most recent

(n) days of snapshots being listed. Pressing without

specifying a number lists all completed snapshots.

Enter value for num_days: 1

Listing the last day's Completed Snapshots

Snap

Instance DB Name Snap Id Snap Started Level

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

TEST TEST 6506 23 Feb 2011 00:00 1

6507 23 Feb 2011 01:00 1

6508 23 Feb 2011 02:00 1

6509 23 Feb 2011 03:00 1

6510 23 Feb 2011 04:00 1

6511 23 Feb 2011 05:00 1

6512 23 Feb 2011 06:00 1

6513 23 Feb 2011 07:00 1

6514 23 Feb 2011 08:00 1

6515 23 Feb 2011 09:00 1

6516 23 Feb 2011 10:00 1

6517 23 Feb 2011 11:00 1

6518 23 Feb 2011 12:00 1

6519 23 Feb 2011 13:00 1

6520 23 Feb 2011 14:00 1

6521 23 Feb 2011 15:00 1

Specify the Begin and End Snapshot Ids

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Enter value for begin_snap: 6514

Begin Snapshot Id specified: 6514

Enter value for end_snap: 6515

End Snapshot Id specified: 6515

Specify the SQL Id

~~~~~~~~~~~~~~~~~~

Enter value for sql_id: 06y3gf61vurz7

SQL ID specified: 06y3gf61vurz7

Specify the Report Name

~~~~~~~~~~~~~~~~~~~~~~~

The default report file name is awrsqlrpt_1_6514_6515.txt. To use this name,

press to continue, otherwise enter an alternative.

Enter value for report_name: 06y3gf61vurz7_awr_report

Using the report name 06y3gf61vurz7_awr_report

WORKLOAD REPOSITORY SQL Report

Snapshot Period Summary

Report written to 06y3gf61vurz7_awr_report

SQL>

Bu bize şunu veriyor aslında, spesifik olarak bu şekilde bir tespitiniz var ise tüm AWR raporu içerisinde bir sürü veriye bakmaktansa, hızlı bir tespitte bulunabilmek adına bu şekilde alabilirsiniz. Ben rapor çıktısını yazıyı çok uzatmamak adına eklemedim. Sizler test ettiğinizde zaten görüyor olacaksınız.

AWR’ ın farklı diğer özellikleri ile devam ediyor olacağım.

Şimdilik görüşmek üzere.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

LOG_MINER Kurulumu, Konfigurasyonu ve Kullanımı ...

2011-02-09T23:48:00.000+02:00

Log miner database’ in kurulumu ile birlikte gelen ve bir package yardımıyla create edilen bir opsiyon olarak düşünebiliriz. Yapabilirlikleri aslında kimi zaman herhangi bir geri dönüş operasyonuna kalkışmadan hızlı bir şekilde yapılmış olan bir hatayı düzeltebilmemize olanak sağlar.

Log miner database seviyesinde yapılan bir takım işlemlerin geri alınabilmesi için izlenilen bir yöntemdir. Kullanımı ile ilgili olarak genelde yanlışlıkla yapıldığı düşünülen bir DML işlemini geri almak için kullanılabilir diyebiliriz.

Log Miner’ ın kurulumu ve konfigure edilmesi ;

Log Miner’ ın çalışması için SUPPLEMENTAL_LOG_DATA_MIN değerinin database’ de açık olması gerekmektedir. Aşağıdaki gibi kontrol edebilirsiniz ;

SQL> select SUPPLEMENTAL_LOG_DATA_MIN from v$database;

SUPPLEMENTAL_LOG_DATA_MIN

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

Sonucun NO dönmesi durumunda aşağıdaki şekilde Alter edebiliriz ;

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
Database altered.

Sonrasında log_miner’ ın ihtiyaç duyduğu nesnelerin create edilmesi için aşağıdaki dizindeki sql dosyası çalıştırılır.

SQL>@$ORACLE_HOME/rdbms/admin/dbmslm.sql

Paket yaratıldı.

Erişim Yetkisi verme başarılı.

Aşağıdaki yetkinin ilgili kullanıcıya

GRANT EXECUTE_CATALOG_ROLE TO kamil;

Grant complete.

Package kolay erişim için public synonym tanımlanabilir. (schema name’ i kullanılarak da erişilebilir.)

CREATE PUBLIC SYNONYM DBMS_LOGMNR FOR SYS.DBMS_LOGMNR;

Synonym created.

Log_miner’ ın redologları okuması için log_miner’ a tanıtılması, eklenmesi gerekmektedir. Bunun için önce loglarımıza bakalım ;

SQL> SELECT distinct member LOGFILENAME FROM V$LOGFILE;

LOGFILENAME

C:\ORACLE\10GR2\ORADATA\TEST\REDO02.LOG

C:\ORACLE\10GR2\ORADATA\TEST\REDO01.LOG

C:\ORACLE\10GR2\ORADATA\TEST\REDO03.LOG

Log_miner package’ ina okuması için dahil etmek için;

BEGIN DBMS_LOGMNR.ADD_LOGFILE

('C:\ORACLE\10GR2\ORADATA\TEST\REDO01.LOG');

DBMS_LOGMNR.ADD_LOGFILE

('C:\ORACLE\10GR2\ORADATA\TEST\REDO02.LOG');

DBMS_LOGMNR.ADD_LOGFILE

('C:\ORACLE\10GR2\ORADATA\TEST\REDO03.LOG');

END;

PL/SQL procedure successfully completed.

Bakacağı son archive’ ı görmek için ;

SELECT NAME FROM V$ARCHIVED_LOG
WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG);

NAME

C:\ORACLE\10GR2\FLASH_RECOVERY_AREA\TEST\ARCHIVELOG\2011_02_08\O1_MF_1_11_6O2RV9M1_.ARC

C:\ORACLE\10GR2\FLASH_RECOVERY_AREA\TEST\ARCHIVELOG\2011_02_08\O1_MF_1_12_6O2RVHG5_.ARC

Log_Miner kurulumu tamamlanmış oldu, şimdi start ediyoruz ;

BEGIN
DBMS_LOGMNR.START_LOGMNR
(options =>
dbms_logmnr.dict_from_online_catalog);
END;
/

PL/SQL procedure successfully completed.

Sonuçları Select etmek içinse v$logmnr_contents view’ ini kullanabiliriz.

SELECT username,

TO_CHAR (timestamp, 'mm/dd/yy hh24:mi:ss') timestamp,

seg_type_name,

seg_name,

table_space,

session# SID,

serial#,

operation,

sql_redo,

sql_undo,

session_info

FROM v$logmnr_contents

Şimdi bir test yapalım, user_test adında bir userımız var, bu userla önce bir tablo create edelim, sonrasında içerisinde data insert edelim. En son olarak da yaptığımız bu işlemin yanlış olduğunu varsayıp nasıl düzeltebileceğimize bakalım.

create table log_miner_test as select * from dba_tables where rownum < 2 ;

Table created.

insert into log_miner_test select * from log_miner_test ;

1 row created.

commit

Commit complete.

v$logmnr_contents tablosundan select ediyoruz.

SELECT username,

TO_CHAR (timestamp, 'mm/dd/yy hh24:mi:ss') timestamp,

seg_type_name,

seg_name,

table_space,

session# SID,

serial#,

operation,

sql_redo,

sql_undo,

session_info

FROM v$logmnr_contents

where seg_name = 'LOG_MINER_TEST'

and username = 'USER_TEST'

Selectin çıktısı olarak sql_redo, sql_undo ve session_info kısımlarını ayrı olarak ekliyorum ;

USERNAME	TIMESTAMP	SEG_NAME	TABLE_SPACE	SID	SERIAL#	OPERATION
USER_TEST	02.08.2011 17:59	LOG_MINER_TEST		128	49	DDL
USER_TEST	02.08.2011 18:00	LOG_MINER_TEST	TEST_TBS	128	49	INSERT

Sql_redo;

insert into "USER_TEST"."LOG_MINER_TEST"("OWNER","TABLE_NAME","TABLESPACE_NAME","CLUSTER_NAME","IOT_NAME","STATUS","PCT_FREE","PCT_USED","INI_TRANS","MAX_TRANS","INITIAL_EXTENT","NEXT_EXTENT","MIN_EXTENTS","MAX_EXTENTS","PCT_INCREASE","FREELISTS","FREELIST_GROUPS","LOGGING","BACKED_UP","NUM_ROWS","BLOCKS","EMPTY_BLOCKS","AVG_SPACE","CHAIN_CNT","AVG_ROW_LEN","AVG_SPACE_FREELIST_BLOCKS","NUM_FREELIST_BLOCKS","DEGREE","INSTANCES","CACHE","TABLE_LOCK","SAMPLE_SIZE","LAST_ANALYZED","PARTITIONED","IOT_TYPE","TEMPORARY","SECONDARY","NESTED","BUFFER_POOL","ROW_MOVEMENT","GLOBAL_STATS","USER_STATS","DURATION","SKIP_CORRUPT","MONITORING","CLUSTER_OWNER","DEPENDENCIES","COMPRESSION","DROPPED") values ('SYS','CON$','SYSTEM',NULL,NULL,'VALID','10','40','1','255','65536',NULL,'1','2147483645',NULL,'1','1','YES','N','2786','12','0','0','0','20','0','0',' 1',' 1',' N','ENABLED','2786',TO_DATE('30/08/2005', 'DD/MM/RRRR'),'NO',NULL,'N','N','NO','DEFAULT','DISABLED','YES','NO',NULL,'DISABLED','YES',NULL,'DISABLED','DISABLED','NO');

sql_undo;

delete from "USER_TEST"."LOG_MINER_TEST" where "OWNER" = 'SYS' and "TABLE_NAME" = 'CON$' and "TABLESPACE_NAME" = 'SYSTEM' and "CLUSTER_NAME" IS NULL and "IOT_NAME" IS NULL and "STATUS" = 'VALID' and "PCT_FREE" = '10' and "PCT_USED" = '40' and "INI_TRANS" = '1' and "MAX_TRANS" = '255' and "INITIAL_EXTENT" = '65536' and "NEXT_EXTENT" IS NULL and "MIN_EXTENTS" = '1' and "MAX_EXTENTS" = '2147483645' and "PCT_INCREASE" IS NULL and "FREELISTS" = '1' and "FREELIST_GROUPS" = '1' and "LOGGING" = 'YES' and "BACKED_UP" = 'N' and "NUM_ROWS" = '2786' and "BLOCKS" = '12' and "EMPTY_BLOCKS" = '0' and "AVG_SPACE" = '0' and "CHAIN_CNT" = '0' and "AVG_ROW_LEN" = '20' and "AVG_SPACE_FREELIST_BLOCKS" = '0' and "NUM_FREELIST_BLOCKS" = '0' and "DEGREE" = ' 1' and "INSTANCES" = ' 1' and "CACHE" = ' N' and "TABLE_LOCK" = 'ENABLED' and "SAMPLE_SIZE" = '2786' and "LAST_ANALYZED" = TO_DATE('30/08/2005', 'DD/MM/RRRR') and "PARTITIONED" = 'NO' and "IOT_TYPE" IS NULL and "TEMPORARY" = 'N' and "SECONDARY" = 'N' and "NESTED" = 'NO' and "BUFFER_POOL" = 'DEFAULT' and "ROW_MOVEMENT" = 'DISABLED' and "GLOBAL_STATS" = 'YES' and "USER_STATS" = 'NO' and "DURATION" IS NULL and "SKIP_CORRUPT" = 'DISABLED' and "MONITORING" = 'YES' and "CLUSTER_OWNER" IS NULL and "DEPENDENCIES" = 'DISABLED' and "COMPRESSION" = 'DISABLED' and "DROPPED" = 'NO' and ROWID = 'AAAMmXAAHAAAAKNAAA';

session_info;

login_username=USER_TEST client_info= OS_username=WINDB\Administrator Machine_name=CB\WINDB OS_terminal=WINDB OS_process_id=4720:488 OS_program_name=toad.exe

görüldüğü üzere yapmış olduğumuz insert işlemine karşılık sorunu düzeltmek adına delete scriptini verdi, delete işlemi yapmış olsaydık insert scriptini verecekti.

Son olarak log miner’ ın çalışma şeklinden biraz bahsetmek gerekirse, ana mantığı redologları okumaktan geçiyor sonrasında ise çıkan archive’ lar üzerinden okumaya devam ediyor. Dolayısıyla geçmişe dönük ne kadar archive’ ınız var ise o kadar geriye gidebilirsiniz demektir.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

(ORA-00313) Redolog grublarından biri (veya birkaçı) Kaybedildiğinde Yapılması Gerekenler

2011-02-08T23:35:00.000+02:00

Database’ in olmazsa olmaz koşullarından biri en 2 gruplu bir redolog grubunuzun olmasıdır. Redolog’ lar sistemin son ana döndürülmesinde kritik bir önem taşıdığından dolayı groupların memberlanması son derece önemlidir. Redologların nasıl memberlanacağı ile ilgili http://kamilturkyilmaz.blogspot.com/2010/11/redolog-group-tanmlama-degisiklik-yapma.html

gerekli bilgiyi daha önceki yazımda detaylı olarak anlatmıştım. Redologlarınız member’ lı değilse ve herhangi birini kaybetdiyseniz veritabanını kurtarmak için aşağıdaki işlemleri yapmamız gerekir. Ancak burada unutumaması gereken nokta; commit edilmemiş tüm transactionların geri getirilemeyeceği yani veri kaybı yaşanacağıdır.

Benzer bir case’ i oluşturabilmek için database’ imizi shutdown immediate ile kapatıyoruz.

SQL> shutdown immediate;

Veritabanı kapatıldı.

Veritabanı kullanıma kapatıldı.

ORACLE anı kapatıldı.

SQL>

Redologlardan birini, yer aldığı dizinden siliyorum; Şimdi bu haliyle database’ i açmayı deniyorum (hatayı görebilmek için) ;

SQL> startup

ORACLE anı başlatıldı.

Total System Global Area 612368384 bytes

Fixed Size 1250428 bytes

Variable Size 222301060 bytes

Database Buffers 381681664 bytes

Redo Buffers 7135232 bytes

Veritabanı kullanıma açıldı.

ORA-00313: 1 günlük grubunun (thread 1) üyeleri açılamadı

ORA-00312: çevrimiçi günlük 1, thread 1:

'C:\ORACLE\10GR2\ORADATA\TEST\REDO01.LOG'

Database redologlardan redo01.log dosyasını bulamadığı için açamadı. Ve mount modda kaldı. (hatırlayınız; database’ e startup komutu verildiğinde son aşaması datafile’ leri ve redologları açtığı nokta idi, bu aşamayı geçemediğinden dolayı mount modda kalıyor.) Kontrol etmek için ;

SQL> select open_mode from v$database;

OPEN_MODE

----------

MOUNTED

Bu durumdan kurtulmak için şimdi komut satırından database’ i recover ediyoruz. Bu işlem ile kayıp olan redolog dosyası otomatikl olarak daha önce olduğu lokasyona aynı isimle system tarafından otomatik olarak create ediliyor. Bu işlemi “recover database until cancel” komutu ile yapmamızın nedeni gelebildiğimiz kadar son noktaya gelmeye çalıştığımızdan dolayıdır.

SQL> recover database until cancel;

Ortam kurtama tamamlandı.

Bu işlemi başarıyla gerçekleştirdikden sonra yine unutulmaması gereken bir nokta incomplete recovery işlemlerinden sonra mutlaka database’ i open resetlogs komutu ile açabilmemizdir. Zaten open ile açmayı denediğinizde aşağıdaki hatayı alırsınız.

SQL> alter database open ;

alter database open

1 satırında HATA:

ORA-01589: veritabanı açma için RESETLOGS veya NORESETLOGS seçeneği kullanılmalı

Rsetlogs ile açıyoruz.

SQL> alter database open resetlogs;

Veritabanı değiştirildi.

Bu şekilde database’ imizi kurtarmış olduk. Bu işlemi yapabilmek için database’ in archive modda olmasına gerek yoktur. Çünkü bu problemi düzeltmek için archive loglara ihtiyaç bulunmamaktadır.

Bu tarz disaster durumlarında veri kaybı çoğu zaman kabul edilebilir bir nokta olmakdan çıkıyor, dolayısıyla yazımın başında belirtmiş olduğum gibi önlemlerimizi zamanında ve doğru bir şekilde alıyor olmamız gerekiyor.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Database’ in DBID ve DB_NAME Değerini Değiştirmek (dbnewid, nid)

2011-02-02T23:44:00.000+02:00

Özellikle Rman ile bir database’ in backupını başka bir ortama kurduğumuzda database’ in dbid ve db_name değerleri asıl ortamda ne ise burda da aynı olur. Dolayısıyla bu şekilde yeni bir database create ettikden sonra elimizdeki bu yeni ortamın bu değerlerini değiştirmek isteyebiliriz. (özelliklede rman catalog database’ i kullanarak database’ lerimizin backupını alıyorsak, dbid bizim için son derece önemli olacaktır)

Şimdi değişikliğe başlamadan önce dbid ve db_name’ in şu anki değerlerine bakalım (bu değerleri sonradan işlem yapılırken de görebiliriz) ;

SQL> select dbid, name from v$database;
DBID                NAME
----------         ----------
4271840000    KTEST

Öncelikle aşağıdaki dizinde init ve spfile dosyasının olduğundan emin olun. İlgili dizin ;

Linux ortam üzerinde çalışıyorsanız ;

cd $ORACLE_HOME/dbs

Windows üzerinde çalışıyorsanız;

cd $ORACLE_HOME/database

Sonra database’ imizi immediate ile kapatıyoruz.

C:\Documents and Settings\oracle>sqlplus "/as sysdba"
SQL*Plus: Release 11.2.0.1.0 Production on Wed Feb 2 22:39:01 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining and Oracle Database Vault options
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount
ORACLE instance started.
Total System Global Area 627732480 bytes
Fixed Size 1376408 bytes
Variable Size 184553320 bytes
Database Buffers 436207616 bytes
Redo Buffers 5595136 bytes
Database mounted.
SQL>

Mount ile database’i start ettikden sonra, komut satırından aşağıdaki komutu çalıştırıyoruz. Bu konuttaki “nid” bizim dbid ve db_name’ i değiştirmemizi sağlayacak olan komutumuz, target kısmı database’ in şu anki sys userı ve onun şifresi @ kısmı ise database’ imizin db_name’ini, dbname = parametresi ise database’ in yeni name’ mini ifade etmektedir.

nid TARGET=sys/oracle@ktest DBNAME=KAMIL

C:\Documents and Settings\oracle>nid TARGET=sys/oracle@ktest DBNAME=KAMIL
DBNEWID: Release 11.2.0.1.0 - Production on Wed Feb 2 22:40:29 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to database KTEST (DBID=4271840000)
Connected to server version 11.2.0
Control Files in database:
C:\ORACLE11GR2\ORADATA\KTEST\CONTROL01.CTL
C:\ORACLE11GR2\FLASH_RECOVERY_AREA\KTEST\CONTROL02.CTL
Change database ID and database name KTEST to KAMIL? (Y/[N]) => Y
Proceeding with operation
Changing database ID from 4271840000 to 3000141920
Changing database name from KTEST to KAMIL
Control File C:\ORACLE11GR2\ORADATA\KTEST\CONTROL01.CTL - modified
Control File C:\ORACLE11GR2\FLASH_RECOVERY_AREA\KTEST\CONTROL02.CTL - modified
Datafile C:\ORACLE11GR2\ORADATA\KTEST\SYSTEM01.DB - dbid changed, wrote newname
Datafile C:\ORACLE11GR2\ORADATA\KTEST\SYSAUX01.DB - dbid changed, wrote newname
Datafile C:\ORACLE11GR2\ORADATA\KTEST\UNDOTBS01.DB - dbid changed, wrote new name
Datafile C:\ORACLE11GR2\ORADATA\KTEST\USERS01.DB - dbid changed, wrote new name
Datafile C:\ORACLE11GR2\ORADATA\KTEST\TEMP01.DB - dbid changed, wrote new name
Control File C:\ORACLE11GR2\ORADATA\KTEST\CONTROL01.CTL - dbid changed, wrote new me
Control File C:\ORACLE11GR2\FLASH_RECOVERY_AREA\KTEST\CONTROL02.CTL - dbid changed, wrote new name
Instance shut down
Database name changed to KAMIL.
Modify parameter file and generate a new password file before restarting.
Database ID for database KAMIL changed to 3000141920.
All previous backups and archived redo logs for this database are unusable.
Database is not aware of previous backups and archived logs in Recovery Area.
Database has been shutdown, open database with RESETLOGS option.
Succesfully changed database name and ID.
DBNEWID - Completed succesfully.

Yukarıdaki mesajları başarıyla almış olmamız gerekiyor.
Bundan sonraki kısımda ;

Database’ i nomunt modda açıyoruz.

SQL> startup mount
ORACLE instance started.
Total System Global Area 627732480 bytes
Fixed Size 1376408 bytes
Variable Size 184553320 bytes
Database Buffers 436207616 bytes
Redo Buffers 5595136 bytes

Yapılan bu değişikliği aşağıdaki Alter ile de system üzerinden spfile’ e yazdırıyoruz.

SQL> ALTER SYSTEM SET DB_NAME=KAMIL SCOPE=SPFILE;
System altered.

Şimdi immediate ile tekrar kapatıyoruz ;

SQL> shutdown immediate
ORA-01507: database not mounted
ORACLE instance shut down.

Aslında bundan sonraki kısım klasik database operayonları gibi düşünebiliriz. Database’in name’ I değiştiğinden dolayı ona uygun bir password file create etmemiz gerekiyor. Ek olarak spfile dosyamızın adını da yeni SID’ imizi içerek şekilde rename edeceğiz.

orapwd file=C:\oracle11gR2\product\pwdKAMIL.ora password=oracle entries=5

Ben bu çalışmamı windows bir sunucu üzerinde yaptığımdan dolayı ..\database\ dizinindeki spfileKTEST.ora dosyasının adını spfileKAMIL.ora olacak şekilde rename ediyorum.

Yine windowslar için unutulmaması gereken bir nokta database ilk create ederken windows servisleride create ettiğinden dolayı (oracle servisleri SID bazında create edilmekte) bu servisleri de değiştirmemiz gerekiyor. Yani eski SID’ li servis tanımı silinip yerine yeni SID’ li servis tanımını eklememiz gerekiyor.

Eski tanımı silmek için ;

C:\Documents and Settings\oracle>oradim -delete -sid KTEST
Instance deleted.

Yenisini eklemek içinse;

C:\Documents and Settings\oracle>oradim -new -sid KAMIL -intpwd oracle –startmode a -pfile C:\oracle11gR2\product\spfileKAMIL.ora
Instance created.

Yapılan bu değişiklikden listener’ ında etkilenmesi için stop / start yapıyoruz.

C:\Documents and Settings\oracle>lsnrctl stop
LSNRCTL for 32-bit Windows: Version 11.2.0.1.0 - Production on 02-FEB-2011 23:29:07
Copyright (c) 1991, 2010, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dataguart)(PORT=1521)))
The command completed successfully

C:\Documents and Settings\oracle>lsnrctl start
LSNRCTL for 32-bit Windows: Version 11.2.0.1.0 - Production on 02-FEB-2011 23:29:12
Copyright (c) 1991, 2010, Oracle. All rights reserved.
Starting tnslsnr: please wait...
TNSLSNR for 32-bit Windows: Version 11.2.0.1.0 - Production
System parameter file is c:\oracle11gR2\product\network\admin\listener.ora
Log messages written to c:\oracle11gr2\diag\tnslsnr\dataguart\listener\alert\log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dataguart)(PORT=1521)))
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dataguart)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for 32-bit Windows: Version 11.2.0.1.0 - Produ
ction
Start Date 02-FEB-2011 23:29:16
Uptime 0 days 0 hr. 0 min. 5 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File c:\oracle11gR2\product\network\admin\listener.ora
Listener Log File c:\oracle11gr2\diag\tnslsnr\dataguart\listener\alert\log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dataguart)(PORT=1521)))
Services Summary...
Service "CLRExtProc" has 1 instance(s).
Instance "CLRExtProc", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
C:\Documents and Settings\oracle>

Buraya kadar herşey yolunda, artık yeni spfile’ imiz ile database’ imizi açabiliriz. Ancak database’ i startup ile açmayacağız. Database’ in dbid ve name’ I değiştiğinden dolayı, bu database’ den alınmış olan backuplar artık kullanılamaz duruma gelmiştir çünkü artık dbid ve name’ ler farklı, dolayısıyla database’ in hayata sıfırdan yeni bir başlangıç yapması için open RESETLOGS ile açmamız gerekiyor (başka türlü açılamaz) ;

SQL> startup mount
ORACLE instance started.
Total System Global Area 627732480 bytes
Fixed Size 1376408 bytes
Variable Size 184553320 bytes
Database Buffers 436207616 bytes
Redo Buffers 5595136 bytes
Database mounted.
SQL> alter database open resetlogs ;
Database altered.

Şimdi yeni dbid ve name değerlerimizi kontrol edelim.

SQL> select dbid, name from v$database;
DBID                NAME
----------          ---------
3000141920     KAMIL

Database’ in sadece DBID’ sini veya DB_NAME’ ini de değiştirebilirsiniz, şöyleki ;

Sadece DBID değiştirmek isterseniz ;

nid TARGET=sys/oracle@ktest komutunu çalıştırmanız yeterli olacaktır. Bu komut sadece dbid’ yi değiştirecektir ve name aynı kalacaktır. Burada db_name’ dokunmadığımız için spfile veya pasword file üzerinde vir değişiklik yapmamıza gerek yok, sadece open RESETLOGS ile açmamız yeterli olacaktır.

Sadece DB_NAME’ i değiştirmek istersenizde

nid TARGET=sys/oracle@ktest DBNAME=KAMIL SETNAME=YES komutunu çalıştırmamız yeterli olacaktır. BU komutta dbid’ ye dokunmadan sadece name’ I değiştirecektir. Diğer adımlar yukarıdakiler ile aynı.

Bu işleme aslında çok sık olmasa da rman’ le create ettiğimiz yeni database’ imizi başka bir projede PROD olarak kullanmamız gerektiğinde veya kullanılan bir database farklı bir projede kullanılacaksa ona uygun bir name verilmek istendiğinde kullanılabilirsiniz.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Sisteme Connect Olan – Olamayan Kullanıcıları Tespit Etme

2011-01-22T00:02:00.000+02:00

Database’ deki kullanıcı sayısı fazla olan şirketler de bir süre sonra şöyle bir problem ortaya çıkıyor. İşe başlayan personele bir database accountu açılıyor. Sonra zaman içerisinde kimi personel ayrılıyor, kimisi yeni işe başlıyor derken ipin ucu bir noktada kaçabiliyor dolayısıyla işten ayrılmış olan personelin accountu sistemde açık olarak kalabiliyor. Buda aslında sisteminiz için bir güvenlik açığı oluşturuyor. Peki bunu nasıl giderebiliriz? Birebir çözümü olmasa da (en azından ben öyle düşünüyorum) şöyle bir tespitte bulunabiliriz. Database’ e connect olan kullanıcıları sisteme giriş yaptığı anda tespit edip, bizim istemiş olduğumuz bazı bilgileri bir tabloya yazdırıp sonrasında sistemdeki tüm kullanıcılar ile karşılaştırıp baktığımız zaman aralığında sisteme hiç giriş yapmamış olan kullanıcıları bulabiliriz. Tabi bu kullanıcıları hemen drop etmek çok akıllıca olmayabilir, burada şu yapılabilir bu kullanıcıların accountları locklanıp en azından araştırmak için zaman kazanılabilir. Şimdi bunun için neler yapmamız gerektiğine bakalım;

Önce v$sessionın tüm kolonlarını içeren bir tablo create edip, trigger da bunu kullanacğım. Aslında bu iş için v$session tablosundaki tüm kolonlara ihtiyacımız yok, siz isterseniz insert ve create table scriptini özelliştirip nesnelerinizi kolon bazında tanımlayıp create edebilirsiniz.

-- tablomuzu create edelim ;

create table kamil.logon_user as select * from v$session where 0=1

-- triggerımızı create edelim ;

create or replace trigger

kamil.logon_user_control

AFTER LOGON ON DATABASE

BEGIN

insert into kamil.logon_user select * from v$session ;

END;

Şimdi tablomuzu kontrol edelim, yeni gelen sessionlara ait tüm bilgileri bizim tablomuzada insert ediyor olması gerekiyor.

select count(*) from kamil.logon_user ;

COUNT(*)

----------

1078

1 row selected

Evet tablo doluyor, problem yok.

Şimdi yaptığımız işlemleri geri alalım. Temizlik zamanı;

drop trigger kamil.logon_user_control ;

Trigger dropped

drop table kamil.logon_user ;

Table dropped

Umarım işinize yarar zaman zaman bu tarz bilgileri kimi uygulama sahipleri isteyebiliyor. Aslında dba’ ler olarak kimi noktalarda bizim de işimize yarıyor.

Kamil TÜRKYILMAZ