CETURK » Oracle

Oracle & High Availability -2 [Video]

Mehmet ACA — Mon, 12 Sep 2011 12:07:07 +0000

CETURK Azerbaycan Oracle Konferansı‘nda Teymur Hacıyev’in “Oracle & High Availability” konulu sunumunun 2. bölümü:

Sunumun 1. bölümü için tıklayınız.

Oracle & High availability

Oracle veritabanı yüksek kullanılabilirlik (High Availability) özelliklerini kapsamlı bir şekilde sunan, sektörde benzersiz bir üründür. Real Application Clusters (RAC), Data Guard, Automatic Storage Management (ASM), Flashback, Recovery Manager (RMAN), Online Reorganization, Edition-based Redefinition gibi yüksek kullanılabilirlik özelliklerini barındırır. Bu özellikler ile entegre bir şekilde çalışabilen Oracle Secure Backup ve Oracle GoldenGate gibi tamamlayıcı ürünler, planlı ve plansız kesintileri azaltacak en iyi çözümü sunmaktadır. Bu seminerde yüksek kullanılabilirlik hakkında bilgi sahibi olacağız.

Oracle & High availability (Azerice)

Oracle verilənlər bazası yüksək mövcudluq (High Availability) xüsusiyyətlərini əhatəli bir şəkildə təqdim edən, sektorda bənzərsiz bir məhsuldur. Real Application Clusters (Rac), Data Guard, Automatic Storage Management (ASM), Flashback, Recovery Manager (RMAN), Qonaqlar Reorganization, Edition-based Redefinition kimi yüksək mövcudluq xüsusiyyətlərini saxlayır. Bu xüsusiyyətlər ilə inteqrasiya bir şəkildə işləyə bilən Oracle Secure Backup və Oracle GoldenGate kimi tamamlayıcı məhsullar, planlı və plansız kəsilməyə azaldacaq ən yaxşı həlli təqdim etməkdədir. Bu seminarda yüksək mövcudluq haqqında məlumat sahibi olacağıq.

Oracle & High Availability -1 [Video]

Mehmet ACA — Mon, 12 Sep 2011 10:23:13 +0000

CETURK Azerbaycan Oracle Konferansı‘nda Teymur Hacıyev’in “Oracle & High Availability” konulu sunumunun 1. bölümü:

Oracle & High availability

Ramin Orucov – Career path to become Oracle Developer Video

Mehmet ACA — Wed, 03 Aug 2011 15:11:25 +0000

1. Bölüm

2. Bölüm

Oracle yazılımcı nasıl olunur? Oracle yazılımcının bilmesi gereken konular hangilerdir? Oracle SQL ve PL/SQL sertifikaları hangilerdir? Bu sertifikaları almak için neleri bilmek ve hangi sınavları geçmek lazım?

Azerice :
Oracle proqramçı necə olmaq olar? Oracle proqramçı nələri bilməlidir? Oracle SQL və PL/SQL sertifikatları hansılardır? Bu sertifikatları almaq üçün nələri bilmək və hansı imtahanları keçmək lazımdır?

Azerbaycan Oracle Konferansı Gerçekleştirildi

Mehmet ACA — Tue, 10 May 2011 08:29:29 +0000

7 Mayıs 2011 tarihinde Azerbaycan Oracle Konferansı’nı Gəncliyə Yardım Fondu‘nda gerçekleştirdik. Bu konferans CETURK’un Yurt dışındaki organizasyonlarının ilkiydi.
Konferansta Talip Hakan Öztürk “Oracle Database Architecture” ve “Oracle Disaster Recovery ” sunumları, Ramin Orucov “Career path to become Oracle Developer” sunumu, Teymur Hacıyev “Oracle & High availability” sunumu yaptı.
Kamran Agayev rahatsızlığı nedeniyle planlanan “RMAN (Backup and Recovery)” sunumunu gerçekleştiremedi.

Koneransa çok sayıda Türk ve Azeri öğrenci ve sektörde çalışan kişi katıldı.

Konferansta bize ev sahipliği yapan Gəncliyə Yardım Fondu‘na, gönüllü konuşmacı olarak katılan Talip Hakan Öztürk, Ramin Orucov, Teymur Hacıyev ve Kamran Agayev’e, konferansın organizasyonunda çok büyük emeği olan Gökhan Uysal‘a ayrıca konferans boyunca bize yardımcı olan Onur Kayhan ve Mehmet Kılıç‘a , ilgilenen ve etkinliğe katılan herkese çok teşekkür ederiz.

Konferansta yaptığımız çekiliş ile aşağıda ismi verilen arkadaşlar kitap kazandı.

Ensar Erdoğan
Gökhan Uysal
Hasan Pehlivanlar
Serhat Koca
Murad İmanbəyli
Selçuk Karabulut

Konferansı sitesinde duyurup bize destek olan aşağıda ismi- site ismi geçen tüm arkadaşlara da çok teşekkür ederiz. Bu arkadaşlardan yaptığımız çekiliş ile 10 kişi kitap kazandı. Kazanan arkadaşlar kırmızı renk ile belirtilmiştir.

CETURK olarak benzer organizasyonları yurt dışında yapmaya devam etmeyi hedefliyoruz. Bizi destekleyen herkese teşekkürler.

Türk Oracle Kullanıcıları TROUG Gününde Buluşuyor!

Mehmet Yüngül — Mon, 18 Apr 2011 09:04:28 +0000

TROUG ( Türk Oracle Kullanıcıları Grubu) 21 Nisan’da Türk Oracle kullanıcılarını “TROUG Day” ‘de buluşturuyor. Katılımın ücretsiz olacağı bu etkinlikte, konusunun uzmanlarından teknik sunumlar ve katılımcıların sorularıyla yönlendireceği “TROUG Panel” oturumu yer alacak.

Program
09:00-10:00 Açılış & Thinking About Joins: Jonathan Lewis
10:00-10:50 20+ Soruda Exadata: Ferhat Şengönül & Hüsnü Şensoy
10:50-11:00 Kahve Molası
11:00-12:00 Enterprise Manager 11g Grid Control: Gökhan Atıl
12:00-13:00 Öğle Yemeği Molası
13:00-14:00 Oracle Dataguard: Nasıl Daha Efektif Kullanırız? Emre Baransel & Ogan Özdoğan
14:00-14:50 ASM Best Practices: Orhan Bıyıklıoğlu
14:50-15:00 Kahve Molası
15:00-16:00 11g Backup & RecoveryNew Features: Kamran Agayev & Zekeriya Beşiroğlu
16:00-16:50 PL/SQL ile Web 2.0: JavaScript ve Javacılar nasıl kıskançlıktan çatlatılır? Yalım K. Gerger
16:50-17:00 Kahve Molası
17:00-18:00 TROUG Panel: H.Tonguç Yılmaz, Kamran Agayev,O. Yasin Saygılı, Talip Hakan Öztürk, Gökhan Atıl, Emre Baransel

Etkinlik Yer ve Zamanı

Tarih: 21 Nisan Perşembe
Yer: Bahçeşehir Üniversitesi /Beşiktaş Kampüsü – İstanbul

Detaylı Bilgi : http://www.troug.org/?p=406
Ücretsiz kaydolmak için: http://apex.oracle.com/pls/apex/f?p=38448:2

Rman Catalog Db Kullanarak Kartuşa Alınan Yedeği Farklı Bir Sunucuya Dönme

kamil.turkyilmaz — Sat, 26 Mar 2011 08:00:08 +0000

Belli dönemlerde prod database’ lerinden alınan backupları farklı sunucular üzerine dönme testleri yapma zorunluluğumuz var. Bu testlerden birinde yaptığım işleme ait detayları aşağıda anlatmaya çalıştım.

Rman ile bir database’ i farklı bir sunucu üzerine taşımak başlıklı yazımda rman backup diske alındığında nasıl restore edileceğinden bahsetmiştik. Orada catalog database’ ini orada aslında kullanmamıştık çünkü alınan rman backupı, restore yapılacak sunucu üzerinde rman’ in istemiş olduğu path’lere kopyalamıştık dolayısıyla orada işimiz daha kolaydı.

Burada ise catalog database’ ini kullanarak (rutin işleyişe birebir örnek oluşturması açısından) kartuşa alınan bir backupı hiçbir kopyalama işlemi yapmadan nasıl başka bir ortama taşıyacağımızdan bahsetmek istiyorum. Yine burda da bir takım öngörülerimiz var. Öncelikle, pathlerimiz burda da farklı olarak kabul ediyoruz. (eğer pathler restore yapılacak sunucu ile birebir aynı ise, aşağıdaki scriplerdeki )Sonrasında yapacağımız işlemlerle ilgili olarak adım adım anlatamaya çalışayım ;

Backupı dönülecek olan sunucu üzerinden rman catalog database’ i ile database’ in backupı kartuşa alınır.

run {

allocate channel 'dev_0' type 'sbt_tape'

parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=prdtest,OB2BARLIST=Betasetcms2_PRDTEST)';

allocate channel 'dev_1' type 'sbt_tape'

parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=prdtest,OB2BARLIST=Betasetcms2_PRDTEST)';

allocate channel 'dev_2' type 'sbt_tape'

parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=prdtest,OB2BARLIST=Betasetcms2_PRDTEST)';

allocate channel 'dev_3' type 'sbt_tape'

parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=prdtest,OB2BARLIST=Betasetcms2_PRDTEST)';

backup incremental level

format 'Betasetcms2_PRDTEST<%t:%p>.dbf'

restore database;

sql 'alter system archive log current';

backup

filesperset 1

format 'Betasetcms2_PRDTEST<%t:%p>.dbf'

archivelog like '/data2/arch/%';

}

Datafile’ leri farklı pathlere restore edeceğimiz için aşağıdaki bilgileri mutlaka biliyor olmamız gerekiyor. Sonrasında file# numarasına göre yeni path’ lere set edeceğiz.

Database’ deki datafile’ lerin listesinide alıyoruz.

SQL> select name from v$datafile;

FILE# NAME

1 /data2/prdtest/system01.dbf

2 /data2/prdtest/undotbs01.dbf

3 /data2/prdtest/sysaux01.dbf

4 /data2/prdtest/users01.dbf

5 /data2/prdtest/example01.dbf

6 /data2/prdtest/kamil_deneme1_01.dbf

7 /data2/prdtest/kamil_deneme1_02.dbf

8 /data2/prdtest/kamil_deneme2_01.dbf

9 /data2/prdtest/kamil_deneme2_02.dbf

Redologlar hakkında aşağıdaki bilgileri alıyoruz.

Select * from v$logfile;

GROUP# STATUS TYPE MEMBER

3 ONLINE /data2/prdtest/redo03.log NO

2 ONLINE /data2/prdtest/redo02.log NO

1 ONLINE /data2/prdtest/redo01.log NO

Ayrıca bu database’ e ait dbid bilgisinide öncesinde bilmemiz gerekiyor. Kullanmakta olduğunuz tüm database’ lerin dbid’ lerini saklamanızda fayda var. Bu değer sonradan değişmeyen ve her database için unique olan bir değerdir.

SQL> select dbid from v$database ;

DBID

———-

165917862

Bundan sonraki adımda aslında şunu düşünüyoruz, bu database herhangi bir problemden dolayı down oldu ve temin edilen farklı bir sunucuya data kaybı olmadan restore etmeniz gerekiyor. Şimdi almış olduğumuz backupı başka bir sunucu üzerine restore etmeye çalışalım.

Restore yapılacak server üzerine sadece oracle software kurulumu yapıyoruz.

Pfile, initfile, pwd, tns, sqlnet ora gibi (parametre) dosyaları yeni sunucumuz üzerine üzerine kopyalıyoruz. (veya elimizde backupları yoksa yenilerini create ediyoruz. Zaman zaman prod ortamlarından bu tarz kritik file’ lerin backupının alınması ciddi zaman kazançları sağlıyor)

Parametre dosyaları restore yapılacak olan servera kopyalandıkdan sonra içerisinde gerekli değişiklikleri yapmamız gerekiyor. Örneğin memory parametreleri yeni sunucuya göre set edilir veya backup alınan sunucu ile restore yapılacak olan sunucunun path’ leri farklı olabileceğinden buradaki controlfile parametresinin restore yapılacak olan sunucuda nerde olması gerekiyor ise ilgili path bilgisi buraya girilir.

Örneğin bizim örneğimizde backup alınan sunucudaki control file parametresi ;

*.control_files=’/data2/prdtest/control01.ctl’,'/data2/prdtest/control02.ctl’,'/data2/prdtest/control03.ctl’

Restore yapılacak sunucudaki olması gereken path ise (burada böyle bir path olmadığından dolayı) ;

*.control_files=’/data/oracle/oradata/prdtest/control01.ctl’,'/data/oracle/oradata/prdtest/control02.ctl’,'/data/oracle/oradata/prdtest/control03.ctl’

Sonra yeni sunucumuzdaki database sys olarak bağlanıp nomount modda database’ i start ediyoruz.

oracle@betasetapp2:/data/oracle/product/10.1.0/db:>sqlplus “/as sysdba”

SQL*Plus: Release 10.1.0.5.0 – Production on Mon Nov 29 09:22:50 2010

Connected to:

Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 – 64bit Production

With the Partitioning, OLAP and Data Mining options

SQL> startup nomount

ORACLE instance started.

Total System Global Area 419430400 bytes

Fixed Size 1330696 bytes

Variable Size 122401272 bytes

Database Buffers 293601280 bytes

Redo Buffers 2097152 bytes

Database’ i nomount moda aldıkdan sonra yine bu sunucu üzerinden önce rman’e sonra catalog database’ ine bağlanıyoruz.

oracle@betasetapp2:/data/oracle:>rman target /

Recovery Manager: Release 10.1.0.5.0 – 64bit Production

connected to target database: prdtest (not mounted)

RMAN> connect catalog RMAN_PRDTEST/r10011002@RMAN

connected to recovery catalog database

RMAN>

Catalog database’ ine bağlanmak için kullandığımız user bizim backup aldığımız veritabanını catalog database’ ine register ederken kullanmış olduğumuz user’ ı ifade ediyor. @RMAN ise rman catalog database’ inin tns kaydıdır.

Rman ile restore işlemine artık başlıyabiliriz, öncelikle işlem yapacağımız database’ in dbid bilgisini set ediyoruz.

RMAN> set dbid=165917862

executing command: SET DBID

database name is “PRDTEST” and DBID is 165917862

İlk olarak controlfile’ i dönmemiz gerekiyor.

RMAN> run {

2> allocate channel 'dev_0' type 'sbt_tape';

3> allocate channel 'dev_1' type 'sbt_tape';

4> allocate channel 'dev_2' type 'sbt_tape';

5> allocate channel 'dev_3' type 'sbt_tape';

6> restore controlfile;

7> }

released channel: ORA_DISK_1

allocated channel: dev_0

channel dev_0: sid=159 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=157 devtype=SBT_TAPE

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

allocated channel: dev_2

channel dev_2: sid=160 devtype=SBT_TAPE

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

allocated channel: dev_3

channel dev_3: sid=161 devtype=SBT_TAPE

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

Starting restore at 30-NOV-10

channel dev_0: starting datafile backupset restore

channel dev_0: restoring controlfile

[Normal] From: OB2BAR_Oracle8@betasetapp2 “PRDTEST” Time: 11/30/10 10:47:22

Starting OB2BAR Restore: betasetcms2:c-165917862-20101125-02 “Oracle8″

[Normal] From: OB2BAR_Oracle8@betasetapp2 “PRDTEST” Time: 11/30/10 10:47:24

Completed OB2BAR Restore: betasetcms2:c-165917862-20101125-02 “Oracle8″

channel dev_0: restored backup piece 1

piece handle=c-165917862-20101125-02 tag=TAG20101125T141314

channel dev_0: restore complete

output filename=/data/oracle/oradata/prdtest/control01.ctl

output filename=/data/oracle/oradata/prdtest/control02.ctl

output filename=/data/oracle/oradata/prdtest/control03.ctl

Finished restore at 30-NOV-10

released channel: dev_0

released channel: dev_1

released channel: dev_2

released channel: dev_3

RMAN>

Ben testimde, channel allocate ederken, rman’ in backup alırken allocate ettiği kadar channel’ lar allocate ettim, istenirse daha az veya daha fazla channel allocate edilebilir.

Örneğin;

RMAN> run {

2> allocate channel 'dev_0' type 'sbt_tape';

3> allocate channel 'dev_1' type 'sbt_tape';

4> allocate channel 'dev_2' type 'sbt_tape';

5> allocate channel 'dev_3' type 'sbt_tape';

6> allocate channel 'dev_4' type 'sbt_tape';

7> allocate channel 'dev_5' type 'sbt_tape';

8> allocate channel 'dev_6' type 'sbt_tape';

9> restore controlfile;

10> }

allocated channel: dev_0

channel dev_0: sid=159 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=157 devtype=SBT_TAPE

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

allocated channel: dev_2

channel dev_2: sid=160 devtype=SBT_TAPE

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

allocated channel: dev_3

channel dev_3: sid=161 devtype=SBT_TAPE

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

allocated channel: dev_4

channel dev_4: sid=156 devtype=SBT_TAPE

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

allocated channel: dev_5

channel dev_5: sid=155 devtype=SBT_TAPE

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

allocated channel: dev_6

channel dev_6: sid=154 devtype=SBT_TAPE

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

Starting restore at 30-NOV-10

…………………….

RMAN> run {
2> allocate channel 'dev_0' type 'sbt_tape';
3> restore controlfile;
4> }

allocated channel: dev_0

channel dev_0: sid=159 devtype=SBT_TAPE

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

Starting restore at 30-NOV-10

…………………….

Controlfile’ lerimizi döndükden sonra database’ imizi artık mound moda çekebiliriz.

SQL> alter database mount;

database mounted.

Rman Catalog Database’ i Kullanarak, Kartuşa Alınan Backupı Farklı bir Sunucuya Dönme -2 ile devam ediyoruz.

Sıra datafile’ leri restore/recover etmeye geldi ;

Pathler backupı alınan database’ deki pathler ile aynı olmadığından öncelikle bu değişikliği yapmamız gerekiyor.

Aşağıdaki script ile datafile’ leri bizim belirttiğimiz yeni lokasyonlarına restore ediyoruz.

Bundan sonraki kısım aslında iki aşamalı olarak düşünebiliriz, birinci aşamamız restore, sonraki aşamamız ise recover aşamasıdır. Datafile’ ler restore edilirken farklı seuence numaralarına sahip olarak restore edilir, yani db içerisindeki tün datafile’ lerin sequence değerleri biririnden farklılık gösterecektir. Bu farklılığı ortadan kaldırıp max sequence değeri altında datafile’ lerin hepsini aynı noktaya çeken işlem ise recover aşamasıdır. Bu konuyla ilgili olarak aşağıdaki iki script ve arasındaki fark aslında konuyu açıklamak için yeterli diye düşünüyorum.

Aşağıdaki scripti çalıştırdığımda restore işleminin en sonunda “RMAN-06054: media recovery requesting unknown log: thread 1 seq 686 lowscn 2858652“ böyle bir hata verdi. Almış olduğumuz backup full backupdı ve backuplanan son archive log numarası 684 idi. Recover işlemini hangi sequence değerine kadar yapılmasını belirtmediğim için aşağıdaki hatayı aldım.

RMAN> run {
2> allocate channel 'dev_0' type 'sbt_tape';
3> allocate channel 'dev_1' type 'sbt_tape';
4> allocate channel 'dev_2' type 'sbt_tape';
5> allocate channel 'dev_3' type 'sbt_tape';
6> set NEWNAME for datafile 1 to '/data/oracle/oradata/prdtest/system01.dbf';
7> set NEWNAME for datafile 2 to '/data/oracle/oradata/prdtest/undotbs01.dbf';
8> set NEWNAME for datafile 3 to '/data/oracle/oradata/prdtest/sysaux01.dbf';
9> set NEWNAME for datafile 4 to '/data/oracle/oradata/prdtest/users01.dbf';
10> set NEWNAME for datafile 5 to '/data/oracle/oradata/prdtest/example01.dbf';
11> set NEWNAME for datafile 6 to '/data/oracle/oradata/prdtest/kamil_deneme1_01.dbf';
12> set NEWNAME for datafile 7 to '/data/oracle/oradata/prdtest/kamil_deneme1_02.dbf';
13> set NEWNAME for datafile 8 to '/data/oracle/oradata/prdtest/kamil_deneme2_01.dbf';
14> set NEWNAME for datafile 9 to '/data/oracle/oradata/prdtest/kamil_deneme2_02.dbf';
15> restore database;
16> switch datafile all;
17> recover database;
18> }

allocated channel: dev_0

channel dev_0: sid=161 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=160 devtype=SBT_TAPE

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

allocated channel: dev_2

channel dev_2: sid=159 devtype=SBT_TAPE

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

allocated channel: dev_3

channel dev_3: sid=156 devtype=SBT_TAPE

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

executing command: SET NEWNAME

Starting restore at 01-DEC-10

channel dev_0: starting datafile backupset restore

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

restoring datafile 00005 to /data/oracle/oradata/prdtest/example01.dbf

restoring datafile 00006 to /data/oracle/oradata/prdtest/kamil_deneme1_01.dbf

restoring datafile 00007 to /data/oracle/oradata/prdtest/kamil_deneme1_02.dbf

channel dev_1: starting datafile backupset restore

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

restoring datafile 00002 to /data/oracle/oradata/prdtest/undotbs01.dbf

restoring datafile 00003 to /data/oracle/oradata/prdtest/sysaux01.dbf

restoring datafile 00004 to /data/oracle/oradata/prdtest/users01.dbf

channel dev_2: starting datafile backupset restore

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

restoring datafile 00001 to /data/oracle/oradata/prdtest/system01.dbf

restoring datafile 00008 to /data/oracle/oradata/prdtest/kamil_deneme2_01.dbf

restoring datafile 00009 to /data/oracle/oradata/prdtest/kamil_deneme2_02.dbf

[Normal] From: OB2BAR_Oracle8@betasetapp2 “” Time: 12/01/10 09:55:10

Starting OB2BAR Restore:

…

Finished restore at 01-DEC-10

Starting recover at 01-DEC-10

starting media recovery

channel dev_0: starting archive log restore to default destination

channel dev_0: restoring archive log

archive log thread=1 sequence=685

[Normal] From: OB2BAR_Oracle8@betasetapp2 “” Time: 12/01/10 09:57:35

Starting OB2BAR Restore: …

…

channel dev_0: restore complete

archive log filename=/data/oracle/flash_recovery_area/PRDTEST/archivelog/2010_12_01/o1_mf_1_685_6hczzhn4_.arc thread=1 sequence=685

channel default: deleting archive log(s)

archive log filename=/data/oracle/flash_recovery_area/PRDTEST/archivelog/2010_12_01/o1_mf_1_685_6hczzhn4_.arc recid=681 stamp=736595856

unable to find archive log

archive log thread=1 sequence=686

released channel: dev_0

released channel: dev_1

released channel: dev_2

released channel: dev_3

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

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

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

RMAN-03002: failure of recover command at 12/01/2010 09:57:43

RMAN-06054: media recovery requesting unknown log: thread 1 seq 686 lowscn 2858652

Until seq vererek çalıştırdığım zaman ;

RMAN> run {

2> allocate channel 'dev_0' type 'sbt_tape';

3> allocate channel 'dev_1' type 'sbt_tape';

4> allocate channel 'dev_2' type 'sbt_tape';

5> allocate channel 'dev_3' type 'sbt_tape';

6> set NEWNAME for datafile 1 to '/data/oracle/oradata/prdtest/system01.dbf';

7> set NEWNAME for datafile 2 to '/data/oracle/oradata/prdtest/undotbs01.dbf';

8> set NEWNAME for datafile 3 to '/data/oracle/oradata/prdtest/sysaux01.dbf';

9> set NEWNAME for datafile 4 to '/data/oracle/oradata/prdtest/users01.dbf';

10> set NEWNAME for datafile 5 to '/data/oracle/oradata/prdtest/example01.dbf';

11> set NEWNAME for datafile 6 to '/data/oracle/oradata/prdtest/kamil_deneme1_01.dbf';

12> set NEWNAME for datafile 7 to '/data/oracle/oradata/prdtest/kamil_deneme1_02.dbf';

13> set NEWNAME for datafile 8 to '/data/oracle/oradata/prdtest/kamil_deneme2_01.dbf';

14> set NEWNAME for datafile 9 to '/data/oracle/oradata/prdtest/kamil_deneme2_02.dbf';

15> set until sequence 686 thread 1;

16> restore database;

17> switch datafile all;

18> recover database;

19> }

allocated channel: dev_0

channel dev_0: sid=161 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=160 devtype=SBT_TAPE

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

allocated channel: dev_2

channel dev_2: sid=159 devtype=SBT_TAPE

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

allocated channel: dev_3

channel dev_3: sid=156 devtype=SBT_TAPE

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

executing command: SET NEWNAME

executing command: SET until clause

Starting restore at 01-DEC-10

channel dev_0: starting datafile backupset restore

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

restoring datafile 00005 to /data/oracle/oradata/prdtest/example01.dbf

restoring datafile 00006 to /data/oracle/oradata/prdtest/kamil_deneme1_01.dbf

restoring datafile 00007 to /data/oracle/oradata/prdtest/kamil_deneme1_02.dbf

channel dev_1: starting datafile backupset restore

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

restoring datafile 00002 to /data/oracle/oradata/prdtest/undotbs01.dbf

restoring datafile 00003 to /data/oracle/oradata/prdtest/sysaux01.dbf

restoring datafile 00004 to /data/oracle/oradata/prdtest/users01.dbf

channel dev_2: starting datafile backupset restore

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

restoring datafile 00001 to /data/oracle/oradata/prdtest/system01.dbf

restoring datafile 00008 to /data/oracle/oradata/prdtest/kamil_deneme2_01.dbf

restoring datafile 00009 to /data/oracle/oradata/prdtest/kamil_deneme2_02.dbf

[Normal] From: OB2BAR_Oracle8@betasetapp2 “” Time: 12/01/10 10:06:54

Starting OB2BAR Restore: …

…

media recovery complete

Finished recover at 01-DEC-10

released channel: dev_0

released channel: dev_1

released channel: dev_2

released channel: dev_3

RMAN>

Redologların path’ ini düzeltiyoruz.

Recover işlemi başarı ile bittikden redologların yeni pathlerini set etmemiz gerekiyor. Yeni pathleri vermeden açmaya çalışırsak aşağıdaki hatayı alırız.

SQL> alter database open resetlogs;

alter database open resetlogs

ERROR at line 1:

ORA-00344: unable to re-create online log ‘/data2/prdtest/redo01.log’

ORA-27040: file create error, unable to create file

IBM AIX RISC System/6000 Error: 2: No such file or directory

Redologların pathlerini düzeltmek için ;

SQL> alter database rename file '/data2/prdtest/redo03.log' to '/data/oracle/oradata/prdtest/redo03.log';

Database altered.

SQL> alter database rename file '/data2/prdtest/redo02.log' to '/data/oracle/oradata/prdtest/redo02.log';

Database altered.

SQL> alter database rename file '/data2/prdtest/redo01.log' to '/data/oracle/oradata/prdtest/redo01.log';

Database altered.

Kontol etmek için ;

SQL> select member from v$logfile ;

MEMBER

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

/data/oracle/oradata/prdtest/redo03.log

/data/oracle/oradata/prdtest/redo02.log

/data/oracle/oradata/prdtest/redo01.log

Sıra en son ve zevkli kısmına geldi , database’ i açıyoruz

SQL> alter database open resetlogs ;

Database altered.

Kartuşa alınan bir database’ in backupını, farklı bir sunucu üzerine farklı pathler de olacak şekilde restore etmiş olduk. Backup – restore testleri bir dba için oldukça önemli konular diye düşünüyorum. Zira esas önemli olan herhangi bir disaster durumunda paniklemeden soğukkanlılıkla ve benzer senaryoları daha önceden test etmiş olmanın rahatlığı içerisinde soruna çözüm üretmekde yatıyor. Umarım faydalı olur.

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Oracle View Yaratmak ve Değiştirmek / Performans

Ogan Ozdogan — Fri, 25 Feb 2011 16:03:57 +0000

Merhabalar,

Öncelikle bir view (bundan böyle görüntü olarak adlandıralım) tanımını yapmakla başlayalım. Bir görüntü, tablo veya başka bir görüntüdeki verinin yeniden gösterilmesi ve düzenlenmesi anlamına gelen objedir. Bir görüntünün referans olduğu objenin adı ise baz tablodur. Görüntülerle ilgili bilinmesi gereken belki de en önemli nokta; görüntüler veri tutmamaktadır. Yalnız içeriğine ait olan sorgunun data dictionary’de tutulmasıdır. Görüntüler, ana objelere refere olan bir işaretleyicidir. Herhangi bir boyutu bulunmamaktadır çünkü içerisinde veri tutmuyordur. Hazır yeri gelmişken, içerisinde veri barındırabilen ve sürekli olarak güncellenebilen görüntü türüne “materialized view” denmektedir. Görüntüler ayrıca bir veri görüntülenebilirliği koruması olarakta kullanabilirsiniz. Örnek; tabloda 10 tane sütun olduğunu düşünün. Bunlardan 2 tanesini tanımlayacağınız gruptaki insanların görmesini istemiyorsunuz. Yapmanız gereken bir görüntü hazırlamak ve kalan 8 sütunu bu görüntünün içeriği olarak işaretlemek.

Oracle komutları arasından “CREATE VIEW” komutu istenilen görüntünün oluşturulmasını sağlar. Yaratılacak olan bu görüntü birden fazla objeye refere ediyor olabilir. Bir örnekle devam edelim;

SQL> create table yonetim
2 (
3 isim varchar2(30) not null,
4 soyisim varchar2(60) not null,
5 kullanici_kodu number(5) not null
6 );

Table created.

SQL> CREATE VIEW ogan_deneme AS
2 SELECT isim, soyisim, kullanici_kodu
3 FROM yonetim
4 WHERE kullanici_kodu IN (100,200,300);

View created.

SQL> DESCRIBE ogan_deneme;
Name Null? Type
----------------------------------------- -------- ----------------------------
ISIM NOT NULL VARCHAR2(30)
SOYISIM NOT NULL VARCHAR2(60)
KULLANICI_KODU NOT NULL NUMBER(5)

Yukarıdaki komut basit bir görüntü yaratma komutudur ve yonetim isimli objeden, kullanici_kodu 100,200 ve 300 olanların; isim, soyisim ve kullanici_kodu bilgilerini almaktadır. Başka bir örnek;

SQL> DESCRIBE yonetim;
Name Null? Type
----------------------------------------- -------- ----------------------------
ISIM NOT NULL VARCHAR2(30)
SOYISIM NOT NULL VARCHAR2(60)
KULLANICI_KODU NOT NULL NUMBER(5)

SQL> CREATE OR REPLACE VIEW ogan_deneme AS
2 SELECT isim||' '||soyisim "AD-SOYAD"
3 FROM yonetim
4 WHERE kullanici_kodu IN (100,200,300);

View created.

SQL> DESCRIBE ogan_deneme;
Name Null? Type
----------------------------------------- -------- ----------------------------
AD-SOYAD VARCHAR2(91)

Yukarıdaki örnekte isim ve soyisim bilgilerini bir adet boşluk ile birleştirmek koşuluyla “AD-SOYAD” olarak tanımladık ve yine kullanici_kodu 100,200 ve 300 içerisinde olan kişileri istediğimizi belirttik. Burada dikkat edilmesi gereken husus Oracle’ın “AD-SOYAD” sütununu 91 byte olarak tanımlamasıdır. ISIM 30, SOYISIM 60 ve bir ara karaterle birlikte 91 olarak tanımlama gerçekleştirilmiştir. Bunu bir de NUMBER için nasıl yapıtığına bakalım;

SQL> ALTER TABLE yonetim ADD kimlik number(7,1);

Table altered.

SQL> ALTER TABLE yonetim ADD departman_id number(3);

Table altered.

SQL> DESCRIBE yonetim;
Name Null? Type
----------------------------------------- -------- ----------------------------
ISIM NOT NULL VARCHAR2(30)
SOYISIM NOT NULL VARCHAR2(60)
KULLANICI_KODU NOT NULL NUMBER(5)
KIMLIK NUMBER(7,1)
DEPARTMAN_ID NUMBER(3)

SQL> CREATE OR REPLACE VIEW ogan_deneme AS
2 SELECT isim, soyisim, kullanici_kodu * departman_id "Calisan Kodu"
3 FROM yonetim;

View created.

SQL> DESCRIBE ogan_deneme;
Name Null? Type
----------------------------------------- -------- ----------------------------
ISIM NOT NULL VARCHAR2(30)
SOYISIM NOT NULL VARCHAR2(60)
Calisan Kodu NUMBER

NUMBER bir alanı birleştirdiğimi zaman “precision” ve “scale” alanları birleştirildi ve yalnız NUMBER olarak gösterilmeye başlandı.

Bir görüntüyü “SELECT *” komutu ile yarattıktan sonra eğer tablo üzerinde yeni bir sütun eklediyseniz görüntüyüde yeniden yaratmanız veya içeriğini güncellemeniz gerekmektedir. Örnek;

SQL> CREATE OR REPLACE VIEW ogan_deneme AS
2 SELECT * FROM yonetim;

View created.

SQL> ALTER TABLE yonetim ADD maas number(10);

Table altered.

SQL> DESCRIBE ogan_deneme;
Name Null? Type
----------------------------------------- -------- ----------------------------
ISIM NOT NULL VARCHAR2(30)
SOYISIM NOT NULL VARCHAR2(60)
KULLANICI_KODU NOT NULL NUMBER(5)
KIMLIK NUMBER(7,1)
DEPARTMAN_ID NUMBER(3)

SQL> SELECT dbms_metadata.get_ddl('VIEW','OGAN_DENEME','SYSTEM') OUTPUT
2 FROM DUAL;

OUTPUT
-------------------------------
CREATE OR REPLACE FORCE VIEW "SYSTEM"."OGAN_DENEME" ("ISIM", "SOYISIM", "KULLANICI_KODU", "KIMLIK", "DEPARTMAN_ID") AS
SELECT "ISIM","SOYISIM","KULLANICI_KODU","KIMLIK","DEPARTMAN_ID" FROM yonetim

yonetim tablosuna maas sütununu eklememe rağmen daha önceden tanımladığım görüntü değişmedi. Bir üstteki sorgundan da anlaşıldığı üzere “*” isteğimiz karşılanmış ancak data dictionary’de, o anki bütün sütunlar çözümlenerek yaratılmış. Buradaki sizi çelişkiye düşürebilecek nokta “select *” olarak tanımladım, neden sonradan yarattığım sütunları da görüntüde göremiyorum” olacaktır. İşte sebebi de budur.

Bir görüntüyü henüz veritabanında olmayan bir obje için yaratabilirsiniz. Bunu yapabilmek için kullanacağınız komut FORCE komutudur. Bir görüntü eğer hata alıyorsa bu o görüntünün yaratılamadığı anlamına gelmektedir. FORCE komutunun kullanımı için;

SQL> CREATE VIEW ogan_yeni AS
2 SELECT *
3 FROM olmayan_bir_tablo;
FROM olmayan_bir_tablo
*
ERROR at line 3:
ORA-00942: table or view does not exist

SQL> CREATE FORCE VIEW ogan_yeni AS
2 SELECT *
3 FROM olmayan_bir_tablo;

Warning: View created with compilation errors.

SQL> SHOW ERRORS VIEW ogan_yeni;
Errors for VIEW OGAN_YENI:

LINE/COL ERROR
-------- -----------------------------------------------------------------
0/0 ORA-00942: table or view does not exist

SQL> SELECT *
2 FROM ogan_yeni;
FROM ogan_yeni
*
ERROR at line 2:
ORA-04063: view "SYSTEM.OGAN_YENI" has errors

Şimdi de ilgili tabloyu yaratalım;

SQL> CREATE TABLE olmayan_bir_tablo AS
2 SELECT *
3 FROM yonetim;

Table created.

SQL> SELECT *
2 FROM ogan_yeni;

no rows selected

Az önce hata veren görüntü, şimdi sadece satır olmadığını gösteriyor. FORCE ile yarattığımız görüntüyü artık kullanabiliriz. Bir altsorgu (subquery) içerisinde FOR UPDATE kelimesini eğer view yaratırken kullanmaya kalkarsanız hata alırsınız.

Bir görüntüyü sadece okuma özelliği ile (read-only) de yaratabilirsiniz. Şu şekilde;

SQL> CREATE VIEW ogan_yeni
2 SELECT *
3 FROM yonetim
4 WITH READ ONLY;

View created.

Bu yaratılan görüntü üzerinden hiçbir DML operasyonu kabul edilmeyecektir.

BİR 11G ÖZELLİĞİ

Oracle 11g versiyonu görüntüler üzerinde constraint yaratabilmenizi sağlamaktadır. Görüntüler üzerindeki kısıtlar (constraint) uygulanmamaktadır veya zorlanmamaktadır. Bir kısıtı uygulamaya almak istiyorsanız baz tabloya gitmeniz gerekmektedir. Bu tipte kısıtlar yalnızca deklere edici tiptetir ve DISABLE NOVALIDATE olarak yaratılmak zorundadırlar. Bir görüntü üzerinde birincil, benzersiz ve referans anahtarları yaratabilirsiniz. Örnek;

SQL> CREATE VIEW ogan_kisit AS
2 (isim CONSTRAINT fk_isim REFERENCES kisiler DISABLE NOVALIDATE,
3 soyisim,
4 kullanici_kodu CONSTRAINT kullanici_kodu_benzer UNIQUE DISABLE NOVALIDATE,
5 AS
6 SELECT isim, soyisim, kullanici_kodu
7 FROM yonetim
8 WHERE kullanici_kod = 400;

View created.

OR REPLACE cümleciğini zaten varolan bir görüntünün içeriğini değiştirmekte veya olmayan bir görüntü yaratmakta kullanabiliyoruz. Bu komutu kullanarak görüntüyü düşürüp yeniden yaratmadan, yalnızca içeriğini değiştirerek ve görüntü üzerindeki bütün hakları da(grant) koruyarak göntüyü güncelleyebiliriz.

Bir tablo üzerinde yapısal bir değişiklik olduğu durumda (örneğin ALTER TABLE komutu ile bir sütunun tipini değiştirdiğimizi düşünün) görüntü geçersiz olacaktır. Eğer görüntüye erişim sağlanırsa görüntü yeniden düzenlecek (recompile) ve çalışır hale gecektir. Bu düzenleme işini biz de yapabiliyoruz;

SQL> ALTER VIEW ogan_deneme COMPILE;

Bir görütüyü kalıcı olarak veritabanından silmek isterseniz;

SQL> DROP VIEW ogan_deneme;

Bir görüntüyü sildiğimiz zaman data dictionary’den bütün bilgileri silinecek, üzerindeki bütün haklar kalkacak ve bu objeye bağlı olan diğer görüntüler de geçersiz kılınacaktır ve yeniden düzenlenmesi gerekecektir.

Bir görüntü kullanmanın bir diğer olumlu yanı ise görüntülerin arkasına kompleks birleşim koşullarını saklayabilmemiz. Bu şekilde görüntüyü kullanan kişinin ne derece kompleks bir erişim sağladığı size kalacaktır. Bununla birlikte size göre anlamlı fakat son kullanıcıya anlamsız gelen sütun isimlendirmelerini yeniden düzenleyebilir ve daha anlamlı isimlerle bir görüntü altnıda sunabilirsiniz.

Bir görüntü üzerinden DML uygulama şansına sahipsiniz ancak aşağıdaki koşulların görüntü için geçerli olmaması gerekmekte yani görüntünün içeriğinin içerisinde bulunmaması gerekmekte.

1) DISTINCT veya UNIQUE
2) GROUP BY
3) START WITH
4) CONNECT BY
5) ROWNUM
6) Bütün SET operatörleri (UNION, UNION ALL, INTERSECT, MINUS)
7) SELECT içerisinde bir altsorgunun varlığı

Bir görüntü üzerinden insert işlemi yaparken görüntü içerisindeki WHERE koşulları uygulanmadan insert işlemi yapılmaktadır. Örnek;

SQL> CREATE VIEW ogan_yeni AS
2 SELECT *
3 FROM yonetim
4 WHERE kullanici_kod > 99;

View created.

SQL> INSERT INTO ogan_yeni
2 VALUES('Ogan','Ozdogan',10);

1 row created.

Gördüğünüz gibi 10 numaralı bir kullanıcı kodunun girişine izin verildi. Bunun kontrol edilmesini istiyorsanız eğer WITH_CHECK_OPTION eklemeniz gerekiyor. Bu arada WITH_CHECK_OPTION ALL_CONSTRAINT görüntüsü içerisinde “V” tipinde gösterilmektedir. CHECK kısıtlarının da “C” olarak gösterildiğini hatırlayalım.

SQL> CREATE OR REPLACEVIEW ogan_yeni AS
2 SELECT *
3 FROM yonetim
4 WHERE kullanici_kod > 99;
5 WITH CHECK OPTION;

View created.

SQL> INSERT INTO ogan_yeni
2 VALUES('Ogan','Ozdogan',10);
INSERT INTO ogan_yeni
*
ERROR at line 1:
ORA-01402: view WITH CHECK OPTION where-clause violation

SQL> SELECT constraint_name, table_name
2 FROM user_constraints
3 WHERE constraint_type = 'V';

CONSTRAINT_NAME TABLE_NAME
------------------------------------------------------------
SYS_B000234 ogan_yeni

Son olarak dokümante edilmeyen bir konuya değinmek istiyorum. Görüntülerin performansı arttığı gibi bir efsane var. Bakalım gerçekten öyle mi?

SQL> CREATE TABLE ogan_tablo AS
2 SELECT *
3 FROM all_users;

SQL> select count(*)
2 from ogan_tablo;

COUNT(*)
----------
593

SQL> CREATE OR REPLACE VIEW ogan_perf AS
2 SELECT *
3 FROM ogan_tablo;

View created.

SQL> SELECT *
2 FROM OGAN_TABLO;

Execution Plan
----------------------------------------------------------
Plan hash value: 3842809937

--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 593 | 23127 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| OGAN_TABLO | 593 | 23127 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------------

Note
-----
- dynamic sampling used for this statement

Statistics
----------------------------------------------------------
4 recursive calls
0 db block gets
49 consistent gets
0 physical reads
0 redo size
23128 bytes sent via SQL*Net to client
917 bytes received via SQL*Net from client
41 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
593 rows processed

SQL> SELECT *
2 FROM OGAN_PERF;

Execution Plan
----------------------------------------------------------
Plan hash value: 3842809937

--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 593 | 23127 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| OGAN_TABLO | 593 | 23127 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------------

Note
-----
- dynamic sampling used for this statement

Statistics
----------------------------------------------------------
11 recursive calls
0 db block gets
51 consistent gets
1 physical reads
0 redo size
23128 bytes sent via SQL*Net to client
917 bytes received via SQL*Net from client
41 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
593 rows processed

“Recursive calls” sayısı Oracle’ın içsel olarak yarattığı peşpeşe okumaları sembolize etmektedir ve bu okumalar hem kullanıcı hem de sistem seviyesinde olmaktadır.
“Consistent gets” sayısı bir blok için kaç defa tutarlı okuma yapıldığını göstermektedir.
“Physical reads” disk üzerindeki bloklardan yapılan fiziksel okuma sayısı.

Yukarıdaki örnekte görüntünün fiziksel okuma yaptığı ve birkaç rakam kadar daha fazla tutarlı okuma yaptığını gördük. Şimdi bu iki sorguyu arka arkaya çalıştıralım ve parse aşamasını geçmesini sağlayarak cache içerisine yazılmasını sağlayalım;

SQL> SELECT *
2 FROM OGAN_PERF;

Execution Plan
----------------------------------------------------------
Plan hash value: 3842809937

--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 593 | 23127 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| OGAN_TABLO | 593 | 23127 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------------

Note
-----
- dynamic sampling used for this statement

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
44 consistent gets
0 physical reads
0 redo size
23128 bytes sent via SQL*Net to client
917 bytes received via SQL*Net from client
41 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
593 rows processed

SQL> SELECT *
2 FROM OGAN_TABLO;

Execution Plan
----------------------------------------------------------

Plan hash value: 3842809937

--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 593 | 23127 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| OGAN_TABLO | 593 | 23127 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------------

Note
-----
- dynamic sampling used for this statement

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
44 consistent gets
0 physical reads
0 redo size
23128 bytes sent via SQL*Net to client
917 bytes received via SQL*Net from client
41 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
593 rows processed

Gördüğünüz gibi görüntünün bana sağladığı bir getiri bulunmamakta ve ilk defa parse edildikleri zaman farklılıklar görülmekte ancak bu farklılığın görüntünün daha hızlı olduğunu açıklayan bir yanı bulunmamakta. Kısacası görüntülerin performansı arttırdığı tek nokta eğer başında nasıl sorgu yazmasını bilen bir geliştirici varsa, yani emin ellerdeyse evet, görüntüler performansı arttırabilir ama bunu arttıran görüntünün yani objenin kendisi değil, içerisinde bulundurduğu sorgudur.

İyi çalışmalar dilerim.

Ogan

Undo Tablespace Yönetimi ve Undo

Ogan Ozdogan — Thu, 24 Feb 2011 09:24:11 +0000

Merhaba,

Bu yazımda, undo’nun ne olduğunu, nasıl yönetildiğini, undo tablespace’in amacını ve günlük kullanımdaki yerini ve boyutlandırmasını anlatmaya çalışacağım.

Her bir Oracle veritabanının işlenen verinin bakımını yapabilmesi ve ihtiyaç anında ilgili bilgiyi geri alabilmesi için bir method kullanması gerekmektedir. Bahsettiğim bilgiyi henüz commit edilmemiş aktif transaction’lar olarak düşünürsek eğer aslında bu bilgi tiplerine undo

Undo bilgileri aşağıdaki durumlarda;

1) Bir işlemi (transaction) rollback yapabilmek,
2) Veritabanını kurtarmak (recover),
3) Verinin okuma tutarlılığını sağlayabilmek,
4) Flashback query ile önceden kullanılmış bir DML’i yeniden sorgulayabilmek,
5) Oracle Flashback özellikleri ile kayıp veriye yeniden ulaşabilmek için undo kullanılabilir.

Henüz commit edilmemiş bir transaction rollback komutunu koşarsa undo bilgileri kullanılarak veriler geriye çevrilebilir. Veritabanının kurtarılması işleminde redo log’lar tarafından fiziksel datafile’lara yazılmış ancak henüz commit edilmemiş değişikliker için undo yine kullanılabilir.

Otomatik Undo Yönetimi

Undo bilgisini ve boyutlandırmasının yönetilmesini Oracle’a bırakabiliriz zira otomatik undo yönetimini devreye alarak bunu sağlayabilirsiniz. Bu şekilde undo tablespace yaratabilir ve aktif session’ların undo yönetimini otomatik olarak yaptırabilirsiniz. Bunu sağlayabilmek içinUNDO_MANAGEMENT parametresini AUTO konumuna getirmeniz yeterli olacaktır.

Bir veritabanı ilk defa yaratılırken undo tablespace’i de yaratılmaktadır. Yalnız bu noktada unutmamanız gereken birşey var ki; bir veritabanın iki datafile, iki tablespace, iki online redolog ve bir control dosyası ile yaratılması şarttır. Tablespace’lerden birisi system bir diğeri ise sysaux’tur ve iki datafile’da bu iki tablespace’e aittir. Yani bir undo tablespace’i veritabanı yaratılırken yaratmak zorunda değilsiniz. Undo tablespace sonradan elle de yaratılabilir.

Bu konunun önemli notlarından birisi ise bir veritabanı her açılışında undo tablespace’ini aramaktadır. Eğer tahsis edilmiş varsayılan bir undo tablespace’i bulunmuyorsa, undo bilgileri system tablespace’ini yazılır. Bu tavsiye edilen birşey kesinlikle değildir ve veritabanı açıldığı zaman undo tablespace’in yaratılmadığı ve undo bilgilerinin system tablespace’ine yazılacağını bildiren bir bilgi alert.log dosyasına işlenmektedir.

Bir veritabanında birden çok undo tablespace bulunabilir. Bunun bir sakıncası yoktur ancak bir tanesini varsayılan olarak atayabilirsiniz. Bunu sağlayan parametre ise UNDO_TABLESPACE parametresidir.

UNDO_TABLESPACE = UNDOTBS_01

Eğer undo_tablespace parametresinin bir değeri varsa ancak ilgili undo tablespace veritabanında bulunmuyorsa STARTUP komutu hata alacaktır. UNDO_TABLESPACE parametresini RAC (Real Application Cluster) ortamlarında da kullanabilirsiniz. Eğer otomatik undo yönetimi aktive edilmişse elle yapılması için tanımlanmış undo parametreleri göz ardı edilecektir.

Yukarıdaki bilgileri aktarmışken, sırada undonun korunacağı (undo retention) periyotunu tanımlamak var. Veritabanındaki undo tablespace’inde tutulan ve aktif transaction’ların henüz commit edilmemiş bilgilerini içeren undo verileri sadece belirli bir süre undo tablespace’inde tutulmaktadır. Buna da “undo retention” süresi denilmektedir. Bir transaction commit edildikten sonra daha önceki undo bilgilerine gerek kalmamaktadır fakat tutarlı bir okuma sağlayabilmek için, uzun süre alan ve çalışan sorguların eski undo bilgileri und tablespace’inde tutulabilmektedir. Bunun sebebi ise flashback özelliğini kullabilmektir. Flashback özelliklerinin kullanabilmesi içinse undo retention süresini mümkün olduğunca uzun tutmak isteyebilirsiniz.

Eski ve commit edilmiş, undo retention parametresinden eski undo bilgileri “süresi dolmuş” olarak kabul edilmekte iken, eski ve commit edilmiş ancak undo retention parametresinden yeni olan undo bilgileri “süresi dolmamış” olarak kabul edilmektedir.

UNDO_RETENTION parametresini -ki saniye olarak atanmaktadır- değiştirebilirsiniz ancak Oracle bunu otomatik undo yönetiminde kendisi de yönetmektedir. Bunu sistem aktivitesine göre boyutlandırmaktadır. Eğer sizin undo tablespace için tanımladığınız alan, yine tanımladığınız undo_retention periyodunu aşmakta ise Oracle, undo tablespace içerisinde “süresi dolmuş” olarak işaretlenen undo bilgilerini silecektir. Bu da aslında otomatik undo yönetiminin bir parçasıdır.

Bir undo tablespace’ini AUTOEXTEND, yani otomatik genişleyecek şekilde tanımladıysanız eğer Oracle, undo tablespace’i büyütmek istediği zaman daha fazla yere ihtiyaç duyacak ve tablespace alanını AUTOEXTEND doğrultusunda arttıracaktır. Arttıramadığı durumlarda bir hata alacaksınız ve bu hatayı alert.log dosyasında göreceksiniz. İlgili hata nedeniyle çalışmakta olan transaction iptal edilecek ancak rollback yapabilmesi için önceki bilgileri undo tablespace’te tutulmaya devam edecektir. Bu noktada dokümante edilmemiş bir Oracle bilgi mesajından bahsetmek istiyorum. Diyelim bir transaction’ınız var ve çok uzun süren bir sorgu. Aradan 30 dakika geçti ve bağlantınız kötü bir biçimde sonlandırıldı. Alert.log dosyasında göreceğiniz mesaj şudur;

SMON: Parallel transaction recovery tried.

Bu tamamen normal bir mesajtır ve undo bilgileri okunarak, transaction bir anlamda rollback yapılmaktadır. Yani SMON sadece startup seviyesinde çalışan bir arka plan görevi değildir.

Retention Garantisi

Veritabanında uzun süren sorguların undo’dan silinmemesini garanti altına alabilirsiniz. Flashback query için tutarlılığın sağlanmasında kullanılabilmektedir. Eğer retention garantisi aktif hale getirildi ise undo_retention parametresinin saniye değeri kadar olan bilgi undo tablespace’inde saklanacaktır. Tablespace dolsa bile bu bilgiler silinmeyecektir ve “süresi dolmamış” bilgilerin üzerine başka undo verileri girilmeyecektir. Bu opsiyonun varsayılanı kapalı konumdur ve bir komut ile aktif hale getirilir.

UNDO_RETENTION parametresini init parametre dosyasında (9i’den önce pfile veya 9i’den sonra spfile) ya da sistem çalışırken değiştirebilirsiniz;

UNDO_RETENTION = 1800

ALTER SYSTEM SET UNDO_RETENTION = 2400;

Bir undo tablespace’inin sabit bir boyutu olabilir ya da otomatik olarak arttırılacak şekilde tasarlanabilir.

Yeni bir sistem kurmuşsanız ve uygulamanın ne kadar undo yaratacağını tahmin edemiyorsanız AUTOEXTEND özelliğini kullanarak undo tablespace’in boyutlarının nereye kadar gidebileceğini gözlemleyebilirsiniz.

Kararınızı sabit boyutlu bir undo tablespace kullanmaktan yana kullanırsanız da size yardımcı olabilecek bir çok özellik bulunmaktadır. Bunlardan bir tanesi DBMS_ADVISOR paketidir. Enterprise Manager’da kullanılan “undo advisor” AWR tarafından toplanan bilgilerle oluşturulmaktadır. Yeni veritabanı kurulduğu zaman tutarlı bir AWR raporu almak mümkün olmadığı için ilk başta otomatik undo yönetimi ve AUTOEXTEND özelliğinin açık olması önerilmektedir. Zamanlar AWR raporları daha da tutarlı veriler sağlamaya başladığı zaman AUTOEXTEND yerini sabit boyutlandırmalı undo tablespace’e bırakabilir.

Undo advisor’ın bir örnek script’ini vermem gerekirse;

DECLARE

tid NUMBER;
tname VARCHAR2(30);
oid NUMBER;

BEGIN

DBMS_ADVISOR.CREATE_TASK('Undo Advisor', tid, tname, 'Undo Advisor Task');
DBMS_ADVISOR.CREATE_OBJECT(tname, 'UNDO_TBS', null, null, null, 'null', oid);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'TARGET_OBJECTS', oid);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'START_SNAPSHOT', 1);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'END_SNAPSHOT', 2);
DBMS_ADVISOR.SET_TASK_PARAMETER(name, 'INSTANCE', 1);
DBMS_ADVISOR.execute_task(tname);

END;
/

Advisor görevini başarıyla yarattıktan sonra Enterprise Manager’dan ADDM’e bakarak ilgili görevleri inceleyebilirsiniz.

NOT: ADDM, AWR Enterprise Edition ile birlikte satın alınabilecek bir pakettir (Bkz. Diagnostic Pack). Bu paketi satın almadıysanız eğer statspack kullanabilirsiniz.

UNDO TABLESPACE YÖNETİMİ

UNDO TABLESPACE OLUŞTURULMASI

Bir undo tablaspace’i iki ayrı yönetim ile oluşturabilirsiniz. Bunlardan bir tanesi CREATE DATABASE komutudur. Instance otomatik undo yönetimi ile açılacak ve bir undo tablespace’iniz olacaktır. Diğer yönetim ise zaten açık olan ve undo yönetimini system tablespace’i devam ettiren bir veritabanında undo tablespace yaratmaktır. Bunu yapabilmenin komutu da CREATE UNDO TABLESPACE.

Önemli notlardan birisi, undo tablespace üzerinde hiçbir obje yaratamazsınız. Sıradan bir tablespace değildir ve obje yaratılması kabul edilmez. Sadece sistem – undo bilgileri içindir.

Aşağıda CREATE DATABASE komutu ile nasıl undo tablespace yaratabileceğiniz görebilirsiniz;

CREATE DATABASE ORCL
CONTROLFILE REUSE
.
.
.
UNDO TABLESPACE undotbs_01 DATAFILE '/u01/oracle/rbdb1/undo0101.dbf';

Eğer CREATE DATABASE komutu koşarken undo tablespace düzgün bir şekilde yaratılamazsa bütün prosedür sonlanacaktır ve yapılan işlemler boşa gidecektir. Bütün veritabanı dosyalarını silmeniz, hatayı düzeltmeniz ve komutu yeniden koşmanız gerekmektedir.

Undo tablespace’in diğer oluşturulma komutu ise;

CREATE UNDO TABLESPACE undotbs_02
DATAFILE '/u01/oracle/rbdb1/undo0201.dbf' SIZE 2M REUSE AUTOEXTEND ON;

Birden çok undo tablespace yaratabilirsiniz ancak bunlardan sadece bir tanesi aktif olarak çalışabilir.

ALTER UNDO TABLESPACE

Bir undo tablespace’inin özellikleri ALTER TABLESPACE komutu ile değiştirilebilir. Bu komut ile;

1) Yeni bir datafile eklenebilir.
2) Varolan bir datafile yeniden adlandırılabilir.
3) Varolan bir datafile offline ya da online yapılabilir (NOT: UNDO TABLESPACE TAMAMEN OFFLINE YAPILAMAZ).
4) Undo garantisini açmak ya da kapamak için kullanılabilir.

Örnek;

ALTER TABLESPACE undotbs_01
ADD DATAFILE '/u01/oracle/rbdb1/undo0102.dbf'
AUTOEXTEND ON NEXT 1M
MAXSIZE UNLIMITED;

DROP UNDO TABLESPACE

Bir undo tablespace’ini düşürebilirsiniz (drop etmek). Bunu yapabilmeniz için aşağıdaki komutu koşmanız gerekmektedir;

DROP TABLESPACE undotbs_01;

Bir undo tablespace sadece ve sadece hiçbir instance tarafından kullanılmıyorken düşürülebilir. Eğer undo tablespace olağanüstü bir transaction içeriyorsa (ölmüş bir transaction ve henüz kurtarılmamış) o zaman drop işlemi çalışmayacaktır.

Bu konu ile ilgili önceki bir yazımı okumanızı tavsiye ederim. Undo tablespace’i düşürebilmek için dikkatli olmak gerekmektedir. İlgili yazı için –> http://oganozdogan.blogspot.com/2010/07/aktif-rollback-segment-ora-01548.html

UNDO TABLESPACE DEĞİŞTİRİLMESİ

Varsayılan ve aktif olarak işlenecek undo tablespace’in hangisi olacağına dinamik olarak karar verebilirsiniz. Tabii bunu yapabilmek için spfile kullanmak gerekmektedir!

ALTER SYSTEM SET UNDO_TABLESPACE = undotbs_02;

Bu komut ile birlikte bütün aktif transaction’lar artık yeni undo tablespace’i kullanacaklardır. Bunu sağlayabilmek için komutun başarılı olması gerekmektedir.

Aşağıdaki komut geçerli undo tablespace’i hiçbir undo tablespace’ine tanımlamamaktadır;

ALTER SYSTEM SET UNDO_TABLESPACE = '';

Tabii yukarıdaki komut dikkatlice kullanılmalıdır zira bu komut ile geçerli undo tablespace yerini eski undo tablespace’e bırakacaktır. Eski bir undo tablespace yoksa eğer hata alınabilir.

UNDO HAKKINDA BİLGİ GÖRÜNTÜLEMEK

Undo hakkında bilgiye sahip olabilmek için aşağıdaki görüntüler sorgulanabilir;

V$UNDOSTAT
V$ROLLSTAT
V$TRANSACTION
DBA_UNDO_EXTENTS
DBA_HIST_UNDO_STAT

V$UNDOSTAT görüntüsü içerisinde çok faydalı undo bilgileri bulunmaktadır. Bu görüntüde undo alan tüketimi, transaction tutarlılığı ve undo retention parametresinin ayarlanması gibi bilgiler bulunmaktadır. Aşağıdaki sorgu kullanılarak bir bilgiye sahip olabilirsiniz;

SELECT TO_CHAR(BEGIN_TIME, 'MM/DD/YYYY HH24:MI:SS') BEGIN_TIME,
TO_CHAR(END_TIME, 'MM/DD/YYYY HH24:MI:SS') END_TIME,
UNDOTSN, UNDOBLKS, TXNCOUNT, MAXCONCURRENCY AS "MAXCON"
FROM v$UNDOSTAT WHERE rownum <= 144;

İyi çalışmalar.

Ogan – http://oganozdogan.blogspot.com/

Veritabanı Temel Kavramları ve ORACLE Veritabanına Genel Bakış Videosu

Mehmet ACA — Wed, 26 Jan 2011 22:02:13 +0000

6 Kasım 2010 tarihinde yapılan CETURK Ege Üniversitesi Java Günü etkinliğinde Talip Hakan Öztürk, “Veritabanı Temel Kavramları ve ORACLE Veritabanına Genel Bakış ” konulu sunum yaptı.

Aşağıdaki videolardan sunumu izleyebilirsiniz.

1. Bölüm

2. Bölüm

ORA 600 Nedir?

Ogan Ozdogan — Fri, 21 Jan 2011 19:16:14 +0000

Merhaba,

Birçoğunuz hiç karşılaşmamış olmanıza rağmen aslında hepimizin yakından takip ettiği ve bildiği ORA-00600 hataları kimi zaman veritabanı yöneticilerinin gerçek anlamda canını sıkmaktadır. Bir 600 hatası aldığınız zaman ilk ve mutlaka yapmanız gereken çözüm, metalink’i kontrol etmektir. Metalink üzerinde ORA-600 ve ORA-07445 ayrıcalıklı hataları için bir araç bulunmakta ve bu araca ilk argümanları girdiğinizde size yapılması gerekenleri özetleyen bir sonuç listesi vermekte. Onun için ORA 600 ve ORA 7445 hatalarını kendiniz düzeltmek için çok fazla vaktinizi harcamayın. Ayrıca üzerinizdeki baskı gittikçe artacağı için google’a hiç danışmamanızı tavsiye ederim zira bu yazıyı aslında google’da arama yaparak buldunuz, öyle değil mi? . Bu hata, sıradan bir hata olmadığı için google size cevap veremeyecektir çünkü bu hatanın genel çözümü sadece metalink içerisindedir. Metalink içerisindeki bir bilgiyi de dışarıya çıkartmak veya başka bir site altında göstermek, kopyalamak kesinlikle yasaktır. Dolayısıyla önce metalink, eğer çözüm bulamadıysanız mecbur bir SR (Service Request) açacaksınız ve Oracle’dan cevap bekleyeceksiniz.

ORA-600 veya ORA-07445 hatalarının kaynağı kimi zaman bir bug veya içsel bir ayrıcalıklı hatadan kaynaklanmayabiliyor. Sizin geliştirdiğiniz bir uygulama veya yanlışlıkla ayarladığınız bir parametre yüzünden de bu hataları almanız mümkün. Benim size tavsiyem en kısa zamanda eğer yoksa bir metalink hesabı edinmeniz ve buradan gerekli kontrolleri yapmanız. Unutmayın, teknik olarak bu hatalar sizin çözebileceğiniz türde hatalar değildir. Çözüme kendiniz ulaştıysanız eğer yine sizden kaynaklanan bir hatadan olduğunu da eklemem gerekiyor. Tabii bunun bir bug olduğunu varsayarsak yapabileceğiniz hiçbir şey yok demektir.

Metalink adresi: http://metalink.oracle.com/

İyi çalışmalar.

Ogan Özdoğan

http://oganozdogan.blogspot.com/