ORACLE DA SAĞLIKLI PERFORMANS TESTİ YAPMAK

Oracle da sağlikli performans testi yapmakiçin bildiğiniz üzere shared_pool ve buffer_cache'i sifirlamanız gerekecektir. Kullandiği sorguyu RAM alıp ikinci sorguyu test ettiğimizde şaibeli sonuçlar vermemesi için aşağıdaki işlemleri yapmakta fayda var.
bu işlemleri testlerden önce yapınız. Her testden önce yaparak sağlıklı sonuçlar alabilirsiniz.

ALTER SYSTEM FLUSH BUFFER_CACHE;

ALTER SYSTEM FLUSH SHARED_POOL;

bu işlemelri yapabilmek için ALTER SYSTEM yetkinizin olması lazım :)

ORA-04031: unable to allocate 27992 bytes of shared memory While Taking RMAN Backup.

RMAN ile backup alırken aşağıdaki hatayı alabiliriz.
ORA-04031: unable to allocate NNNNNN bytes of shared memory While Taking RMAN Backup.
Bu hatanın sebebi yeterli LARGE_POOL_SIZE olmamasıdır. Bu alanı arttırmnın gerekecektir. Bu alanın ne kadar olduğunu görmek için

SQL> show parameter large

NAME TYPE VALUE
------------------------------------ -----------
large_pool_size big integer 0

burada değeri 0 görüyoruz bunun sebebi daha önceden belirlememiş olmamız. Sistemimizin özellikleri, RAM miktarımız ,databasede yapılan işlemler vs.. 'e göre kendimiz bir değer verebiliriz.

SQL> ALTER SYSTEM set LARGE_POOL_SIZE = 20 M;

Sistem de­i■tirildi.

SQL> show parameter large

NAME TYPE VALUE
------------------------------------ ----------- -------------
large_pool_size big integer 20M


burada 20MB değerini görüyoruz ben burada deneme amaçlı olarak sallama bir değer verdim.

Unix makinada ram miktarınızı görmek için
prtconf |grep Mem

Memory Size: 255232 MB
Good Memory Size: 255232 MB
not : HDD gibi RAM makinada :)))

ALTER SYSTEM set SHARED_POOL_SIZE = 20m;
Bunuda arttırmanız da fayda var.

ORA-04031: unable to allocate 127384 bytes of shared memory ("shared pool","CREATE TABLE SHARED_POOL_DENEME...","sql area","qry_text : qcpisqt")
hatasında aldığında share pool ayarlamak yerine yada shared pool alanının yeterli oldugunu kodda hata olduğunu düşünüyor iseniz.

alter system flush shared pool

diyip reallocate edebilirsiniz.

SPLIT PARTITION KULLANIMI

Split partition büyük boydaki partition'u küçük parçalara ayırmaya yarıyor. partitionda belirli bir koşula göre alt parçalara ayırıyoruz. bu işlemi yaptıktan sonra tabloyu analiz etmede fayda var. Oracle'yi olandan bitenden haebrdar etmek lazım. :))

split partition ile ilgili bir çok örnek mevcud. bir tanesini de burada paylaşmak gerekir ise

--2008 yılının partitionlarını iki parçaya bölüyorum.
--TO_DATE('31-JUL-2009 23:59:59', 'DD-MON-YYYY HH24:MI:SS') haziran ayından öncekileri haziran dahil
-- buyuk_tablom_2008_01 partitionuna ekliyorum. Diğerlerinide buyuk_tablom_2008_02 partitionuna ekliyoruz.

ALTER TABLE buyuk_tablom
SPLIT PARTITION buyuk_tablom_2008 AT (TO_DATE('31-JUL-2009 23:59:59', 'DD-MON-YYYY HH24:MI:SS'))
INTO (PARTITION buyuk_tablom_2008_01,
PARTITION buyuk_tablom_2008)
UPDATE GLOBAL INDEXES;

ALTER TABLE buyuk_tablom
SPLIT PARTITION buyuk_tablom_2008 AT (TO_DATE('31-DEC-2009 23:59:59', 'DD-MON-YYYY HH24:MI:SS'))
INTO (PARTITION buyuk_tablom_2008_02,
PARTITION buyuk_tablom_2008)
UPDATE GLOBAL INDEXES;



--eklenen partitionları burada görebiliriz.
SELECT partition_name, num_rows
FROM user_tab_partitions
WHERE table_name = 'BUYUK_TABLOM';
--istatistiğini alalım.

EXEC DBMS_STATS.gather_table_stats(USER, 'buyuk_tablom', cascade => TRUE);

SQL TUNING

Sql Tuning (SQL ayarlama) en kaba anlamı ile sql sorgularının performası denebilir. Sistem kullanımı yada cevap süresi gibi denebilir. Yazdığımzı kodun etkili bir şekilde çalişması gereksiz erişimler yapmaması yada gereksiz kullanılmayan select ler yapmaması gibi sıralayabiliriz. Where sorgusunu nasıl kullanmalı yada join işlemleri yaparken neler yapılmalı gibi bir dünya şey bunun içine giriyor. bu başlık atında bunlardan bazılarına değinmeye çalışacağim

* Automated Maintenance Tasks ile istatistik toplama konusunda çok güzel açiklama http://www.oraclefaq.org/?p=17

* Veritabanı bağlantısından olabildiğince kaçının. Yeni bir database bağlantısı gerçekten yavaş çalişan bir işlemdir.

*Index kullanmaya çok hevesli olmamak gerekiyor. Ayrıca kullanılan index tipide önemli. Bitmap ile indexlenmiş olandan sütünda çok farklı değerlerin olması gibi mesela.

aynı değerlerin tekrar etmesi mantıllıdır. Kadın erkek gibi yada var yok gibi. http://www.dba-oracle.com/art_9i_indexing.htm burada index tiplerini açikliyor.

-b-tree index

-bitmap indexes

-Function-based indexes

*Where kalıbında kullanılan eleme işlemlerinde ilk elemenin olabildiğince çok satir elemesine dikkat etmek gerekiyor. İlk başta çok satir eleyelim ki diğer AND lerde daha az satir ile muhattap olalim değil mi?

*İndex kullanırken diyelim ki 1.000.000 satırlık bir tablodan 40-50 yada ne bileyim 500-1000 satir çekecek isek bunu index ile halletmek mantıklı ama biz buradan 50.000 satir çekecek isek buradan index kullanmak yerine tabloyu tam tarama(full table scan) yapmak daha mantıklı boşuna birde index alanına erişmenin manası yok. zaten bi dünya satir getireceğim. Daha önce dediğim gibi çok buyuk bir tablodan az sayıda satir dönecek ise index kullanmak kaçınılmazdır.

*index kullanacağımız tabloların çok fazla insert update ve delete işlemine maruz kalması iyi değildir. Çünkü tablomuzun içeriği sürekli değiştiği için bu değşiiklilerin indexlere de aktarılması gerekiyor. İndexlere aktarma yaparken index tablosunun komple değişmesi yada uygun algortima ile değiştirilmesi performans sıkıntısına yol açar. Kısacası indexleri çok değişen tablolarda kullanmayın.

*Partition kullanın büyük avantajlar sağlayacaktır.

* union işlemi sıralama yapar eğer sıralamaya ihtiyacınız yok ise union all kullanın. Neden Union All işleminin sıralama yapmayacağını merak ediyor iseniz cevabı basit ve açik. Union işlemi tekrarlı satırları eliyor ama Union All işlemi tekaraları satırları göstertiğin için sıralama yapmıyor.

*Index yaratırken Create Index ile beraber Compute Statistics kullanarak index yaratma esnasında istatistik toplayarak sonraki sıralama işlemlerini elersiniz. (Bunu tam olarak bende anlamadim ama böle bişey varmış içeriğinine bakmak lazım)

*Trigger kullanırken çok dikkatli olmak gerek gerekiyor. Ne demiş atalarımız fazla merak iyi değildir. :))

*Bir database de birden fazla disk olmasımı iyidir yoksa tek bir disk olmasımı iyidir sorusunun cevabı çok disk olmasıdır. Database i birden fazla diske bölmek ve bu diskleri erkili bir şekilde yönetmek gerekir. tek bir diskten farklı verileri çekmekten ise dağınık disklerden çekmek daha iyidir. Dağınık veritabanlari gibi düşünebiliriz. sürekli kullandığın veriyi ana makinadan cekmektense local makinayi kullan gibi (tam açiklamayamadim ama öle bişey işte bu mimarinin bir adi vardi dilimin ucunda çikmadi gitti.)

*Paralellik kulanmaktan çok fazla kaçınmayın imkan varsa kullanın

*LIKE kullanmaktan kaçının ve bunun benzerlerinden

What to do when your query is too slow?

First of all, you have to know why it is slow. What is the real cause of your problem. If the reason why is not known, suggesting to rewrite the query, or hinting the query, suggesting parallellization et cetera is not very productive. Once in a while you may get lucky. But even then you have to realize that if your problem seems "solved", but you don't know why, nothing guarantees you that the problem won't come back tomorrow. So the first step should always be to investigate the root cause.

The tools at your disposal are, among more:
- dbms_profiler
- explain plan
- SQL*Trace / tkprof
- statspack

Use dbms_profiler if you want to know where time is being spent in PL/SQL code. Statspack is a must if you are a dba and want to know what is going on in your entire database. For a single query or a small process, explain plan and SQL*Trace and tkprof are your tools.

explain plan

in SQL*Plus you have to type:

explain plan for ;
select * from table(dbms_xplan.display);


When you get error messages or a message complaining about an old version of plan_table, make sure you run the script utlxplan.sql.

The output you get here basically shows you what the cost based optimizer expects. It gives you an idea on why the cost based optimizer chooses an access path.

SQL*Trace/tkprof

For this you have to type in SQL*Plus:
- alter session set sql_trace true;
-
- disconnect (this step is important, because it ensures all cursors get closed, and "row source operation" is generated)
- identify your trace file in the server directory as specified in the parameter user_dump_dest
- on your operating system: tkprof a.txt sys=no sort=prsela exeela fchela

The file a.txt will now give you valuable information on what has actually happened. No predictions but the truth.
alıntıdır kaynak http://forums.oracle.com/forums/thread.jspa?threadID=501834&start=0&tstart=0

Oracle performance analysis

bu dokuman da açiklamar var EM seviyesinde grafik arayüzde inceleme imkanı veriyor.

http://www.oracle.com/technology/products/manageability/database/pdf/ow07/spa_white_paper_ow07.pdf

ayrıca sql*plus da yapılabiliyor. bazı kısımları türkçe yazmak isterdim ama şu aşamada vaktim yok ing cok sayıda dokuman var zaten kodlara bakılınca anlaşiliyor.

http://www.oracle-base.com/articles/8i/ExplainPlanUsage.php

What to do when your query is too slow?

First of all, you have to know why it is slow. What is the real cause of your problem. If the reason why is not known, suggesting to rewrite the query, or hinting the query, suggesting parallellization et cetera is not very productive. Once in a while you may get lucky. But even then you have to realize that if your problem seems "solved", but you don't know why, nothing guarantees you that the problem won't come back tomorrow. So the first step should always be to investigate the root cause.

The tools at your disposal are, among more:
- dbms_profiler
- explain plan
- SQL*Trace / tkprof
- statspack

Use dbms_profiler if you want to know where time is being spent in PL/SQL code. Statspack is a must if you are a dba and want to know what is going on in your entire database. For a single query or a small process, explain plan and SQL*Trace and tkprof are your tools.

explain plan

in SQL*Plus you have to type:

explain plan for ;
select * from table(dbms_xplan.display);

When you get error messages or a message complaining about an old version of plan_table, make sure you run the script utlxplan.sql.

The output you get here basically shows you what the cost based optimizer expects. It gives you an idea on why the cost based optimizer chooses an access path.

SQL*Trace/tkprof

For this you have to type in SQL*Plus:
- alter session set sql_trace true;
-
- disconnect (this step is important, because it ensures all cursors get closed, and "row source operation" is generated)
- identify your trace file in the server directory as specified in the parameter user_dump_dest
- on your operating system: tkprof a.txt sys=no sort=prsela exeela fchela

The file a.txt will now give you valuable information on what has actually happened. No predictions but the truth.

alıntıdır kaynak http://forums.oracle.com/forums/thread.jspa?threadID=501834&start=0&tstart=0