16 Temmuz 2009 Perşembe

Oracle Görevleri Sonlanıyor!..

Merhaba,

Oracle'da pek sık rastlanmasa da birgün başımıza gelme olasılığı yüksek ancak geldiği zaman da son derece can sıkıcı olabilen bir hatadır Oracle görevlerinin zamanla sonlanması.

Örneğin 10gR2 veritabanımız var ve job_queue_process parametremiz de 50 olarak tanımlanmış. Bir takım görevler yaratıyoruz ve bu görevler rutin olarak her gece, her saat ve hatta her dakika çalışıyor. Ancak birgün bakıyorsunuz ki, tanımladığınız görevler 2 gündür çalışmıyor! Elle çalıştırıyorsunuz, o zaman çalışıyor ama otomatik olarak tetiklenmiyor. Hemen dönüp unix sisteme "ps -ef grep ora" yazıyorsunuz ve karşınıza hiç "ora_j001" ya da "ora_j***" tipinde çıktılar gelmiyor. Bütün arka planda çalışan görevleriniz şu anda ölmüş durumda! Şunu da belirtmeliyim ki bu sorun 9i ve 10g'de ortaya çıkmaktadır ve herhangi bir OS platformunda gerçekleşebilir.

Yapılabilecek çözümleri sıralıyorum;

1) Veritabanınız restricted modda olabilir mi?
select instance_name, logins from v$instance;
eğer logins=restricted ise:
alter system disable restricted session;

2) job_queue_processes > 0 mı?
show parameter job_queue_processes;
job_queue_processes parametresi 0 ise hiçbir görev çalışmayacaktır.

3) _system_trig_enable=false durumda mı?
select a.ksppinm parameter,b.ksppstvl value from x$ksppi a,x$ksppcv bwhere a.indx=b.indx and ksppinm='_system_trig_enabled';
eğer bu değer "false" ise:
alter system set "_system_trig_enable"=TRUE scope=both;

4) Görev kullanım dışı olmuş olabilir mi?
select job, broken, from dba_jobs where job=;
eğer kullanım dışı kalmış ise, alert log dosyasını ve trace dosyalarını incelemenizde fayda olacaktır.

5) Görev commit edilmiş mi?
Yarattığınız görevin script'inin içinde commit; aşaması yoksa, eklemeniz gerekebilir.

6) UPTIME > 497 ?
eğer OS uptime parametresi 497'den büyükse bu bir bug olabilir.(Metalink unpublished bug: 3427424)

7) DBA_JOBS_RUNNING
select * from dba_jobs_running;
görevin koşup, koşmadığına bakabilirsiniz.

8) LAST_DATE ve NEXT_DATE
select Job,Next_date,Last_date from dba_jobs where job=;
last_date ve next_date değerleri anlamsız olabilir.

9) NEXT_DATE ve INTERVAL
select Job,Interval,Next_date,Last_date from dba_jobs where job=;
Bu değerin de doğru olup olmadığını incelemek gerekiyor.

10) JOB_QUEUE_PROCESSES
En mantıklı ancak geçici sonuç olarak:
alter system set job_queue_processes = 0 scope=both;
alter system set job_queue_processes = 10 scope=both;
yaparsak eğer, bütün görevler baştan ve otomatik olarak başlayacaktır. Bu işleme CJQ işleminin yeniden başlatılması da denebilir.

11) DBMS_IJOB
Veritabanını yeniden başlatabilir ya da:
exec dbms_ijob.set_enabled(true); yapabilirsiniz.

Bu arada yukarıda sıralanmış bilgiler metalink'te 313102.1 döküman id'si aratılarak İngilizce olarak bulunabilir.

Bu durumda da hala otomatik olarak çalışmıyorsa -ki 10nuncu maddeden sonra çalışması gerekiyor- mutlaka ve mutlaka SR (Service Request) açmanız gerekiyor. SR aşamasında oluşan trace dosyaları ve alert dosyasını da isteyebilirler, muhafaza edilmesi çok önemli.

İyi akşamlar,

Ogan

18 Haziran 2009 Perşembe

OPTIMA

Merhaba,

Yaklaşık 8 aydır Aircom firmasının ( www.aircominternational.com ) OPTIMA ürünü ve Oracle üzerine çalışıyorum. Oracle ile ilgili zaten biliyorsunuz, ancak OPTIMA bana yeni bir ürün bana.

OPTIMA bir çeşit performans yönetim aracı ve yazılımı. Ericsson'da ENIQ yani Ericsson Network IQ kullanılıyor ve bu ürünle beraber sybase kullanılıyor.

OPTIMA hem fixed hem de wireless hatlar için kullanılabiliyor. Hat üzerindeki ve cihazlardaki (SDH, Santral, Mini-link gibi) performans verilerini toplayıp, manipüle eden ve Oracle veritabanında saklayan bir araç.

Optima ile ilgili sormak istedikleriniz, takıldığınız noktalar, bilmek istedikleriniz vs. sorularınız olursa sorabilirsiniz. Türkiye'de henüz çok fazla kullanılmayan ancak gün geçtikçe yaygınlaşan, 15 yıldır üzerine çalışılan ve geliştirilen bir üründür.

İyi akşamlar,

Ogan

06 Mayıs 2009 Çarşamba

ORA-12549 Çözümü Mevcut!

Merhabalar,
Çok sıklıkla gerçekleşmese de, kısmen büyük çaptaki veritabanların başına gelebilen bir hatadır ORA-12549 hatası.
Veritabanına bağlanmak istediğiniz zaman ise şu şekilde hatalar alabilirsiniz;

ORA-12549: TNS: operating system resource quota exceeded
TNS-12518: TNS:listener could not hand off client connection
Ve veritabanına bağlanmanız reddedilir. İlk bakışta sıradan bir Oracle hatası ya da TNS hatası gibi gözüksede aslında bu bir İşletim sistemi kernel parametresi hatasından kaynaklanmaktadır.
Unix tabanlı işletim sistemlerinde bildiğiniz üzere belirli bir dökümantasyona göre Oracle kurulumları gerçekleştirilir, gerçekleştirilmesi tavsiye edilir. Gerçekleştirilmediği durumlarda ise, bir takım eksikliklerle Oracle veritabanı kurulacaktır ve ileride bir zaman karşınıza hata çıkma ihtimali olacaktır. Bu tarz işletim sistemlerinde kernel parametreleri vardır ve bağlı olan kullanıcılar ile ilgili işletim sistemi bazında bilgiler ve tanımlamaları içerir. Bu tanımlamalar belirli sayılarla temsil edilebilir.
Kernel parametrelerinin arasında "maxuproc" isimli bir parametre vardır. Default olarak 256 olarak belirlenir. Bu parametre her bir kullanıcı için azami işlem sayısını belirler. Oracle işletim sisteminden işlem tüketmek istediği zaman bu sayı sürekli artar ve 256'ya dayandığı zaman sisteme bağlantı dahil, veritabanı girişleri de sonlanabilir. Oracle'ın kurulum dökümantasyonlarında bu kernel parametrelerinin tavsiye edilen sayılarını görebilmek mevcut.
Bu parametreyi değiştirebilmek için root kullanıcısı ile bağlanmak şart. root ile bağlandıktan sonra "sam" yazarak parametremizi ayarlayacağımız Unix programına giriyoruz. Ardından "k" tuşuna basarak kernel parametrelerinin ayarlanması işlemine başlıyoruz. "Tunables" başlığının altında bir dizi parametre göreceksiniz. Burada "maxuproc" parametresini görebilirsiniz. Ayarlama olaraksa "(nproc*9)/10" yazarsanız, toplam nproc (işlem sayısı) sayısının %90'ını alabilir kullanıcılar demiş olursunuz. Bu sayede Oracle kullanıcınız daha fazla işlem tüketebilecek ve işlem sınırlamasından dolayı veritabanınız geçici süre kullanım dışı kalmayacaktır.
Unix/Linux işletim sistemlerine kurulum yaparken eğer kernel parametrelerinin kontrolünü atlarsanız kurulum aşamasında sorunlarla karşılaşmayabilirsiniz ancak ileride oluşabilecek sorunları da kabul etmiş olursunuz. Proaktif bir veritabanı yöneticisi olmak istiyorsanız ve sonradan başınızın ağrımasını istemiyorsanız unix tabanlı işletim sistemlerine Oracle veritabanı kurulumu yaparken mutlaka, mutlaka kernel parametrelerini kontrol edin!
maxuproc ile ilgili olarak google'da bir takım kısa çözümler mevcut. Örneğin;
Action: Acquire more operating system resource, or perform a different function.
Çok kısa ve anlaşılmayan bir çözüm değil mi? Daha fazla işletim sistemi kaynağı ayırmak ya da başka bir fonksiyon uygulamak ne demektir? Yukarıda yazdıklarımın çok fazla özeti olarak düşünüyorum ve maxuproc'u değiştirin diyorum :)
İyi akşamlar,
Ogan

18 Nisan 2009 Cumartesi

Acı ama gerçek, ORA-00600

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. Üzerinizdeki baskı gittikçe artacağı için google'a hiç bulaşmamanızı tavsiye ederim. Sıradan bir hata olmadığı için google size cevap veremeyecektir. Dolayısıyla önce metalink, eğer çözüm bulamadıysanız mecbur ticket açacaksınız ve Oracle'dan cevap bekleyeceksiniz YA DA veritabanının yedeğinden dönmeye razı olacaksınız :)

Geçtiğimiz günlerde ben de bir ORA-00600 hatası ile uğraştım ve gerçekten zor anlar yaşadım. Zor anlar yaşamamın sebebi aslında yöneticiliğini yaptığım veritabanının banka veritabanı olmasından değil, birazcık sorumluluk sahibi olduğumdan diyebiliriz. Bütün bir gün boyunca veritabanının çalışmamış olması, otomatik olarak bağlanan client'larımızın çalıştığı hpux makineyi biraz daha yormasına sebep olmaktan başka bir işe yaramayacaktı. Evet, biraz stresimi azaltan bir durumdu :) Asıl beni germiş olan durum ise, test veritabanında olduğumuz ve ne yazık ki veritabanının hiçbir yedeğinin veya dump'ının olmaması. Hatta ve hatta veritabanı archivelog'da bile değildi :) Nasıl diyelim, kötü ve mutlak mağlubiyetle sonlanacak bir futbol maçı gibi. Sonradan yer sağlandı ve veritabanının archivelog'a geçirip, RMAN ile yedeğini alır hale geldik neyse ki.

Konumuza dönersek eğer, aldığım hata şöyleydi;

ORA-00600: internal error code, arguments: [kksfbc-reparse-infinite-loop],[ ],[ ],[ ],[ ],[ ]

Burada dikkat etmeniz gereken ilk şey, gelen ilk argümandır. Bu argüman, aslında hatanın nerede olduğunu ve doğal olarakta nasıl çözüleceğini anlatmaktadır. Sonrasında gelen argümanlar ise, problemi daha da detaylandırmakta kullanılmaktadır.

kksfbc-reparse-infinite-loop argümanı ile ne zaman karşılaşırsınız? Bu argüman çıktığı zaman ne yapmalısınız? Ben size burada yazacağım ve metalink ile uğraşma zahmetinden kurtaracağım.

Bu hatayı aldığınız zaman başınıza gelen şey aslında şudur; Veritabanındaki önemli şemalarda, örneğin SYS, SYSTEM, DBSNMP gibi INVALID objeler, yani hatalı, bozuk veya çalışmayan objeler olduğu anlamına gelmektedir. Paniğe gerek yok, bunu toparlamak için Oracle bize bir sql vermiştir ve bu sql damarlarındaki asil kanda mevcuttur :) $ORACLE_HOME/rdbms/admin folder'ının altında UTLRP.SQL isimli bir script bulunmaktadır. Bu script veritabanınızdaki bütün invalid objeleri valid hale getirmeye yaramaktadır. Şu şekilde çalıştırabilirsiniz;

@$ORACLE_HOME/rdbms/admin/utlrp.sql

Çalıştırdıktan sonra karşınıza 4 tane sql sorgusu ve neye yaradıklarını anlatan bir çıktı gelecektir. Başka bir terminal ile bağlanıp, bu sorguları takip edebilir ve scriptininiz ne kadar başarılı olduğunu görebilirsiniz. 2-3 defa çalıştırdığınız takdirde de hiçbir invalid obje kalmayacaktır. Yani bir defa çalıştırıp ohh kurtuldum diyerek rahatlamayın :)

Bu script'in en büyük ve tehlikeli impact'i kesinlikle şudur; sonuç olarak bu bir PL/SQL scripti'dir ve belirli paketler sayesinde çalışmaktadır. Eğer SYS şemanızdaki DBMS_UTILITY paketi invalid olduysa, bu scriptte çalışmayacaktır. Yine paniğe gerek yok, kurtarabilmenin bir yolu daha var. Ancak bu durumu düştüğünüzde kullanabilirsiniz.

$ORACLE_HOME/rdbms/admin folder'ının altında CATUPRGD.SQL isimli bir script var ve bu script yeni bir sürüm için katalog yükseltmesi yapmaktadır. Oracle tarafından internal olarak çağırılır. Kullanımı silent, yani responsefile ile grafik olmadan yapılan kurulumlardan sonra bir upgrade yapılmışsa, veritabanının kataloğunu da o sürüme yükseltmek içindir. Bu scripti çalıştırdıktan sonra sizden utlrp'yi çalıştırmanızı isteyecektir. Çünkü katalog yükseltmesi sırasında da invalid objeler oluşabilir.

Bütün bu yapılanlardan sonra hiçbir şemanızda invalid obje bulunmayacaktır ve veritabanını abort dışında bir yöntem ile kapatın ve temiz olarak açın. Probleminiz gitmiş olacaktır. Birgün boyunca alert_oraclesid.log dosyasını incelemeye (tail -f) devam ederseniz faydalı olacaktır.

İyi akşamlar,

Ogan

Automatic Workload Repository

Merhaba,

Automatic Workload Repository, Oracle 10g Enterprise Edition ile gelen bir özellik olup, Oracle 8i versiyonu ile tanıtılan STATSPACK'in yerini almıştır. Amacı veritabanı yöneticisinin günlük aktivitelerini ve yaşamını kolaylatması olarakta düşünülebilir. AWR, veritabanının anlık veya belirli bir dönemdeki snapshot'ını alarak çalışır. Bu snapshot ile veritabanı yöneticisinin önüne performans bilgileri, en çok kaynak harcayan SQL sorgularının listesi, veritabanındaki obje kullanımı hakkında detaylı bilgi gibi somut kaynakları listeler. AWR raporlarının toplandığı uygulamaya da ADDM (Automatic Database Diagnostic Monitor) denir ve yine 10g ile birlikte çıkarılmıştır. ADDM AWR snapshotları alındıktan sonra yine 10g veritabanı tarafından otomatik olarak güncellenir.

AWR veri kaynağını MMON arkaplan görevinden alır ve bilgilerini sysaux tablespace'inde barındırır.

AWR 10g veritabanlarında default olarak 60 dakikada bir otomatik olarak çalışır ve veritabanın snapshot'ını alır. Bunun dışında sizin belirleyebileceğiniz bir zaman dilimi aralığında da sistemin AWR raporunu görebilmeniz mümkündür.

AWR raporlarını elle çalıştırmanız da mümkündür. Enterprise Manager'dan kolaylıkla çalıştırıp, görebileceğiniz gibi aşağıdaki blok ile de yapabilirsiniz;

BEGIN

DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();

END;
/

Görüntülemek isterseniz de DBA_HIST_SNAPSHOT view kullanılabilir. İstenilen bir snapshot'ı düşürmek içinse aşağıdaki komut çalıştırılabilir;

BEGIN

DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id => 22, high_snap_id => 32, dbid => 3310949047);

END;
/

Snapshot'ların aralığını ayarlamak içinse;

BEGIN

DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200, interval => 30, dbid => 3310949047);

END;
/

AWR istatistiklerini incelemek isterseniz kullanabileceğiniz view'lar ise;

V$ACTIVE_SESSION_HISTORY
DBA_HIST_ACTIVE_SESS_HISTORY
DBA_HIST_BASELINE
DBA_HIST_DATABASE_INSTANCE
DBA_HIST_SNAPSHOT
DBA_HIST_SQL_PLAN
DBA_HIST_WR_CONTROL

$ORACLE_HOME/rdbms/admin dosyasının altında da awrrpt.sql isimli bir script bulunmakta. Bu scriptin amacı bir HTML veya text raporu yaratarak, istatistikleri görüntülemek. Şu şekilde de çalıştırılabilir;

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

Enter value for report_type: text

Enter value for num_days: 2

Enter value for begin_snap: 10
Enter value for end_snap: 40

Enter value for report_name:
Using the report name awrrpt_10_40_1_1

10g'den önceki veritabanı yöneticilerinin işi, AWR olmadan gerçekten çok can sıkıcı olabiliyordu ancak AWR ve bir üstü ADDM sayesinde veritabanı gözlemlemek gerçekten çok basitleşti. Ayrıca, çıkan çıktıyı da anlayabilmek ve yorumlayabilmekte çok zor değildir. Zaten Oracle 10g bu raporları bizim için saat başı üretmekte ve bize düşen sadece kontrol etmek :)

İyi akşamlar,

Ogan

Fixed-Line Performance Management

Merhaba,

Oracle dışında kalan bir konu olacak fakat ucu biraz Oracle'a dokunan bir konu :)

Fixed veya Wire Line operatörler, hatlarındaki performans değerlerini takip etmek ve günlük ve anlık raporlar alabilmek için bir takım yazılımlar kullanırlar. Bu yazılımlardan bir kaçı; Aircom OPTIMA, Ericsson ENIQ, Inforvista INFOVISTA gibi. Bu yazılımların da kendilerinin tercih ettiği ve verilerin tutulduğu veritabanları vardır. Ericsson ENIQ (Ericsson Network IQ) Sybase veritabanı kullanır ve bunun dışında kalan firmalar tercihlerini Oracle'dan yana kullanmaktadırlar.


Performans yönetimi olarak kullanmakta olduğum yazılım Aircom -bir İngiliz firması- firmasının OPTIMA ürünüdür. Optima ile neler yapılabilir?

Optima, back-end ve front-end olmak üzere iki ayrı arayüzden oluşur. Back-end arayüzünde programın arka tarafında çalışacak ve veritabanını güncelleyecek konfigürasyonlar yapılır.

Veritabanına bir arayüz yüklemek istiyorsak önce o arayüze ait bir "interface workbook" oluşturmamız gerekmektedir. Bu bir excel sheet'tir ve içerisinde operatörün istediği bir arayüzden gelen verinin, veritabanına nasıl yükleneceğini barındırır. Bu arayüzü aktive edersekte (Optima OIT Tool aracılığı ile) veritabanına yazılabilmesi için "validator" ve "loader" script'lerini oluşturur.

Optima'da veriyi ftp, snmp, xml gibi yöntemlerle, santral'in, sdh cihazının ya da kiralık hatların bağlı olduğu ve yönetildiği EMS'lerden (Element Management System) çekeriz. Çekilen bu veri arından bize anlamlı bir hale getirip, veritabanına düzenli bir şekilde yazılabilmesi için .CSV uzantılı dosyaya, bir parser aracılığı ile çevrilir.

Bu konfigürasyonların ve scriptlerin aşamaları ise şu şekildedir;

FTP --> PARSER --> VALIDATOR --> COMBINER (Opsiyonel) --> LOADER

Yukarıdaki işlemleri ise şu şekilde açıklayabiliriz;

FTP: Perl ile yazılmış ve bir .ini dosyayı gönderilen ftp scripti sayesinde karşıdaki yönetim sisteminden üreyen performans verileri toplanır. İşlenmek üzere bir folder'ın altına konulur.

PARSER: Parser'ın görevi ftp'nin çektiği veriyi anlamlı ve düzenli bir hale getirmektir. Gelen veri .CSV uzantılı olsa bile üretilen parser bu veriyi düzenleyecektir. Parser ise bize, Aircom tarafından geliştirilmektedir.

VALIDATOR: Validator'ın görevi ise, parse edilmiş veriyi load edilebilecek konuma getirmektir. Dolayısıyla loader, bu veriyi bir takım araçlar sayesinde (sql loader) veritabanına hızlı bir şekilde yükleyecektir.

COMBINER: Opsiyonel olan bu script ise validate edilmiş bir verinin içindeki sayaç gruplarının tekbir grup altında toplanmasını gerçekleştirir. Tekbir grup altında toplanan bu verilerse veritabanında tek ve büyük bir tabloda, partition'lar halinde tutulacaktır.

LOADER: Bulk load ve single insert yapabilme özelliklerine sahip olan loader, çok hızlı bir şekilde veriyi veritabanına yazmakla görevlidir. Bulk insert edilen veri grubu, SGA'i fazla yormadan ve single insert'lere göre kat kat daha hızlı veritabanına yazılırlar.

Yukarıda tanımladığım görevler, Optima'nın back-end görevleridir. Bunun dışında bir de front-end görevleri vardır. Front-end arayüzünün amacı ise back-end'in topladığı veriyi raporlamak, görüntülemek, manipüle etmek vb.

Front-end için Optima Lite adı verilen bir program kullanılır. Programın içinde, Data Explorer, Filters, Element Hierarchy, Module Explorer, Reports, Alarms, Administrative Tools, Help gibi içerikler vardır.

Data Explorer: Veritabanındaki veriyi incelemeye yarar. Herhangi bir programa ihtiyacınız olmadan, hangi tabloda ne var görebilirsiniz.

Filters: Filtreler veriin nasıl gösterileceğine karar veren gruplardır. Yeni bir grup tanımlayabilir ya da varolanı değiştirebilirsiniz.

Element Hierarchy: Verinin hangi kademelerde raporlanayacağını belirleyen hierarşik yapıyı düzenleyen birimdir.

Module Explorer: En çok kullanılan birimdir ve SQL sorguları ile dinamik raporlar üretmeye yarar. Hangi tarihte ve hangi filtrelerle, hangi element hierarşisiyle görmek istiyorsanız, veriyi o şekilde gösterir.

Reports: Klasik raporlardır ve SMS,e-posta veya .txt,.doc,.pdf uzantılı dosya olarak çıktı sunar. Genelde günlük, haftalık, aylık ve yıllık raporları takip etmek isteyen müşteriye sunulabilir. Arayüzünün hazırlanması son derece kolaydır.

Alarms: Fault management kısmına, belirli limitleri tanımladıktan sonra, snmp poller aracılığı ile gönderdiğimiz alarmları yükseltir. Bu alarmlar, müşteri tarafından belirlenebilir ve limitleri aşarsa hata yönetim birimine aktarılır.

Administrative Tools: Optima kullanıcılarını tanımlamaya ve veritabanında oluşturmaya yarar. Bu kullanıcılar 3 ayrı grupta toplanır. Optima_Administrator, Optima_Advanced_User, Optima_Tool_User. Tool_User sadece read-only access'e sahiptir ve yetkileri sınırlıdır. Administrator ise programa tam olarak hakim olabilen kullanıcı grubudur. Yeni kullanıcılar yaratılırken bu gruplar dikkate alınır.

Yukarıdaki bilgiler son derece yüzeysel bilgilerdir ve daha detaylı yazarsam da kitap haline dönüştürülebilirler :) OPTIMA ile uğraşan ve problem yaşayan okuyucular bana e-posta gönderebilirler.

Optima'nın şu anda kullandığı veritabanı ve versiyonu ise Oracle DB 10gR2'dir. Yani gelmiş geçmiş en istikrarlı, tutarlı veritabanıdır.

İyi haftasonları,

Ogan

13 Nisan 2009 Pazartesi

The best of PL/SQL seminar with Steven Feuerstein

Merhaba,

Bugün sabah İstanbul'a, Steven Feuerstein'ın 2 günlük semineri için gelmiş bulunuyorum. Kısmetse yarın akşam tekrar Ankara'ya dönüyor olacağım.

Steven, PL/SQL konusunda birçok kitap yazmış, dünyanın en iyi PL/SQL developer'ı olarak bilinen bir kişidir. Aslında index organized table nedir? Ya da SGA optimizasyonu nasıl yapılır? gibi sorular yönelttiğiniz zaman cevaplandıramaması da bana göre doğaldır.

2 gün sürecek olan seminerin ilk gününde PL/SQL nedir? PL/SQL bloğu içerisindeki SQL sorgularının davranış biçimi ve PL/SQL bloğunun Oracle tarafından optimizasyonu, "Collection" konusu (Array-like structures, nested tables, Varrays), Virtual Private Database (DBMS_RLS), DBMS_UTILITY, DBMS_STANDARD paketleri, BULK COLLECT, FORALL gibi konulara girdik. Yarınsa daha çok "tricky" konularla ilgileniyor olacağız. Mesela birçok kişinin yakından takip ettiği ve hep merak edilen bir konu olan "SQL Injection". Bunu başarabilme ve injection'dan korunma methodlarından bahsedecek.

Steven Feuerstein hakkında daha fazla bilgi isteyenler; http://www.stevenfeuerstein.com/

Seminerle birlikte Steven, büyük ölçüde kendisinin hazırladığı Oracle PL/SQL Programming Language cep kitabını da ücretsiz olarak katılımcılara dağıttı.

İyi akşamlar.

04 Şubat 2009 Çarşamba

10g TABLESPACE

Merhaba,

Öncelikle tablespace'in tanımından başlayalım.

Tablespace: Mantıksal yapıları bir arada tutan ve gruplayan veritabanı depolama ünitesidir.

Mantıksal Yapılar: Tablespace, schema objeleri, veri blokları, extent'ler ve segmentlerden oluşan yapılardır.

Tablespace yapı itibariyle ikiye ayrılır.

1) Bigfile Tablespace
2) Smallfile Tablespace

Bigfile Tablespace: Oracle 10g versiyonu ile aramıza katılmışlardır. Bu tip tablespace'lerin en büyük özelliği 128 TB'a kadar .dbf (database file) barındırabilirler. Ancak tek bir database file ekleyebilirsiniz. Fiziksel depolamaya yarayan dbf'iniz dolduğu zaman tek yapabileceğiniz boyutunu arttırmaktır. Bigfile tablespace'ler extend olabilirler.

Eğer bir bigfile tablespace'e database file eklemeye çalışırsanız (alter tablespace add datafile ...) alacağınız hata şu olacak;

ERROR at line 1:
ORA-32771: cannot add file to bigfile tablespace


Smallfile Tablespace: 10g'den önce aramızda olan tablespace'dir. Üzerinde birden fazla dbf yaratılabilir.

İyi akşamlar,

Ogan

23 Aralık 2008 Salı

Oracle'ın Geçmişine Küçük Bir Yolculuk

Merhaba,

Oracle ile uğraşan herkes az çok Oracle'ın nasıl bir geçmişi olduğunu bilir. Bugün anlatmak istediğim aslında perdenin arkasında gerçekleşmiş olaylar.

Oracle'ın geçmişi tam olarak 30 yıllık bir geçmiş. Kurucularından olan Larry Ellison ve Bob Miner'ın başlangıçta sadece 2000 Doları varmış. Veritabanlarının adı da "Oracle"mış. Tabii o zamanlar ilişkisel veritabanı değil, "veritabanı programı" olarak biliniyormuş. Bahsettiğim yıl, 1977. Bruce Scott ve Ed Oates isimli yazılım mühendisleri ise Oracle'ın ilk tam zamanlı çalışan personelleri.

Oracle başlangıçta sadece ürünün adı olacaktı ancak ilerleyen zamanlarda şirketin adı olarak anılmaya başlandı. O zamanlarda da SQL (Structured Query Language) vardı fakat kullanan şirket IBM'di. ANSII gibi bir standart olmadığı için de ilk kullanılan sorgulama dili olmasının avantajı ile bütün veritabanları da peşinden SQL'e geçti ve bugün standart olan halini aldı.

IBM'in araştırma dosyalarından yararlanarak -o zamanların meşhur mühendisi Edgar Codd ile birlikte- ilk ilişkisel veritabanın temellerini 1978 yılında attılar. Projeye IBM destek vermemiş ve Edgar Codd görevinden istifa ederek Oracle'a geçmiştir.

1979'un Temmuz ayında Oracle, raflardaki yerini almaya başladı. Bu sayede Oracle ilk RDBMS olarak tarihteki yerini aldı. Oracle ilk olarak PDP-11 Assembler Language ile yazıldı ve 2nci versiyon olarak piyasaya sürüldü.

1980'li yıllarda Oracle veritabanı o zamanların en popüler programlama dili olan C ile yazılmaya başlandı. Bu yıllarda Oracle'ı diğer bütün yazılımlardan farklı kılan bir özellik vardı. O da işletim sistemi ne olursa olsun çalışması! İnsanlar 80'li yıllarda önce ilk olarak donanım alırlardı sonra yazılım alırlardı. Sonra da kara kara hangi yazılım bizim donanımlarımızda ve işletim sistemlerimizde çalışıyor diye düşünüyorlardı.

1982 yılı geldiğinde Oracle 16 ve 32 bit işletim sistemlerinde de çalışır hale geldi. Bu versiyon 2.3'tü. 2.3'te ise Oracle yepyeni bir son kullanıcı arayüzü ile piyasaya sürüldü. Yeni geliştirmeler içinse yazılım ekibi gece gündüz çalışmaya devam ediyordu.

1984 yılında, Oracle ilk kez "okuma tutarlılığı" konusunu gündeme getirdi ve Oracle versiyon 4 ile birlikte piyasaya sürdü. Bu şekilde Oracle bir sorgunun çalıştırıldığı zamandaki verilerin tutarlı olacağını garantilemiş oldu. Bankalar ve büyük şirketlerin bütün elektriğini üstüne çekmişti Oracle. Bu büyük innovasyon ile pazardaki yeri de gittikçe sağlamlaşıyordu. Informix ile savaşan Oracle'ın vurduğu en büyük darbelerden birisi de fiyatında uygunluk ve 2 ila 15 kat daha fazla arttırdığı performansı oldu. Yine bu yılın en büyük gelişmelerinden birisi de "Export/Import" aracının geliştirilmesi oldu. Günümüzde kullandığımız ve veritabanındaki verileri ve bütün objeleri başka bir veritabanına taşınması 1984 yılında Oracle'ın 4ncü versiyonu ile birlikte yapılır hale geldi.

1985'li yıllarda çok popüler olan Client/Server ilişkisini Oracle 5nci versiyonu ile birlikte hayata geçirdi. Oracle versiyon 9i'deki Real Application Clusters'ın temelleri de bu yıllarda clustering'in gelişmesi ile atılmış oldu.

1988'in en büyük dönüm noktası ise PL/SQL olarak tarihe yazıldı. Oracle 6ncı versiyonunda PL/SQL'i hayata geçirerek procedure'ler oluşturmaya başladı. Satır bazında tablolara kilit koyulması da yine bu versiyon ile gündeme geldi. Yine aynı yıl "Hot Backup" olarak bilinen ve veritabanı açık(online) iken yedekleme alınmasına yarayan sistem geliştirildi. Bundan önceki bütün versiyonlarda veritabanı yöneticileri veritabanını kapatıp sonra yedek alıyorlardı.

Oracle 1989 yılında OLTP sistemler için destek vermeye başladı (OLTP - OnLine Transaction Processing). Bu sistem genelde işlemlerin çok olduğu ve sorguların çok yoğun çalıştığı sistemlerde kullanılıyor. Bu sebepten, Oracle sektördeki birçok potansiyel müşteriyi de etkilemeyi başardı.

90'lı yıllarda teknolojik herşeyin gelişmesi son derece büyük bir ivme ile hızlanmaya başlamıştı. Oracle'ın artık yeni rakipleri, yüzleşmesi gereken bir innovasyon maliyeti ile birlikte gündeme gelmişti. Güncel gereksimler, müşteri ihtiyaçları ve rekabetin daha da kızışması ile birlikte 1990-2000 yılları arasında Oracle'da müthiş gelişmeler kaydedildi.

Oracle artık kat kat daha hızlı, güvenli, tutarlı ve sağlamdı. Oracle geliştirdiği 6.2 versiyonu ile cluster'lı yapısı ve PL/SQL'i ile müşterilerine birçok fırsat sunabiliyordu. Bu yıllarda Oracle daha çok son kullanıcıların arayüzlerinin iyileştirilmesi ile uğraşıyordu. Aslında son derece olumlu sonuçlar da alıyordu. Artık kullanıcılar daha kolay ve hızlı SQL kullanıyorlardı.

Seneler 1992'yi gösterdiğinde Oracle versiyon 7'yi piyasaya sürmeye hazırlanıyordu. Bu versiyonda PL/SQL'de trigger yazılmaya başlandı. Bu şekilde veritabanının işleyişi ve kontrol'ü biraz daha kolaylaşmış oldu. Veritabanı, artık yöneticisi tarafından tam olarak izlenebiliyordu (audit). Bu sayede yönetici, kullanıcılarının girdiği bütün sorguları kontrol edebiliyordu.

Client/Server uygulamaları hız kesmeden devam ediyordu. Bir yandan da 64 bit sistemler için entegrasyon işlemlerini yürütüyorlardı. Internet bazlı ve uygulama tabanlı entegrasyonları da son hız devam etmekteydi.

Oracle veritabanı, 1997 yılında Java ile daha da güçlü hale geldi ve veritabanının içinde Java uygulamaları geliştirebilir hale geldi. Veritabanının içine Java kodu gömülebiliyordu ve son derece hızlı bir şekilde çalıştırılabiliyordu. XML desteğini de vermeye başlayan veritabanının bu yıllardaki versiyonu 7 idi.

1998 yılında Linux tabanlı sistemi ile Oracle, internet ortamında çok daha sağlam bir duruş sergilemeye başladı. Versiyon ise 8i.

2000'li yıllarında başında Oracle "Unbreakable" olarak tanımlamaya başlamıştı kendini. Solaris'in 64 bit işletim sisteminin desteğini arkasına alan Oracle Linux Cluster'ları ile birlikte çok kuvvetli sistemin altına imzasını altın harflerle attı. Oracle veritabanı bu yıllardan sonra hep sağlam bir veritabanı olarak anıldı.

2001 yılında, Oracle'ın belkide en çok kullanılan, hala da uzun zaman önce sistemlerde entegre edilmiş ve sürüm güncellemesi yapılmamış veritabanı olan 9i piyasaya sürüldü. Oracle, Microsoft ve IBM'in veritabanlarına inanılmaz fark atmış, pazardaki payını dramatik bir şekilde arttırma yollarını genişletirken, yeniliklerin de ardı arkası kesilmiyordu. Tam cluster desteğine de geçiş sağlandı. Real Application Clustering ve kırılamayan Oracle 9i'nin lansmanları ve ardından gelen entegrasyonları ile veritabanı yöneticileri de sistemleri daha rahat ve kolay kullanmaya başladılar. Tabii aynı zamanda daha faydalı. Oracle veritabanı ile yapılan testlere göre, 100 TB'lık bir veritabanı, hala tutarlı ve sağlam bir şekilde durabiliyordu. Bu kadar gelişimden sonra da Oracle'ın aldığı ödüllerde artıyordu.

Oracle güvenli backup'ın geliştirilmesini 2006 yılında tamamladı ve sundu. Oracle'da veriler yedeklenirken artık encyrpt edilerek yedeklenebiliyor ve olası bir hırsızlık ve kaybolması durumunda korunabiliyordu. Oracle'ın versiyonu ise 10g oldu.

2007 yılında Oracle 11g versiyonunu tanıttı ve şu andaki sürümü ise 1 (release 1). 11g ile geliştirilen birkaç başlık ise; "Oracle Database Vault, Oracle Partitioning, Oracle Real Application Clusters and Oracle Audit Vault".

30 yılda Oracle'daki gelişmeleri bu şekilde özetleyebiliriz. Evet, sadece bir özet olarak kaydedilebilir yazdıklarım. Bunların arkasında ise inanılmaz bir yazılım geliştirme ekibi ve hırs var. Daha da ilerisinde ise, öğrenilecek çok şey :) Çünkü Oracle'da yeni bir innovasyon, siz eskisini tam olarak anlayana kadar geliştiriliyor ve Oracle durmuyor, yoluna devam ediyor. Bize de buradan şimdiye kadar bu yazılımın geliştirilmesinde katkısı bulunan bütün mühendislere teşekkür ediyoruz, ellerine sağlık.

İyi akşamlar,

Ogan


18 Aralık 2008 Perşembe

Ankara'mın Havası..

İyi akşamlar,

Yine bir kış geldi ve yine havamız solunmayacak halde. Dışarıya çıktığınız zaman dikkatlice bakın ve sis bulutu gibi bir tabaka göreceksiniz. Ne sis, ne bulut, pisliğin ta kendisi. O iğrenç hava kirliliğinin içinde yaşamaya zorunlu bırakılıyoruz. Sebebini ise burada yazmama gerek bile olduğunu düşünmüyorum.

Bir "dejavu"dur bu aslında.

Yine yerel seçim, yine yamalı yollar, yine kirli havalar, yine dağıtılan sadakalar, yine seçim propagandaları... Birgün bunların değişeceğini umuyorum.