Pazar, 11 Temmuz 2010 09:03
yönetici
Veri Sözlüğü
Her Oracle veritabanının bir veri sözlüğü vardır. Oracle veri sözlüğü, veritabanı hakkında referans bilgisi içeren tablolar ve view'lar kümesinden oluşur. Örnegin, veri sözlüğü veritabanının mantıksal ve fiziksel yapıları hakkindaki bilgileri tutar. Veri sözlüğü aşağıda belirtilen bilgileri de tutar:
- Tablolar üzerinde tanımlanmış bütünlük kısıtlamaları
- Şema nesneleri için tahsis edilmiş yer miktarı ve bu alanın ne kadarının kullanılmakta olduğu
Veri sözlüğü, veritabanının yaratılması sırasında yaratılır. İçindeki bilginin daima doğru kalabilmesi için belirli durumlarda Oracle, veri sözlüğünde gerekli değişiklikleri otomatik olarak yapar. Veritabanı yürümekte olan işleri kaydetmek ve onaylamak için Veri sözlüğünü kullanır. Örneğin, bir kullanıcının belli bir tabloya erişmek için yeterli yetkiye sahip olup olmadığını kontrol etmek için Oracle, veri sözlüğünü kullanır.
Veri Erişimi
Cumartesi, 10 Temmuz 2010 08:29
yönetici
Oracle kurulum süreci, malesef çoğu programda alıştığımız gibi rahat geçmedi. 3 kere Oracle'ın farklı sürümünü, birkaç kerede bu sürümler için TOAD sürümünü değiştirmemiz gerekti. Ama sonunda çalışan bir sistemi kullanabilir hâle geldik. Kısaca bu sürece bir göz atalım, sonrasında yazılacak çok konu var.
İlk deneme
İşletim sistemi: Windows-7 Home Premium 64bit Oracle : Oracle Database 10g Release2 Microsoft Windows (x86_32) Toad : 9.5
Problem : ORA-12154: TNS:could not resolve service name.
Çözüm önerileri : Oracle sürümünü değiştirmek.
İkinci deneme
İşletim sistemi: Windows-7 Home Premium 64bit Oracle : Oracle Database 11g Microsoft Windows (x86_64) Toad : 9,5 - 10,5
Problem : Cannot load OCI DLL: D:\oracle\db_1\BIN\oci.dll
Çözüm önerileri : Oracle'a sqlplus ile bağlanabiliyoruz, fakat TOAD ile bağlanmayı deneyince bu hatayı veriyor. Bu nedenle TOAD'ı kullanmak istiyorsak, TOAD bu oracle sürümüne uymadığı için tekrar oracle sürümünü değiştiriyoruz.
Üçüncü deneme
İşletim sistemi: Windows-7 Home Premium 64bit Oracle : Oracle Database 11g Microsoft Windows (x86_32) Toad : 10.5
Problem : Yok ve mutlu son 
Sisteminiz benimki gibiyse, üçüncü denemedeki sürümleri kullanarak bu problemden kurtulabilirsiniz. Mutlaka daha farklı çözümleri vardır fakat, henüz bunları yorumlayabilecek seviyede Oracle bilgim yok. Teşekkür ederim.
Cumartesi, 10 Temmuz 2010 08:54 tarihinde güncellendi
Çarşamba, 07 Temmuz 2010 14:21
yönetici
Fiziksel Veritabanı Yapıları
Oracle veritabanında kullanılan fiziksel yapılar şunlardır:
> Datafilelar : Her Oracle veritabanı bir veya birden fazla fiziksel datafile içerir. Datafilelar bütün veritabanının verisini tutar. Tablo ve indeksler gibi mantıksal yapıların verileri, fiziksel olarak veritabanı için tahsis edilmiş datafilelarda saklanır. Bir datafile ancak bir veritabanı ile ilişkilendirilebilir. İçlerindeki boş yer bittiğinde otomatik olarak büyümelerini sağlayacak şekilde yaratılabilirler. Datafile'lardaki veri normal veritabanı işlemleri sırasında belleğe okunur. Değişikliğe uğramış yada yeni girilen verilerin hemen datafile'lara yazılması gerekmez. Disk erişim sayısını azaltmak ve performansı arttırmak için, verinin bir kısmı bellekte tutulur ve gereken datafile'lara bir kerede yazılır.
> Redo Log dosyaları : Her Oracle veritabanında iki veya daha fazla redo log dosyası bulunur. Bu redo loglar kümesine genel olarak veritabanının redo logu olarak bilinir. Bir redo log, redo kayıtlarından oluşur. Redo logun ana görevi veri üzerinde yapılan tüm değişikliklerin kaydını tutmaktır. Bir sebepten dolayı bellekteki veriler datafile'lara yazılamazsa, değişiklikler redo loglardan elde edilebilir, yani yapılan iş hiçbir zaman kaybolmaz. Redo logları da içeren bir hata durumu oluşması halinde, redo bilgilerini kurtarmak için Oracle "Multiplexed Redo Log" tutulmasına izin verir. Bunun anlamı bir redo logun aynı anda iki yada daha fazla kopyasının tutulmasıdır. Redo log dosyasındaki bilgiler sadece sistem yada medya hatası nedeniyle datafile'lara yazılamayan verileri kurtarmak için kullanılır. Redo log'daki bilgiler kullanılarak veri kurtarılmasına "Rolling Forward" denir.
Çarşamba, 07 Temmuz 2010 14:30 tarihinde güncellendi
Çarşamba, 07 Temmuz 2010 14:11
yönetici
Oracle Mantıksal Veritabanı Yapıları - devam
Tablespaceler Her veritabanı, tablespace adı verilen ve biribiriyle ilişkili mantıksal yapıları gruplayan mantıksal depolama birimlerine bölünmüştür. Örneğin, tablespaceler genelde yönetimsel işleri kolaylaştırmak için bütün uygulama nesnelerini birlikte gruplar. Tablespace içindeki tüm mantıksal yapıları fiziksel olarak tutması için bir veya birden fazla datafile yaratılır. Datafileların toplam büyüklüğü, tablespace'in toplam depolama kapasitesini verir. Tablespacelerin toplam depolama kapasitesi, database'in toplam depolama kapasitesini verir. Şekil 1'de Veritabanları, tablespaceler ve datafilelar arasındaki ilişki gösterilmektedir.

Çarşamba, 07 Temmuz 2010 14:18 tarihinde güncellendi
Çarşamba, 07 Temmuz 2010 13:59
yönetici
Oracle Mantıksal Veritabanı Yapıları - devam
Veri Blokları, Extentler ve Segmentler
Veri blokları, extentler ve segmentlerden oluşan mantıksal saklama yapıları sayesinde Oracle'ın disk alanı üzerinde ayrıntılı bir kontrolü vardır.
>Oracle Veri Blokları : Veri blokları, Oracle veritabanında verinin saklandığı en küçük yapıdır. Bir veri bloğu, fiziksel veritabanı alanında belirli sayıdaki byte'a karşılık gelir. Standard blok büyüklüğü DB_BLOCK_SIZE başlangıç parametresiyle belirlenir. Bunun dışında en çok 5 adet blok büyüklüğü belirtilebilir.
>Extentler : Mantıksal veritabanı alanındaki bir sonraki seviye extentlerdir. Bir extent, belirli sayıdaki ardışık veritabanı bloğundan oluşur, bir seferde alınır ve belirli bir tipteki bilgiyi tutmak için kullanılır.
Çarşamba, 07 Temmuz 2010 14:11 tarihinde güncellendi
Çarşamba, 07 Temmuz 2010 13:47
yönetici
Oracle Mantıksal Veritabanı Yapıları
Oracle veritabanındaki mantıksal yapılar şema nesneleri, veri blokları, extentler, segmentler ve tablespacelerdir.
Şemalar ve Şema Nesneleri: Şema, veritabanı nesnelerinin oluşturduğu topluluktur. Bir şemanın sahibi bir veritabanı kulanıcısıdır ve bu şema o kullanıcıyla aynı isme sahiptir. Şema nesneleri direk olarak veriyle bağlantılı olan mantıksal yapılardır (Şema ve tablespace arasında bir bağlantı yoktur. Aynı şemadaki nesneler farklı tablespacelerde bulunabileceği gibi tablespacelerde farklı şemalara ait nesneler bulunabilir.) Başlıca şema nesneleri şunlardır:
> Tablolar : Oracle veritabanındaki en temel veri saklama birimidir. Veritabanı tabloları, kullanıcılar tarafından ulaşılabilecek tüm veriyi bulundururlar. Her tablonun kolonları ve satırları vardır. Oracle 256 veya daha az kolon içeren bir veritabanı tablosunun her satırını bir veya daha fazla satır parçası halinde saklar. Örnek olarak, çalışanların bilgilerini tutan tabloda, çalışan numarası diye bir kolon varsa, o kolondaki her satır bir çalışanın çalışan numarasını tutar.
> Viewler : Viewler bir veya birden fazla tablo yada view'deki verinin özelleştirilmiş bir gösterim şeklidir. Bir view aynı zamanda saklanmış bir sorgu olarak da değerlendirilebilir. Viewlar aslında veri içermezler. Bunun yerine verilerini kendilerine temel teşkil eden ve viewın temel tabloları olarak adlandırılan tablolardan çıkartırlar. Tablolar gibi viewlerin de bazı kısıtlamalar olmakla birlikte verisi sorgulanabilir, değiştirilebilir, silinebilir ve yeni veri girilebilir. Viewler üzerinde yapılan her işlem aslında viewın temel tablolarını etkiler. Viewler tablonun önceden belirlenmiş satır ve kolonlarına erişimi kısıtlayarak, tablo güvenliğinde ekstra bir seviye sağlar.
> İndeksler : İndeksler tablolarla ilişkilendirilen opsiyonel yapılardır. Data erişim performansını arttırmak için yaratılırlar. Bir Oracle indeksi tablo verisine direk bir erişim yolu sağlar. Oracle bir isteği cevaplarken, istenilen satırları daha hızlı bir şekilde bulmak için tablo ile ilişkilendirilmiş olan indekslerin bir kısmını yada hepsini kullanabilir. İndeksler, uygulamalar bir tablonun satırlarının belli bir bölümünü veya belli bir satırı sorguladıklarında işe yarar (Mesela, maaşı 1 Milyar'dan yüksek olan tüm çalışanlar). İndeksler bir tablonun bir veya birden çok kolonu üzerinde yaratılır. İndeksler yaratıldıktan sonra Oracle tarafından otomatik olarak bakılır ve kullanılır. Tablolar üzerinde yapılacak olan değişiklikler otomatik olarak ilişkili indekslere yansıtılır.
Çarşamba, 07 Temmuz 2010 13:58 tarihinde güncellendi
Çarşamba, 07 Temmuz 2010 13:36
yönetici
Veritabanı Yapısı ve Alan Yönetimi
Oracle Veritabanı, birim olarak kabul edilen verilerin bir araya toplanmasından oluşur. Veritabanının amacı birbiriyle ilişkili bilgilerin depolanması ve sorgulanmasıdır. Bir veritabanı sunucusu bilgi yönetimiyle ilgili problemleri çözmede anahtar roldedir. Genel olarak bir sunucu, büyük miktardaki veriye çok kullanıcılı bir ortamda, bir çok kullanıcının aynı anda aynı veriye ulaşabilmelerini güvenilir bir şekilde sağlar ve bunu aynı zamanda yüksek bir performansla gerçekleştirir. Bir veritabanı sunucusu aynı zamanda izinsiz erişimi engeller ve hata durumundan kurtulmak için gereken en uygun çözümleri sağlar.
Çarşamba, 07 Temmuz 2010 13:58 tarihinde güncellendi
Çarşamba, 07 Temmuz 2010 12:55
yönetici
Aynen reklamlarda söylendiği gibi. Neden aynı yeteneklere sahip bir ürün varken daha pahalı olanı tercih edeyim ki? Bu soru açık kaynak BI’ın keşfiyle iş zekası dünyası için de geçerli hale geldi.
Açık kaynak BI, açık kaynak furyasının başlamasından sonra gelinen ve açık kaynağın her alanda kullanılabileceğini kanıtlayan son noktalardan birisi. İşletim sistemleri, ofis uygulamaları derken açık kaynak BI da bilgisayarlardaki yerini aldı. Peki neden açık kaynak BI?
Şirketler iş zekası ihtiyaçlarını karşılayabilmek için BI uygulamaları üreticilerine milyon dolarlar ödemekteler. Açık kaynak BI ise bu üreticilerin vaad ettiklerini, ücretsiz veya destek hizmeti de almak isterseniz çok daha uygun maliyetlerle sunmaktadırlar.
Bu çok daha uygun maliyet aklınızda bazı soru işaretleri yaratabilir. Açık kaynaklı BI uygulamalarının gerçekten bu yeteneklere sahip olup olmadığı hakkında tereddüte düşebilirsiniz. Sanırım açık kaynak ürünleri kullanan Bnsf Lojistik, Boyne Resorts, Cardiac Science, Centro, Divx, Mozilla, Accor, Aol, Virgin Mobile, Jrc Avrupa komisyonu ve Unhcr gibi firmalar da bu ürünleri satın almadan önce aynı kaygılara sahiptiler ancak şimdi her biri başarılı projeleri için referans konumundalar.
Çarşamba, 07 Temmuz 2010 12:49
yönetici
Gartner'dan Andreas Bitterer'in Business Intelligence'ın ne olduğu ile ilgili tanımı şu:
"Business intelligence is the use of information that enables organizations to best decide, measure, manage and optimize performance to achieve efficiency and financial benefit. Türkçe'ye çevirecek olursak: "İş zekası, kuruluşların etkinlik ve finansal fayda elde etmek amacıyla performansla ilgili gerekli kararları en iyi şekilde verebilmeleri ve ölçümleri yapabilmeleri, performansı en iyi şekilde yönetebilmeleri ve optimize edebilmeleri için bilginin kullanılmasıdır."
Çarşamba, 07 Temmuz 2010 12:38
yönetici
Az çok yapmam gerekenin ne olduğunu anladım; kod adı ETL. Bir de ELT gördüm tabi bakındığım yerlerde ki ilk başta baya bir kafamı karıştırdı. Heleki ETL’i kafamda oturttuktan sonra aklıma takılan ilk soru: “Nasıl oluyorda önce Load edip daha sonra Transform’u gerçekleştiriyorlar? Performans düşmüyor mu?” Hafta bitmeden bunun cevabını aradım ve tabii ki yanıt göz ardı edilen ayrıntıda gizliydi.
E(T)LT
Farklı kaynaklarda bulunan veriler transform olmadan birleştirilemez; ancak bu iş için ayrı bir sunucuya gereksinim duyulmayabilir. Transform işi, Extract ve Load arasında paylaştırılır. Transform’un Load aşamasına aktarılmasını anlarım, sonuçta kaynaktan alınmış bilgiler hedefe yüklenirken bir şekilde işlenebilir. Fakat farklı kaynaklardan veri alabilmek için farklı kod yazmamız gerekiyor; daha sonra birleştirmek için türlü taklalar atıyoruz; nasıl oluyor da Extract aşamasına Transform’un bir kısmı aktarılıyor? Örnek olarak ODI’yi (Oracle Data Integrator) ele alalım. Topology Manager’dan her hangi bir kaynak import ettiğimiz zaman (SQL Server, CSV, Spreadsheet vs.), ki bu hala Extract aşamasıdır, sunucudaki verilere erişim hakkımız vardır. Yani aslında o sunucuya gerekli komutu yollayarak istediğimiz verileri almamız mümkün. Tabi bu cümleleri sarfederken gözardı ettiğim birçok nokta mevcut, bunlara daha sonraki yazılarda değineceğim.
Şu anki durumumuz: SQL Server’a bağlandık, CSV ve Spreadsheet dosyalarını import ettik. Extract aşamasında uygulanan transform’da kullanacağımız kod, o sunucuda kullanılan dile uygun olmak zorunda. Yani biz SQL Server’dan Extract ediyorsak, bu aşamada yapacağımız bir filtre (misal tarih karşılaştırması) SQL Server’da kullanılan sql diline uygun olmak zorunda. Eğer kaynağımız Oracle’sa, aynı şekilde yazacağımız dilin Oracle’a göre düzenlenmiş olması gerekli. Bunun dışında Spreadsheet ve CSV için herhangi bir dil kullanmamız mümkün değil. Bu nedenle onların bir sunucuya import edilmesi, daha sonra bu sunucuya uygun diile Extract aşamasında Transform edilmesi gerekli.
Daha sonra Extract edilen veriler, doğrudan hedef sunucuya istenildiği gibi transform uygulanarak aktarılır. Böylece ETL’deki Transform sunucusundan kurtulmuş oluruz.
Yukarıda verdiğim örneğe göre ELT’nin sadece Oracle’a özel olduğunu düşünmeyin. Birçok farklı sistemde uygulanabilir olduğu için, ELT’nin başlı başına bir yöntem.
|
|