Performance Tuni̇ng

DERS 9

PERFORMANCE TUNİNG

Problemler

Performance tuning DBA olarak çalışan yada az çok oracle ile uğraşanlar için en gerekli konulardan

biridir.Yazılan SQL cümlesinin optimizasyonu yada Oracle getirdiği parametreler performance

açısından bize fayda yada zarar ne getirir görmemizi sağlar.

Performance tuning için oracle getirdiği birkaç uygulamayı ve raporlamayı kullanabiliriz.Bunlar

STATSPACK, UTLBSTAT,UTLESTAT, Oracle Enterprise Manager ve 10G ile gelen ADDM’ dir.

Bizim karşımıza çıkan sorunlar,

1-)BAD SESSION MANAGEMENT = Bu tip problemlerde kullanıcının sisteme giriş çıkışı yada

kullandığı toolardan kaynaklanan problemler olabilir.

2-)BAD CURSOR MANAGEMENT = Kullanılan sql cümlelerinin yaptığı işlemlerin oluşturduğu

sonuçlar ve bunların kullanımı bu sebebi oluşturabilir.

3-)BAD RELATION DESIGN = Bu tip problemlerde karşımıza çıkan sorun,yapılan db dizaynının yanlış

olması,tablolar arası ilişkiler yanlış olması gibi sebeplerdendir.

Bu tip durumlarda performansı optimize etmenin yolarlı şu şekildedir.

• Database dizaynını tekrar gözden geçirip düzenlemeliyiz,

• Uygulamanın işleyişini düzenlemeliyiz,

• Makinanın memorysini güçlendirmeliyiz,

• İşletimim sistemini kontrol edip düzenlemeliyiz.

PERFORMANS TOOLLARI

Performansa girmeden önce databasede oluşan hatalar ve uyarılar için Alert.log ları incelemek

lazım.ALert.log’un içinde genel hatalar örneğin(ORA-600) yada blok hataları (ORA-1498,ORA-1578)

olabilmekte,yapılan db işlemleri Create Database,Shutdown,Startup ve Recover adımları.

Alert.log’un yeri BACKGROUND_DUMP_DEST ile belirtilen yerdedir.

Alert.log ları incelersek sistemde oluşmuş çeşitli hatalar ve uyarıları incelemiş görmüş olururz.

Alert.log lar dışında arka planda oluşan işlemleri izlemek için background trace file lar vardır.Bunlardan

da bazı izlenimler edinebiliriz.Kullanıcılarla ilgili raporlar almak içinde user trace file lar vardır.

Bu trace file rı tüm DB aktiviteleri için görebilmek için SQL_TRACE parametresini TRUE yapmak

gerekir.

Eğer Session bazlı görmek istiyorsakta ,

SQL > EXECUTE dbms_system.set_sql_trace_in_session(8,12,TRUE);

Buradaki 8 ve 12 bağlanan kullanıcıların Sistem kimlik numarası ve seri numarasını göstermektedir.

DBMS_SYSTEM package’ını aktif edebilmek için catproc.sql cümlesini çalıştırmak gerekmektedir.

Buda,

UNİX sistemlerde $ORACLE_HOME/rdbms/admin

Windows sistemlerde %ORACLE_HOME%\rdbms\admin

Bulunmaktadır.Daha sonra session bazlı aşağıdaki kodu çalıştırdığımızda kullanıcının session bazlı

aktivitesi izleyebileceğiz.

SQL> ALTER SESSION SET sql_trace=TRUE;

Bunların yanında dinamik dictionary viewlarda çoğu zaman performans ölçümünde bize yardımcı

olabilirler.Bunlar V$xxxxxxxxxxx ve DBA_XXXXXXXXX ile başlıyan viewlardır.Genellikle Segment

storage hakkında bize bilgi verirler.

V$ table ları asıl olarak X$ table larından türemişlerdir.X$ table larının ne olduğuna bakmak istersek

V$FIXED_TABLE görüntüsü kullanılabilir.

Belli zamanlarda çalıştırılacak olan utlbstat.sql ve utlestat.sql cümleleri ise yine performans ölçümünde

bize yardımcı olur.

Performans ölçümlerinde zaman bazlı istatistik almak istiyorsak parametrelerden

SQL> ALTER SYSTEM SET timed_statistics = TRUE; yapmamız gerekmektedir.

Performance viewlarını incelemek istersek,

Şekilde görüldüğü gibidir.

V$PX_PROCESS_SYSSTAT: Paralel Sorgu istatistiklerini verir

V$PROCESS: Aktif olan proseslerin bilgisini verir

V$WAITSTAT: Beklemede olan proses bilgileri

V$SYSTEM_EVENT: Toplam bekleme süresi

V$BUFFER_POOL_STATISTICS: İnsatnce başladığında buffer pool un tahsis edilen bilgisini gösterir.

V$DB_OBJECT_CACHE: Library cachde depolanan database cache’ini gösterir.

V$LIBRARYCACHE: Library cache in performans bilgisini gösterir.

V$ROWCACHE: Yanlış giden aktiviteler

V$SYSSTAT: Basit instance istatistikleri

V$FILESTAT: Datafile yazma/okuma istatistikleri

V$TEMPSTAT: Temp tablespace leri üzerine yazma / okuma istatistiği

V$ROLLSTAT: Rollback segmentlerin durumu

V$WAITSTAT: Çalışan sql ler ve diğer bilgileri için zaman istatistiği

V$LOCKoluşan kilitler

V$OPEN_CURSOR: her bir sesion da açlıp kapanan cursorlar

V$SORT_USAGE: Disk üzerinde temp alanında yapılan sort bilgileri

V$SESSTAT: Kullanıcı session bilgileri

V$SESSION_EVENT: Sesionlarda oluşan event bilgileri

V$SESSION_WAIT: Bekleyen sesionlar

V$PX_SESSTAT: Paralel yürüyen sesionlar.

Örneğin aşağıdaki sql’e bakarsak

SQL> SELECT name,class,value FROM v$sysstat;

NAME CLASS VALUE

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

logons cumulative 1 6393

logons current 1 10

opened cursors cumulative 1 101298

table scans (short tables) 64 6943

table scans (long tables) 64 344

table scans (rowid ranges) 64 0

redo entries 2 1126226

redo size 2 816992940

redo buffer allocation

retries 2 1461

redo wastage 2 5874784

……

The results shown are only a partial display of the output.

Class ların anlamıda şu şekildedir.

• Class 1 refers to general instance activity.

• Class 2 refers to redo log buffer activity.

• Class 4 refers to locking.

• Class 8 refers to database buffer cache activity.

• Class 16 refers to OS activity.

• Class 32 refers to parallelization.

• Class 64 refers to tables access.

• Class 128 refers to debugging purposes.

Tabiî ki tek başına bu tabloya bakmak bize hiçbir anlma ifade etmiyecektir.

SQL> SELECT * FROM v$sgastat;

POOL NAME BYTES

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

fixed_sga 46136

db_block_buffers 409600

log_buffer 524288

shared pool free memory 8341616

shared pool SYSTEM PARAMETERS 42496

shared pool transaction 64800

shared pool dictionary cache 156524

shared pool library cache 358660

shared pool sql area 551488

Bu viewları etkin kullanmak ve doğru raporlar almak istiyorsak ararlındaki ilşkiyi iyi kurmak gerekir

SQL> SELECT sid, username, type, server FROM v$session;

SID USERNAME TYPE SERVER

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

1 BACKGROUND DEDICATED






9 SYSTEM USER DEDICATED

10 HR USER NONE

11 SH USER SHARED

Örneğin SGA da 30.000 byte tan daha fazla memory harcıyan sessionları görmek istersek,

SQL> select username,name,value

2 from v$statname n, v$session s, v$sesstat t

3 where s.sid=t.sid

4 and n.statistic#=t.statistic#

5 and s.type=’USER’

6 and s.username is not null

7 and n.name=’session pga memory’

8* and t.value > 30000;

USERNAME NAME VALUE

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

SYSTEM session pga memory 468816

Örneğin bekleyen sessionları görmek istiyorsakta,

SQL> select sid, event

2 from V$SESSION_WAIT

3* where wait_time = 0;

SID EVENT

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

1 pmon timer

2 rdbms ipc message

3 rdbms ipc message

9 rdbms ipc message

16 rdbms ipc message



4 rdbms ipc message

5 smon timer

STATSPACK

Performansla ilgili görebileceğimiz asıl toll lardan biride statspack raporlarıdır.Bu raporları

başlatabilmek için öncelğikle birkaç işlem yapmamız gerekmektedir.

Statspack yüklemek için

$ORACLE_HOME/rdbms/admin/spcreate.sql cümlesini çalıştırmamız gerekir.

İstatistik toplamak için

execute STATSPACK.snap çalıştırmamız gerekir.

İstatistikleri otomatik toplamak istiyorsak,

$ORACLE_HOME/rdbms/admin/spauto.sql çalıştırmamız gerekir.

Rapor üretmek istiyorsak

$ORACLE_HOME/rdbms/admin/spreport.sql çalıştırmamız gerekir.

Zamanlama işlemleri içinde ağağıdaki parametreyi ayarlamamız gerekir.

TIMED_STATISTICS = true

Statspack başladıktan sonra otomatik olarak Perfstat isimli bir kullanıcı oluşur.

StatSpack raporlarıyla sistemimiz hakkında her türlü çıktıya sahip olabiliriz.En önemlilerinden biride

TOP 5 Wait events dediğimiz,sistemde fazla bekliyen 5 aktiviteyi çıkarmasıdır.

UTLBSTAT ve UTLESTAT

Performansla ilgili görebileceğimiz diğer tollardan biride utlbstat ve utlestat dır.Bu raporları

başlatabilmek için öncelğikle birkaç işlem yapmamız gerekmektedir.

Zamanlama işlemleri içinde ağağıdaki parametreyi ayarlamamız gerekir.

TIMED_STATISTICS = true

Daha sonra raporları alabilemmeiz için

$ORACLE_HOME/rdbms/admin altındaki ,

utlbstat.sql ve utlestat.sql cümlelerini SQLPLUS’ta sysdba olarak çalıştırmamız gerekir.Ama başlangıç

olarak utlbstat.sql cümleciğini,bitiş olarakta utlestat.sql cümlesini çalıştırmalıyız.

Sistemin bekleme ve event bilgileri ile ilgili bi kaç sql çalıştırmak gerekir,

SQL> SELECT name, parameter1, parameter2, parameter3

FROM v$event_name;

NAME PARAMETER1 PARAMETER2 PARAMETER3

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

PL/SQL lock timer duration

alter system set mts_dispatcher waited

buffer busy waits file# block# id

library cache pin handle addr pin address 0*mode+name

log buffer space

log file switch

(checkpoint incomplete)

transaction undo seg# wrap# count

...

286 rows selected.

V$SYSTEM_EVENT: Tüm Sessionlar için bir eventin toplam bekleme süresini toplu olarak verir,

V$SESSION_EVENT: Herbir Session için bir eventin toplam bekleme süresini verir,

V$SESSION_WAIT: Session bazlı aktif bekliyen sessionları gösterir,

SQL> SELECT event, total_waits, total_timeouts,

time_waited, average_wait

FROM v$system_event;

EVENT TOTAL_ TOTAL_ TIME_ AVERAGE_

WAITS TIMEOUTS WAITED WAIT

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

latch free 5 5 5 1

pmon timer 932 535 254430 272.993562

process startup 3 8 2.66666667

buffer busy waits 12 0 5 5

...

34 rows selected.

• EVENT: Bekleyen event’in ismi

• TOTAL_WAITS: Bekleyen Eventlerin sayısı

• TOTAL_TIMEOUTS: Event için bekleyen timeout ların sayısı

• TIME_WAITED: Bekleyen event için toplam zaman miktarı, 1 dakikada yüzdelik olarak

• AVERAGE_WAIT: Bekleyen event için ortalama zaman miktarı, 1 dakikada yüzdelik olarak

SQL> select sid, event, total_waits,average_wait

from v$session_event where sid=10;

SID EVENT TOTAL_WAITS AVERAGE_WAIT

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

10 buffer busy waits 12 5

10 db file sequential read 129 0

10 file open 1 0

10 SQL*Net message to client 77 0

10 SQL*Net more data to client 2 0

10 SQL*Net message from client 76 0

SQL> SELECT sid, seq#, event, wait_time, state

FROM v$session_wait;

SID SEQ# EVENT WAIT STATE

TIME

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

1 1284 pmon timer 0 WAITING

2 1697 rdbms ipc message 0 WAITING



5 114 smon timer 0 WAITING

6 14 SQL*Net message from client -1 WAITED

SHORT

TIME

SHARED POOL AYARLARI

SGA Oracle ilk açıldığında instance’ın ilk yüklendiği ve başladığı yerdir.

SGA yı adım adım incelersek,

Shared pool Shared_pool_size parametresi ile düzenlenerek kullanılır.

İçinde Libraray cahe,data dictionary cache ve UGA barındırırır.Libaray cache de Execution plan,parse

edilmiş kodlar bulunur.

Data dictionary cache de,Tablo tanımaları ve privillege gibi bilgiler bulunur.

UGA ise Large pool configüre edilmemişse Oracle Shared Server Session bilgisini barındırır.

Shared Pool’un boyut ayarı SHARED_POOL_SIZE ile olmaktadır.

Shared pool size ‘ın default değeri 8 MB’dir.İstenirse değiştirilebilinir.

Library cache sahred SQl ve PL/SQL bilgilerini içerir.Örneğin compile edilmiş

Procedurler,Triggerlar..içerir.Bir LRU algoritmasına göre yönetimi gerçekleşir.Server’ın bir Sql’e

ihtiyacı olduğunda cache bulunan sql den bu işlemi gerçekleştirip tekrar parse etmesine gerek

kalmadan bu işlemi yapmaktadır.

Library Cache Tuning

Library cache ihtiyaç duyduğunda bir sql cümlesini cache ten alıp parse etmeden getirir ama istenen

cümle eğer cache te bulunmuyorsa ,ilgili cümle parse edilir ve daha sonra library cache’ e yerleştirilir.

Fragmentasyonu önlemek için Birkaç konuya dikkat etmek gerekir.

Large Memory için gerekli yer ayrılmalıdır.

Gerekli Large Objelerini pinlemek gerekir.

Bilinmeyen PL/SQL bloklarını elimine etmek gerekir.

Library cache ile ilgili bilgileri ağağıdaki sorgudan alabiliriz.

SQL > select namespace,gets,pins,reloads,gethits,pinhits from V$LIBRARYCACHE

NAMESPACE GETS PINS

RELOAD

S

GETHIT

S PINHITS

SQL AREA 12213 39244 16 12024 38846

TABLE/PROCEDUR

E 12796 12803 0 12536 12432

BODY 2 1 0 0 0

TRIGGER 5 5 0 0 0

INDEX 3783 3752 0 3741 3710

CLUSTER 193 258 0 186 250

OBJECT 0 0 0 0 0

PIPE 0 0 0 0 0

JAVA SOURCE 0 0 0 0 0

JAVA RESOURCE 0 0 0 0 0

JAVA DATA 0 0 0 0 0

Gets : Sorgu sonucu dönen uygun değerlerin toplamı,

Pins : Her bir area için ,SQL statemntların ve procedurlerin execute sayısını gösterir,

SGASTAT tüm SGA yapısının boyutunu gösterir.

V$SQLAREA bütün shared cursorların ilk 1000 karakterleriyle birlikte bilgisini verir.

V$SQLTEXT bütün sql ler için satır satır bilgileri kısaltmaksınız verir.

V$DB_OBJECT_CACHE cache lenmiş Tablo,Synonim bilgilerini gösterir.

Shared Pool için aktivite istatistiği ve efektif kullanım yüzdesi gösteren örnek bir sql yazmak istersek.

SQL> select gethitratio

from v$librarycache

where namespace = ‘SQL AREA’;

SQL> select sql_text, users_executing,

executions, loads

from v$sqlarea;

SQL> select * from v$sqltext

where sql_text like

’select * from hr.employees where %’;

Burada gethitratio parametresi bize cursurların share edilip edilmediğ hakkında kısa bir bilgi verir.Bu

bilgi % cinsindendir.Genelde bu değer % 90 ın üzerinde olmalıdır.

Yukarıda Bir porsedürün 4 defa çalışma bilgisi görünmektedir.

SQL> select sum(pins) "Executions", sum(reloads)

"Cache Misses", sum(reloads)/sum(pins)

from v$librarycache;

Executions

Cache

Misses SUM(RELOADS)/SUM(PINS)

71120 16 0.000224971878515186

Bu Örneğe baktığımızda Bilmemiz gereken reloadslar pinlerin % 1 den daha ufak olmalıdır.Eğer % 1

‘in üzerine çıkarsa,shared_pool_size parametresini büyütmeliyiz.

GEÇERSİZ KILANAN CÜMLELER

Bunun anlamı bazen SQL Areada bulunan cümleler geçersiz olabilmektedir.Bunu engellemenin yolu

ilgili cümlenin tekrar execute ve reparse edilmesidir.

SQL > select count(*) from hr.employees;

SQL > select namespace,pins,reloads,invalidations


NAMESPACE PINS RELOADS INVALIDATIONS

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

SQL AREA 1616 12 0

…

SQL > ANALYZE TABLE hr.employees COMPUTE STATISTICS;

SQL > select count(*) from hr.employees;

SQL > select namespace,pins,reloads,invalidations


NAMESPACE PINS RELOADS INVALIDATIONS

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

SQL AREA 1688 14 3

…

Bir tablo yada view alter edildiğinde yada bir procedur yada package recompile edildiğinde birbirine

bağlı sql areaları invalid duruma düşecektir.

LIBRARY CACHE SIZING

Stored objeler için global bir space Ayarlamak gerekir.

Çok kullanılan sql cümleleri için memory de bir size ayarlamak gerekir.

Çok kullanılan sql cümlelerini muhafaza etmek gerekir.

Mesela büyük Procedurleri parçalayıp daha ufak Package’ler haline geitrmek gerekir.

Çok büyük Sql cümleleri veya triggerlar için Shared Pool içinde belli bir miktar ayırarak,kullanıma

açabilirz.Genelde Sahred pool’un % 10 u kadar olmalıdır.

Cache üzerinde ne kadarlık bir sharable memory ihtiyacı var diye bakmak istersek,

SQL> select sum(sharable_mem)

from V$DB_OBJECT_CACHE;

SUM(SHARABLE_MEM)

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

379600

SQL> select sum(sharable_mem)

from V$SQLAREA where executions > 5;

SUM(SHARABLE_MEM)

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

381067

SQL > select * from V$SHARED_POOL_RESERVED; bize gerekli bilgileri vermektedir.

LARGE MEMORY GEREKSİNİMLERİ

PL / SQL operasyonları için ne kadarlık bir başlangıç değeri ayıracağımız

SHARED_POOL_RESERVED_SIZE gösterir.

Buradaki SHARED_POOL_RESERVED_SIZE normal olarak SHARED_POOL_SIZE’ın % 10’u kadar

olmalıdır.

SQL> select * from v$db_object_cache

where sharable_mem > 10000

and (type=‘PACKAGE’ or type=‘PACKAGE BODY’ or

type=‘FUNCTION’ or type=‘PROCEDURE’)

and KEPT=‘NO’;

Bu cümle bize libraray cache te saklanamamış sql cümleri hakkında bilgi verir.

SQL> EXECUTE dbms_shared_pool.keep(‘package_name’); Library cache te saklamak içinde bu

cümleciği kullanabiliriz.

Yukarıda execution ile bu sql cümlelerini saklamış oluruz.

SQL> select sql_text from v$sqlarea

where command_type = 47

and length(sql_text) > 500; yazarak sistemde büyük procedurleri bulmuş olururz.

Bunu istersek daha ufak parçalarda package haline getirebiliyorsak getirmeliyiz.

SQL> declare x number;

begin x := 5;

end;

SQL> declare /* KEEP_ME */ x number;

begin x := 5;

end;

SQL> select address, hash_value

from v$sqlarea

where command_type = 47 and sql_text like ’%KEEP_ME%’;

Dictionary Cache Tuning

Dictionary Cache Tuning’e tuning uygulamak içinde yapabileceğimiz şeyler vardır.Bu cache sistem

hakkında bilgi aldığımız viewları barındırmaktadır.

Gets:Objeler üzerindeki request sayısı

Getmisses:Cacheteki kayıp Request sonuçlarının sayısı

SQL> select parameter, gets, getmisses

from v$rowcache;

PARAMETER GETS GETMISSES

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

dc_objects 143434 171

dc_synonyms 140432 127

getmisses ların toplamının getslerin toplamına oranı % 15 leri geçmemelidir.Geçerse shared pool size

parametresi arttırılmalıdr.

UGA Tuning

Eğer Large pool konfigure edilmediyse,kullanıcı session ve cursor state bilgisi Burada depolanacaktır.

Aşağıdaki Sql Kullanıcının UGA kullanımları hakkında bilgi verir.

SQL> select SUM(value) ||’bytes’ "Total session memory"

from V$MYSTAT, V$STATNAME

where name = ’session uga memory’

and v$mystat.statistic# = v$statname.statistic#;

Aşağıdaki Sql Shared Server Kullanıcının UGA kullanımları hakkında bilgi verir.

SQL> select SUM(value) ||’bytes’ "Total session memory"

from V$SESSTAT, V$STATNAME

where name = ’session uga memory’

and v$sesstat.statistic# = v$statname.statistic#;

Aşağıdaki Sql Tüm Kullanıcının UGA kullanımları hakkında bilgi verir.

SQL> select SUM(value) ||’bytes’ "Total max memory"

from V$SESSTAT, V$STATNAME

where name = ’session uga memory max’

and v$sesstat.statistic# = v$statname.statistic#;

Eğer yeterli miktar yoksa bunuda Sahred Pool Size parametresi arttırlırak çözebiliriz.

LARGE POOL

Sistem ve kullanıcı işlemleri için tanımlanan isteğe bağlı bir alandır.Örneğin bu alan backup ya da

restore işlemlerinde fazladan alan ihtiyacı için kullanılabilir.LRU gibi bir listesi

yoktur.LARGE_POOL_SIZE parametresi ile büyüklüğü düzenlenebilir.RMAN bu parametreyi

kullanarak BAckup ve Recovery yapar.Minimum 300k,Max 2 Gb olabilir.

SQL > SELECT *

2 FROM v$sgastat

3 WHERE pool = ’large pool’; sorgusu ile kontrol edilebilir.

DBWR_IO_SLAVES parametresi ile ARCN proseslerinin disk üzerinde ne kadara (kaç DBWn) IO

yapacağını gösterir default olarak 0 dır,eğer RMAN kullanılacaksa 4 yapılır.

BACKUP_TAPE_IO_SLAVES ise backup tapelerinin kullanımı içindir.Değeri True yapılırsa ,tapeler

üzerinden okuma yazma yapılır.Yine aynı şekilde RMAN içindir.

DATABASE BUFFER CACHE

Datafile’dan okunan veriler SGA içersinde bu alanda tutulur. Mantıksal olarak kendi içinde parçalara

ayrılarak kullanılır.Veritabanı üzerinde işlem yapan tüm kullanıcılar burayı kullanırlar.Bu durumda

yapılan işlemlerin belli bir sistematikte yapılması gerekmektedir.Bunu sağlamak için database buffer

cache’te “yazma listesi(Write List)” ve “en son kullanılanları tutan liste(Last Recenlty Used-LRU- list)”

olmak üzere 2 ayrı liste tutulur.

“Write List” , “dirty buffer” olarak adlandırılan üzerinde değişiklik yapılmış ama diske(datafile’a) henüz

yazılmamış tampon alanları tutar.LRU listesi ise boş tampon alanları (free buffers) ,henüz “write list”’e

gönderilmemiş “dirty buffer” alan bilgilerini ve “pinned buffer” denilen o an işlem gören alanları tutar.

Kullanıcının veri okuma isteği olduğunda önce bu cache’te varmı diye bakılır.Var ise(cache hit) veri

hafızadan direk okunur.Eğer yok ise (cache miss) veri ilgili data bloktan buraya okunur.Ama bunu

yapabilmesi için önce hafızada boş alan bulunması gerekir.Bunun için LRU listesine bakılır. Boş bir

alan bulunana ya da tanımlı bir eşik değere ulaşıncaya kadar arama sürer. LRU listesinde ”Dirty

buffer” bulunca bu alan “write liste” alınır ve arama işlemi sürdürülür, boş alan bulununca burası LRU

listesinin en sonuna atılarak ,veri , bulunan boş alana okunur.Boş alan bulunamadığı esnada

belirlenen eşik değerine ulaşılınca LRU listesinde arama bitirilir ve DBW0 arka plan işlemcisine

(background process) bir takım “dirty buffer” alanını diske yazması için sinyal gönderilir.

DB_CACHE_SIZE : Varsayılan buffer pool’un byte cinsinden değeridir.

DBA_KEEP_CACHE_SIZE :Korunan buffer pool’un sizdıdır.

DBA_RECYCLE_CACHE_SIZE : Geçici buffer pool’un byte cinsinden değeridir.

DB_BLOCK_SIZE : Database blokalrının sayısını göstermektedir.

SGA OPTİMİMAZYONU

Sga asıl olarak granül adı verdiğimiz yapılardan oluşur. V$BUFFER_POOL görüntüsü ile granüllerin

yerleşimlerini ve tahsis edilen alanlarını görebiliriz.

Granüller genellikle 16 MB dir.Ama SGA değeri 128 civarıysa 4MB olabilir.Minimum SGA

konfigirasyonu için 3 adet granül gerekir.Biri redo buffer için,biri buffer cache için,biri shared pool

için.SGA’nın size ı SGA_MAX_SIZE ile ayarlanabilir.

Örneğin DB_CACHE_SIZE için memory kullanıını arttıralım,

SQL> show parameter db_cache_size;

NAME TYPE VALUE

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

db_cache_size big integer 4194304

SQL> alter system set db_cache_size=8M;

System altered.

SQL> show parameter db_cache_size;

NAME TYPE VALUE

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

db_cache_size big integer 8388608

Bu parametrelerin değişimi ve SGA size’ının artırımı ile ilgili bir örnek verecek olursak,

SGA_MAX_SIZE = 128M,

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

DB_CACHE_SIZE = 96M

SHARED_POOL_SIZE = 32M

Şu an bir sorun yok ama,Shared pool size ını arttırmak istedik diyelim.

SQL > ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;

Sistem bu cümleye hata verir niye,çünkü db cache size ve shared pool toplamı 128’i geçemez.

O zaman,

SQL > ALTER SYSTEM SET DB_CACHE_SIZE = 64M;


Sistem bu cümleyede hata verir niye çünkü,aynı anda bu değişim yapılamaz.Ama DB_CACHE SIZE

yalnız değiştikten sonra,


Yazarsak sistem hata vermez ve istediğimiz sonucu alırız.

DATABASE BUFFER CACHE’IN YÖNETİLMESİ

1-)ilk olarak server buffer cache üzerinde kullanılabilir blokları bir hash fonkiyonu kullanarak kontrol

eder.Eğer blok bulunursa LRU listesinde LRU’nun sonundan başka bir noktaya taşınır.Eğer

bulumazsa server server datafile dan blok okuyamaz.

2-)Data file dan okunmadan önce server LRU listesinde boş olanları arar.

3-)LRU listesinde arama yapılırken,server bozuk blokları dirt liste yerleştirir.

4-)Eğer kirli bloklar belli bir eşik değerini geçerse ,Server sinyal verir ve kirli blokları buffer cache ten

boşaltır.

5-)Eğer boş blok bulunursa server gerekli blokları datafile dan okur.

6-)Blok tutarlı değilse,server bloğun önceki versiyonunu rollback segmentlere bakarak yeniden

oluşturur.

MULTİPLE BUFFER POOLS

İstenirse birden fazla buffer pool kullanılabilir.3 tip buffer pool vardır.

RECYLE : Yeniden kullanılabilir blokları elemek için kullanılır.

KEEP : Yeniden kullanılabilir blokları saklamak için kullanılır.

DEFAULT :Bu pool her zaman vardır.Single buffer cache eşittir.

Her bir bağımsız pool için DB_CACHE_SIZE, DB_KEEP_CACHE_SIZE, ve

DB_RECYCLE_CACHE_SIZE vardır.

Bunların kullanımıda şu şekilde olmaktadır.

SQL > CREATE INDEX cust_idx …

STORAGE (BUFFER_POOL KEEP …);

SQL > ALTER TABLE customer

STORAGE (BUFFER_POOL RECYCLE);

SQL > ALTER INDEX cust_name_idx

STORAGE (BUFFER_POOL KEEP);

Keep Pool için,

SQL> ANALYZE TABLE hr.countries ESTIMATE STATISTICS; ile her bir objenin size bilgisi elde

edilir.

SQL> SELECT table_name, blocks

FROM dba_tables

WHERE owner = ’HR’

AND table_name = ’COUNTRIES’;

TABLE_NAME BLOCKS

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

COUNTRIES 14

Recylce Pool için,

Transactionlar tamamlandıysa bunları memory den atar.

SQL> SELECT owner#, name, count(*) blocks

FROM v$cache

GROUP BY owner#, name;

OWNER# NAME BLOCKS

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

5 CUSTOMER 147

SQL> SELECT *

FROM v$buffer_pool;

ID NAME LO_SETID HI_SETID SET_COUNT BUFFERS LO_BNUM HI_BNUM

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

1 KEEP 3 3 1 14000 0 13999

2 RECYCLE 4 6 3 2000 14000 15999

3 DEFAULT 1 2 2 4000 16000 19999

Aşağıdaki dictionat viewlar buffer pool kolonuna sahiptir.

• USER_SEGMENTS, DBA_SEGMENTS

• USER_CLUSTERS, ALL_CLUSTERS, DBA_CLUSTERS

• USER_INDEXES, ALL_INDEXES, DBA_INDEXES

• USER_TABLES, ALL_TABLES, DBA_TABLES

• USER_OBJECT_TABLES, ALL_OBJECT_TABLES, DBA_OBJECT_TABLES

• USER_ALL_TABLES, ALL_ALL_TABLES, DBA_ALL_TABLES

TABLOLARIN CACHELENMESİ

Server full table scan yaparak blokları sorgulamışsa ,LRU listesinde az kullanılanlar sırasına

gider,Bloklar ileride kullanılam için ihtiyaç duyulursa ,Diğer prosesler için kullanımda

olmayacaklardır.Bu yüzden en çok kullanılanları seçmek gerekir.

SQL> SELECT name, value

FROM v$sysstat

WHERE name = ’free buffer inspected’;

NAME VALUE

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

free buffer inspected

SQL> SELECT event, total_waits

FROM v$system_event

3 WHERE event in

4 (’free buffer waits’, ’buffer busy waits’);

EVENT TOTAL_WAITS

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

free buffer waits 337

buffer busy waits 3466

REDOLOG BUFFER TUNİNG

INSERT,UPDATE,DELETE,CREATE,ALTER ve DROP işlemleri sonucu meydana gelen değişiklikleri

hafızada tutulduğu kısımdır.Yapılan değişikliklerin geri alınmasında ve gerektiğinde “recovery”

işlemleri için kullanılır.Sıralı ve doldugunda başa dönecek şekilde bir yapısı vardir.

Bu alanda tutulan bilgiler “Log Writer Process(LGWR)” ile redo log dosyalarına yazılır.LOG_BUFFER

parametresi redo log alanının büyüklüğünü belirler.Büyük değer alması I/O mailiyeti

düşürür.Gennellikle 500 K ile değeri belirlenir.

SQL> select 'V$PARAMETER' "Table name", name,

to_number(value,'9999999') "Value"

from v$parameter

where name = 'log_buffer'

UNION

select 'V$SGASTAT' "Table name", name, bytes

from v$sgastat

where name ='log_buffer';

Table name NAME VALUE

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

V$PARAMETER log_buffer 120320

V$SGASTAT log_buffer 120320

Bilindiği gibi makinelerin CPU ları hızlı fakat diskleri yavaştır bu yüzden birden fazla işlemi yapmakta

disk üzerinde belli bir I/O gerektirir.Birden fazla redo gerekitren işlemin daha performnaslı olması

isteniyorsa LOG BUFFER parametresi arttırılmalıdır.

Log buffer larla ilgili çeşitli sorgular alabiliriz.

SQL> select sid, event, seconds_in_wait, state

from v$session_wait

where event = ’log buffer space%’;

SID EVENT SECONDS_IN_WAIT STATE

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

log buffer space 110 WAITING


FROM v$sysstat

WHERE name = ’redo buffer allocation retries’;

SQL> select name, value

from v$sysstat

where name=’redo log space requests’;

Aşağıdaki sorgunun sonucunda herhangi bir değer dönmemeisi gerekmektedir.

SQL> SELECT sid, event, seconds_in_wait, state

FROM v$session_wait

WHERE event = ‘log buffer space’;

Aşağıdaki sorguda ise ‘redo buffer allocation retries’ değeri 0 a yakın olmalıdır. ‘redo entries’ değeri ise

%1 in altında olmalıdır.


FROM v$sysstat

WHERE name IN (‘redo buffer allocation retries’,

‘redo entries’);

Bu sorunları çözmek için redo buffer değeri arttırılabilir yada redologlar için daha hızlı bir disk

kullanılabilir.

Documents

Performance Tuni̇ng