Change Font Size

Change Screens

Change Profile

Change Layouts

Change Direction

Change Menu Styles

Cpanel

Duyurular

SAP Türkiye’ye yeni Pazarlama Müdürü

Ericcson Türkiye’de Pazarlama ve Strateji Müdürü  olarak görev yapan Erdem Aksakal, SAP Türkiye’nin yeni Pazarlama Müdürü oldu. Dünyanın en büyük kurumsal yazılım firmalarından SAP, Türkiye kadrosunu genişletmeye devam ediyor. SAP…...
Devamını Oku..
Salı, 14 Aralık 2010 13:47 in Duyrular

IBM'den çevre dostu veritabanı sistemi

IBM'den çevre dostu veritabanı sistemi IBM’in yeni DB2 veritabanı sürümü, veri saklama altyapılarından kaynaklanan karbon salınımını %75’e varan oranda azaltarak, küresel ısınmayla savaşıyor. IBM, yeni DB2 veritabanında yüksek ölçekli sıkıştırma…...
Devamını Oku..
Salı, 14 Aralık 2010 10:01 in Duyrular

Avea BT Sistemleri Uygulama Geliştirme Direktörü Cahit Terzioğlu

Merhaba, ETL süreçlerini ve faydalarını iyi analiz edebileceğimiz bir yazı paylaşıyoruz.Bunun için Avea BT Sistemleri Direktörü Cahit Beyle roportajdan bir bölüm yayınlayalım. Avea BT Sistemleri Uygulama Geliştirme Direktörü Cahit Terzioğlu…...
Devamını Oku..
Salı, 14 Aralık 2010 09:32 in Duyrular

Genel Duyuru

Merhaba  Arkadaşlar, Sitemiz güncellenmekte ve sizden gelen istekler doğrultusunda her gün yeni bir şeyler eklenmektedir. Bundan dolayı sitemize Forum, Video bölümlerini ekledik. Modüllerimizi daha da geliştiriyor olacağız. Sitemizi bloglarınızda link…...
Devamını Oku..
Salı, 14 Aralık 2010 09:10 in Duyrular

Yapı Kredi Bankası DataWarehouse Uygulaması

      "YKB Oracle 8i üzerinde geliştirdiği DataWarehouse uygulamasını yedi hafta içerisinde Sybase IQ ya taşıyarak, on aylık geri ödeme süresi ile yatırım geri dönüş maliyetinde %154 kazanç sağlamış…...
Devamını Oku..
Pazar, 12 Aralık 2010 20:34 in Duyrular

En Çok Okunanlar


Data Dictionary İstatistiğinin Alınması on 24 Haziran 2010, 00.00 by Yusuf Arslan in Oracle
Data Dictionary İstatistiğinin Alınması
Bu yazımda Oracle Database 10g ‘yle birlikte kullanıma sununlan cost-based optimizer (COB) hakkında işinize yarayacak bazı bilgiler vermek istiyorum. Cost-based optimizer uygulamasının asli görevi SYS ve SYSTEM ş
Veri, Veritabanı, Başarılı Veritabanı Uygulamaları İçin Dört Öneri
Hasan Tonguç Yılmaz bey’in Turkcell bloğunda yeralan yazılarını izniyle paylaşıyor olacağız.Öncelikle tanımayanlar için Tonguç Yılmaz kimdir kendi yazılarından tanıyalım.    Liseyi Mu�
Oracle Database 11g Bileşenleri Ve Mimarisi-1
Oracle Database 11g Bileşenleri Ve Mimarisi-1 Bu makalede Oracle Database 11g (Oracle 11g) veritabanı yönetimini öğrenmeye başlayacağız. Makalenin hazırlanış amacı Oracle 11g Administration I OCA sertifika
Oracle 11g BI ile Harita Üzerinde Rapor Oluşturma(Integratıon Mapviews)
BI EE 11 g’nin en büyük özelliklerinden biri MapViewer’dır.  Bu özellik , haritalara yetenek ve görsellik katarak raporlar oluşturmamızı sağlamaktadır.Örneğin dünya çapında bir haritada ülke b
Veriambarı Yazılım Geliştirme Sürecinde Test on 14 Aralık 2010, 09.47 by Yusuf Arslan in Oracle
Veriambarı Yazılım Geliştirme Sürecinde Test
Veriambarı bir organizasyonun elektronik olarak saklanan datasının deposudur.Veri ambarları raporlama ve analizi kolaylaştırmak için dizayn edilmişlerdir. Veriambarları analiz ve ilişkili verilerin sorgulanabildi
Muhammet Ali YURTÇİÇEK

Muhammet Ali YURTÇİÇEK

Veri bilgi çağının vazgeçilmez unsurudur.

Website bağlantısı: aliyurtcicek.blogspot.com E-posta: Bu e-Posta adresi istek dışı postalardan korunmaktadır, görüntülüyebilmek için JavaScript etkinleştirilmelidir

Salı, 14 Aralık 2010 11:27

SAP (System Applications and Products)

SAP (System Applications and Products)

 Bu yazımızda SAP'nin piyasaya çıkış serüveni ile birlikte temel olarak dayandığı mimariye değineceğiz. SAP sistemlerini tanımak ve genel hatları ile mimarisini anlamak için önsöz niteliğinde bir yazı ile başlayalım istedik.

sap 

SAP 1972 yılında, IBM ‘de çalışan beş kişi ( Dietmar Hopp, Hans-Werner hector, Hasso Plattner, Klaus Tschira ve Claus Wellenreuther) tarafından, Almanya ‘nın , Mannheim kentinde, ufak bölgesel bir şirket olarak kuruldu. Kurulduğu 70 ‘li yıllarda R/1 ve 80’li yılarlıda kapsayan R/2 sistemlerini geliştiren SAP, 1980 ler de geldiğinde hızla büyüdü ve Almanya ‘nın Heidelberg yakınlarında bulunan Walldorf ‘a taşındı. O yıllarda, Almanya ‘da ilk yüze giren Endüstri firmalarından çoğu SAP müşterisiydi. (ICI, BASF, John Dere) fakat büyüme sadece Almanya sınırlı değil, Almanya dışında da devam ediyordu. 80 ‘lerde gelişmesi devam eden R/2 sistemi, çok uluslu müşteripotansiyalini, dil, para, para birimi, ülkelere özgü yasal koşulları dikkate aldı. Bu çok uluslu yaklaşımı bugünde devam etmektedir. 1980 ‘lerin ortasında SAP ilk satış grubunu Almanyanın dışında, Avusturya ‘da başlattı. Geliri 52 milyon doları geçti ve büyük bilgisayar fuarlarında varlığını göstermeye başladı. 1988 içerisinde, SAP GmbH, SAP AG oldu ve o yıl Frankfurt ve Stuttgart borsaları üzerinde ticaret yapmaya başladı.

SAP başarılarını sürdürmeye devam etti ve 1990 ‘larda, gerçek bir uluslararası iş anlayışı geliştirdi. R/3 sistemini 1990 ‘larda tanıttı, bu ticari şirketler için bilgi işlem alanında dev bir adım oldu. Bu dev adımla birlikte kod yazma, uygulamalar, arayüzlere son kullanıcı daha rahat ulaşabilir, konfigre edebilir ve kod geliştirebilir oldu.

SAP R/3, üç katmanlı sunucu mimarisinden esinlenmişti. R/3 sistemininde esinlendiği bu mimari , temelde verileri bilgisayardan talep ederken bilgileri bölerek alır ve depolar. Başka bir deyişle üç katmanlı “three-tier” mimarisi ;

3 ana kısımdan oluşur, bunlar ; - Server yada Client - İş mantığı - Veritabanı ve bu veritabanını yönetimi ile ilgili program. Tipik bir three-tier uygulamada, uygulama kullanıcısının iş istasyonu; kullanıcıya arayüz sağlayan (GUI) programı, uygulamaya özel giriş formlarını ve etkileşimli pencereleri içerir. (Yerel veriler veya iş istasyonunun kullanıcısına özel veriler de yerel sabit diskte saklanır).İş mantığı, bir yerel alan ağ sunucusu veya başka bir paylaşımlı bilgisayarda bulundurulur. İş mantığı, iş istasyonlarından gelen istemci istemlerine sunucu olarak karşılık verir. Hangi verilerin gerekli olduğuna (ve nerede bulunduğuna) karar verir ve bir mainframe de bulunan 3. katman programı ile (bu kez) istemci olarak ilişki kurar.

 3. katman, veritabanını ve bu veritabanına okuma ve yazma erişimini yöneten programı içerir. Bir uygulamanın oluşumu daha karmaşık olmakla birlikte, bu 3 katmanlı görüş büyük ölçekli bir programdaki parçalar için uygun bir düşünce yapısı oluşturur. Three-tier bir uygulama istemci-sunucu modelini kullanır.

Her üç katman, farklı programlama dilleri ile çalışan farklı takımlar tarafından paralel olarak geliştirilebilir. Bir katmanın programı, diğer katmanlar etkilenmeden değiştirilebilir veya taşınabilir. Böylece, bir kuruluş için yeni ihtiyaçlar doğduğunda değişiklik yapmak kolay olur. Varolan uygulamaların tamamı veya bazı kritik kısımları geçici veya sürekli olarak saklanabilir ve eklenen yeni bir katmanın içine katılabilir. Bu 3 katlı mimari temel esasına dayanarak R/3 ;

Veri tabanı katmanı organizasyonun iş bilgilerini yönetir. Bu ana bölümlerin ana verileri ,bölümlerin ortak verileri ve veri tabanı yapısını tarif eden meta verileridir. Bütün verileri işlemek ve tanımlamak için SQL ( Structured Query Language –Yapısal Sorgu Dili) adlı endüstri standardı kullanılır. Belirli bir Pazar payına sahip ve organizasyonel amaçlar için uygun bütün ilişkisel veri tabanı yönetimi sistemleri (DBMS) SAP R/3 tarafından desteklenir.

 İlişkisel veri tabanı üzerine yerleştirilmiş uygulamalar ikinci katmanı oluşturur. Bunlar veri tabanı katmanından aldıkları bilgilerle çalışır ve sonuç verilerini yine bu katmana yazarlar .R/3 sistem uygulamaları da ,ABAP programlama dili ile yazılan özel olarak yazılmış uygulamalar gibi... bu katmanda çalışır. Uygulamalar veri tabanından istediği gibi çağrılır,uygulama katmanına yüklenir ve burada çalıştırılır. Kullanıcı ara yüzü olarak da bilinen sunum katmanı diğer adıyla prezantasyon katmanı ,kullanıcıya en yakın şekilde yerleştirilmiştir .Kullanıcının her gün kullandığı grafik ara yüz bu katmanın bir parçasıdır.SAP uygulamaları ABAP/4 adlı ,SAP tarafından geliştirilmiş dördüncü nesil bir dille yazılır . İşletmenin ihtiyaçlarını karşılamak için gerekli değişiklikler bu dil yardımıyla yapılır. SAP, AR-GE ‘ye kurulduğu gün itibariyle önem vermiş, günümüzde bu öneme devam etmektedir. Geliştirmeleriyle bugün dünyanın neredeyse her ülkesinde başarıyla hizmet veren çokuluslu bir firmadır…

 

Pazartesi, 06 Aralık 2010 15:59

Oracle Database 11g Bileşenleri Ve Mimarisi-1

Oracle Database 11g Bileşenleri Ve Mimarisi-1

Bu makalede Oracle Database 11g (Oracle 11g) veritabanı yönetimini öğrenmeye başlayacağız. Makalenin hazırlanış amacı Oracle 11g Administration I OCA sertifikası sınavının amaçlarının açıklanması ve bu sertifikanın alınması için gerekli olan konular anlatılmasıdır. Oracle Şirketi güçlü ve özellik bakımından zengin olan ayrıca performans, kullanılabilirlik, yedeklenebilirlik, uygulama- test ve kritik uygulamalar için güvenlik yeterliliğini karşılayabilecek bir sürüm olarak Oracle 11g’yi piyasaya sürdü. Oracle DBA olarak size düşen Oracle Database 11g’yi kullanım başlangıcından son dağıtıma kadar ilk yükleme,  yaratma ve konfigure edilmesini yönetmek ve bu yapıyı korumaktır. Bu görevleri uygulamak için Oracle ürünleri hakkında güçlü bir altyapıya sahip olmanız gerekmektedir ki uygulamalar için uygun araçları ve öznitelikleri seçebilesiniz. Bunlara ek olarak ilişkisel veritabanı konseptini bilmeniz dizayn, gerçekleştirim ve uygulama verilerinin saklandığı tabloların korunması için gereklidir. Bütün bunların yanı sıra Oracle mimarisini doğru anlamak araçları doğru bir şekilde yönetmek ve izlemek için çok büyük bir öneme sahiptir. Bu bölüme Oracle Veritabanının temellerini anlatarak başlayacağım.Genel bir bakış olarak bellek yapılarının, veritabanını yöneten proseslerin nasıl bir süreçte oluşturulduğunu ve verinin nasıl veritabanına kaydedildiğini öğreneceksiniz. Aynı zamanda araçların Oracle Database 11g’yi yönetmek için nasıl kullanılacağını ve Oracle 11g yazılımının nasıl yükleneceği de anlatılacaktır.

Oracle Veritabanı Temelleri

Veritabanları verileri depolamak için kullanılır. Verinin içeriğinde ilişkili mantıksal birimlerin bilgisi bulunmaktadır. Veritabanı yönetim sisteminin (VTYS) görevi verilerin depolanma şekilleri, modifikasyonları ve geri kazanımı işlemlerini sağlamaktır. Önceden kullanılan bazı veritabanları düz dosyaların veya hiyerarşik dosyaların uygulama verilerine saklanması için kullanılmıştır. Diğerleri ise verilerin set edilmesi sırasında depolanması ve konumunu bağlantı ağları kullanarak sağlamıştır. Eski VTYS mimarileri verinin fiziksel yapısıyla mantıksal yapısını birlikte kullanmıştır. Bu kullanım verinin yeri değiştirildiğinde uygulamanın veriyi güncellenmiş gibi algılamasına sebep olurdu. İlişkisel veri tabanı beraberinde veritabanı mimarisinde devrim niteliğinde değişikler getirmiştir. İlişkisel VTYS bizleri bağımsız veri kavramıyla tanıştırdı böylelikle verinin fiziksel modeli ile mantıksal modelinin ayrı kullanılabileceği ortaya gösterilmiştir. Oracle bir ilişkisel VTYS’dir.

Oracle’ın bütün veritabanı sürümleri ilişkisel VTYS modelini veritabanına veri depolamak için kullanmıştır. Bu ilişkisel modeller Dr. Edgar Codd 1970’de yayınlanan“A Relational Model of Data for Large Shared Data Banks” adlı kitabından esinlenilerek geliştirilmiştir. Dr. Codd’un modellini ilk benimseyen şirket olarak IBM bugün bütün ilişkisel veritabanında kullanılan bilgisayar dilinin –SQL- geliştirilmesine yardımcı olmuştur.  SQL dilinin en önemli özelliği ilişkisel veritabanıyla kompleks bilgisayar programları yazmadan kolayca erişebilmeniz ve verinin fiziksel olarak belleğin neresinde olduğuna bakmaksızın kolayca etkileşim kurabilmenizdir.



İlişkisel Veritabanı

İlişkisel veritabanı yönetim sistemi(İVTYS) kavramını oluşturan şey verinin ilişkisel nesne dizilerinde var olmasıdır. Verinin veritabanında saklanmasında kullanılan en temel şey tablodur.  İlişkiler, verinin tablonun hangi satır ve sütununda bulunduğu göz önüne alınılarak uygulanırlar. Şekil kurulan ilişkiyi göstermektedir.





Küçük olan şekilde görülen DEPT tablosu şirketin departman bilgilerini saklamaktadır. Her departmanın bir departman ID’si bulunmaktadır. Bu ID ile birlikte departmanın adı ve konumu da tabloda saklanmaktadır. EMP tablosu şirket çalışanlarının bilgilerini tutmaktadır. Her çalışan(employee) ayırıcı bir çalışan ID ye sahiptir. Bu tabloda hire date, salary, manager gibi çalışan bilgileri tutulmaktadır. İki tabloda da ortak olarak bulunan DEPTNO sütunu iki tablo arasında ilişkiyi sağlamaktadır. Bir departmanda çok sayıda çalışan bulunabilir ama bir çalışan sadece belirli bir departmanda çalışabilir.  Kullanıcı bu verilerden birine ulaşmak için satırların nasıl ve nereye saklandığı bilgisine ihtiyacı yoktur, her satırın ayırt edici bir özelliği olmak zorundadır. Örneğimizde departmanlar departman numaraları ile birbirlerinden ayırt edilebilir aynı şekilde çalışanlar birbirinden employee ID ile ayırt edilebilir. Satırları ayırt edici olarak ayıran kolanlar primary key olarak bilinir. İlişkisel teoriye göre ilişkisel veritabanındaki her tablo bir pirimary key’e sahip olmalıdır. İlişkili tablolar birleştirilirse primary keylere göre birleştirme yapılır böylelikle yeni bir tablo oluşturulabilir.  Örneğin, DEPT tablomuzun pirimary keyi  EMP tablosunda sütun olarak bulunmaktadır  İVTYS terminolojisinde bu sütun EMP tablosunun foreign key’ini oluşturur.  Bu foreign key’in varlığı bize bu verinin başka bir tabloda da var olduğunu ve iki tablo arasında ilişkiyi sağladığını gösterir. Primary keyin var olduğu tablo ana tablo olarak, foreign keyin var olduğu tablo da çocuk tablo olarak adlandırılır. Oracle Kısıtları(Constraint) kullanarak tablolar arasında ana-çocuk ilişkisi oluşmasını sağlar.

Oracle Database 11g Nesneleri

Her İVTYS veritabanı nesnelerinin çeşitliliğini destekler. Oracle 11g tablo, view, Constraint gibi ilişkisel veritabanı için gerekli olan bütün dizi nesnelerini destekler. Bu aynı zamanda geniş bir nesne gücünü Oracle 11g’nin özellikli olarak desteklediğini gösterir. Bunlara örnek olarak paketler, sequences ve uyarlanmış viewler verilebilir. Tablo 1.1 de Oracle Database 11g de yer alan nesneler listesi yer almaktadır.

Nesne Tipi

Tanımı

Tablo

Tablo temel veri depolama nesnesidir. Tablolarda verinin depolandığı satır ve sütunlar bulunmaktadır.

View

Bir nevi özelleştirilmiş tablodur ve tablolar üzerinde yapılan bir takım işlem sonucunda oluşturulurlar. Bellekte yer kaplamazlar dinamik olarak oluşturulup kullanılırlar.

Index

Verilerin yerleştirilmesi veya istenilen verilere ulaşılması için isteğe bağlı olarak kullanılan bir yapıdır. Veri ile olan işlemlerde pek çok kolaylık sağlar.

Materialized view

Bu yapı verilerin özetlenip saklanması için kullanılır. Viewlerle benzer bir yapıdadır fakat bellekte yer kaplarlar.

Index-organized

table

Bu yapı tabloları indeksleme-organize etme için primary keyleri kullanıp veri tablosunu indeks segmentine saklar.

Küme

Küme aynı bloklarda saklanan verilerin oluşturduğu gruptur.

Constraint

Veri bütünlüğünü güçlendirmek amacıyla saklanan kuraldır.

Sequence

Üretim sayısında sürekliliği sağlamak için bir mekanizma oluşturur.

Synonym

Veritabanı şema nesneleri için oluşturulan takma ad gibi kullanılan bir yapıdır.

Triggers

Trigger(Tetikleyici)  PL/SQL program birimidir ve bir olayın gerçekleşmesi sonucu çalıştırılır(örneğin veri silme sırasında çalıştırılır verinin silinmesi tetikler).

Stored function

PL/SQL programıdır ve kullanıcı tanımlı bir fonksiyonunda geri dönüş değeri ile kullanılabilir.

Stored procedure

PL/SQL programıdır ve iş sürecini tanımlar.

Package

Prosedür, fonksiyon ve başka bir programın kısıtlayıcılarından oluşan bir derlemedir.

Java

İş tanımlamak için Oracle tarafından oluşturulabilen saklı java prosedürleridir.

Database link

Database linkleri veritabanı ile paylaşılan veri arasında iletişimi sağlamak için kullanılır.

SQL’i veritabanı nesnesi oluşturmak ve uygulama verileri ile etkileşim sağlamak için kullanabilirsiniz. Önümüzdeki bölümde Oracle 11g veritabanını yönetmek için kullanılan araçları ele alacağız.

Oracle 11g ile etkileşim Kurma

Oracle 11g database ile etkileşim kurmak için kullanlılan dil SQL’dir. DBA’in bir Oracle 11g veritabanını yönetmesi için bir çok araç bulunmaktadır. En çok kullanılan araçlar aşağıda belirtilmiştir:

-SQL*Plus, komut satırı ara yüz aracıdır.

-SQL Developer, bir GUI aracıdır

-Oracle Enterprise Manager Database Control,  bir GUI aracıdır.

SQL*Plus ve SQL Developer’ı kullanarak direk olarak Oracle 11g veritabanı ile etkileşim kurabilirsiniz. Bu etkileşim SQL cümleleri ve STARTUP, SHUTDOWN gibi üst komutlar kullanılarak

oluşturulur. Enterprise Manager kullanarak ise dolaylı olarak Oracle 11g veritabanıyla etkileşim kurulabilir.


SQL*Plus

SQL*Plus Oracle DBA’in veritabanını yönetmek için kullandığı birincil araçtır ve SQL komutlarını kullanarak yönetir. SQL ifadelerini çalıştırmadan önce Oracle 11g veritabanına bağlanmanız gerekmektedir. SQL*Plus Windows komut istemi olan SQLPLUS.EXE ile çalıştırılabilir veya $ORACLE_HOME/bin/sqlplus  kullanılarak Unix/Lunix platformları için çalıştırılabilir. Şekil 1.2 SQL*Plus’a Lunix üzerinden nasıl bağlanılacağını göstermektedir.




SQL Developer

SQL Developer ücretsiz bir GUI veritabanı geliştirme aracıdır. SQL Developer ile veritabanı nesneleri oluşturulabilir ve görüntülenebilir, nesnelere değişiklik yapılabilir, SQL ifadeleri çalıştırabilir, PL/SQL programları çalıştırılabilir, oluşturulabilir,  düzenlenebilir ve hata ayıklaması yapılabilir.

SQL Developer aynı zamanda Microsoft Access ve Microsoft SQL Server veritabanlarını Oracle 11g’ye taşıma özelliğine de sahiptir. Şekil1.3de SQL Developer’ın ekran çıktısı görülebilir.






Enterprise Manager Database Control

Oracle Enterprise Manager Database Control Oracle 11g veritabanı ile birlikte gelen web tabanlı veritabanı yönetim aracıdır. Bu grafiksel araç Oracle veritabanını yönetmek için özel olarak tasarlanmıştır. Enterprise Manager Database Control bir veritabanını yönetebilirken Enterprise Manager Grid Control birden fazla veritabanı veya başka servis ve uygulamaları yönetebilir örnek olarak OAS ve Oracle dışında bir uygulamayı aynı anda yönetebilir. Şekil1.4  Enterprise Manager Control  ana sayfası ve veritabanının genel görünüşü gösterilmiştir.











Bu bölümdeki bütün veritabanı yönetimi örneklerinde SQL komut satırını gerçekleştirmek için SQL*Plus kullanılabileceği gibi GUI araçı olan Enterpirise Manager (EM) Database Control kullanılarak da yapılabilir. Oracle 11g veritabanını yönetmeyi öğrenmeden önce gelin önümüzdeki bölümde Oracle 11g mimarisinin temellerinden başlayalım.

Oracle 11g Mimarisi

Her veritabanı yönetim ve geliştirme araçları kullanıcının veritabanı ile etkileşim kurması için eski kullanımlara izin verir. Bu araçları kullanmak, kullanıcı hesaplarının veritabanında oluşturulabilmesi ve veritabanı bağlantısının bu bağlantı ağı üzerinde olmasını sağlamayı gerektirir. Aynı zamanda kullanıcı gireceği veriler için yeterli depolama alanına sahip olmalı ve oluşabilecek donanımsal bir hata için yedekleme ve kurtarma mekanizmasına da oluşturulmalıdır. DBA olarak bütün bu görevleri ve aşağıda belirtilen görevler ile beraber yerine getirmelisiniz:

-          Veritabanı yazılımının çalışacağı donanım sunucusunun seçilmesi

-          Donanım sürücüsüne Oracle 11g yazılımının yüklenmesi

-          Oracle 11g veritabanının oluşturulması

-          Uygulama verilerini yönetmek için kullanılacak tabloların ve diğer nesnelerin oluşturulması ve yönetimi

-          Veritabanı kullanıcılarının oluşturulması ve yönetilmesi

-          Veritabanı için güvenilir yedekleme ve kurtarma işlemleri Kurulması

-          Veritabanı performansının izlenmesi ve ayarlanması

Bu kitabın kalanında size bu görevlerin ve diğer önemli Oracle veritabanı yönetimi görevlerinin nasıl yerine getirilebileceğini anlatmaya çalışacağım. Ama önce Oracle DBA olarak başarılı olmak için Oracle’in arka plan mimarisini ve mekanizmasını tamamıyla anlamanız gerekmektedir. Oracle’ın hafıza yapısı, arka plan işlemleri ve I/O aktivitelerinin arasındaki ilişkileri anlaşılması bu alanların nasıl yönetileceğini öğrenmek için kritik bir öneme sahiptir.

Oracle sunucu mimarisi 3 kategoride açıklanabilir:

-          Kullanıcı tanımlı işlemler

-          Mantıksal bellek yapıları, Oracle instance olarak adlandırılır

-          Fiziksel dosya yapıları, veri tabanını oluştururlar

Ayrıca tablo ve indeks gibi nesnelere yabancı değilseniz fiziksel yapının veritabanının mantıksal yapısına nasıl bağlandığı da anlaşılacaktır.

Veritabanı sık sık farklı platformlarda farklı şeyler göstermek için kullanıldığından kafa karıştırıcı bir terimdir; tek ortak nokta ise veri depolama ile ilgili bir şey olduğudur. Oysa Oracle da veritabanı terimi, verinin depolandığı fiziksel dosyaları temsil eder. Oturum(Instance) Bellek yapısının ve arka plan işlemlerinin bulunduğu kısımdır. Her veritabanı en az bir oturuma sahip olmalıdır.  Çoklu oturumların bir veritabanına erişimi mümkündür; Gerçek Uygulama Kümeleri konfigürasyonu (RAC-Real Aplication Clusters) gibi.  Bu makalede sadece tek oturumlu veritabanları ele alınacaktır çünkü RAC sertifika sınavının konusu değildir.

Şekil 1.5’de Oracle oturumunun ve veritabanının bütün bölümleri gösterilmiştir.

Şekil 1.5deki mimari ilk bakışta karışık gelebilir, bütün bu mimari bileşenler ilerleyen bölümlerde kullanıcı tanımlı işlemlerden başlanılarak ayrıntılı olarak açıklandıktan sonra oldukça basit olduğu görülecektir. Bu şekil Oracle 11g mimarisini öğrenmek için temel bilgi olduğu için oldukça önemlidir.



** Anahtar veritabanı bileşenleri bellek yapıları, işlem yapıları ve depolama yapılarıdır. İşlem ve bellek yapıları beraber oturumu(instance) oluştururlar. Oturum ve veritabanı ise beraber Oracle server olarak adlandırılırlar.

Kullanıcı İşlemleri

Kullanıcı bölümünde iki tip işleme izin verilir ilki, kullanıcının oturum ile ilişki kurması ikincisi ise veritabanı ile kullanıcı işlemleri ve sunucu işlemleridir.

Kullanıcı insan kaynakları veya sipariş alma gibi bir uygulama yaptığı zaman, Oracle kullanıcın oturuma bağlanmasına destek olmak için kullanıcı işlemi başlatır. Uygulamanın teknik mimarisine dayanarak, kullanıcı işlemleri ya kullanıcının kişisel bilgisayarında veya orta katma uygulama sunucusunda oluşturulur. Kullanıcı işlemi daha sonra oturuma bağlantı oluşturur. Oracle kullanıcı işlemi ve oturum arasındaki bağlantı ile oluşturulmuş ve devam eden işlemi çağırır. Bağlantı bir kere oluşturulursa kullanıcı oturumda bir session oluşturur.

Çarşamba, 01 Aralık 2010 17:11

SQL Optimize Nedir ?

Bu yazimda Sql performans iyilestirme için ve veritabanina ulasimi optimize etmek amaçli kullanilan SQL optimizeri ana hatlari ile ve basit birkaç örnek vererek açiklamaya çalisacagim

Herhangi bir SQL sorgusu çalistirildiginda, istenilen bilgiye nasil ulasilacagina “Optimizer” adi verilen
veri tabani optimizasyon birleseni karar vermektedir. Oracle, kullanicilarina tahminler üzerine çalisan
“Rule-Based Optimizer” ve daha çok akil yürütme yöntemi ile çalisan “Cost-Based Optimizer” olmak
üzere iki adet optimizasyon seçenegi sunmaktadir.
Rule-Based Optimizer

Veri tabanina ulasilirken, Rule-Based Optimizer (RBO) ile önceden tanimlanmis kurallar seti
kullanilarak hangi yolun izlenecegine karar verilir. Burada bahsedilen kurallar “SELECT /*+ RULE
*/. . .” seklinde kullanilmaktadir ve böylece veri tabaninda hangi indeksin kullanilacagi gibi ek
bilgiler verilmektedir. Eger bu yöntem kullanilacaksa, RDBMS‘de asagidaki tanimlamalarin yapilmasi
gerekmektedir:
• INIT.ORA ya da SPFILE dosyasinda OPTIMIZER_MODE = RULE degisikligi yapilmalidir.
• ALTER SESSION SET OPTIMIZER_MODE = RULE komutu sistemde çalistirilmalidir.
Cost-Based Optimizer

Cost-Based Optimizer’in (CBO) Rule-Based Optimizer‘a göre daha kapsamli ve karisik bir çalisma
prensibi bulunmaktadir. Kullanilacak olan en iyi yöntemi belirlenirken, çesitli veri tabani bilgileri (tablo
boyutlari, kayit sayilari, verilerin dagilimi vs.) kullanilmaktadir.
Cost-Based Optimizer‘inin ihtiyaci olan veriyi saglamak için veri tabani objelerinin DBMS_STATS
prosedürü kullanilarak analiz edilmeleri ve istatistiklerinin toplatilmasi gerekmektedir. Eger bir tablonun
analizi yapilmamissa, Rule-Based Optimizer‘in kurallari kullanilarak yolu belirlenir. Ayni sorguda bazi
tablolar analiz edilmis ve bazilari analiz edilmemis ise, sistem öncelikli olarak Cost-Based Optimizer‘ini
kullanir. Eger bu yöntem kullanilacaksa; RDBMS‘de asagidaki tanimlamalarin yapilmasi
gerekmektedir:
• INIT.ORA/SPFILE dosyasinda OPTIMIZER_MODE = CHOOSE degisikligi yapilmalidir ve
sorgudaki tablolardan en az bir tanesinin istatistik bilgilerinin mevcut olmasi gerekmektedir.
• ALTER SESSION SET OPTIMIZER_MODE = CHOOSE komutu sistemde çalistirilmalidir ve
sorgudaki tablolardan en az bir tanesinin istatistik bilgilerinin mevcut olmasi gerekmektedir.
• ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS ( veya ALL_ROWS ) komutu
sistemde çalistirilmalidir ve sorgudaki tablolardan en az bir tanesinin istatistik bilgilerinin
hesaplanmis olmasi gerekmektedir.

SQL OPTIMIZASYON ÖNERILERI
Birden fazla sorgu kullanilmasi

Önerilmez

SELECT name
FROM products
WHERE product_id = 1;

SELECT type_name
FROM product_type
WHERE product_type_id = 1;

Önerilir

SELECT p.name,
pt.type_name
FROM products p,
product_type pt
WHERE p.product_type_id = pt.product_type_id
AND p.product_id = 1;

Önerilmez

SELECT product_id,
product_type_id,
name
FROM products
UNION
SELECT product_id,
product_type_id,
name
FROM more_products;

Önerilir

SELECT product_id,
product_type_id,
name
FROM products
UNION ALL
SELECT product_id,
product_type_id,
name
FROM more_products;

* not: sql tunning adli kaynaktan yararlanilmistir.

Çarşamba, 03 Kasım 2010 08:21

SQL Performans İyileştirme

Bu makalemizde SQL izleme yöntemlerini ve iyilestirme senaryolarina bakis açimizi irdeleyecegiz.Çogu kez raporlarimizin saatlerce çalistigi durumlar olmustur veya çok kisa sürede çalismasi gereken sorgularimizin neden uzun süre çalistigini merak etmisizdir.Simdi bu tip problemler için çözüm yöntemlerine kisaca bi bakalim

Neden SQL Izleme-Iyilestirme?


SQL iyilestirme islemi ile genel olarak sunlar hedeflenmektedir

 

  • Büyük tablolar üzerindeki gereksiz “full-table” erisimlerin indeksli erisime dönüstürülmesi,
  • Küçük tablolar üzerindeki “full-table” erisimleri cach’lemek,
  • Indeks kullaniminin optimum düzeyde oldugunu garantilemek,
  • Optimal JOIN teknikleri kullanmak,
  • Tune complex subqueries to remove redundant access

 

Ne Zaman SQL Izleme-Iyilestirme?

 

Bir SQL sorgusunun iyilestirilmesini çesitli kosullar tetikleyebilir. Bunlar arasinda kullanici tarafindan islemin uzun sürdügü seklinde yapilan geri bildirimler olabilecegi gibi, yapilan izleme, istatistik toplama çalismalari kapsaminda sorgunun fazla kaynak kullandiginin tespit edilmesi de yer alabilir. Üzerinde çalisilmasi gereken sorguya karar verildiginde, inceleme ve test çalismalarinin, olabildigi ölçüde uygulamadan ve diger ara katmanlardan bagimsiz olarak gerçeklestirilmesi yararli olacaktir. Buradaki amaç uygulamanin kendi yapisindan kaynaklanan farkli islemleri devre disi birakarak, sadece SQL’in optimizasyonuna yogunlasilmasidir. Bu nedenle, kullanilan izleme araçlari ile, sorunlu oldugu düsünülen SQL sorgusu tespit edildikten sonra dogrudan sorgu üzerinde çalisilmalidir.

 

Sorgularda dikkat edilmesi gereken bir diger husus da, “literal” veya “bind” kullanimidir. “Literal”de, asagidaki örnekte oldugu gibi, where kosulu içinde bir deger (value) belirtilmistir.

 

SQL> select ad,soyad from calisan where calisan_id=765;

 

“Bind”da ise asagida belirtildigi gibi bir parametre kullanimi vardir

 

SQL> select ad,soyad from calisan where calisan_id=:B1;

 

 

“Bind” ve “literal” kullanimda farkli çalisma planlari ortaya çikabileceginden, orijinal sorguda hangisi kullanilmissa, iyilestirme çalismalarinin da bunun üzerinde yogunlasmasi gerekir.

 

Production ortamindaki veritabanlarini olabildigi ölçüde yansitan test veritabanlari mevcut ise, sorgu iyilestirme çalismalarinin test veritabanlarinda yapilmasi daha saglikli olacaktir. Her sorgudan önce buffer cache’in flush edilmesi veya veritabaninin kapatilip açilmasi ile daha dogru ölçüm degerleri elde edilebilecektir.

 

SQL Izleme Yöntemleri

1. TRACE Kullanimi

 

TRACE, bir sorgunun, batch islemin veya tüm sistemin ölçümü için kullanilabilecek bir yöntemdir. Sistem üzerindeki darbogazlarin olustugu noktalarin tespiti için yararli olan genis kapsamli bir yöntemdir. TRACE

 

  • Sorguyu çalistirir, çalisan sorguyla ilgili olarak istatistik üretir,
  • Uygulama gelistiricilerin sorgunun her bir bölümünü analiz etmesine yardimci olur.

 

TRACE ile yapilan izlemede, user_dump_dest initora parametresi ilen belirtilen dizine ora_nnnnn.trc söz diziminde bir trace dosyasi olusturulur.

 

TRACE’in bulunulan session’dan baslatilmasi mümkün oldugu gibi, bir baska session’in çalismasi da izlenebilir.

 

Bulunulan session için TRACE islemi :

 

SQL> alter system set timed_statistics=true;

SQL> alter session set max_dump_file_size=20000;

 

SQL> show parameter user_dump

 

NAME TYPE VALUE

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

user_dump_dest string /usr/oracle10/rdbms/log/udump

 

SQL> alter session set SQL_TRACE true;

 

SQL> select MUSTERI_ADI from MUSTERI where MUSTERI_NO=1;

 

..

 

SQL> select * from dual;

 

SQL> alter session set SQL_TRACE false;

 

Dump dosyasinin olustugu dizinde, ilgili trace dosyasinin içerigi incelenir.

 

 

Dump file /usr/oracle10/rdbms/log/udump/tst1_ora_1105.trc

……

=====================

PARSING IN CURSOR #1 len=32 dep=0 uid=0 oct=42 lid=0 tim=164924072960 hv=789637826 ad='7b4fa270'

alter session set sql_trace true

END OF STMT

EXEC #1:c=1952,e=2048,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=164924072960

*** SESSION ID:(1633.1093) 2007-05-16 13:55:46.154

=====================

PARSING IN CURSOR #5 len=28 dep=0 uid=0 oct=3 lid=0 tim=164932504576 hv=4187904027 ad='7b29b108'

select MUSTERI_ADI from MUSTERI where MUSTERI_NO=1;

……

 

Baska session için TRACE islemi :

 

Izlenmesi istenen sesssion’a ait SID ve SERIAL# bilgileri elde edilir (Örnek olarak TEST kullanicisi seçilmistir).

 

SQL> alter system set timed_statistics=true;

 

SQL> alter session set max_dump_file_size=20000; -- OS block

 

SQL> select SID, SERIAL# from v$session where username=’TEST’;

 

SID SERIAL#

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

163 110

 

Elde edilen bu SID ve SERIAL# degerleri, asagidaki sekilde kullanilarak trace baslatilir.

 

SQL>execute dbms_system.set_sql_trace_in_session('163','110',true);

 

 

Trace’in sonlandirilmasi için ayni komut, false parametresi ile çalistirilir (Asagidaki komu isletilmezse izlenen kullanicinin o session’dan çikana kadar yapacagi sonraki islemler de ayni trace dosyasina eklenir).

 

SQL>execute dbms_system.set_sql_trace_in_session('163','110',false);

 

Dump dosyasinin olustugu dizinde, ilgili trace dosyasinin içerigi incelenir.

 

 

Dump file /usr/oracle10/rdbms/log/udump/tst1_ora_1105.trc

……

=====================

PARSING IN CURSOR #1 len=32 dep=0 uid=0 oct=42 lid=0 tim=164924072960 hv=789637826 ad='7b4fa270'

alter session set sql_trace true

END OF STMT

EXEC #1:c=1952,e=2048,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=164924072960

=====================

PARSING IN CURSOR #5 len=28 dep=0 uid=0 oct=3 lid=0 tim=164932504576 hv=4187904027 ad='7b29b108'

select MUSTERI_ADI from MUSTERI where MUSTERI_NO=1;

……

 

2. EXPLAIN PLAN Kullanimi

 

EXPLAIN PLAN ile, sorgu çalistirilmaksizin, Oracle optimizer tarafindan izlenecek plan görüntülenir. Bu yöntem, sorgunun çok uzun sürdügü durumlarda tercih edilebilir. Sorgunun süresine, getirecegi kayitlara ihtiyaç olmadan sadece çalisma planinin elde edilmesi için yararlidir.

 

  1. Izleme islemini yapacak kullanicinin öncelikle bir PLAN_TABLE tablosuna sahip olmasi gerekir. Genellikle $ORACLE_HOME/rdbms/admin dizini altina yer alan utlxplan.sql script’i, izleme islemini yapacak kullanici tarafindan SQL*Plus’tan çalistirilir.

 

SQL> @utlxplan

 

  1. Izlenecek sorgu SQL*Plus’tan asagidaki sekilde çalistirilir.

 

SQL> explain plan

set statement_id=’MUSTERI’ for

select MUSTERI_ADI

from MUSTERI

where MUSTERI_NO=1;

 

  1. Plan, asagidaki sorgu ile görüntülenir.

 

SQL> select lpad(‘ ‘,2*(level-1)) || operation || ‘ ‘

|| options || ‘ ‘ || object_name || ‘ ‘ ||

Decode(id,0, ‘Cost = ‘ || position) “Query Plan”





About me

Sakarya Üniversitesi Bilgisayar Mühendisligini bitirdikten sonra kariyerime özel bir sirkette Danisman olarak devam etmekteyim.

Datawarehouse sistemlerin ve mimarilerin , dwh'a bakis açisini incelemek ve küçükte olsa bunlar hakkinda bilgi vermek amaciyla bu siteyi kurduk.Bunun yani sira diger sistemlere de dokunduk ve Türkçe makaleler paylastik.

Yazarlarimiz; Muhammet Ali Yurtçiçek, Ercan Yazgan, Samet Aslan,Ali Yildiz,Emin Sayan,Ömer Faruk Gül,Mustafa Aksoy,Burak Kutbay'dir.

 

Son Yazılar

Hangi Yazılım Dilini Kullanıyorsunuz








Sonuçlar
You are here