Sühan Erol (Oracle+PHP)

Mart 25, 2009

PHP ile OCI Client Result Cache (Sorgu sonuçlarının İstemci(webserver) tarafında tutulması)

Filed under: Oracle,PHP — suhanerol @ 8:38 pm
Tags:

İstemci tarafında sorgu sonuçlarının tutulması(result caching) Oracle 11g nin sunduğu yeni özelliklerden biridir. Bu özellik OCI (Oracle Call Interface) teknolojisini kullanan uygulamalar ve sürücüler tarafından kullanılabilmektedir. Bu makalede PHP özelinde incelenen konu OCI teknolojisini kullanan diğer programlama lisanlarında da geçerlidir.

(more…)

Mart 24, 2009

Ubuntu Linux üzerinde PHP , OCI8 ve Oracle Instant Client Kurulumu

Filed under: Oracle,PHP — suhanerol @ 9:55 am

Bu makale ile, günümüzün en yaygın ve kullanışlı linux dağıtımlarından olan Ubuntu üzerinde Oracle bağlantı destekli PHP kurulumu anlatılarak bir sonraki  “PHP ile ‘OCI Client Result Cache’  (Sorgu sonuçlarının İstemci(webserver)  tarafında tutulması)”  konulu makalenin uygulanabilmesi için hazırlık yapılması amaçlanmıştır.

(more…)

Temmuz 28, 2008

Oracle Analitik Fonksiyonlar

Filed under: Oracle — suhanerol @ 7:14 pm
Tags:

Oracle analitik fonksiyonlarında temel prensip bu fonksiyonların sorgu sonuç bilgilerinin üzerinde çalıştırılmasıdır. Analitik fonksiyonlar içeren bir sorguda önce ” where , joinler , group by, having ” çalıştırılır, daha sonra analitik fonksiyonlar sonuçlar üzerinde çalıştırılır , en son olarakta “order by ” çalıştırılır. Analitik fonksiyonlar “View, alt sorgu” kullanımı gerektiren bir çok sorguda bu gereksinimi ortadan kaldırarak çok büyük performans artışı sağlamaktadır. Bu durumu bir örnekle gösterelim.

(more…)

Mart 20, 2008

ORACLE DA CONTROLFILE VE ONLINE REDO LOG DOSYALARI OLMADAN COLD BACKUP VE ARCHIVE LOGLAR İLE KURTARMA(RECOVERY)

Filed under: Oracle — suhanerol @ 12:27 pm
Tags: , , ,

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.

ORACLE’DA COLD BACKUP İLE YEDEKLEME

Filed under: Oracle — suhanerol @ 8:17 am
Tags:

“Cold Backup” taki amaç veritabanına ait bütün bilgilerin yedeklenerek daha sonra oluşabilecek hatalardan kurtartarma işlemi bir başlangıç noktası oluşturmaktır. Cold Backuptan sonra oluşan “Archive Log” dosyaları kullanılarak kurtarma işlemi yapılabilmektedir.

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

Mart 17, 2008

ORACLE DATA GUARD KAVRAMLAR KURULUM YÖNETİM -1-

Filed under: Oracle — suhanerol @ 9:09 pm
Tags:

Oracle Data Guard , Oracle’da yüksek erişilebilirlik ve beklenmeyen sistem hataları neticesinde oluşabilecek veri kayıplarını en aza hatta sıfıra indiren oracle veritabanı ile bütünleşik bir veri koruma eklentisidir. Oracle enterprise sürümü gerektirir.Bütünleşiktir, ek kurulum gerektirmez. Veri tabanı hizmeti veren birincil sisteme (Primary) ek olarak bir veya daha fazla yedek (Secondary) sistem veya sistemlerin eş zamanlı veya eş zamanlı olmayan şekilde eşleştirilmesi prensibiyle çalışır. Çalışma prensibi , birincil veritabanında oluşan arşivlenmiş geridönüş loglarının (Archived Redo Logs) ikincil veritabanına aktarılması ve bu logların iki farklı yöntemle ikincil veritabına işlenmesine dayanır. Logların ikincil veritabanına işlenmesi yöntemi eşitlemenin fiziksel(Physical) mi mantıksal(Logical) mı olduğunu belirler. bu iki farklı
işletim temel farklılıklar getirir. Sistemler birbirleriyle “Oracle Net” ile haberleşirler. Sistemler aynı ortamda veya uzak mesefalerde olabilirler. Sistemlerin yerleşimleri ile ilgili bir kısıtlama yoktur.

(more…)

Oracle DRCP (Database Resident Connection Pooling) ile PHP için Connection Pooling

Filed under: Oracle,PHP — suhanerol @ 2:55 pm
Tags:

Oracle 11G ile birlikte gelen yeni özelliklerden biri de DRCP (Database Resident Connection Pooling) dir. Klasik 3 katmanlı mimarinin avantajlarından biri olan connection pooling(bağlantı havuzu) özelliğinin PHP gibi “Çalış ve sonunda bütün kaynakları kapat” mantığı ile çalışan betik lisanlarında bulunmaması veya 3ncü parti yazılımlarla giderilmeye çalışılsa da yeterli ve düzgün çalışır olmaması sorunu PHP gibi lisanların büyük hacimli projelerde tercih edilmemesine sebep olmaktadır. Bir uygulamanın en maliyetli kısmı veritabanına bağlantı ve yeni bir oturum açılması bölümüdür. Java gibi üst düzey uygulama geliştirme ortamları “Hibernate” gibi uygulama katmalarının “Connection Pooling” özellikleriyle bu sorunu çözmüşlerdir. DRCP ile birlikte Oracle 11g’de bu sorunun çözümü amaçlanmıştır.

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.

SQL>execute
dbms_connection_pool.configure_pool(null, minsize=>10,
maxsize=>100,
inactivity_timeout=>300,
max_think_time=>600, …);

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.

SQL>execute dbms_connection_pool.start_pool;

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.

SQL>execute dbms_connection_pool.stop_pool;

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.

    dbserver.deneme.com:1521/finans:POOLEDYada(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=dbserver.deneme.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=finans)(SERVER=POOLED)))

    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.

    WordPress.com'da ücretsiz bir web sitesi ya da blog oluşturun.