Oracle –ÇözümPark

Kurumsal firmalarda uzun bir zamandır hem databasehemdeoperatingsytem seviyesinde şirket için gizli ve değerli bilgilerin bir takım kullanıcılar tarafından şirklet dışına çıkartılması veya bu bilgilerin şirket içerisinde kötü amaçlarla kullanılmasnıönlemek için firmalar çok çeşitli yöntemler kullanmaya başlamışlardır. Bir oracledba olarak burada database seviyesinde kullanıcıları nasıl izleyebiliriz, bunu yaparken nelere dikkat etmeliyiz gibi bir takım teknik konulara değineceğiz.

Oracle‘ dakiaudit mekanizmasının biraz tarihçesine inersek, 1992 yılında oracle 7 sürümüyle tüm auditözelliklerini içeren ilk veritabanı olma, 1994 yılında ise bağımsız güvenlik kuruluşlarından onay alan ilk veritabanı olma özelliiğinede sahiptir. Bu açıdan düşünüldüğünde oracleveritabanı diğer ilişkisel veritabanları arasında güvenilirliğini ile ilk sırada yer almayı başarmış bir veritabanıdır.

Peki Auditing nedir? Özetle, seçilen bazı userların (veya hepsinin) database içerisinde yapmış olduğu aktivitelerin monitör edilmesi ve sonra kayıt altına alınarak saklanması işlemine auditing diyebiliriz. Bu monitöring ve kayıt altına alma işlemi, kullanıcı adı, işlemin yapıldığı an, hangi uygulama kullanılarak yapıldığı, hangi makine üzerinden sisteme giriş yapıldığı gibi bilgileri kapsar. Bir işlemin auditlenmesi için mutlaka başarılı olması gerekmemektedir, başarısız olan tüm işlemlerde izlenebilmektedir. (başarız olan işlemler kimi zaman başarılı olanlardan daha fazla önem taşırlar. Sürekli olarak birinin, sistemde yer alan bir kullanıcı adı ile sisteme giriş yapmayı denemesi şüphelenmek ve araştırmak için yeterli bir nedendir.)

Neden Aduting yapılmaya ihtiyaç duyulur? Bunun nedenleri ana hatlarıyla;

· Yapılan İşlemlere Ait Sorumluları Tespit Etmek İçin;

· Davetsiz Misafirleri Caydırmak İçin,

· Şüpheli İşlemleri Araştırmak için,

· Yetkisiz Kullanıcıya Ait İşlemleri Tespit Etmek ve Denetime Bildirmek İçin,

· Özel bir database işlemi ile ilgili istatistik toplama ve monitor etmek için,

· Yetki ve Erişim Kontolleri ile Problemleri Tespit Etmek İçin.

Neden auditing yapacağımıza karar verdikden sonra, karar verilmesi gereken 2 konu karşımıza çıkmaktadır. Bunlardan birincisi, nelerin audit edileceğine ikincisi ise audit kayıtlarının nerede saklanacağına karar vermekteir. Database’ deki her oturumu her işlemi auditlememelisiniz, sonuçta bu kayıtların tutulması için de bir kaynak kullanılması gerekmektedir ki, audit kayıtları yanlış bir konfigurasyonlaçok hızlı büyüyebilir ve sizi olmadık bir anda zor durumda bırakabilir. Sorun sadece kaynak problemi değildir aslında, yapılan auditing işleminin sisteme getirdiği ek bir performans kaybı olmaktadır. Dolayısıyla herşeyiauditlemek kimi zaman çözüm olmakdan uzak bir hal almaktadır. Bir diğer neden ne kadar çok auditin işlemi yaparsanız o kadar çok incelemeniz, denetlemeniz gereken kayıt ortaya çıkacaktır.

Audit işlemleri ile ilgili olarak nasıl yapılacağı konusu aslında ne tarz bir auditing metodu uygulayacağınızla birebir ilişkilidir. Audit yöntemlerinden bahsedelim biraz;

1 -Genel Aktivitilerin Standart Auditing ile Auditlenmesi;

Satndartauditing, SQL statamentlerın, yetkilerin, schema objelerinin ve networkdekiaktivitilerinauditlenmesidir. Standart auditing AUDIT komutu ile başlatılır, NOAUDIT komutu ile sonlandırılır. Bu auditing işlemi AUDIT ANY yetkisi ile AUDIT SYSTEM yetkisine sahip herhangi bir kullanıcı yapabilir.

Audit kayıtları, güvenlik işinden sorumlu adminindatabase seviyesinde auditingienable etmesiyle başlar. Auditing enable edilmesiyle, databaseçalışan SQL statementınınçalışmasından sonra bir audit kaydı üretir. Üretilen bu audit kaydı kullanıcının transactionıcommit etmesinden bağımsızdır. Aynı şekilde başlatılan bir rollbackişlemide yine yeni bir audit kaydı oluşturur.

Burada AUDIT_TRAIL parametresi önemlidir, database tarafından tespit edilen audit kayıtlarının nerede ve nasıl saklanacağının belirlendiği parametredir. Bu parametrenin şu anki değerini görmek için;

SQL> showparameteraudit_trail;

NAME TYPE VALUE

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

audit_trail string NONE

Şu an bu değer NONE olduğundan dolayı auditingözelliği bu database’ de disable anlamına gelmektedir. AUDIT_TRAIL parametresi statik bir parametre olduğundan dolayı yapılan değişikliğin geçerli olması için database’ in restart olması gerekmektedir. Değişikliği yapmak içinse;

SQL> showuser

USER is "SYS"

SQL> ALTER SYSTEM SET AUDIT_TRAIL=DB SCOPE=SPFILE;

Systemaltered.

SQL> shutdownimmediate;

Database closed.

Database dismounted.

ORACLE instanceshutdown.

SQL> startup

ORACLE instancestarted.

Total System Global Area 419430400bytes

Fixed Size 1249368 bytes

Variable Size 96473000bytes

Database Buffers 314572800bytes

RedoBuffers 7135232 bytes

Database mounted.

Database opened.

SQL>

Komutlarından faydalanılabilir. Buaradaaudit_trail parametresini “db” olarak set ettik. Bunun anlamı ve diğer alternatiflerini şöyle özetleyebiliriz;

DB ; Audit kayıtlarının database’ de tutulması anlamına gelir. Bu kayıtlar database’ de sys.aud$ tablosunda saklanır. (sysuserına ait audit kayıtları hariç, sysuserına ait audit kayıtlar OS’ ye yazılır) Audit_trail parametresi DB olarak set edili iken database’ i readonlymodda açmak isterseniz, database size aşağıdaki gibi hata dönecektir. Bunun nedeni, audit_traildb olarak set edili iken database’ i readonly olarak açmak istiyorsanız önce audit_trail parametresini ya OS yada NONE olarak set etmeniz gerektiğidir (readonly modda iken audit kayıtlarını database’ e write edemeyeceğinden dolayı).

SQL> startupmount

ORACLE instancestarted.

Total System Global Area 419430400bytes

Fixed Size 1249368 bytes

Variable Size 100667304bytes

Database Buffers 310378496bytes

RedoBuffers 7135232 bytes

Database mounted.

SQL> alterdatabaseopenreadonly

2 /

alterdatabaseopenreadonly

ERROR at line 1:

ORA-16006: audit_traildestinationincompatiblewithdatabaseopenmode

SQL> selectopen_modefromv$database ;

OPEN_MODE

----------

READ WRITE

SQL> showparameteraudit_trail;

NAME TYPE VALUE

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

audit_trail string DB

SQL>

OS; Audit kayıtları operating sistemde belirtilen bir path’ de saklanır. Buraya file bazında çıkan dosyalar .aud uzantılı olur. Burada iki farklı parametre daha var set etmemiz gereken, AUDIT_FILE_DEST parametresi audit kayıtlarının nerede tutulacağının set edildiği parametredir. Aşağıdaki şekilde set edilebilir;

altersystem set AUDIT_FILE_DEST ='d:\oracle11gR2\audit' scope=spfile;

Diğer parametre SYS userınınauditlenipauditlenmemesi ile ilgili, eğer SYS userınınsessionlarıdaauditlenecekse AUDIT_SYS_OPERATIONS parametresi TRUE olarak set edilmelidir.

Altersystem set AUDIT_SYS_OPERATIONS=TRUE scope=spfile;

10g’ de olmayan, 11g ile yeni gelen bir parametremiz daha var; AUDIT_SYSLOG_LEVEL parametresi. Bu parametre sadece Unix ortamlarda kullanılmaktadır. Bu parametre manuel olarak initSID.ora dosyasına eklenilerek set edilebilir. İki farklı değer alabilir;

Facility;İşletim sistemi' nin, mesajı loglayan bölümünü ifade eder. Kabul ettiği değerler; user, local0–local7, syslog, daemon, kern, mail, auth, lpr, news, uucp ve cron.

Local0 – local7 arasındaki değerler, syslog mesajlarını kategorize etmemize olanak sağlayan önceden tanımlanmış etiketlerdir. Bu kategoriler, syslog aracının ulaşabileceği log dosyaları veya diğer dizinler olabilir. Bu etiket tipler ile ilgili ayrıntılı bilgi için, syslog aracının MAN sayfasına bakabilirsiniz.

Priority; Mesajın öncelik derecesini belirler. Kabul ettiği değerler, notice, info, debug, warning, err, crit, alert ve emerg’ dir.

Bu parametreyi database’ e set etmek için;

ALTER SYSTEM SET AUDIT_TRAIL=DB SCOPE=SPFILE;

Komutundan faydalanabiliriz.

DB, EXTENTED ; Audit kayıtları sys.aud$ tablosuna kaydedilir aynı zamanda Sqlbind değerleri ile sqltext’ deki Clobbilgileride bu tabloda tutulur.

Aşağıdaki gibi 2 farklı şekilde set edilebilir.

ALTER SYSTEM SET AUDIT_TRAIL=DB, EXTENDED SCOPE=SPFILE;

ALTER SYSTEM SET AUDIT_TRAIL='DB','EXTENDED' SCOPE=SPFILE;

Aşağıdaki gibi bu iki kriteri tek tırnak içerisinde kullanılmamalıdır;

ALTER SYSTEM SET AUDIT_TRAIL='DB, EXTENDED' SCOPE=SPFILE;

XML ; Auditing kayıtları operatingsystem de xml dosyası olarak saklanır. XML formatındaki audit kayıtlarının defaultlokasyonuwindows’ da dahil olmak üzere tüm platformlarda; $ORACLE_HOME/admin/$ORACLE_SID/adumplokasyonudur.

Sys ve zorunlu audit dosyalarını operating sisteme XML fromatında yazmak için ; Audit_trail = XML orXML,ExTENDED, AUDIT_SYS_OPERATIONS=TRUE fakat AUDIT_SYSLOG_LEVEL parametresi set edilmemiş olmalıdır.

Sys ve zorunlu audit kayıtlarını syslogAudit file’ lerine, Standart Audit kayıtlarını XML Audit file’ lerine yazmak için; Audit_trail = XML orXML,ExTENDED, AUDIT_SYS_OPERATIONS=TRUE ve AUDIT_SYSLOG_LEVEL parametreside set edilmiş olmalıdır.

Bu parametreyi database’ e set etmek için ;

ALTER SYSTEM SET AUDIT_TRAIL=XML SCOPE=SPFILE;

Komutundan faydalanabiliriz.

XML, EXTENTED ; Auditing kayıtları operatingsystem de xml dosyası olarak saklanır aynı zamanda Sqlbind değerleri ile sqltext’ deki Clobbilgileride burada saklanır.

Bu parametreyi set etmek içinde aşağıdaki iki komuttan biri kullanılabilir.

ALTER SYSTEM SET AUDIT_TRAIL=XML, EXTENDED SCOPE=SPFILE;

ALTER SYSTEM SET AUDIT_TRAIL='XML','EXTENDED' SCOPE=SPFILE;

Aşağıdaki gibi çalıştırılmamalıdır;

ALTER SYSTEM SET AUDIT_TRAIL='XML, EXTENDED' SCOPE=SPFILE;

NONE ; Auditingdisable anlamına gelir.

Audit_trail parametresini DB olarak set ettiğimizde belirlediğimiz auditkriterlerine uygun sessionlar geldikçe bu tabloda dolmaya başlayacaktır.

selectsessionid, userid, userhost, terminal, action# fromsys.aud$

SESSIONID USERID USERHOST TERMINAL ACTION#

14708 KAMIL WORKGROUP\KHOME KHOME 101

Burada action alanı çalıştırılan sql komutunun kodunu ifade etmektedir. Hangi kodun hangi komuta denk geldiğini aşağıdaki sorgu ile çekebilirsiniz.

Select * from AUDIT_ACTIONS ;

Ile sorgulayabilirsiniz.

Biraz da AUDIT ve NOAUDIT komutlarının nasıl çalıştığından bahsedelim.

Audit veya Noaudit komutları sisteme gönderilirken komut sonlarında yer alan aşağıdaki 3 parametre önemlidir;

· WHENEVER SUCCESSFUL cümlesi; herhangi bir audit veya noaudit komutunun sonunda bu cümle yer alıyorsa, çalıştırılan komut başarılı olmak kaydıyla auditleneceği veya auditlenmeyeceği anlamına gelir. Yani başarısız olan komut üzerinde işlem yapılmaz.

· WHENEVER NOT SUCCESSFUL cümlesi; Eğer komutun sonunda bu cümle yer alıyorsa, başarısız olan komutların auditleneceği veya auditlenmeyeceği anlamına gelir. Başarılı olan komut üzerinde işlem yapılmayacak demektir.

· Her İkiside kullanılmazsa; Çalıştırılan Audit/Noaudit komutu içerisinde yukarıda belirtilen kısımlar kullanılmaz ise, hem başarılı hemdebaşarız tüm işlemlerin auditleneceği/auditlenmeyeceği anlamına gelir.

Örneğin;

AUDIT CREATE TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;

Bu script ile createtablescriptiniçalıştıran tüm userlar içerisinde sadece başarız olanlar (çalıştırdığı komutu hata verenler) auditlenecek demektir.

Oracleaudit komutlarında BY ACCSESS cümleciğini kullanmayı önerir. Oracle 11gR2 ile birlikte audit komutunun sonunda byaccsess cümleciği kullanılmasa bile defaultunda yer aldığı için kullanılacaktır. Bu komutu kullanmanın bir takım avantajları vardır. Bu avantajları özetleyecek olursak;

· BY ACCSESS komutu kullanıldığında, elde edilen audit kayısında daha fazla bilgi yer alacaktır. Örneğin, executionstatus (returncode), execution zamanı vetarihi, kullanılan privilege, sqltext’ i ve bindvariable değerleri gibi . Ek olarak BY ACCSESS kullanımı ile yapılan işleme ait SCN ‘ ıda kaydettiğinden geri dönüş gibi bir aksiyon alınması gerektiğinde bu bilgi ile Flashback komutları kullanılarak çok rahat eski veriye ulaşım sağlanabilecektir.

· Oracledatabase’ i çalışan her bir sqlstatement’ını, kullanılan bir privilege‘ ı ve auditlenen her nesneye erişimi kaydeder. Bu kayıtlar neticesinde bu işlemin kaç defa yapıldığını bulmanıza da yardımcı olur.

· BY ACCSESS audit kayıtlarında oturum açma ve kapatma kayıtlarını fine-grained zamanları ile birlikte tutar.

BY ACCSESS kullanımına örnek olarak;

AUDIT SELECT TABLE BY ACCESS;

Spesifik bir Usera ait işlemlerin Auditlenmesi;d

Örneğin, Kamil ve Hakan userınınçalıştırmış olduğu tüm selectler ile Updateleriauditlenmesini istersek;

AUDIT SELECT TABLE, UPDATE TABLE BY KAMIL, HAKAN BY ACCESS;

Başlıklar altında örnek scriptlerbaşlangıçda az gibi algılanabilir.

NOAUDIT Komutunun Çalıştırılması;

Audit edilen bir nesne, systemprivilege, veya bir kullanıcının audit edilmesini n kaldırılması, iptal edilmesini sağlar. NOAUDIT komutunda WHENEVER SUCCESSFUL ve WHENEVER NOT SUCCESSFUL kullanımına dikkat edilmelidir, burada da AUDIT’ dekine benzer bir kullanım sözkonusudur, bu cümle NOAUDIT komutunun sonunda kullanılmazsa başarılı/başarısız tüm işlemler audit kapsamı dışına çıkarılmış olur.

Auditişlemlerleri ile ilgili olarak konu içerisinde vermiş olduğum örnekler ileride konular detaylandıkça artacağından şu aşamada konunun anlaşılması için yeterli olacağını düşünüyorum.

SQL Cümlelerinin Auditlenmesi ;

Database de yapılan tüm selectleri ayırt etmeksizin auditlemek istersek;

AUDIT SELECT TABLE BY ACCESS;

Komutundan faydalanabiliriz.

Eğer tüm SQL komutlarını auditlemek istiyorsanız, userconnectionlarını veya var olmayan nesnelere ait referanslar için aşağıdaki adımları izleyebilirsiniz;

· Userların tüm SQL Statement’ larınınAuditlenmesi ; ALLSTATEMENTS cümleciği ile sadece top-level SQL sorguları auditlenebilir. Bu audit seçeneği diğer audit seçeneklerinden farklıdır. Eğer sqlstatement’ ı pl/sqlproceduru içerisinden çalıştırılıyorsa, All Statement opsiyonu bunları auditlemeyecektir. Bu auditopsiyonu diğer set edilmiş olan audit opsiyonlarından etkilemez.

Kullanımı ile örnek;

      AUDIT ALL STATEMENTS BY KAMIL BY ACCESS WHENEVER SUCCESSFUL;

· Userlar tarafından çalıştırılan tüm Sql Statement’ larının (Komutların Kısayollarıİl e) Auditlenmesi ;

Burada ifade edilmek istenen İndex, Procedure, Database Link vs. gibi bazı komutların kısayolları ile bu komutlar ile yapılan tüm işlemleri auditleyebilirsiniz. Oracle’ da çok fazla sayıda komut olduğundan dolayı komutlara ait kısayolları buraya yazmaktansa merak edenler aşağıdaki linkden bunlara ulaşabilirler;

http://download.oracle.com/docs/cd/E11882_01/server.112/e17118/statements_4007.htm#SQLRF53735

Bu konuyla ilgili örnek olarak;

        AUDIT ALL BY KAMIL BY ACCESS;

verebiliriz.

· Kullanıcı Ayıt Etmeksizin Geçerli Oturumdaki Tüm SQL StatementlarınınAuditlenmesi ; All Statement audit seçeneği için IN SESSION CURRENT cümleciği ile top-levelsqlstatementlarınısession sonlanmadığı sürece audit edebilirsiniz. Bu auditi NOAUDIT ile sonlandıramazsınız fakat usersessionıdiscconect olduğunda zaten auditte sonlamış olacaktır.

Örneğin, mevcut bir sessinındaki tüm işlemleri auditlemek için;

         AUDIT ALL STATEMENTS IN SESSION CURRENT BY ACCESS WHENEVER NOT SUCCESSFUL;

komutunu kullanabilirsiniz.

· Login ve logout’ larınAudilenmesi ; İsterseni z AUDIT_SESSION komutu ile tüm login ve logooutlarıauditleyebilirsiniz.

Örneğin,

        AUDIT SESSION BY ACCESS;

Sadece belli bir kullanıcının login ve logoutlarınıauditlemek isterseniz,

        AUDIT SESSION BY kamil BY ACCESS;

Komutunu kullanabiliriz.

· Object doesn’ t exist hatasıyla fail olan sqlstatementlarınınAuditlenmesi ; NOT EXIST cümleciği ile object doesn’ t exist hatasıyla fail olan sorguları auditleyebilirsiniz.

Örneğin,

AUDIT NOT EXIST ;

SQL Stamentları ile İlgili Audintingleri Sonlandırmak İçin;

NOAUDIT komutu ile SQL statementlarıüzerindeki auditingleri sonlandırabiliriz. Bu komutu çalıştırmadan önce mutlaka çalıştıracak olan kullanıcının AUDIT SYSTEM yetkisine sahip olmalıdır. AuditAllStatements seçeneği ile set edilmiş olan autiler, NoauditAuditStatements ile kaldırıldığında, bu işlemden diğer auditkonfigurasyonları etkilenmeyecektir. Daha öncede belirttiğimiz üzere InSessionCurrent cümleciği ile set edilmiş olan auditlerNoaudit ile geri alınmazlar, bu auditing işlemi session sonlandığında bitecektir.

Noaudit ile ilgili örnek olarak aşağıdaki komutları verebiliriz;

NOAUDIT session;

NOAUDIT session BY kamil;

NOAUDIT DELETE ANY TABLE;

NOAUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE ;

NOAUDIT ALL STATEMENTS;

Privilege ile İlgili Audit Seçeneklerinin Configure Edilmesi;

Haklar ile ilgili audit seçenekleri, ilgili ayrıcalığın ismine karşılık gelen sistem hakları ile aynıdır. Örneğin, Deleteanytable komutunun auditlenmesi ;

AUDIT DELETE ANY TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;

AUDIT DELETE ANY TABLE BY ACCESS;

AUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE BY ACCESS WHENEVER NOT SUCCESSFUL;

şeklindedir.

Bu auditlerüzerindeki auditing işleminin kaldırılması ise, yine benzer bir mantıkla ;

NOAUDIT ALL PRIVILEGES;

NOAUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE;

Schema Objelerinin Auditlenmesi ;

Konuyu biraz daha spesifiklendirebiliriz, yani tüm select komutlarını auditlemekistemiyde sadece x userının altındaki bir tabloyu auditlemek isteyebiliriz.

AUDIT SELECT ON owner.tablename BY ACCESS;

AUDIT SELECT ON owner.viewname BY ACCESS;

AUDIT DELETE ON laurel.emp BY ACCESS;

AUDIT SELECT, INSERT, DELETE ON hr.dept BY ACCESS WHENEVER SUCCESSFUL;

AUDIT SELECT ON DEFAULT BY ACCESS WHENEVER NOT SUCCESSFUL;

AUDIT EXECUTE ON procedure_name BY ACCESS;

AUDIT INSERT TABLE BY ACCESS;

Schema Objelerinin Auditlerinin Kaldırılması;

Schema nesneleri üzerindeki auditingi kaldırmak için yine Noaudit komutundan faydalanabiliriz;

NOAUDIT DELETE ON emp;

NOAUDIT SELECT, INSERT, DELETE ON hr.dept;

NOAUDIT ALL ON emp;

NOAUDIT ALL ON DEFAULT;

Bu radaON DEFAULT cümleciğinden bahsetmek gerekebilir. Aşağıdaki örnek üzerinden açıklamaya çalışalım.

AUDIT ALL ON DEFAULT BY ACCESS;

Bu komut ile aşağıdaki komutların hepsi etkilenecektir.

Alter , Execute, İnsert, Select , Audit, Grant, lock, Update, Comment, Flashback, Read, Delete, Index, Rename .

On default yerine spesifik olarak neleri auditleyeceğinizi siz belirlemek isterseniz, örneğin;

AUDIT ALTER, DELETE ON DEFAULT BY ACCESS;

İle yapabilirsiniz.

Directory’ lerinAuditlenmesi;

Directoryler içerisindeki nesneleri auditleyebilirsiniz. Örneğin, bir directory içerisine create ettiğiniz bir programı, kimin çalıştırdığını auditleyebilirsiniz. Bunu yaparken aşağıdaki komuttan faydalanabiliriz;

AUDIT EXECUTE ON DIRECTORY my_directory BY ACCESS;

Audit işlemini iptal etmek içinse;

NOAUDIT EXECUTE ON DIRECTORY my_directory;

komutunu kullanabiliriz.

Tüm Function, Procedure, Package ve Trigger’ larıAudit Etmek İçin;

AUDIT EXECUTE PROCEDURE BY ACCESS;

User bazında bu işlemi yapmak istersek;

AUDIT EXECUTE PROCEDURE BY psmith BY ACCESS;

Schemaİçerisinden Procedure veya FunctionExecute Edildiğinde Auditlemekİçin;

AUDIT EXECUTE ON HR.check_work BY ACCESS WHENEVER SUCCESSFUL;

Function, Procedure , Packages ve Trigger’ lar Üzerindeki Auditingi Kaldırmak İçin;

Noaudit komutu ile kaldırılabilir.

NOAUDIT EXECUTE PROCEDURE;

NOAUDIT EXECUTE PROCEDURE BY kamil;

NOAUDIT EXECUTE ON sales_data.checkwork;

Networkü Auditlemekİçin;

Network üzerinden yapılan işlemleri auditlemek istiyorsak;

AUDIT NETWORK BY ACCESS;

Bu auditingi kaldırmak içinse;

NOAUDIT NETWORK;

komutlarından yararlanabiliriz.

2. Güvenlik ile İlgili SQL Komutlarının ve Yetkilerin Varsayılan Olarak Auditlenmesi ;

Çok kullanılan bir yöntem olmamakla beraber, bu konuya da açıklık getirmekte fayda var. Dbca ile database’ i create ederken, oracledatabase’i auditiçok sık kullanılan güvenlikle ilgili sqlstatementlarını ve haklarını auditleyecekşekilde set eder.

Oracledatabasedefault olarak aşağıdaki yetkileri auditler.

ALTER ANY PROCEDURE	CREATE ANY LIBRARY	DROP ANY TABLE
ALTER ANY TABLE	CREATE ANY PROCEDURE	DROP PROFILE
ALTER DATABASE	CREATE ANY TABLE	DROP USER
ALTER PROFILE	CREATE EXTERNAL JOB	EXEMPT ACCESS POLICY
ALTER SYSTEM	CREATE PUBLIC DATABASE LINK	GRANT ANY OBJECT PRIVILEGE
ALTER USER	CREATE SESSION	GRANT ANY PRIVILEGE
AUDIT SYSTEM	CREATE USER	GRANT ANY ROLE
CREATE ANY JOB	DROP ANY PROCEDURE

3. Spesifik Olarak Fine-grainedActivitilerininAuditlenmesi;

Fine-grainedauditing i kullanmak için, istenilen durumları içeren policiler oluşturup sonrasında bu policy’ leriauditleyebilirsiniz. FGA aslında audit işleminin yapılan aktivitiye göre özelleştirilmesidir şeklinde tanımlayabiliriz.

FGA insert, update ve delete gibi operasyonları ile ilgili sqlquery’ lerininauditlenmesine de olanak sağlar.

FGA adutinglog kayıtları sys.fga_log$ tablosuna kaydedilir. Bu kayıtlar DBA_FGA_AUDIT_TRAIL view’ inden select edilebilir. DBA_COMMON_AUDIT_TRAIL viewi standart ve fga kayıtlarını combine eder. Ayrıca audit_trail kayıtları XML file’ lere yazılacak şekilde set edilmişse V$XML_AUDIT_TRAIL view’ i kullanılarak select edilebilir.

Fga sadece bizim istemiş olduğumuz spesifik alanlar üzerinde yapılan işlemleri auditlememizi sağlar. Böylelikle bizim için daha anlamlı sonuçlar oluşturur. Durum böyle olduğunda gereksiz audit kayıtlarının oluşmasını n önüne geçilmiş olunur. FG auditingi kullanabilmek için sys’ ninşemalarından DBMS_FGA package’ ınaexecute yetkisinin olması yeterlidir.

FG auditpolicymanage etmek için dbms_fgapackage’ ından faydalanabiliriz. Bu package ile tek policy ile tüm kombinasyonları (select, insert, update, delete) komutlarının audit edilmesini enable edebiliriz. Burada önemli bir nokta policy’ i create ettikden sonra modify edemiyoruz onun yerine drop– cerate ederek yenisini oluşturuyoruz. DBMS_FGA’ ın tüm değişkenleri ile birlikte kullanımı aşağıdaki gibi,

DBMS_FGA.ADD_POLICY(

object_schema VARCHAR2,

object_name VARCHAR2,

policy_name VARCHAR2,

audit_condition VARCHAR2,

audit_column VARCHAR2,

handler_schema VARCHAR2,

handler_module VARCHAR2,

enable BOOLEAN,

statement_types VARCHAR2,

audit_trail BINARY_INTEGER IN DEFAULT,

audit_column_opts BINARY_INTEGER IN DEFAULT);

Kullanımına geçmdenönce burada sık kullanılan değişkenler üzerinde biraz bahsedebiliriz;

· Object_schema ; Hangişemasnın altındaki objectauditlenecekse, bu şemanın belirlendiği parametre,

· Object_name ; Auditlenecek olan object’ in isminin belirlendiği parametre,

· Policy_name ; oluşturulan bu policy’ e istenirse ismin verildiği parametre, unigue bir alandır, kullanılan bir isim bir daha kullanılamaz.

· Audit_condition ; Auditlenecek olan sqlstatementlarındawherecondition’ı içerisinde geçecek olan alanı ifade eder. Null olarak set edilirse ve bu parametre kullanılmaz ise tüm aktivitelerin auditleneceği anlamına gelir.

· Audit_column ; spesifik bir kolon auditlenecek ise bunun set edildiği parametre,

· Enables ; TRUE ise policy enable demektir, defaultdeğeride TRUE’ dur,

· StatementsTypes ; Hangisqlstatementınınaudit edileceğini belirten parametredir (sadece select, insert, update, delete’ i içerir. Bu ğernull gönderilirse default değeri SELECT olduğundan buna göre policy’ i set edilecektir. )

· Audit_trail ; fgaudit kayıtları için destination DB veya XML set edilebilir, (default değeri db+extented‘ dır)

Tüm parametreleri ile package’ ı aşağıdaki şekilde kullanabiliriz ;

Begin

DBMS_FGA.ADD_POLICY (

object_schema => 'scott',

object_name => 'emp',

policy_name => 'mypolicy1',

audit_condition => 'sal < 100',

audit_column => 'comm,sal',

handler_schema => NULL,

handler_module => NULL,

enable => TRUE,

statement_types => 'INSERT, UPDATE',

audit_trail => DBMS_FGA.XML + DBMS_FGA.EXTENDED,

audit_column_opts => DBMS_FGA.ANY_COLUMNS);

end ;

Create edilmiş olan policy dolayısıyla auditidisable etmek için aşağıdaki sytax kullanılabilir, bunlarla ilgili örnekleri aşağıda bulabilirsiniz;

Begin

DBMS_FGA.DISABLE_POLICY(

   object_schema  VARCHAR2,

   object_name    VARCHAR2,

   policy_name    VARCHAR2 );

end;

Package içerisinde object_schema parametresini göndermeniz, database otomatik olarak sisteme connect olmuş olan userı dikkate alacaktır.

Var olan bir policydrop etmek içinse ;

Begin

DBMS_FGA.DROP_POLICY(

   object_schema  VARCHAR2,

   object_name    VARCHAR2,

   policy_name    VARCHAR2 );

end ;

systax’ dan faydalanabiliriz.

Bir örnekle yaptıklarımızı açıklamaya çalışalım. Scottscheması altındaki emp tablosunda yapılan işlemleri scott_emp_policy adı ile bir policy oluşturup auditmeleyeçalışalım.

Begin

DBMS_FGA.DROP_POLICY (

object_schema   =>  'scott',

object_name     =>  'emp',

policy_name     =>  'scott_emp_policy');

end ;

Dikkat ederseniz statement_type parametresi kullanmadım, dolayısıyla auditpolicy’ imiz sadece bu tabloya yapılan selectleriauditleyecektir.

Şu anda disable olan bir policy’ i tekrar aktive etmek içinse;

Begin

DBMS_FGA.ENABLE_POLICY(

   object_schema  VARCHAR2,

   object_name    VARCHAR2,

   policy_name    VARCHAR2,

   enable         BOOLEAN);

end ;

komutundan faydalanabiliriz. Örneğin.

Begin

DBMS_FGA.ENABLE_POLICY (

object_schema    =>  'scott',

object_name      =>  'emp',

policy_name      =>  'mypolicy1',

enable           =>   TRUE);

end ;

Daha anlaşılması için örnekleri biraz daha detaylandıralım;

BEGIN

  DBMS_FGA.ADD_POLICY(

   object_schema      => 'HR',

   object_name        => 'EMPLOYEES',

   policy_name        => 'chk_hr_employees',

   policy_owner       => 'SEC_MGR',

   enable             =>  TRUE,

   statement_types    => 'INSERT, UPDATE, SELECT, DELETE',

   audit_trail        =>  DBMS_FGA.DB);

END;

Tukarıdakişekilde policy’ i oluşturdukdan sonra aşağıdaki gibi sql’ lerauditleniyor olacaktır.

SELECT COUNT(*) FROM HR.EMPLOYEES WHERE COMMISSION_PCT = 20 AND SALARY > 4500;

SELECT SALARY FROM HR.EMPLOYEES WHERE DEPARTMENT_ID = 50;

DELETE FROM HR.EMPLOYEES WHERE SALARY > 1000000;

Spesifik bir schema altında yer alan bir tablodaki özel bir (yada birden fazla) kolunu, istediğimiz bir kondition gerçekleştiğinde auditlemek istiyorsak createpolicypackage’ ına aşağıdaki kısımlarıda aeklememiz gerekir;

audit_condition    => 'DEPARTMENT_ID = 50',

audit_column       => 'SALARY,COMMISSION_PCT,'

Fine– Grating yöntemi oluşan audit kayıtlarını UTL_MAIL package’ ınıkullarak sonuçları istenilen kullanıcılara mail attırabiliriz. Bunun için oracledocumentation’ dan UTL_MAIL package’ ının kullanımı ile ilgili ayrıntılı bilgi alabilirsiniz.

Bir başka örnek olarak;

BEGIN

 DBMS_FGA.ADD_POLICY(OBJECT_SCHEMA => 'OE',

   OBJECT_NAME                     => 'ORDERS',

   POLICY_NAME                     => 'ORDERS_FGA_POL',

   AUDIT_CONDITION                 => 'SYS_CONTEXT(''USERENV'', ''CLIENT_IDENTIFIER'') = ''Robert''',

   HANDLER_SCHEMA                  => NULL,

   HANDLER_MODULE                  => NULL,

   ENABLE                          => True,

   STATEMENT_TYPES                 => 'INSERT,UPDATE,DELETE,SELECT',

   AUDIT_TRAIL                     => DBMS_FGA.DB + DBMS_FGA.EXTENDED,

   AUDIT_COLUMN_OPTS               => DBMS_FGA.ANY_COLUMNS);

END;

systaxı kullanılabilir.

4. Admin Userlarının (SYS) Auditlenmesi ;

Sys userını veya sistemde sysdba veya sysoper yetkisine sahip olan tüm kullanıcıları auditleyebilirsiniz. Sysuserınınauditlenmesi ile ilgili olarak bir takım faklılıklar mevcut, örneğin sys’ yiauditliyorsanızaudit_trail parametreniz ne olarak set edilmiş olursa olsun (None, Db, Xml, EXTENDE) sysuserıauditlenir ve bu audit kayıtları operating sisteme file olarak yazar. Sysuserınınaudit kayıtlarını operating sisteme yazması, sys.aud$ tablosuna yazmasından çok daha güvenlidir, sysuserı zaten sysdba yetkisine sahip olduğundan dolayı tabloya müdahale edebilir yani burdaki bir takım audit kayıtlarını delete edebilir, bu yöntem ile bu tarz kötü davranışların önüne geçilmesi planlanmıştır.

Sysuserınınauditlenmesi ile ilgili özel bir parametrenin ( AUDIT_SYS_OPERATIONS) tanımlanması gerekmektedir. Yapılacak değişiklik aşağıdaki gibidir;

ALTER SYSTEM SET AUDIT_SYS_OPERATIONS=TRUE SCOPE=SPFILE;

Audit_trail parametresi zaten set edilmiş olmalı ;

ALTER SYSTEM SET AUDIT_TRAIL=XML, EXTENDED SCOPE=SPFILE;

Son olarak database’ i restart ediyoruz. Sonrasında sysuserına ait tüm işlmler artık auditleniyor olacaktır.

Buraya kadar 4 tane audit yöntemi üzerinde konuştuk. Her yöntemde audit kayıtları DB olarak seçilirse, bu kayıtlar SYSTEM tablespace’ inde tutulur. Bizim için SYSTEM tablepace’ i kritik önem taşıdığından dolayı bu tarz verilerin systemtablespace’ i dışında farklı bir yerde tutulmasını isteriz. Bu tarz bir işlemi gerçekleştirmek isterseniz aşağıdaki adımları kullanarak yapabilirsiniz;

Öncelikle audit kayıtlarımızın tutulduğu tablespace’ lerin hangi tablespace’ de olduğunu kontrol etmekle başlayalım ;

SELECT table_name, tablespace_name

FROM dba_tables

WHERE table_name IN ('AUD$', 'FGA_LOG$')

ORDER BY table_name;

TABLE_NAME TABLESPACE_NAME

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

AUD$ SYSTEM

FGA_LOG$ SYSTEM

Gördüğünüz gibi SYSTEM tablespace’ i içerisinde yer alıyorlar. Şimdi yeni oluşturacağımız bir tablepace‘ e taşıyalım.

Yeni bir tablespacecreate edelim;

Createtablespaceonly_audit datafile‘c:\oracle11gR2\audit\’ size 10M ;

Aşağıdaki pl/sql ile taşıma işlemi yapıyoruz.

BEGIN

DBMS_AUDIT_MGMT.set_audit_trail_location(

audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,

audit_trail_location_value => 'ONLY_AUDIT');

END;

Son durumu kontol edelim.

SELECT table_name, tablespace_name

FROM dba_tables

WHERE table_name IN ('AUD$', 'FGA_LOG$')

ORDER BY table_name;

TABLE_NAME TABLESPACE_NAME

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

AUD$ ONLY_AUDIT

FGA_LOG$ ONLY_AUDIT

ve taşıma tamamlanmış oldu.

Oracle da özellikle 11gR2 ile gelen yeni değişikliklerden de bahsederek audit kavramını açıklamaya çalıştım. Umarım faydalı olmuştur.

Adım adım OE Linux 5.3 Üzerine İki Düğümlü Oracle 11g R2 RAC Kurulumu

OE Linux 5.3 üzerine iki düğümlü Oracle 11g R2 Real Application Clusters(RAC) kurulumu 4 safhaya ayırmaktayım.

A. Linux üzerinde kurulum öncesi yapılandırma.

B. Oracle Grid Infrastructure yazılımının kurulumu.

C. Oracle Database yazılımının kurulumu.

D. Oracle veritabanı oluşturma.

Her bir adımın uygulamasına geçmeden önce Oracle RAC konseptine kısa bir göz atalım.

Oracle 11g R2 RAC mimarisi konsepti ve gelen yenilikler

Oracle Database 11g Release 2 itibariyle, Oracle Clusterware ve Oracle ASM, grid home olarak adlandırılan aynı tekil dizine kurulmaktadır. Oracle grid mimarisi kombine ürünlerin kurulumuyla adlandırılmaktadır.Ancak, Oracle Clusterware ve Oracle ASM ayrı ürünlerdir.

Birden fazla sunucunun Oracle Clusterware ve Oracle RDBMS yazılımlarını kullanarak, tek bir veritabanı üzerinde ve aynı zamanda (aktif/aktif) işlem yapabilmesine olanak sağlayan teknolojiye Oracle Real Application Cluster denir.Oracle RAC yapısının çekirdeğini yine Oracle tarafından geliştirilen “Cache Fusion” teknolojisi oluşturmaktadır.Cache fusion teknolojisi birden fazla instance‘a ait ön bellek alanlarının kaynaştırılarak, tek bir önbellek alanı şeklinde kullanılmasıdır. Sonuç itibariyle cache fusion ‘ın görevi veritabanının tek bir instance tarafından yönetiliyormuş gibi davranmasını sağlamaktır.

Oracle Clusterware sunuculara host veya düğümler olarak bakarak birden fazla sunucunun tek bir sunucu gibi işlev görmesine imkan vermektedir.Halbuki sunucular bağımsızdır ve her bir sunucunun diğer sunucular ile iletişimini sağlamak için ilave prosesleri vardır.Bu şekilde tek bir veritabanı birden fazla sunucunun üzerinde düğümler olarak adlandırılan yapıda çalışırken her bir sunucunun donanım kaynakları ayrı ayrı paylaşımda olmaktadır. Böylece birden fazla sunucudan oluşan düğümlerde paylaşımlı bellek ve prosesleri için tahsis edilen kaynaklar düğüm sayısına parallel arttığından bellek ve proses performanslarındada yüksek oranda iyileşmeler meydana gelmektedir. Oracle Clusterware yazılımı Oracle Real Application Clusters hizmetinin çalışması için gerekli mimariyi desteklemektedir.

Oracle veritabanı, instance ve veri dosyaları arasında bire bir ilişki içindeyken, Oracle RAC veritabanı instancelar ve veri dosyaları arasında birçok ilişik içindedir.Bu sebeple veri dosyaları paylaşımlı bir depolama alanında tutulmalı ve Clusterware kurulu tüm düğümlerin bu paylaşımlı depolama alanına erişiminin sağlanması gerekmektedir.Her bir instance kendi bellek yapısını ve arkaplan prosesleri belirtmektedir.

Sunucu havuzları(server pools) Oracle 11g R2 ile yeni gelen özelliklerden bir tanesidir ve cluster ortamında iş yükünün mantıksal dağıtımı ile ilgili yeni konseptler getirmektedir. Sunucu havuzlarının kullanımının sağlanması için ilke bazlı(policy based) cluster yönetimi adı altında bir teknoloji ile sağlanmaktadır. Hem uygulamaları, hemde veritabanı instanceları ilke bazlı olarak sunucu havuzları içinde yönetilebilmektedir.

Sunucu havuzu, aslında RAC ortamında clusterware hizmetinde arzu edilen mantıksal işyükünü sağlayacak olan düğüm sayısını optimal seviyede tutarak(aktif/aktif), varsa diğer düğümleride yedekte bekleterek(pasif), bir felaket anında <- havuz içindeki düğümlerden birisi erişilemez olursa -> bu yedekteki düğümü havuza dahil ederek mantıksal işyükünü her daim optimal seviyede bulundurmayı sağlamaktadır. Bu şekilde, havuzlar mantıksal olarak işlevsellik yapmakta olup, aslında kümelerin cluster içindeki yönetimini sağlamaktadır.

Oracle Automatic Storage Management (ASM) yüksek performanslı ve entegre bir volume yöneticisi ve dosya sistemidir. Oracle Database 11g Release 2 sürümü itibariyle, Oracle ASM’ye ait disk gruplarında, clusterware tarafından kullanılan OCR ve voting diskleri saklayabilmekteyiz. OCR ve voting diskler Oracle clusterware tarafından kulanılan parçalardır.İsterseniz kısaca bu iki parçanın ne olduğuna bakalım;

OCR(Oracle Cluster Registry) disk kümeyi yönetir ve RAC veritabanı yapılandırma bilgilerini tutan dosyadır.
Voting disk ise düğümler arası üyelik bilgilerini yöneten dosyadır.

Oracle 11g R2 ile yeni gelen One Node(Tekli düğüm) teknolojisi ile Oracle RAC teknolojisinin failover ve yüksek erişilebilirlik nimetlerini kullanarak cluster içinde tek bir instance çalıştırılabilmektedir. Veritabanının RAC veritabanı olarak kurulması gerekmesine rağmen birden fazla düğüm yerine sadece tek bir düğüm seçilerek kurulum sağlanabilmektedir.Eğer bu düğüme bir şey olursa, bu tekli düğüm üzerindeki veritabanı başka uygun bir düğüme taşınabilmektedir.

Oracle RAC kurulumu ve yapılandırmasında kullanılan araçlar aşağıda yer almaktadır.

Oracle Universal Installer (OUI)–Oracle grid mimarisi yazılımını kurmaya yarayan grafiksel arayüzlü sihirbaz(Oracle Clusterware and Oracle ASM den oluşmaktadır)
Cluster Verification Utility (CVU)– Kümeleme ortamını doğrulamak için kullanılan komut satırı aracıdır. Kurulum öncesi olduğu kadar kurulum sonrasında kümeleme ortamının kontrol edilmesinde kullanılmaktadır.
Oracle Enterprise Manager(OEM)– Tekli instance veya Oracle RAC ortamının yönetilmesini sağlayan web tabanlı grafiksel arayüzlü araçtır.
Server Control (SRVCTL) - Oracle Cluster Registry (OCR) içinde belirtilen kaynakları yönetmek maksadıyla kullanılan komut satırı aracıdır.
Cluster Ready Services Control (CRSCTL)- Oracle Clusterware bünyesindeki servisleri yönetmek için kullanılan komut satırı aracıdır. Bu servisler Cluster Synchronization Services (CSS), Cluster-Ready Services (CRS), and Event Manager (EVM) dir.
Database Configuration Assistant (DBCA)— Oracle veritabanı kurmak ve yapılandırmak için kullanılan grafiksel arayüzlü araçtır.
Oracle Automatic Storage Management Configuration Assistant (ASMCA)— Oracle ASM instanceları, disk gruplarını ve volume ları kurmak ve yapılandırmak için kullanılır. Hem grafiksel arayüzlü hemde komut satırından kullanılabilir.
Oracle Automatic Storage Management Command Line utility (ASMCMD)— Oracle ASM instanceları ve Oracle ASM disk grupları yönetmek, disk grupları için dosya erişim kontrolü yapmak ve Oracle ASM disk grupları içinde dizin ve dosyalarının yönetimini yapmak için kullanılan komut satırı aracıdır.
Listener Control (LSNRCTL)—Listener yönetiminde kullanılan komut satırı aracıdır.

ASMCMD, srvctl, sqlplus, veya lnsrctl komutlarını ASM veya clusterware sistemini yönetmek için kullanırken Oracle veritabanı dizini yerinde Grid dizini içindeki binary dosyaları çalıştırın.Bu sebeple yönetim yapılacakken ORACLE_HOME değişkeninin geçici olarak grid dizinini gösterin.

srvctl, sqlplus veya lnsrctl komutlarını veritabanı veya listenerları yönetmek için kullanılacaksa ORACLE_HOME değişkeninin Oracle veritabanı dizinini işaret etmesi gerekmektedir.

Oracle Clusterware dosyaları 11g R2 sürümünden itibaren blok veya raw cihazlar üzerinde kurulumu desteklenmemektedir.

A. Kurulum öncesi gereksinimler

Donanım gereksinimleri.
Network donanım gereksinimleri.
IP adres gereksinimleri.
İşletim sistemi ve yazılım gereksinimleri.
Sunucuyu grid mimarisi kurulumu için hazırlama.

Donanım Gereksinimleri:

Kümeleme için grid mimarisinde en az 1.5 GB RAM olmalıdır.Oracle RAC için ise ilave en az 1 GB RAM olmalıdır. RAM değerini öğrenmek için aşağıdaki komutu çalıştırabilirsiniz.

# grep MemTotal /proc/meminfo

Swap alanı için ise en az 1.5 GB boş alana gereksinim vardır. Oracle swap alanının hesaplanmasında aşağıdakileri tavsiye eder. Tabii bunlar minimum gereksinimlerdir.

- 2GB RAM değerinde veya daha az olan sistemlerde mevcut RAM değerinin 1.5 katı

- 2 GB ve 16 GB RAM arası sistemlerde swap alanı RAM ile aynı tutun.

- 16 GB RAM üzerindeki sistemlerde swap alanını 16GB de sabitleyin.

Swap alanı bilgilerini almak için;

# grep SwapTotal /proc/meminfo

/tmp içindeki geçici alan boyutu en az 1GB olmalıdır,ancak ihtiyaç olduğu durumlarda fazla olmasında sakınca yoktur.

# df -h /tmp

Grid home dizini için en az 4.5 GB disk alanına gereksinim duyulmaktadır.

Network Donanım Gereksinimleri:

Her bir düğümde en az iki adet network arayüz kartı(NIC) bulunmalıdır. Bir adaptor public network arayüzü kullanımı için, diğeri(private arayüz) ise düğümlerin birbiriyle iletişiminde kullanılmak içindir. Eğer Network Attached Storage(NAS) kullanılıyorsa ilave olarak bir adet NIC daha bulunmalıdır.

Bunun yanında, umumi arayüz isimleri her düğümde aynı olmalıdır.Eğer bir düğümde kullanılan public arayüz ismi eth0 ise, diğer tüm düğümlerdede public arayüz ismi eth0 olarak adlandırılmalıdır.Keza aynısı private arayüz ismi içinde geçerlidir.

Private network adaptörleri yüksek hızda network adaptörlerini kullanarak UDP protokolünü desteklemeli, ayrcıa TCP/IP destekli network switchleride desteklemelidir.

IP Adres Gereksinimleri:

Oracle 11g R2 itibariyle SCAN adı verilen ve istemcilerin kümeye servis erişimini sağlayan yeni bir sanal network arayüz yöneticisi gelmiştir. SCAN farklı 3 adet IP adrese sahiptir ve cluster ismi ile tanımlanmaktadır.Düğüm mantığı yerine cluster katmanında hizmet vermektedir. İstemci bağlantı talebinde bulunduğunda, bu istemciye vekaleten SCAN IP adres üzerinden dinlemede olan SCAN listener ve bu scan listenerın portu üzerinden bu talep karşılanır. Cluster içindeki tüm servisler, SCAN listerenera kayıtlı olduğundan, istemcinın bu bağlantı talebini cluster üzerindeki en az yük olan düğüme ait lokal listenere yönlendirerek bu hizmeti sağlar. Yeni düğümler eklendiğinde ve mevcut düğümlerden biri erişilemez olduğunda yeni yük dengesini SCAN hesaplar ve değişikliğe paralel olarak istemci bağlantı metriksini günceller.

SCAN ile VIP IP adresler birbirinden tamamen farklıdır. VIP IP adresi, SCAN sonucu sağlanan cluster servisleri aracılığıyla, istemcinin o düğümde açtığı oturumu sağlayan ve yöneten public IP adresidir ve aslında lokal listenerı işaret etmektedir.Düğümlerdeki listener.ora dosyası içindeki HOST parametresinin işaret ettiği adres işte bu Virtual IP adresi olmalıdır.

SCAN listener için DNS sunucusu kullanılmalıdır. Bu sebeple, kuruluma başlamadan önce DNS sunucusunun hazırlanması gerekmektedir. DNS sunucunuzda aşağıdaki girişleri manuel olarak ekleyiniz.

i) Her bir düğüm için public IP adresi

ii) Her bir düğüm için virtual IP adresi

ii) Single client access name (SCAN) adresleri

SCAN adresler için kullanılan IP adresler VIP adresler ile aynı subnet içinde olmalıdır ve kurulumdan önce çekilecek ping komutlarına cevap vermemesi gerekmektedir.

İşletim Sistemi ve Yazılım Gereksinimleri:

Hangi Linux versiyonunun kullanıldığını belirlemek için;

# cat /proc/version

Oracle 11g R2 sürümünü destekleyen Linux versiyonunu kullandığınızdan emin olmanız gerekmektedir.

Chipset versiyonunu öğrenmek için ise;

# uname–m

Mesela 64-bit mimarisi için sonuç "x86_64" şeklide olacaktır.Oracle 11g R2 sürümü, 32 bit chipset üzerine kurulamamaktadır.

Kernel ve errata versiyonunu öğrenmek için ise;

# uname–r

2.6.9-55.0.0.0.2.ELsmp

Grid mimarisini kurarken eğer eksik Linux paketi varsa sihirbaz bu paketleri listeleyecek ve bu paketlerin kurulmasını talep edecektir.Bu eksik paketleri bu aşamada alttaki komutu çalıştırararak yükleyebiliriz.

# rpm -Uvh <paket_ismi>

Grid Mimarisi Kurulumu İçin Sunucunun Hazırlanması

RAC düğümleri arasında saatin senkronize edilmesi:

Oracle Clusterware 11g R2 (11.2), Oraclere RAC yayınlanırken kümeleme içersindeki tüm düğümler arasında saat senkronizasyonuna gereksinim duymaktadır.Aşağıdaki komut tüm düğümler üzerinden aynı saatin ayarlanmasını sağlayacak grafiksel arayüz programını çalıştıracaktır.

# dateconfig

Ancak saat formatının kalıcı olarak ayarlanması için Network Time Protocol (NTP) veya Oracle Cluster Time Synchronization Service(octss) servislerinden birisi üzerinden bu ayarlamanın yapılması tavsiye edilmektedir.

Benim tavsiyem; Oracle Cluster Time Synchronization Servisi ile herhangi bir harici saat sunucusu ile irtibat kurmaya gerek duymadan tüm küme düğümleri arasında saat senkronizasyonun dahili olarak Oracle tarafından yapılandırılması ve takip edilmesi olacaktır.

Eğer Cluster Time Synchronization Servisi ile küme içinde saat senkronizasyonunu sağlamak istiyorsanız Linuxüzerinde Network Time Protocol (NTP) servisini iptal etmeli ve kaldırmalısınız.

NTP’yi devredışı bırakmak için;

# /sbin/service ntpd stop

# chkconfig ntpd off

# rm /etc/ntp.conf

Ayrıca alttaki girişide sistemden kaldırmanız gerekmektedir;

/var/run/ntpd.pid

Gerekli oracle kullanıcısı ve gruplarını oluşturma ve gerekli Oracle dizinlerinin oluşturularak oracle kullanıcısına gerekli izinlerin atanması. Tüm düğümlerde yapılıyor.

# groupadd -g 1000 oinstall

# groupadd -g 1200 dba

# useradd -u 1100 -g oinstall -G dba oracle

# mkdir -p /u01/app/11.2.0/grid

# mkdir -p /u01/app/oracle

# chown -R oracle:oinstall /u01

# chmod -R 775 /u01/

# passwd Oracle

Linux kernel parametre değerlerinin ayarlanması:

/etc/sysctl.conf dosyasını açarak aşağıdaki kernel değerlerini giriyoruz.Kernel parametre değerlerinin ne anlama geldiği ve sisteminize en uygun değerleri nasıl hesaplayacağınız ile ilgili benimle irtibata geçebilirsiniz.Bu işlemleri tüm düğümlerde yapıyoruz.

#vi /etc/sysctl.conf

kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144

Oracle 11gR2 itibariyle kurulum sihirbazı kernel.sem parametreleri eğer eksik ayarlanmışsa veya boşsa herhangi bir uyarı mesajı vermemektedir ve kurulum sonrasında ciddi sıkıntılar yaşabileceksiniz.

/etc/security/limits.conf dosyası içinde aşağıdakileri ekliyoruz.

oracle soft nproc 2047

oracle hard nproc 16384

oracle soft nofile 1024

oracle hard nofile 65536

/etc/pam.d/login dosyasında tek satır olarak “session required pam_limits.so” değerini ekliyoruz.

Oracle kullanıcısı profile dosyasının ayarlanması:

Oracle kullanıcısı olarak oturum açarak .bash_profile dosyası içerisine aşağıdaki değerleri giriyoruz.Bu işlemi tüm düğümlerde yapıyoruz.ORACLE_SID ve ORACLE_HOSTNAME her düğümde ilgili düğümü işaret etmelidir.

ORACLE_HOSTNAME=linux1.localdomain; export ORACLE_HOSTNAME

ORACLE_UNQNAME=rac; export ORACLE_UNQNAME

ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE

ORACLE_HOME=$ORACLE_BASE/product/11.2.0/db_1; export ORACLE_HOME

ORACLE_SID=rac1; export ORACLE_SID

ORACLE_TERM=xterm; export ORACLE_TERM

PATH=/usr/sbin:$PATH; export PATH

PATH=$ORACLE_HOME/bin:$PATH; export PATH

LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH

CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib; export CLASSPATH

if [ $USER = "oracle" ]; then

if [ $SHELL = "/bin/ksh" ]; then

ulimit -p 16384

ulimit -n 65536

else

ulimit -u 16384 -n 65536

Network yapılandırmasının yapılması

Cluster ismini belirleyin. Benim senaryomda cluster ismi rac olacaktır.
Küme içindeki her bir düğüm için public(umumi), private ve sanal(virtual) host isimlerini belirleyin.

Linux1 hostu için public host ismi à linux1

Linux2 hostu için public host ismi à linux2

Linux1 hostu için private host ismi à linux1-priv

Linux2 hostu için private host ismi à linux2-priv

Linux1 hostu için virtual host ismi à linux1-vip

Linux2 hostu için virtual host ismi à linux2-vip

Her bir düğümde tüm network adaptörleri için atanan IP adreslerini ve arayüz isimlerini belirlemek için alttaki komutu çalıştırabiliriz.

# /sbin/ifconfig

Her bir düğümde bir network adaptörüne statik olarak public bir IP adresi atayın.bu public IP adresinin DNS üzerinde kayıt edilmesi gerekmektedir.

Aynı zamanda düğümlerde public subnetten başka bir subnet içinde yer alan IP bloğundan private IP adresleri atayın.Bu private IP adresler eğer DNS içinde kayıtlı değillerse, her bir düğümde bunları /etc/hosts dosyası içerisine ekleyiniz. Tüm düğümlerin private IP adresleri her bir düğümdeki hosts dosyasında yer almalıdır.

Her bir düğüm için virtual IP adreslerini tanımlayın.Bu adresler ve isim DNS üzerinde kayıt edilmelidir. Virtual IP adreslerin public IP adreslerden farklı olması, ancak aynı subset içinde olması gerekmektedir. Virtual IP adresler clusterware kurulumundan sonra erişelebilir olacaktır.

Her 3 IP adresini DNS içinde çözebilecek SCAN belirlememiz gerekmektedir.Benim tüm IP adres atamaların aşağıdaki tabloda yer almaktadır.

Kimlik	Host Düğüm	İsim	Tipi	Adres	Statik / Dinamik	İsim çözümleme metodu
Düğüm 1 Public	rac1	rac1	Public	192.168.2.101	Static	DNS
Düğüm 1 virtual	Oracle Clusterware seçecek	rac1-vip	Virtual	192.168.2.103	Static	DNS ve/ veya hosts dosyası
Düğüm 1 private	rac1	rac1-priv	Private	192.168.0.101	Static	DNS veya hosts dosyası
Linux 2 Public	rac2	rac2	Public	192.168.2.102	Static	DNS
Düğüm 2 virtual	Oracle Clusterware seçecek	rac2-vip	Virtual	192.168.2.104	Static	DNS ve/veya hosts dosyası
Düğüm 2 private	rac2	rac2-priv	Private	192.168.0.102	Static	DNS veya hosts dosyası
SCAN vip 1	Oracle Clusterware seçecek	rac	Virtual	192.168.2.105	Static	DNS
SCAN vip 2	Oracle Clusterware seçecek	rac	Virtual	192.168.2.106	Static	DNS
SCAN vip 3	Oracle Clusterware seçecek	rac	Virtual	192.168.2.107	Static	DNS

/etc/resolve.conf dosyası içine DNS sunucusunun adresini eklememiz gerekmektedir.

# vi /etc/resolve.conf

192.168.2.1

Paylaşımlı depolama alanının yapılandırması

Oracle RAC herşeyi paylaşır.Tüm veri dosyaları, clusterware dosyaları, veritabanı dosyaları umumi bir alanı paylaşmak zorundadır.Oracle, ASM tipi paylaşımlı depolama kullanılmasını tavsiye etmektedir.

Oracle Clusterware dosyaları veya Oracle Veritabanı dosyaları olarak ASM kullanıldığı takdirde, veritabanı sayısına bağlı olmaksızın her bir düğümde sadece bir adet Oracle ASM instance oluşturulur.

Depolama alanının ASM yapısını destekleyecek şekilde hazırlanması gerekmektedir. Sunucu yeniden başlatıldığında, eğer cihaz kalıcılığı için özel dosyalar hazırlamadıysanız kapanmadan önce /dev/sdg olarak beliren bir disk, /dev/sdg olarak değişebilir ve aynı zamandada sistem yeniden başladığında sahipliklerdede değişiklik meydana gelmiş olabilir. Bunun üstesinden gelmek için en basit metod Linux ASMLIB RPM paketinin yüklenmesidir.ASMLIB yazılımı Oracle ASM ile kullanılan depolama cihazlarında kalıcı hedefler ve izinler sağlamaktadır, ayrıca edev veya devlabel dosyalarının hedef ve izinleri için güncelleme ihtiyacını ortadan kaldırmaktadır.

ASMLIB RPM paketi aşağıdaki linkten indirilebilmektedir.Kernel versiyonunuz ile aynı versiyon numarasına sahip ASMLIB rpm paketini indirmeniz gerekmektedir, aksi durumda sorunlar yaşarsınız.

Oracle download sitesindeki download tabından "Linux Drivers for Automatic Storage Management" seçmeniz gerekir. Herbir Linux versiyonu için ayrı ayrı ASMLIB RMP paketleri vardır(SuSE Linux Enterprise Server 11, SuSE Linux Enterprise Server 10, Red Hat Enterprise Linux 5 AS, Red Hat Enterprise Linux 4 AS, SuSE Linux Enterprise Server 9, Red Hat Enterprise Linux 3 AS, SuSE Linux Enterprise Server 8 SP3, Red Hat Advanced Server 2.1. gibi). Ayrıca OS listesi altından, oracleasmlib ve oracleasm-support paketlerini indirin.Aynı zamanda bu paketler ile uyumlu olan kernel paketinide indirmeniz gerekmektedir.uname -r komutu ile sunucunuzun kernel versiyonunu görebilirsiniz. Mesela, eğer kernel verisyonu 2.6.18-194.8.1.el5 ise bu durumda oracleasm driver sürücüleri için kernel 2.6.18-194.8.1.el5 olmalıdır.

ASMLib 2.0 yazılımı toplamda 3 Linux paket setinden oluşmaktadır(kırmızı değerler benim girişlerimdir):

oracleasmlib-2.0 - Oracle ASM kütüphanesi

oracleasm-support-2.0 - ASMLib yönetimi için gerekli araçlar

oracleasm - Oracle ASM kütüphanesi için kernel modülü

6. Root kullanıcısı olarak tüm düğümlerde bu 3 paket yüklenmelidir.

# rpm -Uvh oracleasm-support-2.1.3-1.el4.x86_64.rpm

# rpm -Uvh oracleasmlib-2.0.4-1.el4.x86_64.rpm

# rpm -Uvh oracleasm-2.6.9-55.0.12.ELsmp-2.0.3-1.x86_64.rpm

7. ASMLIB yapılandırması için;

# oracleasm configure –I

Default user to own the driver interface oracle

Default group to own the driver interface dba

Start Oracle Automatic Storage Management Library driver on boot (y/n): y

Fix permissions of Oracle ASM disks on boot? (y/n): y

Bu işlemin sonunda;

/etc/sysconfig/oracleasm yapılandırma dosyası oluşturulur.

/dev/oracleasm mount point oluşturulur.

ASMLIB sürücüsü dosya sistemi mount edilir.

Aşağıdaki komut ile oracleasm kernel modülü yüklenir:

# /usr/sbin/oracleasm init

Her bir düğümde yukardaki işlemler teker teker tekrarlanmalıdır.

Paylaşımlı depolama alanındaki fiziksel disklerin formatlanma işleminden sonra ilgili fiziksel disklerde ASM disklerini aşağıdaki gibi oluşturuyoruz.Paylaşımlı fiziksel disklerin formatlama işlemini burada anlatmıyorum, tek bir düğüm üzerinde fdisk /dev/sdx işlemi ile yapılabilmektedir. Herbir fiziksel diski bir ASM diskine atıyoruz. Aşağıdaki adımlar sadece tek bir düğüm üzerinde yapılmalıdır.

# oracleasm createdisk data0 /dev/sdb1

# oracleasm createdisk data1 /dev/sdc1

# oracleasm createdisk data2 /dev/sdd1

# oracleasm createdisk data3 /dev/sde1

# oracleasm createdisk data4 /dev/sdf1

# oracleasm createdisk data5 /dev/sdg1

# oracleasm createdisk data6 /dev/sdh1

# oracleasm createdisk cdata1 /dev/sdd2

# oracleasm createdisk cdata2 /dev/sde2

# oracleasm createdisk cdata3 /dev/sdf2

Yukardaki data1 den data6 ya kadar olan ASM diskleri veritabanı veri dosyalarını, redo log dosyalarını ve kontrol dosyalarını saklayacak, cden cdata3 e kadar olan ASM diskleri ise OCR ve voting disk dosyalarını saklayacaktır.OCR ve voting diskleri tutacak olan fiziksel disklerin boyutunun 1GB altında olmasında sakınca yoktur.

Eğer bir diski ASM diski olarak işaretlemekten vazgeçerseniz aşağıdaki komutla bu işlemi tamamlayabilirsiniz.

# /usr/sbin/oracleasm deletedisk <disk_ismi>

Tüm ASM disklerini oluşturduktan sonra listdisks komutu ile bu diskleri listeliyoruz.

# /usr/sbin/oracleasm listdisks

Oluşturulan AS disklerin tüm düğümler üzerinde görülebilmesini sağlamak amacıyla scandisks komutunu diğer düğümlerde çalıştırıyoruz.Bu işlem sonunda tüm düğümler bu paylaşımlı ASM disklerine erişebilecektir.

# /usr/sbin/oracleasm scandisks

Bu aşamada kurulum öncesi yapılandırma işlemi tamamlandı.Artık Oracle Grid Infrastructure yazılımı yüklenebilir.

B. Oracle Grid Infrastructure Yazılımının Yüklenmesi.

Oracle kullanıcısı olarak Oracle Grid Infrastructure yazılımı aşağıdaki gibi çalıştırılır.Grid yazılımın Oracle veritabanı dizininden farklı yere kurulması için varsayılan ORACLE_HOME dizinini kuruluma başlamadan önce geçici olarak değiştiriyoruz.

$ export ORACLE_HOME=/u01/app/11.2.0/grid

$ ./runInstaller

http://download.oracle.com/otn/linux/oracle11g/R2/linux_11gR2_grid.zip linkinden yazılım indirilebilir.

"Install and Configure Grid Infrastructure for a Cluster" seçerek ilerliyoruz.

İkinci aşamada “Advanced Installation” seçeneği seçilerek ilerliyoruz. Üçüncü aşamada dil seçeneğini seçip ilerliyoruz.

Üçüncü aşamada cluster bilgilerinin girildiği menu listelenmektedir. Burada;

Cluster name: rac

SCAN name: rac

SCAN port: 1521

Configure GNS seçeneğini boş geçerek ilerliyoruz.

Cluster düğümlerinin belirtildiği menu listelenecektir. İkinci düğümü burada aşağıdaki gibi “Add” düğmesine basarak ekleyerek ilerliyoruz.

Ekrandaki menüden “SSH connectivity…” düğmesine tıklayarak oracle kullanıcısının şifresini giriyoruz. Böylece tüm düğümlerde Linux sistemleri arasında güven teşkil edilmiş olmaktadır. 11G R2 öncesinde bu işlemler Linux üzerinden manuel yapılmaktaydı, ancak artık otomatik olarak grid kurulumunda yapılmaktadır.

RAC sistemde public ve private olarak kullanılacak network arayüz isimlerini ve adaptörlerini belirliyoruz.

OCR ve voting disklerin lokasyonlarını belirlemek için “Automatic Storage Management” seçeneğini seçerek ilerliyoruz. Bir sonraki ekranda ASM disk grubu oluşturuyoruz. Disklerin tanınması için “change discover path” düğmesine tıklayarak /dev/sd* ile tüm ASM disklerini listeliyoruz. ASM disk grup ismi olarak DATA giriyorum ve DATA ile başlayan diskleri bu gruba ekliyorum. Bu aşamada OCR ve voting diskleri tutacak olan ASM diskleri için bir disk grubu oluşturmuyorum. Kurulum sonunda çalıştırılacak ilk düğümde çalıştırılacak olan root.sh scripti ile CDATA adı altında bir ASM diskgrubu otomatik olarak oluşturulacaktır.

Varsayılan izolasyon desteğini seçerek ilerliyoruz.
Varsayılan OS gruplarını seçerek ilerliyoruz.
Oracle base dizini olarak /u01/app/Oracle, software location olarak /u01/app/11.2.0/grid dizinlerini giriyoruz.

Diğer seçenekleri varsayılan olarak seçerek kurulumu sonlandırıyoruz.

Kurulum sonundaki scriptleri tüm düğümlerde sırasıyla teker teker çalıştırıyoruz.

Aşağıda RAC1 düğümünde çalıştırılan scriptler yer almaktadır. Aynı komutlar daha sonra RAC2 düğümündede çalıştırılmalıdır.

# cd /u01/app/oraInventory

# ./orainstRoot.sh

Changing permissions of /u01/app/oraInventory.

Adding read,write permissions for group.

Removing read,write,execute permissions for world.

Changing groupname of /u01/app/oraInventory to oinstall.

The execution of the script is complete.

# ./root.sh

Running Oracle 11g root.sh script...

The following environment variables are set as:

ORACLE_OWNER= oracle

ORACLE_HOME= /u01/app/11.2.0/grid

Enter the full pathname of the local bin directory: [/usr/local/bin]:

Copying dbhome to /usr/local/bin ...

Copying oraenv to /usr/local/bin ...

Copying coraenv to /usr/local/bin ...

Creating /etc/oratab file...

Entries will be added to the /etc/oratab file as needed by

Database Configuration Assistant when a database is created

Finished running generic part of root.sh script.

Now product-specific root actions will be performed.

2010-01-01 15:56:39: Parsing the host name

2010-01-01 15:56:39: Checking for super user privileges

2010-01-01 15:56:39: User has super user privileges

Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params

Creating trace directory

LOCAL ADD MODE

Creating OCR keys for user 'root', privgrp 'root'..

Operation successful.

root wallet

root wallet cert

root cert export

peer wallet

profile reader wallet

pa wallet

peer wallet keys

pa wallet keys

peer cert request

pa cert request

peer cert

pa cert

peer root cert TP

profile reader root cert TP

pa root cert TP

peer pa cert TP

pa peer cert TP

profile reader pa cert TP

profile reader peer cert TP

peer user cert

pa user cert

Adding daemon to inittab

CRS-4123: Oracle High Availability Services has been started.

ohasd is starting

CRS-2672: Attempting to start 'ora.gipcd' on 'rac1'

CRS-2672: Attempting to start 'ora.mdnsd' on 'rac1'

CRS-2676: Start of 'ora.gipcd' on 'rac1' succeeded

CRS-2676: Start of 'ora.mdnsd' on 'rac1' succeeded

CRS-2672: Attempting to start 'ora.gpnpd' on 'rac1'

CRS-2676: Start of 'ora.gpnpd' on 'rac1' succeeded

CRS-2672: Attempting to start 'ora.cssdmonitor' on 'rac1'

CRS-2676: Start of 'ora.cssdmonitor' on 'rac1' succeeded

CRS-2672: Attempting to start 'ora.cssd' on 'rac1'

CRS-2672: Attempting to start 'ora.diskmon' on 'rac1'

CRS-2676: Start of 'ora.diskmon' on 'rac1' succeeded

CRS-2676: Start of 'ora.cssd' on 'rac1' succeeded

CRS-2672: Attempting to start 'ora.ctssd' on 'rac1'

CRS-2676: Start of 'ora.ctssd' on 'rac1' succeeded

clscfg: -install mode specified

Successfully accumulated necessary OCR keys.

Creating OCR keys for user 'root', privgrp 'root'..

Operation successful.

CRS-2672: Attempting to start 'ora.crsd' on 'rac1'

CRS-2676: Start of 'ora.crsd' on 'rac1' succeeded

Now formatting voting disk: +CDATA/voting_disk.

CRS-4603: Successful addition of voting disk +CDATA/ voting_disk.

## STATE File Universal Id File Name Disk group

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

1. ONLINE 7b24ab5191b94f5fbf0078253186db97 (+CDATA/voting_disk) []

Located 1 voting disk(s).

CRS-2673: Attempting to stop 'ora.crsd' on 'rac1'

CRS-2677: Stop of 'ora.crsd' on 'rac1' succeeded

CRS-2673: Attempting to stop 'ora.ctssd' on 'rac1'

CRS-2677: Stop of 'ora.ctssd' on 'rac1' succeeded

CRS-2673: Attempting to stop 'ora.cssdmonitor' on 'rac1'

CRS-2677: Stop of 'ora.cssdmonitor' on 'rac1' succeeded

CRS-2673: Attempting to stop 'ora.cssd' on 'rac1'

CRS-2677: Stop of 'ora.cssd' on 'rac1' succeeded

CRS-2673: Attempting to stop 'ora.gpnpd' on 'rac1'

CRS-2677: Stop of 'ora.gpnpd' on 'rac1' succeeded

CRS-2673: Attempting to stop 'ora.gipcd' on 'rac1'

CRS-2677: Stop of 'ora.gipcd' on 'rac1' succeeded

CRS-2673: Attempting to stop 'ora.mdnsd' on 'rac1'

CRS-2677: Stop of 'ora.mdnsd' on 'rac1' succeeded

CRS-2672: Attempting to start 'ora.mdnsd' on 'rac1'

CRS-2676: Start of 'ora.mdnsd' on 'rac1' succeeded

CRS-2672: Attempting to start 'ora.gipcd' on 'rac1'

CRS-2676: Start of 'ora.gipcd' on 'rac1' succeeded

CRS-2672: Attempting to start 'ora.gpnpd' on 'rac1'

CRS-2676: Start of 'ora.gpnpd' on 'rac1' succeeded

CRS-2672: Attempting to start 'ora.cssdmonitor' on 'rac1'

CRS-2676: Start of 'ora.cssdmonitor' on 'rac1' succeeded

CRS-2672: Attempting to start 'ora.cssd' on 'rac1'

CRS-2672: Attempting to start 'ora.diskmon' on 'rac1'

CRS-2676: Start of 'ora.diskmon' on 'rac1' succeeded

CRS-2676: Start of 'ora.cssd' on 'rac1' succeeded

CRS-2672: Attempting to start 'ora.ctssd' on 'rac1'

CRS-2676: Start of 'ora.ctssd' on 'rac1' succeeded

CRS-2672: Attempting to start 'ora.crsd' on 'rac1'

CRS-2676: Start of 'ora.crsd' on 'rac1' succeeded

CRS-2672: Attempting to start 'ora.evmd' on 'rac1'

CRS-2676: Start of 'ora.evmd' on 'rac1' succeeded

rac1 2011/02/02 16:02:24 /u01/app/11.2.0/grid/cdata/rac1/backup_20110202_160224.olr

Preparing packages for installation...

cvuqdisk-1.0.7-1

Configure Oracle Grid Infrastructure for a Cluster ... succeeded

Updating inventory properties for clusterware

Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB. Actual 3999 MB Passed

The inventory pointer is located at /etc/oraInst.loc

The inventory is located at /u01/app/oraInventory

'UpdateNodeList' was successful.

Oracle Grid Infrasture kurulumunu başarıyla tamamladıktan sonra artık Oracle yazılımı yükleyip veritabanını oluşturabiliriz.

C. Oracle veritabanı yazılımının kurulumu:

ORACLE_HOME veritabanının varsayılan dizinine işaret etmesi için değiştirdikten sonra aşağıdaki komut ile Oracle veritabanı yazılımını yüklemeye başlıyoruz.

$ export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/db_1

$ ./runInstaller

1. İlk aşamada “Install Database software only” seçerek ilerliyoruz.

2. İkinci aşamada RAC veritabanı için “RAC database installation” seçeneğini işaretleyerek ilerliyoruz.

3. “Enterprise Edition” seçeneğini işaretleyerek ilerliyoruz. Lisansınız hangi versiyon ise onu seçiniz.

4. Diğer adımlarda varsayılan ayarları seçerek kurulumu tamamlıyoruz.

Kurulum sonrasında aşağıdaki scriptleri düğümlerde çalıştırıyoruz.

u01/app/orainstRoot.sh

u01/app/oracle/product/11.2.0/dbhome_1/root.sh

D. Oracle veritabanı oluşturma:

1. Oracle kullanıcısı olarak aşağıdaki komutu çalıştırarak Veritabanı Oluşturma Sihirbazını çalıştırıyoruz.

$ ./dbca

2. İlk pencerede “Oracle real application clusters database”seçeneğini tıklıyoruz.

3. “Create and configure database” seçeneğini tıklayarak ilerliyoruz.

4. Listeden yapınıza uygun veritabanı şablonunu seçerek ilerliyoruz. Bu aşamada karşımızda gelecek olan "server pool" kısmında "administrator managed" bölümünü değiştirmeden ilerliyoruz. Bu bölümde cluster düğümlerini ilke yönetimli olarak sunucu havuzlarında tanımlamak istenirse “policy managed” seçilmelidir. Bu server pools adını verdiğimiz kaynakların mantıksal olarak dağıtılması Oracle Clouding tarafında tanımlanmaktadır ve ayrı bir makale yazısıdır.

5. Aşağıdaki gibi gerekli değerleri girip depolama tipi olarak ASM seçiyoruz. Veri dosyalarının tutulacağı disk grubunu DATA olarak belirleyip ilerliyoruz. Global veritabanı olarak “rac.localdomain” giriyoruz. Siz dilediğiniz ismi verebilirsiniz.

6. Son adımda özete bakarak veritabanının kurulumuna başlıyoruz.

7. Kurulum sonunda OK basarak ekrana çıkan scripti tüm düğümlerde sırasıyla çalıştıyoruz.

RAC veritabanının ve küme servislerin sağlıklı çalışıp çalışmadığının kontrolünü yapmak için;

$ srvctl config database -d RAC

Database unique name: RAC

Database name: RAC

Oracle home: /u01/app/oracle/product/11.2.0/db_1

Oracle user: oracle

Spfile: +DATA/RAC/spfileRAC.ora

Domain: localdomain

Start options: open

Stop options: immediate

Database role: PRIMARY

Management policy: AUTOMATIC

Server pools: RAC

Database instances: RAC1,RAC2

Disk Groups: DATA

Services:

Database is administrator managed

$ srvctl status database -d RAC

Instance RAC1 is running on node rac1

Instance RAC2 is running on node rac2

$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Wed Feb 02 12:41:21 2011

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production

With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,Data Mining and Real Application Testing options

SQL> SELECT inst_name FROM v$active_instances;

INST_NAME

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

rac1.localdomain:RAC1

rac2.localdomain:RAC2

Oracle 11g Release 2 RAC yazılımı ve RAC veritabanı yapılandırmasını başarıyla tamamlıyoruz.Daha sonraki yazılarda Oracle 11g R2 RAC mimarisini yönetimsel ve performans iyileştirme başlıkları altında çok detaylı olarak inceleyeceğiz.

Oracle 11g RAC veritabanı sisteminde iki önemli servis vardır. Bunlar Global Cache Service (GCS) ve Global Enqueue Service (GES) dir. Bu ikisi temelde arkaplan proseslerinin koleksiyonudur. Her iki proses birlikte toplam "cache fusion" prosesini, kaynak transferlerini ve instancelar üzerinden kaynak tırmanmasını kapsar ve yönetir. Aşağıdaki şekilde yer alan “shared cache” kısmı, aslında tüm düğümlerde paylaşılan ortak ön bellektir ve kısaca “cache fusion” diye adlandırılır.

Global Kaynak Dizini (Global Resource Directory)

GES ve GCS prosesleri beraberce, kaynak ve kuyruğa ekleme bilgilerini kaydetmek için Global Kaynak Dizinini(GRD) oluştururlar. GRD, bellek içinde yer alır ve tüm instanceler üzerinde saklanır.Her instance dizinin bir parçasını yönetir.Bu dağıtık sadelik, RAC’ın fault tolerance yapısı için anahtar noktayı oluşturmaktadır.

Global Kaynak Dizini (GRD), veri bloklarının mevcut durumunu kaydeden ve saklayan dahili bir veritabanıdır. Bir blok, bulunduğu instance içindeki lokal bellekten diğer instance’ların belleğine transfer olur olmaz GRD güncellenir. GRD içinde aşağıdaki kaynak bilgileri yer almaktadır.

* Veri blok tanımlıyıcıları (DBI)

* En güncel versiyon bilgisinin lokasyonu

* Veri blok modları (N)Null, (S)Shared, (X)Exclusive

* Her bir instance tarafından tutulan veri bloklarının rolleri(lokal veya global)

* Küme içindeki çoklu düğümler üzerindeki ön bellekler

Global Cache Service (LMSx)

GCS veri bloklarının lokasyonunu, mod ve rol durumları ile birlikte tüm instance’ların erişim haklarını izler. Veri bloğunun mevcut versiyonu bir instance’ın ön belleğinde yer alırken ve bu esnada diğer bir instance o bloğu değiştirmek için talepte bulunursa, Oracle,GCS prosesini bellek uyumluluğu için kullanmaktadır. GCS aynı zamanda blokları diğer instance’dan okumak içinde kullanılır.

Ayrıcalıklı kaynakların ilk okumasını takiben tekil RAC instance içinde çalışan çoklu işlemler, bloğu uzunca süre lokal bellek dışına transfer yapmadan GCS ilişkisi olmaksızın veri blok setlerine erişimi paylaşabilmektedir. Bu yapı, RAC olmayan Oracle veritabanı ile benzerlik gösterir. Eğer bloğun lokal belleğin dışına transfer olması gerekirse GCS paylaşımlı havuz içinde Global Kaynak Dizinini günceller.

GCS ve Cache Coherency( Bellek Uyumluluğu)

GCS tüm veri blok tiplerini yönetir. Bellek uyumluluğu, veritabanı bloğunu değiştirmeden veya okumadan önce, instanceların cluster boyunca kaynak kazanma(blok üstündeki kilit veya kuyruğa alma) gereksinimi sebebiyle GCS üzerinden sürdürülür. GCS, sadece bir instance’ın herhangi bir tekil zaman anında bloğu değiştirmesine izin vererek global bellek erişimi senkronizasyonu için kullanılmaktadır. Global Kaynak Dizini boyunca GCS, cluster içinde herhangi bir modda belleğe alınan veri bloklarının durumunun global olarak görünür ve sürdürülür olmasını temin eder.

Oracle RAC birçok versiyon mimarisinden oluşmaktadır. Yani bu birçok versiyon mimarisi, mevcut veri blokları ile bloğun bir veya daha fazla kalıcı okuma(CR) versiyonunu ayırt etmeye yaramaktadır. Mevcut veri bloğu, commit edilmiş ve daha henüz commit edilmemiş işlemler ile ilgili değişiklikleri içermektedir.Bloğun kalıcı okuma(CR) versiyonu, verinin geçmişte herhangi bir zaman anında alınan kalıcı snapshot görüntüsünü ifade etmektedir. Bir veri bloğu, paylaşımlı kaynakların himayesi altında pek çok ön bellek içinde bulunabilmektedir.

Oracle RAC’da rollback segment bilgisinin mevcut bloklara uygulanması, bloklarda kalıcı okuma versiyonlarının oluşmasına sebep olur. Hem mevcut okuma blokları, hemde kalıcı okuma blokları GCS tarafından yönetilir.

Veri bloklarını veritabanı bellekleri arasında transfer etmek için bu tamponlar, yüksek hızda IPC interconnect ortalamasıyla taşınmaktadırlar. Disk yazmaları sadece bellek değiştirmesi için gereklidir. Bloğun eski görüntüsü(PI), eğer kirli(değiştirilmiş) blok ise, gönderilmeden önce bellek içinde saklanır. Herhangi bir başarısızlık durumunda Oracle bu blokların eski görüntüsünü kullanarak bloğun mevcut versiyonunu yeniden inşa eder.

GCS Kaynak Modları ve Roller

GCS global kaynak dizini, RAC sistemin başından sonuna kadar aktarılan kaynak bloklarını izlemektedir. Aynı blok, birçok bellek içinde sonuçta blok transferleri olarak yer alır. Blok, instance’nın kaynak veriyi güncellemek içinmi yoksa yalnızca okuma içinmi niyetlendiğine bağlı olarak farklı modlarda tutulur.

RAC kaynağı iki faktör tarafından belirlenmektedir:

Mod – null, shared veya exclusive.

Rol – Lokal veya global

Kaynak için talebin bir parçası olarak kaynak modları tutucu tarafından genellikle ayarlanmaktadır.Kaynak modu, taşıyıcının bloğu değiştirip değiştiremeyeceğini belirler. RAC kaynaklarının modları aşağıda açıklanmaktadır.

Null – N ile tanımlanır. Bu seviyede kaynak tutmak hiç bir erişim hakkının olmadığını ifade eder.

Shared – S ile tanımlanır. Korumalı okuma anlamına gelir. Kaynak bu seviyede tutulursa, proses onu değiştiremez ve birçok proses aynı kaynağı okuyabilir.

Exclusive – X ile tanımlanır. Prosesin ayrıcalıklı erişimi tutmasını onaylar.Diğer prosesler kaynağa yazamaz, ancak eski blokların sürekli okumaları PI prosesi üzerinden hala müsaittir.

Kaynak rolleri erişim tipine göre ayarlanmaktadır. Eğer kaynak exclusive(ayrıcalıklı) modda ise lokal, null veya shared mod da ise kaynak globaldir.

Cache Coherency(Bellek uyumluluğu) ile kullanılan performans izleme yolları

Bazı AWR raporlarını çalıştırmaktan çok daha fazla şekilde, HSI(High Speed Interconnects) network arayüzlerinin sağlığını ölçmeye ihtiyacımız vardır. Bunun yanında düğümler üzerindeki trafik hacmini ve cevap sürelerinide izlememiz gerekmektedir.Tipik bir OLTP sistemi bizi bu noktada fazlasıyla meşgul edecektir.Bu trafiği ölçmek için iki kategoriye odaklanılması gerekmektedir.

GCS (Global Cache Services)

GES (Global Enqueue Services)

Global Kuyruğa Alma Servisi (Global Enqueue Service)

Global olarak paylaşılan kuyruğa alma işlemlerini koordine eden servistir. RAC mimarisinde bloklar çoğunlukla işleri kendi başlarına halledebilmektedir, ancak GES devreye girdiğinde can alıcı bir nokta ortaya çıkar. RAC işlemi için düğümler arasında kusursuz bir koordinasyonun sağlanması şarttır. İşte bu noktada, GES önceliği ele alarak dictionary ve library bellekleri içinde uyumluluğun sağlanmasından sorumlu olur.Dictionary bellek, her bir düğümün kendi SGA’sı içinde öncelikli olarak hızlı bakış ve erişim için data dictionary master bilgisinden oluşmaktadır. Bir düğümde commit edilen herhangi bir DML işlemi, RAC yapısındaki tüm düğümlerde data dictionaryler üzerinden senkronize edilmeli ve yazılmalıdır. GES, değişikliklerin düğümler üzerinden sürekli kılındığını ve böylece uyuşmazlık olmadığını garanti altına alır.GES aynı objeye erişimde düğümler arasında deadlock olmamasını da garanti etmelidir. LMON, LCK ve LMD prosesleri birlikte bir koordinasyon içinde çalışarak, GES'in çalışmasını yumuşak ve kusursuz şekilde ayarlar.

Oracle RAC GCS performansını izlemek için Grid Enterprise konsoldan “Cluster Cache Coherency” performans izleme sayfasına girince aşağıdaki ekran çıkmaktadır.

• GC CR Blocks Received: Bu metrik mevcut cluster üzerinden okuma kalıcılık uygulamasını yansıtmaktadır. Diğer bir şekilde cluster içindeki herhangi bir düğümde SELECT işlemi çalışır durumdayken başka bir oturum başka bir düğümde bu SELECT sorgusu çalışmaya başladığı andan itibaren satırları değiştirdiyse, oturum sorgu başladığı andaki veriyi içeren veri bloklarını talep edecektir. Eğer kalıcı okuma talebi lokal ön bellekten sağlanamazsa, bu durumda cluster içindeki başka bir instance içindeki veri bloklarını taşıma yoluyla sağlayabilmektedir.İşte bu taşıma işlemleri bu metrik içinde kayıt edilmektedir.

• GC Current Blocks Received: Bu metrik mevcut durumdaki veri bloklarının instance’lar arası transferini göstermektedir. Bir veri bloğu INSERT, UPDATE veya DELETE işlemi sonucunda değiştirilmiş veya oluşturulmuşsa “mevcut durum” modundadır ve bu hareketi sağlayan en son güncel veri instance içindeki ön bellekte yer almaktadır. Eğer bu mevcut veri, cluster içindeki başka bir instance tarafından talep edilmiş ve başarılı bir şekilde transfer edilmişse bu metrik içinde yer alır.

GV$ görünümleri

Awr raporları yanında SQL*Plus üzerinden GV$ görünümleride performas izleme ve proaktif işlemler açısından önemlidir.

Örneğin, aşağıdaki sorgu düğümler üzerinde gönderilen GCS mesajları ile ilgili sonuç verecektir.Eğer düğümler arasında çok farklılıklar varsa bir sorun var demektir.

SQL> select * from gv$sysstat where name like ‘%gcs %’;

Bunun yanında aşağıdaki sql cümlesi, “nunhem” şemasındaki segmentlere ait global bellek aktivitesini gösterecektir. Eğer sonuçta blok başına yüksek satır sonuçları mevcutsa, bu objelerin PCTFREE değerlerinin artırılmasında fayda vardır.

SQL> SELECT

> table_name AS "Table Name",

> gc_buffer_busy AS "Buffer Busy",

> gc_cr_blocks_received AS "CR Blocks Received",

> gc_current_blocks_received AS "Current Blocks Received"

> FROM

> (

> SELECT table_name FROM dba_tables

> WHERE owner = 'NUNHEM'

> ) t,

> (

> SELECT object_name,value AS gc_buffer_busy

> FROM v$segment_statistics

> WHERE owner = 'NUNHEM'

> AND object_type = 'TABLE'

> AND statistic_name = 'gc buffer busy'

> ) ss1,

> (

> SELECT object_name,value AS gc_cr_blocks_received

> FROM v$segment_statistics

> WHERE owner = 'NUNHEM'

> AND object_type = 'TABLE'

> AND statistic_name = 'gc cr blocks received'

> ) ss2,

> (

> SELECT object_name,value AS gc_current_blocks_received

> FROM v$segment_statistics

> WHERE owner = 'NUNHEM'

> AND object_type = 'TABLE'

> AND statistic_name = 'gc current blocks received'

> ) ss3

> WHERE t.table_name = ss1.object_name

> AND t.table_name = ss2.object_name

> AND t.table_name = ss3.object_name;

Table Name Buffer Busy CR Blocks Received Current Blocks Received

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

CSTTBL 0 54 434

RGNTBL 0 62 370

JOBTBL 0 6 19

ITMTBL 0 0 637

ORDTBL 1 250 574

STCTBL 0 1193 531

WRHTBL 0 206 192

Global Cache Services(GCS) kalıcı okumalarının izlenmesi

Kalıcı okumaların performansını izlemek için alttaki formül kullanılır.

(gc cr block receive time × 10) / (gc cr blocks received)

Yukardaki formulün sonucunda instance için milisaniye değerinde kalıcı blok okuması taleplerinin ortalama zamanı dönmektedir ve Enterprise Manager RAC performans görünümlerinde gözlemlediğimiz global bellek blok transfer oranı (Global Cache Block Transfer Rate) metrikidir. Bu değer interconnect performansını belirlemek için kullanılan en önemli değerdir.

Veri blokları için global kaynak talepleri, talep eden instance’ın ön belleği içinde meydana gelir. Talep, GCS talep kuyruğuna girmeden önce Oracle, SGA içinde talebin durumunu izleyecek ve bu kaynak yapıları üzerinde istatistik toplayacak veri yapılarını tahsis eder.

SQL> SELECT

> gc_cr_block_receive_time AS "Receive Time",

> gc_cr_blocks_received AS "Blocks Received",

> (gc_cr_block_receive_time * 10) /

> gc_cr_blocks_received AS "Average Latency (MS)"

> FROM

> (

> SELECT value AS gc_cr_block_receive_time FROM v$sysstat

> WHERE name = 'gc cr block receive time'

> ),

> (

> SELECT value AS gc_cr_blocks_received FROM v$sysstat

> WHERE name = 'gc cr blocks received'

> );

Alttaki sonuç yukardaki raporun çalışması sonucu alınan bir örnek sonuçtur:

Receive Time Blocks Received Average Latency (MS)

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

5405 3869 23.9681803

Kalıcı blok talep gecikmesi, orijinal talep ile lokal instancetaki kalıcı blok imaj alındısı arasında geçen zamandır.Gigabit Ethernet bağlatısı ile, be değer normalde 5ms altında olmalı ve 15ms üzerine çıkmamalı, bununla beraber bu değer sistem konfigürasyonu ve hacimdende etkilenebilmektedir. Yukardaki örnekte gecikme süresi 24ms dir. Linux içerisinden “netstat” komutunu kullanarak network paket alımı ve gönderimi gibi bir network yapılandırma sorunu olup olmadığı anlaşılabilir.Bunun yanında, “top” ve “sar” komutları ile düğümler üzerindeki yükü ölçmelisiniz. Eğer “interconnect” düzgün bir şekilde yapılandırıldıysa ve hala yüksek ortalama gecikme süreleri varsa, bu durumda

DB_FILE_MULTIBLOCK_READ_COUNT parametresinin değerini düşürün. Bu değer tekli operasyonda beher proses için ne kadar bloğun belirler. Proses tüm blokların dönmesini bekleyeceğinden dolayı muhtemelen yüksek bekleme oranlarına sebebiyet verebilir. Bu parametreyi düzenlemeden önce, tüm işyükündeki etkisini gözden geçirin.

Yüksek ortalama gecikme süreleri, yüksek sayıdaki gelen çağrılar veya birçok proses çağrıları LMS prosesine dağıtması yüzünden meydana gelebilir. Ortalama LMS servis süresi aşağıdaki formul ile hesaplanabilir.

average LMS service time = average latency - average time to build consistent read block - average time to wait for log flush - average time to send completed block

Kalıcı okuma bloğu inşa etmek için gereken ortalama zaman hesaplaması:

gc cr block build time / gc cr blocks served

Redo log flush işlemi için ortalama bekleme süresi hesaplaması:

gc cr block flush time / gc cr blocks served

Tamamlanmış bloğun ortalama gönderim süresi hesaplaması:

gc cr block send time / gc cr blocks served

Alttaki sorgu, kalıcı blok okuması için gereken ortalama LMS servis süresini hesaplamaktadır.

SQL> SELECT

> average_latency AS "Average Latency",

> average_build_time AS "Average Build Time",

> average_flush_time AS "Average Flush Time",

> average_send_time AS "Average Send Time",

> average_latency - average_build_time - average_flush_time - average_send_time

> AS "Average LMS Service Time"

> FROM

> (

> SELECT

> (gc_cr_block_receive_time * 10) / gc_cr_blocks_received AS average_latency,

> (gc_cr_block_build_time * 10) / gc_cr_blocks_served AS average_build_time,

> (gc_cr_block_flush_time * 10) / gc_cr_blocks_served AS average_flush_time,

> (gc_cr_block_send_time * 10) / gc_cr_blocks_served AS average_send_time

> FROM

> (

> SELECT value AS gc_cr_block_receive_time FROM v$sysstat

> WHERE name = 'gc cr block receive time'

> ),

> (

> SELECT value AS gc_cr_blocks_received FROM v$sysstat

> WHERE name = 'gc cr blocks received'

> ),

> (

> SELECT value AS gc_cr_block_build_time FROM v$sysstat

> WHERE name = 'gc cr block build time'

> ),

> (

> SELECT value AS gc_cr_block_flush_time FROM v$sysstat

> WHERE name = 'gc cr block flush time'

> ),

> (

> SELECT value AS gc_cr_block_send_time FROM v$sysstat

> WHERE name = 'gc cr block send time'

> ),

> (

> SELECT value AS gc_cr_blocks_served FROM v$sysstat

> WHERE name = 'gc cr blocks served'

> ) );

Oratalama gecikme süresi ve ortalama inşa, boşaltma ve gönderme zamanı arasındaki farklılık, LMS servisi içindeki harcanan zamanı ve “interconnect” üzerinden mesaj işlerken geçen süreyi temsil eder. Aşağıdaki sorgu sonucu buna bir örnek teşkil etmektedir.

Average Average Average Average Average

Latency Build Time Flush Time Send Time LMS Service Time

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

41.8455403 0.039572616 0.696264345 0.03661535 40.957365

Yukardaki örnekte görüldüğü üzere doğrusu LMS servis zamanında baya yüksek bir bekleme oranı mevcuttur.netstat- l ile TCP/UDP paketleri incelenmelidir. Oracle Net hizmetlerinde RECV_BUF_SIZE ve SEND_BUF_SIZE parametrelerinin BDP (Bandwidth Delay Product) değerinin 3 katına eşit olmasını sağlanması gerekmektedir. Bu sayede network çıktısında büyük artışlar sağlanacaktır.

Bunun yanında Linux 2.16 versiyon üzerinde maksimum UDP tampon büyüklüğü 4MB'dır ve alım tarafında otomatik iyileştirm etkindir. udp_max_buffer parametresini 8MB 'ye artırarak maksimum UDP tampon büyüklüğünün genişletilmesi gerekmektedir. Bunun neticesinde de udp_xmit_hiwat ve udp_recv_hiwat değerlerini 256KB'ya yükselterek, yetersiz UDP alım/işleme tampon büyüklüğü yüzünden düşen paket sayısını önemli oranda azaltmak mümkün olacaktır. Bunun yanında eğer networkunuz jumbo frame destekliyorsa, jumbo frameleri kullanın. Tipik olarak MTU büyüklüğü 1500 bytes büyüklüğündedir, bu değeri yaklaşık 9000 bytes sınırına çıkarın.

Soket tampon büyüklüğü hem işletim sistemi seviyesinde hemde Oracle net servisleri seviyesinde atanabilir. Bazı Linux işletim sistemi versiyonlarında bu değerler olduğundan fazla yüksek olabilir.Bu durumda bu değerleri optimal seviyeye indirmeniz gerekmektedir. Düğümlerdeki sqlnet.ora dosyalarına aşağıdaki eklemeler yapılabilir.

RECV_BUF_SIZE=<soket tampon büyüklüğü>

SEND_BUF_SIZE=<soket tampon büyüklüğü>

Kuyruk büyüklüğünü kernel network alt sistemleri ve ethetnet kartı sürücüsü arasındada düzenleyebiliriz.Herhangi bir kuyruk tekrardan boyutlandırılabilir, böylece local tampon aşırı yüklemeleri sebebiyle kayıplar meydana gelmez.Bu yüzden yüksek bant genişliğindeki networklerde etkili iyileştirme yapmak için kuyruk büyüklüklerinin mevcut network bağlantımıza uygun olduğundan emin olmamız gerekmektedir.Kuyruk büyüklükleri için Linux’ta 2 kuyruk tipi önemlidir, arayüz iletim kuyruğu ve network alım kuyruğu.ifconfig ile gönderim tarafında TXQUEUELEN arayüzü seçeneğini artırın, alım tarafında ise NET_DEV_MAX_BACKLOG kernel parametre değerini artırın.

100ms latency ye sahip 1 gigabitlik network için bir örnek altta yer almaktadır.Bu şartlarda network için TXQUEUELEN değeri en az 10000 olmalıdır. İdeal değerler için Linux üreticilerinin tavsiyeleri alınabilir.

echo 20000 > /proc/sys/net/core/netdev_max_backlog

echo 1 > /proc/sys/net/ipv4/route/flush

ifconfig eth0 txqueuelen 10000

GCS Mevcut Bloklarda performansın izlenmesi

SQL*Plus kullanarak EM RAC performans görünümlerindeki Global Cache Block Transfer Rate oranı ile mevcut blok aktivitesini izleyebiliriz. Mevcut bloklar için işlem gören çağrılar içinde baştan sona ortalama gecikme süresi aşağıdaki formül ile bulunabilir.

SQL> SELECT

> gc_current_block_receive_time AS "Receive Time",

> gc_current_blocks_received AS "Blocks Received",

> (gc_current_block_receive_time * 10) / gc_current_blocks_received

> AS "Average (MS)"

> FROM

> (

> SELECT value AS gc_current_block_receive_time

> FROM v$sysstat

> WHERE name = 'gc current block receive time'

> ),

> (

> SELECT value AS gc_current_blocks_received

> FROM v$sysstat

> WHERE name = 'gc current blocks received'

> );

Aşağıdaki çıktı örnek bir sonuç olabilmektedir.

Receive Time Blocks Received Average (MS)

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

12279 14222 8.63380678

LMS işlemine dayandırılan baştan sona gecikme süresi aşağıdaki formül ile hesaplanabilir.

average LMS service time = average latency - average time to pin current blocks - average time to wait for log flush - average time to send completed block

Mevcut blok okumaları için ortalama LMS servis zamanı hesaplamasında aşağıdaki sorgu kullanılabilir:

SQL> SELECT

> average_latency AS "Average Latency",

> average_pin_time AS "Average Pin Time",

> average_flush_time AS "Average Flush Time",

> average_send_time AS "Average Send Time",

> average_latency - average_pin_time - average_flush_time - average_send_time

> AS "Average LMS Service Time"

> FROM

> (

> SELECT

> (gc_current_block_receive_time * 10) / gc_current_blocks_received

> AS average_latency,

> (gc_current_block_pin_time * 10) / gc_current_blocks_served

> AS average_pin_time,

> (gc_current_block_flush_time * 10) / gc_current_blocks_served

> AS average_flush_time,

> (gc_current_block_send_time * 10) / gc_current_blocks_served

> AS average_send_time

> FROM

> (

> SELECT value AS gc_current_block_receive_time FROM v$sysstat

> WHERE name = 'gc current block receive time'

> ),

> (

> SELECT value AS gc_current_blocks_received FROM v$sysstat

> WHERE name = 'gc current blocks received'

> ),

> (

> SELECT value AS gc_current_block_pin_time FROM v$sysstat

> WHERE name = 'gc current block pin time'

> ),

> (

> SELECT value AS gc_current_block_flush_time FROM v$sysstat

> WHERE name = 'gc current block flush time'

> ),

> (

> SELECT value AS gc_current_block_send_time FROM v$sysstat

> WHERE name = 'gc current block send time'

> ),

> (

> SELECT value AS gc_current_blocks_served FROM v$sysstat

> WHERE name = 'gc current blocks served'

> ));

Aşağıda bu sorgu sonucu hazırlanan örnek bir sorgu sonucu yer almaktadır.

Average Average Average Average Average

Latency Build Time Pin Time Send Time LMS Service Time

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

8.67584376 0.041137669 0.022696645 0.04397475 8.56803469

Yüksek değerler interconnect veya sunucu bazlı sorunlar olduğunu işaret eder.Bununla beraber yüksek “average pin time” değerleri olduğunda, LGWR prosesinin işlem önceliğini artırın. Redo log dosyaları üzerinde yazma performansının artması tüm RAC ortamında blok işlemlerinde performans artışı sağlayacaktır. Örneğin, Solaris host için aşağıdaki gibi LGWR prosesine öncelik verebilirsiniz.

priocntl -e -c class -m userlimit -p priority

priocntl -e -c RT -p 59 `pgrep -f ora_lgwr_${ORACLE_SID}`

priocntl -e -c FX -m 60 -p 60 `pgrep -f ora_lms[0-9]*_${ORACLE_SID}`

Bunun yanında yüksek bekleme olaylarıyla ilişkili veritabanı objelerini bulmak için aşağıdaki sorgu çalıştırılabilir.

SELECT INST_ID "Instance", name, kind, sum(forced_reads) "Forced Reads", sum(forced_writes) "Forced Writes"

FROM gv$cache_transfer

WHERE owner# != 0

GROUP BY inst_id, name, kind

ORDER BY 1,4 desc,2;

Instance NAME KIND Forced Reads Forced Writes

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

1 MOD_TEST_IND INDEX 308 0

1 TEST2 TABLE 64 0

1 AQ$_QUEUE_TABLES TABLE 5 0

2 TEST2 TABLE 473 0

2 MOD_TEST_IND INDEX 221 0

Bunun yanında Cache Fusion Hit Ratio oranını bulmak için ise;

SELECT A.inst_id "Instance",

A.VALUE/B.VALUE "Cache Fusion Writes Ratio"

FROM GV$SYSSTAT A, GV$SYSSTAT B

WHERE A.name='DBWR fusion writes'

AND B.name='physical writes'

AND B.inst_id=a.inst_id

ORDER

BY A.INST_ID;

Instance Cache Fusion Writes Ratio

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

1 .227487558

2 .141465042

Yüksek orandaki Cache Fusion Write Ratio değeri, yetersiz büyüklükte bellek olmasından veya çok fazla checkpoint meydana gelmesinden veya bellek replacement(yeniden yerleştirme) -yada -checkpoint yüzünden çok büyük tamponların yazılmasından kaynaklanmaktadır. Bu durumda checkpoint sıklığını azaltmak bir çözüm olabilecektir. Bunun yanında geniş sort ve full tablo taramalarını azaltmakta çok büyük tamponların DBWR prosesi ile yazılma büyüklüğünü azaltacaktır. Aslında SGA alanında ön bellek miktarını bir miktar artırmakta bir çözüm olabilecektir.Ancak en optimal Cache Fusion yazma değerini yakalamak için Veri dosyalarını diskler veya disk kontroller üzerine serpiştirin ve sıcak noktaların oluşmasının önüne geçin.

Global Kuyruğa Alma Servisinin izlenmesi

SQL> SELECT

> global_enqueue_get_time AS "Get Time",

> global_enqueue_gets_sync AS "Synchronous Gets",

> global_enqueue_gets_async AS "Asynchronous Gets",

> (global_enqueue_get_time * 10) /

> (global_enqueue_gets_sync + global_enqueue_gets_async)

> AS "Average (MS)"

> FROM

> (

> SELECT value AS global_enqueue_get_time

> FROM v$sysstat

> WHERE name = 'global enqueue get time'

> ),

> (

> SELECT value AS global_enqueue_gets_sync

> FROM v$sysstat

> WHERE name = 'global enqueue gets sync'

> ),

> (

> SELECT value AS global_enqueue_gets_async

> FROM v$sysstat

> WHERE name = 'global enqueue gets async'

> );

Get Time Synchronous Gets Asynchronous Gets Average (MS)

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

159674 98861 10555 15.3954835

“Synchronous gets” değerleri genellikle kilitleme olaylarını işaret ederken yüksek orandaki “asynchronous gets” ise instanceler arası engelleyici olmayan prosesler yüzünden meydana gelir.

Yukardaki örnekte ortalama global kuyruğa alma zamanı yaklaşık olarak 15.4 ms, ki bu değer kabul edilebilir sınırlar içindedir. Eğer bu oran 20ms üzerinde olursa, çalıştırdığınız uygulamada sorunların ve beklemelerin olduğu anlamına gelmektedir. Bu noktada index kullanımını gözden geçirmeniz ve bu beklemelerde bloklayan SID yi bulmanız gerekecektir.Eşzamanlı kilitleyebilmede önkuyruk sayısını maksimum sayıda kontrol etmek için ENQUEUE_RESOURCES parametresi kullanılmaktadır. Bu değeri artırmayı deneyin.

Bu yazıda Oracle 11g R2 RAC mimarisini hem primary hemde standby veritabanı olarak kullanarak, cluster çapında Data Guard yapılandırmasını ve yönetim tekniklerini inceleyeceğiz. Aslında bu incelemeyi migration testleri kapsamında 2010 Temmuz ayında Hollanda’da datacenterımızda yapmıştım, bu sebeple o zamanki test sonuç analiz notlarımı bulup harmanlayarak bu yazıyı hazırladım. Ancak unutmadan belirtmek isterim, Swingbench adlı stres testi aracı ile 1,000 kadar sanal kullanıcıya oturum açtırıp eşzamanlı hem primary siteden INSERT-UPDATE işlemleri yapıp hemde standby siteden SELECT sorgularını sorunsuz yapabildiğimi söyleyebilirim ve bu sürede cluster CPU, bellek ve I/O performanslarıda oldukça iyiydi.

Bu inceleme için o tarihte kullandığım fiziksel kaynaklar; 4 adet Sun SPARC Enterprise M3000 Server ve 1 adet Sun Storage 6180 Array ünitesinden oluşmaktadır. Sunucularda, Oracle Enterprise Linux 5.4 ve Oracle 11.2 Grid Infrastructure yazılımı kurulu ve Oracle depolama sistemi olarak Oracle ASM kullanılmaktadır.

RAC kullanılacak olan primary ve standby sitelerindeki sunuculara Oracle 11gR2 GI ve RDBMS yazılımlarının kurulmuş olmalıdır. Primary sitede ayrıca bir RAC veritabanının hizmet veriyor olması gerekmektedir. Daha önce yayınlanan Oracle 11g R2 RAC kurulum adlı yazıyı referans alarak clusterware kurulumunu 2 farklı sitede ve 2 ayrı yapıda aşağıdaki mimaride gerçekleştiriyoruz.

Benim yukardaki sistemimde;

LINUX1_RACPRIM à RAC1 adlı instance içermektedir

LINUX2_RACPRIM à RAC2 adlı instance içermektedir

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

Primary site içerisinde RAC adlı cluster primary veritabanını bulunur ve SCAN adresi rac-scan olmuştur. DATA ve DGSTDBY adlı ASM diskgruplar mevcuttur.

LINUX1_RACSTD à RACSTD1 adlı instance içerecektir.

LINUX2_RACSTD à RACSTD2 adlı instance içerecektir.

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

Standby site içerisinde RACSTD adlı cluster standby veritabanını bulunacaktır ve SCAN adresi racstd-scan olacaktır. DATA adlı disk grubu önceden mevcuttur.

Önce isterseniz RAC ve Dataguard ne anlama gelmekte ve her ikisi birlikte kullanıldığında ne gibi avantajlar sağlanmaktadır.

“Oracle RAC” küme mimarisi içerisinde yer alan birden fazla sunucunun, ortak disk katmanında bulunan tek bir veritabanına erişmesini sağlayan bir çözümdür. Birden fazla sunucu olduğu için yüksek seviyede devamlılık sağlanmaktadır. Birden fazla sunucunun aktif olarak veri tabanına erişmesi sayesinde, sunuculardan birinin çökmesi durumunda o sunucu üzerinde bulunan yük, küme içerisindeki diğer sunuculara otomatik olarak aktarılır ve kullanıcılar çalışmalarına devam eder. Ayrıca artan iş taleplerinden dolayı, daha fazla işlemci gücüne ihtiyaç duyulduğunda kullanıcıların bağlantısı kesilmeden kümeye yeni sunucuların eklenmesi mümkün olmaktadır. Bunun yanında Oracle 11g R2 itibariyle server pools adını verdiğimiz yapı ile en uygun işyükü hesaplanmakta ve işyükünün yetersiz kaldığı durumlarda ilgili havuza ek düğümler ile işyükü dengesi optimal seviyelerde sağlanmaktadır.

Oracle Data Guard, kurumsal veriler için sunulan en etkin ve kapsamlı veri devamlılığı koruma ve afet yönetimi çözümlerinden biridir. Oracle Data Guard, kurumsal verileri afet, hata ve kesintilerden korumak için bir veya daha fazla yedek veritabanının yaratılmasını, yönetimini ve takibini sağlayan yönetim, takip ve otomasyon yazılım altyapısıdır. Data Guard, bu yedek veritabanlarını ana veritabanının tutarlı kopyaları olarak tutar. Yedek veritabanları, ana veritabanından binlerce kilometre uzakta bir afet merkezinde olabileceği gibi, aynı şehir, kampüs hatta aynı odada bulunabilir. Ana veritabanının planlı ya da planlanmamış bir sebeple ulaşılamaz hale gelmesi durumunda, Data Guard, yedek veritabanlarından birini ana veritabanı olarak aktif hale getirerek ulaşılamama süresini en aza indirir ve veri kaybını önler. İstenildiği takdirde yedek veritabanı okuma amaçlı olarak da hizmet verebilmektedir.

Sonuçta, RAC teknolojisinin çoklu düğüm yapısı sayesinde devamlılık sağlama avantajını, Data Guard teknolojisinin veri devamlılığını felaket anlarında bile en üst seviyede koruma avantajı ile kaynaştırarak, en üst seviyede erişilebilirlik ve koruma performansı sağlanmaktadır.

Unutmadan tekrar belirtmek isterim, standby sitedeki RAC düğümlerde sadece Oracle 11g R2 Grid Infrastructure ve Oracle 11g R2 veritabanı yazılımı yüklüdür ve herhangi bir şekilde veritabanı kurulmamıştır.

Bu yazıda 4 düğümlü RAC mimarisinde, primary sitedeki 2 düğüm primary veritabanı read/write işlemlerine cevap verecek, standby sitedeki 2 düğüm ise standby veritabanı olarak read-only olarak istemcilere raporlama hizmeti sunacaktır. Herhangi bir failover durumunda ise aşağıdaki gibi roller değişecektir.

st1\:*{behavior:url(#ieooui) }

Bu yazıda OEM kullanmadan sqlplus, RMAN ve Data Guard Broker(dgmgrl) kullanarak standby RAC veritabanı oluşturacağız ve kurulum sonrasında çeşitli senaryolar uygulayarak yöneteceğiz. Bu yazı içerisinde dataguard standby veritabanını oluştururken genel yaklaşım adımları aşağıdaki gibi olacaktır:

Primary veritabanında “force logging” özelliğinin etkinleştirilmesi
Primary veritabanında ASM içinde saklı ve OCR ile kayıt olmuş spfile kullanıldığından emin olacağız.
Primary veritabanında standby redo log dosyalarını oluşturuyoruz.
RAC için her instance içinde redo taşımasını yapılandırıyoruz.
Grid Infrastructure listenerlar içerisinde hem primary hemde standby sitelerde Oracle NET yapılandırması ve RDBMS tnsnames girişlerinin eklenmesi.
Standby sunucular için password dosyalarının oluşturulması ve ignorecase=y parametresi ekleyerek case sensitive olmayan password dosyası oluşturulması.
Standby sitesinde pfile dosyasının ve DIAG dizinlerinin oluşturulması.
RMAN ile primary RAC veritabanının standby RAC veritabanı olarak klonlama işlemi.Klonlama süresince RAC veritabanı işlevselliğini sürdürecekse cluster_database=FALSE değeri atanmalıdır.
Primary veritabanında ASM içinde saklı ve OCR ile kayıt olmuş spfile kullanıldığından emin olacağız.
Standby veritabanını OCR içinde kayıt etme.
DG Broker kurulumu.
Data Guard yapılandırılmasının yapılması.

RAC veritabanının klonlanması aşamasında aşağıdaki bilgilere dikkat edilmesi gerekmektedir:

Klonlama süresince cluster_database parametre değerini FALSE olarak atayın.
ASM içinde paylaşımlı spfile dosyasına işaret eden bir pfile oluşturun.
RAC veritabanlarını OCR ye kayıt edin.
ASM içinde bulunacak ve her iki sitede instanceler arasında paylaşılacak Data Guard Broker yapılandırma dosyalarını oluşturun.
Hem primary hemde standby veritabanını RAC cluster içinde tutun.

Dataguard kurulumundan sonra switchover, failover işlemleri gerçekleştirerek rol değişimlerinin sağlanabildiğinden emin olmanızı tavsiye ederim.

Oracle 11g R2 RAC düğümlerinde Data Guard Yapılandırması

Primary veritabanı olarak kullanılacak olan RAC adlı kaynak veritabanı yapılandırılmış ve hizmete hazırdır. Bu bölümde fiziksel standby veritabanı oluşturulacak ve Data Guard Broker yapılandırılacaktır.

Önce isterseniz primary sitedeki RAC veritabanı konfigürasyonunu inceleyelim.

[oracle@linux1_racprim] $ srvctl config database -d rac

Database unique name: rac

Database name: rac

Oracle home: /u01/app/oracle/product/11.2.0/db_10

Oracle user: oracle

Spfile: +DATA/RAC/spfilerac.ora

Domain:

Start options: open

Stop options: immediate

Database role: PRIMARY

Management policy: AUTOMATIC

Server pools: rac

Database instances: rac1,rac2

Disk Groups: DATA, DGSTDBY

Mount point paths:

Services:

Type: RAC

Database is administrator managed

[oracle@ linux1_racprim] $ srvctl status database -d rac

Instance rac1 is running on node linux1_racprim

Instance rac2 is running on node linux2_racprim

Primary RAC veritabanında “force logging” özelliği etkinleştiriliyor.Böylece NOLOGGING takısını kullanarak yapılabilecek işlemlerin önüne geçiyoruz. Aksi durumda redo dosyasını bypass geçen NOLOGGING işlemleri sonucunda standby sunucularda blok bozulmaları oluşabilecek ve redo uygulaması böyle durumlarda durabilecekti.

SQL> alter database force logging;

Standby sitede standby redo log dosyaları oluşturuluyor. Primary RAC veritabanında üç adet redo log dosyası olduğundan dolayı standby sitedede bir fazla , yani dört adet standby log dosyası oluşturuyoruz. Benim senaryomda kullandığım dosya yapısı Oracle Managed File(OMF) ve ASM olduğundan, isterseniz standby sunucuda OMF yi etkinleştirelim ve standby log dosyalarını saklayacak olan ASM diskgrubunu oluşturalım. Standby sitedeki bir düğüm üzerinden aşağıdaki şekilde ASM diskleri oluşturun. /etc/rc.local içinde bu yeni diskleri eklemeyi ve sahiplik ile erişim izinlerini oracle kullanıcısına atamayı unutmayın.

[root@linux1_racstand] # service oracleasm createdisk STDBY01 /dev/sdm1

[root@linux1_racstand] # service oracleasm createdisk STDBY02 /dev/sdn1

[root@linux1_racstand] # service oracleasm scandisks

Ardından, diğer düğümdede bu yeni disklerin tanınması için taramayı başlatın.

[root@linux2_racstand] # service oracleasm scandisks

Daha sonra standby sitedeki herhangi bir düğümden(sadece bir tanesinden) DGSTDBY adındaki standby log dosyalarının tutulacağı ASM diskgrubunu oluşturuyoruz. Bu işlemler öncesinde ORACLE_SID parametresinin ASM instance’ını gösterdiğinden emin olun. Ayrıca db_create_file_dest parametresinin tüm standby düğümlerde ‘+DGSTDBY’ yi işaret ettiğinden emin olun.

[oracle@linux1_racstand] $ set ORACLE_SID=+ASM1

[oracle@linux1_racstand] $ sqlplus / as sysdba

SQL> CREATE DISKGROUP DGSTDBY

NORMAL REDUNDANCY

FAILGROUP controller1 DISK

'/dev/sdm1',

'/dev/sdn1’

ATTRIBUTE 'compatible.asm' = '11.2', 'compatible.rdbms' = '11.2',

'sector_size'='4096';

SQL> EXIT

[oracle@linux1_racstand] $ set ORACLE_SID=RAC1

[oracle@linux1_racstand] $ sqlplus / as sysdba

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST=’+ DGSTDBY’ SCOPE=SPFILE;

İkinci düğümdede db_create_file_dest dizinini değiştiriyoruz.

[oracle@linux2_racstand] $ set ORACLE_SID=RAC2

[oracle@linux2_racstand] $ sqlplus / as sysdba

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST=’+DGSTDBY’ SCOPE=SPFILE;

Standby düğümleri yeniden başlattıktan sonra standby sitedeki düğümlerden birisinde ASM instance’ına oturum açarak gerekli ASM dizinleri oluşturun.

[oracle@linux1_racstand] $ set ORACLE_SID=+ASM1

[oracle@linux1_racstand] $ asmcmd

ASMCMD> cd DATA

ASMCMD> mkdir RACSTD

ASMCMD> cd DGSTDBY

ASMCMD> mkdir RACSTD

Standby instanceleri restart ettikten sonra bir düğümden standby log dosyalarını oluşturuyoruz. Bu standby log dosyaları paylaşımlı disk alanında saklanacak ve cluster içindeki tüm standby düğümler tarafından erişilebilecektir. Standby log dosyalarının büyüklüğü primary redo log dosyaları ile aynı büyüklükte olmalıdır.

SQL> alter database add standby logfile thread 1 group 4 size 104857600;

SQL> alter database add standby logfile thread 1 group 5 size 104857600;

SQL> alter database add standby logfile thread 1 group 6 size 104857600;

SQL> alter database add standby logfile thread 1 group 7 size 104857600;

Primary veritabanı üzerindeki her instance için redo taşımasını standby veritabanına doğru yapılandırın.Bu işlemi primary sitede sadece bir düğümde yapmak yeterlidir.

SQL> alter system set log_archive_config=’dg_config=(rac,racstd)’ sid=’*’ scope=both;

SQL> alter system set log_archive_dest_2=’service=racstd SYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=racstd’ sid=’*’ scope=both;

Hem primary, hemde standby için SCAN listener kayıtlarını yapıyoruz ve Data Guard Broker ile uyumlu çalışması için tnsnames dosyasında gerekli eklentileri yapıyoruz. Oracle 11.2 sürümünden itibaren SCAN listener cluster içinde VIP listenerler yerine listener.ora dosyası içerisinde yer almaktadır ve tüm düğümler için ayrı ayrı ADDRESS yerine, tek bir SCAN address yeterli gelmektedir. Primary ve standb sitede farklı 2 clusterware olduğundan dolayı 2 farklı SCAN adresi vardır, rac-scan ve racstd-scan olmak üzere.rac-scan SCAN adresi primary site düğümlerini, racstd-scan SCAN adresi ise standby site düğümlerini işaret etmektedir.

Aşağıdaki girişi primary sitedeki düğümlerin tnsnames.ora dosyalarının içerisine ekliyoruz ve ardından standby sitedeki tüm düğümlere bu tnsnames.ora dosyasını kopyalıyoruz. Bu arada, sqlnet.ora dosyasınıda standby düğümlere kopyalamakta fayda var.

RAC =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = rac)

)

RACSTD =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = racstd-scan)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = racstd)

)

Alttaki girişi linux1_rac ve linux1_racstand sunucularındaki listener.ora dosyası içerisine teker teker ekliyoruz.

SID_LIST_LISTENER =(

SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = rac)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = rac1)

)

(SID_DESC =

(GLOBAL_DBNAME = racstd)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = racstd1)

)

(SID_DESC =

(GLOBAL_DBNAME =rac_DGMGRL)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = rac1)

)

(SID_DESC =

(GLOBAL_DBNAME = racstd_DGMGRL)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = racstd1)

)

linux2_rac ve linux2_racstand sunucularındaki listener.ora dosyasınada yukardaki girişi racstd1 ve rac1 olan SID_NAME değerlerini, racstd2 ve rac2 olarak değiştirdikten sonra.ekliyoruz.

Standby için oracle password dosyaları oluşturun. Oracle RAC ortamında dataguard yapılandırmasında karşılaşılan ORA-16191 hatasını almamak için ignorecase=y takısını ekleyin. Standby tekli instance gibi oluşturulacak ve ardından RAC etkinleştirilecektir. Bu sebeple 3 tane password dosyası oluşturuyoruz. Biri RAC veritabanı için, biri birinci RAC düğümdeki instance için, diğeri ise ikinci RAC düğümündeki instance içindir

orapwd file=orapwracstd entries=100 password=password1 ignorecase=y

orapwd file=orapwracstd1 entries=100 password=password1 ignorecase=y

orapwd file=orapwracstd2 entries=100 password=password1 ignorecase=y

Standby sitedeki tüm düğümlerdeki stanby veritabanında kullanılmak üzere $ORACLE_HOME/dbs dizini altında initracstd.ora adında bir pfile dosyası oluşturuyoruz ve bu boş dosyanın içine aşağıdaki değerleri giriyoruz.

*.cluster_database=FALSE

*.db_name=’racstd’

Standby sitede $ORACLE_BASE/admin/racstd/adump dizinini oluşturun.

[root@linux1_racstand] # mkdir $ORACLE_BASE/admin/racstd

[root@linux1_racstand] # mkdir $ORACLE_BASE/admin/racstd/adump

[root@linux1_racstand] # chown oracle:oinstall $ORACLE_BASE/admin/racstd

[root@linux1_racstand] # chown oracle:oinstall $ORACLE_BASE/admin/racstd/adump

[root@linux1_racstand] # chmod –R 775 $ORACLE_BASE/admin/racstd/adump

Oracle password dosyalarını kullanarak primary ve standby servislerine bağlantının tnsnames.ora dosyası üzerinden sağlandığından emin olun.

[root@linux1_racprim] # sqlplus sys/password1@rac as sysdba

[root@linux1_racprim] # sqlplus sys/password1@racstd as sysdba

Standby sitede bir düğümde veritabanını NOMOUNT modda açıyoruz.

[oracle@linux1_racstand] $ set ORACLE_SID=racstd

[oracle@linux1_racstand] $ sqlplus / as sysdba

SQL> startup nomount using pfile=’$ORACLE_HOME/dbs/initracstd.ora’;

RMAN scriptini kullanarak aktif olarak çalışan primary veritabanından standby RAC veritabanı oluşturulacaktır. Bu amaçla bazı parametrelerin standby veritabanını destekleyecek şekilde değiştirilmesi gerekmektedir. Bu scripti çalıştırmadan önce standby sitedeki standby RAC veritabanını NOMOUNT modda başlatıyoruz.

[oracle@linux1_rac] $ rman target / auxiliary system/password1@racstd nocatalog

run {

allocate channel rac type disk;

allocate channel rac1 type disk;

allocate auxiliary channel racstd type disk;

duplicate target database for standby

from active database

DORECOVER

spfile

parameter_value_convert ‘rac’,’racstd’

set db_unique_name=’racstd’

set db_file_name_convert=’+DATA/RAC’,’+DATA/RACSTD’

set log_file_name_convert=’+ DGSTDBY/RAC’,’+ DGSTDBY/RACSTD’

set fal_client=’racstd’

set fal_server=’rac’

set standby_file_management=’AUTO’

set log_archive_config=’dg_config=(rac,racstd)’

set log_archive_dest_2=’service=rac SYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=rac’;}

Yukardaki işlem sonunda, klonlanan veritabanı standby veritabanı olarak, RAC adlı tüm dizinler yerini RACSTD’ye bırakacaktır. Primary sunucu rolünü standby veritabanında belirtmek için FAL_SERVER parametresine primary veritabanını yazıyoruz. Bunun yanında, eşzamanlı redo taşıması olacak, yani primary veritabanında bir redo dosyasından diğer redo dosyasına yazmaya geçiş olduğunda(switch) en son yazılmış redo log dosyasının içeriği, anında standby veritabanında ilgili standby log dosyası olarak yazılmaya başlanacaktır(redo shipping).

Oluşturduğumuz standby veritabanını(RACSTD) ve standby instanceleri(RACSTD1 ve RACSTD2) OCR içerisine aşağıdaki gibi kayıt ediyoruz . Standby sitedeki herhangi bir düğümden bu işlem yapılmalıdır.

[oracle@linux1_racstand] $ srvctl add database -d RACSTD –o /u01/app/oracle/product/11.2.0/db_1 -s mount -r physical_standby -c RAC

[oracle@linux1_racstand] $ srvctl add instance -d RACSTD -i RACSTD1 -n linux1_racstand

[oracle@linux1_racstand] $ srvctl add instance -d RACSTD -i RACSTD2 -n linux2_racstand

Standby RAC veritabanını çalıştırarak yapılandırmanın doğruluğunu kontrol ediyoruz.

[oracle@linux1_racstand] $ srvctl status database -d RACSTD
Instance racstd1 is not running on nodeLINUX1_RACSTAND
Instance racstd2 is not running on node LINUX2_RACSTAND

[oracle@linux1_racstand] $ srvctl start database -d RACSTD

[oracle@linux1_racstand] $ srvctl status database -d RACSTD
Instance racstd1 is running on nodeLINUX1_RACSTAND
Instance racstd2 is running on node LINUX2_RACSTAND

Standby veritabanı için ASM dosya yapısı içerisinde bir spfile oluşturacağız, ardından bu spfile değişikliğini standby RAC veritabanında etkinleştireceğiz.

SQL> ALTER SYSTEM SET CLUSTER_DATABASE=’TRUE’ SCOPE=BOTH;

SQL> CREATE SPFILE=’+DATA/RACSTD/SPFILERACSTD.ORA’ FROM MEMORY;

[oracle@linux1_racstand] $ srvctl modify database -d racstd -p ‘+DATA/RACSTD/SPFILERACSTD.ORA’

[oracle@linux1_racstand] $ srvctl config database -d racstd

Database unique name: racstd

Database name:

Oracle home: /u01/app/oracle/product/11.2.0/db_1

Oracle user: oracle

Spfile: +DATA/RACSTD/spfileracstd.ora

Domain:

Start options: mount

Stop options: immediate

Database role: PRIMARY

Management policy: AUTOMATIC

Server pools: racstd

Database instances: racstd1,racstd2

Disk Groups: DATA,DGSTDBY

Mount point paths:

Services:

Type: RAC

Database is administrator managed

Standby RAC veritabanını mevcut log dosyasından redo taşıması yapacak şekilde geri yükleme durumunda başlatın.Standby RAC düğümlerin sadece birinde bu işlemi yapın.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Standby RAC veritabanına primary RAC veritabanından redo taşımasının ve uygulamasının başarılı şekilde çalıştığını test edin.Aşağıdaki sorguyu hem primary hemde standby sitedeki birer düğümde çalıştırın ve sonuçların birbiri ile aynı olduğunu teyit edin. Bu durumda redo taşıma hizmetleri sorunsuz olarak çalışmaktadır.

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SQL> select PROTECTION_MODE, PROTECTION_LEVEL, OPEN_MODE, DATABASE_ROLE from v$database;

PROTECTION_MODE PROTECTION_LEVEL OPEN_MODE DATABASE_ROLE

——————– ——————– ——————– —————-

MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE MOUNTED PHYSICAL STANDBY

SQL> select * from v$archive_gap;

no rows selected

Data Guard Broker kurulumunu tamamlıyoruz. Hem primary, hemde standby RAC veritabanlarında düğümlerin her birinde aşağıdaki komutları çalıştırıyoruz.

Primary veritabanı için;

SQL> alter system set dg_broker_config_file1=’+ DGSTDBY/rac/dr1rac.dat’ scope=both sid=’*';

SQL> alter system set dg_broker_config_file2=’+ DGSTDBY/rac/dr2rac.dat’ scope=both sid=’*';

SQL> alter system set dg_broker_start=true scope=both sid=’*';

Standby veritabanı için ise;

SQL> alter system set dg_broker_config_file1=’ +DGSTDBY/racstd/dr1racstd.dat’ scope=both sid=’*';

SQL> alter system set dg_broker_config_file2=’ +DGSTDBY/racstd/dr2racstd.dat’ scope=both sid=’*';

SQL> alter system set dg_broker_start=true scope=both sid=’*';

Data Guard Yapılandırmasını oluşturuyoruz. dgmgrl komutunu kullanarak önce primary veritabanını tanımlıyoruz, arkasından standby veritabanını tanımlıyoruz ve konfigürasyonu etkinleştiriyoruz.

DGMGRL> connect /

Connected.

DGMGRL> create configuration “DataGuard” as primary database is “rac” connect identifier is rac;

Configuration “DataGuard” created with primary database “rac”

DGMGRL> add database “racstd” as connect identifier is racstd;

Database “racstd” added

DGMGRL> enable configuration;

Enabled.

DGMGRL> show configuration;

Configuration – DataGuard

Protection Mode: MaxPerformance

Databases:

rac – Primary database

racstd – Physical standby database (disabled)

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

DGMGRL> show configuration verbose;

Configuration – DataGuard

Protection Mode: MaxPerformance

Databases:

rac – Primary database

racstd – Physical standby database (disabled)

Properties:

FastStartFailoverThreshold = ’30′

OperationTimeout = ’30′

FastStartFailoverLagLimit = ’30′

CommunicationTimeout = ’180′

FastStartFailoverAutoReinstate = ‘TRUE’

FastStartFailoverPmyShutdown = ‘TRUE’

BystandersFollowRoleChange = ‘ALL’

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

DGMGRL> show database “rac”;

Database – rac

Role: PRIMARY

Intended State: TRANSPORT-ON

Instance(s):

rac1

rac2

Database Status:

SUCCESS

DGMGRL> show database “racstd”;

Database – racstd

Role: PHYSICAL STANDBY

Intended State: APPLY-ON

Transport Lag: 0 seconds

Apply Lag: 0 seconds

Real Time Query: OFF

Instance(s):

racstd1 (apply instance)

racstd2

Database Status:

SUCCESS

19. Hem primary RAC veritabanında hemde standby RAC veritabanında Flashback Database özelliklerini etkinleştiyoruz.

Primary veritabanındaki herhangi bir düğümde;

SQL> alter database flashback on;

Database altered.

Standby veritabanındaki herhangi bir düğümde;

DGMGRL> edit database “racstd” set state=’apply-off’;

Succeeded.

SQL> alter database flashback on;

Database altered.

DGMGRL> edit database “racstd” set state=’apply-on’;

Succeeded.

20. Fast Start Failover özelliğini etkinleştiriyoruz. Böylece primary RAC veritabanı veri dosyalarının bir kısmı erişilemez olduğunda veya kontrol dosyalarından bazıları bozulduğunda veya blok bozulması meydana geldiğinde, otomatik olarak standby veritabanı READ-WRITE işlemlerine açılacak ve primary RAC veritabanı rolüne dönecektir.

DGMGRL> show fast_start failover;

Fast-Start Failover: DISABLED

Threshold: 30 seconds

Target: (none)

Observer: (none)

Lag Limit: 30 seconds

Shutdown Primary: TRUE

Auto-reinstate: TRUE

Configurable Failover Conditions

Health Conditions:

Corrupted Controlfile YES

Corrupted Dictionary YES

Inaccessible Logfile NO

Stuck Archiver NO

Datafile Offline YES

Oracle Error Conditions:

(none)

DGMGRL> enable fast_start failover;

Enabled.

DGMGRL> show fast_start failover;

Fast-Start Failover: ENABLED

Threshold: 30 seconds

Target: racstd

Observer: (none)

Lag Limit: 30 seconds

Shutdown Primary: TRUE

Auto-reinstate: TRUE

Configurable Failover Conditions

Health Conditions:

Corrupted Controlfile YES

Corrupted Dictionary YES

Inaccessible Logfile NO

Stuck Archiver NO

Datafile Offline YES

Oracle Error Conditions:

(none)

Data Guard yapılandırma testleri

Data Guard yapılandırmasının başarıyla tamamlanmasından sonra uygulamanın düzgün çalışıp çalışmadığını test yapmak amacıyla switchover ve failover işlemleri yapıyorum. Bu testlere geçmeden önce kısaca switchover ve failover işleminin ne anlama geldiğini kısaca açıklayayım.

Switchover: Primary veritabanın rolünü standby sunucuya olağan durumlarda devretme olayına switchover denir. Genellikle primary veritabanında işletim sistemi güncellemesi veya donanım yükseltmesi gibi planlanan kesintiler olacağı zaman meydana gelir. Switchover esnasında herhangi bir veri kaybı yaşanmaz. Switchover sonrasında her veritabanı yeni rolünde görev yapmaya başlar.

Failover: Dataguard ortamında failover primary veritabanının erişilemez olduğu durumlarda kullanılır. Belirli bir sure zarfında servisi geri yükleme imkanı olmaz.

Switchover işleminin yapılması:

DGMGRL> switchover to racstd;

DGMGRL> show configuration;

Configuration – DataGuard

Protection Mode: MaxPerformance

Databases:

racstd – Primary database

rac – (*) Physical standby database

Fast-Start Failover: ENABLED

Configuration Status:

SUCCESS

Koruma modunun Data Guard ortamında değiştirilmesi:

DGMGRL> edit configuration set PROTECTION MODE AS MaxAvailability;

Succeeded.

DGMGRL> show configuration;

Configuration – DataGuard

Protection Mode: MaxAvailability

Databases:

rac – Primary database

racstd – Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

DGMGRL> edit configuration set PROTECTION MODE AS MaxProtection;

Succeeded.

DGMGRL> show configuration;

Configuration – DataGuard

Protection Mode: MaxProtection

Databases:

rac – Primary database

racstd – Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

SQL> select NAME, DATABASE_ROLE, DATAGUARD_BROKER, PROTECTION_MODE,PROTECTION_LEVEL from v$database;

NAME DATABASE_ROLE DATAGUAR PROTECTION_MODE PROTECTION_LEVEL

——— —————- ——– ——————– ——————–

TST PRIMARY ENABLED MAXIMUM PROTECTION MAXIMUM PROTECTION

Oracle 11.2.0.2 sürümünden itibaren dgmgrl komut satırı içerisinden SQL cümleleri çalıştırılabilmektedir. Aşağıda bununla ilgili bir kaç örnek bulunmaktadır.

[oracle@raclinux1 ~]$ dgmgrl

DGMGRL for Linux: Version 11.2.0.2.0 – 64bit Production

Welcome to DGMGRL, type “help” for information.

DGMGRL> connect /

Connected.

DGMGRL> sql “alter system archive log current”;

Succeeded.

DGMGRL> sql “alter system switch logfile”;

Succeeded.

DGMGRL> sql “alter system archive log current”;

Succeeded.

Failover işlemi ile primary ve standby rollerin değiş tokuşu:

DGMGRL> connect sys/password1@racstd

Connected.

DGMGRL> failover to racstd;

Performing failover NOW, please wait…

Failover succeeded, new primary is “racstd”

Evet makalemizin sonuna geldik, dünya üzerine örneği bulunmayan bu makaleyi siz değerli ÇözümPark ziyaretçileri ve üyeleri için hazırladım. Umarım faydalı bir makale olmuştur.

Merhaba, bu makalemizde sizlere Oracle Dataguard mimarisinde Redo Log taşıma hizmetlerinin iyleştirmesini anlatacağım.

Primary veritabanında uygun veri koruma modunun ayarlanması

Standby veritabanında redo boşluklarının olmaması için primary veritabanı üzerinde uygun veri koruma modunun seçimi gerekmektedir. Üç çeşit veri koruma modu vardır.

Maksimum uygunluk

Bu koruma modu primary veritabanının erişilebilirliğinde taviz vermeden en yüksek seviyede veri koruma seviyesini belirtir. İşlemler, herhangi bir çökmede geri kurtarmayı sağlayacak verinin online redo log dosyalarına yazılmadan ve bu redo log dosyalarının en azından bir standby veritabanına senkronize olmadan COMMIT işlemine izin vermez. Bu mod sıfır veri kaybı sağlar, ancak birkaç saniyelik düşmeler redo veri setlerinin standby veritabanına taşınmasını engellemez ve bu birkaç saniyelik düşmelerin olduğu zaman zarfında veri kaybı yaşanma ihtimali yüksektir.

Maksimum performans

Bu koruma modu primary veritabanının performansını etkilemden un yüksek seviyede veri koruma seviyesini belirtir. İşlemler, online redo log dosyasına yazılır yazılmaz COMMIT olur. Redo verisi daha sonra eşzamanlı olmadan standby veritabanına yazılır. Böylece bu mod aktifken, primary veritabanı eşzamanlı redo taşıması esnasındaki gecikmelerden kaynaklanan performans sıkıntısını yaşamaz. Bu mod varsayılan koruma modudur ve primary veritabanı performansı üzerinde etkisi sınırlıdır.

Maksimum koruma

Bu koruma modu primary veritabanı çöktüğü zaman sıfır veri kaybını sağlar. İşlem commit olmadan önce aynı maksimum uygunluk modunda olduğu gibi hem primary redo log dosyalarına yazılmalı hemde en az bir standby veritabanına yazılması gerekmektedir. Veri kaybının yaşanmaması eğer redo dosyalarını en az bir standby veritabanına yazamazsa primary veritabanı kendini kapatır, böylece veri kaybı ihtimalini ortadan kaldırır. En az 2 standby veritabanı kullanıldığı Dataguard mimarilerinde bu modun seçimi tavsiye edilir.

Primary veritabanında veri koruma modunu değiştirmek için aşağıdaki adımları izleyebilirsiniz.

1 - Aşağıdaki tablodan uygunluk, performans ve veri koruma isteklerinizi karşılayacak modu seçiniz.

Maksimum Uygunluk	Maksimum Performans	Maksimum Koruma
AFFIRM	NO AFFIRM	AFFIRM
SYNC	ASYNC	SYNC
DB_UNIQUE_NAME	DB_UNIQUE_NAME	DB_UNIQUE_NAME

2 - Redo taşıma hizmetinin en azından bir standby veritabanında etkinleştirildiğinden emin olun.

LOG_ARCHIVE_DEST_n başlangıç parametresi değeri yukardaki tablodaki en uygun mod için listelenen redo taşıma

değerlerini almalıdır.

LOG_ARCHIVE_DEST_2='SERVICE=orclprm ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILE,

PRIMARY_ROLE) REOPEN=5 COMPRESSION=ENABLE DB_UNIQUE_NAME=orclprm'

Örneğin; yukardaki standby veritabanında parametre değeri redo taşıma hizmetinin eş zamanlı olmayacağını, redo logların arşivlendikten sonra standby veritabanına senkronize edileceğini, NOAFFIRM değeri ile kaynak veritabanında alınan redo dosyasının standby veritabanına yazılana kadar doğruluğunun sağlanmayacağını, böylece read-only standby veritabanlarında yapılan raporlamalarda bu verilerin işleme sokulmayacağını garantiye alır.

VALID_FOR değeri ise standby sunucu primary olarak rol değiştirdiği zaman kendisinin primary olduğunu ve bu durumda sadece online redo dosyası taşıma hizmeti sunacağını işaret eder.

REOPEN değeri ise primary ile arasındaki bağlantı bir şekilde koptuğunda ne kadar dakika sonra yeniden bağlantı denemesinin yapılması gerektiğini belirtir. Eğer compression etkin ise primary üzerinde akan redo verileri sıkıştırılmış olarak gelecek ve buda network bant genişliğinde rahatlama sağlayacaktır.

3 - DB_UNIQUE_NAME başlangıç parametresinin hem primary veritabanında hemde standby veritabanında servis

ismini işaret ettiğinden emin olun.

Primary veritabanında;

SQL> ALTER SYSTEM SET DB_UNIQUE_NAME='orclprm' SCOPE=SPFILE;

Standby veritabanında;

SQL> ALTER SYSTEM SET DB_UNIQUE_NAME='orclstdby' SCOPE=SPFILE;

4. LOG_ARCHIVE_CONFIG başlangıç parametresinin hem primary hem standby sunucularda ilgili

DB_UNIQUE_NAME değerinin DG_CONFIG listesi içinde eklendiğinden emin olun.

Hem primary hemde standby veritabanlarında;

SQL> ALTER SYSTEM SET

2> LOG_ARCHIVE_CONFIG='DG_CONFIG=(orclprm,orclstdby)';

5. Primary veritabanını kapatıp MOUNT modda tekrar başlatın.Eğer RAC kullanılırsa tüm instancelerı kapatın ve tek

bir instanceı MOUNT modda başlatın.

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

6. Uygun veri koruma modunu etkinleştirin.Eğer RAC kullanıyorsanız durdurduğunuz instancelerı tekrar başlatın.

SQL> ALTER DATABASE

2> SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY |

PERFORMANCE | PROTECTION};

7. Primary veritabanını tekrar başlatın.

SQL> ALTER DATABASE OPEN;

8. Primary veritabanının yeni modda çalıştığını kontrol ediniz.

SQL> SELECT PROTECTION_MODE FROM V$DATABASE;

Redo taşıması için ne kadar bant genişliği yeterli olacaktır?

Dataguard 3 çeşit redo taşıma metodu sunmaktadır: ARCH, LGWR ASYNC, LGWR SYNC

Dataguard yapılandırmalarının amacı redo verisinin uzak siteye veritabanında bir felaket durumunda en kısa zamanda ve en son güncel durumdan eksiksiz geri kurtarma hizmeti vermektir. Eğer gerekli yoğunluğu ele alabilecek yeterli bant genişliği mevcut değilse hiç bir iyileştirme hizmeti sonuç vermez. Ne kadar bant genişliği kullanılacak sorusuna cevap vermek için ise, önce primary veritabanından ne kadar redo yoğunluğu olduğunun incelenmesi gerekmektedir.

Bu yoğunluğun hesaplanması için en kolay yol, veritabanının normal ve yoğun kullanıldığı zamanlarda AWR(Automatic Workload Repository) raporlarını toplamak ve primary veritabanının ürettiği redo verisini saniye başı byte miktarı olarak belirlemektir. Örneğin, yoğun zamanlarda kullandığınız uygulama 3MB/saniye lik redo verisi üretiyorsa, primary ve standby veritabanlarınız arasındaki network linki en az 3MB/saniye’lik network bant genişliğine sahip olmalı ve bu trafiği işleyebilmelidir. Network bant genişliği Megabits/second(Mbps) olarak tanımlanmakta ve 3 MB/sec de formulasyona göre 25.2 Mbps lik network çıktısına eşit olmaktadır. Bu miktarda yoğunlukta dolayısıyla 1.544 Mbps genişliğindeki T1/DS1 linkinin kapasitesini aşmakta, 44.7Mbps genişlikteki T3/DS3 linkinin sınırları içerisinde kalmaktadır. Bunun yanında networkteki gecikmeler, ISP kalitesi, paket düşmeleri ve link performansı ile ilgili diğer etkenlerde göz önünde bulundurulmalıdır. Bu noktada, redo log dosyalarını taşımak için günlük ne kadar bant ihtiyacı olacağı ve bununla beraber saat başı ne kadar ortalama,minimum ve maksimum Mbps gerekeceği alttaki sorgu sonucu elde edilebilir.

SELECT DT,
SUM(RB*8/3600000000*1.3) TOTAL_Mbps_REQ_FOR_A_DAY,
MIN(RB*8/3600000000*1.3) MIN_Mbps_REQ_FOR_AN_HOUR,
MAX(RB*8/3600000000*1.3) MAX_Mbps_REQ_FOR_AN_HOUR ,
AVG(RB*8/3600000000*1.3) AVG_Mbps_REQ_FOR_AN_HOUR
FROM
(
SELECT TRUNC (COMPLETION_TIME) DT,
TO_CHAR (COMPLETION_TIME,'HH24') HH,
SUM(BLOCKS*BLOCK_SIZE) RB
FROM
V$ARCHIVED_LOG
WHERE COMPLETION_TIME > SYSDATE-5
AND DEST_ID=1
GROUP BY TRUNC(COMPLETION_TIME),
TO_CHAR (COMPLETION_TIME, 'HH24')
)
GROUP BY DT;

AWR raporlarında yardımcı olacak bileşenler altatdır.

· Redo volume – Bu rapor süresince oluşturulan redo miktarı

· Transactions – Rapor için TPS

· Redo writes – Rapor süresince redo yazma sayısı

Bunun yanında V$SYSMETRIC_HISTORY görünümü kullanıcı sorgularının ne kadar sürede yanıtlandığı noktasında faydalı bilgiler vermektedir. Bu görünümden elde edilecek bazı noktalar ise;

· Response Time per Txn – Transcationlar için yanıtlama süresi

· SQL Service Response Time – Kullanıcı çağrı başına yanıt süresi

· Database Time Per Sec – DB Süresi / Geçen Süre

Network bant genişliği gereksinimi hesaplarken sonraki düşünce ise Data Guard koruma modu ve kullanılan taşıma hizmetidir. Örneğin, LGWR SYNC eşzamanlı taşıma redo verisi oluşturma oranlarını ele alırken yetersiz bant genişliği oluduğu durumlarda primary veritabanında performansta darboğazlara sebebiyet verecektir. LGWR ASYNC ise aksine geçici olarak network çıktısının maksimum sınırları aştığı durumlarda bile primary veritabanı performansını etkilemeden online redo logları kullanarak tamponda redo oluşturmaya devam eder. ARCH moduda tampon olarak lokal arşiv log dosyalarını kullanarak aynı işlevi sağlar, ancak LGWR ASYNC’e göre daha fazla veri kaybı riski ortaya çıkarabilir. Primary ve standby arasında gerekli bant genişliği hesaplamasından sonra her taşıma modu için alttakileri uygulayabilirsiniz.

ARCH Redo Taşıması

· ARCn proses sayısını artırmayı göz önünde bulundurun. Veritabanı oluşturulurken bu değer 2’dir.

LOG_ARCHIVE_MAX_PROCESSES başlangıç parametresi maksimum ARCn proses değerini işaret eder. Oracl 9i için

maksimum 10, Oracle 10g Release2 için ise maksimum 30 olabilir. Yüksek ARCn proses değeri network ağı

genişlediğinde veya standby veritabanı kesintiye uğradığında kolayca arşiv dosyası sorunlarını çözmeye yardımcı

olur. Bunun yanında yüksek ARCn değeri, remote archiving parallism özelliğini desteklemektede yardımcı

olmaktadır.

· MAX_CONNECTIONS başlangıç parametre değerini 2’ninüzerine çıkarın. Bu sayede arşiv logların transferi

hızlanacaktır. Makimum değeri 5’dir.

LGWR SYNC Redo Taşıması

· NET_TIMEOUT değerini primary veritabanı performansında network kesintilerine etki etmemesi için düşürün.

Bu değer, primary veritabanındaki LGWR isteklerine cevap vermek için bekleyen Oracle Net Servislerininin LGWR

saniye değerini belirtir. Oracle 10g Release2 için varsayılan değer 180 saniye’dir. Oracle gereksiz yere standby

veritabanından bağlantının kesilmemesi için bu değerin en az 10 saniye olarak ayarlanmasını tavsiye eder. Bu

değerin yeterince kısa olması bant genişliğindeki rahatlama sürelerini azaltacağından potensiyel olarak veri

kayıpları meydana gelebilir.

· LGWR SYNC kullanılırken redo hem primary hemde standby veritabanına yazılmadan o redonun içindeki

transactionlara COMMIT izin verilmez. Alternatif olarak COMMIT NOWAIT ile commitler henüz veritabanında

commit olmamasına rağmen programa geri döner ve böylece programda gecikmeler meydana gelmez. Bu yüzden

programlarda cevap süresinin optimizasyonunda transactionlarda COMMIT NOWAIT kullanmak performans

açısından önem kazanır.

Tüm Redo Taşımaları için tavsiyeler

· Standby redo log dosyalarının ayrı fiziksel disklerde tutulduğundan emin olun.

· Standby redo dosyalarını multiplex yapmayın. İlave standby redo log üyeler varsa ek yazmaları engellemek için bunları veritabanından kaldırın.

· Depolama alanlarında tekli I/O isteklerinde en az 1Mb I/O rezerve edin. Bu noktada Stora Uzmanlarından destek alın.

Network hizmetlerinin iyileştirilmesi

· Oracle Net hizmetlerinde RECV_BUF_SIZE ve SEND_BUF_SIZE parametrelerinin BDP(Bandwidth Delay Product

değerinin 3 katına eşit olmasını sağlayın. Bu sayede network çıktısında büyük artışlar sağlanacaktır.

BDP değerini hesaplamak için Linkin bant genişliği ve network Round Trip Time(RTT) değerleri gerekmektedir. RTT değeri, primary veritabanından standby veritabanına network iletişiminde kullanılan seyahat süresidir ve ms(milisaniye) olarak hesaplanır.25ms RTT değerinde 1Gigabit network linkinde BDP değeri;

BDP = 1000Mbps X 0.25sec

BDP = 25000000Mbps / 8 = 3125000 bytes

Soket tampon büyüklüğü = 3125000 X 3 = 9375000

Soket tampon büyüklüğü hem işletim sistemi seviyesinde hemde Oracle net servisleri seviyesinde atanabilir. Bazı Linux işletim sistemi vcersitonlarında bu değerler olduğundan fazla olabilir.Bu Kurumda bu değeri optimal seviyeye indirmeniz gerekmektedir.

Data Guard Broker servisinin kurulu olduğu STANDBY sistemlerde sqlnet.ora dosyasına alttaki ekleme yapılabilir.

RECV_BUF_SIZE=9375000

SEND_BUF_SIZE=9375000

Data guard aktif değilse STANDBY sistemin listener.ora dosyasında alttaki şekilde ekleme yapılabilir.

LISTENER=

(DESCRIPTION=

(ADDRESS=(PROTOCOL=tcp)

(HOST=linux2)(PORT=1521)

(SEND_BUF_SIZE=9375000)

(RECV_BUF_SIZE=9375000) ) )

…

· Oracle Net Session Data Unit(SDU) boyutu olarak 32767 değerini atayın. Bu işlemi Data Guard Broker hizmeti

kullanıyorsanız hem primary hemde standby sistemlerdeki sqlnet.ora dosyasına alttaki gibi ekleyebilirsiniz.

DEFAULT_SDU_SIZE=32767

Eğer Data Guard Broker hizmeti kullanılmıyorsa hem primary hemde standby sistemlerde listener.ora dosyasında ekleme yapılmalıdır. Altta örneği yer almaktadır.

…

(SID_LIST=

(SID_DESC=

(SDU=32767)

(GLOBAL_DBNAME=orcl.test.com)

(SID_NAME=orcl)

(ORACLE_HOME=/u01/app/oracle) ) )

…

· Linuxlarda kuyruk büyüklüğünü kernel network alt sistemleri ve ethetnet kartı sürücüsü arasındada

düzenleyebiliriz. Herhangi bir kuyruk tekrardan boyutlandırılabilir, böylece local tampon aşırı yüklemeleri

sebebiyle kayıplar meydana gelmez. Bu yüzden yüksek bant genişliğindeki networklerde etkili iyileştirme yapmak

için kuyruk büyüklüklerinin mevcut network bağlantımıza uygun olduğundan emin olmamız gerekmektedir. Kuyruk

büyüklükleri için Linux’ta 2 kuyruk tipi önemlidir, arayüz iletim kuyruğu ve network alım kuyruğu. ifconfig ile

gönderim tarafında TXQUEUELENGTH arayüzü seçeneğini artırın, alım tarafında ise NET_DEV_MAX_BACKLOG kernel

parametre değerini artırın. 100ms latency ye sahip 1 gigabitlik network için bir örnek altta yer almaktadır.Bu

şartlarda network için TXQUEUELENGTH değeri en az 10000 olmalıdır. İdeal değerler için Linux üreticilerinin

tavsiyeleri alınmalıdır.

echo 20000 > /proc/sys/net/core/netdev_max_backlog

echo 1 > /proc/sys/net/ipv4/route/flush

ifconfig eth0 txqueuelen 10000

Bu sayede ilişkili network arayüzlerinde alım ve gönderim kuyruk büyüklüğü artacaktır.

Test Evresi	Test süresi (saniye)	Transfer olan veri miktarı	Ulaşılan network çıktısı (Megabits/saniye)	Yüzdesel değişim
İyileştirme öncesi	60	77.2 MB	10.8 Mbps
Network soket tampon büyüklüğünü 16K varsayılan değerinden 3XBDP değerine yükseltikten sonra	60	5.11 GB	731.0 Mbps	665% İyileştirme öncesine gore performanstaki artış
Üsteki ayarlama sonrasında ve donanım kuyruk uzunluklarını 100’den 1000 ‘e yükseltikten sonra	60	6.55 GB	937.0 Mbps	28% iyileşme (önceki değere göre)

Oracle Net servisinde TCP_NODELAY değerinin “yes” olarak ayarlandığından emin olun(bu varsayılan değerdir eğer değiştirilmediyse kurulumda veya sonrasında)

Data Guarda bağlı bekleme olayları

Primary veritabanından standby veritabanına redo gönderirken ayrılan zaman iki ana bölüme ayrılır, networkun bir ucundan diğer ucuna geçerken zaman ve standby sunucu üzerinde diske yazarken geçen zaman. I/O olurken geçen zaman esnasında primary veritabanında sağlanan toplam zamanı ele geçiren bekleme olayları standby üzerinde izlenebilir.

Primary veritabanınından standby veritabanına ARCH veya LGWR prosesleri ile redo gönderirken meydana gelen bekleme olayları altta yer almaktadır. Bu veriler primary veritabanından elde edilir.

Olay İsmi	Proses	Tanımı
ARCH wait on ATTACH	ARCH	Bu bekleme olayı tüm arşivci prosesler tarafından yeni RFS bağlantıları meydana getirme süresindeki geçen süreyi izler.
ARCH wait on SENDREQ	ARCH	Bu bekleme olayı tüm arşivci prosesler tarafından arşiv dosyalarını standbya yazmakla birlikte lokal diskede yazma esnasında geçen süreyi izler.
ARCH wait on DETACH	ARCH	Bu bekleme olayı tüm arşivci prosesler tarafından RFS bağlantısını silme esnasında geçen süreyi izler.
LNS wait on ATTACH	LGWR	Bu bekleme olayı tüm LNS prosesleri tarafından yeni bir RFS bağlantısı meydana getirme süresindeki geçen süreyi izler.
LNS wait on SENDREQ	LGWR	Bu bekleme olayı tüm LNS prosesleri tarafından alınan redoları diske yazmakla birlikte standby arşiv redo dosyalarını açmak ve kapatmak sırasında geçen süreyi izler.
LNS wait on DETACH	LGWR	Bu bekleme olayı tüm LNS prosesleri tarafından RFS bağlantısını silme sürecindeki geçen süreyi izler.
LGWR wait on LNS	LGWR	Bu bekleme olayı LNS prosesinden alınan mesajları beklerken LGWR prosesince geçen süreyi izler.
LNS wait on LGWR	LGWR	Bu bekleme olayı LGWR prosesinden alınan mesajları beklerken LNS prosesince geçen süreyi izler.
LGWR-LNS wait on channel	LGWR	Bu bekleme olayı LGWR tarafından geçen zamanı veya mesajları almak için bekleyen LNS prosesleri tarafından geçen süreyi izler.

Bunun yanında primary veritabanında izlenmesi gereken önemli I/O olayları ise altta yer almaktadır.

Olay İsmi	Proses	Tanım
Log File Sync	LGWR	Ön planın bir işlemi commitleme zamanından, LGWR prosesinin önplana commit işleminin tamamlamasının kabulüne kadar geçen bekleme süresidir. Kullanıcı oturumu commit yaptığında oturumun redo bilgisi redo log dosyasını boşaltma ihtiyacı duyar. Kullanıcı oturumu LGWR prosesini log belleğini redo log dosyasına yazmakla görevlendirir. LGWR yazmayı bitirdiğinde bunu kullanıcı oturumuna ilan eder.
Log File Parallel Write	LGWR	LGWR I/O ları için commit yazma işlemini tamamlamak için geçen zamandır. Redo kayıtlarının parallel olarak yazılmasına rağmen diskteki en son I/O işlemine kadar parallel yazma tamamlanmaz.
DB File Sequential Read	Foreground	Veritabanında ardışık okuma olurken oturum bekler. Bu olay aynı zamanda kontrol dosyası ve dumping data dosyası başlıklarını yeniden inşa etmek için kullanılır ve veritabanı dosya başlıklarını elde eder.

Alttaki sorgu fiziksel standby veritabanındaki I/O bekleme olaylarını listeler.

SQL> SELECT EVENT, TOTAL_WAITS,

ROUND(TIME_WAITED/100) "TIME(S)",

AVERAGE_WAIT*10 "AVG(MS)",

TO_CHAR(SYSDATE, 'DD-MON-YYYY HH:MI:SS') TIME

FROM V$SYSTEM_EVENT

Bu yazıda Oracle 11.2 Dataguard ve RAC kombinasyonundamaksimumerişilebilirlikmimarisininnasılyapılandırılacağınıinceleyeceğiz.İlk önce Fast-Start-Failover işlemiileDataguardmimarisindekesintisizveriiletişimininnasılsağlanacağınıaçıklayacağım, ardındanikifarklıserviskullanarak primary RAC kümesineyazma(INSERT/UPDATE/DELETE) işlemiyapacakbirservisin, fiziksel standby RAC kümesineise salt okumaişlemiyapacakolandiğerbirservisinyapılandırmasınıbirörnekleadımadımaçıklayacağım. Son bölümdeise Oracle 11.2 Dataguard RAC kümesineveritransferiyapan middle-tier uygulamasunucularınınkullandığı JDBC bağlantılarındamaksimumerişilebilirliğisağlayacakolanyapılandırmayıadımadımbirörnekleaçıklayacağım.

Yazıyabaşkarken Oracle 11.2 mimarisindekullanılan Fast-Start-Failover özelliğinin ne anlamageldiğiniinceleyelim.Fast-Start-Failover özelliği, primary veritabanınabağlantıkaybolduğudurumlardadahaöncedenseçilenfiziksel standby veritabanına Data Guard Broker prosesininotomatikolarakbağlantıkurmasıdır. Fast-Start Failover özelliğisadece Data Guard Broker yapılandırmasıiçindekullanılır ve DGMRL komutsatırıveya Enterprise Manager konsoluüzerindenetkinleştirilir.

Fast-Start-Failover hizmeti hem maksimumerişilebilirlik, hemdemaksimumperformansmodundaçalışabilmektedir.Maksimumerişilebilirlikmoduseçiliolduğundasıfırverikaybıgarantiedilmektedir. MaksimumperformansmoduseçiliolduğudurumdaiseFastStartFailoverLagLimitkonfigürasyonparametresiilebelirlenensaniyeiçerisindekiveridendahafazlasınınkaybıönlenmişolmaktadır.

Herhangibir failover durumundabroker’ınkesintisizçalışmasınısağlamakiçin, gözlemciyi(observer) primary ve standby veritabanlarıdışındabirmakineyekurmakfaydalıolacaktır. Hem Dataguard Broker, hemde standby veritabanı primary veritabanıilebağlantıyıFastStartFailoverThresholdparametresindebelirlenensüredendahauzunsüredekaybettiğizaman, broker standby veritabanınadoğru fast-start failover işleminitetikler. Buna ilaveten, eğerFastStartFailoverPmyShutdownparametresi TRUE olarakayarlanmışsa, FastStartFailoverThresholdparametresindekisüredendahauzunsürelikesintidurumunda primary veritabanıkapatılır.

Bununsebebi, redo taşımasıile standby ile primary arasındamuhtemeloluşabilecek redo boşluklarınınönünegeçmektir.Çünküoluşabilecekmuhtemel redo boşluklarında fast-start failover işlemi en iyimserdurumdauzayacak, en kötüdurumda işlem başarısızolacak ve standby sunucunubütünlüğünükaybederekyenidenoluşturulmaihtiyacıduyacaktır.FastStartFailoverAutoReinstateparametresi TRUE olarakayarlandığındaise, failover işlemitamamlandığındaeski primary veritabanınabağlantıtekrarsağlandığındaeski primary veritabanı standby veritabanıdurumunagetirilmişolacaktır.

Uygunkorumamodununbelirlenmesi

Eğermaksimumerişilebilirliközelliğininetkinolmasıisteniyorsabudurumda standby veritabanınınLogXptModeparametresinin SYNC değeriniişaretetmesigerekmektedir.Maksimumperformansmodununetkinolmasıiçinisedurumda standby veritabanınınLogXptModeparametresinin ASYNC değeriniişaretetmesigerekmektedir.

DGMGRL> EDIT DATABASE ’orclprm’ SET PROPERTY LogXptMode=SYNC;

DGMGRL> EDIT DATABASE ’orclstd’ SET PROPERTY LogXptMode=SYNC;

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;

Eğer minimal verikaybındanziyadeperformansdüşünmekteyseniz o zamanmaksimumperformansmodunuetkinleştirmekyeterligelecektir.Ancak, bu mod etkinleştirmedenönce ne kadarsüreiçerisindekiverikaybıkabuledilirmiktardır, bunubelirlemenizgerekmektedir. İştebusüreyiFastStartFailoverLagLimitparametresiiledüzenleyebilirsiniz.Buözellik, saniyedeğeriolarak, primary veritabanındanetkieden redo miktarından ne kadargeridegecikmeolacaktır, onubelirtmektedir. Bu parametresadecemaksimumperformansmodunda, yani standby veritabanında ASYNC aktifikenkullanılabilir, varsayılandeğer 30 saniyedir.En fazla 10 saniye’yedüşürülebilir.

DGMGRL> EDIT DATABASE ’orclprm’ SET PROPERTY LogXptMode=ASYNC;

DGMGRL> EDIT DATABASE ’orclstd’ SET PROPERTY LogXptMode=ASYNC;

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxPerformance;

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverLagLimit=15;

Fast-start failover işlemi, hem gözlemci(broker) hemdefiziksel standby sunucu primary sunucuyabağlantısınıyitirdiğindemeydanagelirdemiştik. İşte, ne kadarlıkzamansonra fast-start failover işlemidevreyegirecekonubelirlemekiçinFastStartFailoverThresholdparametresinisaniyedeğeriolarakayarlanmalıdır.Bu parametreninvarsayılandeğeri 30 saniyedir, en fazla 6 saniye’yedüşürülebilir.Eğerbirdenfazladüğümlü Oracle RAC veritabanıkullanıyorsanızbudeğeri 40 saniyeninüstündetutmanıztavsiyeedilir, çünküOracle RAC instancelerındanbirisibiranlıkerişilemezolursa, istemedendeolsa fast-start failover işlemihemendevreyegirecek ve standby RAC veritabanına failover meydanagelecektir.

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 45;

Fast-start failover işleminietkinleştirmekiçingözlemcimakinedeaşağıdakikomutçalıştırılır.

DGMGRL> ENABLE FAST_START FAILOVER;

Enabled.

DGMGRL> SHOW FAST_START FAILOVER;

Fast-Start Failover: ENABLED
Threshold:           30 seconds
Target:                 orclstd
Observer:            (none)
Lag Limit:           30 seconds
Shutdown Primary:    TRUE
Auto-reinstate:           TRUE

Configurable Failover Conditions
Health Conditions:
    Corrupted Controlfile          YES
    Corrupted Dictionary           YES
    Inaccessible Logfile              NO
    Stuck Archiver                      NO
    Datafile Offline                    YES

Oracle Error Conditions:

(none)

Bununyanındasağlıkşartlarıolarak log dosyalarınınerişilemezolmasıveyaarşivdosyalarının primary sunucudasıkışmasısorunlarındaotomatikolarak fast-start failover meydanagelmez. Eğerbuözelliklerideetkinleştirmek ve fast-start failover işlem alanınadahiletmekiçinENABLE FAST_START FAILOVER CONDITION komutukullanılır.

Bozulmuşkontroldosyasıtespitedildiğinde fast-start failover işlemininotomatik devreyegirmesinietkinleştirmekiçin;

DGMGRL> ENABLE FAST_START FAILOVER CONDITION "Corrupted Controlfile";

ORA-27102 olayımeydanageldiğinde fast-start failover işlemininotomatik devreyegirmesinietkinleştirmekiçin;

DGMGRL> ENABLE FAST_START FAILOVER CONDITION 27102;

Eğergözlemcimakinekullanılıyorsaaşağıdakikomutla observer servisibumakinedbaşlatılmalıdır.

DGMGRL> START OBSERVER;

Primary ve Fiziksel Standby veritabanlarındaservislerilekusursuzerişilebilirliğinsağlanması

Oracle 11.2 sürümüilegelenSCAN(Single Class Access Name) hizmeti, kümeiçindeki her birdüğümünistemcilertarafındantekertekerbilinmesinegerekduyulmadan, en optimal işyükününotomatikolarakDBA'yeihtiyaçduymadanhesaplanması ve buistemcinin en uygundüğümeyönlendirilmesinisağlayanprosesdir. Bu sayedeistemcitarafındakiyükdengelemesiyönetimi DBA leriçinızdırapolmaktançıkıp, clusterwaretarafındanotomatikolarakyönetilmektedir.Sunucutarafındakiyükdengelemesiise, talepedilenservisiçin en azyüklü instance bulmakamacıyla SCAN tarafındankontroledilir ve budüğümünlokallistenerınabutalepyönlendirilir.

Rolbazlıveritabanıservisleri, Oracle Clusterwareveya Oracle Restart içerisindenyapılandırılır. Oracle Dataguard, OracleClusterwareveya Oracle Restart ileetkileşimegeçerek primary-standby roldeğiştokuşusonundagerekliservislerinaktifolmasınısağlar, böylecesistemibaşlatmaolayıiçinherhangibir trigger yazılmasınadagerekkalmaz.

Aşağıdakiörnekte 2 düğümlü RAC adlı primary veritabanında“HR_APP” adlıservis primary roldeaktiftir.2 düğümlü RACSTD adlı standby veritabanında da “HR_REPORT” adlıservisiseraporlamahizmetleriyapmaküzerefiziksel standby rolündeaktiftir.

[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_APP -l PRIMARY -q TRUE -e SELECT –m BASIC -w 10 -z 150

[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_REPORT -l PHYSICAL_STANDBY -q TRUE –e SELECT -m BASIC -w 10 -z 150

Herhangibir switchover/failover durumunda HR_APP servisinin primary olarakhizmetvermeyedevametmesiiçin RACSTD adlı standby veritabanındadaaşağıdakigibiservislereklenmiştir.

[oracle@linux1_racstand] $ srvctl add service -d RACSTD -s HR_APP -l PRIMARY -q TRUE -e SELECT –m BASIC -w 10 -z 150

[oracle@linux1_racstand] $ srvctl add service -d RACSTD -s HR_REPORT -l PHYSICAL_STANDBY -q TRUE –e SELECT -m BASIC -w 10 -z 150

Fiziksel standby sunucuya redo taşımasıyoluylataşındığındaneminolmakiçin“HR_REPORT” adlıservisin primary veritabanında SRVTL START SERVICE ilebaşlatılması ve ardından SRVCTL STOP SERVICE ilededurudurulmasıgerekmektedir.

[oracle@linux1_rac] $ srvctl start service -d RACSTD -s HR_APP

[oracle@linux1_rac] $ srvctl stop service -d RACSTD -s HR_APP

HerhangibirDataguard Failover işleminitakiben, Oracle Data Guard Broker hatalı primary veritabanınabağlantılarıtemizlemesiiçinotomatikolarakFAN(Fast Application Failover) olayıyayınlar. Olayınalımınıtakiben FAN alımaboneleriyeni primary veritabanındabaşlayanserviseotomatikolarakyenidenbağlanırlar.

Kusursuzuygulama(application) failover işlemi disk arızası, data bozulması, donanımsalarıza, programınaskıdakalmasıgibioldukçasıkmaydanagelebileceklokalarızalardurumundaoldukçaelverişlidir. Kusursuzuygulama failover işleminde 3 anaparçavardır.

Yeni primary sitede/sunucudaservislerinyenidenbaşlatılması
Uygulamalarımevcutbağlantılarınısonlandırmasıiçinbilgilendirme
En elverişlişekildeuygulamalarınyenidenbağlantıaçmasınısağlama

Kusursuzuygulama failover işlemiiçin cluster ortamında Oracle Clusterware, tekil instance ortamında Oracle Restart olmalı ve her ikidurumdadaDataGuard Broker aktiveli Oracle DataGuardyapılandırmasınaihtiyaçduyulmaktadır.

JDBC uygulamalarındakusursuz application failover yapılandırması

Oracle veritabanınayapılan JDBC bağlantılarındakusursuz application failover işlemiiçinoluşturulacakolanservis hem primary hemdefiziksel standby sitedeoluşturulmalıdır. Servisleringerek normal çalışmadurumunda primary sitede primary rolde işlem yapması, gerekseherhangibir switchover/failover durumundayeni primary rolünegeçenclusterdada primary roldebaşlamasıiçin primary ve standby cluster içindeilgiliservislerioluşturuyoruz.Burdaönemliolannokta; sadece JDBC bağlantılarındakullanılacakolanservislerioluştururken, TAF ve OCI HA olaylarınıdevredışıbırakmamızgerekmektedir (alttakiörneklerdekikırmızıkısımlar).

Primary cluster içinde;

[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_APP -r linux1_rac, linux2_rac -l PRIMARY -q FALSE -e NONE -m NONE -w 0 -z 0

[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_REPORT -r linux1_rac, linux2_rac -l PHYSICAL_STANDBY -q FALSE -e NONE -m NONE -w 0 -z 0

Standby cluster içinde:

[oracle@linux1_racstand] $ srvctl add service -d RAC -s HR_APP -r linux1_racstand, linux2_racstand -l PRIMARY -q FALSE -e NONE -m NONE -w 0 -z 0

[oracle@linux1_racstand] $ srvctl add service -d RAC -s HR_REPORT -r linux1_racstand, linux2_racstand -l PHYSICAL_STANDBY -q FALSE -e NONE -m NONE -w 0 -z 0

JDBC bağlantısındamaksimumerişilebilirliğisağlamakiçinkullanılacakolanservislerioluşturduktansonra HR_REPORT servisininprimaryden standby siteye redo taşımasınıbaşlatmasıiçin primary sitede SRVCTL START SERVICE ilebaşlatılmalıdır.

[oracle@linux1_rac] $ srvctl start service -d RACSTD -s HR_APP

Oracle JDBC sürücüsüyüklenmelidir. Her bir site için SCAN adresiiçerecekadreslistesinitaşıyacakolanbağlantıtanımlayıcısınınkullanılmasıgerekmektedir. Aşağıdakiörnek HR_APP uygulamasıiçindir. Eğerraporlamaiçindejdbcbağlantısıkullanılacaksabudurumda HR_REPORT servisiiçindeaşağıdakigibigirişoluşturulmalı ve yüklenmelidir.

"jdbc:oracle:thin:@" + "(DESCRIPTION_LIST=" +

"(LOAD_BALANCE=off)" + "(FAILOVER=on)" + "(DESCRIPTION=" + "(ADDRESS_LIST=" + "(LOAD_BALANCE=on)" + "(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521)))" + "(CONNECT_DATA=(SERVICE_NAME=hr_app)))" + "(DESCRIPTION=" + "(ADDRESS_LIST=" + "(LOAD_BALANCE=on)" + "(ADDRESS=(PROTOCOL=TCP)(HOST=racstd-scan)(PORT=1521)))" + "(CONNECT_DATA=(SERVICE_NAME=hr_app))))";

JDBC URL üzerindenyapılanbağlantısonrasında Oracle NET servisi DNS ileiletişimegeçerek RAC primary sitesinin SCAN adresinitoplam 3 IP adresineçözümler.Rastgelebirtanesiniseçerekbağlantısağlar.Eğer primary üzerinebağlantıbaşarısızolursabudurumda RACSTD standbysitesindeki SCAN üzerindenrastgelebirtanesiüzerindenbağlantısağlar.

Eğer TCP_CONNTIMEOUT_STR özelliğiayarlanırsa, JDBC istemcisiçokkolaybirşekildeadreslistesinetaşınır.

Properties prop = new Properties();

prop.put(oracle.net.ns.SQLnetDef.TCP_CONNTIMEOU T_STR, ""+5000); // 5000ms

pds.setConnectionProperties(prop);

Fast Connection Failover işleminiaşağıdakiadımlardaanlatıldığışekildeaktiveediyoruz.

Bu işlem içinONS(Oracle Notification Services) tümdüğümlerdeaktifolmalıdır. Tümdüğümlere ONSCTL PING komutuyla ping çekiyoruz ve ONS ninaktifolupolmadığınıkontrolediyoruz. ONSCTL PING komutununcevapvermediğidüğümlerdesırasıylakomutlarınıçalıştırırak ONS servisinikuruyoruz.

$ srvctl add ons

$ srvctl enable ons

$ srvctl start ons

Eğer application tier ONS üzerinde çalışıyorsa cluster düğümlerini application ONS ye duyarlı hale getiriyoruz.ORA_CRS_HOME/bin/racgons dizini altından aşağıdaki komutu primary ve standby sitelerde yeni bir terminal penceresinde root hesabı ile oturum açarak çalıştırıyoruz.

# racgons.binadd_config linux1_rac:6200 linux2_rac:6200 linux1_racstand:6200 linux2_racstand:6200

VerikaynağıüzerindesetFastConnectionFailoverEnabled(true)parametresiile Fast Connection Failover işleminiayarlayarakuygulamanın hem primary hemde standby sitedeki ONS bekleticiprogramlarına(daemons) bağlanmaişleminitamamlıyoruz.

ods.setConnectionCachingEnabled(True);

Properties prop = new Properties();

prop.setProperty("MinLimit", "5");

prop.setProperty("MaxLimit", "40");

prop.setProperty("InitialLimit", "10");

ods.setConnectionCacheProperties(prop);

ods.setFastConnectionFailoverEnabled(True);

ods.setConnectionCacheName(“MyCache”);

ods.setConnectionCacheProperties(cp);

ods.setONSConfiguration("nodes= linux1_rac:6200,linux2_rac:6200, linux1_racstand:6200,linux2_racstand:6200");

Umarımfaydalıbirmakaleolmuştur.

Bu yazıda, Oracle veritabanında performansı önemli derecede azaltan belli başlı “Oracle bekleme olaylarını” neler olduğu, bu bekleme olaylarını kabul edilir seviyelere çekmek için yapılması gereken eylemleri tavsiyeler ışığında inceleyeceğiz. Oracle veritabanı kullanan her veritabanı uzmanının mutlaka karşı karşıya kaldığı bu bekleme olaylarının hangilerinin veritabanı yönetimindeki eksikliklerden oluştuğunu, hangilerinin kullanılan programın yapısal eksikliklerinden olduğunu karşılaştıracağız. Ayrıca Dataguard veya RAC tabanlı bekleme olayları bu yazıda yer almadığından bu yapılarda Oracle veritabanı hizmeti kullanmayan pek çok firmanın veritabanı yöneticisi için faydalı bir yazı olacağını düşünüyorum.

Ayrıca bu yazıdaki bekleme olaylarını tespit etmek için SQL*Plus ekranından çalıştırılacak SQL cümleleri ile sorun tespiti vasıtasıyla, karışık analiz işlemleri/programları kullanım ihtiyacı ortadan kaldırılmıştır. Kullanılan analiz scriptleri tüm Oracle sürümleri ile uyumludur.

Belli başlı Oracle bekleme olayları aşağıda yer almaktadır.

db file sequential reads
db file scattered reads
log file parallel write
log file sync
buffer busy waits
free buffer waits
enqueue waits
cache buffer chain latch

Şimdi bu yukardaki bekleme olaylarını tek tek açarak, ne anlama geldiklerine, bunlara nelerin sebep olduğuna ve iyileştirme tavsiyelerine bakalım.

Bekleme Olayı:db file sequential reads
Üst sınır: V$SYSTEM_EVENT içinde ortalama bekleme süresi 15ms yi geçmemeli

Muhtemel sebepler:

Yanlış index kullanımı
Fragmente olmuş indexler
Belirli disk veya raw partitionlar üzerinde aşırı I/O trafiği
Kullanılan programda tasarım eksikliği
Index okuma performansı yüksek oranda ortalama bekleme süresine sebep olan yavaş I/O altsistemi ve/veya veritabanı dosyalarının fiziksel yerleşimindeki eksikliklerden etkilenmektedir.

Alınacak eylemler:

Tablodaki indexleri kontrol ederek doğru indeksin kullanıldığından emin olun. Bu noktada önbellekteki işlemlerden hangi indekslerin kullanılmadığını analiz edebilir ve gereksiz indeksleri bu şekilde düzeltebiliriz(Önbelleği gereksiz işgal eden indeksleri görmek için alttaki sorgu kullanılabilir)

select distinct b.owner, b.segment_name
   from x$bh a, dba_extents b
   where b.file_id=a.dbarfil
     and a.dbablk between b.block_id
     and b.block_id+blocks-1
     and segment_type='INDEX'
     and b.owner = upper('&OWNER')

Top SQL listesinden tabloda kullanılan indekslerin WHERE kısmındaki kolonların order sırasını kontrol ediniz.
Indeksleri yüksek kümeleme faktöründe tekrar oluşturun.
Ziyaret edilen blok miktarını azaltmak için bölümlendirme(partitioning) kullanın.
İyileştirme istatistiklerinin güncel olduğundan emin olun.
Yüksek I/O trafiğine sahip olan veri dosyalarını farklı veri dosyalarına taşıyın(Dengesiz I/O yükünü veridosyası bazında görmek için alttaki sorgu kullanılabilir)

select d.name,s.PHYRDS,s.PHYWRTS
from v$datafile d, v$filestat s
where d.file#=s.file#
order by 1

Çoklu bellek havuzlarını kullanmayı düşünün ve sık kullanılan indeks ve tabloları KEEP havuzunda tutun(SQL alanında sık işlem gören ancak KEEP havuzunda tutulmayan tabloları görmek için alttaki sorgu kullanılabilir)

SELECT o.owner, object_name, object_type, COUNT(1) buffers
FROM SYS.x$bh, dba_objects o
WHERE tch > 10
    AND lru_flag = 8
    AND obj = o.object_id
    AND o.owner = upper('&OWNER')
GROUP BY o.owner, object_name, object_type
ORDER BY buffers;

İndeksler üzerinden veri erişimi sağlayan SQL cümleciklerinin işlem planlarını araştırın.
İndeksler üzerinden veri erişimini mümkün olduğunca fazla sağlayın.
Kullandğınız program OLTP mi veya DSS mi? Full tablo taramasımı daha verimlidir? SQL cümleciklerinde doğru “driving” tablolar kullanılıyormu? sorularının cevaplarını analiz edin.
İyileştirmenin hedefi hem mantıksal hemde fiziksel I/O trafiğini azaltmaktır. Bu noktada öncelikle yeterli önbelleğin olduğundan ve hızlı fiziksel sistemlerde ve doğru RAID yapısında çalıştığınızdan emin olun.

Tavsiyeler:

Oracle prosesi, SGA alanı içinde o an bulunmayan bloğu ister ve diskten SGA alanına bu bloğun okunması için bekler.
Sabit orandaki db file sequential read bekleme zamanını azaltmak için yapılan tüm iyileştirme işlemleri sonucunda bu oran hala yüksekse programınızda iyileştirmeye odaklanmanız gerekir.
Eğer indeksin DBA_INDEXES.CLUSTERING_FACTOR değeri tablodaki blokların sayısına yaklaşırsa bu durumda tablodaki pekçok satır sıralanmıştır. Bu arzulanan bir sonuç olacaktır.
Ancak, eğer kümeleme faktörü tabloadaki satır sayısına yaklaşırsa bu demektirki tablodaki pek çok satır rastgele sıralanmıştır ve bu sebeple bu operasyonu tamamlamak için çok daha fazla I/O meydana gelecektir. İndeksin kümeleme faktörünü iyileştirmek için tablo tekrar oluşturulabilir, böylece satırlar indeks anahtarına gore sıralanacak ve sonrasında indeksler tekrar oluşturulacaktır.OPTIMIZER_INDEX_COST_ADJ ve OPTIMIZER_INDEX_CACHING başlangıç parametreleri “nested loop” işlemlerini desteklemek için iyileştiriciyi etkiler ve full tablo taraması üzerinden indeks erişim yolunu seçer.
I/O tabanlı iyileştirmeler için Metalink Note# 223117.1 a bakınız.
Daha fazla db file sequential read iyileştirme metotları için Metalink Note# 34559.1 a bakınız.

Bekleme Olayı:db file scattered reads

Muhtemel sebepler:

Oracle oturumu çoklu komşu veritabanı bloklarını(DB_FILE_MULTIBLOCK_READ_COUNT değerine kadar) disk alanından SGA’ya okunmak için beklemektedir.
Çok fazla full tablo taramaları (FTS)
Çok fazla hızlı full indeks taramaları
Bellek havuzunda en fazla FTS ve/veya full indeks taramasına sebep olan 20 top obje alttaki sorgu ile bulunabilir.

SELECT * FROM
(SELECT SUBSTR(O.OWNER, 1, 15) OWNER,
         SUBSTR(O.OBJECT_NAME, 1, 35) OBJECT,
         COUNT(*) BLOCKS,
         DECODE(O.OBJECT_TYPE, 'TABLE', 'FULL TABLE SCAN',
                               'INDEX', 'FAST FULL SCAN',
                               'OTHER') "SCAN TYPE"
FROM DBA_OBJECTS O, X$BH B
WHERE B.OBJ = O.DATA_OBJECT_ID AND
STANDARD.BITAND(B.FLAG, 524288) > 0 AND
O.OWNER != 'SYS'
GROUP BY O.OWNER, O.OBJECT_NAME, O.OBJECT_TYPE
ORDER BY COUNT(*) DESC)
WHERE ROWNUM <=20;

Hangi 20 SQL cümlesinin aşırı FTS ve/veya aşırı full indeks taramasına sabep verdiği ise alttaki sorgu ile bulunabilir.

SELECT * FROM
(SELECT SUBSTR(SA.SQL_TEXT, 1, 68) SQL_TEXT,
         SA.DISK_READS DISK_READS
FROM V$SQLAREA SA WHERE
(SA.ADDRESS, SA.HASH_VALUE) IN
(SELECT ADDRESS, HASH_VALUE FROM V$SQL_PLAN
WHERE OPERATION = 'TABLE ACCESS' AND
       OPTIONS = 'FULL' OR
       OPERATION = 'INDEX' AND
       OPTIONS LIKE 'FAST FULL%')
ORDER BY 2 DESC)
WHERE ROWNUM <=20;

Alınacak Eylemler:

DB_FILE_MULTIBLOCK_READ_COUNT parametresini ayarlayarak çoklu blok I/O işlemlerini optimize edin.
Bölümlendirmeleri alt bölümlere budamak ziyaret edilen bloklarının sayısını azaltır.
Çoklu tampon havuzları kullanmayı düşünün ve sık kullanılan indeks ve tabloları KEEP pool içinde saklayın.
En çok bekleme olaylarını başlatan SQL cümlelerini iyileştirin. Burdaki amaç fiziksel ve mantıksal okuma sayısını azaltmaktır.
SQL sonucu erişilen data indeks FFSmi yoksa full tablo taraması sonucumu gelmeli?
İndeks aralığı veya unique taramamı en etkili olacaktır ?
Sorgu doğru “driving” tabloyu kullanıyormu?
SQL cümleleri ilgili hash veya ilgili merge birleşmelerine dayanıyormu?
Eğer full taramalar(FS) uygunsa parallel sorgu cevap süresini iyileştiriyormu?
Amaç, hem fiziksel hemde mantıksal I/O lar için istekleri azaltmaktır.Buna erişmek için en iyi yol SQL ve program iyileştirmesi olacaktır.
LAST_ANALYSED tarihini control ederek tüm istatistiklerin güncel veriyi temsil ettiğinden emin olun.

Bekleme Olayı:log file parallel write

Muhtemel sebepler:

LGWR redo log önbellek içeriğini online log dosyalarına yazarken bekler.
I/O, online redo log dosyalarını tutarken altsistemde bekler.

Alınacak Eylemler:

Oluşturulan redo miktarını azaltın.
Çok gerekmedikçe tablespaceleri sıcak yedekleme(hot backup) modunda bırakmayın.
Redo log dosyaları için RAID 5 kullanmayın, RAID 1 tercih edilebilir.
Redo log dosyaları için daha hızlı diskler kullanın.
İçeriklerin çakışmaması için arşiv redo log dosyaları ve online redo log dosyalarının birbirlerinden farklı disklerde tutulduğundan emin olun.
SQL cümleciklerinde gerektiğinde NOLOGGING veya UNRECOVERABLE seçeneklerini kullanmayı dikkate alın.

Bekleme Olayı:log file sync

Üst sınır:V$SYSTEM_EVENT içinde ortalama bekleme süresi 15ms yi geçmemeli

Muhtemel sebepler:

Oracle arkaplan prosesleri COMMIT veya ROLLBACK lerden birini sonuçlandırmak için beklemektedir.

Alınacak Eylemler:

LGWR prosesini disklere doğru iyi çıktı almak amacıyla iyileştirin.Örneğin, redo logları RAID 5 te tutmayın, RAID-1 tercih edin.
İşlemleri yığınlayarak tüm COMMIT sayısını azaltın ki daha az sayıda COMMIT işlemleri olsun..

Tavsiyeler:

Bakınız Metalink Reference Note# 34592.1
Log dosyası senkronizasyonunda yüksek beklemeleri optimize etmek için bakınız Metalink referans Note# 125269.1
Redo log önbellek iyileştirmesi ve redo latch içeriği iyileştirmesi için bakınız Metalink Referans Note# 147471.1

Bekleme Olayı:buffer busy waits

Üst sınır:V$SYSTEM_EVENT içinde ortalama bekleme süresi 45ms yi geçmemeli

Muhtemel sebepler:

Yoğun bellek beklemeleri I/O sekmeli Oracle sistemlerinde olağandır.
Bu olayın meydana geldiği 2 temel neden vardır: Başka bir oturum bloğu bellek içinden okumaktadır veya başka bir oturum isteğimize karşılık belleği uyumsuz bir modda tutmaktadır.
Bu beklemeler okuma/okuma,okuma/yazma veya yazma/yazma içeriklerine işaret eder.
Oracle oturumu belleğe iliştirmek için beklemektedir. Bellek okunmadan veya değiştirilmeden once iliştirilmelidir.Sadece bir proses belleği herhangi bir zamanda iliştirebilir.
Bu beklemeler daha çok satır içerecek kadar daha geniş blok büyüklüklerince pekiştirilir.
Bu beklemeler bir oturum önbellek içindeki bir veritabanı bloğuna erişmek istediğinde ancak bellek meşgul olup erişemediğinde meydana gelir. Sık sık ilişkili bloklarda bu beklemeler oluşuyorsa hangi ilişkili segmentlerin buna sebep olduğunu bulmak için alttaki sorguyu çalıştırın. HDR kolonu bunun header blok olup olmadığını gösterecektir.

SELECT SUBSTR(SEGMENT_NAME, 1, 30), SEGMENT_TYPE,
DECODE(<block#> - BLOCK_ID + EXTENT_ID, 0, 'YES', 'NO') HDR
FROM DBA_EXTENTS
WHERE FILE_ID = <file#> AND
<block#> BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1;

Hangi data dosyalarının buffer busy waits olayına sebep olduğunu görmek için ise alltaki sorgu faydalıdır.

SELECT * FROM
   (SELECT COUNT, FILE#, SUBSTR(NAME, 1, 50) FILE_NAME
   FROM X$KCBFWAIT, V$DATAFILE
   WHERE INDX + 1 = FILE#
   ORDER BY COUNT DESC)
WHERE ROWNUM <=20;

Birkaç proses aynı bloğu tekrar tekrar okuduğundan ötürü bu beklemeler sık sık olur. Mesela, farklı kullanıcılar aynı anda aynı bloğa erişim sağlıyorsa.

Alınacak Eylemler:

Yoğun bellek bekleme sayısını azaltmanın ana yolu sistem üzerindeki toplam I/O yu azaltmaktır.Blok tipine bağlı olarak uygulanacak eylemler aşağıdaki gibi farklıdır.

Data blokları için;

Çok fazla erişilen blokları programınızdan çıkartın.
Tekrarlı tarama/seçimsiz indeksleri kontrol edin.
Objeleri daha yüksek PCTFREE oranlarında yeniden oluşturun, böylece blok başına satır sayısını azaltmış olursunuz.
Farklı prosesler tarafından indekslerdeki aynı lokasyona eklenen indeksleri kontrol edin.
INITRANS ve MAXTRANS değerlerini artırın, PCTUSED değerini azaltın.Bu şekilde tablolar daha az sıkışır.
Blok başına satır sayısını azaltın.
db_block_buffers başlangıç parametresi değeri artırılabilir.

Segment Başlığı

FREELISTS ve FREELIST GROUP sayısını artırın.

Undo Başlığı

Rollback segment sayısını artırın.

Tavsiyeler:

buffer busy waits olayında beklemede olan prosesin sebep kodu bekleme olayının P3 parametresinde yayınlanır.
En sık karşılaşılan bekleme olaylarından olan 130 ve 220 arası referanslar için Metalink Note # 34405.1 bakınız.
Yoğun ve rastgele bellek bekleme performans problemleri için Metalink Note# 155971.1 bakınız.

Bekleme Olayı:free buffer waits

Muhtemel sebepler:

Boş tampon beklenmekte ancak bellekte çok fazla kirli tamponlar yüzünden bellekte yeterli boş alan yok.
Ya önbellek çok küçük veya DBWR değiştirilmiş tamponları diske yazmak için çok yavaş kalmakta.
DBWR yazma taleplerini sürdürememekte.
Muhtemelen yetersiz büyüklükte redo log dosyaları veya yüksek veritabanı işlemleri sebebiyle çok fazla checkpoint meydana gelmekte.
Geniş sort ve full tablo taramaları, tamponu DBWR prosesinin diske yazabileceğinden çok daha hızlı şekilde değişime uğramış bloklarla doldurmakta.
Eğer kirli tamponların sayısı DBWR prosesinin yığın başına yazabileceği miktardan daha fazla diske yazma ihtiyacı duyarsa, bu bekleme olayı oluşabilir.

Alınacak Eylemler:

Checkpoint sıklığını azaltın. Online redo log dosyası büyüklüğünü artırın.
Tampon bellek büyüklüğünü sorgulayın. SGA alanında tampon belleği artırmayı değerlendirin.
disk_asynch_io = true
DBWR prosesi sayısını CPU sayısına bağlı olarak arttırın.
DBWR prosesi çok fazla bu bekleme olayına sebep oluyorsa, FAST_START_MTTR_TARGET değerini azaltıp deneme yapın. Ancak şunu unutmayın bu parametre azaltılırsa DBWR üstünde çok aşırı yazma yoğunluğu oluşur.
Veri dosyalarını diskler veya disk kontroller üzerine serpiştirerek sıcak noktaların olmadığından emin olun.
Önceden sort işlemleri ve verileri yeniden organize etmek yardımcı olabilir.

Tavsiyeler:

Önbellek ve DBWR yi anlamak ve iyileştirmek için bakınız Metalink Note# 62172.1
Önbellek içinde sıcak blokların nasıl belirleneceği için bakınız Metalink Note# 163424.1

Bekleme Olayı:enqueue waits

Muhtemel sebepler:

Talep edilen moda karşılık, uyumsuz bir mod içinde başka oturumlar tarafından tutulan kilitler sebebiyle kuyruk sonuna atılan bekleme olayıdır. Bekleyen kuyruğa alma kilitleri tespit etmek için alttaki sorgu kullanılabilir.

select /*+ ordered */
l.type || '-' || l.id1 || '-' || l.id2 "RESOURCE",
nvl(b.name, lpad(to_char(l.sid), 4)) sid,
decode(
    l.lmode,
    1, '      N',
    2, '     SS',
    3, '     SX',
    4, '      S',
    5, '    SSX',
    6, '      X'
) holding,
decode(
    l.request,
    1, '      N',
    2, '     SS',
    3, '     SX',
    4, '      S',
    5, '    SSX',
    6, '      X'
) wanting,
l.ctime seconds
from sys.v_$lock l, sys.v_$session s, sys.v_$bgprocess b
where s.sid = l.sid and
b.paddr (+) = s.paddr
order by   l.type || '-' || l.id1 || '-' || l.id2,   sign(l.request), l.ctime desc

TX İşlem Kilidi

Genellikle tablo oluşum kaynaklı hatalar veya program geliştirmedan kaynaklanan hatalar
Satır bazlı kilitler kısmındaki çakışmaları belirtir.
Bir işlem başka bir işlem tarafından kilitlenmiş satırları güncellemeye veya silmeye çalıştığından bu bekleme oluşur.
Bu bekleme olayı genellikle program katmanındaki sorunlardan kaynaklanır.

TM DML Kuyruksonu Kilidi

Genelikle yabancı anahtarların tek tek indekslenmediği durumlarda program katmanındaki sorunlardan kaynaklanır. Bu tarz kilitleri nelerin tetiklediğini belirlemek için alttaki sorgu kullanılabilir.

select /*+ ordered */
n.name constraint_name,
u.name ||'.'|| o.name table_name,
c.name column_name
from
(
    select /*+ ordered */ distinct
      cd.con#, cd.obj#
    from sys.cdef$ cd, sys.tab$ t
    where
      cd.type# = 4 and   -- foriegn key
      t.obj# = cd.robj# and
      bitand(t.flags, 6) = 0 and
      not exists (   -- not indexed
select null
from
   sys.ccol$ cc, sys.ind$ i, sys.icol$ ic
where
          cc.con# = cd.con# and
          i.bo# = cc.obj# and
          bitand(i.flags, 1049) = 0 and
          ic.obj# = i.obj# and
   ic.intcol# = cc.intcol#
        group by
          i.obj#
        having
          sum(ic.pos#) = (cd.cols * cd.cols + cd.cols)/2
      )
) fk,
sys.obj$ o, sys.user$ u, sys.ccol$ cc, sys.col$ c, sys.con$ n
where
o.obj# = fk.obj# and
o.owner# != 0 and   -- ignore SYS
u.user# = o.owner# and
cc.con# = fk.con# and
c.obj# = cc.obj# and
c.intcol# = cc.intcol# and
n.con# = fk.con#
order by

ST Kilidi

Drop, truncate veya coalesce gibi eylemler içeren ST kilidine gereksinim duyan UET$(kullanılmış extent) ve FET$(boş extent) tablolarını değiştiren veritabanı işlemleri.
ST kilitlerindeki çakışmalar dictionary yönetimli tablespace yapısında birden fazla oturumun aktif olarak dinamik disk alanını paylaştığı yada serbest bıraktığını işaret eder.

Alınacak Eylemler:

Bekleme ve bekleme sürelerini azaltın. TX kuyruk tabanlı kuyruğa alma beklemeleri gördüğünüzde ilk adım olarak bloklayanın kim olduğunu bulun ve aynı kaynak için birden fazla bekleyen olup olmadığını araştırın.
Mod 3 içindeki TM kuyruk beklemeleri öncelikli olarak indekslenmemiş yabancı anahtar kolonları olmasından kaynaklıdır.
Oracle 9i için yabancı anahtarlarda indeks oluşturun.
Lokal yönetimli tablespace kullanın.
Tüm geçici tablespacesleri yeniden oluşturun. CREATE TEMPORARY
TABLESPACE TEMPFILE…

Tavsiyeler:

Eşzamanlı kilitleyebilmede önkuyruk sayısını maksimum sayıda kontrol etmek için ENQUEUE_RESOURCES parametresi kullanılır. Bakınız Metalink Reference Note# 34566.1
Kuyruk sonunda bekleyen oturumları izlemek için bakınız Metalink Note# 102925.1
V$LOCK görünümü ve kilitleme modları için bakınız Metalink Note:29787.1

Bekleme Olayı:cache buffer chain latch

Muhtemel sebepler:

Bu mandal(latch) data blokları için arama yapılırken elde edilir. Önbellek blok sırasıdır ve taramaya ihtiyaç duyulduğunda her bir sıra alt mandal tarafından korunur.
Bu bekleme olayının bir diğer ortak sebebi ise sıcak bloklardır. Birden fazla oturum bu bekleme olayının alt sırasındaki bir veya daha fazla bloğa tekrar tekrar erişiyorsa bu bekleme olayı meydana gelir.
EXECUTION başına yüksek BUFFER_GETS(mantıksal okuma-bellekten) değerine sahip SQL cümleleri baş suçludur. Önbellkte çok fazla yer meşgul eden SQL cümlelerini görmek için alttaki sorgu kullanılabilir.Örnekte 5MB'den fazla BUFFER_GETS sebep olan cümleler listelenir.

SELECT substr (sql_text, 1,100) "Stmt", count (*) "Count",
round(sum (sharable_mem)/1024/1024,2) ||' MB' "Mem",
sum (users_opening) "Open",
sum(parse_calls) "Hard Parses",
sum (executions) "Exec"
FROM v$sql
GROUP BY substr (sql_text, 1,100)
HAVING round(sum (sharable_mem)/1024/1024,2)>5;

Birden fazla eşzamanlı SQL oturumu aynı veri setini hedef gösteren yetersiz SQL leri yürütmektedir.

Alınacak Eylemler:

Bu bekleme olayı için çakışmaları azaltmak genellikle iyileştirme ile mantıkssal I/O oranını azaltmaya ve SQL ilişkili I/O gereksinimini azaltmaya ihtiyaç duymaktadır. Yüksek I/O oranı çok fazla erişilen blokları işaret eder.
Tabloyu export edin, PCTFREE oranını anlamlı olarak arttırın ve verileri import edin.Bu metot blok başına satır sayısını azaltacak ve bu satırları pek çok blok üzerine dağıtıcaktır. Tabi bu da depolama alanı ihtiyacını artıracak ve full tablo taramaları yavaşlayacaktır.
Tabloda blok başına kayıt sayısını minimize edin.
Indeksler için bunları daha yüksek PCTFREE değerlerinde yeniden oluşturun, tabi bunun indeksin yüksekliğini artıracağını akılda tutarak.
Blok boyutunu azaltmayı gözönünde bulundurun.
İndex ve buna bağlı tabloların aynı blok boyutunda olduğundan emin olun.
Hash latch sayısı, DB_BLOCKS_HASH_LATCHES parametresi ile değiştirilebilir.

Makalemizin sonuna geldik, umarım faydalı bir makale olmuştur. Bir sonraki makalemizde görüşmek üzere

Oracle da database’ ini startup ile açmaya kalktığımız da instance ilk iş olarak parametre dosyasını okumaya çalışacaktır. Dolayısıyla temel initial parametrelerinden bahsederken bizim için çok kritik file’ lerimizden biri olan spfileSID.ora dosyasından da kısaca bahsedeceğiz.

Parametre dosyaları Linux’ da; $ORACLE_HOME/dbs, Windos’da $ORACLE_HOME/database altında bulunur. Database create edilmesiyle birlikte spfileSID.ora dosyamızda oluşur. Bunun yanısıra parametre değişikliğini database içirisinden Alter system veya Alter database ile yapmak istemediğimiz veya yapamadığımız durumlarda ise kullandığımız birde pfileSID.ora dosyamız olacaktır. Bu dosya db create operasyonu sonrasında oluşmaz, bunu create etmek için sql satırında;

Create pfile from spfile;

Komutunu çalıştırmamız yeterli olacaktır. Hazır yeri gelmişken bu iki dosya arasındaki farklardan bahsedelim;

Pfile, bir metin dosyasıdır ve edit edilebilir. Spfile direk olarak düzenlenemez.

Pfile’ de yapılan değişikliklerin etkin hale gelmesi için database’ i restart etmek gerekir. Spfile üzerinde yapılan değişikliklerin birçoğu hemen etkin hale gelir.

Pfile’ den spfile, spfile’ den pfile oluşturulabilir. Pfile create etmek için; create pfile from spfile, spfile create etmek içinse create spfile from pfile komutunu kullanabiliriz.

Bir farkda dosya isimlerinde var, pfile’ in ismi init(instane_name).ora, spfile’ in ismi ise spfile(instance_name).ora ‘ dır.

Çok kullanılan bazı başlangıç parametrelerinin ne olduğunu açıklamaya çalışalım. Aşağıdaki parametrelerin bazıları 11g ile yeni gelmiş olan parametrelerdir. Dolayısıyla 10g versiyonlarında göremiyor olabilirsiniz.

(Aşağıdaki notlarım uzun bir zaman aralığında oluşmuştur, bir çoğu oracle dökümantasyonlarından, kişisel tecrübelerden bir kısmı ise kimi net sayfalarından derlenmiştir.)

Cluster_database : Real Application Clusterı etkin belirten Real Application Clusters parametresidir. Default değeri false’ dir. True yada False olarak 2 değer alabilir. Modify edilemez.

Compatible : Size Oracle’ ın yeni sürümünü kullanmaya izin verir, aynı zamanda geriye doğru bir önceki sürümü ile uyumluluk sağlar. Eğer daha önceki sürümden geri dönmek gerekirse bu parametre gerekli ve yeterli olacaktır.

Control_files : Database’ in yapısını veritabanı adını, create edilme zamanını, redologların ve datafile’ lerin adını ve lokasyonunu tutan kontrol dosyaları vardır. Control file denetim dosyaları bir veya daha fazla olabilirler, virgülle birbirinden ayrılarak belirtilirler. Minumum 1 ile 8 tane arasında olabilirler. Control file’ lerin lokasyonunu belirtir.

Db_create_file_destination: Data file’ lerin varsayılan konumunu belirtir. Bu lokasyon DB_CREATE_ONLINE_LOG_DEST_n parametresi set edilmemişse control files ve redo log larında lokasyonunu belirtir. Dizinin, Oracle kulanıcısının dosyalarını oluşturması için gerekli izinlere sahip olması gerekir. Oracle create edilirken file isimleri belirtilmez ise, uniqe nameler ile dosyaları create eder.

Alter system set db_create_file_dest = ‘/u01/oradata’;

Create tablespace tbs_1;

Db_create_online_log_dest_n: DB_CREATE_ONLINE_LOG_DEST_n (burada = 1, 2, 3, ...

5)varsayılan default konumu, control files ve redo logların konumunu belirler.

Db_domain : Dağıtılmış bir veritabanı sisteminde, DB_DOMAIN ağ yapısı içinde

veritabanının mantıksal konumu belirtir.

Nls_language : NLS_LANGUAGE veritabanının varsayılan dilini belirtir. Bu dil mesajları,

gün ve ay adları, AD, BC, am, pm ve semboller için kullanılır. Bu parametre de

parametreleri NLS_DATE_LANGUAGE ve NLS_SORT varsayılan değerler belirler.

Open_cursors : (özel SQL alanlara) Bir defada sahip olabilecek açık imleçler sayısını

belirtir. Size, cursors sayısının fazla oturum açmasını engellemek için bu parametreyi

kullanabilmenize olanak sağlar. OPEN_CURSORS değeri yüksek olması, uygulamaların out

of open cursor hatası almasını engeller.

Job_queue_processes : JOB_QUEUE_PROCESSES bu işlerin yürütülmesi için

oluşturulabilir süreçlerinin sayısını belirtir. Bu iş sıra sayısını belirtir örneği (her J000, J999 ...)

işler. Çoğaltma veri yeniler için iş kuyruklarını kullanır. Gelişmiş kuyruk mesaj yayılması için

iş kuyruklarını kullanır. DBMS_JOB paketi üzerinden kullanıcı jobları,oluşturulabilir. Bazı

iş kuyruğu kişi, otomatik olarak oluşturulur. materialized views için örnek yenileme

desteklemektedir. Eğer materialized views otomatik olarak güncellemek istersen, bir veya

daha yüksek bir değere JOB_QUEUE_PROCESSES ayarlamanız gerekir.

Processes : İşletim sistemi kullanıcı sayısını belirtir aynı anda oracle’a

bağlanabilecek sayıyı ifade eder.

Remote_listener : REMOTE_LISTENER ağ adı bir adres veya Oracle Net uzak dinleyici

adresini listesine çözümler belirtir. Adresi veya adres listesi sistem için yapılandırılmış olarak

TNSNAMES.ORA dosyasında belirtilir.

Rollback_segments: ROLLBACK_SEGMENTS adıyla bir veya daha fazla rollback

segmentini allocate eder. Eğer bu parametre set edilirse, instance rollback_segments adıyla

tüm segmentleri kazanır. Dinamik olarak bu parametrenin değerini değiştirmek mümkün

değil, ancak değerini değiştirebilir ve sonra instance’ ı yeniden başlatabilirsiniz.

Undo_management : Alan yönetimi konusunda hangi sistemi kullanmalıyımı belirtir.

Parametre Auto olarak set edildiğinde, instance start olduğunda undo management modu

atomatic olarak devreye girer. Mauel olarak set edildiğinde ise, rollback segment alanları

harici olarak tahsis edilir.

Undo_tablespace: Undo Tablespace’ i, instance start oldukdan sonra, kullanılmak üzere

ayırır. Bu parametre, instance’ da manuel undo management modda ise, sonrasında hata

oluşur ve startup işlemi başarısızlıkla sona erer. Kullanılabilir bir Undo Tablespace’ I yoksa,

instance undo tablespace alanı olmadan start olur. Bu gibi durumlarda, user

transactionları sistem rollback segmentini kullanarak çalışırlar. Normal şartlar altında bu

modda çalışmakdan kaçınmalısınız. Database çalışırken undo tablespace’ ini başka bir

undo tablespace ile replace edebilirsiniz.

Undo_guarantee : Undo tablespace içerisinde belli bir süre mutlaka dataların tutulmasını

sağlar.

Alter tablespace undo_guarantee retention guarantee;

Alter system set undo_tablespace = undo_noguarantee ;

Alter system set undo_tablespace = undo_ guarantee ;

ALTERSYSTEMSET UNDO_RETENTION = 3600

Db_block_size : Database create edilirken set edilir. Sonradan değiştirilemez. Database’

deki blockların size’ ını ifade eder.

Db_create_online_redo_dest_n: Redologların create ederken default olarak nereye

oluşturulacağının bilgisi yer alır.

Control_file_record_keep_time : Control filede dosyaların saklanma süresini belirtir.Bu

parametre 7 ile 365 arasında bir değer alabilir. (default değeri 7’ dir)

remote_os_authent : Bu parametre FALSE ise uzaktan password file dosyası olmadan

sysdba ile bağlanamazsın demek.

Remote_login_password_file : Uzakdan bağlanmak için gereken parametre Default değeri EXCLUSIVE dir. Parametre dosyası kaybolduğunda bu değer NONE’ a çekilip dosya create edilip tekrar EXCLUSIVE’ e alınması gerekmektedir.

Alter system set remote_login_password_file=EXCLUSIVE scope=spfile;

Background_dump_dest : Alert logun pathini verir.

alter system set background_dump_dest = 'D:\orcl rman backup\' scope=both

(alert logun adı = alert_(db_sid).log şeklinde oluşur.)

07_dictionary_accessibility : Select any table yetkisi olan userın data dictionaryi

görmemesi için bu parametre = FALSE olmaldır.

Log_archive_dest_1 (dest) : Archive logların nerede tutulacağının bilgisinin set edildiği

parametre.

log_archive_start : Otomatik arşivlemenin doğrudan yapılıp yapılmayacağını gösterir. Buna

true demezseniz zaman zaman svrmgrl’ye bağlanarak log archive start diyerek, arşiv

dosyalarını yazma işlemini elle kontrol etmeniz gerekir ki bu genelde önerilmez. Ama tape

gibi farklı bir yere zaman zaman arşivlemek için bu yöntemi kullanabilirsiniz. B u parametre

oracle 10g ile birlikte deprecated olmuştur.

log_archive_format :Üretilecek arşiv dosyalarının yazılma biçimini gösteriyor.%s ile logların

sıra numarasını .arc ile de uzantısı belirlenebilir. (%s.arc)

· %s: log sequence number

· %S: log sequence number, zero filled

· %t: thread number

· %T: thread number, zero filled

· %d: DBID

Log_archive_max_processes : Archive process sayısı bu parametre ile set edilir.

ALTER SYSTEM SET log_archive_max_processes = 4 SCOPE=SPFILE

Db_flashback_retention_target : Veritabanını kaç dakika geriye alabileceğinizin set edildiği

parametre.

alter system set db_flashback_retention_target=60 scope=memory;

Db_recovery_file_dest_size : Yedek işlemleri için ayrılan alanının size’ nın set edildiği

parametre.

ALTER SYSTEM SET Db_recovery_file_dest_size = 35G SCOPE=SPFILE

Db_recovery_file_dest : Flashback bilgisinin nerede tutulacağı bilgisinin set edildiği

parametre. Aynı zamanda default backup dizinidir.

alter system set db_recovery_fıle_dest ='d:/orcl_backup' scope=both;

select * from v$recovery_fıle_dest;

Db_block_checking : Db data blocklarında corruption oluşmasını önler.(değer true yapılırsa

%10’ lar civarında memory kaybı oluşur)

Db_block_checksum : Db corruption oluşmasını engeller, veriyi datafile’ e yazarken çift

kontrol yapar. (değer true yapılırsa I/O da %1-2 civarında artış olur.)

Db_keep_cache_size : Buffer cache’ in keep alanının size’ ı set edilir.

alter system set db_keep_cache_size = 50M scope=MEMORY;

Db_recycle_cache_size : Buffer cache’ in recyclebin alanının size’ ı set edilir.

alter system set db_recycle_cache_size= 10M scope=MEMORY;

Db_cache_size : Buffer cache’ in default alanının size’ ı set edilir.

Shared_pool_size : Shared pool’ un size’ ı set edilir.

Large_pool_size : Large pool’ un size’ ı set edilir.

Java_pool_size : Java pool’ un size’ ı set edilir.

Streams_pool_size : Streams pool’ un size’ ı set edilir.

Sga_max_size : Sga atanmış olan kullanılabilecek alanı ifade eder.

Sga_target : Sga’ nın kullanılabileceği alanı ifade edebilir. Bu değer sga_max_size değerinden büyük olamaz.

ALTER SYSTEM SET sga_max_size = 16000M SCOPE=SPFILE;

ALTER SYSTEM SET sga_target = 15000M SCOPE=SPFILE ;

Pga_aggregate_target : Pga alanına atanan memory alanını ifade eder.

Statistics_level : Sistem tarafından toplanan istatistiklerin nasıl toplanacağının set edildiği

parametredir. 3 değer alabilir. BASIC; Datanın istatistiğini almaz. Dolayısıyla bu değer set

edilmişken ADDM çalışmaz. TYPICAL; default değerdir.segment seviyesinde istatistikleri alır.

ALL; operating systeminde istatistiğini alır. Sisteme yük getirir.

ALTER SYSTEM SET statistics_level=all

Open_cursors : Bir sessionın aynı anda kaç tane select çalıştırabileceğini belirtir. (default değeri 300)

Alter system set open_cursors=350;

User_dump_dest : user trace dosyalarının pathi burda yer alır.

fast_start_mttr_target : Database’ e checkpoint attırma zamanı (değer saniye cinsinden)

ALTER SYSTEM SET fast_start_mttr_target = 900

db_writer_processes : Databasede kidb writer procecessinin kaç adet olduğunu bilgisini bu parametreden alır.

*.db_writer_processes=1

audit_sys_operations : Database’ in izlenmesi sürecinde Sys userının da denetlenip

denetlenmeyeceğini gösteren parametredir. Defaultu FALSE’ dir.

audit_file_dest : sysnin auditlenmesi durumunda sys audit kayıtlarının yerini belirtir.

Windows da windows application log’ larda, linuxda audit_file_dest parametresine bakar.

log_archieve_start : otomatik archive alma parametresidir. İnit.ora dosyasında değeri

log_archieve_start=true şeklinde set edilmelidir. Noarchivelog modunda çalışan bir db

için bu parametre init.ora dosyasında olmaması gerekmektedir.

open_links : OPEN_LINKS uzak veritabanlarına tek oturumda aynı anda açık bağlantı

sayısını belirtir. (deafult’ u 4. static bir parametre olduğundan değiştirildiğinde db restart

etmek gerekir.)

Statistic_level : AWR’ ın çalışmasını sağlayan parametredir. 3 değer alabilir. Defaultu Typical’ dır. All ve Basic’ de olaiblir. Basic olduğunda AWR devredışı kalır.

alter system set statistics_level = all;

Control_management_pack_acces : Addm’ in çalışması için gereken parametredir. Diadnostic+ tuning default değeridir.Diagnostic veya None olarak da set edilebilir. None olması durumunda ADDM devredışı kalır.

remote_dependencies_mode ; İki değer alabilir. timestamp, Clientın istediği procedure ancak serverdaki kayıt tarihi ile, localdeki şimdiki tarih ile uyuşursa çalıştırılır. signature, oracle, bir procedure'nin imzalarının güvenli olarak göz önüne alınmış olması durumunda çalıştırılmasına müsade eder. Bu ayar, PLSQL uygulamalarının tekrar compile edilmeden çalıştırılmasını sağlar.

Alter session SET REMOTE_DEPENDENCIES_MODE = ( SIGNATURE / TIMESTAMP )

Alter system SET REMOTE_DEPENDENCIES_MODE=( SIGNATURE / TIMESTAMP )

Ddl_lock_timeout : Ddl işlemlerinde oluşaacak lock’ lardaki bekleme süresini ifade eder. Defaultu “0”. Bu parametre 0 ile 100.000 arasında değer alabilir. system ve session bazında değiştirilebilir.

Alter system set ddl_lock_timeout = 10 scope = SPFILE

max_dump_file_size : Oluşan trace dosyalarının maximum ne kadar boyutta olacağını belirtir. (bu maximum size sınırlaması alert logu kapsamaz.)

alter system set max_dump_file_size = ‘5m’;

aq_tm_processes : Parametre enable edildiğinde queue mesajlarının monitör edilmesini

sağlar. 0 – 10 arasında değer alır. 0 olduğunda disable olur. Eğer oracle stream

kullanılıyorsa bu parametrenin 0 olarak set edilmesi başka problemlere yol açılacaktır. Oracle

bu değerin 0’ dan bir değer olarak set edilmesini öneriyor.

alter system set aq_tm_processes=0

cursor_sharing : Shared pool içerisinde tutulan sqllerin benzerleri geldiğinde aynı plan ile

diğerlerininde çalışıp çalışmayacağının set edildiği parametredir. SIMILAR = Çalışan sql'

lerin birebir aynı olmasa da benzeyenler için (execution planlarına da bakar) cache den

çalıştırmaya yönlendirir. EXACT = Çalışan sqlerin cache' den çalışması için sorguların

birebir aynısı olması gerekmektedir. FORCE = Cache de Çalışan sql lerin benzeri varsa

mevcut execeution plan kullanılmasını zorlar

ALTERSYSTEMSET cursor_sharing = FORCE SCOPE=MEMORY

Utl_file_dir : Bu parametre bir veya daha fazla lokasyonun, oracle tarafından PL/SQL ile

kullanılmasını sağlar. Bu parametre ile tüm userlar bu lokasyonlardaki bütün file’ leri okuyup

azabilirler.

Alter system set url_file_dir=’/u01/file1/’, ‘/u02/file2/’, ‘/tmp’ scope =SPFILE

CREATE DIRECTORY log_dir AS '/appl/gl/log';

GRANT READ ON DIRECTORY log_dir TO DBA;

CREATE DIRECTORY out_dir AS '/appl/gl/user'';

GRANT READ ON DIRECTORY user_dir TO PUBLIC;

Umarım faydalı bir makale olmuştur.

Bu yazıda Oracle 10g ile gelen ve Oracle 11g R2 sürümünde dahada mesafe kateden SQL Tuning Advisor(SQL İyileştirme Tavsiyecisi) paketinden bahsedeceğim. Oracle Tuning Advisor paketi ile SQL iyileştirme görevleri, Oracle 11g Grid Control veya Enterprise Manager(EM) grafiksel arayüzünden sihirbazlar yardımıyla adım-adım basitçe oluşturulduğu gibi komut satırındanda oluşturulabilmektedir. Bu yazıda komut satırından hazırlanışını adım-adım yapılandıracağız ve yazı sonunda bir tavsiye raporu alacağız.

Oracle 11g sürümü itibariyle SQL Tuning Advisor otomatik olarak yüksek kaynak tüketen SQL komutlarına karşı çalıştırılsada, Oracle SQL Tuning Advisor(SQL İyileştirme Tavsiyecisi), talep olduğunda bir veya birçok SQL komutunun manuel olarak iyileştirilmesinde de kullanılmaktadır. Bunun için AWR raporu ile geçen hafta alınan CPU ve I/O toplamları kıyaslaması yapılmaktadır. Otomatik SQL iyileştirmesinin etkinleştirilmesi için;

dbms_auto_sqltune(
begin_exec   IN VARCHAR2 := NULL, --oto sql iyileştirme başlama zamanı
end_exec     IN VARCHAR2 := NULL, --oto sql iyileştirme bitiş zamanı
type         IN VARCHAR2 := TEXT | HTML | XML,
level        IN VARCHAR2 := TYPICAL | ALL | BASIC,
section      IN VARCHAR2 := FINDING | PLAN | INFORMATION | ERROR | ALL,
object_id    IN NUMBER   := NULL,
result_limit IN NUMBER   := NULL)

ACCEPT_SQL_PROFILES adlı başlangıç parametresi değeri TRUE olarak ayarlanırsa SQL profilleride otomatik olarak kabul edilir. SQL profilleri diğer bir makale konusu olacak kadar kapsamlıdır, bu yazıda hiç girmeyeceğim. Ancak, otomatik SQL iyileştirme tavsiyecisinin etkinleştirilmesi, 11.2 sürümünde dahi hala “bug” lar olmasından dolayı pek tavsiye edilmez. Bu arada otomatik itileştirme etkinleştirildiğinde sistem üzerinde gereksiz bir kaynak tüketimi olacağıda göz ardı edilmemelidir.

Hazırlanacak tavsiye raporunda, komut içinde kullanılan tablo birleştirmelerinde varsa eksik indeksler ve anahtarlar tavsiye olarak işaret edilmektedir, ayrıca ulaşılan bloklar ve objeler ile ilgili detaylı bir çalıştırma planı kıyaslaması yer almaktadır. Bununla beraber SQ komutunun yeniden yapılandırılması(sorguda kullanılan birleştirme türlerinin uygunluğu,doğru sürücü tablo(lar) seçimi işaretivvb.), objeler üzerinde eksik istatistikler varsa bu eksik istatistiklerin toplanması ve SQL profil oluşturulması gibi tavsiyelerde bu raporda yer alır.

Birçok komutu iyileştirmek için öncelikle SQL iyileştirme setlerinin oluşturulması gerekmektedir.Tek bir komut için ise direkt olarak SQL iyileştirme görevi çalıştırılır.

SQL Tuning Advisor için gerekli olan veriler aşağıdaki gibi pekçok farklı kaynaktan sağlanabilir.

ADDM( Automatic Database Diagnostic Monitor)

Ana veri sağlama kaynağı ADDM’dir. Varsayılan olarak ADDM proaktif olarak her saat başı bir sefer çalışır ve son bir saat boyunca aşırı yüklü SQL komutlarını içeren bir kısım performans problemlerini belirlemek için AWR tarafından toplanan anahtar istatistikleri analiz eder. Eğer aşırı yüklü SQL belirlenirse, ADDM bu SQL komutu üzerinde SQL Tuning Advisor’ı çalıştırmayı tavsiye eder.

AWR(Automatic Workload Repository)

İkinci en önemli veri sağlama kaynağıda AWR’dir. AWR,CPU tüketimi ve bekleme süresi gibi ilişkili istatistikler tarafından sıralanan aşırı yüklü SQL komutlarını içeren sistem aktivitelerinin düzenli snapshotlarını çeker. İlgili AWR raporuna bakıldığında en çok kaynak tüketen SQL komutları belirlenebilir. Oracle, bu SQL komutları için otomatik iyileştirme tavsiyelerini sağlamasına rağmen manuel olarakta SQL Tuning Advisor çalıştırılabilir. AWR normalde çektiği bir snapshotu sekiz gün saklar.

Paylaşımlı SQL alanı

Üçüncü veri kaynağı ise paylaşımlı SQL alanıdır.Henüz AWR tarafında snapshhotu çekilmemiş olan son çalıştırılan SQL komutlarını iyileştirmek için kullanılmaktadır.

SQL iyileştirme seti (STS)

Diğer bir muhtemel veri sağlama kaynağı ise SQL iyileştirme setidir.SQL iyileştirme seti birçok SQL komutunun çalıştırma içeriklerini saklayan bir veritabanı objesidir.

SQL İyileştirme Tavsiyecisinin çalıştırılması

SQL iyileştirme tavsiyecisini çalıştırmanın en basit yolu Enterprise Manager konsoludur. Diğer bir yol ise, DBMS_SQLTUNE paketini komut satırından kullanarak SQL iyileştirme tavsiyecisini çalıştırmaktır ki bu yazıda DBMS_SQLTUNE paketi kullanımı üzerine odaklansamda, Oracle EM grafiksel arayüzü üzerinden çektiğim snapshotlarıda ekleyeceğim. Ya manuel yada sihirbazları kullanabilirsiniz.Benim tercihim komut satırından PL/SQL paketlerini kullanmak olduğundan, bu yazıda da komut satırı kullanımı üzerine odaklanacağım. Komut satırı kullanımı pek çok kişinin gözünü korkutsada OEM veya Grid Control arayüzünden sihirbazların kullanımı çok daha kompleks ve karılıktır(en azından bana öyle geliyorJ)

Aşağıda Oracle 11 EM konsolundan SYS ile oturum açıp, “Performans” tabı altında “Advisor” sekmesi altında “SQL Tuning Advisor” linkini tıklıyoruz.

SQL iyileştirme tavsiyecisinin çalıştırılması için aşağıdaki adımların izlenmesi gerekmektedir.

Eğer birden fazla SQL komutu iyileştirilecekse bir SQL iyileştirme seti oluşturulur.
Bir SQL iyileştirme görevi oluşturulur.
SQL iyileştirme görevi çalıştırılır.
SQL iyileştirme görevinin sonuçları görüntülenir.
Tavsiyeler yerindeyse uygulanır.

Şimdi yukardaki beş adımın her birini sırasıyla inceleyelim. Bu yazıda sadece SQl iyileştirme setinin oluşturulması ve içerisine filtrelenmiş SQL komutlarının nasıl yükleneceğini anlatacağım.

SQL iyileştirme setinin oluşturulması

Birden fazla SQL komutunu tek bir SQL seti içerisinde toplamak için önce bir set oluşturulmalı ve ihtiyaca uygun SQL komutları filtrelenip bu sete yüklenmelidir. İlgili SQL komutlarının filtrelenmesinde paylaşımlı bellek alanı veya herhangi bir AWR raporu kullanılabilir.

İlk adım olarak bir SQL seti aşağıdaki gibi oluşturulmalıdır.

BEGIN

DBMS_SQLTUNE.CREATE_SQLSET(sqlset_name => ‘test_sqlset’);

END;

Veya aşağıdaki gibi “Create SQL Tuning Set” seçilir. Aşağıdaki örnekte AWR snapshotunda yer alan SQL komutlarından seçim yapılarak set içine alınacak veriler bulunur ve seçilir.

Ardından SQL seti SQL cümlelerinin kaynak tüketimine göre sıralanmış olarak oluşturulur.

Aşağıda manuel olarak SQL set oluştururken veri alımında kullanılan metotlar yer almaktadır.

İmleç önbelleğinden yükleme

Paylaşımlı SQL alanından imleç önbelleğinde bulunan ve filtreleme şartlarına uyan SQL komutlarını seçip, ilgili SQL setine yüklemek için MS_SQLTUNE.SELECT_CURSOR_CACHE ve DBMS_SQLTUNE.LOAD_SQLSET komutlarının birlikte kullanıldığı bir PL/SQL bloğu çalıştırılır.

Aşağıdaki örnekte, imleç önbelleğinde bulunan SQL textlerinin içinde TBL_STOKGIRIS kelimesi geçen ve HR kullanıcısına ait tüm SQL komutları seçilip test_sqlset adlı SQL seti içerisine yüklenmektedir.

DECLARE

testgiris DBMS_SQLTUNE.sqlset_cursor;

BEGIN

OPEN testgiris FOR

SELECT VALUE(X)

FROM TABLE( DBMS_SQLTUNE.select_cursor_cache(

basic_filter => 'sql_text LIKE ''%tbl_stokgiris%'' and parsing_schema_name = ''HR''',

attribute_list => 'ALL')

) X;

DBMS_SQLTUNE.load_sqlset(sqlset_name => 'test_sqlset',

populate_cursor => testgiris);

END;

DBMS_SQLTUNE.SELECT_CURSOR_CACHE fonksiyonu ile birlikte kullanılan parameterlerin ne anlama geldikleri aşağıda yer almaktadır.

DBMS_SQLTUNE.SELECT_CURSOR_CACHE (

basic_filter IN VARCHAR2 := NULL,

object_filter IN VARCHAR2 := NULL,

ranking_measure1 IN VARCHAR2 := NULL,

ranking_measure2 IN VARCHAR2 := NULL,

ranking_measure3 IN VARCHAR2 := NULL,

result_percentage IN NUMBER := 1, -> sıralamaya bağlı top N listesinin yüzdesel değeri

result_limit IN NUMBER := NULL, à Top sınır listesi

attribute_list IN VARCHAR2 := NULL àBASIC | TYPICAL | ALL değerlerinden birisi)

Aşağıda basic_filter parametresi ile kullanılan bazı örnekler yer almaktadır.

basic filter => 'buffer_gets > 500' -- 500 tampon alımı yapan SQL komutları alır

basic filter => 'elapsed_time > 5000000' -- En az 5 saniye çalışan tüm komutları alır

basic_filter => ‘sharable_mem > 5242880’ --5 MB üzerinde paylaşımlı bellek kullanan tüm komutları alır

basic_filter => ‘parse_calls > 300 and executions< 2* parse_calls’ --En az 300 hard parse yapan tüm komutları alır

Bunun yanında tamamlanma süresine göre büyükten küçüğe TOP 10 SQL sıralamasındaki komutları imleç önbelleğinden almak için;

DBMS_SQLTUNE.SELECT_CURSOR_CACHE(

basic_filter => 'ELAPSED_TIME',

result_percentage => 1,

result_limit => 10)

Önbellek içinde tampon alımlarının %80’ini kullanan SQL komutlarını imleç önbelleğinden almak için;

DBMS_SQLTUNE.SELECT_CURSOR_CACHE(

basic_filter => 'BUFFER_GETS',

result_percentage => .8)

AWR raporundan yükleme

AWR raporundan SQL setine ilgili filtrelenmiş SQL komutlarını yüklemek için;

DBMS_SQLTUNE.SELECT_WORKLAOD_REPOSITORY (

begin_snap IN NUMBER,

end_snap IN NUMBER,

basic_filter IN VARCHAR2 := NULL,

object_filter IN VARCHAR2 := NULL,

ranking_measure1 IN VARCHAR2 := NULL,

ranking_measure2 IN VARCHAR2 := NULL,

ranking_measure3 IN VARCHAR2 := NULL,

result_percentage IN NUMBER := 1,

result_limit IN NUMBER := NULL

attribute_list IN VARCHAR2 := NULL)

veya

DBMS_SQLTUNE.SELECT_WORKLAOD REPOSITORY (

baseline_name IN VARCHAR2,

basic_filter IN VARCHAR2 := NULL,

object_filter IN VARCHAR2 := NULL,

ranking_measure1 IN VARCHAR2 := NULL,

ranking_measure2 IN VARCHAR2 := NULL,

ranking_measure3 IN VARCHAR2 := NULL,

result_percentage IN NUMBER := 1,

result_limit IN NUMBER := NULL)

attribute_list IN VARCHAR2 := NULL)

Fonksiyondaki parametrelerin anlamları SELECT_CURSOR_CACHE fonksiyonundaki parametreler ile aynıdır. Sadece AWR raporunun başlangıç ve bitiş snapshot parametreleri(ilk paket) ve snapshot baseline ismi(ikinci paket) ek parametrelerdir.

Şimdi AWR raporlarından SQL komutlarını alıp ilgili SQL setine yükleme örneğini inceleyelim.713 ve 721 arasındaki AWR snapshotlarında tamamlanma süresi en uzun olan 10 SQL komutu çekilip test_sqlset adlı SQL seti içine yüklenmektedir.

DECLARE

testgiris DBMS_SQLTUNE.sqlset_cursor;

BEGIN

OPEN testgiris FOR

SELECT VALUE(X)

FROM TABLE( DBMS_SQLTUNE.select_workload_repository

begin_snap => 713

end_snap => 721

basic_filter => ‘elapsed_time’

result_limit => 10

attribute_list => 'ALL')

) X;

DBMS_SQLTUNE.load_sqlset(sqlset_name => 'test_sqlset',

populate_cursor => testgiris);

END;

SQL iyileştirme görevinin(task) oluşturulması

İyileştirilme görevleri tek bir SQL komutunun textinden, birden fazla komutu barındıran bir SQL setinden yada paylaşımlı havuzdaki veya AWR raporundaki bir SQL komutununun SQL ID değeri seçilerek oluşturulabilir.Birinci bölümde iyileştirlme görevinde çoklu komutlardan oluşturulan SQL setlerinin nasıl hazırlandığını görmüştük.

Bununla beraber standart bir kullanıcının iyileştirme görevi oluşturabilmesi için; önce ADVISOR hakkına sahip olması ve ardından ilgili kullanıcının şema objeleri üzerinde bu fonsiyonun çalıştırılması gerekmektedir.

Aşağıda SQL iyileştirme görevini oluşturmak için kullanılan PL/SQL paketleri yer almaktadır.

Bir SQL textinden, bind değişkenli yada bind değişkensiz SQL iyileştirme görevi oluşturmak;

DBMS_SQLTUNE.CREATE_TUNING_TASK(

sql_text IN CLOB,

bind_list IN sql_binds := NULL,

user_name IN VARCHAR2 := NULL,

scope IN VARCHAR2 := SCOPE_COMPREHENSIVE,

time_limit IN NUMBER := TIME_LIMIT_DEFAULT,

task_name IN VARCHAR2 := NULL,

description IN VARCHAR2 := NULL)

Bir SQL textinden plan_hash_value değerine göre SQL iyileştirme görevi oluşturmak;

DBMS_SQLTUNE.CREATE_TUNING_TASK(

sql_id IN VARCHAR2,

plan_hash_value IN NUMBER := NULL,

scope IN VARCHAR2 := SCOPE_COMPREHENSIVE,

time_limit IN NUMBER := TIME_LIMIT_DEFAULT,

task_name IN VARCHAR2 := NULL,

description IN VARCHAR2 := NULL)

Bir AWR raporundan ilgili snapshot aralığında SQL iyileştirme görevi oluşturmak;

DBMS_SQLTUNE.CREATE_TUNING_TASK(

begin_snap IN NUMBER,

end_snap IN NUMBER,

sql_id IN VARCHAR2,

plan_hash_value IN NUMBER := NULL,

scope IN VARCHAR2 := SCOPE_COMPREHENSIVE,

time_limit IN NUMBER := TIME_LIMIT_DEFAULT,

task_name IN VARCHAR2 := NULL,

description IN VARCHAR2 := NULL)

Bir SQL setinden filtreleme şartlarına uygun SQL iyileştirme görevi oluşturmak;

DBMS_SQLTUNE.CREATE_TUNING_TASK(

sqlset_name IN VARCHAR2,

basic_filter IN VARCHAR2 := NULL,

object_filter IN VARCHAR2 := NULL,

rank1 IN VARCHAR2 := NULL,

rank2 IN VARCHAR2 := NULL,

rank3 IN VARCHAR2 := NULL,

result_percentage IN NUMBER := NULL,

result_limit IN NUMBER := NULL,

scope IN VARCHAR2 := SCOPE_COMPREHENSIVE,

time_limit IN NUMBER := TIME_LIMIT_DEFAULT,

task_name IN VARCHAR2 := NULL,

description IN VARCHAR2 := NULL

plan_filter IN VARCHAR2 := 'MAX_ELAPSED_TIME',

sqlset_owner IN VARCHAR2 := NULL)

DBMS_SQLTUNE.CREATE_TUNING_TASK paketinde önemli olan bazı parametrelerin ne anlama geldiğine bakarsak;

bind_list: ANY DATA tipinde bind değişkenlerinin sıralı listesi(mesela 100 adlı bind değişkeni için => sql_binds(anydata.ConvertNumber(100))

plan_hash_value: SQL çalıştırma planının hash değeri

sqlset_name: Daha önceden oluşturulan SQL setinin adı

time_limit: Optimizer’ın derleme için harcayacağı saniye değerinden süre

basic_filter: SQL iyileştirme seti içinden kaynak kullanımı ile ilgili filtreleme yapabilmek için kullanılan filtre değeri veya değerleri

result_limit: Filtre sonucunda göre Top N sıralaması.

result_percentage: Toplam ölçüt değerininin yüzdesi (örneğin paylaşımlı alanının %5 ini kullanan SQL komutlarını bulmak gibi…)

scope: LIMITED veya SCOPE_COMPREHENSIVE değerini alır. Sınırlı yada daha kapsamlı durumlar için tercih edilir, LIMITED seçilirse SQL profil analizi es geçilir.

rank 1-2-3: Oracle kaynak kullanım tercihleri(varsayılan “elapsed_time” değeridir, eğer değiştirilmek istenirse veya yeni kaynak verileri eklenmek istenirse rank2,rank3 parametresine eklenir.)

plan_filter: Aynı komut için birden fazla plan seçildiğinde kullanılan plan filtresidir (plan_hash_value) Aşağıdaki değerlerden birisini alır.

LAST_GENERATED: En güncel zaman mührüne sahip plan
FIRST_GENERATED: En eski zaman mührüne sahip plan
LAST_LOADED: En güncel first_load_time istatistiği olan plan
FIRST_LOADED: En eski first_load istatistiğine sahip plan
MAX_ELAPSED_TIME: Maksimum tamamlanma süresine sahip plan
MAX_BUFFER_GETS: Maksmimum tampon alımına sahip plan
MAX_DISK_READS: Maksimum disk okumasına sahip plan
MAX_DIRECT_WRITES: Maksimum direkt yazma değerine sahip plan
MAX_OPTIMIZER_COST: Maksimum optimizer cost değerine sahip plan

Aşağıda bu paket ile ilgili her üç tip veri alım kriteri örnekleri yer almaktadır. İlk olarak senaryoda kullanılan HR şeması objelerinin incelenmesi için HR kullanıcısına ADVISOR yetkisini tamamlayıp, ardından 2 farklı değişken atıyorum.

GRANT ADVISOR to HR;

variable test_task VARCHAR2(80);

variable test_task2 VARCHAR2(80);

SQL text formatından iyileştirme;

EXEC :test_task:= DBMS_SQLTUNE.CREATE_TUNING_TASK(

sql_text => ‘SELECT e.employee_id, d.department_name, e.salary, e.hire_date FROM employees e,departments d WHERE e.salary IN (SELECT AVG(salary) FROM employees GROUP BY department_id) AND e.department_id=d.department_id’,

user_name => ’HR’, task_name => ‘test_task’);

SQL ID formatı(imleç önbelleğinden);

EXEC :test_task:= DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_id => '7c6hmwaywnha9', task_name => ‘test_task_bycache’);

LIMITED scope içinde iyileştirme;

EXEC :test_task:= DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_id => '7c6hmwaywnha9', scope => 'LIMITED', task_name => ‘test_task_bycachescopelimited’);

SQL komutunu iyileştirmek için derleme zamanına sadece 10 dakika verilmek istenirse;

EXEC :test_task:= DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_id => '7c6hmwaywnha9', time_limit => 600, task_name => ‘test_task_bycachetimelimited’);

AWR içinden ilgili SQL ID numarasına göre iyileştirme;

EXEC :test_task2:= DBMS_SQLTUNE.CREATE_TUNING_TASK(begin_snap => 102,

end_snap => 103, sql_id => 'lq5m4mtflgw9k', task_name => ‘test_task_byawr’);

SQL iyileştirme seti kullanarak iyileştirme; Bu işlemden önce ilgili SQL seti yüklenmelidir. Aşağıdaki örnekte, “buffer_gets” sıralamasına göre bir saat süre boyunca test_sqlset setinden iyileştirme işlemi yer almaktadır.

EXEC :test_task := DBMS_SQLTUNE.CREATE_TUNING_TASK(

sqlset_name => 'test_sqlset',

rank1 => 'BUFFER_GETS',

time_limit => 3600,

task_name => ‘test_taskbysqlset’);

Oracle EM veya Grid Control grafiksel arayüzü üzerinden SQL iyileştirme görevinin oluşturulması örneği aşağıda yer almaktadır.

SQL iyileştirme görevinin çalıştırılması

SQL iyileştirme görevini oluşturduktan sonra bu görevin çalıştırılması gerekmektedir.Böylece SQL iyileştirme prosesi başlatılmış olur ve derleme zamanı işlemeye başlar.Bu derleme zamanı, görevi oluştururken verilen “time_limit” değerine bağlıdır.Bu süre sonunda derleme işlemi biter.

BEGIN

DBMS_SQLTUNE.EXECUTE_TUNING_TASK(‘test_task’);

END;

Çalışmakta olan bir SQL iyileştirme görevinin durumunu kontrol etmek için USER_ADVISOR_TASKS veya DBA_ADVISOR_LOGS görünümlerine, görevin çalıştırılma sürecini kontrol etmek için ise V$SESSION_LONGOPS görünümüne sorgu çekilebilir. Aşağıdaki ilk sorgu, derlenmesi devam eden iyileştirme görevlerini listeler, ikinci sorgu ise derlenmiş iyileştirme görevlerini listeler.

SELECT SOFAR, TOTALWORK

FROM V$ADVISOR_PROGRESS

WHERE TASK_NAME = ‘test_task';

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

SELECT task_name, status

FROM dba_advisor_log

WHERE owner = 'HR';

TASK_NAME STATUS

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

test_task COMPLETED

1 row selected.

SQL iyileştirme görev sonuçlarının raporlanması

Bu adımda çalıştırılan SQL iyileştirme görevlerinin sonuçları rapor olarak alınmaktadır.Bu işlem için DBMS_SQLTUNE.REPORT_TUNING_TASK fonksiyonu çalıştırılmaktadır.Bu raporda SQL iyileştirme tavsiyesicisinin bulguları ve tavsiyeleri yer almaktadır. Text, HTML veya XML formatında rapor alınabilir ve analiz raporu tipik, temel ve kapsamlı(all) şeklinde olabilmektedir.

Aşağıda SQL iyileştirme setlerinin raporlanması için kullanılan sentaks yer almaktadır.

DBMS_SQLTUNE.REPORT_TUNING_TASK(

task_name IN VARCHAR2,

type IN VARCHAR2 := TEXT | HTML |XML ,

level IN VARCHAR2 := TYPICAL | BASIC | ALL ,

section IN VARCHAR2 := FINDING | PLAN | INFORMATION | ERROR | ALL ,

object_id IN NUMBER := NULL,

result_limit IN NUMBER := NULL-- rapor içinde bulunacak maksimum SQL komut sayısı-- )

Bunun yanında Oracle 11.2.0.2 sürümünden itibaren otomatik SQL iyileştirme görev sonuçlarının raporlanması aşağıdaki komutla yapılır. Ancak hala oto rapor fonksiyonuyla ilgili “bug” lar mevcuttur(mesela fonsiyonda üstteki maneul raporlama gibi LEVEl ve SECTION parametreleri varsayılan ayarlardan değiştirilirken alınan ORA-01748 hatası gibi…).

SELECT dbms_auto_sqltune.report_auto_tuning_task FROM dual;

Aşağıda bu örnekte kullandığım test_task adlı iyileştirme görevinin raporu yer almaktadır. LEVEL ve SECTION parametre değerlerini ALL olarak atıyorum.

SET LONG 10000

SET PAGESIZE 1000

SET LINESIZE 200

SELECT DBMS_SQLTUNE.report_tuning_task('test_task', ‘TEXT’, ‘ALL’, ‘ALL’) FROM dual;

DBMS_SQLTUNE.REPORT_TUNING_TASK('TEST_TASK','TEXT','ALL','ALL')

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

GENERAL INFORMATION SECTION

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

Tuning Task Name : test_task

Tuning Task Owner : HR

Tuning Task ID : 256

Scope : COMPREHENSIVE

Time Limit(seconds) : 1800

Completion Status : COMPLETED

Started at : 05/09/2011 15:44:49

Completed at : 05/09/2011 15:44:55

Number of Index Findings : 1

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

Schema Name: HR

SQL ID : 7c6hmwaywnha9

SQL Text : SELECT e.employee_id, d.department_name, e.salary, e.hire_date FROM employees e,departments d WHERE e.salary IN (SELECT AVG(salary) FROM employees GROUP BY department_id) AND

e.department_id=d.department_id

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

FINDINGS SECTION (1 finding)

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

1- Index Finding (see explain plans section below)

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

The execution plan of this statement can be improved by creating one or more indices.

Recommendation (estimated benefit: 100%)

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

- Consider running the Access Advisor to improve the physical schema design or creating the recommended index.

- Create index HR.IDX$$_01000001 on HR.EMPLOYEES('SALARY');

Rationale

---------

Creating the recommended indices significantly improves the execution plan of this statement. However, it might be preferable to run "Access Advisor" using a representative SQL workload as opposed to a single statement. This will allow to get comprehensive index recommendations which takes into account index maintenance overhead and additional space consumption.

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

EXPLAIN PLANS SECTION

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

1- Original

-----------

Plan hash value: 3509108563

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

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

| 0 | SELECT STATEMENT | | 2 | 96 | 9 (23) | 00:00:01 |

| 1 | NESTED LOOPS | | 2 | 96 | 9 (23) | 00:00:01 |

|* 2 | HASH JOIN SEMI | | 2 | 64 | 8 (25) | 00:00:01 |

| 3 | TABLE ACCESS FULL | EMPLOYEES | 107 | 2033 | 3 (0) | 00:00:01 |

| 4 | VIEW | VW_NSO_1 | 1 | 13 | 4 (25) | 00:00:01 |

|* 5 | FILTER | | | |

| |

| 6 | HASH GROUP BY | | 1 | 7 | 4 (25) | 00:00:01 |

| 7 | TABLE ACCESS FULL | EMPLOYEES | 107 | 749 | 3 (0) | 00:00:01 |

| 8 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 1 | 16 | 1 (0) | 00:00:01 |

|* 9 | INDEX UNIQUE SCAN | DEPT_ID_PK | 1 | | 0 (0) | 00:00:01 |

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

Query Block Name / Object Alias (identified by operation id):

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

1 - SEL$5DA710D3

3 - SEL$5DA710D3 / E@SEL$1

4 - SEL$683B0107 / VW_NSO_1@SEL$5DA710D3

5 - SEL$683B0107

7 - SEL$683B0107 / EMPLOYEES@SEL$2

8 - SEL$5DA710D3 / D@SEL$1

9 - SEL$5DA710D3 / D@SEL$1

Predicate Information (identified by operation id):

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

2 - access("E"."SALARY"="$nso_col_1")

5 - filter(AVG("SALARY")>0)

9 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")

Column Projection Information (identified by operation id):

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

1 - (#keys=0) "E"."SALARY"[NUMBER,22], "E"."EMPLOYEE_ID"[NUMBER,22],

"E"."HIRE_DATE"[DATE,7], "D"."DEPARTMENT_NAME"[VARCHAR2,30]

2 - (#keys=1) "E"."SALARY"[NUMBER,22], "E"."EMPLOYEE_ID"[NUMBER,22],

"E"."HIRE_DATE"[DATE,7], "E"."DEPARTMENT_ID"[NUMBER,22]

3 - "E"."EMPLOYEE_ID"[NUMBER,22], "E"."HIRE_DATE"[DATE,7],

"E"."SALARY"[NUMBER,22], "E"."DEPARTMENT_ID"[NUMBER,22]

4 - "$nso_col_1"[NUMBER,22]

5 - AVG("SALARY")[22]

6 - (#keys=1) "DEPARTMENT_ID"[NUMBER,22], AVG("SALARY")[22]

7 - "SALARY"[NUMBER,22], "DEPARTMENT_ID"[NUMBER,22]

8 - "D"."DEPARTMENT_NAME"[VARCHAR2,30]

9 - "D".ROWID[ROWID,10]

2- Using New Indices

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

Plan hash value: 2906953147

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

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

| 0 | SELECT STATEMENT | | 2 | 96 | 7 (29)| 00:00:01 |

| 1 | NESTED LOOPS | | 2 | 96 | 7 (29)| 00:00:01 |

| 2 | NESTED LOOPS | | 2 | 64 | 6 (34)| 00:00:01 |

| 3 | VIEW | VW_NSO_1 | 1 | 13 | 4 (25)| 00:00:01 |

| 4 | HASH UNIQUE | | 1 | 7 | 4 (25)| 00:00:01 |

|* 5 | FILTER | | | | | |

| 6 | HASH GROUP BY | | 1 | 7 | 4 (25)| 00:00:01 |

| 7 | TABLE ACCESS FULL | EMPLOYEES | 107 | 749 | 3 (0)| 00:00:01 |

| 8 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 2 | 38 | 1 (0)| 00:00:01 |

|* 9 | INDEX RANGE SCAN | IDX$$_01000001 | 2 | | 0 (0)| 00:00:01 |

| 10 | TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 1 | 16 | 1 (0)| 00:00:01 |

|* 11 | INDEX UNIQUE SCAN | DEPT_ID_PK | 1 | | 0 (0)| 00:00:01 |

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

Query Block Name / Object Alias (identified by operation id):

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

1 - SEL$5DA710D3

3 - SEL$683B0107 / VW_NSO_1@SEL$5DA710D3

4 - SEL$683B0107

7 - SEL$683B0107 / EMPLOYEES@SEL$2

8 - SEL$5DA710D3 / E@SEL$1

9 - SEL$5DA710D3 / E@SEL$1

10 - SEL$5DA710D3 / D@SEL$1

11 - SEL$5DA710D3 / D@SEL$1

Predicate Information (identified by operation id):

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

5 - filter(AVG("SALARY")>0)

9 - access("E"."SALARY"="$nso_col_1")

11 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")

Column Projection Information (identified by operation id):

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

1 - (#keys=0) "E"."EMPLOYEE_ID"[NUMBER,22], "E"."HIRE_DATE"[DATE,7],

"E"."SALARY"[NUMBER,22], "D"."DEPARTMENT_NAME"[VARCHAR2,30]

2 - (#keys=0) "E"."EMPLOYEE_ID"[NUMBER,22], "E"."HIRE_DATE"[DATE,7],

"E"."SALARY"[NUMBER,22], "E"."DEPARTMENT_ID"[NUMBER,22]

3 - "$nso_col_1"[NUMBER,22]

4 - (#keys=1) AVG("SALARY")[22]

5 - AVG("SALARY")[22]

6 - (#keys=1) "DEPARTMENT_ID"[NUMBER,22], AVG("SALARY")[22]

7 - "SALARY"[NUMBER,22], "DEPARTMENT_ID"[NUMBER,22]

8 - "E"."EMPLOYEE_ID"[NUMBER,22], "E"."HIRE_DATE"[DATE,7],

"E"."SALARY"[NUMBER,22],

"E"."DEPARTMENT_ID"[NUMBER,22]

9 - "E".ROWID[ROWID,10], "E"."SALARY"[NUMBER,22]

10 - "D"."DEPARTMENT_NAME"[VARCHAR2,30]

11 - "D".ROWID[ROWID,10]

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

Yukardaki raporda iyileştirme görevi kapsamındaki SQL komut textinin 1.kısım mevcut mimaride çalıştırılması halinde çalıştırma planını, 2. kısım ise tavsiye sonucunda çalıştırılması halinde yeni çalıştırma planını göstermektedir.

Aşağıda Oracle EM veya Grid Control grafiksel arayüzünden alınan bir tavsiye raporu örneği yer almaktadır.

İyileştirme işlemi tamamlandığında veya ilerde bu SQL iyileştirme görevlerine ihtiyaç kalmadığında, tüm içeriğiyle beraber Oracle sistemden silinebilir.

BEGIN

DBMS_SQLTUNE.drop_tuning_task (task_name => 'test _task');

DBMS_SQLTUNE.drop_tuning_task (task_name => 'test _taskbycache');

DBMS_SQLTUNE.drop_tuning_task (task_name => 'test_taskbycachescopelimited');

DBMS_SQLTUNE.drop_tuning_task (task_name => 'test_taskbycachetimelimited');

DBMS_SQLTUNE.drop_tuning_task (task_name => 'test_taskbyawr');

DBMS_SQLTUNE.drop_tuning_task (task_name => 'test_taskbysqlset');

END;

Bu makalede Oracle 10g itibariyle kullanıma sunulan, SQL komutlarını otomatik olarak iyileştirmek için tavsiye raporları sunan Oracle Tuning Advisor ile SQL iyileştirme görevlerinin hazırlanmasını inceledik.

TKPROF, SQL izleme(trace) dosyalarını sırasıyla analiz etmek ve bu izleme dosyalarında yer alan bilgilerden okunabilir formda raporlar hazırlamak için işletim sistemi seviyesinde kullanılan bir Oracle yardımcı aracıdır. TKPROF aracını kullananarak ayrıntıların çağrılması platformdan platforma değişiklik göstermesine rağmen, TKPROF tüm Oracle sürümlerince desteklenmektedir ve tüm Oracle veritabanı sürümlerinde aynı işleve sahiptir.

SQL izlemesi, bütün bir instance için veya bireysel oturumlar için etkinleştirilen veya devredışı bırakılan bir işlemdir. Bir oturum için SQL izlemesi etkinleştirildiğinde, oturumu tutan Oracle prosesi, tüm veritabanı çağrılarını ve operasyonları ile ilgili detaylı bilgileri bir izleme dosyasına yazar. Özel veritabanı olayları, bind variables(bağlaç değişkenler) gibi daha spesifik bilgilerin sırasıyla Oracle’ın izleme dosyasına yazılmasına sebep vermek içinde ayarlanabilir.

SQL izlemesi, bireysel SQL komutlarındaki performans bilgilerini içerir. Her bir komut için aşağıdaki istatistikleri oluşturur:

Çözümleme(parse), çalıştırma(execute) ve satır alıp getirme(fetch) sayıları

CPU süresi and tamamlama süresi

Fiziksel okumalar ve mantıksal okumalar

İşlem gören satır sayısı

Library cache üzerindeki kayıplar(misses)

Her bir çözümleme işlemindeki kullanıcı adı

Her bir commit and rollback işlemi

Her bir SQL komutu için bekleme olayı ve her bir izleme dosyası için özet bilgisi

Eğer SQL oturumunu için SQL komutunun imleci(cursor) kapanmışsa, SQL izlemesi aynı zamanda aşağıdakiler ile ilgilide satır kaynak bilgilerini sağlayacaktır.

Her bir SQL komutunun güncel çalışma planını gösteren satır işlemleri

Satır üzerindeki her bir işlem için tamamlama süresi, satır sayısı, ardışık okumalar(consistent reads) ve fiziksel yazma sayısı

Bir instance veya oturum için SQL izlemesini etkinleştirmek münkün olmasına rağmen, bunların yerine DBMS_SESSION veya DBMS_MONITOR paketlerinin kullanılması tavsiye edilmektedir. Bir oturum veya instance için SQL izlemesi etkin olduğunda, kullanıcı oturumu veya instance oturumu içinde çalıştırılan tüm SQL komutlarına ait performans istatistikleri izleme dosyalarına yazılır. SQL izlemesinin kullanılması veritabanında şiddetli performans etkisi oluşturabilir ve aşırı CPU kullanımı, yetersiz disk alanı gibi artan sistem yüklerine sebebiyet verebilir.

Aslında, SQL izleme dosyaları text dosyaları olduğundan bir editor programla açıldığında rahatlıkla okunabilir formattadır,yani binary değildir. Ancak, aşırı oranda tekrarlıdır, ayrıntılıdır ve kısmen karışık formattadır. Örneğin, eğer bir uygulama bir imleç açıp bir seferde tek satır imlecinden 1000 satır alıp getirirse, izleme dosyası içinde 1000 tane ayrı giriş olacaktır. Tabii, çıplak gözle bunların ne olduğunu anlamak imkansız hale gelecektir. İşte bu sebeple, izleme dosyasını sırasıyla daha kolayca anlaşılabilecek bir formata dönüştürmek için, işletim sistemi komut satırından çağrılan bir araç olan, TKPROF kullanılır.

Her bir SQL komutunun ne kadar çözümlendiği, çalıştırıldığı ve satır getirdiği(fetch) sayılarıyla birlikte bu raporda gösterilir. CPU süresi, tamamlanma süresi, mantıksal ve fiziksel okumalar ve işlenen satırların library cache içindeki kayıpları ve tekrarlama(recursion) seviyesiyle birlikte ayrıca raporlanır. TKPROF, ayrıca opsiyonel olarak rapor içindeki her bir SQL komutu için, çalışma planının her bir adımında ne kadar satır işlendiği sayısıyla birlikte, bütün bir çalışma planıda(execution plan)içerebilir.

Eğer istenirse, bu TKPROF raporu içinde SQL komutlarının ne kadar kaynak tükettiğide sırasıyla listelenebilir. Ayrıca, SYS kullanıcısı tarafında “data dictionary” objeleri yönetmek için yinelemeli yayınlanan SQL komutlarıda dahil edilebilir veya hariç tutulabilir. TKPROF, izlenen oturumdan SQL komutlarını bir kuyruk(spool) dosyasınada yazabilir.

SQL izlemesini instance seviyesinde etkinleştirmek için SQL_TRACE başlangıç parametresinin TRUE olarak ayarlanması ve veritabanının yeniden başlatılması gerekmektedir. Bu işlemden sonra veritabanında açılan tüm oturumlar SQL izleme modunda olacaktır, yani tüm SQL işlemleri izleme dosyalarına kayıt edilecektir, hatta PMON ve SMON işlemleri bile.

Pratikte SQL izlemesinin instance seviyesinde etkinleştirilmesi genelde uygun olmaz, tüm gerekli gereksiz SQL komutlarının izlenmesi sisteme oldukça yüksek ek yük getirecektir. Bu sebeple sadece performansı etkileyen oturumların izlenmesi ve/veya istenen SQL komutlarının oturum katmanında izlenmesi tavsiye edilir. Oturum katmanında SQL izlemesini etkinleştirmek (TRUE) ve devredışı bırakmak (FALSE) için aşağıdaki komut kullanılmaktadır.

ALTER SESSION SET sql_trace = TRUE | FALSE;

İzlenmesini istediğimiz oturumda ALTER SESSION komutunun yürütülmesinin mümkün olmadığı durumlarda (önceden paketlenmiş uygulamalar gibi), veritabanına DBA kullanıcısı olarak başka bir oturumdan bağlanarak DBMS_SYSTEM paketi ile SQL izlemesi açılabilir veya kapanabilir. Bunu yapmak için V$SESSION görünümüne sorgu çekilerek izlenmesi istenen oturumun SID ve seri numarası bulunabilir ve ardından aşağıdaki gibi DBMS_SYSTEM paketi çalıştırılabilir.

EXECUTE SYS.dbms_system.set_sql_trace_in_session (<SID>, <serial#>, TRUE | FALSE);

Bir oturum için ilk seferinde SQL izlemesi etkinleştirildiğinde, oturumu tutan Oracle sunucusu user_dump_dest başlangıç parametresince belirtilen dizinde izleme dosyasını oluşturur. Oracle sunucusu, veritabanı işlemlerini gerçekleştirmek için uygulama tarafından çağrıldıkça sunucu prosesi izleme dosyasının üzerine yazmaya devam eder.

Multi-thread sunucu(MTS) kullanarak veritabanını izlemek biraz daha karışıktır, çünkü uygulamadaki her bir veritabanı çağrısı farklı sunucu proseslerince toplanacaktır. Bu durumda, her bir sunucu prosesi o proses tarafından gerçekleştirilen işlemler hakkında izleme bilgilerini içeren bir izleme dosyası oluşturacaktır. Yani, uygulamanın veritabanı ile nasıl entegre olduğu hakkında büyük resmi görebilmek için birden çok izleme dosyası birlikte kombine olarak kullanılacaktır. Bununda ötesinde, eğer tek seferde birden çok oturum izleniyorsa, izleme dosyasındaki bir işlemin hangi oturuma ait olduğunun söylenmesi zor olacaktır. Bu sebepler yüzünden, SQL izlemesi ile veritabanı oturumu izlemesinde “dedicated” sunucu modu kullanılmalıdır.

SQL izleme dosyası detaylı süre bilgisi içermektedir. Varsayılan olarak Oracle 11g sürümünde süre izlemesi etkindir. Eğer süre devredışı bırakılırsa, zaman izlemesi olmayacağından dolayı izleme dosyası içindeki bütün zaman görüntüleri sıfır olarak gözükecektir. Süre bazlı izlemeyi etkinleştirmek için başlangıç parametresindeki parametre aşağıdaki gibi değiştirilmeli ve instance yeniden başlatılmalıdır.

ALTER SYSTEM SET timed_statistics=true SCOPE=SPFILE;

Oturum katmanında süre bazlı izlemenin etkinleştirilmesi için aşağıdaki komut bu oturumdan çalıştırılır.

ALTER SESSION SET timed_statistics = TRUE | FALSE;

SQL izlemesinin etkinleştirilmesi sonucunda sistem üzerine ek bir yük bineceğinden bahsetmiştik, hatta bazı DBA’ler bunun %25’e kadar performansta olumsuz etki yapacağını belirtmektedirler. Bunun yanında SQL izlemesinin etkinleştirilmesi, gereğinden fazla izleme dosyalarının oluşturulmasına sebebiyet verecektir. Bu sebeplerle, SQL izlemesini gerektiğinde ve kararınca kullanmak gerekmektedir.

Linux/UNIX sistemlerde Oracle temel izinleri ayarlayarak, sadece oracle kullanıcısı ve dba adlı Unix grubu tarafından izleme dosyaları okunabilir. Unix/Linux sistemlerden oturum açan diğer sistem kullanıcılarının izleme dosyalarını okuyabilmesi isteniyorsa, bu durumda aşağıdaki başlangıç parametresi ayarlanmalıdır. Ancak bunun bir güvenlik zaafiyeti oluşturacağını unutmamanız gerekmektedir.

ALTER SYSTEM SET “_trace_files_public” = true SCOPE=SPFILE;

Eğer veritabanı sunucusuna olması gerektiğinden çok çağrı yapan oturumlar tespit edilmişse ve bunlar izlenecekse, izleme dosyası oldukça büyük tutulmalıdır. İzleme dosyasının maksimum büyüklüğü max_dump_file_size parametresince tanımlanmaktadır. UNIX/Linux sistemlerde bu parameyre 512 bytelık blok birimleri olarak belirlenmiştir. Böylece, 10240 lık bir ayar izleme dosyasını 5MB büyüklüğündeki bir parçaya kadar sınırlandırmış olacaktır. Bunun yanında 2GB dan daha büyük izleme dosyasının UNIX/Linux sistemlerde izlenmesinde “could not open trace file xxx_xx_xxx.trc” hata mesajına karşılık izleme dosyası lokasyonu içerisinde mkfifo komutu yeni bir pipe oluşturularak bir prosesin dosyaya yazarken başka bir prosesin bu dosyayı okumasına imkan vererek verinin normal anonim pipe şeklinde akmasına imkan sağlanır. 2GB dan daha büyük SQL izleme dosyası kullanıldığında TKPROF işleminin başarılı okuma yapması için aşağıdaki adımlar uygulanabilir. Aşağıdaki örnekte test_ora_3419.trc adlı SQL izleme dosyası 2 GB üzerindedir ve normalde TKPROF ile çağrıldığında hata mesajı vermektedir. 2GB üzerindeki her bir izleme dosyasının TKPROF ile çağrılması için aşağıdaki 3 adımın uygulanması gerekmektedir. Alternatif olarak 2GB dan daha büyük bir kuyruk dosyası oluşturarakta bu sorun çözülebilir(detaylar için bakınız Metalink Note 94486.1)

izleme dosyaların bulunduğu lokasyon içinde yeni bir pipe oluşturulur

$ mkfifo izlemepipe

tkprof ile bu pipe dosyasından çıktı oluşturulur.

$ tkprof izlemepipe test_ora_3419.out

Başka bir oturumdan izleme dosyasının olduğu dizin değiştirilir ve aşağıdaki komut çalıştırılır

$ cat test_ora_3419.trc > izlemepipe

SQL izleme dosyası maksimum büyüklüğü aştığında, veritabanı sunucu prosesi izleme dosyasına izleme bilgisini yazmayı durdurur. UNIX/Linux sistemlerde eğer max_dump_file_size parametresi ayarlanmadıysa izleme dosya büyüklüğünde maksimum bir limit yoktur.

Eğer bir oturum izleniyorsa ve izleme dosyası max_dump_file_size parametresince belirlenen limiti aşmak üzere olduğu anlaşıldıysa, dinamik olarak limit gözardı edilebilir ve böylece izleme bilgisi kaybedilmez. Bunu yapmak izleme dosyasına yazan prosesin ORACLE PID’sini bulmak için V$PROCESS görünümünün PID kolonuna sorgu yapılır. Ardından SQL*Plus içinden aşağıdaki komutlar çalıştırılır.

CONNECT / AS SYSDBA

ORADEBUG SETORAPID <pid>

ORADEBUG UNLIMIT

İzleme dosyasında TKPROF aracının çalıştırılması

TKPROF kullanılmadan önce izleme dosyasının oluşturulması ve yerinin belirlenmesi gerekmektedir. Oracle izleme dosyalarını -- PMON gibi daemon prosesleri haricindeki işlemleri -- user_dump_dest başlangıç parametresinde belirlenen dizine yazar. Unix/Linux sistemlerde, izleme dosyası, bu dosyaya yazan sunucu prosesinin işletim sistemi PID’si ile örtüşen bir isme sahiptir.

Eğer user_dump_dest dizininde çok sayıda izleme dosyası varsa, istenen dosyanın bulunması biraz teferrüatlı olabilir. Bunun üstesinden gelmenin en önemli yolu dosyaların oluşturulma zamanına bakmaktır. Diğer bir metot ise oturum katmanında izleme dosyasının etkinleştirilmesinde kullanılan komut içine bu izleme dosyasını diğerlerinden farklı kılıp anlaşılması için bir “yorum” eklemektir. Bununla ilgili örnek aşağıda yer almaktadır.

ALTER SESSION /* Module hr_22042011.c */ SET sql_trace = TRUE;

Bunun yanında hangi oturumların hangi izleme dosyasına işlem yaptığını görmek için aşağıdaki sorguda kullanılabilir. Bunun neticesinde izlenmesi istenen oturumun SQL komutlarının yer aldığı izleme dosyasına TKPROF ile izleme başlatılabilir.

select b.username, c.value || '\' || lower(d.value) || '_ora_' ||

to_char(a.spid, 'fm00000') || '.trc' "TRACE_FILE"

from v$process a, v$session b, v$parameter c, v$parameter d

where a.addr = b.paddr

and c.name = 'user_dump_dest'

and d.name = 'db_name'

and b.username is not null;

USERNAME TRACE_FILE

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

SYS /u01/app/oracle/diag/rdbms/ugur/ugur/trace/UGUR_ora_3345.trc

HR /u01/app/oracle/diag/rdbms/ugur/ugur/trace/UGUR_ora_3564.trc

ARDA /u01/app/oracle/diag/rdbms/ugur/ugur/trace/UGUR_ora_3708.trc

Unix/Linux platformlarında TKPROF uygulamasını çalıştırmak için terminal penceresinden aşağıdaki komut çalıştırılır.

tkprof <trace file> <output file> [explain=<username/password>] [sys=yes | no] [table=<schema>.<table>] [insert=<filename>] [record=<filename>] [sort=<keyword>]

Eğer TKPROF komutunu herhangi bir arguman kullanmadan çalıştırırsanız tüm seçenekler ekrana listelenecektir. Basit formda, TKPROF komutu bir çıktı dosya ismi ve bir SQL izleme dosyası ile tanımlanır. TKPROF, izleme dosyasını okuyacak ve belirlenen bir çıktı ismi altında bu rapor dosyasını oluşturacaktır. TKPROF, veritabanına bağlanmaz ve bu rapor SQL komutları için çalıştırma planları içermez. SYS kullanıcısı tarafında yinelemeli olarak çalıştırılan SQL komutlarıda bu rapor içinde yer alır ve SQL komutları izlenen oturumunda çalıştırma sırasına göre listelencektir.

Eğer“explain”kelimesi eklenirse TKPROF veritabanına bağlanır ve izleme dosyası içinde bulunan her bir SQL komutu için bir EXPLAIN PLANçalıştırır. Açıklama planı sonuçları bu rapor dosyası içinde yer alacaktır. TKPROF komutunda tanımlanan kullanıcı adının izlenen oturumun kullanıcısı ile aynı olması gerekmektedir. Sırasıyla explain kelimesini kullanmak için bir plan tablosuna gerek yoktur, TKPROF bir tane oluşturacak ve gerektiğinde kendi plan tablosunu düşürecektir.

Eğer sys=nolarak tanımlanırsa, TKPROF, SYS kullanıcısı olarak Oracle tarafından işlenen SQL komutlarını rapora dahil etmeyecektir. Bu raporu daha özlü hale getirecek ve sadece uygulama tarafından halihazırda çalıştırılan komutları içerecektir. Aslında bu idealdir, çünkü Oracle dahili SQL komutları Oracle veritabanı kernel yazılımcıları tarafından en üst seviyede optimize edilmiştir ve bizim bunlar üzerinde kafa yormamıza gerek yoktur.

Eğer “insert” kelimesi kullanılırsa bu rapora ilave olarak bir SQL scripti oluşturulacaktır. Bu SQL scripti tkprof_table adında bir tablo oluşturacak ve raporda yer alan her bir SQL komutu için bir satır ekleyecektir. Bu satır, izlenen SQL komutunun textini ve rapor içinde görünen tüm istatistiklerini içerecektir. Bu özelliği TKPROF raporunu efektif olarak veritabanına yüklemek ve istatistikleri analiz ve manipüle etmek için SQL’i kullanır. Nadiren kullanımı olsa gerektiği anlarda faydalı bir özelliktir.

Eğer “record” kelimesi eklenirse, izleme etkinken uygulama tarafından yayınlanan her bir SQL komutunun bir kopyasını içeren bir SQL scripti oluşturulur. Aslında bu bilgi TKPROF raporunun kendisindende elde edilebilir, ancak bu durumda kayıt etmek için kopyala-yapıştır gibi zahmetli işlemlere girilecektir.

“Sort”kelimesi pekçok durumda kullanışlıdır. Tipik olarak bir TKPROF raporu yüzlerce SQL komutu içerebilir, ancak pek çok durumda sadece belirli SQL komutlarını analiz etmek ihtiyacı duyulmaktadır. İşte bu durumlarda, “sort” kelimesi SQL komutlarının listesini sıralamaya izin verecek, böylece tüm dosyayı taramak zahmetine girilmeyecektir. Bazı durumlarda sort komutları işlem yapmaz, örneğin “tüketilen CPU zamanı” bazında komutlar tasnif(sort) edilmez , bunun yerine “çözümleme(parsing) için harcanan CPU zamanı” veya“satırları alıp getirme(fetching) için harcanan CPU zamanı” bazında tasnif yapılabilir. Tasnif(sort) seçenekleri aşağıda yer almaktadır.

PRSCNT Çözümleme sayısı

PRSCPU Çözümleme için harcanan CPU zamanı

PRSELAÇözümleme süresince geçen(elapsed) zaman

PRSDSK Çözümleme esnasında diskten yapılan fiziksel okuma sayısı

PRSQRY Çözümleme süresince sürekli blok okuma sayısı

PRSCU Çözümleme esnasında mevcut blok okuma sayısı

PRSMIS Çözümleme süresince library cache kayıpları sayısı

EXECNT Çalışma(execute) sayısı

EXECPU Çalışma için harcanan CPU zamanı

EXEELAÇalışma süresince geçen zaman

EXEDSK Çalışma esnasında diskten yapılan fiziksel okuma sayısı

EXEQRY Çalışma süresince sürekli blok okuma sayısı

EXECU Çalışma esnasında mevcut blok okuma sayısı

EXEROW Çalışma esnasında işlenen satır sayısı

EXEMIS Çalışma süresince library cache kayıpları sayısı

FCHCNT Fetch sayısı

FCHCPU Satırları alıp getirme(fetching) için harcanan CPU zamanı

FCHELA Satırları alıp getirme esnasında geçen zaman

FCHDSK Satırları alıp getirme esnasında diskten yapılan fiziksel okuma sayısı

FCHQRY Satırları alıp getirme süresince sürekli blok okuma sayısı

FCHCU Satırları alıp getirme esnasında mevcut blok okuma sayısı

FCHROW Alıp getirilen satır sayısı.

USERIDİmleci çözümleyen kullanıcının userid’si

Aşağıda UGUR_ora_3564.trc adlı SQL izlemesinin TKPROF ile çağrılma işlemi yer almaktadır. HR şemasının SQL komutları ile ilişkili sort seçenekleri OUT.PRF adı altında bir çıktı dosyasına yazılacak ve STOREHR.SQL adı altında bir SQL scripti oluşturulacaktır.

TKPROF UGUR_ora_3564.trc OUTPUT.PRF

EXPLAIN=hr/hr INSERT=STOREHR.SQL SYS=NO SORT=EXECPU,FCHCPU,EXECU,EXEROW,PRSDSK,FCHROW

İlave olarak, tüm izleme dosyası için bekleme olayları dosyanın sonunda özetlenir. Oturum için bekleme olaylarının izleme dosyasına yazıldığından emin olmak için aşağıdaki komut çalıştırılır.

ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';

Bu 10046 izleme olayını ilerki yazıda detaylı olarak örneklerle inceleyeceğim için bu yazıda kullanımına ve detaylarına girmeyeceğim.

Eğer bekleme bilgiside TKPROF raporunda yer alırsa, ilgili bekleme olayları TKPROF çıktısında aşağıdaki gibi bir bölümde yer alacaktır.

Event waited on Times Waited Max.Wait Total Waited

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

db file sequential read 7884 0.12 5.43

direct path write 953 0.00 0.00

direct path write temp 861 0.00 0.05

db file parallel read 12 1.61 6.12

db file scattered read 4452 0.08 1.39

direct path read 7173 0.00 0.05

direct path read temp 7201 0.00 0.46

rdbms ipc reply 27 0.00 0.04

SQL*Net message to client 2 0.00 0.00

SQL*Net message from client 2 0.00 0.00

TKPROF raporlarının okunması

Bütün TKPROF raporları; TKPROF sürümü, raporun hazırlandığı tarih ve zaman, kullanılan izleme dosyasının adı, kullanılan tasnif seçenekleri ve rapor içindeki kolon başlıklarının özet tanımını listeleyen bir başlık ile başlar ve özet istatistik serileri ile biter. Aşağıda örnek bir TKPROF başlığı yer almaktadır.

TKPROF: Release 11.1.0.7.0 - Production on Wed Apr 27 12:28:45 2011

Trace file: UGUR_ora_3564.trc

Sort options: default

***************************************************************

count = number of times OCI procedure was executed

cpu = cpu time in seconds executing

elapsed = elapsed time in seconds executing

disk = number of physical reads of buffers from disk

query = number of buffers gotten for consistent read

current = number of buffers gotten in current mode (usually for update)

rows = number of rows processed by the fetch or execute call

**************************************************************

TKPROF raporunun ana gövdesi, SQL izlemesi etkinken veritabanında çalıştırılan her bir farklı SQL komutuna ait bir girişten meydana gelir. Bir önceki cümle ile oynarken bir takım incelikler vardır. Eğer bir uygulama, mesela “müşteriler” tablosuna 50 sefer sorgu çekerse ve her seferinde farklı musteri_id değeri kullanırsa, bu durumda TKPROF raporunda 50 adet farklı giriş olacaktır. Ancak, eğer musteri_id değeri için bind değişkeni kullanılırsa, rapor içinde bu komutun 50 sefer çalıştırıldığı işareti ile birlikte sadece tek bir giriş gözükecektir. Dahada ötesinde ayrıca bu raporda, veritabanının kendisi tarafından başlatılan “tekrarlamalı işlemler” olarakta adlandırılan “data dictionary” ve “dictionary cache” gibi işlemleri uygulayan SQL cümleleride işlem sırasına göre yer alacaktır.

TKPROF raporu içindeki her bir SQL cümlesi tek satırda ardışık yıldızlarla ayrılmaktadır. Her bir girişin ilk bölümü SQL komutunu ve bu SQL komutu ile ilişkili çözümleme, çalıştırma ve satır alıp getirme istatistiklerini listeler. Aşağıda örnek bir giriş yer almaktadır.

**************************************************************

SELECT *

FROM emp

ORDER BY emp_id

call count cpu elapsed disk query current rows

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

Parse 1 0.01 0.02 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0

Fetch 14 0.59 0.99 0 33633 0 194

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

total 16 0.60 1.01 0 33633 0 194

Misses in library cache during parse: 1

Optimizer goal: CHOOSE

Parsing user id: HR [recursive depth: 0]

**************************************************************

Dosyanın içine baktığımızda; ilk satırda, SQL izlemesi etkinken uygulamanın bu komutu bir sefer çözümlediğini(parse) görüyoruz. Çözümleme işlemi için 0.01 saniyelik CPU tüketimi 0.02 saniye geçen sürede meydana gelmektedir. Buna rağmen herhangi bir fiziksel I/O ve hatta herhangi bir tampon(buffer) okuması gerekmeketedir.

İkinci satırda ise çalıştırma(execute) sayısının tek sefer olduğunu görüyüruz. Bu tek sefer çalıştırma için sistem 0.01 saniyenin altında CPU tüketmekte ve çalıştırma için geçen süre 0.01 saniye altında olmaktadır. Tekrardan, herhangi bir fiziksel I/O işlemi veya tampon okuması olmamaktadır. Burada ilginç olan nokta, çözümleme ve çalıştırma sürecinde Oracle’ın kaynakları çalıştırma yerine çözümleme esnasında kullanması ve böylece çözümleme sonrası çalıştırma tüketiminin genelde çok düşük kalmasıdır.

Bir sonraki satır, SQL komutunun 14 satır alıp getirme(fetch) işlemiyle 14 satır çağırdığını ve toplamda 194 satır aldığını göstermektedir. Bu 14 çağrı süresince toplamda 0.59 saniye CPU tüketilmiş ve işlem için geçen süre 0.99 saniye olmaktadır. Fizisel bir I/O işlemi olmamış ve sürekli okuma modunda 33,633 tampon okuması meydana gelmektedir. Diğer bir kelime ile “fetch” işleminde, tampon bellek içinde 33,633 hit olmakta ve herhangi bir kayıp meydana gelmemektedir(fiziksel I/O oluşmadığından). Ben bu sorguyu SQL*Plus üzerinden çalıştırdığımdan, tek bir “fetch”çağrısında pekçok satır alınıp getirilmesinden dolayı SQL*Plus’ın dizin arayüzü kullandığını görüyoruz.

İlk bölüm dışında kalan kısımlarda; tek bir library cache kaybının olduğunu (yani SQL komutu henüz paylaşımlı havuzda değildir), çalıştırma planının CHOOSE optimizer modu ile gerçekleştiğini, çözümleme işleminin ise HR şeması tarafından gerçekleştirildiğini gözlemliyoruz.

SQL komutlarının yinelemelerine ve library cache istatistiklerine bakarak, uygulamanın Oracle paylaşımlı SQL olanaklarına uygun olup olmadığı belirlenebilir. Bind değişkenleri kullanılıyormu veya her bir sorgu boştan çözümleme gerektiren tekil bir komutamı ait?

Çözümleme, çalıştırma ve satırları alıp getirme sayılarından, uygulamanın Oracle API’lerini düzgün şekilde kullanıp kullanmadığıda görülebilmektedir. Uygulamalar tek seferde satırları alıp getiriyormu? Uygulama, bir imleci açık bırakıp bir sonraki çözümlemeleri engelleyeceği yerde, aynı imleci yüzlerce sefer yeniden çözümlüyormu? Uygulama SQL cümlelerini PL/SQL blokları içine gömmek yerine, oldukça fazla sayıdaki basit SQL işlemlerimi gönderiyor veya dizin bind’lerini mi kullanıyor?

CPU ve I/O istatistiklerine bakarak en çok sisTem kaynaklarını tüketen komutlar gözlemlenebilir. Bazı uygulamaların yapısı yeniden geliştirilerek, daha az CPU ve I/O tüketimi olabilirmi? Az biraz tampon okumaları traşlanarak çalıştırma planında biraz rahatlama yapılabilirmi? belki komutlar olması gerektiğinden sık çalıştırılıyor, bu yinelemeler azaltılabilirmi? Bunun yanında tablolar yanlış birleştirme (join) metodu kullanıldığından dolayı sırasına göre alıp getirmesi gerekenden daha fazla satırmı işlemekte? veya birbirinin aynısı(duplicate) kayıtların çağrılması gerekmediği halde çağrılıyormu?

TKPROF raporu olduğundan uzun gözükebilir ve bakıldığında ilkel bir rapor formatına sahip olabilir, ancak çok eski sürümlerden bugünlere gelmesine rağmen bilhassa SQL komutlarının performansının geliştirilmesinde çok kritik bir öneme ve faydaya sahiptir. Her ne kadar SQL komutlarının analizi ve performansının iyileştirilmesi Oracle 11g sürümünde “advisor” lar ile otomatikleştirilmiş olsada, sistem üzerindeki yüklerin analizi ve bu bekleme olaylarına göre SQL komutlarının omurgalarının iyileştirmesinde TKPROF’a alternatif bir Oracle built-in aracı bulunmamaktadır.

Daha sonraki yazımda 10046 izleme olayının TKPROF ile entegrasyonu ve 10046 izleme sonucunda kompleks sorgularda gözlemlenen bekleme olaylarının genel veritabanı performansı üzerine etkisinin analizini işleyeceğim.

Oracle’ın gruplama konusunda ki yeteneklerinin hepimiz farkındayız. Bu makalemizde olap uygulaması kurmadan da verileri nasıl istatistiksel olarak görebiliriz bunları inceleyeceğiz. Bu amaçla Rollup ve Cube deyimlerini inceleyeceğiz.

Rollupsql ifademizde kullandığımız sütun sayısı kadar gruplama yapar. Kullandığımız kolonları sağdan sola doğru gruplar ve her grubun altına özet satırı oluşturur.

Cube ise kullandığımız sütunların tüm kombinasyonları kadar özet oluşturur.

Şimdi kısaca bunların kullanımına bakalım.

Rollup;

Genel olarak syntax’ışu şekildedir.

SELECT [column,] group_function(column). . .

FROM table

[WHERE condition]

[GROUP BY [ROLLUP] group_by_expression]

[HAVING having_expression];

[ORDER BY column];

Aşağıdakisqlcümlemizdekullandığımıztümkolonlarkadargruplamayaptık. Department_idsi 30 olankişilerintoplamlarınıaldık ve bunlarınsayısınıbelirttik.

Explain Planda oluşan costu ve adımları yukardaki şekilden görebiliriz.

Cube;

Genel syntax’ışu şekildedir.

SELECT [column,] group_function(column)...
FROM table
[WHERE condition]
[GROUP BY [CUBE] group_by_expression]
[HAVING having_expression]
[ORDER BY column];

Buradaki cube ifadesi tüm kolonlar için çaprazlama yaptığından her bir değer için sonuç oluşturmuştur.

Aynı kodu cube fonksiyonuyla yazdığımızda extra adımların geldiğini görüyoruz. Cube fonksiyonun tüm kolonlar için kombinasyonlarıoluşturdugundan datası fazla olan tablolar için nasıl extra işlem hacmi getirdiğini görmüş olduk.

Bir sonraki yazımızda dwh ortamlarında test veya development yaparken başka hangi tip gruplama fonksiyonlarını kullanabileceğimizi inceleyeceğiz.

Oracle Database 11g Sürüm 1 (11gR1) sürümü ile kullanıma sunulan SQL Performance Analyzer aracı, zayıf performans gösteren SQL komutlarının mevcut durumu ve gerekli düzeltme işlemi sonunda performanslarında meydana gelen değişimleri test ortamında kıyaslayarak, kaynak kullanımında ve çalıştırma planı maliyetinde meydana gelen olumlu/olumsuz gelişimleri okunabilir rapor formatında hazırlayarak, veritabanı yöneticilerine SQL cümlelerinin iyileştirilmesinin veritabanıüzerinde olumlu etkisini kolayca görmesini sağlanır. SQL PerformanceAnalzyer aracında kıyaslama için önceki ve sonraki olarak adlandırılan iki tür şablon kullanılmaktadır. “Önceki” kelimesinden kasıt; herhangi bir iyileştirme yapılmadan çalıştırılan zayıf SQL komutlarının mevcut durumudur. “Sonraki” ise; gerekli yapısal iyileştirme yapıldıktan sonra bu konfigürasyon değişikliğinin sistem üzerinde ne tür performans geliştirmesi yapacağının testine imkan veren bir analiz ve simülasyon metodudur.

Bu makelede, zayıf SQL komutlarının“önceki” ve “sonraki” arasındaki performans değişimlerini kıyaslama simülasyonu yer alacak ve performans değişim sonuçlarının zengin formatta raporlanması bir örnek ile yapılandırılacaktır. Oracle Enterprise Manager(OEM) grafiksel arayüzünde yer alan adım-adım sihirbazlar yardımıyla oluşturulacak olan SQL Performans Analyzer görevinde “önceki “ve “sonrası” arasındaki değişikliklerinin kıyaslama simülasyonu kolayca yapılmaktadır. Bu işlem için izlenecek adımlar aşağıda sırasıyla yer almaktadır.

Oracle veritabanındakiörnek yükü kapsayacak olan zayıf performansa sahip SQL komutlarının yakalanması(SQL Tunin setler yardımıyla).
Mevcut veritabanı sistemini kullanarak “önceki” olarak adlandırılan imajı/şablonu oluşturmak için örnek işyükünün mevcut performans etkisinin belirlenmesi.
Oracle veritabanı sisteminde yapılan yapısal değişiklik sonucunda mevcut işyükünün“sonraki” durumuna karşılık değişim göstermiş performansının test edilmesi.
Yapılan yapısal değişim sonucu hangi işyükükomponentlerinde pozitif veya negatif yönde değişim meydana geldiğinin bulunması için “önceki” ve “sonraki” arasında kıyaslamanın yapılması ,ayrıca hangi işyükükomponentleirnde değişiklik olmadığının tespiti.
Zayıf performans gösteren SQL komponentlerinin nasıl en iyi şekilde düzeltileceğinin belirlenmesi, böylece yeni ortamda bu SQL komutlarının en iyi şekilde çalışacağından emin olunması.

SQL Performance Analyzer aracının çalışmasını göstermek için, bu yazıda kullanılacak olan örnek tabloların oluşturulması ve SQL komutlarının beliritildiği adımları, “önceki” ve “sonraki” değişim simülasyonları ile birlikte aşağıdaki gibi yapılandıracağım.

1 - Simülasyon hazırlığı: Bu yazı için kullanacağım tabloları Oracle veritabanındakiörnek şemalardan biri olan OE şemasındaki objelerden türeteceğim. Bunun yanında bu tabloların güncel istatistiklerinin alınmasıda bu adımda yer alacaktır

CONN OE/OE

CREATE TABLE CUSTOMERSD AS SELECT * FROM CUSTOMERS;

CREATE TABLE ORDERSD AS SELECT * FROM ORDERS;

CREATE TABLE ORDER_ITEMSD AS SELECT * FROM ORDER_ITEMS;

CREATE TABLE PRODUCT_INFORMATIOND AS SELECT * FROM PRODUCT_INFORMATION;

--- İstatistikleri topluyoruz.---

EXEC DBMS_STATS.GATHER_TABLE_STATS(‘OE’,’CUSTOMERSD’,cascade=> true);

EXEC DBMS_STATS.GATHER_TABLE_STATS(‘OE’,’ORDERSD’,cascade=> true);

EXEC DBMS_STATS.GATHER_TABLE_STATS(‘OE’,’ORDER_ITEMSD’,cascade=> true);

EXEC DBMS_STATS.GATHER_TABLE_STATS(‘OE’,’PRODUCT_INFORMATIOND’,cascade=> true);

2 - SQL komutlarının toplanmasına hazırlık: Ardından, yukarda oluşturduğum tablolara erişim sağlamak üzere Oracle veritabanınında aşağıdaki iki adet SQL komutunu çalıştırıyorum.

select a.customer_id,a.cust_first_name||' '||a.cust_last_nameCustomer, b.order_id, b.order_total, d.product_name, c.unit_price, c.quantity,d.supplier_id

fromcustomersd a, ordersdb,order_itemsd c, product_informationd d

wherea.customer_id=b.customer_id

andb.order_id=c.order_id

andc.product_id=d.product_id

anda.customer_id=144;

select a.customer_id,b.order_date,c.order_id,d.product_name,d.list_price

fromcustomersda,ordersdb,order_itemsdc,product_informationd d

wherea.customer_id=b.customer_id

andb.order_id=c.order_id

andd.product_id=c.product_id

andc.order_id in

(select order_id

fromordersd

whereorder_status=3);

3 - “Önceki” olarak adlandırılan şablonun hazırlanması:“Önceki” olarak adlandıracağım şablonun test için hazır olmasından itibaren yukardaki SQL komutlarını içerecek olan SQL TuningTask hazırlanması işlemine geçeceğim. Ardından, bu oluşturulan SQL Tuning Set, SQL Performance Analyzer görevi içerisine eklenecek ve performans kıyaslaması için “sonraki” olarak adlandırılacak şablona karşı kullanılmak üzere SQL Performance Analyzer görevi içerisinden “önceki” larak adlandırılan adımda çalıştırılacaktır.

4 - Veritabanında yapısal değişiklik yapılması:“Sonraki” olarak adlandırdığım şablonu hazırlamadan önce veritabanında mevcut SQL komutlarının çalıştırma planını ve kaynak kullanım istatistiklerini optimize edebilecek olan iyileştirme işlemlerine geçeceğim. Bu amaçla bu noktada; üç adet indeks oluşturacağım. Bu indekslerden birisi CUSTOMERSD tablosundaki CUSTOMER_ID kolonunu indeksleyecek, ikincisi ORDER_ITEMSD tablosundaki ORDER_ID ve ORDER_STATUS kolonlarını birlikte indeksleyecektir, üçüncüsü ise PRODUCT_INFORMATIOND tablosundaki PRODUCT_ID kolonunu indeksleyecektir. Daha sonra, doğru bir çalıştırma planı oluşturabilmek için bu indeksleme yapılan tabloların istatistikleri yeniden toplanacaktır.

CREATE INDEX CUSTID_IDX ON CUSTOMERSD(CUSTOMER_ID)PCTFREE 30;

CREATE INDEX ORDITMS_IDX ON ORDER_ITEMSD(ORDER_ID,ORDER_STATUS)PCTFREE 20;

CREATE INDEX PRODID_IDX ON PRODUCT_INFORMATION(PRODUCT_ID)PCTFREE 25;

--- İstatistikleri topluyoruz.---

EXEC DBMS_STATS.GATHER_TABLE_STATS(‘OE’,’CUSTOMERSD’,cascade=> true);

EXEC DBMS_STATS.GATHER_TABLE_STATS(‘OE’,’ORDERSD’,cascade=> true);

EXEC DBMS_STATS.GATHER_TABLE_STATS(‘OE’,’ORDER_ITEMSD’,cascade=> true);

EXEC DBMS_STATS.GATHER_TABLE_STATS(‘OE’,’PRODUCT_INFORMATIOND’,cascade=> true);

5 - “Sonraki” olarak adlandırılan performans şablonunun oluşturulması: Değişikliklerin orjinalözdeş işyükünde sonuçlarını belirlemek için, SQL Performance Analyzer içerisinde “sonraki” adımında çalıştıracağım.

6 - “Önceki “ ve “Sonraki” şablonlarının sonuçlarının kıyaslaması: Son adımda ise “önceki” ve “sonraki” şablonlarında elde edilen bulgular birbiriyle kıyaslanacak ve bir rapor ile çalıştırma planı üzerilerinde değişimler, kaynak kullanım istatistikleri arasındaki değişimler pozitif ve/veya negatif yönden kolaylıkla görülebilecektir. Bu şekilde yapılacak değişimin üretim ortamına etkileri test ortamında simüle edilebilecek ve SQL komutlarının performanslarının gerçek platform için iyileştirmesi için çok etkili bir simülasyon ortamı oluşturulmuş olacaktır.

Şimdi yukarda bahsettiğim adımları Oracle Enterprise Manager(OEM) grafiksel arayüzünden adım adım uygulayalım:

1.) İlk adımda iyileştirme yapılması planlanan SQL komutlarını içerecek olan SQL Tuning Set’inin oluşturulması gerekmektedir. Bu amaçla Oracle Enterprise Manager konsolundan “Performance” tabı altında yer alan “SQL Tuning Set” linkine tıklıyorum ve alttaki ilk adım ekrana geliyor.

SQL Tuning Set oluşturmasının ikinci adımında hedef SQL komutlarının nereden yakalanacağı ile ilgili kısım yer almaktadır. “Data Source” kısmında yer alan değerler;

· AWR snapshots– otomatik iş yükü ambarında kayıtlı olan SQL komutları ile geçmişte çalıştırılan SQL komutları yakalanabilir. Ne kadar geçmişe gidileceği AWR snapshots kısmında seçilir.

· Cursor Cache – Henüz AWR raporuna yazılmamış ve önbellek içinde yer alan SQL komutları yakalanır.

Eğer imleç önbelleği içerisinden belirli zaman aralığında(duration) birden çok çalıştırılan ve imleç kullanan SQL komutları yakalanmak isteniyorsa bu durumda ilk kısım seçilmelidir. Benim örneğimde tek sefer çalıştırılan SQL komutları yüklenmek istendiğinden ben ikinci kısmı seçiyorum ve burada “Cursor Cache” seçeneğini seçip aşağıdaki gibi ilerliyorum.

Ardından hangi SQL komutlarının yakalanacağı ile ilgili filtreleme alanına gelinir. Bu alanda ilgili şemaya ait SQL komutu gibi filtreleme seçenekleri mevcuttur. Bunun yanında eğer SQL cümlesinin ID si biliniyorsa bu filtre alanına direkt bu SQL ID de belirtilebilir. Ben SQL ID yi bilmediğimden ve bu komutları OE şemasından çalıştırdığımdan aşağıdaki gibi tanımlama yapıp ilerliyorum.

BU SQL Tuning Setin hemen çalıştılıp ilgili SQL komutlarını toplamasını istediğimden bu görevin hemen çalışması için “immediatelly” kısmını işaretleyip ilerliyorum.

Son aşamada ise oluşturduğumuz SQL Tuning Set ekranda listelenir.

2.) SQL Tuning Set oluşturulduktan ve içerisine hedef SQL komutları yüklendikten sonra artık SQL Performance Analyzer aracı çalıştırılmalıdır. SQL Performance Analyzer aracıda ana konsoldaki “Performance” tabı altından çalıştırılmaktadır. Ekranda gözüken “GuidedWorkflow“ ile “önceki” ve “sonraki” performans kıyaslaması işlemine başlayacağız. Bu aşamada yer alan diğer seçenekler ile ilgili makaleleri ilerleyen zamanlarda yayınlayacağımdan bunların ne anlama geldiği konusuna girmiyorum.

“GuidedWokflow“ ile aslında Oracle tüm aşamaları iş akışı şeklinde adım adım basite indirgenmektedir. İlk sıradaki görevin yanındaki “Execute” sembolüne tıklayarak işleme başlıyorum.

Oluşturacağım SQL Performance Analyzer görevine DEMO SPA adını veriyorum, SQL Tuning Set bölümü altında bir önceki adımda oluşturduğum SQL Tuning Setini tanımlayarak “CREATE” komutu ile bir sonraki adıma ilerliyorum.

Bir sonraki aşamada mevcut ortamda SQL denemesini oluşturuyorum. Bu kısımda önemli olan nokta CreationMethod ve Per-SQL Time Limit kısımlarıdır. “CreationMethod” kısmında; çalıştırılan SQL komutunun lokalortamdamı yoksa uzak bir makinede varsayımı ile simulasyonu yapılacağı, veya lokal veya uzak makine varsayımı ile SQL komutunun çalıştırma planı simülasyonumu yapılacak, yoksa hem SQL komutu çalıştırma planı hemdeçalışma esnasında kaynak kullanımı ile ilgili detay istatistikleme simülasyonu yapılacak gibi seçenekler yer alır. “Execute SQLslocally” ile lokalveritabanındaçalıştırılan SQL komutlarının hem kaynak kullanımı detayları istatistiki olarak simüle edilmekte, hemdeçalıştırma planı detayları bu simülasyona dahil edilmektedir. “Per-SQL Time Limit” kısmı ise bu test ortamında yüklü SQL komutunun ne kadar süre deneme simülasyonunda tutulacağını belirtir. Aşağıdaki seçenekler ile ilerliyorum ve “önceki” olarak adlandırılan şablonu hazırlamış oluyorum.

*** Bu aşamada karşınıza gelen ekranın sağ alt kısmındaki “Trial environmentestablished” seçeneğini tıklamayı unutmayın. ***

Bir sonraki aşamaya geçmeden önce mevcut veritabanı ortamında değişiklik yapıyorum ve bu aşamada ilgili indeksleri oluşturup, gerekli istatistikleri yeniden topluyorum(bakınız 4. adım Veritabanında yapısal değişiklik yapılması) Bu işlem sonunda aşağıdaki gibi üçüncü görev alanınında“execute” sembolüne tıklayarak, “sonraki” olarak adlandırılan şablonun oluşturulması işlemine geçiyorum.

“Sonraki” kısmındaki tanımlamalarım “önceki” aşamasındaki ile aynıdır.

Bir sonraki aşamada “önceki” ve “sonraki” aşamalarının kıyaslaması işlemi yapılacaktır, alttaki gibi ilerliyorum.

Kıyaslama metodu için kullanılacak kıstası belirliyorum. Bu kıyaslama metrikleri aşağıda yer almaktadır. Ben bu örnekte “buffergets“ kıstasını kullanacağım. Rapor alındıktan sonra diğer metrikler içinde kıyaslama raporu alınabilmektedir.

Elapsed Time - SQL komutunun ne kadar sürede tamamlandığı

CPU Time - Bu komut için İşlemci çalışma zamanı

User I/O Time - Bu işlem için I/O süresi

BufferGets - Bu komut sonuçseti için önbellekten alınan veri miktarı

Physical I/Os - Bu komut sonuçseti için fiziksel diskten alınan veri miktarı

OptimizerCost - İyileştirici maliyeti

I/O interconnectbytes - Cluster ortamı için düğümler arası bağlantılarda transfer olan veri miktarı

Son aşamada deneme ortamında kıyaslama raporunu alacağım.

Aşağıdaki gibi bu SQL Performance Analiz görevinde oluşturulan kıyaslama raporu görülmektedir. Gerekli iyileştirmeler sonucunda perfromansın iyileştiği “Improved” grafiğindende görülmektedir.

Örnek SQL cümlelerinden birisinin SQL ID si üzerine tıklayarak bu SQL cümlesi ile ilgili çalıştırma planı istatistiklerini “önceki” ve “sonraki” olarak ayrı ayrı görebilmekte olup aradaki değişimin etkisini yüzdesel olarakta görebilmekteyiz.

Bunun yanında “önceki” ve “sonraki” test ortamlarının simülasyon edilmiş çalıştırma planları aşağıda yer almaktadır. İndekslerin sisteme eklenmesi sonucunda cost değerinde bir azalma meydana gelmiştir.

Bir sonraki makalede, SQL Performance Analyzer aracı kullanarak Oracle başlangıç parametrelerinde yapılacak değişiklikler ile SQL komutlarında meydana gelecek değişimlerin “önceki” ve “sonraki” kıyaslama simülasyonunu adım adım yapılandıracağız.

Oracle veritabanları büyük ölçekli firmalarda genellikle coğrafik olarak farklı bölgelere dağıtılmıştır, böylece Oracle veritabanları uzmanları için veritabanının network bağlantılarından nasıl etkilendiğinin anlaşılması önemli bir görev olmaktadır. Oracle tarafından sağlanan Transparent Network Substrate(TNS), veritabanları arasında dağıtık bağlantılara izin vermektedir.

Dağıtık işlemlerin performansı bu yazıda yer alan bazı değişiklikler ile arttırılabilecektir. Bu değişiklikler sqlnet.ora, tnsnames.ora ve protocol.ora dosyaları içindeki parametreler olacaktır. Bu parametreler, konfigürasyonu ve TCP paketlerinin boyutunu değiştirmek için kullanılır. Bu parametrelerin ayarlanmasının, tüm Oracle işlemlerinin çıktısını geliştirmek için, temel network taşıma katmanı üzerinde çok yoğun bir etkisi vardır.

Oracle Net, veritabanı uzmanlarına temel network ayarlarını iyileştirebilecek yeterliliğe izin vermez ve network trafiğinin çoğunluğu Oracle yapısı içerisindende iyileştirilmez. Çünkü Oracle Net, OSI modeli içinde network spesifik protocol yığını üstünde bulunur.

Network paketlerinin sıklığı ve büyüklüğü Oracle DBA tarafından kontrol edilir. Oracle, paket sıklığı ve büyüklüğünü değiştirmek için zengin araçlara sahiptir. Network üzerinden paket taşımasının sıklığı ve büyüklüğü, aşağıdaki parameter dosyaları içinde yer alan ayarları kullanılarak etkilenir:

· protocol.ora dosyası - tcp.nodelay parametresi

· sqlnet.ora server dosyası - automatic_ipc parametresi

· tnsnames.ora ve listener.ora dosyaları - SDU ve TDU parametreleri

protocol.ora dosyası içindeki tcp.nodelay parametresi

Oracle Net, varsayılan olarak verinin iletilmesinden önce tampon dolana kadar bekler. Bu yüzden, talepler hedeflerine her zaman anında gönderilmemektedir. Bu olay, çoğu zaman büyük miktarda verilerin bir sondan bir diğerine akıp gittiği zamanda yaygın bir olaydır ve Oracle Net tampon dolana kadar paketleri işlemez. protocol.ora dosyası eklemek ve tampon taşıma gecikmelerini durdurmak için tcp.nodelay değerinin belirtilesi bu sorunun üstesinden gelebilir.

protocol.ora dosyası tüm TCP/IP yapılandırmaları için veri tamponlamasının olmamasını göstermek için belirtilir. Bu parameter, hem istemci hemde sunucu üzerinde kullanılabilir. protocol.ora içinde bu parametrenin kullanımı:

tcp.nodelay = yes

Bu paramerenin tanımlanması TCP tamponlamanın es geçilmesine sebep olur, böylece tüm talepler hemen ve anında gönderilir. Ancak unutmamak gerekirki, network trafiği daha küçük ama sık paket işlemesi sebebiyle artar, bu da networkte ağırlaşmaya sebep olur. tcp.nodelay parametresi, sadece TCP zaman aşımı ile karşılaşıldığı zamanlarda kullanılmalıdır. tcp.nodelay parametresinin ayarlanması, veritabanı sunucuları arasında yüksek hacimde trafik olduğunda performansı aşırı oranda geliştirmeye sebep olabilir.

Sqlnet.ora dosyasındaki “automatic_ipc” parametresi

automatic_ipc parametresi network katmanını atlar, böylece veritabanına local bağlantıları hızlandırır. automatic_ipc değeri ON olarak ayalandığında, Oracle Net local veritabanının aynı alias ile belirtilip belirtilmediğini kontrol eder. Eğer aynı alias ile belirtilmişse, bağlantı direkt olarak local IPC bağlantılarına çevrildiğinden network katmanları atlanır. Bu veritabanı sunucuları için kullanışlıdır, ancak Oracle Net istemcileri için kesinlikle gereksizdir.

automatic_ipc parametresi sadece Oracle Net bağlantısının local veritabanına yapılması zorunlu olduğu durumlarda kullanılmalıdır. Eğer lokal bağlantılar gerekmezse veya zorunlu değilse, bu parametrenin değerinin OFF olarak ayarlanması gerekir ki böylece tüm Oracle Net istemcilerinin performansı artar.

tnsnames.ora dosyası içindeki SDU ve TDU parametreleri

Oturum veri birimi(SDU) ve taşıma zaman birimi(TDU) parametreleri tnsnames.ora ve listener.ora dosyaları içinde yer alır.

Oturum veri birimi(SDU), network üzerinden veriyi göndermeden önce SQL*Net ‘in veriyi tampona almasıdır. SDU, tampon dolu olduğunda veya uygulama veriyi okumaya çalıştığında, veriyi bu tamponda saklanmak üzere gönderir. Büyük miktarda veriler alınırken ve paket büyüklüğü sürekli aynı olduğunda, varsayılan SDU büyüklüğünü genişletmek için alım hızını artırabilir. En uygun SDU büyüklüğü normal paket büyüklüğüne bağlıdır. Bir sniffer ile frame büyüklüğü bulunabilir veya izleme işlemi gönderilen ve alınan paket sayılarını kontrol etmek için en yüksek seviyeye ayarlanabilir, ve fragmente olup olmadıkları görülebilir. Fragmentasyonun miktarını sınırlandırmak için sistem iyileştirilmelidir. Bunun için bir formül olmadığından dolayı farklı büyüklükte tamponlar ile denemeler yapılması gerekmektedir. Varsayılan SDU büyüklüğü 2,048’dir ve 512 ile 32K arasında genişletilebilir.

SDU büyüklüğü hem istemci hemde sunucu tarafında ayarlanmalı ve genelde aynı olmak zorundadır. Eğer istemci ve sunucu tarafında farklı büyüklükte SDU büyüklüklerine gereksinim duyulursa, SDU büyüklüğünün iki alt aşağı seviyede olması şeklinde düzenlenebilir.

İdeal olarak SDU büyüklüğü MTU büyüklüğünü aşmamalıdır. MTU, kullanılan network yapılandırmasına bağlı olan bir sabit değerdir. Oracle, SDU büyüklüğünün MTU ile aynı değerde ayarlanmasını tavsiye etmektedir. SDU büyüklüğü, normal taşıma frame büyüklüğünün katı olarak ayarlanmalıdır.Ethernet frame büyüklüğünün günümüzde en az 1,024 olmasından itibaren, Ethernet protokolu üzerinden en verimli SDU büyüklüğü 1,024 ün katı olmalıdır, ancak 1,024 toplamının dört katından fazla olmamalıdır.

TDU, verileri birlikte gruplamak için Oracle Net içinde kullanılan varsayılan paket büyüklüğüdür. TDU parametresi ideal olarak SDU parametresinin katı olmalıdır. Hem SDU hemde TDU’un varsayılan değeri 2,048 dir ve maksimum değeri ise 32,767 byte’dır.

SDU ve TDU için geçerli kılavuz noktalar aşağıda yer almaktadır:

1. SDU hiç bir zaman TDU’dan büyük olmamalıdır çünkü her bir paket içinde gerksiz alanın taşınmasıyla network kaynakları gereksiz yere kullanılır.

2. Eğer kullanıcılar modem hatları üzerinden bağlanıyorsa, SDU ve TDU değerlerinin, modem hatları üzerinden meydana gelen çok sık yeniden göndermeler yüzünden daha küçük değerlere düşürülmesi istenebilir.

3. Hızlı network bağlantılarında(T1 ve T3), SDU ve TDU büyüklüğünü MTU ile aynı değere ayarlamak gerekmektedir. Standart ethernet networklerde varsayılan MTU büyüklüğü 1,514 bytes’dır.

4. Eğer Multi-Threaded Server (MTS) kullanılıyorsa, mts_dispatchers değeri düzgün bir MTU TDU yapılandırmasıyla ayarlanmalıdır.

SDU ve TDU ayarları hostlar arasındaki bağlantı hızı direkt fonksiyonudur. Hızlı T1 hatlarda SDU=MTU=TDU şeklinde ayarlama yapılmalıdır.

Aşağıdaki örnek, 4,202 bytes MTU değerine sahip T2 networkü için yapılan parametre değerleridir..

tnsnames.ora dosyası:

ARDA =
(DESCRIPTION =
    (SDU=4202)
    (TDU=4202)
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = LINUX1)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SID = ARDA)
      (SERVER=DEDICATED)
    )
)

listener.ora dosyası:

   SID_LIST_LISTENER =
      (SID_LIST =
        (SID_DESC =
          (SDU = 4202)
          (TDU = 4202)
          (SID_NAME = ARDA)
          (GLOBAL_DBNAME = ARDA)
        )
      )

SDU büyüklüğü aşağıdaki durumlarda yeniden düzenlenmelidir:

· Sunucudan geri gelen veriler farklı paketlere fragmente olduğunda.

· Uzun gecikmelerin olduğu WAN bağlantıları içinde bulunulduğunda.

· Paket büyüklüğü devamlı aynı olduğunda.

· Büyük miktarlarda veri döndüğünde.

· SQL*Net tabanlı bekleme olayları içinde “more data from/to” tipi bekleme olaylarının çok büyük ortalama oranlarıyla sık sık meydana geldiği gözlemlendiğinde.

SDU büyüklüğü aşağıdaki durumlarda değiştirilmemelidir:

· Uygulama gecikmelerini yakalamak için iyileştirilmesi gereken durumlarda.

· Uygulama sunucusunda meydana gelen bu gecikmeler, aslında “SQL*Net message from client” bekleme olayının büyük ortalama oranlarında sık sık meydana gelmesi ile tespit edilebilmektedir. Bu durumda, Oracle sunucusundan uygulama sunucusuna gönderilen veri paketleri aynı hızda uygulama sunucusundan geri alınamamakta ve bu bekleme olayı meydana gelmektedir.

· Data işleme etkisinin önemsiz ve göz ardı edilebilir olduğu yüksek hızda networka sahip olunduğu durumlarda

· İstemci taleplerinin sunucudan küçük miktarlarda veri döndürdüğü durumda

Aşağıdaki eylemlerden birisi uygulanmadığı takdirde, Oracle veritabanı instance!ları otomatik olarak listener.ora dosyasına kayıt eder:

· Otomatik servis kaydının devre dışı olduğu durumda. Bunu yapmak için local_listener adlı init.ora parametresinde, listener.ora dosyasında tanımlananTCP portundan başka bir portun ayarlanması gerekmektedir.

· MTS uygulandığında ve aşağıdaki örnekteki gibi init.ora dosyasındaki mts_dispatchers parametresi tanımlanmadığında:

MTS_DISPATCHERS="(DESCRIPTION=(SDU=8192)(TDU=8192)
ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)(HOST=linux1)))
(DISPATCHERS=1)"

· tnsnames.ora dosyasının connect_data bölümünde service_name=global_dbname kullanıldığında. Bu ayar, global_dbname kullanımının desteklenmediği TAF kullanımını devredışı bırakacaktr.

Listener yük dengelemesinin kullanılması

Listener yük dengelemesi, sunucuya pek çok bağlantı talebinin olduğu durumlarda kullanışlıdır. Bu talepleri karşılamak için birden fazla listenera sahip olarak, tekil bir listener üzerindeki sorumluluk azaltılır ve bağlantı hızı artar. Listener yük dengelemesi ayrıca replike sunucular için dinleme yapan birçok listener olan çoklu sunucu ortamında oldukça kullanışlıdır.

Problemin tespiti

Aşağıdaki sorgu, sunucu veya istemci için ortalama bekleme süresinin, ayrı ayrı sunucu veya istemciden bir mesaj için bekleme süresine bağlı kaydının, Oracle perspektifinden, network performansı belirleme metodunu göstermektedir.

select event, average_wait
from v$session_event

where event in ('SQL*Net message from client','SQL*Net message to client', 'SQL*Net more data to client', 'SQL*Net more data from client') and average_wait > 0;

Bunun yanında STATPACK raporlarından geçmiş ile ilgili aynı veriye erişmek için aşağıdaki sorgu oldukça kullanışlıdır ve Oracle 9i ve Oracle 10g veritabanlarında sorunsuzca çalışmaktadır.

select

to_char(snap_time,'yyyy-mm-dd HH24') mydate,

e.event,

e.total_waits - nvl(b.total_waits,0) waits,

((e.time_waited_micro - nvl(b.time_waited_micro,0))/100) /

nvl((e.total_waits - nvl(b.total_waits,0)),.01) avg_wait_secs

from

stats$system_event b,

stats$system_event e,

stats$snapshot sn

where

e.snap_id = sn.snap_id

and

b.snap_id = (e.snap_id-1)

and

b.event = e.event

and

e.event like 'SQL*Net%'

and

(e.total_waits - b.total_waits )> 100

and

(e.time_waited_micro - b.time_waited_micro) > 100

order by 1 desc;

Aşağıdaki sorgu istemci ve sunucu için ortalama bekleme süresini ve fiilen transfer edilen bytes’ları göstermektedir.

select v$sesstat.sid, substr(v$session_event.event,1,30) "Event",v$SESSION_EVENT.AVERAGE_WAIT "Avg Wait",

v$sesstat.value "Bytes",substr(v$session.program,1,20) "Program"
from v$session_event,v$session_wait, v$sesstat, v$session,v$statname
where v$session_wait.event in ('SQL*Net message from client','SQL*Net message to client','SQL*Net more data to client','SQL*Net message from dblink')
and v$session_wait.event=v$session_event.event
and v$session_wait.sid = v$sesstat.sid
and v$session_wait.sid = v$session_event.sid
and v$statname.statistic#=v$sesstat.statistic#
and v$statname.name like 'bytes%'
and v$sesstat.value > 0
and v$session.sid = v$sesstat.sid
and V$SESSION_EVENT.AVERAGE_WAIT > 100;

       SID Event                      Avg Wait Bytes Program
---------- ------------------------ ---------- ------- -----------
        18 SQL*Net message from cli    1458         19 MVXLAWSN.exe
        18 SQL*Net message from cli    1458        150 MVXLAWSN.exe
        18 SQL*Net message from cli    1458          4 MVXLAWSN.exe
        18 SQL*Net message from cli    1458      11122 MVXLAWSN.exe
        18 SQL*Net message from cli    1458     274712 MVXLAWSN.exe
        18 SQL*Net message from cli    1458     143896 MVXLAWSN.exe
        18 SQL*Net message from cli    1458 1114450960 MVXLAWSN.exe
        18 SQL*Net message from cli    1458 1114450960 MVXLAWSN.exe
        18 SQL*Net message from cli    1458         76 MVXLAWSN.exe
        18 SQL*Net message from cli    1458         76 MVXLAWSN.exe
        14 SQL*Net message from cli    5510         31 service.exe
        14 SQL*Net message from cli    5510         77 service.exe
        14 SQL*Net message from cli    5510      22912 service.exe
        14 SQL*Net message from cli    5510     145648 service.exe
        14 SQL*Net message from cli    5510        111 service.exe
        14 SQL*Net message from cli    5510         77 service.exe

Oracle tarafından network iyileştirmesindeki tüm mesele networkun münkün olduğunca küçük miktarlarda kullanılmasıdır. Muhtemelen en önemli faktör SQL komutlarının işlemler içinde gruplandırılması olacaktır. Örneğin; 10 satır alıp getirilecekse(fetch), bu on satır için tek bir talebin gönderilmesi, her bir satır için on talep gönderilmesinden daha verimli ve efektif olacaktır. Networkun veritabanı sunucusundan veya istemci makineden daha yavaş olmasından itibaren, bu yaklaşım önemlidir.

Bunun yanında STATSPACK snapshotları arasındaki değişimlerin(delta değerlerinin) izlenmeside pek çok SQL*Net tabanlı bekleme olayının iyileştirilmesinde genel reime bütün olarak bakabilmek noktasında faydalı olmaktadır. Aşağıdaki örnekte 44050 ve 44125 numaralı snapshotlar arasındaki SQL*Net tabanlı bekleme olaylarının değişimleri yer almaktadır. Örnekte sıkıntı yaşanan alanın “SQL*Net message from client” bekleme olayı olduğu yüksek delta değerlerinden anlaşılmaktadır. bu noktada, uygulama sunucusu veritabanı sunucusundan aldığı veri paketlerini aynı hızda işleyememekte ve bu noktada bu uygulama sunucusunda paket cevaplarında gecikmeler meydana gelmektedir.

SELECT s1.snap_time,

w1.event,

s1.snap_id,

w1.total_waits,

LAG(w1.total_waits)

OVER (ORDER BY w1.total_waits) prev_val,

w1.total_waits - LAG(w1.total_waits)

OVER (ORDER BY w1.total_waits) delta_val

FROM stats$snapshot s1,

stats$system_event w1

WHERE s1.snap_id BETWEEN 44100 AND 44125

AND s1.snap_id = w1.snap_id

AND w1.event in ('SQL*Net message from client','SQL*Net message from dblink', 'SQL*Net more data from client')

ORDER BY w1.event, s1.snap_id;

SNAP_TIME EVENT SNAP_ID TOTAL_WAITS PREV_VAL DELTA_VAL

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

19-July-2011 SQL*Net message from client 44110 21053209911 61434967 20991774944

19-July-2011 SQL*Net message from client 44115 21058681336 21053209911 5471425

19-July-2011 SQL*Net message from client 44116 21062289324 21058681336 3607988

19-July-2011 SQL*Net message from client 44125 21068495873 21062289324 6206549

19-July-2011 SQL*Net message from dblink 44110 61434121

19-July-2011 SQL*Net message from dblink 44115 61434967 61434121 846

19-July-2011 SQL*Net message from dblink 44116 61434967 61434967 0

19-July-2011 SQL*Net message from dblink 44125 61434967 61434967 0

Ayrıca, geçici olarak yüksek seviye izlemeyi ayarlamak için sqlnet.ora dosyasındada düzenleme yapılmalıdır, böylece o an kullanımda olan ne kadar “pipeline” büyüklüklerinin olduğu görülebilir. Aşağıda bununla ilgili düzenlemenin olduğu örnek yer almaktadır:

                trace_level_client=16
                trace_directory_client=/u01/app/oracle/admin/network
                trace_file_client=client.trc
                trace_unique_client = true

                trace_level_server=16
                trace_directory_server=/u01/app/oracle/admin/network
                trace_file_server=server.trc

Bu, basit bir SQL*Plus oturumu oluşturup kullandığından dolayı uçsuz bucaksız miktarlarda verinin izleme dosyalarına üretilmesine sebep verir. Bir çift izleme dosyası üzerinden tarama yapılırsa, açık bir IPC bağlantısıyla ve multi-threaded sunucunun çalışmadığı izleme dosyasından aşağıdaki gibi satırlar bulunacaktır.

      ntc=0x7308
                nsconneg: vsn=309, gbl=0x801, sdu=32640, tdu=32767
                nsconneg: normal exit

Bu sunucu ve istemci arasında kullanılacak SDU yu belirlemek için yapılan düzenlemenin bir parçasıdır. İlk bölümde istemci tarafından geçilen bağlantı verisi görülür, ikinci bölümdeki satırlarda ise ne yapılacağı ve nasıl bir düzenlemeye ulaşıldığı ile ilgili sunucu raporları yer almaktadır. Buradaki nsconneg,Network Substrate CONnection NEGotiation(Ağ Yüzey Bağlantı Düzenlemesi) anlamına gelir.

Varsayılan kurulumda, SDU muhtemelen 32,640 yerine 2,048 olacaktır.Ayrıca, iki nsconneg satırının SDU için iki farklı değeri gösterdiği görülmektedir, istemci ve sunucu tarafında ne yapacakları hakkında bilgi. Sonuç bölümü ise her iki teklifin düşürülmesidir.

Onaylama:

SQL Net izleme dosyasından SDU büyüklüğünün beklenen değerde ayarlanmasının görülmesinin yanında, “pipeline” büyüklüklerini büyülten oturumları belirlemek için diğer bir alternatif ise Unix ps komutudur

ps -ef | grep oracleSID

oracle 2324 1 0 19:49:40 ? 0:01 oracleD734

(DESCRIPTION=(LOCAL=NO)(SDU=32640))
oracle 2327 2318 12 19:50:09 pts/2 0:00 grep oracleD

Network ayarlarının düzenlenmesi

1. Network adaptor ayarlarının değiştirilmesi

Network adaptörlerinin hızını ve ayarlarını kontrol etmek için ethtool komutu kullanılabilir. Aşağıda eth0 network arayüzünün ayarları konrol edilir:

# ethtool eth0

Hızı 1000 full duplex olarak değiştirmek için;

# ethtool -s eth0 speed 1000 duplex full autoneg off

Hız değişikliğini eth0 için kalıcı olarak ayarlamak için /etc/sysconfig/network-scripts/ifcfg-eth0 dosyasına ETHTOOL_OPT değişkeninin eklenmesi gerekmektedir.Bu şekilde network servisinin her başlatılmasında network scriptleri içerisine bu ortam değişkeni eklenecektir.

ETHTOOL_OPTS="speed 1000 duplex full autoneg off"

2. Kernel ayarlarının değiştirilmesi

Oracle instanceler arasında cache fusion tampon transferleri gibi süreçlerarası bağlantılar için varsayılan olarak UDP protokolünü kullanmaktadır. Ancak, Oracle 10g itibariyle network ayarları standalone veritabanları içinde ayarlanmalıdır.

Oracle varsayılan ve maksimum gönderme tampon büyüklüğünü (SO_SNDBUF soket seçeneği) ve alım tampon büyüklüğünü (SO_RCVBUF soket seçeneği) 256 KB olarak ayarlanmasını tavsiye etmektedir. Okuma esnasında uygulama için alınan veriyi tutmak için TCP ve UDP ile alım tamponları kullanılır. Bu tampon dışa taşmaz, çünkü gönderim partisinin bu veriyi tampon boyut penceresi ötesinde göndermesine izin verilmez. Bu demektir ki, datagramlar alım tamponu içine sığmazsa iptal edilecektir.Bu da göndericinin alıcıyı ezmesine sebep verecektir.

Varsayılan ve maksimum pencere büyüklükleri sistemi yeniden başlatmaya gerek kalmadan proc dosyası içinden değiştirilebilir:

# sysctl -w net.core.rmem_default=262144 # Soket alım tamponunun bytes değerinden varsayılan değeri

# sysctl -w net.core.wmem_default=262144 # Soket gönderim tamponunun bytes değerinden varsayılan değeri

# sysctl -w net.core.rmem_max=262144 # SO_RCVBUF soket seçeneğini kullanarak maksimum soket alım tampon büyüklüğü ayarlanabilir

# sysctl -w net.core.wmem_max=262144 # SO_RCVBUF soket seçeneğini kullanarak maksimum soket gönderim tampon büyüklüğü ayarlanabilir

Değişikliklerin bir sonraki sistem açılışlarında da kalıcı olmasını sağlamak için aşağıdaki satırlar /etc/sysctl.conf dosyası içine eklenir:

net.core.rmem_default=262144

net.core.wmem_default=262144

net.core.rmem_max=262144

net.core.wmem_max=262144

RAC platformunda failover performasını geliştirmek için aşağıdaki IP kernel parametrelerini değiştirmeyi iyice gözönünde bulundurmak gerekir. Bu parametrelerin optimal ayarları ile ilgili bilgi almak için Metalink Note:249213.1 ve Note:265194.1 bakabilirsiniz.

net.ipv4.tcp_keepalive_time

net.ipv4.tcp_keepalive_intvl

net.ipv4.tcp_retries2

net.ipv4.tcp_syn_retries

Red Hat Linux sistemlerde 9i ve 10g için TCP ve UDP trafiğinde kullanılmasına izin verilen port aralığı çok kısıtlıdır. Bu ayarlar aşağıdaki gibi değiştirilerek bu sıkıntının önüne geçilebilir.

# sysctl -w net.ipv4.ip_local_port_range="1024 65000"

Bu değişikliği kalıcı olarak ayarlamak için aşağıdaki satır /etc/sysctl.conf dosyası içine eklenmelidir.

net.ipv4.ip_local_port_range=1024 65000

3. e1000 NIC ler için akış kontrolü

e1000 NIC ler 2.6 kernel sistemlerde(mesela RHEL 4) akış kontrol etkin değildir. Eğer ağır bir trafik varsa, bu durumda RAC interconnect bağlantılarda blok kayıpları olabilir(bakınız Metalink Bug:5058952).

e1000 NIC ler için alım akış kontrolünü etkinleştirmek için aşağıdaki satır /etc/modprobe.conf dosyası içerisine eklenir:

options e1000 FlowControl=1

Umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek dileği ile esen kalın.

Bu makalemizde Oracle 11gR2’nin Windows Server 2008R2 işletim sistemi üzerine kurulum işlemlerini göreceğiz. Oracle 11gR2 ile gelen yenilikler aşağıdaki gibi gözümüze çarpmaktadır.

Automatic BlockRepair: Bu özellik sayesinde blockcorruption işi otomatikleştirilmiş oluyor.

DuplicateWithout Connection to Target Database:Target database bağlanmadan catalogyadaaux database bağlanarak duplicateözelliği.

EnhancedTablespace Point-In-Time Recovery (TSPITR): Geliştirilmiş tablespacepoint in time recovery. Drop edilmiş bir tablespace bile recover edebiliyoruz. Aynı tablespace birçok defa recover edebilme imkanı bu özellik sayesinde gelmiştir.

Diğer gelen yeni özellikler için, http://docs.oracle.com/cd/E11882_01/server.112/e10881/chapter1.htmlintekidökümanı inceleyebilirsiniz.

Öncelikle oracle sitesindeki kuracağımız versiyonunudownload ediyoruz. http://www.oracle.com/technetwork/database/enterprise-edition/downloads/112010-win64soft-094461.html Download için oracle sitesinde bir account oluşturmalısınız.

Kurulum işlemine Intel Core2 cpu, 1,5 GB Ram, regional settings ayarlarım english ve localadministrator yetkisi ile birlikte başlıyoruz. Setup.exe’yeçift tıkladığınızda ve biraz beklediğinizde karşımıza aşağıdaki gibi bir ekran gelmektedir.

Email adresinizi ve oraclesecurityupdateleri indirebilmek ve bunlardan haberdar olabilmek için oraclesupportşifrenizi isteyen ekran bizi karşılamaktadır. Bu kısımdaki bilgileri daha sonrada girebilmektesiniz. Ben boş bırakıp next tuşu ile ilerliyorum.

Boş bıraktığımıza dair bir uyarı mesajı gelmektedir. Bu kısmı geçebilmek için Yes ve sonrasında Next tuşuna tıklayarak ilerleyebilmektesiniz.

Gelen ekranda karşımıza 3 adet seçenek çıkmaktadır.

Create and configure a database: Yeni veritabanı oluşturmaya ve rdbmssoftware kurulumunu yapar. Rdbms nedir peki? Yüksek datalara hızlı şekilde erişim sağlayan ve güvenli şekildiği tutulduğu platformdur.

Install database software only: Sadece Rdbms software kurulumunu yapar.

Upgrade an existing database :Varolan database upgrade işlemi için kullanılmaktadır.

Biz ilk defa kurulum işlemi yaptığımız için, birinci seçenği işaretleyip devam ediyoruz.

Hangi sınıf üzerine kurulum işlemi yaptığımızı belirtmeliyiz.

Desktop Class: Kişisel desktoppc ya da notebooka kurulum yapıyorsanız bunu seçmelisiniz.

Server Class: Server işletim sistemi üzerine kurulum yapıyorsanız bunu seçmelisiniz.

İki seçenek arasında konfigürasyon farklılığı bulunmakatadır. Biz serverclass seçeneğini seçip ilerliyoruz.

Database kurulum tipini seçtiğimiz kısım karşımaza gelmekte.

Singleinstance database installation: Tek bir database kurulumu yapacaksanız seçeceğiniz adım.

Real Application Clusters database installation: RAC kurulumu yapacaksak seçeceğimiz kısım.

RAC kurulumu yapmadığımız için, Singleinstance database installation seçeneği ile ilerliyoruz.

DB versiyonu, lokasyonunu, Global Database Name, password işlemlerini kendim belirlemek için advancedinstall kısmını seçip ilerliyorum. Siz dilerseniz, typical seçeneği ile de ilerleyebilirsiniz. İlgili seçeneği işaretleyip, next ile bir sonraki adıma geçiyoruz.

Kurulum dilini seçip, bir sonraki adıma ilerliyoruz.

Bu adımda kurulum için seçebileceğiniz versiyon tipleri bulunmaktadır. Seçmiş olduğunuz versiyona göre select options kısmından ek componentleri kurabilmektesiniz. Enterprise Edition seçeneğini işaretleyip, bir sonraki adıma geçiyorum.

Bu adımda Oracle kurulum dosyalarının ve base dosyalarının ( tns gibi ) nereye atılacağı kısmı seçip, next ile ilerliyoruz.

Oluşturacağımız veritabanının ne amaçla kullanılacağını bu kısımda seçmeliyiz.

General Purpose / TransactionProcessing: OLTP veritabanı kurulumu için seçilecek kısım. Oltp, database içindeki verilerin, birçok kişi tarafından kullanılabilmesidir. Giriş, silme, güncelleme vb. İşlemlerin aynı anda yapılması. Ayrıca oltpveritabanı içindeki verileri düzenlemekle birlikte, dbhızınında artırılmasını sağlar.

Data Warehousing: Veri ambarı tarzından bir database kurulumu için kullanılır.

Biz birinci seçeneğini işaretliyerek, next ile ilerliyoruz.

Oluşturacağımız database adını ve SID bilgilerini gireceğimiz bölümdür. Bu bilgilerin ikisini de aynı yazabileceğiniz gibi, farklı da yazabilirsiniz. Next ile bir sonraki adıma ilerliyoruz.

Memory tabında,Enable Automatic Memory Management seçeneğini işaretleyerek, otomatik bellek yönetimini açıyoruz. Bunun faydası kaynağı (ram) daha etkili, verimli ve yeterli kullanması için seçmemiz gerekmektedir.

Diğer önemli kısım ise Charectersets tabıdır.

Kullanacağınız karakter setini seçmelisiniz. Bunun önemi database’e sorgu gönderirken önem taşımaktadır. Oracle’da TR karakterlerin okunup yazılabilmesi için yukarıdaki gibi seçip ilerliyoruz.

Eğer bu seçeneği seçmeyi unuttuysanız daha sonra database’e bağlanarak aşağıdaki komutlarla değişimi yapabilirsiniz.

CONNECT / AS SYSDBA
SHUTDOWN IMMEDIATE
STARTUP MOUNT;
ALTER SYSTEM ENABLE RESTRICTED SESSION;
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
ALTER SYSTEM SET aq_tm_processes=0;
ALTER DATABASE OPEN;
UPDATE sys.props$ SET VALUE$=’TURKISH_TURKEY.WE8ISO8859P9′
WHERE name=’NLS_CHARACTERSET’;
COMMIT;
SHUTDOWN IMMEDIATE;
STARTUP;

Database control tarafında e-mail ile bilgilendirilme işlemini yaptığımız kısımdır. Eğer smtpserverınız varsa, bu bilgileri girerek yapılandırabilirsiniz. Ben e-mail bilgilendirmesi istemediğim için next ile ilerliyorum.

Bu kısımda database dosyalarımızın lokasyonunu ve file system kullanacağımızı seçerek ilerliyoruz. ASM ile ilgili portalımızda makaleler bulunmaktadır. ASM kısmını bu makalede işlemeyeceğiz.

Database backup ayarlarının yapılacağı kısımdır. Kurulum işleminden sonra da backup ayarlarını yapabilmekteyiz.

Database kurulumu sonrası yönetim için gelecek olana SYS, SYSTEM, SYSMAN ve DBSNMP kullanıcıları için şifre belirleyeceğimiz kısımdır. Bu kullanıcılara tek tek şifre tanımlayabileceğiniz gibi, tek bir şifrede atayabilmektesiniz. Ben unutmamak adına hepsine tek bir şifre atayıp, next ile ilerliyorum.

Bu adıma kadar seçmiş olduğumuz seçenekleri burada bize rapor olarak vermektedir. File olarak kaydedebilmekteyiz. Finish tıkladığımızda kurulum işlemi başlayacaktır.

Bu adıma kara seçtiğimiz ayarlar ile birlikte database oluşturma işlemi başlamış bulunmaktadır. Bu işlem kurulum yapacağınız kayaklara göre değişim göstermektedir.

Database oluşturma işleminin sonuna doğru ulaşmaktayız.

Database oluşturulma işleminin bittiğini bağlantı url kısmını bize göstermektedir. Şifre yönetimini yapabileceğimiz son adım, biz tüm kullanıcılara aynı şifreyi atağımızdan ok ile devam ediyorum.

Web tarafından database’e ulaşabilmek için URL’i bize vermektedir. Bunu isterseniz unutmamak adına bir kenara not edebilirsiniz. Artık kurulum ve database oluşturma işlemi tamamlandı. Close seçeneği ile işlemi bitiriyorum.

Database Connection Test İşlemlerini Yapalım.

1. İlk olarak komut satırı ile bağlantıyı test edelim. Aşağıda database ile bağlantı işleminin başarılı şekilde sağlandığını görebilmekteyiz.

2. Web tarafından URL ile birlikte bağlanalım.

Kurulum esnasında kullanıcıya atadığımız şifre ile giriş yapalım.

Web üzerinden de database’inmanagement paneline ulaşabildiğimiz görebilmekteyiz.

Bir başka makalede görüşmek üzere. Faydalı olması dileğiyle.

Kaynak: http://www.oracle.com

Günümüzde, kurumlar için en önemli varlık “veri”dir. Peki nedir bu veri? Bankalar ve telekomünikasyon kurumları için veri, Müşteri Bilgisi (anne kızlık soyadı, adres, telefon, mevduat bilgisi, en çok kullanılan servisler vb) olarak adlandırılabilir. Kurumlar bu bilgilerin bütünlüğünden (integrity), erişilebilirliğinden (availability) ve gizliliğinden (confidentiality) sorumludur.Veriyi kullanarak kurumlar gelir elde ederler.Bu durumda veri, ticari bir varlık olarak da nitelendirilebilir.Aynı zamanda, bu bilgileri kullanarak kanun düzenleyiciye sundukları raporların doğruluğundan da sorumludurlar.

Buraya kadar, verinin ne olduğundan ve ne işe yaradığından bahsettik. Peki, bu derece önemli bir varlığı nasıl korumalıyız?Ya da korunduğunu nasıl denetim kanıtı olarak denetimlerde nasıl göstermeliyiz?

Bilgiyi fiziksel ve mantıksal olarak koruyabiliriz.Fiziksel olarak, güvenlik görevlileri, döner kapılar, çelik kasalar vb; mantıksal olarak ise, verinin saklandığı sunucudan başlayarak onu işleyen son kullanıcıya kadarki döngüde geçen her sistem sayılabilir.

Yasal zorunluluklar (BDDK, BTK, SOX, PCI vb) nedeniyle veriye olan her tür erişim talebinin yetkilendirilmesi, erişimlerin de kayıt altına alınması gerekmektedir (least priviledge, need-to-know).

Kurumlar, denetimler için çeşitli bağımsız denetim firmaları ile çalışarak, gerçekleştirdikleri operasyonları nasıl kontrol ettiklerini ilgili denetim kanıtları ile ispatlamak zorundadırlar.Sürmekte olan teknik operasyonlara gerekli kontrol noktaları ilave ederek denetim kanıtı sunmak tüm kurumlar için başarılı denetimin en önemli başlangıç noktasıdır.

Denetimlere hazırlanırken de, kendi öz değerlendirmelerini yapmak ve gerekli kontrolleri devreye almak denetimlerde sorun yaşamamak adına en önemli yardımcıları olacaktır. Peki, bu denetimlerde neler nasıl kontrol edilmektedir?

Bu yazımızda, bunları açıklarken gerekli sql cümleciklerini ve çıktılarının nasıl yorumlanacağından bahsedeceğiz.

Denetimlerde, öncelikle kullanıcı hesapları, üye oldukları roller ve sahip oldukları haklar en büyük paya sahip diye düşünebiliriz.Bu denetimleri yaparken uygulama kullanıcılarımızı kısmen bu işin dışında tutmamız gerekiyor.Çünkü uygulama kullanıcıları, doğası gereği uygulama sunucuları üzerinden gelecekleri ve uygulama sahibinin scheması altında tüm tablolar üzerinde yetkileri olması gerektiği için denetimlerde sadece Yetkili IPden ve uygulamadan geldiğinin kontrolü yeterlidir. Ama bu şu demek değildir, uygulama userı full yetkiye sahip olabilir, örneğin dba yetkisine! Hayır, sadece uygulama sahibinin schemaları üzerinde yetkiye sahip olmaları gerekmektedir. Dolayısıyla sistemde dba yetkisine sahip kullanıcılar kimlerdir diye bakarken bu kullanıcılara da dikkate alınır ancak select dışında kimlerin yetkisi var gibi bir denetim maddesine bakarken bu kulanıcılar hariç tutularak bakılması gerekecektir.

Örneğimizde de hemen hemen tüm bankalarda bir INFRA scheması olduğunu düşünerekden uygulama ownerımız INFRA, uygulama userlarımız APP_INFRA1, APP_ INFRA2, APP_ INFRA3 olsun.

Aşağıdaki sorguların outputlarında örnek olması açısından bir sadece kısmını yazıya ekliyor olacağız.Dolayısıyla sizlerdeki sorgu sonuçları satır ve sutun sayıları bakımından farklılık gösterebilir. Aşağıdaki maddeleri örneklerle açıklayabilmek için data oluşturabilmek adına test ortamım da farklı isimlerde bir takım userlar oluşturarak farklı yetkiler atadık.

Son olarak production ortamlarda oluşturulan tüm userların create edilme talepleri ve bu userlara verilen tüm yetkilere ait yetki talepleri (tabi gerekli onay aşamalarından geçmiş ve onaylanmış olmaları şartıyla) olmaları gerekmektedir. Bu durum aşağıdaki tüm maddeler içinde geçerli olduğundan dolayı her maddede sürekli olarak bu hatırlatmayı yapmamak için burada özellikle belirtmek istiyoruz. Denetim ekibi bir userda olmaması gereken bir yetkiye rastladıklarında bu yetkinin kim tarafından ve ne zaman verildiğini sizden belgelemenizi isteyeceklerdir. Dolayısıyla da sizin de bunu (bu genelde güvenlik departmanının sorumluluğunda olan bir süreçtir) gösterebiliyor olmanız gerekmektedir.

Artık denetim maddelerimizin üzerinden sırayla geçmeye başlayabiliriz;

1 – Select Yetkisi Dışında Yetkisi Olan Tüm Kullanıcıların Tespiti ;

Burada beklenilen database’ i manage eden dba’ ler dışında her kim olursa olsun (kimi zaman dba’ lerin bile dba yetkileri sorgulanabilmektedir!) database’ de update, delete vs gibi kritik yetkilerin olmaması gerektiğidir.Bu sorgu sonucunda bu yetkiye sahip kullanıcılar çıkabilir, bunu da denetimcilere ikna edebilecek şekilde gerekliliğini açıklayabiliyor olmanız gerekmektedir.

Account statusu locklı olan userlar haricindekleri bulmak için aşağıdaki sorguyu kullanabiliriz;

SELECT *

FROM dba_tab_privs

WHEREprivilegeNOTIN('SELECT')

ANDgranteeNOTIN('APP_INFRA1','APP_INFRA2','APP_INFRA3')

ANDgranteeNOTIN(SELECT username

FROM dba_users

WHERE account_status ='LOCKED')

ORDERBYprivilege

Sorgunun çıktısı ;

Bu sorgu sonucunda gelen tüm userlar incelenerek örneğin, ozgul kullanıcısının neden infra scheması altındaki satis_detay tablosuna ALTER yetkisi olduğu açıklanır.Önceden kalmış olan veya yanlışlıkla verilmiş olan yetkiler var ise bunlar geri alınır.

2 – Database’ de Kritik Bir Takım Önemli Rollere Sahip Olan Kullanıcıların Tespiti ;

Kritik role’ den nelerin kastedildiğini aşağıdaki sorgu içerisinden görebilirsiniz. (Kontrol aşamasında bakılan temel roller bunlardır ama denetmenin talebi doğrultusunda değişiklik gösterebilir)

SELECT *

FROM dba_role_privs

WHERE granted_role IN

('SELECT_CATALOG_ROLE',

'DELETE_CATALOG_ROLE',

'EXECUTE_CATALOG_ROLE',

'DBA',

'DROP ANY TABLE',

'ALTER TABLE',

'ALTER ANY TABLE',

'DROP TABLE',

'ALTER SYSTEM',

'CREATE ANY TABLE',

'CREATE TABLE')

Sorgunun çıktısı ;

Yukarıdaki kullanıcıların neden bu yetkiye sahip olmaları gerektiği açıklanır.Önceden kalmış olan veya yanlışlıkla verilmiş olan yetkiler var ise bunlar geri alınır.

3 – Kullanıcı Hesapları Kontrolü ;

Database’ de yer alan tüm kullanıcıların accountlarının statüslerine bakılır. Firmada çalışmadığı halde hala userı olup ve locklı olmayanlar tespit edilmeye çalışır. (çalışan kullanıcı bilgileri listesinin güncel haline IK biriminden ulaşılır)

SELECT username, account_status FROM dba_users;

Sorgunun çıktısı ;

4 – Siteme X Gündür Erişim Yapmamış Olan Kullanıcıların Tespiti ;

Sizin firmanızdaki çalışan sayınıza bağlı olarak yüzlerce userınız olabilir, dolayısıyla bunların zaman zaman içerisinde personel sirkülasyonuda düşünüldüğünde takibinde bir takım aksaklıklar çıkabilir.Bu tarz aksaklıkları gözlemleyebilmek/tespit edebilmek için kullanıcıların sisteme log on – log off aksiyonlarını loglayarak örneğin 1 aydır sisteme hiç giriş yapmayan kullanıcıları tespit edebilirsiniz.Bunu tespit edebilmenin iki yolu bulunmaktadır. Birincisi database’ de oracle’ ın audit parametrelerini kullanarak bir auditing yapıyorsanız aşağıdaki sorguyu kullanabilirsiniz ;

SELECTDISTINCT(u.username)

FROM dba_users u

WHERE account_status ='OPEN'

ANDNOTEXISTS

(SELECT'x'

FROM dba_audit_trail A

WHEREu.username =a.username

ANDa.logoff_time >SYSDATE-30);

Sorgunun çıktısı;

Buradaki gün değeri parametrik olup (SYSDATE–30) istenirse bu aralık azaltılıp artırılabilinir.

Eğer auditing için third-party bir uygulama kullanıyor ve oracle tarafındaki audit parametreleriniz tümüyle kapalı ise (örneğin Guardium yazılımını kullanıyosanız db tarafında ayrıca bir auditing parametresi açmanıza gerek olmayacaktır.) yazacağınız bir trigger ile connectionları loglayabilir ve sonrasında bu logları dba_users tablosundaki userlar ile karşılaştırabilirsiniz.

Logon trigger yapılandırılması için;

http://www.kamilturkyilmaz.com/2011/01/22/sisteme-connect-olan-%E2%80%93-olmayan-kullanicilari-tespit-etme/

3^rd party Audit Uygulamalası için;

http://www.bilgiguvenligi.gov.tr/kayit-yonetimi/veritabani-loglama.html

linkleri yardımcı olacaktır.

5 - Database’ de Kritik Bir Takım Yetkilere Sahip Olan Kullanıcıların Tespiti ;

3 nolu madde de kritik rollere sahip kullanıcılardan bahsetmiştik.Burada ise kritik yetkilere sahip kullanıcıları nasıl tespit edebileceğimizden bahsedeceğiz.

Bunun için aşağıdaki sorgudan faydalanabiliriz;

SELECT *

FROM dba_sys_privs

WHEREPRIVILEGEIN

('SELECT ANY TABLE'

'SELECT ANY DICTIONARY',

'CREATE LIBRARY',

'CREATE ANY LIBRARY',

'ALTER ANY LIBRARY',

'EXECUTE ANY LIBRARY',

'CREATE PROCEDURE',

'EXECUTE ANY PROCEDURE',

'ALTER SESSION',

'BECOME USER',

'ALTER SYSTEM')

Sorgunun çıktısı;

Bu çıktı sonucunda olmaması gereken userlar var ise açıklamaya devam ediyor olacağız.

6 – With Admin Option Opsiyonu ile Atanmış Olan (Role & System) Yetkilerin Tespiti ;

Kullanıcılara yetkileri vermenin bir yolu grant komutunun sonuna with admin option komutu eklemektir. Bu şekilde grant vermeniz durumunda yetkiyi verdiğiniz bu kullanıcı sahip olduğu bu yetkiyi istediği bir kullanıcıya atayabilir demektir. Yani aslında sadece yetkiyi değil, yetkinin bir anlamda devir edebilme hakkını da vermiş oluyorsunuz. Dolayısıyla zaman zaman açık olarak değerlendirilmektedir. Bu durumu tespit edebilmek için aşağdıki sorgu kullanılabilirsiniz;

SELECT'ROLE',grantee, granted_role

FROM dba_role_privs

WHERE admin_option ='YES'ANDgranteeNOTIN('SYS','SYSTEM','DBA')

UNION

SELECT'SYSTEM',grantee,PRIVILEGE

FROM dba_sys_privs

WHERE admin_option ='YES'ANDgranteeNOTIN('SYS','SYSTEM','DBA')

Scriptin çıktısı ;

Bu durumunda, bir açıklamanız olduğunu varsayarak devam ediyoruz J

Burada system ve role privilege’ lerinden with admin option opsiyonu ile yetkilendirme olup olmadığını kontrol ettik.

19. madde de yine bu kapsamda değerlendirilebilir, object grantları verilirken with admin option opsiyonu ile verilmiş olanları bulabilirsiniz.

7 – Auditing Parametrelerinin Kontrol Edilmesi ;

Burada hedeflenen Oracle’ın Auditing sistemini kullanarak bir auditing yapıyorsanız burada auditing ile ilgili sistem parametrelerinin nasıl set edildiğini sorgulamak için aşağıdaki scriptten yaranılabilir ;

SELECTname,valueFROM v$parameter WHERENAMELIKE'%audit%'

Scriptin çıktısı ;

Burada audit_trail set edilmiş olmalı, audit_sysoperations TRUE olarak set edilmeliki sys’ nin yapmış olduğu tüm işlemlerde audit kapmamına alınmış olsun.

Oracle’ da auditing işlemleri için aşağıdaki makale yardımcı olacaktır;

http://www.kamilturkyilmaz.com/2011/01/21/oracle%E2%80%99-da-audit-mekanizmasi/

8 – Hangi Yetkilerin Audit Edildiğinin Tespit Edilmesi ;

Burada yine auditing açık olabilir ama hiçbirşeyi auditlemiyorda olabilirsiniz fikrinden hareketle aslında neleri auditlediğinizi sorgulama için yapılan bir denetim aşamasıdır. Hangi yetkilerin auditlendiğini tespit etmek için aşağıdaki sorguyu kullanabilirsiniz;

SELECT * FROM sys.dba_priv_audit_opts;

Sorgunun çıktısı ;

Hangi yetkilerin kullanıldığında audilendiği bilgisine buradan ulaşabilirsiniz. Audit edilmeyen yetkileri tespit etmek içinse aşağıdaki sorgudan faydalanabilirsiniz ;

SELECTprivilege

FROM role_sys_privs

minus

SELECTprivilegeFROM sys.dba_priv_audit_opts;

Sorgu çıktısı ;

Yukarıdaki yetkiler ile yapılan işlemler audit kapmamında olmayan işlemlerdir. Burada şunu iyi değerlendirmek gerekir.Herşeyi auditlemek iyi bir çözüm değildir.Bu şekilde yapmanız durumunda milyonlarca datanın içinde boğulmak durumunda kalabilirsiniz.Örneğin Alter any index yetkisinin auditlenmesinin kime ne faydası olacaktır? Index’ i alter etmekle data üzerinde bir değişikliğe sebeb oluyor musunuz, kullanıcı datası yapılan bu işlemden ne kadar etkileniyor gibi sorulara vereceğiniz cevap aslında size audit yapıp yapmamanızı da söylüyor olacaktır. Hangi verinin loglanacağı, loglanacak olanların ne detayda loglanıp raporlarının kimlere iletilceği kurum içinde alınacak bir karardır.

9 – Hangi Objelerin Audit Edildiğinin Tespit Edilmesi ;

Bir önceki madde de role bazında auditing işleminin nasıl yapıldıüından bahsetmiştik. Bu kısımda da obje bazında da nelerin audit edilğini tespit ediyor olacağız. Bunun için aşağıdaki sorguyu kullanabiliriz ;

SELECT * FROM sys.dba_obj_audit_opts;

Sorgu çıktısı ;

Bunlar INFRA schemasındaki olan tablolardan hangi komutların auditing edildiğini gösteriyor.

10 – Hangi Statementların Audit Edildiğinin Tespit Edilmesi ;

Database’ de çalıştırılan hangi komutların auditlendiğini tespit etmek içinse aşağıdaki script kullanılabilir ;

select * from dba_stmt_audit_opts ;

Scriptin çıktısı ;

11 – Sistemdeki Profile Settinglerini Kontrol Etmek Edilmesi ;

Database’ deki profile settinglerini kontrol etmek için aşağıdaki sorguları kullanabilirsiniz ;

-- Sistemde tanımlı olan profileleri sorgulamak için ;

SELECTdistinctprofile

FROM sys.dba_profiles

-- Mevcut profilelerin nasıl set edildiğini görmek için ;

SELECT*

FROM sys.dba_profiles

Sorgunun çıktısı ;

Sistemde tanımlı olan her user mutlaka daha önceden tanımlanmış olan profile’ lere atanmış olmalıdır.Yöntem, uygulama userları için farklı bir profile, dba’ ler için farklı bir profile, yazılımcılar için farklı profile varsa diğer userlar içinde farklı bir profile tanımlaması yapılması şeklindedir.Örneğin uygulama userları için oluşturulacak profile’ da password_life_time, failed_logon_attemps gibi değerlerin unlimited olması gerekmektedir. Ancak diğer userlar için bu değerlerin mutlaka sınırlandırılmış olması gerekmektedir.

12 – Tüm Kullanıcılara ve Rollere Atanmış Olan Rolleri Kontrol Edilmesi ;

Bu madde ile dataabse’ de yer alan tüm kullanıcılara ve rollere (bir role farklı bir role’ de atanabileceğinden) verilmiş olan role yetkilerini göstermektedir.

SELECT *

FROM dba_role_privs

Sorgunun çıktısı ;

Burada da sahip olmaması gereken bir role sahip kullanıcı veya bir role grubu olup olmadığı kontrol edilmektedir.

13 – Database’ deki Public DB Link Kontrolleri ;

Farklı database’ ler arasında veri aktarımı sağlayabilmek için kullanılan database linkleri zaman zaman oluşturulma biçimlerine göre güvenlik açığı teşkil edebilmektedirler.Database linkler iki farklı şekilde oluşturulur; Birincisi private olarak create edilebilir ki, aslında önerilen yöntemi de budur. Private olarak create edilen bir link hangi userın altında oluşturuluyor ise sadece o user tarafından kullanılabilir. Public linkler ise denetim esnasında bulgu olarak belirtilen durumlardır ki, public olan bir link sisteme connect olan yetkili/yetkisiz herhangi bir user tarafından kullanılabilecek olan linklerdir. Bu linkleri tespit etmek için ;

select * FROM SYS.dba_db_links where status ='PUBLIC'

Sorgunun çıktısı ;

Database’ de public link olmamalıdır. Kontroller öncesinde olanlar var ise bunlar drop edilerek hangi user kullanıyor ise o userın schemasının altına oluşturulmalıdır. Bu işlemin nasıl yapılacağı ile ilgili detaylı bilgi için aşağıdaki makaleye yardımcı olacaktır:

http://www.kamilturkyilmaz.com/2010/11/10/database%E2%80%99-ler-arasi-link-kurulumu-dblink/

14 – Sistemde Sysdba Yetkisine Sahip Olan Kullanıcıların Tespiti;

Sysdba, oracle database’lerindeki en yetkili user’ dır.Dolayısıyla da çok kritik bir öneme sahiptir.Sistemde bu yetkiye sahip olan userlar sürekli olarak kontrol edilmelidir. Bu kullanıcıların tespiti için aşağıdaki sorguyu kullanabilirsiniz ;

SELECT * FROM v$pwfile_users;

Sorgunun çıktısı ;

Bu yetkiye sahip olmaması gereken userlar tespit edilirse, mutlaka yetki ilgili userdan revoke edilmelidir.

15 – Unlimited Tablespace Yetkisine Sahip Kullanıcıların Tespiti;

Unlimited tablespace yetkisine production ortamlarda genellikle uygulama ownerı dışında kimsenin ihtiyacı olmaması gerekmektedir.Çünkü production ortama veri girişi sadece uygulama scheması altına olmalıdır.En azından beklenti bu yöndedir.Çoğunlukla bazı kritik sistemlerin yönetilmesi için kimi developerlara zaman zaman sahip olması gerektiğinden daha fazla bir yetki verilmesi gündeme gelebilir.Bu tarz durumlarda bu sürecinde mutlaka sürekli olarak takip ediliyor olması gerekecektir.Aynı şekilde yetkinin verilmesi nedenin ve onay aşamalarınında mutlaka ispatlanabiliyor olması gerekmektedir.

SELECTgrantee,privilege

FROM dba_sys_privs, dba_users

WHERE dba_users.username = dba_sys_privs.grantee

ANDprivilege='UNLIMITED TABLESPACE'

AND dba_users.account_status ='OPEN';

Script çıktısı ;

Bu yetkiye sahip olmaması gereken user tespit edilirse, yetki geri alınmalıdır. Userlara tablespace bazında da kota verilebilir ;

alteruser murat quota500Monusers;

User bazında kotaları select etmek istersek ;

SELECTSUBSTR(TABLESPACE_NAME,1,10)TABLESPACE,

SUBSTR(USERNAME,1,15) USERNAME,

SUBSTR(BYTES,1,10)/1024/1024 USED_MB,

DECODE(MAX_BYTES,

'-1','Unlimited',

SUBSTR(MAX_BYTES,1,10)/1024/1024)

QUOTA_MB

FROM dba_ts_quotas;

Scriptin çıktısı ;

16 – Role İçerisindeki Yetkilerin Kontrolü ;

Öncelikle database’ deki tüm role’ leri listelemek için aşağıdaki sorgudan faydalanabiliriz.

select * from dba_roles;

Database’ de oluşturulan role’ lerin içerisindeki yetkileri kontrol etmek için aşağıdaki sorgu kontrol kullanılabilir;

select * from DBA_TAB_PRIVS wheregrantee='READ';

SELECT * FROM role_sys_privs whererole='READ';

Yukarıdaki ilk sorgu ile READ isimli role’ içerisindeki object grantları, ikinci sorgu ilede system yetkileri kontrol edilmektedir.

İlk scriptin çıktısı ;

İkinci scriptin çıktısı ;

Bu örnekde READ isimli role içerisinde aslında olmaması gereken role’ ler olduğu gözlenmektedir. Buda bu haliyle bulgu olarak önümüze gelmektedir.

Role’ ler aslında üzerinde dikkatle durulması gereken noktalardan biridir. Neden bu kadarönemli olduğunu bir örnekle açıklamaya çalışalım. Örneğin database’ deki dba rolü bu tarz kontrollerde ilk bakılan yetkilerden biridir.Kimlerin dba rolüne sahip olduğuna denetçilerin mutlaka kontrol edeceğini herkes bildiği için kimi durumlarda kullanıcıya dba rolü vermek yerine dba rolünün içini dolduran yetkileri direk olarak kullanıcıya atama yoluna gidenler olabilmektedir.Ancak denetimler esnasında rollerinde mutlaka kontrol edildiği unutulmamalıdır.

Aşağıdaki sorgu ile dba role’ ünün sahip olduğu yetkilerden hangilerinin READ rolünde de olduğunu kıyaslamak istersek ;

SELECT*FROM role_sys_privs whererole='READ'

andprivilegein(

SELECT* FROM role_sys_privs whererole='DBA')

Bu sorguyu sonradan create edilen tüm role’ ler için kullanabilirsiniz.

Script çıktısı ;

17 – Oracle Kurulumu İle Birlikte Gelen Default Userların Kontrolü ;

Oracle database kurulumu ile birlikte kurulan Oracle componentlerine bağlı olarak kimi userlar default olarak gelir.Burada dikkat edilmesi gereken nokta bu default userların accountlarının locklanması, mümkünse silinmesidir.Default user listesi oracle’ ın versiyonuna göre farklılık gösterebilmektedir.

Oracle 10g ve 11g için default user listesini aşağıda belirtilmiştir:

SELECT username, account_status

FROM dba_users

WHERE username IN

('SYS',

'SYSTEM',

'DBSNMP',

'MDSYS',

'ORDSYS',

'ORDPLUGINS',

'CTXSYS',

'DSSYS',

'PERFSTAT',

'WKPROXY',

'WKSYS',

'WMSYS',

'XDB',

'ANONYMOUS',

'ODM',

'ODM_MTR',

'OLAPSYS',

'TRACESVR',

'REPADMIN',

'MGMT_VIEW',

'LBACSYS',

'OUTLN',

'FLOWS_FILES',

'EXFSYS',

'APPQOSSYS',

'APEX_030200',

'ORDDATA',

'ORDPLUGINS',

'SI_INFORMTN_SCHEMA',

'ORACLE_OCM',

'XS$NULL',

'DIP',

'APEX_PUBLIC_USER')

Script çıktısı ;

18 – Sys, System, Sysman, Public Userları Dışındaki Tüm Userların System ve Object Grantlarının Kontrolü ;

Database’ deki tüm userların sahip oldukları (sys,system,sysman ve public userlar hariç) tüm system privilege’ leri ile object grantlarının görüntülenmesi için ;

SELECTgrantee,

'SYSTEM',

'--',

privilege

FROM dba_sys_privs

WHEREgranteeNOTIN('SYSTEM','SYSMAN','SYS','PUBLIC')

ANDNOTEXISTS

(SELECT'x'

FROM dba_roles

WHERErole=grantee)

UNION

SELECTgrantee,

'TABLE',

table_name,

privilege

FROM dba_tab_privs

WHEREgranteeNOTIN('SYSTEM','SYSMAN','SYS','PUBLIC')

ANDNOTEXISTS

(SELECT'x'

FROM dba_roles

WHERErole=grantee)

UNION

SELECTgrantee,

'COLUMN',

table_name,

privilege

FROM dba_col_privs

WHEREgranteeNOTIN('SYSTEM','SYSMAN','SYS','PUBLIC')

ANDNOTEXISTS

(SELECT'x'

FROM dba_roles

WHERErole=grantee)

Script çıktısı ;

Burada da kullanıcın sahip oldukları yetkileri (system ve object grantları) toplu olarak görüntülendiğinden dolayı kullanıcı – yetki ilişkisi sorgulanmaktadır.

19 – Objectler Üzerinde “With Grant Option” Hakkına Sahip Olan Userlar ;

6. maddede role ve system privilege’ lerinden admin opsiyonuna sahip kullanıcıları görüntülemiştik, burada da benzer bir mantıkla var olan objeler üzerinde with grant opsiyonuna sahip kullanıcıları sorguluyor olacağız;

select * from dba_tab_privs where grantable ='YES'

andgranteenotin('SYS','SYSTEM','DBA')

andgranteenotin(SELECT USERNAME FROM DBA_USERS WHEREPROFILE='&APPLICATION_PROFILE')

union

select * from dba_col_privs

where grantable ='YES'

andgranteenotin('SYS','SYSTEM','DBA')andgranteenotin(SELECT USERNAME FROM DBA_USERS WHEREPROFILE='&APPLICATION_PROFILE')

Script Çıktısı ;

6. maddedeki durumu açıklarken with admin option özelliğinin ne anlama geldiğinden bahsetmiştik. Bu özellik kullanılarak yetki verildiğinde bir süre sonra ilgili tablo üzerindeki yetki dağılımı kontrolden çıkabilir.Buraki çıktıda benzer bir mantıkla tek tek kontrol edilmelidir.

20 – Security Patch’ lerin Uygulanıp Uygulanmadığı Kontrolü ;

Oracle, her 3 ayda bir security path’ leri yayınlamaktadır.Versiyonlar piyasa çıktıkdan bir süre sonra tespit edilen security açıkları bu patchler’ le kapatılmalıdır. Sisteme şimdiye kadar hangi patch’ lerin uygulandığını sorgulamak için OS üzerinde aşağıdaki komutla sorgulanabilmektedir.

$ORACLE_HOME/OPatch/opatch lsinventory

Script çıktısı ;

C:\oracle\product\11.2.0\dbhome_1\OPatch>opatch lsinventory

Invoking OPatch 11.1.0.6.6

Oracle Interim Patch Installer version 11.1.0.6.6

Oracle Home : c:\oracle\product\11.2.0\dbhome_1

Central Inventory : C:\Program Files\Oracle\Inventory

from : n/a

OPatch version : 11.1.0.6.6

OUI version : 11.2.0.1.0

OUI location : c:\oracle\product\11.2.0\dbhome_1\\oui

Log file location : c:\oracle\product\11.2.0\dbhome_1\cfgtoollogs\opatch\opatch2012-01-29_03-09-57AM.log

Patch history file: c:\oracle\product\11.2.0\dbhome_1\cfgtoollogs\opatch\opatch_history.txt

Lsinventory Output file location : c:\oracle\product\11.2.0\dbhome_1\cfgtoollogs\opatch\lsinv\lsinventory2012-01-29_03-09-57AM.txt

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

Installed Top-level Products (1):

Oracle Database 11g 11.2.0.1.0

There are 1 products installed in this Oracle Home.

There are no Interim patches installed in this Oracle Home.

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

OPatch succeeded.

Buradan da anlaşılacağı üzere benim test ortamıma hiçbir patch apply edilmemiş.

21 – Oracle Dosyalarına / Dizinlerine Erişim Kontrolü ;

Burada vurgulanmak istenen Oracle’ ın işletim sisteminde kullandığı dizinlerine sadece Oracle userının eriştiğinden emin olunmasıdır.Örneğin OS’ de ORACLE_HOME ve ORACLE_BASE dizinlerinin sahibi oracle olmalıdır. Aslında bunu oracle’ ın kullandığı ve ürettiği tüm file dizinleri için düşünebilirsiniz. (Linux sistemler için ORACLE_BASE ve ORACLE_HOME dizinlerinin yetkilendirilmesi 750, diğer file pathleri içinde 600 olarak yapılandırılması uygun olacaktır.)

22 – Default Listener Port Kontrolü ;

Listener servisinin default portu 1521 dir. Bu port herkes tarafından bilindiği için bu şekilde kullanımı açık olarak değerlendirilmektedir. Listener servisinin default portunun nasıl değiştirilmesi gerektiği ile ilgili aşağıdaki linkten daha detaylı bilgi edinebilirsiniz ;

http://www.kamilturkyilmaz.com/2012/01/29/listener-service%E2%80%99-inin-portunu-%E2%80%93-adini-degistirme/

23 –Listener Servisi Parola Kontrolü ;

Kullanıcıların oracle database’ ine ulaşması için Listener servisi çok kritik bir öneme sahiptir.Dolayısıyla bu servisi olabildiğince güvenlik altına almak gerekmektedir.Listener servisinde parola olmaması bir güvenlik açığı sayıldığından dolayı bu servisede mutlaka parola konulması gerekmektedir. Bu işlemin nasıl yapılması gerektiği ile ilgili olarak aşağıdaki linkten faydalanabilirsiniz;

http://www.kamilturkyilmaz.com/2011/08/07/listener-service%E2%80%99-ine-sifre-atama/

24 – Kullanıcı Password Oluşturma Politikası Kontrolü ;

Burada kontrol edilen, production ortamlardaki kullanıcılar şifrelerini oluştururken hangi kriterlere göre oluşturuyorlar.Nelere dikkat ediliyor ve bunların güvenlik seviyesi nedir gibi sorulara cevap aranıyor.Bunu yaparken de sisteme bir password_verify functionı tanımlıyorsunuz.Sonrasında database’ de kullanıdığınız tüm profile’ lere (password_verify_funtion kısmına) bu functionı atadığınız zaman sorununuz ortadan kalkmış olmaktadır. Bu function kullanıcı şifresini belirlerken kaç karakter olması gerektiğini, password içerisinde numeric ve alfa numeric karakterlerin kullanılıp kullanılmadığını, ardarda 3 karakterin kullanılıp kullanılmadığını, paswordun username ile aynı verilip verilmediğini kontrol etmektedir. Bu arada bu bahsetmiş olduğumuz kontrolleri yapacak verify functionı ben nerden bulacağım veya nasıl yazacağım diye düşünmenize gerek yok. Oracle, sizin için bunu önceden hazırlayıp $ORACLE_HOME\RDBMS\ADMIN altına utlpwdmg.sql adıyla text formatında saklıyor sizin tek yapmanız gereken bu scripti çalıştırmanız.İhtiyaç duyacağınız tüm kontrolleri bu function fazlasıyla yapmaktadır.

25 – Public Kullanıcısı Yetkileri ;

Detayına çok girmeden bazı paketlerdeki açıklardan dolayı PUBLIC kullanıcısının bu paketler üzerindeki haklarının revoke edilmesi gerekmektedir. Aksi takdirde örneğin sys.dbms_export_extention paketi kullanılarak dba yetkisine sahip kullanıcı oluşturulması riskiyle karşı karşıya kalabilirsiniz.Bu paketler ve barındırdıkları riskler itibariyle detaylı bilgiye Tübitak’ ın yayınlamış olduğu Oracle Veritabanı Güvenliği Klavuzundan ulaşabilirsiniz.Yazımın sonunda bende referans olarak bu dökümanı belirtiyor olacağım.

Alınması gereken yetkiler;

REVOKEEXECUTEONDBMS_EXPORT_EXTENSIONFROMPUBLIC;

REVOKEEXECUTEONUTL_FILEFROMPUBLIC;

REVOKEEXECUTEONUTL_SMTPFROMPUBLIC;

REVOKEEXECUTEONUTL_HTTPFROMPUBLIC;

REVOKEEXECUTEONUTL_TCPFROMPUBLIC;

REVOKEEXECUTEON SYS.DBMS_EXPORT_EXTENSIONFROMPUBLIC;

26 – SYS Scheması Altındaki Tablolara Erşim Kontrolü ;

Database Select any table yetkisine sahip olan kullanıcıların User tabloları dışında Sys altındaki tablolarıda görüp göremeyeceği database’ deki 07_DICTIONARY_ACCESSIBILITY parametresi ile belirlenir. Bu değer default’ da false olarak gelmekle birlikte kontrol edilmesinde fayda vardır. TRUE olması açık kapsamında değerlendirilmektedir. Bu değer False olmasına rağmen SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE veya DELETE_CATALOG_ROLE yetkilerinden birine sahip olan kullanıcıları bu tabloları görebilme yetkisinede sahip olmuş demektir. Dolayısıyla bu kritik role’ lerinde kontrol edilmesi gerektiğini 2.maddede belirtmiştik.

27 – Oracle Database SID Kontrolü ;

Denetimlerde bulgu olarak değerlendirilen bir diğer madde ise oracle database SID’ lerinin sistemin ne olduğu ile ilgili fikir veriyor olmasıdır. Örneğin production database’ nizin adının PROD olması, İnternet bankacılığı database’ inin Sid’ nin INT_BANK veya bu tarz anımsatıcı bir isim olması, kredi kartları database’ inizin adının KART, KREDI_KART gibi isimler olması açık kapsamında değerlendirilmektedir.

Database’ in SID ‘ sinin nasıl değiştirilmesi gerektiği ile ilgili bilgiye aşağıdaki linkden ulaşabilirsiniz ;

http://www.kamilturkyilmaz.com/2011/02/02/database%E2%80%99-in-dbid-ve-db_name-degerini-degistirmek-dbnewid-nid/

28 – Uygulama Userlarının Erişim Kontrolü ;

Buraya kadarki olan kısımdan da anlayacağınız üzere, denetimlerin temeli aslında temel kim hangi dataya neden ve nasıl ulaşıyor üzerinde dönüyor. Önceki maddelerde yetkileri, rolleri object grantlarını sorguladık ve bunu yaparkende kimilerinde uygulama userlarını hariç tutarak yaptık.Çünkü bu userların zaten amacı uygulama schemalarına erişmeleri (program üzerinde) olduğu için, burda bunu yaparken şunu atlamamız gereken nokta şu aslında, o zaman uygulama userları ile sadece application üzerinden sisteme connect olmalarını bekliyebiliriz yani hiçbir uygulamacı kendi clientından toad veya benzer bir tool ile bu userları kullanarak sisteme giriş yapamamalıdır. Bu önemli bir nokta, o zaman alınması gereken önlem yine bir trigger yardımı ile bu userlardan birisi ile sisteme connection kurmaya çalıştığında ip bazında kontrol yapıp (eğer geldiği ip application sunucunun ip’ si ise giriş yapabilecek farklı bir ip ise girişine izin verilmeyecektir) sonrasında girişine izin verilmesi gerekecektir.

Bahsi geçen trigger´ ın bir örneğine aşağıdaki linkden ulaşabilirsiniz ;

http://www.kamilturkyilmaz.com/2011/01/21/bilinen-adiyla-logon-trigger/

29 – Uygulama Ownerı Accountu Kontrolü ;

Database’ deki uygulama ownerı ile işlem yapılmaması gerekmektedir. Dolayısıyla bu userın acountunun lock’ lı olmasına dikkat edilmelidir ;

Bizim database’ imizde INFRA kullanıcımızı uygulama ownerı olduğunu kabul etmiştik ;

SQL> select username, account_status from dba_users where username = 'INFRA'

USERNAME ACCOUNT_STATUS

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

INFRA LOCKED

1 row selected.

30 – Alınan Backupların Başarılı Olarak Alındığının Kontrolü ;

Database’ den alınan günlük rman backuplarının (sıkca bu yöntem kullanıldığı için örnek veriyorum) düzgün olarak alındığının loglar üzerinden gösterilebiliyor olması gerekmektedir. Bunun için third-party bir tool kullanıyor iseniz kullandığınız tool’ un loglarından veya database’ den aşağıdaki sorguyu kullanarak da loglara ulaşabilirsiniz ;

SELECT *

FROM(SELECT start_time Backup_baslangic_suresi,

end_time Backup_bitis_süresi,

output_device_type backup_lokasyonu,

input_type Backup_Type,

status backup_durumu,

output_bytes_display backup_boyutu,

time_taken_display backup_alma_süresi

FROM V$RMAN_BACKUP_JOB_DETAILS

ORDERBY1DESC)

WHEREROWNUM<10

Script çıktısı ;

Test ortamımızda, diskte yer probleminden dolayı tüm backuplarım fail etmiş durumda, sizler production database’ lerinizde tümünü succesful olarak göreceğinizi tahmin ediyorum.

31 – Wievler ve Yetki Kontrolleri ;

Denetimler esnasında dikkat edilen bir diğer nokta ise, görüntüler yani viewlerdir. Database’ de yer alan view’ lerin neler olduğuna bu viewlerde hangi alanların görüntülendiğine ve bu viewleri kimlerin görüntülediğine dikkat edilmektedir.

Database’ deki tüm view’ leri sorgulamak için ;

select * from all_objects where OBJECT_TYPE ='VIEW';

Script çıktısı ;

Bu viewler üzerindeki yetkileri görmek içinse;

selectgrantee, owner ,table_name ,privilegefrom dba_tab_privs

where table_name in(

select view_name table_name from dba_views)

Script çıktısı ;

32 – Public Synonym Kullanımı Denetimi ;

13. maddede public database linklerden bahsetmiştik. Public db linkler nasıl ki yetkisiz erişimlere olanak sağlıyor ise public synonym’ lerde bu kapsamda değerlendirilmekte olup açık olarak işlem görmektedir. Adında anlaşılacağı üzere siz bir tablo üzerinde public synonym oluştursanız bütün veritabanı kullanıcıları bu synonym’ ler üzerinden tabloları okuyabilir hale gelebilmektedir. (public userına da ilgili tablo için grant hakkıda verildiğinde) Dolayısıyla bu açıdan bakıldığında public synonym’ ler veri güvenliği açısından bakıldığında kullanılması pek istenilmeyen nesnelerdir.

Database’ de kullanılan synonym’ leri tespit etmek isterseniz ;

select * from dba_synonyms;

Script çıktısı ;

Yukarıdaki tabloda owner schemalarına ait public erişimlerin olup olmadığı ve owner schemalarına erişimin public synonym’ ler aracılığıyla sağlanıp sağlanılmadığı incelenecektir. Developer’ lar eğer yazılım yaparken sorgularında kullanıdığı tabloların başına schema isimlerinide yazarlarsa aslında public synonym kullanımın büyük ölçüde önüne geçilmiş olacaktır. Public synonym’ in kolaylık açısından bir çare gibi algılanmasında son derece karşı olduğumuzu da belirtmeden geçemeyeceğiz.

Yaklaşık 32 madde de nelerin nasıl denetlendiğini özetlemeye çalıştık.En azından denetimin arkasında nelerin kontrol edildiği konusunda artık herkes fikir sahibi olmuştur diye düşünüyoruz.

Bilgi paylaştıkça çoğalır düşüncesinden hareketle, bu konudaki her türlü fikre diğer tüm yazılarımızda olduğu gibi sonuna kadar açığız. Sizler de denetim maddeleri arasında bu da var dedikleriniz var ise lütfen yorum olarak eklemekten çekinmeyiniz, sizlerin de katkısıyla bu alanda güzel bir yazıya imza atmış oluruz diye düşünüyoruz.

Umarım faydalı olabilmişizdir.

Yazarlar:

Kamil Türkyılmaz

Çağatay Işıkcı

Referans ;

1) http://www.bilgisite.com/oracle/UEKAE%20BGT-5001%20Oracle%20Veritaban%C4%B1%20G%C3%BCvenli%C4%9Fi%20K%C4%B1lavuzu.pdf

2) http://www.petefinnigan.com/tools.htm

3) http://www.bilgiguvenligi.gov.tr/kayit-yonetimi/veritabani-loglama.html

4) http://www.bilgiguvenligi.gov.tr/bt-guv.-standartlari/cobit-denetimleri-acisindan-bilgi-guvenligi.html

Bu yazıda Oracle veritabanı uzmanlarının en sık karşılaştığı sorunlardan olan; problem yaşayan kullanıcıların yaptığı işlemlerinin online olarak izlenmesi ve hangi işlemlerin iyileştirme için hedeflenmesi, kullanıcıların kullandığı programın aynı komutta farklı bind değişkenleri girildiğinde SQL Planında ne tür bir değişme olduğu, bunun genel sistem performansına olumlu veya olumsuz etkileri nelerdir gibi komplike sorulardır. Ayrıca Oracle sistem performansının değerlendirilmesinde ilgili SQL komutlarının yaptığı beklemeler, kilitler ve farklıbind değişkenleri kullanıldığında muhtemel ORA hatalarıda bazen bir Oracle DBA’in saatlerini almaktadır. İşte bu noktada ham izleme dosyaları başka hiç bir sistemin veremeyeceği çok değerli bilgileri saklamaktadır.

Ham formattaki izleme dosyalarını okunabilir formata dönüştürmek için kullanılan en yaygın araç olan TKPROF ne yazıkkibind değişkenlerini rapora ekleyememektedir. Ayrıca TKPROF içinde aynı anda birden fazla işlem tarafından kullanılan bloklar listelenmemektedir. Bu gibi kısıtlamalar sebebiyle, TKPROF aracına alternatif olarak Oracle’ınücretsiz bir aracı olan “Trace Analyzer” aracı Oracle Metalink’ten indirilip kullanılabilir. Böylece, aynı anda birden fazla işlem tarafından kullanılan ve kilite sebebiyet veren segmentler ve ilgili bloklarda(biz buna “hot blocks” diyoruz) raporlandığı gibi ilgili SQL komutlarının hash değerleri ve aldığı farklı bind değerlerini yaptığı beklemeler ve yürütme planı çerçevesinde görme imkanına sahibiz.

“Trace Analyzer” aracı ile tek bir ham izleme dosyası analiz edilebildiği gibi, istenirse birden fazla ham izleme dosyasıda tek bir rapor gövdesinde alınabilmektedir. Analiz işlemi sonunda elde edilen zip dosyada TKPROF raporu yer aldığı gibi, çok kapsamlı bir HTML formatta raporda yer almaktadır.

Trace Analyzer aracı ile izleme analizinin raporlanması işleminden önce aşağıdaki adımların sırasıyla uygulanması gerekmektedir.

1. İlk aşamada; Trace Analyzer aracının Oracle Metalink’ten indirilmesinden sonra SQL*Plus komut satırından SYS ile oturum açıp TRCA aracı aşağıdaki gibi kurulmalıdır. Benim trca dosyalarım C:\trca altında yer almaktadır.

SQL> @C:\trca\install\tacreate.sql

Kurulum esnasında bazı sorulara cevap verilmelidir:

· Optional Connect Identifier: Bazı kısıtlamalı sistemlerde @<instance_adı> şeklinde belirtilir. Opsiyoneldir. Eğer gerekli değilse boş bırakıp enter tuşuna basın.

· TRCANLZR password:Trace Analyzer aracını çalıştırmak için şifre. Opsiyoneldir.

· TRCANLZR default tablespace:Trace Analyzer kurulumunda gerekli olan tablo ve görünümlerin kurulacağı varsayılan tablespace ismi. USERS tablespace varsayılandır.

· TRCANLZR TemporaryTablespace:Trace Analyzer çalışırken bilgilerin tutulacağı geçici tablespace. Varsayılan olarak TEMP dir.

· Type of largeobjects in TRCA repository: TRCA ambarında büyük objelerin geçici veya kalıcı olarak tutulma seçeneği. T olarak geçici olması tavsiye edilir.

2. Oturum bazlı izlemenin etkinleştirilmesi gerekmektedir. İzleme dosyaları varsayılan olarak udump dizini altında yer almaktadır ve izleme açıldığında çok sayıda izleme dosyası oluşturulacağından, hangi dosyanın bizim izlemek istediğimiz kullanıcının SQL işlemlerini içeren izleme dosyası olduğunun belirlenmesinde sıkıntı olacağından, başlayacak olan izleme dosyasına bir IZLEME1önekli bir “isim tanımlayıcı” ekliyorum.

SQL> ALTER SESSION SET tracefile_identifier='IZLEME1';

3. Ardından izlenmesini istediğimiz oturumun SID ve SERIAL# değerleriyle birlikte bekleme ve binddeğişkenlerininde izleme dosyasında tutulmasını istediğimizden aşağıdaki izleme komutunu devreye sokuyoruz. Örneğimde 10 numaralı SID ve serial numarası ise 115.

SQL>execdbms_support.start_trace(sid=> 10, serial#=>115, waits=>true,binds=>false);

NOT: İlgili kullanıcının hangi SID ve SERIAL# değerine sahip olduğunu bulmak için aşağıdaki sorgu kullanılabilir.Aşağıda TEST domainindeki UGUR adlı aktif durumdaki windows kullanıcısının SID ve SERIAL# değerini buluyorum.

SQL> SELECT OSUSER, SID, SERIAL#, USERNAME, STATUS

FROM v$SESSIONwhere UPPER(OSUSER) = 'TEST\UGUR’

AND status = 'ACTIVE';

4. SQL*Plus ekranından SYS kullanıcısı ile oturum açıp aşağıdaki gibi TraceAnalzer aracı ile “nunicist_ora_656_IZLEME1.trc” adlı izleme dosyasının analizini yapıyorum. Sonuç olarak zip uzantılı bir dosya oluşturulacaktır.

SQL> @C:\trca\run\trcanlzr.sql nunicist_ora_656_IZLEME1.trc

Eğer birden fazla izleme dosyasının analizinitek raporda yapmak istersek, bu durumda udump dizininde control_file.txt adında bir text dosya oluşturup, analizinin yapılmasını istediğimiz tüm izleme dosyalarının adlarını bu text dosya içine alta alta yazıyoruz. Bu durumda aşağıdaki gibi çalıştırıldığında control_file.txt dosyası içindeki izleme dosyaları TRCA tarafından okunur, analiz edilir ve tek bir rapor formatında listelenir.

SQL> @C:\trca\run\trcanlzr.sql control_file.txt

Aşağıda “Trace Analyzer” aracı ile sekiz adet ham izleme dosyasının birleştirilip, analiz edilerek elde edilen tekil raporda yer alan önemli kısımları ele alacağım. Elde edilen zip dosyasının içindeki HTML raporunu kullanmaktayım.

Bu HTML formatındaki analiz raporun ilk kısmında yer alan “Response Time Summary” bölümünde izleme dosyasındaki işlemlerin toplam cpu kullanım süresi, yüzdesel cevap süresi, toplam işlem süresi, boşta bekleme süresi gibi genel değerler yer almaktadır.

Hem recursive(özyinelemeli) hemdenon-recursive işlemlerin genel anlamda çözümleme(parse), çalıştırma(execute), satır alıp getirme(fetch) istatistikleriyle birlikte genel bekleme istatistiki bilgileri yer almaktadır. Aşağıda non-recursive ile ilgili bilgilerin olduğu snapshot yer almaktadır.

Bu kısımların altında rapor kapsamında yer alan izleme dosyalarının(veya dosyasının) içinde, %10 eşik değerini toplam cevap süresinde(total response time), işlem süresinde(elapsed time) ve CPU süresinde(CPU time) aşan SQL komutları sırasıyla yüzdesel değerleriyle yer almaktadır. SQL Text kısmında ilgili SQL cümlesinin üzerine mouse ile geldiğinize o SQL cümlesinin bütününü görebilmektesiniz.

“SQL Genealogy” kısmında rapor kapsamındaki tüm SQL komutlarını çalıştırılma sayısı, recursive cevap süresi ve bireysel cevap süresi gibi kriterlerde görebiliriz. Sorunlu SQL komutları kırmızı ile belirtilerek seçimde yardımcı olmaktadır.

“SQL Self – Time, Totals, Waits, Binds and Row Source Plan” bölümü altından hash değerlerine göre SQL komutlarının bireysel olarak bekleme istatistikleri, aldıkları bind değerleri ile ilgili istatistiksel bilgiler, satır kaynak planları yer almaktadır.

Aşağıdaki gibi çalıştırılan SQL komutunun yürütme planı ve bekleme istatistikleri yer alacaktır. Burada her bir WHERE şartında geçen kıyaslamaların hangi satır kaynak işlemini yaptığı, indeks kullanıp kullanmadığı, Full Table Scan yapıp yapmadığı görülebildiği gibi her bir satırın ne kadar kaynak tükettiği ve ne tür bekleme olayına sebebiyet verdiği gözlemlenebilmektedir.

Bunun ardından yer alan “RelevantExecutions” kısmında ise bu SQL komutunun benzer şekilde çalıştırıldığı farklı bind değerleri ile ilgili genel liste yer almaktadır. Burada hangi bind değerinin ne kazda SQL cevap süresine sahip olduğu, ne kadar sürede işlmein tamamlandığı ve işlem süresince ne kadar CPU tükettiği gibi istatistiksel bilgiler yer almaktadır.

“Rank” kolonundan hangi bind değerinin ne kadar yanıt süresi verdiği yüzdesel görülmektedir. “Rank” kolonundaki değerlere tıklandığında ise ilgili bind değerinin execute-fetch istatistiği, yaptığı bekleme bilgileri ve bind değişkenin veri tipleri, veri uzunluğu ve aldığı değerler listelenmektedir.

Daha sonraki kısımda ise izleme dosyasındaki işlemler tarafından kullanılan segmentlerin I/O istatistik bilgileri listelenmektedir. Buradan hangi objenin hangi I/O bekleme olayına sebebiyet verdiği görülebilmektedir. Tablo ve indekslerin hem obje bazımda hemde bağlı oldukları blok sayısı olarak hangi bekleme olayına sebebiyet verdiği, ne kadar süre bekleme yaptığı gerek toplam, gerekse ortalama bazda listelenmektedir.

Bunun ardından ise en fazla dokunulan “hot” objeler dosya numarası ve blok id leri ile birlikte listelenir. Bu kısım veritabanı performansında oldukça önemli bir kısım olarak karşımıza çıkmaktadır.

Ardından SQL işlemlerinde varsa alınan ORA hataları kodu, meydana gelme zamanı ve ilgili SQL Text ile birlikte raporlanır, ayrıca birden fazla izleme dosyası traceanalyzer ile tek raporda alındıysa her bir izleme dosyasının işlem özet bilgiside“TransactionSummary” kısmında yer alır. Aşağıdaki ORA-01722 kodlu hata mesajları, kullanıcının 16220719891 numaralı SQL komutunda yanlış bind değeri kullandığını işaret etmektedir.

TraceAnalzer aracı özet olarak; performans sorunu yaşanan uygulamalarda gerek oturum bazlı, gerekse veritabanı bazlı yapılan izlemeler sonucu tüm SQL işlemlerinin gerek bekleme bazlı, gerek çalıştırma planı bazlı ve gerekse farklı bind değişkenlerinin sisteme etkisini ham veri olarak tutan izleme dosyalarının profesyonel açıdan sistem tarafından otomatikman analiz edilmesinde oldukça geniş bakış açıları sunmakta ve oluşturulan zengin içerikli HTML raporu ile gerçek darboğazların tespitinde tüm Oracle DBA’lere oldukça faydalı olmaktadır. Diğer bir önemli özelliği ise Oracle tarafından müşterilerine ücretsiz olarak sunulmasıdır.

Bu makalede Suse Enterprise Server 11 SP1 X64 üzerine Oracle 11GR2 X64 database kurulumunu anlatacağım. Linux kullanmaya yeni başlayanlar için Suse işletim sisteminin linux ailesinin Microsoft’u diyebilirim. Susenin user friendly bir yapısı var. İster Yast grafik arayüzü ile kullanın isterseniz komut satırıyla seçim size kalmış.

Suse, Oracle 11g için ölçeklenebilirlik, performans ve güvenlikle ilgili standardlar sunmakta. Bilgi için bu adrese göz atabilirsiniz.

http://www.suse.com/partners/alliance-partners/oracle/

Kurulum aşamasına geçmeden önce belirtmek istediğim önemli noktalardan biri daha önceden gerçek ortamda çalışmak suretiyle kurduğum ESX 5.0 ve Hyper-V 2008R2 üzerinde herhangi bir sorunla karşılaşmamış olmam.

Kurulumu Vmwareworkstationüzerinde yapıyorum

Yeni bir Suse kurulumuna başlıyorum.

Suse’yi ilk kez kuracak olanlar aşağıdaki resimde yeşil renkle üstünü çizdiğim Oracle ile ilgili paketleri seçmeleri gerekir.

Disk yapısından bahsedecek olursam, Ham 60gb disk alanım var. 20gb root, 5 gbswap, /data isimli mount ettiğim kısma oracle veri tabanının çalışacağı yeri 35 gb olarak ayırdım.

Not: Sistemde 2 gb ram mevcut. Bu durumda Swap’ı iki katı kadar ayarlamak yeterli olacaktır. Swap, sunucunuzda bulunan ram ile hesaplanmalıdır. Ben swap alanına 5 gb verdim.

Install seçeneğini seçip suse kurulum dosyalarını kopyalamaya başlıyor.

Ipv6 ve firewall kısımlarını disable ediyorum.

Network Interfaces kısmından işletim sistemine static ip veriyorum, otomatik olarak DHCP sunucusundan ip adresi almışsa ileride oracle kurulumunda sorun çıkmakta.

Kurulum tamamlandı. Root şifremi belirledikten sonra sıra Oracle kullanıcısı yaratmaya geldi. Yastcontrol panelinden User and Group Management kısmına geliyorum. Suse de Oracle kullanıcısı default olarak gelmektedir ve systemusers kısmında yer almaktadır. Ayrıca yaratmanıza gerek yoktur.

Oracle kullanıcısının ayarlarında, homedirectory kısmında oracle’ınhome dizininde herhangi bir değişiklik yapmıyorum. Hemen altındaki Move to New Location seçeneği home klasörümüzde dosyalar varsa bunu yeni path’ine taşır.

Terminal console ile bağlanıp root kullanıcısıyla, etc/profile.d dizini içersinde oracle.sh dosyasını kendi ayarlarıma göre düzenliyorum. Vi editörünü kullanıyorum.

Komutum vi oracle.sh

Oracle_BASE: kurulacak yer

ORACLE_HOME: kısmı oracleversiyonuna göre verilerin tutulacağı alan olarak belirliyorum

ORACLE_SID kısmında herhangi bir değişiklik yapmadım. Default olarak gelen orcl ismiyle veri tabanına erişim sağlayacağım.

Rac yapısı kullanmayacağımdan For Rac ile ilgili kısımda bir değişiklik yapmıyorum.

Vi editörüyle değişiklikleri wq! Şeklinde kaydedip çıkıyorum. Daha sonra yine komut satırından moreprofile.d dediğimde yeni değişikliklere bakabilirim.

Yine yastcontrol panelden Oracle ile ilgili bir kaç ayar yapmam gerekmekte. Bunlardan bir tanesi ORACLE_BASE kısmındaki kendi path im olan /data/app/oracle olarak değiştireceğim.

Database ve Listener servislerinin işletim sistemi başladığında otomatik olarak açılması için yaptığım ayarlar.

Terminal de root ile login olduktan sonra /data klasörünün içerisinde bulunan tüm dosyaların oracle tarafından çalıştırılması işlemini yapacağım.

Not: Buraya kadar olan bütün işlemleri root kullanıcısıyla yaptım.

Oracle ile ilgili işletim sisteminde tüm hazırlıkları yaptık. Artık kurulum aşamasına geçebiliriz.

Oracle 11gr2 iki dosyadan oluşmakta unzip komutuyla partları ayrı ayrı açıyorum. unzip linux_11gR2_database_1of2.zip komutu ile dosyaları ziptençıkartıyorum. İkinci part için aynı işlemi yapıyorum unzip linux_11gR2_database_2of2.zip. Her iki partı açıp tek dosya halinde oluşturuyor. Dosyamızın ismini database olarak kendisi yaratıyor. Bu işlemleri Suse de Oracle kullancısıyla login olarak yapıyorum.

Database klasörünün içeresinde runInstallerbatch dosyasını çalıştırıyorum.

İkinci aşamada Update’leri indirmek için bizden mail adresi istiyor ben boş geçip devam ediyorum

Burada üç seçenek karşıma çıkıyor. Birinci seçenek software ve veri tabanını oluşturur. İkinci seçenek sadece software’ı kurar, üçüncü seçenek ise daha önceden kurulmuş oraclevery tabanını upgrade etmek için kullanılır. Ben ilk seçeneği seçip devam ediyorum.

Bir sonraki ekranda desktopclass ve serverclass seçenekleri gelmekte. Server Class seçeneğini seçip next ile devam ediyorum

SingleInstance Database seçeneğiyle devam ediyorum

Bundan sonraki ekranda Advanced Install seçeneğini seçiyorum. Detaylı ayarları buradan yapacağım.

Oracle veri tabanı dilini Ingilizce kuracağımdan default olarak gelen English seçeneğiyle devam ediyorum

Bir sonraki ekranda Oracle lisans durumuna göre next deyip devam ediyorum.

Oracle veri tabanının kurulum yeri olan /data/app/oracle dizini otomatik olarak geldi. Next deyip devam ediyorum

Veri tabanının ne amaçlı kullanılacağını seçiyorum. İlk seçenek OLTP veritabanı, ikinci seçenek ise veri ambarı seçeneği, ilk seçenekle devam ediyorum.

Oracle veri tabanı SID adını, suseninoracle parametrelerinde yapmıştım hiç değiştirmeden devam ediyorum. (Global Database Name kısmı farklıda olabilir)

Memory ayarlarını Oracle’ın otomatik olarak yapmasını istiyorum. Daha sonra ileride kendim manuel olacakta ayarlayabilirim.

Bu kısım çok önemli karakter setin Turkish WEISO8859P9 olması gerekmekte.

Enterprise Manager (Veri tabanı yönetimi)’ın yükleneceğini söylüyor. Next ile devam ediyorum.

File system dosyalarının nerede tutulacağını söylüyor herhangi bir değişiklik yapmadan next ile devam diyorum.

Otomatik backup kullanmayacağımdan hiç bir değişiklik yapmıyorum.

Her kullanıcı için ortak şifre giriyorum. İsterseniz siz SYS, SYSTEM, SYSMAN, DBSNMP kullanıcıları için ayrı ayrı şifreler seçebilirsiniz

Oracle’ın işletim sisteminde hangi gruplara üye olduğunu seçmiştim. Dba ve Oinstall gruplarını değiştirmeden devam ediyorum.

İstersem Save Response File seçeneği ile şu ana kadar olan ayarları text dosyaya çıkarabilirim. Bir sonraki oracle kurulumunda kullanabilirim. Finish seçeneğiyle oracle veri tabanı kurulumunu bitiriyorum.

Kurulumun başarılı bir şekilde tamamlandığını görüyoruz.

Aşağıdaki ekranda iki tane scriptiçalıştırmam gerekiyor. Bu işlemi root kullanıcısıyla login olup yapmam lazım. Permision, write, read gibi haklerı vermem lazım.

Son olarak /data/app/oracle/product/11.2.0/db_1/install klasörünün içersindeoratab dosyasını editliyorum. Dosyasının içersindeorcl:/data/app/oracle/product/11.2.0/db_1:N olan kısmı Y yapıyorum kaydedip, kapatıyorum ve bunu etc system dosyasının altına yapıştırıyorum. Buradaki amaç sistemin yeniden başladığın Oracle database’in otomatik olarak başlaması. Oracle kullanıcımın etc system dosyasına yazma hakkı bulunmadığından Root ile login olup cp komutuyla kopyaladım.

Oracle kullanıcımla işletim sistemine login olduktan sonra terminal konsolundan oracledatabase’ine bağlanıyorum.

Enterprise Manager da çalışmakta.

Bir sonraki makalemizde görüşmek üzere.

Bu makalemde oracle üzerinden data pump ile export ve import alımını anlatacağım. Bir önceki makalemde Suse Enterprise Server SP1 üzerine Oracle 11GR2 database kurulumunu anlatmıştım.

http://www.cozumpark.com/blogs/oracle/archive/2012/07/08/suse-enterprise-server-11-zerine-oracle-11gr2-database-kurulumunu.aspx

Aynı database üzerinden işlemleri gerçekleştireceğim. Bu işlemi Oracle Veritabanı kurulu olduğu işletim sistemi üzerinden yapabildiğim gibi herhangi bir oracle client yüklü makinadan çalıştırabilirim. Eskiden kullandığımız export ve import dan farklı olarak, DataPump komutunun Veritabanı ve Client versiyonları birbirleriyle aynı olmalı. DataPump Sunucu tarafında calısan bir uygulamadır. Veritabanına baglanabilmek icin oncesinde ,Client kurulu bilgisayar uzerindeki C:\app\oracle\product\11.2.0\client_1\network\admin dizinin içersindeki TNSNAMES.ora dosyasını düzenlemeniz gerekir.

Clientdan tnsping ile bağlanılabilirliğini kontrol edebilirsiniz.

Sıra geldi oracle da directory yaratmaya. DTPUMP isimli directory yaratıyorum. Directory Sunucu üzerindeki Local bir adres tanımı icermektedir.Dump dosyasımın yaratılacagı locasyonu vermeliyim.Sqlplus ile login olup aşağıdaki sql’i çalıştırıyorum. Dikkat edilecek önemli nokta directory kısmının nerede olacağı. İşletim sisteminde /data klasörünün içersinde backup isimli bir klasör oluşturacağım. (Dilerseniz siz ismi istediğiniz gibi verebilirsiniz)

CREATE OR REPLACE DIRECTORY

DTPUMP AS

'/data/backup';

Expdp komutumla datapumpın directory kısmını yazıyorum. Ona yukarıda ‘DTPUMP’ ismini vermiştim. Dmp dosyamın adı yedek.dmp, log dosyasının isminide yedek.log olarak yazıyorum. İstatistikleri toplamasını istemediğimden exclude dedim ve mevcut database’in bütün yedeğini alıyorum. O yüzden full=yes dedim. Kullanıcı adı ve şifreyi girdikten sonra export başlamış oluyor.

Export işlemini successfully completed demesiyle sona ermiş oluyor.

İşletim sisteminde /data/backup’ın altında iki adet dosya oluştu.

Linux de more komutuyla log dosyasının içersine bakabilirim. Komutum more yedek.log

Log dosyasının içersinde veritabanına ait bilgiler bulunmakta. Export versiyonu, hangi tarihte başladığı, export komut satırı, tabloların büyüklüğü ve satır sayısı, dump ‘ın yaklaşık büyüklüğü bilgileri bulunmakta. Datapump ile export bu şekilde alınmakta. Tabi siz isterseniz schema bazlı da export alabilirsiniz. Expdp nin komutlarını expdp help=yes dediğinizde görebilirsiniz.

Import kısmı export ile hemen hemen aynı.

Impdp komutunu kullanıyorum. Directory kısmı aynı ve export ile aldığım dmp dosyamın adını yazıyorum. Logfile kısmında yedek.imp.log dedim çünkü bir önceki logumu ezsin istemedim. Full=yes deyip importa başlıyorum.

Import bitti fakat 8034 error verdi korkulacak bir durum yok J Mevcut objelerin var olduğundan o hatayı verdi. More yedek.imp.log ile baktığımda objelerde already exists ibaresini görüyorum

Exporttaki gibi yine importta, tarihi, import komutu gibi bilgiler almakta. Import komutunun detayı için impdp help=yes diyebilirsiniz.

Evet datapump ile import ve export nasıl alınır, veriliri gördük. Bir sonraki makalede görüşmek üzere.

Kullanıcı (cihaz , varlık) ‘dan birinin , dataya (kaynak ,uygulama) erişmek için kimlik doğrulama yapması gerekmektedir. Kimlik doğrulama, güvenli bir şekilde belirli bir veriye erişimi sağlar. Kimlik doğrulamadan sonra, sahip olunan yetki işleme izin verir yada erişim basamaklarına limitler koyar. Bu erişim basamakları Oracle da privileges , roles , profiles ve resource limitations dan yapılandırılır.

Kulllanıcıların kimlik doğrulama yapabilmesi için, bazı işletim sistemleri bilgi kullanması için Oracle’a izin verir. Yani bir kez işletim sistemi ile kimlik doğrulama gerçekleştirildiğinde, kullanıcı adı ve şifre belirlemeden Oracle ‘ a bağlanılabilir.

Örn: İşletim sisteminde kimlik doğrulama SQL plus ‘a başvurur. Kullanıcı adı ve şifreyi yönlendirir.

Oracle veritabanı kimlik doğrulaması gerçekleşebilmesi için kullanıcının oracle veritabanı ile bağlantı kurması gerekmektedir. Bu sebeple kullanıcı adı ve şifreyi tanımlamalıdır. Bu işlem veritabanı ‘na yetkisiz erişimleri önler, eğerki kullanıcı hatalı şifre işlemi sağlarsa bağlantı engellenir.

Oracle 11g ‘de Kullanıcı Doğrulama (Authentication – Standart Logon Process) Adımları ;

Oracle 11g de kimlik doğrulama adımları aşağıdaki sırayı takip eder.

1. Client logon adını Db’ye gönderir.

Tool üzerinden kullanıcı adı ve şifre bilgisini girdiği anda DB tarafına logon bilgisini iletmiş olur.

2. DB logon bilgisine karşılık , bir challenge gönderir. Challenge random number(salt) ile şifrenin hashlenmesinden oluşur.

Challenge = Hash(ran num + şifre)

Client şifreden hashi hesaplar ve random number’ı decyrpt eder.Böylece random numarın açık halini elde etmiş olur.

3. Client random number’ı (salt) şifreyi encyrpt etmek için anahtar(key) olarak kullanır ve bu bilgiyi db’ye gönderir.

Üçüncü adımın sonunda kimlik doğrulama işlemi gerçekleşmiş olur.

Şifre USER$ tablosu altında tutulur ve burada açık bir şekilde tutulmaz. Şifre bir hashleme algoritmasına tabi tutulur.Bu algoritma tek yönlü bir hashleme algoritmasıdır.

Oracle 11g ‘de hash algoritması olarak SHA-1 kullanılır. Oracle 11g hash Algoritması aşağıdaki adımları takip eder;

1. Random bit (salt) yaratılır.

2. Şifre , salt ile birleştirilir. (password +salt)

Burada şifre büyük harf küçük harf duyarlı bir şekilde birleştirilir. (case sensitive)

3. SHA-1 kullanılarak hashli string elde edilir.

4. Hash value ile random number(salt) birleştirilir.Bu değer ise db ‘de tutulur.

Dördüncü adımda kullanıcı db’ye authenticate olurken şifre saklandı.Hash’in farklı bir değerde gelmemesi için aynı random sayı kullanıldı.

Oracle 11g öncesinde çalışan Oracle’ın özel hash algoritması ise aşağıdaki adımları takip eder;

1. Kullanıcı adı , şifre ile birleştirilir.Ve tamamı büyük harfe çevrilir.

Bunun sebebi Oracle 11g ‘den öncesinde Oracle’ın büyük harf küçük harf duyarlılığı olmamasıydı(case insensitive).

2. Elde edilen string’in uzunluğu 16 bit oluncaya kadar “0”(sıfır) ‘lar ile tamamlanır.

3. String’i 3DES /CBC(chiper block coding) kullanarak fix key kullanarak encyrpt eder.

4. Encyrpted text ‘in son 8 karakterini yeni bir anahtar (key) olarak alınır.

5. String tekrar 3DES /CBC kullanılarak encrypt edilir. Şifrelerken 4. Adımda elde edilen anahtar kullanılır.

6. String’in son 8 karakteri alınır ve hex ‘a ya çevrilir. Böylece elimizde 16 bitlik hashli karakter dizisi olur.

Oracle ‘da Taşınan Veri

Oracle veritabanında, veritabanına yetkili erişim olmadan verinin ele geçirilebilmesi için çeşitli yollar mevcuttur. Çünkü veri hem trafik olarak network üzerinden geçmektedir hem de dosyalar üzerinde saklanmaktadır.

Network üzerinden geçen trafik üçüncü şahıslar tarafından izlenebilir ve hassas veriler çalınabilir. Aynı zamanda hassas veri içeren bilgiler, işletim sistemi üzerinde dosya olarak saklanmaktadır. Bu dosyalara yapılan yetkisiz erişimler olması durumunda hassas veriler çalınabilir.

Oracle Veritabanı Trafiğinin Şifrelenmesi

Oracle veritabanı bağlantılarının çoğu, bilgisayar ağları üzerinden yapılan (uzaktan) bağlantılardır. Dolayısıyla veritabanı trafiği bilgisayar ağları üzerinden geçmektedir. Veritabanı trafiği TNS protokolünü kullanarak TCP/IP paketleri halinde bilgisayar ağları üzerinden iletilir. Trafiği daha iyi analiz edebilmek adına oluşan veritabanı trafiği üç genel başlık altında sınıflandırılmıştır.

1. Session bilgisini içeren, veritabanına bağlantıyı oluşturan trafik (logon kayıtları)

2. Bağlantı oluşturulduktan sonra çalıştırılan SQL queryler

(Client’dan Server ‘a giden gelen SQL queryler)

3. Çalıştırılan SQL querylere karşı geri dönen cevaplar.

Oracle veritabanı kurulumu da belirtmediğiniz sürece ön tanımlı olarak yapılan yapılandırma ile, veritabanı üzerine gelen ve giden tüm trafik açık metin şeklindedir.

Dolayısıyla araya girebilecek üçüncü şahıslar tarafından trafik dinlenebilir ve hassas bilgiler çalınabilir.

Düz metin trafiğin içeriğine bakabilmek için Wireshark uygulamasını kullanıldığında uygulama ile alınmış olan oturum bilgisi trafiği şekilde gösterildiği gibidir.

Çalıştırılan Query aşağıdaki gibidir.

Query çalıştırıldığında dönen sonuç aşağıdaki gibidir.

Bir başka örnek ise aşağıdadır.

Bu örnekte kullanıcı CREDIT_CARD tablosundan Select sorgusu çeker.

Wireshark ile araya girildiğinde aşağıdaki görüntüler elde edilir.

Yukarıdaki örnekde görüldüğü gibi saldırganın erişimi kalmadan bile hassas verileri ele geçirilebilir. Böyle bir durumda saldırganın bir DB kullanıcısına dahi ihtiyacı olmayacaktır.

Yakalanan trafiklerden anlaşılıyorki hem çalıştırılan SQL querysi hem de bu query karşılık olarak dönen cevap, ağ trafiğinin içinden düz metin olarak geçmekte ve üçüncü şahıslar tarafından görüntülenebilmektedir.

Oracle veritabanı bu tür suistimaller için Advanced Security Option (Oracle ASO) uygulaması yardımıyla veri güvenliğini sağlamaktadır. ASO yardımıyla veritabanı trafiği şifreli hale getirilebilir, veritabanında bulunan hassas verilerin şifreli halde saklanması sağlanabilir.

Oracle ASO İle Veritabanı Trafiğinin Şifrelenmesi

Veritabanı dosyaları harddisk üzerinden kopyalanması, network üzerinden geçtiğinde üçüncü şahıslar tarafından dinlenmesi veya veritabanı backuplarının bulunduğu teyp`ler ele geçirilmesi durumunda hassas veriler yetkisi olmayan kişilerin erişimine açık hale gelmektedir. Bunu önlemenin en güvenli yolu bu verilerin şifrelenerek tutulması veya taşınmasıdır.

Oracle veritabanı tarafından sunulan ASO uygulaması ile verilerin hem ağ katmanında hem de disk katmanında şifrelenerek taşınması ve saklanması sağlamaktadır. Oracle ASO bazı Oracle dağıtımlarında beraber gelmektedir, bazılarında ise sonradan ilave edilebilmektedir.

Oracle ASO için “Oracle Net Manager” kullanılarak yapılandırma, arayüz yardımı ile yapılabilir.

Arayüzü açmak için aşağıdaki komut kullanılır.

$ORACLE_HOME/bin/netmgr

Trafiğin şifrelenmesi için bazı ayarların yapılması gerekir.

Encryption Type” için dört seçenek bulunmaktadır;

REQUIRED: Şifrelemenin gerekli olduğunu belirtir.

Oracle şifrelenmemiş bağlantılara izin vermeyecektir.

REQUESTED: İsteğe bağlı olarak trafik şifrelenecektir. Hem sunucu hem client tarafında bu şekilde seçilmiş ise trafik şifrelenir, aksi durumda şifrelenmez.

ACCEPTED: Oracle`ın “accepted”, client tarafının “required” ve “requested” ayarlaması ile trafik şifreli olacaktır. Burada karar client ‘a bırakılmıştır.

REJECTED: Şifreli trafiğe izin verilmeyeceği anlamına gelir.

Değişiklikler kaydedildiğinde $ORACLE_HOME/network/admin/sqlnet.ora dosyası içine aşağıdaki bilgilerin de kaydedilmesi gerekmektedir.

SQLNET.ENCRYPTION_CLIENT = requested

SQLNET.ENCRYPTION_SERVER = requested

NAMES.DIRECTORY_PATH = (TNSNAMES, EZCONNECT)

SQLNET.CRYPTO_SEED = 'encryption test'

SQLNET.ENCRYPTION_TYPES_CLIENT = (3DES168)

SQLNET.ENCRYPTION_TYPES_SERVER = (AES192, 3DES168, 3DES112)

Şimdi aşağıdaki sorguyu denemek için çalıştırdığımız da ;

Şifrelenmiş verinin wireshark elde edilen görüntüsü aşağıdaki gibi olacaktır.

Oracle ASO kullanımıyla bilgisayar ağları üzerinden geçen veritabanı trafiği şifrelenmiş olup trafiği dinleyen üçüncü şahıslar tarafığından elde edilen bilgilerin düz metin olmaması sağlanmıştır.

Solaris Zfs Pool - Volume Oluşturma ISCSI ile Windows Disk Atama

Oracle Audit Mekanizması

Adım Adım OE Linux 5.3 Üzerine İki Düğümlü Oracle 11g R2 RAC Kurulumu

Oracle 11g RAC Performansı İzleme ve İyileştirme Teknikleri

Oracle 11g R2 11.2.0.2 RAC Mimarisinde Data Guard Kurulumu ve Yönetimi–Dünyada İlk ve Tek!

Oracle Dataguard Mimarisinde Redo Log Taşıma Hizmetlerinin İyileştirilmesi

Oracle 11.2 Veritabanında Maksimum Erişilebilirlik Mimarisinin Yapılandırması

Yaygın Oracle Bekleme Olayları ve İyileştirme Tavsiyeleri

Oracle İnitial Parametreleri

Oracle Tuning Advisor İle Sql Komutlarinin Performanslarinin İyileştirilmesi

TKPROF ile Oracle SQL Uygulamalarının Performans Analizi

Oracle Cube Rollup Kavramları

Oracle Sql Performance Analyzer İle Sql Komutlarının İyileştirilmesi

Oracle Network Konfigürasyonun Optimizasyonu

Windows Server 2008R2 üzerine Oracle 11GR2 Kurulumu

Oracle Veritabanı Denetimleri

Oracle Trace Analyzer İle İzleme Dosyalarının Analizi

Suse Enterprise Server 11 Üzerine Oracle 11GR2 Database Kurulumunu

Oracle Üzerinde Data Pump ile Export ve Import

Oracle Veritabanında Kimlik Doğrulama