Merhaba,
RDBMS (Relational DataBase Management Systems), yani "İlişkisel veritabanı yönetim sistemleri"'nin temeli 1980'li yıllarda atılmıştır. IBM tarafından Oracle tarafında geçen ve 2003 yılında vefat eden Dr. Edgar J. Codd bu temelin atılmasında çok büyük rol oynamıştır.
İlişkisel veritabanının mantığı veriye daha hızlı ve sağlam ulaşmaktan geçer, diyebiliriz. Veri modelleri arasındaki bağlar birbirleri ile ilişkilendirildiği zaman mantıklı ve stabil sonuçlar elde edildiği anlaşılmıştır.
Bu andan itibaren SQL (Structured Query Language)'in önemi o yıllardan başlayarak hızlı bir şekilde artmıştır. Devamında gelen PL/SQL (Procedural Language) ile de günlük veritabanı yönetimi işlemlerimiz için de bir dönüm noktası olmuştur.
Aslında bu yazımda SQL'den bahsetmek istiyorum. SQL'i nerelerde, neden, ne zaman ve ne için kullanıyoruz ona bakalım.
SQL sorgularını, ilişkisel veritabanına ait tablolardaki verileri çekmek ve görüntülemek için kullanabiliriz. Bu verileri, birbirine bağlı olan tablolarla birleştirip farklı sonuçlar görmeyi sağlayabiliriz. Bu sonuçları bi view'da tutup, her seferinde uzun sorgular yazmak yerine o view'u sorgulayarak ulaşabiliriz.
Tablolar, sequenceler, synonymler, viewlar vb. objeler yaratmak için SQL kullanırız. Kullanıcı yaratmak, haklar dağıtmak, dağıtılan hakları geri almak ve kullanıcıları düşürmek için de kullanırız.
Başka veritabanlarında kendi veritabanımıza bağlı iken sorgular çalıştırabilir, gerekli yetkilerimiz varsa bu yetkiler doğrultusunda veritabanının yapısını değiştirebiliriz.
Veritabanının memory parametrelerini değiştirebilir, daha hızlı ve performanslı çalışmasını sağlayabiliriz.
Veritabanının yedeğini alabilir, aldığımız yedekten dönebilir ve veritabanını kapatıp, açabiliriz.
Oracle veritabanında kayıtlı olan paketlerden özel fonksiyonları kullarak hesaplama işlemlerimiz yapabiliriz. X$ tablolarından alınan V$ view'ları ile de veritabanının monitör edilmesinde kritik rol oynayan verileri görebilir, değiştirebiliriz.
Velhasıl, Oracle'ın kurulum anından, kaldırdığımız ana kadar SQL ile her işimizi belirli düzeylerde görebiliriz. Çok daha ileri durumlarda, mesela veritabanına giren kullanıcıların takip edilmesi gibi, PL/SQL'e başvurabiliriz. O kademede ise işlerimiz çok daha rahat olacaktır, PL/SQL ile.
ANSI standartlarının belirlediği SQL sorguları, günümüzde bütün ilişkisel veritabanlarında desteklenmektedir. Oracle'a ait bazı sorgu çeşitleri vardır ve sadece Oracle veritabanlarında kullanılabilir. Aslında ANSI standarları uyarınca bilinen SQL her veritabanında hayat kurtarabilir.
Oracle veritabanı SQL'in olduğu yerde başlar ve olmadığı yerde biter. SQL sorgularının çalıştırılmadığı bir veritabanı olamaz, düşünülemez.
İyi çalışmalar.
Ogan
17 Mart 2008 Pazartesi
ORACLE - ORA HATALARI
Merhaba,
Oracle veritabanını yönetirken, yedeğini alırken, performansını ayarlarken veya sql-pl/sql sorguları hazırlarken hepimizin, yaptığımız hatalardan dolayı aldığımız hatalar ORA- ile başlar ve hatanın algılanması için son derece kritiktir.
Destek verdiğiniz kurum, şahıs veya kuruluşta Oracle konusunda hatalar oluşuyorsa, bunu çözmenin en mantıklı yolu ORA hatasına bakmaktadır. İkinci olaraksa alert.log'a bakılabilir.
Sıklıkla karşılaştığımız ORA hatalarını kısaca şu şekilde özetleyebiliriz;
ORA-06550 : PL/SQL kodu compile edilirken oluşan hatalardır. (PL/SQL compilation error)
ORA-00936 : Sorgumuzda atlanan veya unutulan bir bölüm olduğu zaman oluşan hatalardır. (missing expression)
ORA-01034 : Oracle veritabanı açık değildir. (ORACLE not avaliable)
ORA-01033 : Oracle kapatılma sürecindeyken log on olduğumuz durumlarda oluşan hatalardır. (ORACLE initialization or shutdown in progress)
ORA-01555 : Üzerine veri kaydedilmiş rollback kayıtları olduğu zaman oluşan hatalardır. (snapshot too old)
ORA-01017 : Kullanıcı adı veya parolayı yanlış girdiğimiz durumlarda aldığımız hatalardır. (invalid username/password; logon denied)
ORA-00932 : Veri tipleri (data type) uyuşmadığında aldığımız hatalardır. (inconsistent datatypes)
Oracle'da sık sık aldığımız hataların başında gelen bu hatalar, hata kodunu bildiğimiz durumlarda aslında çok kolaylıkla kurtulabileceğimiz ve düzeltebileceğimiz hatalardır. Hata kodunu bildiğimiz durumlarda müdahale etmemiz ne kadar kolaysa, bilmediğimiz durumlarda da yorum yapıp, müdahale etmemiz o kadar zordur!
ORA-00600 hataları, Oracle Yazılımının kernel kodundan kaynaklanan hatalardır. Bu problem ile karşı karşıya kaldığımız anlarda müdahale şansımız düşüktür ve bu hataların ürettiği logları alert.log larda bulabiliriz.
Bu hatalar beraberinde bir takım argümanları da getirmektedir.
Örneğin;
ORA-00600 [400][520][11][900][][]
Bu hatalara sadece Oracle hata analizcileri müdahale edebilir. Ayrıca, bu argümanların içerisindeki değerler versiyondan versiyona değişebildiği için, son kullanıcılara veya DBA'lere ezberlemeleri tavsiye edilmez. Daha detaylı bilgi için yazdığım bir başka yazıya tıklayınız.
Oracle konusunda eğer bir hatayı çözmek istersek, o hatanın en derinine inmemiz gerekir. Asıl sebep ile gerçek sonuca ulaşabilmek şüphesiz çok hızlı gerçekleşecektir. Onun dışında deneme-yanılma yöntemleri veya içgüdüsel duygularla yapacağımız işin sonucu pek de hayırlı olmayacaktır.
İyi çalışmalar.
Ogan
Oracle veritabanını yönetirken, yedeğini alırken, performansını ayarlarken veya sql-pl/sql sorguları hazırlarken hepimizin, yaptığımız hatalardan dolayı aldığımız hatalar ORA- ile başlar ve hatanın algılanması için son derece kritiktir.
Destek verdiğiniz kurum, şahıs veya kuruluşta Oracle konusunda hatalar oluşuyorsa, bunu çözmenin en mantıklı yolu ORA hatasına bakmaktadır. İkinci olaraksa alert.log'a bakılabilir.
Sıklıkla karşılaştığımız ORA hatalarını kısaca şu şekilde özetleyebiliriz;
ORA-06550 : PL/SQL kodu compile edilirken oluşan hatalardır. (PL/SQL compilation error)
ORA-00936 : Sorgumuzda atlanan veya unutulan bir bölüm olduğu zaman oluşan hatalardır. (missing expression)
ORA-01034 : Oracle veritabanı açık değildir. (ORACLE not avaliable)
ORA-01033 : Oracle kapatılma sürecindeyken log on olduğumuz durumlarda oluşan hatalardır. (ORACLE initialization or shutdown in progress)
ORA-01555 : Üzerine veri kaydedilmiş rollback kayıtları olduğu zaman oluşan hatalardır. (snapshot too old)
ORA-01017 : Kullanıcı adı veya parolayı yanlış girdiğimiz durumlarda aldığımız hatalardır. (invalid username/password; logon denied)
ORA-00932 : Veri tipleri (data type) uyuşmadığında aldığımız hatalardır. (inconsistent datatypes)
Oracle'da sık sık aldığımız hataların başında gelen bu hatalar, hata kodunu bildiğimiz durumlarda aslında çok kolaylıkla kurtulabileceğimiz ve düzeltebileceğimiz hatalardır. Hata kodunu bildiğimiz durumlarda müdahale etmemiz ne kadar kolaysa, bilmediğimiz durumlarda da yorum yapıp, müdahale etmemiz o kadar zordur!
ORA-00600 hataları, Oracle Yazılımının kernel kodundan kaynaklanan hatalardır. Bu problem ile karşı karşıya kaldığımız anlarda müdahale şansımız düşüktür ve bu hataların ürettiği logları alert.log larda bulabiliriz.
Bu hatalar beraberinde bir takım argümanları da getirmektedir.
Örneğin;
ORA-00600 [400][520][11][900][][]
Bu hatalara sadece Oracle hata analizcileri müdahale edebilir. Ayrıca, bu argümanların içerisindeki değerler versiyondan versiyona değişebildiği için, son kullanıcılara veya DBA'lere ezberlemeleri tavsiye edilmez. Daha detaylı bilgi için yazdığım bir başka yazıya tıklayınız.
Oracle konusunda eğer bir hatayı çözmek istersek, o hatanın en derinine inmemiz gerekir. Asıl sebep ile gerçek sonuca ulaşabilmek şüphesiz çok hızlı gerçekleşecektir. Onun dışında deneme-yanılma yöntemleri veya içgüdüsel duygularla yapacağımız işin sonucu pek de hayırlı olmayacaktır.
İyi çalışmalar.
Ogan
12 Mart 2008 Çarşamba
BLOCK CHANGE TRACKING
Merhaba,
Bu yazımda Oracle Database 10g'ye özel bir özellik olan ve RMAN ile incremental backuplarımızı çok kritik ölçülerde hızlandırabilen "BLOCK CHANGE TRACKING"den bahsedeceğim.
Bu tarz bir hız artışına neden ve hangi durumlarda ihtiyacımız olabilir?
1) Veritabanımız ciddi boyutlarda ve adette verileri barındırıyorsa, yedekleme işlemi saatlerce sürebilir.
2) Gelişen ve hızla büyüyen ülkemizde ve dünyada artık zamanın çok kritik olduğu.
3) Incremental backup ile geliştirilmiş bir yedekleme stratejisi oluşturmuşsak.
Yeni ve sıklıkla kullanılan bir özellik olan Block Change Tracking, özel bir dosyada (bizim enable ederken belirlediğimiz), veritabanı bloklarını flag ile tutar.
Bu özelliği aktif hale getirebilmek için ise;
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/ORACLE/ADMIN/TRIAL/BLOCKTRACK.DBF';
Bu komutun ardından, veritabanında değişen bütün blocklar bu özel dosyada değişiklikleri ile tutulur. RMAN ile incremental backup alınırken, RMAN bu dosyayı kontrol eder ve blockların üzerindeki değişiklikleri algılar. Bu işlem, backup sırasında, ciddi boyutlarda CPU ve zaman kazançları sağlayabilir.
Block change tracking aktif iken RMAN ile herhangi bir işlem veya komut gerçekleştirmeden bu uygulamadan yararlanabiliyoruz.
Hızla büyüyen ve çok büyük boyutlarda veritabanlarında incremental backup alınırken bu komutu mutlaka aktif hale getirmeliyiz de denebilir. Bu özellik sayesinde, aynı zaman da çok ciddi zaman ve para kaybı da engellenmiş olacaktır.
V$BLOCK_CHANGE_TRACKING view'u, bizim bu özellliği en son hangi duruma ayarladığımızı ve hangi dosyaya kaydedildiğini gösterir.
SQL> ALTER DATABASE RENAME FILE '/ORACLE/ADMIN/TRIAL/BLOCKTRACK.DBF' TO '/ORACLE/ADMIN/BLOCK.DBF';
Bu komut ile özel dosyamızın adını değiştirebilir (mount modunda) ya da
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
ile bu özellikten yararlanmaktan vazgeçebiliriz.
Bu özellik daha önce enable edilmiş ve ardından disable edilmişse, disable komutundan enable komutuna aynı özel dosya ile geçiriyorsak, bütün değişiklikler silinir ve bilgiler baştan toplanır.
İyi çalışmalar.
Ogan
Bu yazımda Oracle Database 10g'ye özel bir özellik olan ve RMAN ile incremental backuplarımızı çok kritik ölçülerde hızlandırabilen "BLOCK CHANGE TRACKING"den bahsedeceğim.
Bu tarz bir hız artışına neden ve hangi durumlarda ihtiyacımız olabilir?
1) Veritabanımız ciddi boyutlarda ve adette verileri barındırıyorsa, yedekleme işlemi saatlerce sürebilir.
2) Gelişen ve hızla büyüyen ülkemizde ve dünyada artık zamanın çok kritik olduğu.
3) Incremental backup ile geliştirilmiş bir yedekleme stratejisi oluşturmuşsak.
Yeni ve sıklıkla kullanılan bir özellik olan Block Change Tracking, özel bir dosyada (bizim enable ederken belirlediğimiz), veritabanı bloklarını flag ile tutar.
Bu özelliği aktif hale getirebilmek için ise;
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/ORACLE/ADMIN/TRIAL/BLOCKTRACK.DBF';
Bu komutun ardından, veritabanında değişen bütün blocklar bu özel dosyada değişiklikleri ile tutulur. RMAN ile incremental backup alınırken, RMAN bu dosyayı kontrol eder ve blockların üzerindeki değişiklikleri algılar. Bu işlem, backup sırasında, ciddi boyutlarda CPU ve zaman kazançları sağlayabilir.
Block change tracking aktif iken RMAN ile herhangi bir işlem veya komut gerçekleştirmeden bu uygulamadan yararlanabiliyoruz.
Hızla büyüyen ve çok büyük boyutlarda veritabanlarında incremental backup alınırken bu komutu mutlaka aktif hale getirmeliyiz de denebilir. Bu özellik sayesinde, aynı zaman da çok ciddi zaman ve para kaybı da engellenmiş olacaktır.
V$BLOCK_CHANGE_TRACKING view'u, bizim bu özellliği en son hangi duruma ayarladığımızı ve hangi dosyaya kaydedildiğini gösterir.
SQL> ALTER DATABASE RENAME FILE '/ORACLE/ADMIN/TRIAL/BLOCKTRACK.DBF' TO '/ORACLE/ADMIN/BLOCK.DBF';
Bu komut ile özel dosyamızın adını değiştirebilir (mount modunda) ya da
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
ile bu özellikten yararlanmaktan vazgeçebiliriz.
Bu özellik daha önce enable edilmiş ve ardından disable edilmişse, disable komutundan enable komutuna aynı özel dosya ile geçiriyorsak, bütün değişiklikler silinir ve bilgiler baştan toplanır.
İyi çalışmalar.
Ogan
Kaydol:
Kayıtlar (Atom)