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 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…

 

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.

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.

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”