Oracle Teknolojileri, Weblogic, SOA Suite, Java, Kurumsal Veri Sözlüğü, API Gateway, API Manager: 01/01/2013

30 Ocak 2013 Çarşamba

kupprdp: worker process DW01 started with worker

kupprdp: worker process DW01 started with worker, eger alertlog`da bu sekilde bir prosesin calistigini goruyorsaniz, veritabani uzerinde datapump (import-export) islemin yapildigi veya hala devam ettigidir.

alterlog.log

ALTER SYSTEM SET service_names='SERVICESO','SERVICE1','ORCL','SYS$SYS.KUPC$C_1_20120530152424.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' SCOPE=MEMORY SID='ORCL';

kupprdp: master process DM00 started with pid=242, OS id=18774
to execute - SYS.KUPM$MCP.MAIN('EXP_FULL_1', 'SYSTEM', 'KUPC$C_1_20120530152424', 'KUPC$S_1_20120530152424', 0);
kupprdp: worker process DW01 started with worker id=1, pid=568, OS id=8654

21 Ocak 2013 Pazartesi

Index Clustering Factor

Soyle bir senaryo dusunelim, varolan bir tablonuzdaki herhangi bir kolon uzerinde index olusturnuz ve sorgunuz where sartinda bu kolon uzerinden bir kosul sagladik ve sorgumuzun execution planina baktigimizda “index range scan” yaziyor. Burada kadar her sey cok guzel, istedigimiz gibi index`imiz calisiyor.

Ama bir sorun var.! Sorgum index range scan plani kullanmasina ragmen bana donen sonuc bekledigimden cok yavas. Acaba bunun sebebi ne olabilir. Bunun sebebi su ki, sorgum index kullanmasina ragmen tablodan cok fazla blok okumasidir. Buda bize Index Clustering Factor degerinin cok buyuk oldugunu gostermektedir.

Index Clustering Factor : Indeks üzerinden tabloya gidildiğinde, her gidişte okunan tablo bloklarının sayısıdır. ICF degeri bir tablodan arka arkaya ayni blogu okudugumuzda artmaz, yeni bloklara gecildigi zaman artar.

Index Clustering Factor degerindende anlayacagimiz gibi, sorgumuzun execution planda index calistigini gorsek bile, sorgumuz sonuc getirirken malasef tablo uzerindeki cok fazla blogu ziyaret etmekte ve buda system uzerinde I/O degerini artirmaktadir. Ve ne kadar cok blog okunursa sorgumuzun cost(maliyet)ini o derecede artiracaktir.

Clustering factor'ü düşük olan bir indeks ile costu cok dusuk sorgulara sahip olabilirsiniz

Clustering factor'ü arttırabilecek faktörlerden birisi tablonun sürekli olarak taşınması(move) veya yeniden oluşturulmasıdır. Tabloya girilen her yeni kayıt ile indeks kendine ait olan mantıksal yapraklarını günceller ve daha fazla clustered olma eğilimine girer. Bu sekilde devam eden bir durumda, clustering factor degerinin nelere gelebilcegine inamamazsiniz.

Peki bu kadat bahsettigimiz clustering factor degerini nasıl düşürebiliriz?Akla gelen ilk yol tabloyu yeniden organize etmektir.Bunu da 10g ile gelen shrink opsiyonu ile gerçekleştirebiliriz. Ancak SHRINK yapildigi zaman, tablodaki indexler kullanilamaz hale gelir ve yeninde rebuild edilmesi gerekmektedir.

Oracle Optimizer Istatistikleri

Bu bolumde asagidaki konulari gorecez.
Cost Based Optimizer (CBO), verilen SQL'i hangi yol ile çalıştıracağını tespit eden bir sistem. Bu sistem aslına bakarsanız oldukça faydalı ve en düşük maliyetli sorgu yolunu seçmekte başarılı.

CBO kimi zaman tablo üzerindeki istatistikler güncel olsa bile doğru sonucu vermiyor olabilir. Burada dikkat, CBO zaten doğru sonuca gidiyor ama "optimum" sonuca gitmiyor olabilir. Bu da şu demek oluyor, CBO kendi hesapladığı maliyeti en düşük olan çalıştırma yoluna girer. Bunu da tablo üzerindeki istatistikleri baz alarak yapar.

Evet yukaridaki tanimlardada belirtildigi gibi, ozellikle tablo ve indexlerin istatistik bilgilerinin guncel olmasi performans acisindan bizim icin cok onemli. Cunku tablo veya indexlerin istatistik bilgileri eski ise optimizet eski olan bu istatistik bilgilerine gore bir execution plan(calisma plani) olusturacaktir.

Peki bizim icin bu kadar onemli olan istatisktik bilgileri nasil toplayabiliriz veya istatistik bilgilerimizin guncel olabilmesi icin ne yapmaliyiz.

Oracle ANALYZE ifadesini kullanarak istatistik bilgileri toplamanız mümkündür. Ancak Oracle 9i versiyonu ile birlikte aramiza katilan ve bir PL/SQL paketi olan DBMS_STATS paketini yapabiliriz ve bu bolume bu paket uzerinden devam edecegiz.

DBMS_STATS bu paketin amaci. Daha once bahsetmis oldugumuz Cost Based Optimizer icin gerekli tablo, index ve diger objeler uzerinde istatistik bilgilerini toplamaktir. Toplanan bur istatistik bilgilerini oracle data dictionaryde tutmaktadir.Oracle istenilirse istatistikleri data dictionary dışında da tutulabilmektedir ve optimizer'ı hic bir sekilde etkilemeden yapabilmektedir. Toplanan istatistikleri başka bir veritabanına da taşıyabilirsiniz.

Simdide optimizer istatistik tiplerine bakalim.

Optimizer Istatistik tipleri

Bu tipleri 4 baslik altinda toplayabiliriz. Bunlara Table, Index, System ve Column

Table Istatistikleri
• Number of rows
• Number of blocks
• Average low length
Index Istatistikleri
• B*-tree level
• Distinct keys
• Number of leag blocks
• Clustering factor
System istatistikleri
• I/O performance and utilization
• CPU performance ve utilization
Column istatistikleri
• Basic : Number of distinct values, number of nulls, average length, min, max
• Historamgs (data distribution when the column data is skewed)
• Extended statistics

Yukarida en cok kullanilan ve bilinen istatistik tiplerini gordurk. Oracle 10g surumu ile birlikte indexlerin istatistik bilgileri, index olusturuldugunda ve yeniden rebuild edilginde otomatik olarak toplanmaktadir.(create or rebuild).

Daha once bahsettigimiz gibi, optimizer istatistik bilgileri data dictionaryde tutulur. Ve bunlari bazi view(goruntu)ler yardimiyla goruntuluyebiliriz. Bu goruntuler performans goruntuleri ile karsilastirilmamalidir.

Tablo istatistikleri icin : DBA_TAB_STATISTICS
Index Istatistikleri icin : DBA_IND_STATISTICS

Peki bu istatistikleri bir manuel olarak toplamak zorundamiyiz.? Oracle'ın GATHER_STATS_JOB isminde bir otomatik istatistik toplayan görevi bulunmaktadır ve hafta içi 22:00'den sonra hafta sonu ise sabah otomatik olarak devreye girerek, veritabanı istatistiklerini toplamaktadır.

Bu sorumuzu cevabini aldikdan sonar akilimiza su gelebilir. Demekki biz, hafta ici gun icersinde bir tablo olusturdugumuzda ve bu tabloya mesala milyonda fazla kayit ekledikden sonar tablonun istatistik bilgileri tabloda 0 rows oldugunu gosterecek ve optimizer execution plani bu istatistik dogrultusunda yapacaktir. O zaman yapmamiz gerek bu durumlar icin, tablonun istatik bilgilerini manuel olarak almaktadir. Daha sonra gece, bu job kendisi otomatik olarak toplayacaktir.

Not: Gun icerisinde bir tabloya cok fazla veri ekleniyorsa, bu job isini yapmasini beklemektense kendimiz bir job yazib bu tablonun istatistik bilgilerini gunde bir kac defa toplamamasina veya 4 saatte bir istatistik toplamasini saglayabiliriz.

Adaptive Cursor Sharing

Bir onceki baslikta gordugumuz bind variable ve cursor sharing yani benzer SQL statement`a sahip SQL`lerin ayni exectuion plani kullanmalarini gormustuk. Ancak bununda dezavantajlarinin oldugunu soylemek mumkun. Mesala benzer olan uc tane SQL ifademiz var, ve cursor sharing oluyorsa ilk calisan SQL icin olusturulan execution plan diger SQL`ler icinde calisacak ve eger ilk calisan SQL hard parse veya FTS(Full Table Scan) yapiyorsa ondan sonra gelen SQL`ler icinde ayni durum olacaktir. Ama diger SQL`ler FTS yapmiyor olabilir. Bu durumda cursor sharing avantajli durumdan cikacaktir.
Oracle 11g surumunden sonra bu durum icinde bir cozum olusturulmustur oracle bu sorunu Adaptive Cursor Sharing ile asabilmektedir.

Adaptive Cursor Sharing : Cost Based Optimizer (CBO)’ın execution planları oluştururken bir statement için daha fazla execution plan tutmasına olanak sağlayan yapı olarak ön plana çıkmaktadır. Bir statement için birden fazla execution planı tutuyor olmak daha önceki versiyonlardan farklı olarak ilk hard parse olan statement’ın planını daha sonra tekrar tekrar farklı parametrelerle çalışan aynı statementlarıda kullanmak zorunda bırakmamak anlamınada geliyor olacaktır. Bind variable kavramındaki execution planları ortak kullandırma mantığının aynı plana sahip olmaması gereken 2 cümle için ortak plan kullandırdığı zaman ne kadar maliyetli (costu yüksek) olduğunu görebiliriz. Mesala asagidaki SQL`i degerlendirelim.

select * from emps where salary= :sal;

Bu SQL icin, mesala :sal degeri once 10000 daha sonrada 2000 olarak set edilsin. 10000 olarak set edildiginde 1 tane sonuc geliyor(yani selectiviysi yuksek) ve execution plani optimizer uzerinde INDEX RANGE olarak calissin ve index uzerinden veriyi getiriyor olsun. Ama :sal degeri 2000 olarak set ettigimizde ise tablodaki verilerin % 40 `I geliyor. Bu durumda hatirlayalim optimizer bir sorguda istenen sonuc tum tablounun tahmini olarak % 10`undan daha fazla ise Full table scan yapilmasi cost(maliyet) acisinda daha avantajlidir.

Simdi ikinci calistiracagimiz SQL`in bu durumunu inceleyelim; Bilindigi gibi bu SQL ifadesi daha birçok kez çalışacaktır ve eğer Adaptive Cursor Sharing(ACS) olmasaydi ilk hard parse olan yani :sal = 10000’e göre oluşan execution plan :sal 2000 içinde uygulanacaktı ve daha avantajli olan Full Table Scan ile gelmesi gereken bir tablo index üzerinden getirilmeye çalışılacak ve response time’ı düşecekti ve sorgunun sonucu daha uzun sürede oluşacaktır.

Adaptive Cursor Sharing`den bilgileri alabilmemiz icin bize yardimci views(goruntuler) mevcuttur.

V$SQL : tablosunda – IS_BIND_SENSITIVE, IS_BIND_AWARE kolonlari
V$SQL_CS_HISTOGRAM : SQL ifadesinin bind sensitive olup olmadığını 3 adet frequency histogram ile yorumlamamızı sağlar. Ayrica Child cursorların kaçar kere çalıştığı bilgisinide içerir.
V$SQL_CS_SELECTIVITY : Bir SQL ifadesi ile beraber gelen where koşulundaki değerleri, bunların selectivitysini ve high value – low value aralığını tutar.
V$SQL_CS_STATISTICS : Adaptive Cursor’ın nekadar paylaşıldığını gösteren istatistik bilgilerini iceren bir view(goruntudur).

Oracle Cursor Sharing`e bakis

Cursor Sharing
Oracle 9i versiyonundan sonra, benzer SQL ifadeleri icin ayni execution plani olusturmaya baslamistir. Sadece literal degeri degisen sorgular icin ilk calisan sorguda olusturulan execution plan diger sorgular icinde kullanilmaya baslanmis ve her sorgu icin yeni execution plan olusturulmamis oldu. Simdi asagidaki iki sorguya bakalim.
SQL> SELECT * FROM emps WHERE dep_id = 100;
SQL> SELECT * FROM emps WHERE dep_id = 20;
Yukaridaki iki sorgumuzda, ikinci sorguyu birinci sorguya bagli olarak, nasil bir execution plan olusturulmus ise ikinci sorgudada ayni execution plan devam edecektir.(Bu Full table scan olabilcegi gibi INDEX RANGE SCAN da olabilir)

Sorgularınızı yazarken dikkat etmeniz gereken konu sorgunun genel yapı olarak sürekli değişmiyor olması. Yaptığınız her en ufak değişiklik Oracle tarafından farklı bir sorgu olarak algılanır ve eğer bir de içeride bind variable yerine literal (numara veya karakter) kullanıyorsanız ve cursor_sharing parametreniz SIMILAR’da kalmış ise arka tarafda cok iyi seyler olmuyor diyebiliriz.

- CURSOR_SHARING bir oracle initilization parametresidir ve Shared pool içerisinde tutulan sqllerin benzerleri geldiğinde aynı plan ile diğerlerininde çalışıp çalışmayacağının set edildiği parametredir (literal(numara veya karakter) kullanımını görüp bunun birer bind variable olarak plan’larının saklanmasını sağlar)
Cursor sharing parametresinin degerleri nelerdir ve nasil degistirebilirim.
• CURSOR_SHARING paremetresinin alabilecegi degerler
- FORCE
- EXACT(default (varsayilan degerdir))
- SIMILAR
• CURSOR_SHARING parametresini nasil degistirebilirim.
- ALTER SYSTEM CURSOR_SHARING = ?
- ALTER SESSION CURSOR_SHARING = ?
- Initializtaion parameter dosyasi icinden degistirebiliriz

Simdi CURSOR_SHARING parametresinin alabilecegi, FORCE, EXACT, ve SIMILAR degerlerinin ne yaptiklarina bakalim.
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.(Yani yazilan, ve benzer butun sql`ler icin ilk olusutural execution planlarin ortak kullanilmasi)
SIMILAR : sql’ lerin birebir aynı olmasa da benzeyenler için (execution planlarına da bakar) cache den çalıştırmaya yönlendirir.

Simdi asagidaki uc SQL` e bakalim ve bu uc sql`in ayni execution plani kullandigini gorecegiz. Oncelikle CURSOR_SHARING parametresini FORCE olarak set edelim.
SQL> alter session set cursor_sharing = FORCE;
SQL> SELECT * FROM emps WHERE salary > 10000;
SQL> SELECT * FROM emps WHERE salary > 15000;
SQL> SELECT * FROM emps WHERE salary > 9000;

Birinci SQL`imiz calsitikdan sonra Oracle bu SQL`e shared pool`da asagidaki gibi bir bind-variable generate ediyor ve bu SQL icin execution plan olusturuyor.

SELECT * FROM emps WHERE salary > :"SYS_B_0";
Daha sonra diger iki SQL calsitiginda bind-variable generate ettigi ve exectuion plani olusuturdugu plani calistiriyor.

Yukaridaki ornekten sunu cikarabiliriz. CURSOR_SHARING parametresi “auto binder”, yani biz sql`imizde bind_variable kullanmiyorsak Oracle bu parametre sayesinde bizim yerimize otomatik bind variable yapiyor.
Simdi bu degerleri veritabanizda degistirerek sonuclara bakalim.

Labs :
SQL> alter system set cursor_sharing='SIMILAR';
System altered.
SQL> select /*TEST_SIMILAR*/ count(*) from system.myobjects where owner='SYS';
SQL> select /*TEST_SIMILAR*/ count(*) from system.myobjects where owner='SYSTEM';
SQL> select /*TEST_SIMILAR*/ count(*) from system.myobjects where owner='SCOTT';

SQL> select sql_id,sql_text from v$sql where sql_text like 'select /*TEST_SIMILAR*/%';
SQL_ID SQL_TEXT
7qsnvbzwh79tj select /*TEST_SIMILAR*/ count(*) from system.myobjects where owner=:"SYS_B_0"
SQL> select sql_id,child_number,EXECUTIONS,LOADS,PARSE_CALLS from v$sql where sql_text like 'select /*TEST_SIMILAR*/%';
SQL_ID CHILD_NUMBER EXECUTIONS LOADS PARSE_CALLS
------------- ------------ ---------- ---------- -----------
7qsnvbzwh79tj 0 3 1 3

Goruldugu gibi, bir tane SQL`imi var ve otomatik olarak bind variable atanmis :SYS_B_0 ve 3 defa cagirilmis.

Simdi “v$sqlarea”`da kactane sqlmiz var bakalim.
SQL> select version_count from v$sqlarea where sql_id='7qsnvbzwh79tj';
VERSION_COUNT
-------------
1

Ayni durumu LIKE kullanarak yapalim ve durumun ne kadar degistigini ve ortaya ayni sqlidye uc tane SQL ciktigini gorecegiz.

SQL> select /*TEST_SIMILAR*/ distinct owner from myobjects where owner like 'A%';
SQL> select /*TEST_SIMILAR*/ distinct owner from myobjects where owner like 'B%';
SQL> select /*TEST_SIMILAR*/ distinct owner from myobjects where owner like 'C%';

SQL> select sql_id,child_number,EXECUTIONS,LOADS,PARSE_CALLS from v$sql where sql_text like 'select /*TEST_SIMILAR*/%';
SQL_ID CHILD_NUMBER EXECUTIONS LOADS PARSE_CALLS
------------- ------------ ---------- ---------- -----------
6hkkxzpas5hyq 0 1 1 1
6hkkxzpas5hyq 1 1 1 1
6hkkxzpas5hyq 2 1 1 1
SQL> select version_count from v$sqlarea where sql_id='6hkkxzpas5hyq';
VERSION_COUNT
-------------
3

Simdi ayni ornegi CURSOR_SHARING parametresini FORCE olarak set edip test edelim.

SQL> alter system set cursor_sharing='FORCE';
System altered.
SQL> select /*FORCE*/ distinct owner from myobjects where owner like 'A%';
SQL> select /* FORCE */ distinct owner from myobjects where owner like 'B%';
SQL> select /* FORCE */ distinct owner from myobjects where owner like 'C%';
SQL> select version_count from v$sqlarea where sql_id='6c4f9xwp19pff';
VERSION_COUNT
1
SQL> select sql_id,child_number,EXECUTIONS,LOADS,PARSE_CALLS from v$sql where sql_text like 'select /*FORCE*/%';
SQL_ID CHILD_NUMBER EXECUTIONS LOADS PARSE_CALLS
6c4f9xwp19pff 0 3 1 3
SQL> select /*TEST_SIMILAR*/ distinct owner from myobjects where object_type='A';
SQL> select /*TEST_SIMILAR*/ distinct owner from myobjects where object_type='B';
SQL> select /*TEST_SIMILAR*/ distinct owner from myobjects where object_type='C';
SQL> select /*TEST_SIMILAR*/ distinct owner from myobjects where object_type='D';
SQL> select /*TEST_SIMILAR*/ distinct owner from myobjects where object_type='E';
SQL> select sql_id,child_number,EXECUTIONS,LOADS,PARSE_CALLS from v$sql where sql_text like 'select /*TEST_SIMILAR*/%';
SQL_ID CHILD_NUMBER EXECUTIONS LOADS PARSE_CALLS
------------- ------------ ---------- ---------- -----------
2m80tr9fhhbwn 0 1 1 1
2m80tr9fhhbwn 1 1 1 1
2m80tr9fhhbwn 2 1 1 1
2m80tr9fhhbwn 3 1 1 1
2m80tr9fhhbwn 4 1 1 1
SQL> select version_count from v$sqlarea where sql_id='2m80tr9fhhbwn';
VERSION_COUNT
5
SQL> select hash_value,address from v$sqlarea where sql_text like 'select /*TEST_SIMILAR*/%';
HASH_VALUE ADDRESS
1560817556 0000000095B58FD8
SQL> select * from v$sql_shared_cursor where address='0000000095B58FD8';
SQL_ID ADDRESS CHILD_ADDRESS CHILD_NUMBER U S O O S L F E B P I S T A B D L T B I I R L I O E M U T N F A I T D L D B P C S C P T M B M R O P M F L P L A F L R L H P B
2m80tr9fhhbwn 0000000095B58FD8 000000009160F6B8 0 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N
2m80tr9fhhbwn 0000000095B58FD8 0000000091633E68 1 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N Y N N
2m80tr9fhhbwn 0000000095B58FD8 0000000091741E10 2 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N Y N N
2m80tr9fhhbwn 0000000095B58FD8 000000008DA39108 3 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N Y N N
2m80tr9fhhbwn 0000000095B58FD8 00000000947D5B30 4 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N Y N N

19 Ocak 2013 Cumartesi

Performance

Oracle Bind variables

Bind Variables

Yukarida uc farkli SQL gormekteyiz. Daha onceki bolumlerdede gormustuk, oracle SQL`leri library cache`de tutmaktadir. Bu uc SQL`de ayni islemi farkli degerlerle yapsa bile, sonuc olarak ayni SQL`dir. Ama acikca goruluyor ki, her uc SQL`de ayri ayri library cahce`de tutulmakta ve her yeni SQL`e yeni sqlmis gibi davraniyor ve SQL statement parse-execute-fecth adimlarini her seferinde yeniden yapmakta ve performans kaybina neden olmaktadir. Hatirlayam, parse islemi en uzun ve en cok zaman alan bolumdu, bizim parse`dan mutlaka kacinmamiz gerekmektedir.

Seklimiz uzerinde yeniden devam edecek olursak, ilk SQL`imiz calisti ve library cache atildi, ikinci SQL calistiginda oracle once library cahce bakiyor ve SQL`i bulamiyor ve yeni bir ayiriyor. Ve her SQL icin yeni bir execution plan olusturuyor.
Bu sekilde bir kullanimda, cursor sharing avantajli degildir.

Oracle veritabanı yazılan SQL ya da PL/SQL kodlarının bir kere yazılıp devamlı kullanılmasına imkan vermektedir. Simdi oracle olan parse islemleri gorelim. Oracle`da iki turlu parse islemi vardir. Ve eger ayni sql bu iki asamadan yapiyorsa sorgularimizi duzenlemeiz gerekmektedir.

Peki bu parse islemleri hangileridir.
• Hard parse
• Soft parse

Hard parse : Oracle veritabaninda SQL ya da PL/SQL kod daha önce kullanılmamış ve shared poolun library cache`inde yoksa sırasıyla parsing ve optimization aşamalarını geçirdikten sonra row-source-generator ve son olarak gerçek anlamda veriyi getiren execution aşamalarından geçmesidir.

Soft parse : Shared Pool (library cache) da var ise elimizde optimizer plan(execution plan) var demektir ve bu da dogrudan “execution” aşamasına geçilebilir anlamına gelmesine isleminde oracle soft parse yapiyordur.

Not : Hard parse ve soft parse ile ilgili cok guzel bir sozu vardir. Soft parse kotudur ama hard parse cok cok daha kotudur. Buradan sunu cikarabiliriz bir kere parse yapılınca aynı kodun devamlı olarak bir daha parse görmeden çalışmasını sağlayabilmemizdir.

Peki bunun nasil yapabiliriz.? Iste burada sorunun cevabi bind variable kullanımıdir.
Sorgularinizda bind variable kullanidigimizda extra parse islemlerinden kurtulmus oluruz ve execution time çok daha kısa sürer(daha once execution plan(optimizer plan) olusturulmustu) ve bu durumda çok kullanıcılı ve yoğun işlemlerin yapıldığı veritabanlarında cok buyuk performans saglamis oluruz.

Performansın yanında parse esnasında library cache alanı da meşgul edileceği için sistem bu anlamda da zorlanacaktır.Çünkü aynı anda pek çok kullanıcı bu alanı kullanmak zorunda kalacaktır.
Simdi yukaridaki seklimizi asagidaki gibi degistirelim.

Seklimizde acik bir sekilde goruluyor ki, library cache`de bi tane sql`imiz var.
Simdi bir SQL*Plus kullanarak bind variable ornegine bakalim.


SQL> variable sal varchar2(10);

SQL> exec :sal := 5000;

PL/SQL procedure successfully completed.

SQL> select count(*) from employees where sal = :sal;

     10

SQL> exec :sal := 10000;

PL/SQL procedure successfully completed.

SQL> select count(*) from employees where salary = :sal;

      3

18 Ocak 2013 Cuma

Indexleri yonetmek icin kurallar

Indexleri yonetmek icin kurallar;
Indexlerden en iyi sekilde performans alabilmek icin, uyulmasi gereken belirli kurallar vardir.

• Create indexes after inserting table data : Tavsiye edilen tablo olusturdukdan sonra icinde veri yokken index olusturmak degilde, daha sonra veriler eklendikten sonra index olusturulmasi. Tabii ki, bu durum import/export islemler olacagi durumlarda dogrudur. Yani siz verilerini yeni bir tabloya tasidiniz o durumlar icin.

• Index the correct tables and columns: Tavsiye edilen, dogru kolonlar uzerinde index olusturulmasidir. Yani, eger index olusturacagiz kolondan sorgu cektiginizde gelen sonuc tum verilerin 15 % `den fazla ise bu durumda olusturdunuz indexin performans acisindan size faydasi degil zarari olacaktir. Index unique olan, email, telno gibi tekil olan kolonlar uzerinde index olusturulmasidir.

• Columns not suitable for indexing: Uygun kolon tipleri uzerinde index olusturmak. Mesala LONG veya LONG RAW kolonlar uzerinde index olusturamazsiniz

• Order index columns for performance : CREATE INDEX cumlesi ile olusturacaginiz indexteki kolonlarin sirasi cok onemlidir. En cok kullanilan kolonlari once yazmaniz performans acisindan daha dogru bir tercih olacaktir.

• Limit the number of indexes for each table: Her tablo uzerinde bir veya birden fazla index olabilir. Ama bir tablo index olustururken belirli bir limiti goz onunde bulundurmakta fayda vardir. Cunku tablodaki verilerin degistirilecegi goz onunde bulundurularak, ve cok fazla kolon uzerinde index olusturmak tabloya kulfettir.

• Specify the tablespace for each index: Eger tablo ve indexleri ayni tablespace icerisinde kullaniliyorsaniz bir cok uygun bir yontem degildir. Cunku, tablespace backup, database maintance yapabilmeniz icin daha cok zaman harcamaniza sebeb olacaktir.

• Consider parallelizing index creation : Index olustururken parallelizm kullanirsa, yani parallel execution kullandiginizda index daha hizli olusuturulacak ve sorgu yaptiginizda 12mb bir data geliyorsa ve 12 parallellik verdiginizde 1mb ve parallel olarak getirecek ve sonuc cok cok daha hizli olacaktir.

• Consider creating indexes with NOLOGGING : Index olustururken NOLOGGING olarak olusturdugunuzda en az sekilde redo log uretecektir.

Uninstall GoldenGate from Linux/Unix

Merhaba, daha once linux/unix uzerine golden gate`i nasil install ettigimizden bahsetmistik, simdi ise nasil silebilecegimize gorelim.

1. Log on, golden gate`in install oldugu server login olunur

2. Change directory, golden gate`in yuklu oldugu directory secilir

[oracle@db1 /]$ cd /u01/app/gg

3. Start GGSCI

[oracle@db1 gg]$ ggsi

4. Stop All Golden Gate process


GGSCI (db1) 1> stop EXTRACT *

 OR

GGSCI (db1) 1> stop REPLICAT *


GGSCI (db1) 2 > stop MGR

prompt : y 


GGSCI(db1) 3> exit


[oracle@db1 /]$ cd /u01/app


[oracle@db1 /]$  rm -rf gg

7. Logon to Oracle Database as SYSDBA, golden gate icin olusuturdugumuz kullaniciyi cascade ederek butun iliskileri ile birlikte siliyoruz.



[oracle@db1 gg]$ sqlplus / as sysdba;
SQL > drop user ggs_admin cascade;

15 Ocak 2013 Salı

Middleware-weblogic-j2ee

Oracle Golde Gate

Golden Gate DDL senkorinasyonu (active-standby)

Bu Makalemizde, iki veritabani arasinda, Kaynak veritabanindaki bir DDL isleminin Hedef veritabanina nasil aktarilacagini gorecegiz.

########################## Kaynak Makinede ###########################
[oracle@db1 gg]$ sqlplus / as sysdba;

SQL> @marker_setup
Marker setup script

You will be prompted for the name of a schema for the GoldenGate database objects.
NOTE: The schema must be created prior to running this script.
NOTE: Stop all DDL replication before starting this installation.

Enter GoldenGate schema name:GGS_ADMIN

Marker setup table script complete, running verification script...
Please enter the name of a schema for the GoldenGate database objects:
Setting schema name to GGS_ADMIN

MARKER TABLE
-------------------------------
OK

MARKER SEQUENCE
-------------------------------
OK
Script complete.

SQL> alter session set recyclebin=OFF;
Session altered.

SQL> @ddl_setup

GoldenGate DDL Replication setup script
Verifying that current user has privileges to install DDL Replication...

You will be prompted for the name of a schema for the GoldenGate database objects.
NOTE: The schema must be created prior to running this script.
NOTE: On Oracle 10g and up, system recycle bin must be disabled.
NOTE: Stop all DDL replication before starting this installation.

Enter GoldenGate schema name:GGS_ADMIN

You will be prompted for the mode of installation.
To install or reinstall DDL replication, enter INITIALSETUP
To upgrade DDL replication, enter NORMAL
Enter mode of installation:INITIALSETUP

Working, please wait ...
Spooling to file ddl_setup_spool.txt

Using GGS_ADMIN as a GoldenGate schema name, INITIALSETUP as a mode of installation.

Working, please wait ...

RECYCLEBIN must be empty.
This installation will purge RECYCLEBIN for all users.
To proceed, enter yes. To stop installation, enter no.

Enter yes or no:yes

DDL replication setup script complete, running verification script...
Please enter the name of a schema for the GoldenGate database objects:
Setting schema name to GGS_ADMIN

DDLORA_GETTABLESPACESIZE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

CLEAR_TRACE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

CREATE_TRACE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

TRACE_PUT_LINE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

INITIAL_SETUP STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

DDLVERSIONSPECIFIC PACKAGE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

DDLREPLICATION PACKAGE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

DDLREPLICATION PACKAGE BODY STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

DDL HISTORY TABLE
-----------------------------------
OK

DDL HISTORY TABLE(1)
-----------------------------------
OK

DDL DUMP TABLES
-----------------------------------
OK

DDL DUMP COLUMNS
-----------------------------------
OK

DDL DUMP LOG GROUPS
-----------------------------------
OK

DDL DUMP PARTITIONS
-----------------------------------
OK

DDL DUMP PRIMARY KEYS
-----------------------------------
OK

DDL SEQUENCE
-----------------------------------
OK

GGS_TEMP_COLS
-----------------------------------
OK

GGS_TEMP_UK
-----------------------------------
OK

DDL TRIGGER CODE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

DDL TRIGGER INSTALL STATUS
-----------------------------------
OK

DDL TRIGGER RUNNING STATUS
-----------------------------------
ENABLED

STAYMETADATA IN TRIGGER
-----------------------------------
OFF

DDL TRIGGER SQL TRACING
-----------------------------------
0

DDL TRIGGER TRACE LEVEL
-----------------------------------
0

LOCATION OF DDL TRACE FILE
--------------------------------------------------------------------------------
/u01/app/oracle/diag/rdbms/ORCL/orcl/trace/ggs_ddl_trace.log

Analyzing installation status...

STATUS OF DDL REPLICATION
--------------------------------------------------------------------------------
SUCCESSFUL installation of DDL Replication software components
Script complete.

SQL> @role_setup

GGS Role setup script

This script will drop and recreate the role GGS_GGSUSER_ROLE
To use a different role name, quit this script and then edit the params.sql script to change
the gg_role parameter to the preferred name. (Do not run the script.)

You will be prompted for the name of a schema for the GoldenGate database objects.
NOTE: The schema must be created prior to running this script.
NOTE: Stop all DDL replication before starting this installation.

Enter GoldenGate schema name:GGS_ADMIN
Wrote file role_setup_set.txt

PL/SQL procedure successfully completed.

Role setup script complete
Grant this role to each user assigned to the Extract, GGSCI, and Manager processes, by using the following SQL command:

GRANT GGS_GGSUSER_ROLE TO

where is the user assigned to the GoldenGate processes.

SQL> grant ggs_ggsuser_role to GGS_ADMIN;
Grant succeeded.

SQL> @ddl_enable
Trigger altered.

SQL> @ddl_pin GGS_ADMIN
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.

Turn Recyclebin OFF

[oracle@db1 gg]$ ggsci

GGSCI (db1) 5> DBLOGIN USERID GGS_ADMIN, PASSWORD GGS_ADMIN
Successfully logged into database.

GGSCI (db1) 6> ADD TRANDATA scott.emp

Logging of supplemental redo data enabled for table SCOTT.EMP.

Edit the parameter file for the Extract process to enable DDL synchronization

We had earlier created a parameter file for an Extract process ext1. We now edit that parameter file and add the entry
DDL INCLUDE MAPPED

This means that DDL support is now enabled for all tables which have been mapped and in this case it will only apply to the SCOTT.EMP
table as that is the only table which is being processed here. We can also use the INCLUDE ALL or EXCLUDE ALL or wildcard characters t
o specify which tables to enable the DDL support for.

GGSCI (db1) 1> EDIT PARAM EXT1

EXTRACT ext1
USERID GGS_ADMIN, PASSWORD GGS_ADMIN
RMTHOST db2, MGRPORT 7809
RMTTRAIL /u01/oracle/gg/dirdat/rt
DDL INCLUDE MAPPED
TABLE scott.emp;

########### Test ##########################################

############# Kaynak Makinede ##############

[oracle@db1 gg]$ sqlplus scott/tiger;

SQL> ALTER TABLE EMP ADD MYCOL VARCHAR2(10);
Table altered.

###### Hedef Makinede ##############3

[oracle@db2 gg]$ sqlplus scott/tiger;

SQL> desc emp
Name Null? Type
—————————————– ——– —————————-
SQL> desc emp
Name Null? Type
----------------------------------------- -------- ----------------------------
EMPNO NOT NULL NUMBER(4)
ENAME VARCHAR2(10)
JOB VARCHAR2(9)
MGR NUMBER(4)
HIREDATE DATE
SAL NUMBER(7,2)
COMM NUMBER(7,2)
DEPTNO NUMBER(2)
NEW_COL2 VARCHAR2(10)
MYCOL VARCHAR2(10)

Golden Gate DML senkorinasyonu (active-standby)

Bu makalemizde, Golden gate ile kaynak veritabanindan, hedef veritabanina, kaynak veritabaninda yapilan bir DML(insert, update, delete) isleminin hedef veritabanina nasil etkilendigini gorecegiz.

Oncelikle Her iki veritabanida archivelog mode olmalidir
##################### Her iki tarfdada ##############################
[oracle@db1 gg]$ ggsci

GGSCI (db1) 1> dblogin userid ggs_admin, password ggs_admin
Successfully logged into database.
GGSCI (db1) 2> add trandata SCOTT.*

################## Her iki makinedede ####################
ggsci > edit param mgr
port 7980
purgeoldextracts dirdat/*, usecheckpoints, minkeepdays 2

ggsci > start manager
Manager started.

ggsci > info manager
Manager is running (IP port canada.7980).

############### Kaynak Makinede #######################################
ggsci> edit param ext1
extract ext1
userid ggs_admin, password ggs_admin
exttrail /u01/app/gg/dirdat/t1
table SCOTT.*;

GGSCI (db1) 8> add extract ext1, tranlog, begin now
EXTRACT added.

GGSCI (db1) 9> add exttrail /u01/app/gg/dirdat/t1, extract ext1, megabytes 100
EXTTRAIL added.

GGSCI (db1) 10> start extract ext1
Sending START request to MANAGER ...
EXTRACT EXT1 starting

GGSCI (db1) 13> info extract ext1
EXTRACT EXT1 Last Started 2013-01-12 20:47 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:03 ago)
Log Read Checkpoint Oracle Redo Logs
2013-01-12 20:48:15 Seqno 5, RBA 6204416

ggsci > stop extract ext1

############# Kaynak makinede ############3

GGSCI> edit param dpump1

extract dpump1
passthru
rmthost db2, mgrport 7980
rmttrail dirdat/t2
table SCOTT.*;

GGSCI (db1) 15> add extract dpump1, exttrailsource /u01/app/gg/dirdat/t1
EXTRACT added.

GGSCI (db1) 16> add rmttrail dirdat/t2, extract dpump1, megabytes 100
RMTTRAIL added.

GGSCI (db1) 17> start extract dpump1
Sending START request to MANAGER ...
EXTRACT DPUMP1 starting

##### To stop datapump.
GGSCI> stop extract dpump1

GGSCI (db1) 18> info extract dpump1
EXTRACT DPUMP1 Last Started 2013-01-12 20:58 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:04 ago)
Log Read Checkpoint File /u01/app/gg/dirdat/t1000000
First Record RBA 943

GGSCI (db1) 19> info all

Program Status Group Lag Time Since Chkpt
MANAGER RUNNING
EXTRACT RUNNING DPUMP1 00:00:00 00:00:00
EXTRACT RUNNING EXT1 00:00:00 00:00:02

############## Hedef makinede ##########################

[oracle@london gg]$ ggsci

#### -create checkpoint table ####

GGSCI (db2) 3> dblogin userid ggs_admin, password ggs_admin
Successfully logged into database.

GGSCI (db2) 4> add checkpointtable ggs_admin.chkpt
Successfully created checkpoint table GGS_ADMIN.CHKPT.

GGSCI (db2) 1> edit param repl1
replicat repl1
userid ggs_admin, password ggs_admin
handlecollisions
assumetargetdefs
discardfile dirrpt/repl1.dsc, append
discardrollover at 5:00 on sunday
map SCOTT.*, target SCOTT.*;

GGSCI (db2) 5> add replicat repl1, exttrail dirdat/t2, checkpointtable ggs_admin.chkpt
REPLICAT added.

GGSCI (db2) 6> start replicat repl1
Sending START request to MANAGER ...
REPLICAT REPL1 starting

## To stop replicat service. ###

GGSCI> stop replicat repl1

GGSCI (db2) 7> info replicat repl1
REPLICAT REPL1 Last Started 2013-01-12 21:28 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:09 ago)
Log Read Checkpoint File dirdat/t2000000
First Record RBA 0

GGSCI (db2) 8> info all

Program Status Group Lag Time Since Chkpt
MANAGER RUNNING
REPLICAT RUNNING REPL1 00:00:00 00:00:03

###################### Kontrol edelim ##############################

###################### Kaynak Makinde ###########################
SQL> conn scott/tiger;

SQL> update emp set sal=17000 where ename='MILLER';
1 row updated.

SQL> commit;
Commit complete.

###################### Hedef Makinede ###########################

SQL> conn scott/tiger;

SQL> select sal from emp where ename='MILLER';

SAL
----------
17000

SQL> exit

[oracle@db2 gg]$ ggsci

GGSCI (db2) 1> stats replicat repl1

Sending STATS request to REPLICAT REPL1 ...

Start of Statistics at 2013-01-12 21:35:11.

Replicating from SCOTT.EMP to SCOTT.EMP:

*** Total statistics since 2013-01-12 21:31:54 ***
Total inserts 0.00
Total updates 1.00
Total deletes 0.00
Total discards 0.00
Total operations 1.00

*** Daily statistics since 2013-01-12 21:31:54 ***
Total inserts 0.00
Total updates 1.00
Total deletes 0.00
Total discards 0.00
Total operations 1.00

*** Hourly statistics since 2013-01-12 21:31:54 ***
Total inserts 0.00
Total updates 1.00
Total deletes 0.00
Total discards 0.00
Total operations 1.00

*** Latest statistics since 2013-01-12 21:31:54 ***
Total inserts 0.00
Total updates 1.00
Total deletes 0.00
Total discards 0.00
Total operations 1.00

End of Statistics.