İstemci tarafında gerçekleşen bu işlem sayesinde veritabanına bağlantılar azalacağından performans açısından fayda sağlanmaktadır. Sorgu çalıştırılması istemci tarafında yapıldığından sunucuya yük binmeyecek ve sonuç daha hızlı alınacaktır. Sorgu sonuçları istemci tarafında sistem hafızasında(RAM) tutulmaktadır. İstemcide bulunan farklı uygulamalar OCI teknolojilerini kullandıkları takdirde bu özellikten ortak olarak yararlanabilmektedirler. Bir diğer ifadeyle OCI tarafından sağlanan bu sorgu sonuç deposu tüm OCI kullanan uygulamalara saydamdır ve ortak olarak kullanılabilmektedir. Mevcut sorgu sonuçları veritabanında meydana gelen bir değişiklik sonucunda otomatik olarak güncellenmektedir. İstemci peş peşe sorgu dizisi çalıştırdığı esnada veritabanında ilgili kayıtlarda bir değişiklik olursa istemcideki sorgu sonuçları önce geçersiz duruma getirilir daha sonra sorgu sonuncunun son hali depolanır ve kullanılmaya devam eder.

.

İstemci tarafındaki sorgu sonuç deposunun güncel tutulması işlemi veritabanı ve OCI arasındaki iletişim sayesinde yapılmaktadır. Veritabanında ilgili veriler bir transaction tarafından değiştirilmesi durumunda, istemciden yapılacak olan ilk istek sırasında istemciye mevcut sorgu sonucunun geçersiz olduğu bilgisi gönderilir ve bu sorgu sonucunun kullanılması engellenmiş olur. Eğer istemciden veritabanına bir süre istekte bulunulmamışsa ve bu süre CLIENT_RESULT_CACHE_LAG veritabanı parametresinde belirtilen (varsayılan 3 saniye) süreden uzun ise yine OCI bir sonraki oci_execute() işleminin güncellik kontrolü yapmasını sağlayacaktır.

Bu özelliğin PHP ile birlikte kullanılabilmesi için OCI’nin 1.3 ve üstü sürümünün kurulması gerekmektedir. PHP ve OCI kurulumu için http://suhanerol.wordpress.com/2009/03/24/ubuntu-uzerinde-php-oci8-ve-oracle-instant-client-kurulumu/ makalesi incelenebilir.

.

CLIENT_RESULT_CACHE_SIZE veritabanı parametresi bu özelliğin aktif/devre dışı olduğunu belirleyen parametredir. 0 değeri bu özelliğin kapalı olmasını sağlar, 0 Haricinde bir değer atanması durumunda özellik aktif hale gelir. Atanan değer istemci tarafında sorgu sonuçlarının depolanması için hafızada ne kadar byte yer ayrılacağını belirler. Sorgu sonuçlarını istemcinin(webserver) RAM’inde tutulurlar.

.

$ sqlplus / as sysdba
SQL> alter system set client_result_cache_size=64M scope=spfile;
SQL> startup force
.

Bu komutlarla birlikte İstemci tarafında sorgu sonuçlarının tutulması özelliği aktif hale getirilmiş olmaktadır. İstemci RAM’inde 64MB’lık bir bölüm sorgu sonuçlarının depolanması için ayrılmış olmaktadır.

.

SQL>show parameter client_result_cache;

komutuyla bu parametreye ilişkin durumu listelenebilmektedir.

NAME                                           TYPE          VALUE
———————————— ———– ——————————
client_result_cache_lag               big integer       3000
client_result_cache_size              big integer       64M

.

Konu ile ilgili belirleyici bir diğer parametre de “RESULT_CACHE_MODE” dir. Bu parametre FORCE veya MANUAL olarak iki farklı değer alabilmektedir. MANUAL değeri varsayılan değerdir. Eğer bu değer MANUAL ise ve sorgu sonuçlarının istemcide tutulması isteniyorsa sorgulara /*+ result_cache */ hint’inin eklenmesi gerekmektedir. Aksi taktirde sorgu sonuçları tutulmayacaktır. Parametrenin FORCE olması durumunda uygun bütün sorguların sonuçları istemcide tutulacaktır. Eğer tutulması istenmeyen sorgular var ise bu sorgulara /*+ no_result_cache */ hint’inin eklenmesi gerekmektedir.

Oracle 11gR2 ile birlikte DBA’lerin de tablo veya view’ların istemcide tutulabilmesini ayarlayabilmeleri sağlanmıştır.

create table deneme (….) result_cache

alter table deneme result_cache

Görüldüğü gibi bu özelliğin kullanılması için PHP tarafında bir değişiklik yapılması gerekmemektedir. Oracle Server’da ilgili parametrelerin ve gerekiyorsa sorguların değiştirilmesi yeterli olmaktadır.

.

Aşağıdaki örnekte aynı sorgunun peş peşe çalıştırılması ve bunun Oracle Server’a ne şekilde yansıdığı gösterilmiştir.

.

<?php
$c=oci_connect(‘hr’,'hr’,'//oracleserver:1521/xxx’);
for($i=0;$i<100;$i++) {
$s=oci_parse($c,”select /*+ result_cache */ * from hr.employees”);
oci_execute($s,OCI_DEFAULT);
oci_fetch_all($s,$res);
}

?>

bu php betiği çalıştırıldıktan sonra oracle serverda bu sorgunun çalıştırılma istatistiği şu şekildedir.

.

SQL> select parse_calls, executions, sql_text from v$sql where sql_text like ‘%employees%’;

.

PARSE_CALLS        EXECUTIONS    SQL_TEXT
—————————————————————————————————–

2                                 2 ……………select / *+ result_cache */ * from hr.employees

.

Aynı PHP betiği tekrar çalıştırıldığında …

.

SQL> select parse_calls, executions, sql_text from v$sql where sql_text like ‘%employees%’;

.

PARSE_CALLS       EXECUTIONS           SQL_TEXT
—————————————————————————————————–
4                                   4 ………………select /*+ result_cache */ * from hr.employees

.

Bu duruma göre PHP betiğinde 100 kere çalıştırılan bir sorgu veritabanında 2 kere çalıştırılmıştır. Geriye kalan 98 sorgu istemcide çalıştırılmış ve oracle server çok daha az işlem yaptırılmıştır. Sorgu istemci tarafında geçerli olarak tutuluyor olsa bile ilk oci_execute() komutu veritabanında çalışıtırılır, daha sonraki çalıştırmalar istemci tarafındaki sorgu sonuçlarından bilgiyi alırlar. Bu php betiğinde sorgu ilk olarak veritabanında çalıştırılmıştır ve hr.employees tablosunda bir değişiklik olmadığından bundan soraki sorgular istemci tarafında çalışıtırılmış ve oracle serverdan yük alınmıştır. İkinci çalıştırılmanın sebebi şudur: CLIENT_RESULT_CACHE_LAG veritabanı parametresi istemci tarafındaki sorgu sonuçlarının geçerlilik süresini belirler ve bu süre varsayılan olarak 3000 milisaniyedir. PHP betiği çalıştıktan sonra 3ncü saniyede oci_execute() serverda çalıştırılır ve istemcideki sorgu sonuçlarının geçerliliği kontrol edilir.

.

Burada PHP geliştiricilerinin dikkat etmesi gereken bir konu vardır. oci_execute() fonksiyonun ikinci parametresi OCI_DEFAULT olarak belirtilmezse aşağıdaki tablo ortaya çıkacaktır.

.

SQL> select parse_calls, executions, sql_text from v$sql where sql_text like ‘%employees%’;

.

PARSE_CALLS        EXECUTIONS         SQL_TEXT
—————————————————————————————————–
2                                100 ……………select /*+ result_cache */ * from hr.employees

.

Görüldüğü gibi sorguların tamamı veritabanında çalıştırılmıştır. Bu yüzden OCI_DEFAULT parametresinin kullanılması gerekmektedir. OCI_DEFAULT değeri auto-commit özelliğini devreden çıkaran bir değerdir. Otomatik commit özelliğinin açık olması durumunda her oci_execute() fonksiyonu çağırımından sonra içsel olarak yapılan commit işleminin mevcut sorgu sonucunun değişimine sebep olabileceği ihtimali sebebiyle bir sonraki oci_execute() işlemi veritabanında çalışıtırılmaktadır.

.

Aşağıdaki örnekte aynı veriler üzerinde işlem yapan iki PHP betiğininden birinin güncelleme işlemi yapması sonucunda ortaya çıkan tablo gösterilmiştir. a.php betiği employees tablosundan peş peşe bilgi okurken b.php betiği a.php betiği çalışmaya başladıktan sonra aynı tablo üzerinde güncelleme işlemi yapmaktadır. Bu durumda a.php betiğindeki oci_execute() fonksiyonu b.php betiğinin güncelleme işlemini yapmasından sonra istemci sorgu sonuçlarının geçersiz olmasından dolayı oracle server tarafında çalışmaktadır. b.php betiği commit() fonksiyonun çalıştırdıktan sonra ise a.php tekrar istemci tarafındaki sorgu sonuçlarından yararlanmaya devam edecektir.

.

a.php

<?php
$c=oci_connect(‘hr’,'hr’,'//oracleserver:1521/xxx’);
for($i=0;$i<100;$i++) {
$s=oci_parse($c,”select /*+ result_cache */ * from hr.employees”);
oci_execute($s,OCI_DEFAULT);
oci_fetch_all($s,$res);
sleep(1);

}

?>

b.php

<?php
sleep(10); //10 sn bekle
$c=oci_pconnect(‘system’,’123456′,’//oracleserver:1521/xxx’);
$s=oci_parse($c,”update hr.employees set salary=1000 where employee_id=100″);
oci_execute($s,OCI_DEFAULT);
sleep(10);
ocicommit($c);

?>

# php a.php &

#php b.php

.

komutları çalıştırıldığında b.php 10 sn bekleyecektir. bu süre içinde a.php sorgu sonuçlarını istemciden alacaktır. b.php ‘deki güncelleme işlemi çalıştığında ve tekrar 10 saniye beklemeye geçtiğinde a.php deki oci_execute() istemciden bilgi alamayacak ve sorguları veritabanında çalıştıracaktır. Çünkü b.php tabloda güncelleme yapmıştır ve henüz commit işlemini gerçekleştirmemiştir. OCI bu durumu algılar ve a.php devam eden sorgularında istemcideki sorgu sonuçlarını kullanmasını engeller, sorguların veritabanında çalıştırılması sağlar. b.php deki ocicommit() fonksiyonu çalıştırıldıktan sonra a.php deki sorgular güncellenen istemci sorgu sonuçları üzerinden çalışmaya devam eder.

.

İstemci Tarafında Depolanamayacak Sorgu Türleri

.

Bazı sorgu türleri bu özellik tarafından desteklenmemektedir. Sorguda /*+ result_cache */ hint’i kullanılsa bile bu sorgular depolanmayacaktırlar. Bu sorgulardan bazıları 11g ile gelen başka bir özellik olan “Sunucu Tarafında Sorgu Sonucu Depolama (RESULT CACHE)” özelliği sayesinde oracle server’da SGA da depolanabilirler.

• View’lar

• Uzak Nesneler (Remote Objects)

• Flashback sorgular

• PL/SQL fonksiyonu içeren sorgular

Bu özellikle ilgili istatistikler CLIENT_RESULT_CACHE_STATS$ görünümden takip edilebilir. OCI belirli aralıklar Oracle Server’a istatistik bilgileri göndermektedir.

.

Sonuç

.

OCI Result Cache özelliğinin hiç değişmeyen(Read-only) veya çok az değişen tablolar için kullanılmasının daha doğru bir karar olduğu görülmektedir. Çok sık çağırılan fakat nispeten daha fazla değişikliğe uğrayan sorgularda da bu özelliğin kullanılması uygun olabilir. İstemci tarafındaki RAM maliyetinin Oracle Server tarafında olduğundan daha düşük olması bu özelliğin daha yaygın kullanılmasının da bir sebebi olabilir.

.

OCI Result Cache özelliği, Oracle’ın ölçeklenebilirlik ve performans konularında bir adım daha atmasına sağlamaktadır. Yazılım geliştiricilerin dosya sisteminde sorgu sonuçlarını tutmak ve bunları kullanarak uygulamaya çalıştıkları Caching uyarlama çalışmalarının mevcut bütün handikaplarını ortadan kaldıran ve tek bir satır kod yazmadan kullanıma sunan bu özellik , Server Taraflı Sorgu Sonucu Depolama (RESULT CACHE) ve DRCP özellikleriyle de birleştirildiğinde, PHP gibi betik lisanlarının diğer üst düzey lisanlar karşısındaki handikaplarının büyük bir kısmının ortadan kalkmasını da sağlamaktadır. Oracle tarafından desteklenen PHP , 11g ve OCI’daki yenilikler sayesinde Oracle Veritabanı kullanacak yazılımlar için güçlü bir alternatif haline gelmiştir.

Bir terminal açınız ve aşağıdaki sudo komutunu yazarak sistem yöneticisi hakkını alınız.

# sudo -i

Aşağıdaki komut apache’nin son sürümünü yükleyecektir.

# apt-get install apache2


PHP ve diğer modüllerin kurulumu
# apt-get install php5-common php5 php5-dev libapache2-mod-php5 php5-cli

# apt-get install build-essential php-pear


# apt-get install libaio1


Aşağıdaki linki kullarak Oracle Instant Client BASIC ve SDK dosyalarını indiriniz.

http://www.oracle.com/technology/tech/oci/instantclient/index.html

Dosyalar muhtemelen kullanıcının masaüstüne kayıt edilecektir.

Aşağıdaki komut ile yeni bir dizin açınız.

# mkdir /opt/oracle

İndirdiğiniz iki dosyayı yeni oluşturulan /opt/oracle klasörüne taşıyınız.

# mv /home/ubuntu/Desktop/*.zip /opt/oracle


Yeni oluşturulan klasöre geçiniz

# cd /opt/oracle

InstantClient dosyalarını aşağıdaki komut ile açınız.
# unzip \*.zip

Unzip işlemi sonunda yeni bir klasör oluşacaktır. Bu klasörün ismini aşağıdaki komut ile değiştiriniz.

# mv instantclient_11_1 instantclient

Yeni klasöre giriniz.
# cd instantclient


Yeni Sembolik linkler oluşturmak için aşağıdaki komutlar çalıştırınız.

# ln –s libclntsh.so.11.1 libclntsh.so
# ln –s libocci.so.11.1 libocci.so


Aşağıdaki komut ile yeni bir klasör oluşturunuz. Bu klasör OCI8 kütüphane dosyalarını içerecektir.

# mkdir /opt/oracle/src

Yeni oluşturulan klasöre geçiniz ve pecl ile OCI8 tar dosyasını indiriniz. Pecl son sürüm OCI8 dosyasını indirecektir. Şuanda son sürüm 1.3.5 dir. 1.3 sürümünden itibaren "Client Result Cache" özelliği kullanılabilmektedir.

# cd /opt/oracle/src
# pecl download oci8

İndirilen OCI8 dosyasını açınız.

# tar xvf oci8-1.3.5.tgz

Yeni oluşan klasöre giriniz.

# cd oci8-1.3.5

phpize komutu, PHP için yeni bir eklenti derlemek gerektiğinde sistemde gerekli hazırlıkların yapılmasını sağlamaktadır. OCI8 Eklentisini derlemek için bu komutu çalıştırınız.

# phpize

Aşağıdaki komutu kullarak ORACLE_HOME çevre değişkenini tanımlayınız.
# export ORACLE_HOME=/opt/oracle/instantclient


OCI8 eklentisinin derlemesi işleminin ilk adımı olarak aşağıdaki configure komutunu çalıştırınız.
# ./configure --with-oci8=share,instantclient,/opt/oracle/instantclient

make komutuyla derlemeyi başlatınız.

# make


Aşağıdaki komut ile oluşan oci8.so dosyasının ilgili klasöre kopyalanmasını sağlayınız.

# make install

PHP ve OCI8 bağlantısının sağlanması için php.ini dosyalarına “extension=oci8.so” satırının eklenmesi gerekmektedir. Aşağıdaki komutlar ile bunu gerçekleştirebilirsiniz.

# echo extension=oci8.so >> /etc/php5/apache2/php.ini
# echo extension=oci8.so >> /etc/php5/cli/php.ini

Apacheyi Yeniden Başlatınız.

# /etc/init.d/apache2 restart


Bu işlemlerden sonra PHP, OCI aracılığıyla Oracle veritabanı bağlantısı yapabilir hale gelmiştir. aşağıdaki örnek kod ile test yapabilirsiniz.

<?php
$c=oci_pconnect('hr','hr','//oracleserver:1521/xe');
$s=oci_parse($c,"select  * from hr.employees");
oci_execute($s);
oci_fetch_all($s,$res);
print_r($res);
?>

Kategorilerde bulunan ürünlerin toplamını ve bu toplamların bütün kategorilerdeki ürünlerin toplamına oranını gösteren bir sql :

1) Alt sorgu kullanılarak :

select kategori_id,count(urun_id) Toplam, ( count(urun_id)/(select count(urun_id) from urunler) )*100 Oran from urunler group by kategori_id

2) Analiktik Fonksiyon Kullanarak

select kategori_id,count(urun_id) Toplam, (COUNT(urun_id)/COUNT(COUNT(urun_id)) over())*100 Oran from urunler group by kategori_id

Alt sorgu veya view kullanımı özellikle kayıt sayısı yüksek olan tablolar için ciddi performans sorunlarına yol açacaktır.

Analitik fonksiyonlarının sağladığı bir diğer avantaj da gruplama yapılan sorgularda sonuç sahalarındaki kısıtlamayı ortadan kaldırmasıdır. Örneğin :

ürün id, kategori id ve bu kategoride bu ürünün bağlı olduğu kategorideki ürün sayısını veren sorgudaki urun id bilgisi gruplama yapmayı engellemektedir. ancak alt sorgu veya view kullanarak sonuca ulaşılabilir. Fakat analitik fonksiyonlar kullanılarak alt sorgulara gerek kalmadan sonuç alınabilir.

select urun_id,kategori_id, count(urun_id) over( partition by kategori_id) kategori_urun_sayisi from urunler

İkinci bir örnek olarak ORACLETURK@yahoogroups.com grubuna gönderilen bir soruyu verebiliriz.

Soru :

Cevap :

Bu sorguda “partition by kul_adi” ile dense_rank() fonksiyonunun herbir kul_adi değeri için ayrı hesaplanması, “Order by kul_tarih DESC” ile de dense_rank() fonksiyonunun sıralama yaparken “kul_tarih” sahasının tersten sıralarayak

Bir analitik fonksiyonu aşağıdaki gibi bir sözdizimine sahip olabilir.

<fonksiyon_ismi>() OVER
(
[PARTITION BY <exp1> [, …]]
ORDER BY <exp2> [ASC|DESC]
[NULLS FIRST|NULLS LAST]
)

PARTITION BY : Bu komut analitik fonksiyonun kullanacağı sorgu sonuçlarını bölümlere ayırır. Örneğin yukarıdaki örnekte Count() fonksiyonu “partition by kategori_id” komutuyla “kategori_id” lere göre sayım yapmaktadır. Yani her kategori_id değeri için ayrı sayım yapmaktadır. “partition by” komutundan sonra saha isimleri veya oracle deyimleri kullanılabilir. Birden fazla saha ismi veya deyim yazılabilir. Örneğin : kategori_id,grup_id,nvl(ust_kategori,0) gibi. Eğer asıl sorguda “group by” kullanılmış ise sadece “select” listesindeki sahalar kullanılabilir, kullanılmamış ise tablolardaki tüm sahalar kullanılabilir. Eğer “partition by” kullanılmazsa tüm sorgu sonucu kullanır.

Plan
SELECT STATEMENT ALL_ROWS Cost: 135 Bytes: 192,004 Cardinality: 8,348
	2 WINDOW SORT Cost: 135 Bytes: 192,004 Cardinality: 8,348
		1 TABLE ACCESS FULL TABLE URUNLER Cost: 134 Bytes: 192,004 Cardinality: 8,348

Plandaki “Window Sort” bölümü analitik fonksiyonun kullanımını belirtmektedir.

ORDER BY :

SIRALAMA (RANKING) FONKSİYONLARI

Bu fonksiyonlar belirtilen saha değerlerine göre kayıtın diğer kayıtlara göre sırasını belirlemeye yararlar. Sıralama fonksiyonları şunlardır :

• RANK() ve DENSE_RANK()

• CUME_DIST() ve PERCENT_RANK()

• NTILE()

• ROW_NUMBER()

RANK() ve DENSE_RANK() : Bu fonksiyonlar kayıtın tüm kayıtlar veya bölümleler içindeki sırasının bulunması sağlar. İki fonksiyon arasındaki fark aynı sıra değerine sahip kayıtların olması durumunda bir sonraki sıra numarasının ne şekilde belirleneceğidir. RANK() fonksiyonunda aynı sıra değerine sahip kayıtlardan sonraki kayıtın sıra değeri için boşluk bırakılır. DENSE_RANK() de ise boşluk bırakılmaz ve sıra değerleri birbirini takip eder.

sql > select malkodu,satis_sayisi,rank() over(order by satis_sayisi) Rank,dense_rank() over(order by satis_sayisi) Dense_Rank from web.urunler URUN SATIS_SAYISI RANK DENSE_RANK FPA.GR4-PG186 2 1 1 SW.GM-AK.23.0346 3 2 2 CM.CIO-MK000CAS54 7 3 3 CM.BQ-MK000BNQ18 7 3 3 CM.CIO-MK000CAS55 7 3 3 HP.SE-HD-280-PRO-S 11 6 4 <——– DENSE_RANK() Sırayı takip ediyor. FPA.ARW-AZ371ZZ 12 7 5 KKB.PH-66862 34 8 6 MU.ARZ-AR-342 56 9 7 HP.SE-MX-560-S 56 9 7 NB.ASU-UN105ASU86 62 11 8 HP.SE-MX-560-B 68 12 9 EV.ARN-HYDRA 74 13 10

Bu fonksiyonlar parametre almazlar. “Order By” kullanımı zorunludur. “Partition By” kullanımı zorunlu değildir. Kullanılmadığı taktirde tüm sorgu sonucu kullanılacaktır.

ROW_NUMBER() : “ORDER BY” ile belirtilen sıraya göre ve eğer belirtilmişse “PARTITION BY” ile belirtilen gruplar için her bir satıra 1 den başlamak üzere bir sıra numarası verir. “İLK N KAYIT” veya “SON N KAYIT” sorgularında rank() ve dense_rank() fonksiyonlarına nazaran daha iyi sonuç verir.

En Çok Satılan ilk 10 ürün sql > select * from (select malkodu,satis_sayisi,row_number() over(order by satis_sayisi desc) Sira from web.urunler) where sira=<10 URUN SATIS_SAYISI SIRA EV.ARN-HYDRA 74 1 HP.SE-MX-560-B 68 2 NB.ASU-UN105ASU86 62 3 HP.SE-MX-560-S 56 4 MU.ARZ-AR-342 56 5 KKB.PH-66862 34 6 FPA.ARW-AZ371ZZ 12 7 HP.SE-HD-280-PRO-S 11 8 CM.CIO-MK000CAS54 7 9 CM.BQ-MK000BNQ18 7 10

WINDOWING FONKSİYOLARI

Bu fonksiyonlar sorgu sonuç satırları üzerinde hareket ederek birtakım işlemler yapmamıza olanak sağlarlar. Örneğin bir önceki veya bir sonraki satırdaki bir sahadaki değeri kullanarak mevcut satır için hesaplama yapılabilmesini sağlar. Bir sahanın değerlerini ilk satırdan itibaren toplanarak her satır için değerini bulunabilir, ortalama alınabilir, maksimum veya minimum değeler bulunabilir. Özetle bu özellik “PARTITION BY” ile belirlenen grup içinde istenilen ölçüde(satır sayısı, tarih aralığı gibi) önceki veya sonraki kayıtlara ulaşılarak bu kayıtlardan değerlerin alınmasını sağlar.

Ürünlerin satış miktarları ve bu satış miktarlarının yukarıdan aşağıya toplanmış değerlerinin listesi sql > select malkodu,satis_sayisi,sum(satis_sayisi) over(order by satis_sayisi ROWS UNBOUNDED PRECEDING) toplam from web.urunler MALKODU SATIS_SAYISI TOPLAM CM.CIO-MK000CAS54 7 7 CM.BQ-MK000BNQ18 7 14 HP.SE-HD-280-PRO-S 11 25 FPA.ARW-AZ371ZZ 12 37 KKB.PH-66862 34 71 HP.SE-MX-560-S 56 127 MU.ARZ-AR-342 56 183 NB.ASU-UN105ASU86 62 245 HP.SE-MX-560-B 68 313 EV.ARN-HYDRA 74 387

Windowing fonksiyonları Fiziksel (ROWS) ve Mantıksal(RANGE) olmak üzere ikiye ayrılmaktadır. Aralık satır sayısı belirtilecekse fiziksel , satır sayısı yerine değerlere ait aralık belirtilecekse Mantıksal olmaktadır.

Sözdizimi :

ROWS | RANGE

{ UNBOUNDED PRECEDING | <exp> PRECEDING} |

BETWEEN

{UNBOUNDED PRECEDING | <exp> PRECEDING}

AND

{CURRENT ROW | <exp> FOLLOWING} } )

ROWS işlemin fiziksel yani belirli satır aralığıyla olacağını belirtir.

RANGE işlemin Mantıksal yani saha değerine bağlı olarak belirleneceği durumlarda kullanılır. Örneğin 2 gün öncesi, 1 Aylık aralık gibi…

BETWEEN … AND …. Başlangıç ve bitiş noktalarını belirler.

UNBOUNDED PRECEDING işlemin eğer “PARTITION BY” var ise belirlediği aralığın en başından, eğer “PARTITION BY” yok ise tüm sorgu sonucunun en başından başlayacağını belirtir

UNBOUNDED FOLLOWING işlemin eğer “PARTITION BY” var ise belirlediği aralığın sonuna kadar, eğer “PARTITION BY” yok ise tüm sorgu sonucunun sonuna kadar olacağını belirtir.

CURRENT_ROW Eğer ROWS kullanıyorsa o anki satırı pozisyonu, RANGE kullanıyorsa o anki satırın Değeri anlamına gelmektedir.

LEAD ve LAG FONKSİYONLARI

Bu fonksiyonlar sayesinde sorgu sonucunda bir önceki veya bir sonraki satırdaki değerleri kullanarak sonuç elde edilebilmektedir. LEAD ile birlikte sonraki LAG ile birlikte önceki satırlardan değer alınabilmektedir.

LEAD(kolon veya formul, sayısal değer,varsayılan değer) şeklinde kullanılır. sayısal değer LEAD için kaç satır sonraki değerin kullanılacağını belirtir. Kullanılmazsa 1 varsayılan değeridir.

LAG(kolon veya formul, sayısal değer,varsayılan değer) şeklinde kullanılır. sayısal değer LAG için kaç satır önceki değerin kullanılacağını belirtir. Kullanılmazsa 1 varsayılan değeridir.

Varsayılan değer bilgisi sayısal değerin dışına çıkıldığında geri dönen değer olarak verilebilir. belirtilmezse Null değeri döner.

SQL> select malkodu,satis_sayisi from urunler; MALKODU SATIS_SAYISI CM.CIO-MK000CAS54 7 CM.BQ-MK000BNQ18 7 HP.SE-HD-280-PRO-S 11 FPA.ARW-AZ371ZZ 12 KKB.PH-66862 34 HP.SE-MX-560-S 56 MU.ARZ-AR-342 56 NB.ASU-UN105ASU86 62 HP.SE-MX-560-B 68 EV.ARN-HYDRA 74 Bir sonraki sorguda ürürün satış sayısının satis sayisina göre sıralı olarak bir önceki ürünün satış sayısından farkı bulunmaktadır. SQL>select malkodu,satis_sayisi, satis_sayisi – LAG(satis_sayisi,1,0) over(order by satis_sayisi) as FARK from urunler; MALKODU SATIS_SAYISI FARK CM.CIO-MK000CAS54 7 7 <— Varsayılan değer 0 olduğundan ve bir önceki satır olmadığından fark (7-0=7) oluyor CM.BQ-MK000BNQ18 7 0 HP.SE-HD-280-PRO-S 11 4 FPA.ARW-AZ371ZZ 12 1 KKB.PH-66862 34 22 HP.SE-MX-560-S 56 22 MU.ARZ-AR-342 56 0 NB.ASU-UN105ASU86 62 6 HP.SE-MX-560-B 68 6 EV.ARN-HYDRA 74 6

]]> http://suhanerol.wordpress.com/2008/07/28/oracle-analitik-fonksiyonlar/feed/ 7 suhanerol http://suhanerol.wordpress.com/2008/03/20/oracle-da-controlfile-ve-online-redo-log-dosyalari-olmadan-cold-backup-ve-archive-loglar-ile-kurtarmarecovery/ http://suhanerol.wordpress.com/2008/03/20/oracle-da-controlfile-ve-online-redo-log-dosyalari-olmadan-cold-backup-ve-archive-loglar-ile-kurtarmarecovery/#comments Thu, 20 Mar 2008 12:27:41 +0000 suhanerol http://suhanerol.wordpress.com/?p=8 ]]> “Cold backup” ı alınan ve archive log dosyaları yedeklenen bir sistemin
çökmesi ve erişilemez hale gelmesi durumunda veritabanı kurtarması nasıl
yapılır? Bu durumda elimizde çalışan sisteme ait controlfile dosyası ve Online
Redo Log dosyaları bulunmayacaktır. Elimizdeki Cold Backup ve archive log
dosyalarını kullanarak da kurtarma işlemi yapılabilir. Bunun için izlenmesi
gereken yol şudur:

1) “Cold Backup” ile alınan dosyalar (Datafile , controlfile, online redo log
dosyaları) ve Archive Log dosyaları yeni sistemde ait oldukları klasörlere
kopyalanır.

2) “oracle # sqlplus / as sysdba”  komutuyla sqlplus programı
çalıştırılır.

3) SQL> startup mount;      ile veritabanı “mount”
modunda başlatılır.

4) RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
komutuyla kurtarma işlemi başlatılır. Bu komutta normal kurtarma işleminden
farklı olarak “USING BACKUP CONTROLFILE” parametleri kullanılır. Çünkü elimizde
çöken sisteme ait son controlfile dosyaları yoktur. Hangi datafile dosyasına
hangi Archive Log dosyasının işleneceği bilinememektedir. Bu komut sayesinde
hangi archive log dosyalarının kullanılacağının kararı datafile dosyalarının
“header” bölümünde bulunan bilgiler kullanılarak karar verilir.

Komut çalışıtırıldığında aşağıdaki gibi bir sonuç verir.

ORA-00279: 347898987 değişikliği (03/20/2008 14:01:18
içinde oluşturulan) thread 1 için gerekli

ORA-00289: öneri: /opt/oracle/product/10gR2/dbs/arch/1_2_649864014.dbf

ORA-00280: 347898987 numaralı değişiklik (1 thread’i için), 2 numaralı sırasında

Günlüğü belirtin: {<RET>=önerilen | dosya adı | AUTO | CANCEL}

Bu aşamada sistem bize 4 farklı seçenek sunar.

a) ENTER tuşuna basarak önerdiği
archive log dosyasını işler.

b) Hangi archive log dosyasının
işleneceğini yazabiliriz.

c) AUTO yazıp enter a basarak
sormadan sırasıyla bütün archive log dosyalarının işlenmesini sağlar.

d) CANCEL yazıp enter a basarak
kurtarma işlemini bitirilmesini sağlar.

Bu komutlardan 3.sünü uygulayalım yani AUTO yazıp enter tuşuna basarak
archive log dosyalarının işlenmesini başlatalım. Sistemde mevcut en son archive
log dosyasına kadar bütün archive log dosyaları sisteme işlenir. En son dosyayı
işledikten sonra aşağıdaki gibi bir hata verir.

ORA-00308: arşivlenmiş
‘/opt/oracle/product/10gR2/dbs/arch/1_2_649864014.dbf’

günlüğü açılamaz

ORA-27037: dosya staüsü elde edilemiyor

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

Artık bütün archive log dosyaları işlenmiştir ve sıradaki archive log
dosyasını bulamadığı için hata vermiştir.

5) Archive log dosyalarını işledikten sonra veritbanını “ALTER DATABASE OPEN
RESETLOGS” komutuyla başlatırsak aşağıdaki gibi bir hata verir.

ALTER DATABASE OPEN RESETLOGS

*ERROR at line 1:

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: 'system01.dbf'

Bu hatanın sebebi “RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; “
komutunun archive log dosyalarını işleme işleminin CANCEL komutuyla bitirilmesi
gerekliliğidir. Bu yüzden “ALTER DATABASE OPEN RESETLOGS” komutunu çalıştırmadan
önce tekrar “RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; ” komutunu
çalıştırarak kurtarma işlemini başlatmamız ve komut olarak ta “CANCEL” komutunu
vermemiz gerekir.

SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

ORA-00279: 347898987 değişikliği (03/20/2008 14:01:18
içinde oluşturulan) thread 1 için gerekli

ORA-00289: öneri: /opt/oracle/product/10gR2/dbs/arch/1_2_649864014.dbf

ORA-00280: 347898987 numaralı değişiklik (1 thread’i için), 2 numaralı sırasında

Günlüğü belirtin: {<RET>=önerilen | dosya adı | AUTO | CANCEL}

CANCEL

6) Kurtarma işlemi tamalanmıştır. veritabanının RESETLOG parametresi ile
açılması gerekmektedir. Çünkü çöken sisteme ait son Online Redo Log dosyaları
elimizde yoktur. “Cold Backup” tan gelen Online Redo Log dosyaları kurtarılmış
veritabanıyla uyumsuzdur.

SQL> ALTER DATABASE OPEN RESETLOGS;

Artık veritbanı kutarılmıştır. Burada dikkat edilmesi gereken bir husus da,
çöken sistemden Online Redo Log dosyaları alınamadığından ve bu Online Redo Log
dosyalarının içinde bulunan ve arşivlenmemiş işlemler olduğundan, bu
arşivlenmemiş işlemler kaybedilmiş olacaktır. Online Redo Log dosyalarının
boyutları bu yüzden önem kazanmaktadır. Büyük boyutlu olması “Log switch”
işleminin ve Arşivleme işleminin daha az olmasını sağlarayarak performans artışı
getirirken, Kurtarma durumlarında daha fazla bilginin kaybolmasına sebep
olmaktadır. Bu yüzden Online Redo Log dosyalarının boyutlarının ayarlarken bu
konuya da dikkat edilmesi gerekir.

Cold Backup alabilmek için veritabanının kapatılması gerekmektedir. Kapatma işlemi “ABORT” yöntemiyle yapılmamalıdır. Diğer kapatma yöntemlerinden herhangi biri kullanılabilir(NORMAL,IMMEDIATE,TRANSACTIONAL).

Veritabanı kapatıldıktan sonra veritabanına ait dosyalar(datafiles, controlfiles ve online redo logs) işletim sistemi komutlarıyla yedeklenir. Hangi dosyaların yedekleneceği aşağıdaki sorgular veritabanı açıkken çalıştırılarak öğrenilebilir.

Datafiles : select name from v$datafile

Controlfiles : select name from v$controlfile

Online Redo Logs : select member from v$logfile

Yukarıdaki yedeklenmesi zorunlu olan dosylar haricinde , istenirse init.ora, spfile, listener.ora,tnsnames.ora gibi daha sonradan da oluşturulabilecek dosyalarda yedeklenebilir.

Yedekleme işlemini yapan bir örnek scripte aşağıdaki linkten erişilebilir.

http://www.adp-gmbh.ch/ora/admin/backup_recovery/coldbackup_sh.html

Fiziksel Bekleme Veritabanı (Physical Standby Database) : Birincil veritabanın birebir kopyasının ikincil veritabanında tutulmasıdır. İkincil veritabanı birincil veritabanın birebir kopyası olarak hazırlanır, birincil veritabanında oluşan arşiv geridönüşüm loglarının ikincil veritabanına uygulanması ile eşitlik sağlanmış olur. Fiziksel Bekleme Veritabanları açık veritabanları değillerdir. Startup Mount komutu ile açılırlar. birincil veritabanından gelen loglar Veritabanı Kurtarma(Database Recover) mantığıyla ikincil veritabanına işlenir. İstenirse ikincil vertabanı salt-okunur olarak açılabilir, fakat bu süre zarfında loglar işlenmez, biriktirilir. Tekrar işleme moduna alınarak logların işlenmesine devam edilebilir. Fiziksel Bekleme Veritabanları çoğunlukla felaket durumda kurtarma(disaster recovery) amaçlı olarak kullanılırlar. Felaket durumunda birincil veritabanının yerine geçecek olan veritabanı budur. böylece veri kaybı olmadan ve süre kaybetmeden kurtarım yapılmış olur.

Mantıksal Bekleme Veritabanı (Logical Standby Database) : Birincil veritabanının mantıksal olarak bir kopyasıdır, yani tablolar ve indexler gibi nesneler aynıdır fakat datafile dosyalarının düzeni farklılık gösterebilir. Birincil veritabanından gelen loglar SQL cümleciklerine çevrilerek işlenirler. Veritabanı açıktır, yani veritabanı üzerinde raporlama işlemleri yapılabilmektedir.Mantıksal veritabanına ait birtakım kısıtlamalar vardır. Bazı veri tipleri desteklenmemetedir. Ayrıca sistemdeki eşleşecek tabloların birincil anahtar indeksinin olması gerekmektedir. Oluşturulan SQL cümlecikler bu birincil anahtarlar kullanılarak işlenmektedir. Mantıksal veritabanları hem yedekleme için kullanılırlar hem de açık veritabanı oldukları için raporlama gibi işlemlerde de kullanılırlar. Böylece birincil veritabanının üzerinden yük alınarak performans artışı sağlanmış olur.

Oracle Data Guard 3 farklı koruma seviyesi sunar. Bunlar :

• Maksimum Koruma : Bu seviyede hiçbir veri kaybı olmaması sağlanır. Birincil veritabanında oluşan redo log dosyası eş zamanlı olarak en ez bir ikincil veritabanına kopyalanıp işlenemelidir. Eğer bir sorun olur da ikincil veritabanına işlenemez ise birincil veritabanı kapatılır.
• Maksimum Kullanılabilirlik : Bu seviye de maksimum korumada olduğu gibi sıfır veri kaybı hedeflenir, fakat hata durumunda veritabanı kapatılmaz, commit işlemi yapılmaz. hata düzelene kadar maksimum performans
  seviyesine geçilir. böylece veritabanının devamlılığı sağlanır. Hata düzeldikten sonra tekrar maksimum kullanılabilir seviye geçilir.
• Maksimum Performans : Bu seviye varsayılan seviyedir ve birincil veritabanın performansında azalma olmadan koruma sağlar. Birincil veritabanında işlem commit edilir ve online redo log dosyasına yazılır. Bu redo loglar eşzamansız olarak ikincil veritabanına aktarılır ve işlenir. Log dosyalarının aktarılmasında sorun olursa sorun düzeldikten sonra kalınan yerden işleme devam edilir.

Donanımsal ve Yazılımsal gereksinimler : Sistemler aynı platformlara sahip olmalıdırlar. Örneğin 32-bit intel Linux sisteme sahip olabilirler. Donanımsal olarak bir kısıt yoktur. Farklı sayıda işlemci , ram disk birimlerinden oluşabilirler. Oracle veritabının enterprise sürüm olması ve sürümlerinin aynı olması gerekmektedir. Standart sürümde çalıştıralamamaktadır. Birincil Veritbanının ARCHIVELOG modunda çalışması gerekmektedir. Bütün sistemlerde COMPATIBLE parametrelerinin aynı olması gerekmektedir.

• Fiziksel Bekleme Veritabanının Oluşturulması :
  Fiziksel bekleme vertabanı oluşturulmadan önce birincil veritabanında birtakım ayarlar ve kontrollerin yapılması gerekir. Bunlar :
  • Force Logging ayarının açılması :
    Aşağıdaki komutla birlikte veritabanın geçici Tablespace’lerin haricindeki tüm aktivitelerin loglanması sağlanır. Bu komuttan sonra NOLOGGING olarak ayarlanmış nesnelerde loglanmaya başlanır. Böylelikle bütün aktivitelerin log dosyalarına yazılması ve ikincil veritabanlarına uygulanması sağlanmış olur.

  
  SQL > Alter Database force logging;

  • Standby Redo Log oluşturulması :
    Maksimum Koruma ve Maksimum Kullanılabilirlik seviyelerinin kullanılabilmesi için Standby Redo Logların oluşturulması gerekmektedir. Maksimum performans seviyesinde zorunlu değil fakat kullanılması performans ve koruma açısından fayda sağlar. Standby Redo Log dosyaları bekleme modundanki veritabanlarında çalışırlar. Bekleme
    modunda çalışma için dizayn edildiklerinden online redo loglara veya
    arşinvenmiş loglara göre daha fazla koruma sağlarlar. Oluşturulacak olan
    Standby Redo Logların boyutlarının mevcut Online Redo Logların
    boyutlarıyla aynı olması gerekmektedir. Aşağıda bir Standby Redo Log
    dosylarının oluştrulması gösterilmiştir.SQL>
    ALTER DATABASE ADD STANDBY LOGFILE GROUP 10
    (‘/oracle/dbs/log1c.rdo’,'/oracle/dbs/log2c.rdo’) SIZE 500M;

  Standy Redo Loglar ikincil veritabanlarında çalışırlar. Birincil veritabınında oluşturulması şartı yoktur. Fakat birincil ve ikincil veritabanlarının yer değiştirilmesi(switchover) işlemlerinden sonra düzgün çalışılabilmesi için birincil vertabanında da aynı şekilde Standby Redo Logların oluşturulması yararlı olacaktır. Aşağıdaki sorgu sistemdeki Standby
  Redo Logların durumu gösterir.

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

  	GROUP#     THREAD#    SEQUENCE#  ARC STATUS
  
   ---------- ---------- ---------- --- ----------
  
            3          1         16 NO  ACTIVE
  
            4          0          0 YES UNASSIGNED
  
            5          0          0 YES UNASSIGNED

  • Birincil Veritabanında Başlangıç Parametrelerinin
    Oluşturulması : Birincil veritabanında oluşan log dosyalarının ikincil veritabanlarına aktaramıyla ilgili parametreler oluşturulacaktır. Bunun yanında zorunlu olmasa da , daha sonra
    veritabanlarının rol değiştirmesi (switchover,failover işlemleriyle) gerekli olan , birincil veritabanının ikincil veritabanı olarak çalışması ile ilgili ayarlar da yapılacaktır. Aşağıdaki hem birincil hem de ikincil veritabanlarına ait ayırıcı bilgiler bulunmaktadır. Bu bilgiler parametrelerde kullanılacatır.

  Veritabanı	DB_UNIQUE_NAME*	Oracle Net Service Name
  Birincil(Primary)	istanbul	istanbul
  İkincil(Secondary)	ankara	ankara

  * DB_UNIQUE_NAME parametre değişkenin her veritabanı için farklı
  olan, log transfer ayarlarında kullanılan bir değişkendir. Veritabanlarının log transferi seviyesinde birbirlerinden ayrılmalarını sağlar.

  Aşağıda birincil veritabanına ait bir başlangıç parametleri gösterilmektedir.

  DB_NAME=istanbul
  DB_UNIQUE_NAME=istanbul
  LOG_ARCHIVE_CONFIG=’DG_CONFIG=(istanbul,ankara)’
  CONTROL_FILES=’/opt/oracle/product/10gR2/dbs/control1.ctl’,
  ‘/opt/oracle/product/10gR2/dbs/control2.ctl’
  LOG_ARCHIVE_DEST_1=
  ‘LOCATION=/opt/oracle/product/10gR2/archive/
  VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
  DB_UNIQUE_NAME=istanbul’
  LOG_ARCHIVE_DEST_2=
  ‘SERVICE=ankara LGWR ASYNC
  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
  DB_UNIQUE_NAME=ankara’
  LOG_ARCHIVE_DEST_STATE_1=ENABLE
  LOG_ARCHIVE_DEST_STATE_2=ENABLE
  REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
  LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
  LOG_ARCHIVE_MAX_PROCESSES=30
  

  Yukarıdaki parametrelerin oracle başlangıç paremetre dosyasına yazılması gerekir. Öncelikle mevcut sistemdeki SPFILE bir dosyaya yazılır. Oluşturulan bu dosyaya yukarıdaki parametreler
  eklenir(Control_files parametresi zaten mevcuttur.) ve bu dosya kullanılarak yeni SPFILE oluşturulur.

Yukarıdaki parametrelerde LOG_ARCHIVE_DEST_1 parametresi sistemdeki online redo logların nereye arşivleneceğini belirtiyor. LOG_ARCHIVE_DEST_2 ise ikincil veritabanı hakkında bilgiler içeriyor.”SERVICE=ankara” parametresi logların ankara veritabanına aktarılacağını,”LGWR” aktarma için LGWR yönteminin kullanılacağını (ARCH da olabilir di) ,”ASYNC” ise aktarmanın eşzamansız olduğunu belirtiyor. Bu parametreler daha önce bahsettiğimiz 3 farklı koruma seviyesinden hangisinin kullanılacağını belirler.

• Birincil Veritabanınında Log Arşivlemenin Ayarlanması : Eğer birincil veritabanında log arşivleme etkin değilse aşağıdaki komutlar ile etkin hale getirilmelidir.

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE ARCHIVELOG;

SQL> ALTER DATABASE OPEN;

Artık birincil veritabanı hazır hale geldi. bundan sonraki ilk işlem birincil veritabanına ait bütün datafile dosyalarının , Online Redo Logları ve oluşturulan Standby Redo Logların
ikincil veritabanına kopyalanmasıdır. dosyalar ikincil veritabanına kopyalandıktan sonra birincil veritabanından controlfile ve initfile bilgileri aşağıdaki sorgularla alınır ve ikincil veritabanına işlenir.

• İkincil Veritabanı için Controlfile Dosyasının oluşturulması : İkincil veritbanına birincil veritabanına ait controlfile dosyalarının alınıp birebir kopyalanması hatalıdır. Bekleme modundaki ikincil veritabanı için önce birincil veritabanında “Standby Controlfile” oluşturulmalıdır.

SQL > STARTUP MOUNT;

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/tmp/ankara.ctl’;

Oluşturulan bu dosya ikincil veritabanına kopyalanmalıdır. Kopyalama SCP ve FTP kullanılarak yapılabilir.

ikincil veritabanın da kontrol dosyalarının ‘/opt/oracle/product/10gR2/dbs/control1.ctl’ ve
‘/opt/oracle/product/10gR2/dbs/control2.ctl’ olduğunu, istanbul
bilgisayarının ip adresinin ankara bilgisayarındaki /etc/hosts
dosyasına tanımlı olduğunu varsayarsak aşağıdaki scp komutları
ile kontrol dosyları kopyalanmış olur.

ankara # scp istanbul:/tmp/ankara.ctl
/opt/oracle/product/10gR2/dbs/control1.ctl;

ankara # scp istanbul:/tmp/ankara.ctl /opt/oracle/product/10gR2/dbs/control2.ctl;

• İkincil Veritabanında Başlangıç
  Parametrelerinin Oluşturulması : İkincil
  veritabanının başlangıç parametreleri birincil veritabanına göre
  biraz farklılık gösterir.

DB_NAME=ankara
DB_UNIQUE_NAME=ankara
LOG_ARCHIVE_CONFIG=’DG_CONFIG=(istanbul,ankara)’
CONTROL_FILES=’/opt/oracle/product/10gR2/dbs/control1.ctl’,
‘/opt/oracle/product/10gR2/dbs/control2.ctl’
LOG_ARCHIVE_DEST_1=

‘LOCATION=/opt/oracle/product/10gR2/archive/

VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

DB_UNIQUE_NAME=ankara‘
LOG_ARCHIVE_DEST_2=

‘SERVICE=istanbul LGWR ASYNC

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)

DB_UNIQUE_NAME=istanbul‘

LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=30

Buradaki LOG_ARCHIVE_DEST_1 ve LOG_ARCHIVE_DEST_2
ikincil veritabanı birincil veritabanına çevrilirse çalışacaktır.
İkincil veritabanında bu parametreler çalıştırılmaz.

Bu ayarlar yapıldıktan ve spfile dosyası yukarıda
anlatıldığı gibi oluşturulur.

Veritabanları başlatılmadan önce Oracle Net
ayarlarının yapılması gerekmektedir. aşağıda birincil ve ikincil
veritabanına ait TNSNAMES.ora dosyası vardır.

ankara =(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = ankara)(PORT = 1521)))(CONNECT_DATA =(SERVICE_NAME = FINANS))) istanbul =(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = istanbul)(PORT = 1521)))(CONNECT_DATA =(SERVICE_NAME = FINANS)))

işletim sisteminde her iki bilgisayarda
ping ankara ve ping istanbul
komutlarının başarılı olması gerekmektedir. Başarılı değil ise linux
sistemlerde /etc/hosts dosyasında gerekli tanımların yapılması
gerekmektedir.

Artık her iki veritabanı başlatılabilir. Birincil
veritabanı ALTER DATABASE OPEN; komutuyla açılarak kullanıma
başlanabilir. daha sonra listener hizmetinin açılması gerekir.

istanbul # lsnctrl start;

İkincil veritabanı ise STARTUP MOUNT;
komutuyla açılmalıdır. Daha sonra gelen log dosyalarının işlenmesini sağlamak için aşağıdaki komut çalıştırılır.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE DISCONNECT FROM SESSION;

Artık yedekleme işlemi başlamış durumdadır.

birincil veritabanında

SQL> alter system switch logfile;

Komutu ile bir arşiv log dosyası oluşturulur ve bu dosyanın
ikincil veritabanına ulaşıp ulaşmadığı ve işlenip işlenmediği
aşağıdaki komutla test edilebilir.

İkincil veritabanında :

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

SEQUENCE# APP

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

        8 YES

        9 YES

       10 YES

       11 YES

Birincil veritabanında aşağıdaki sorgu
çalıştırılarak sistemin işleyip işlemediği, var ise hatanın sebebi
görülebilir.

SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE STATUS
<> ‘DEFERRED’ AND STATUS <> ‘INACTIVE’;

DRCP nin kullanılması için Veritabanı ve Uygulama Katmanlarında yapılması gereken değişiklikler şunlardır :

1. Veritabanı Katmanı :

Pool(Havuz) Özelliğinin Kullanıma açılması ve Ayarlanması : DRCP basit bir kullanıma sahip olan API ile yönetilebilmektedir. Her 11g vertabanı anının (instance) varsayılan bir havuzu mevcuttur. Bu havuz aşağıdaki örnekteki gibi ayarlanabilmektedir.

Yukarıdaki komut ile birlikte varsayılan ayarların değiştirilmesi sağlanabilir. bu komut kullanılmaz ise varsayılan ayarlar geçerli olacaktır.

Aşağıdaki komut ile “Havuz” özelliği başlatılır ve istemciler bu özellikten yararlanmaya başlamaları sağlanmış olur.

Yukarıda komut çalıştırıldıktan sonra , veritabanı her açılışında bu özellik ile birlikte açılır. eğer bu özelliğin kapatılması istenirse aşağıdaki komut çalıştırılmalıdır.

2. Uygulama Katmanı :

Uygulama bağlantılarının DRCP ye yönlendirilmesi :

Bağlantı cümleciklerinde SERVER=POOLED kullanırak DRCP özelliğinin kullanılmak istendiği belirtilir.

Bu düzenlemelerden sonra PHP veritabanı bağlantı istekleri Oracle 11G tarafından yönetilen bir havuz tarafından sağlanacak ve otomatik olarak yönetilecektir. Oracle 11G nin sağladığı bu özellik sayesinde PHP gibi betik lisanlarının yüksek hacimli projelerde kullanılabilmesinin yolu açılmış olmaktadır.