Oracle veritabani performans kontrol listesi

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Oracle Veritabanı Performans Kontrol Listesi
1
Orhan Eripek
orhaneripek.com
Senior Oracle DBA
Oracle ACE Associate
10g/11g OCP
Member of TROUG
Oracle SQL, Analitik
SQL ve PL/SQL
kitabı yazarlarından
Database Administration SIG 2017

Ajanda
2
1 Kontrol listesi (Checklist) nedir? Faydaları nelerdir? Günlük
hayatta kullandığımız örnek kontrol listeleri nelerdir?
Oracle Veritabanı Performans yönetiminde kontrol listesi (Check
list) gerekli midir? Olursa faydaları nelerdir?
Oracle Veritabanı Performans Kontrol listemizde neler
olmalıdır? Birlikte oluşturalım!
Kontrol listemizin güncellenmesi (Checklist check)
2
3
4

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 3
Kontrol listesi (Checklist) nedir? Faydaları nelerdir? Günlük hayatta kullandığımız
örnek kontrol listeleri nelerdir?
Günlük hayatta kullandığımız kontrol listeleri örnekleri;
 Acil durum planı kontrol listesi
 Güvenlik kontrol listesi
 Sağlık kontrol listesi (Check Up)
 Temizlik kontrol listesi
 Yemek kontrol listesi
 Pilotun uçuş kontrol listesi
 Şantiye, Oto tamir, Kasap, Lokanta, Pastane,... kontrol listeleri
Checklist: «Yapılması veya kontrol edilmesi gerekenler listesi», «Başvurulan standart kontroller
listesi», «Yapılan bir işin eksiksiz ve hatasız olduğunu kontrol etmek için yapılan liste» ...
To-Do list genel olarak yapılacaklar listesi iken Checklist, yapılan bir işe ait kontroller listesidir.

Oracle Veritabanı Performans yönetiminde kontrol listesi (Checklist) gerekli midir?
Olursa faydaları nelerdir?
Beklenmedik bir anda yaşanan sorunla ilgili zamanında kontroller yapmadıysak (veya
Checklist'imizde yoksa) hem zaman, efor kaybı yaşarız hem de sorunu büyüterek içinden çıkılmaz
durumlara düşebiliriz.
Veritabanının stabil-performanslı çalışmasını istiyorsak neden bir ‘Oracle Veritabanı Performans
Checklist’imiz olmasın!
Veritabanında yaptığımız iyileştirmelerin sonuçlarını görerek önceki durumu ile karşılaştırabilmek
için de Checklist’lerimizden faydalanabiliriz
Özellikle üretim ortamı (canlı, production) veritabanlarında yaptığımız operasyonel çalışmalarda bir
rollback planımızın olmasının yanında ayrıca bir Checklist’imizin de olması oldukça önemlidir.

Oracle Veritabanı Performans Kontrol listemizde neler olmalıdır? Birlikte oluşturalım!
İnvalid obje var mı?
Unusable index var mı?
SELECT OWNER,
OBJECT_NAME,
OBJECT_TYPE,
CREATED,
LAST_DDL_TIME
FROM dba_objects
WHERE status LIKE 'INVALID'
ORDER BY LAST_DDL_TIME DESC;
SELECT 'ALTER INDEX ' || owner || '.' || index_name || '
REBUILD;'
FROM dba_indexes
WHERE status = 'UNUSABLE';

İndex monitoring -> invisible index -> drop index
SET HEADING OFF
SET ECHO OFF
SET PAGES 10000
SPOOL start_monitoring.sql
SELECT 'alter index ' || owner || '.' || index_name ||
' monitoring usage;'
FROM dba_indexes
WHERE owner NOT IN ('SYS',
'SYSTEM',
'SYSMAN',
...);
SPOOL OFF
@start_monitoring.sql
/
SELECT *
FROM (SELECT do.owner,
io.NAME index_name,
t.NAME table_name,
DECODE (BITAND (i.flags, 65536), 0, 'NO', 'YES')
monitoring,
DECODE (BITAND (ou.flags, 1), 0, 'NO', 'YES') used,
ou.start_monitoring,
ou.end_monitoring
FROM SYS.obj$ io,
SYS.obj$ t,
SYS.ind$ i,
SYS.object_usage ou,
dba_objects do
WHERE i.obj# = ou.obj#
AND io.obj# = ou.obj#
AND t.obj# = i.bo#
AND ou.obj# = do.object_id)
WHERE monitoring = 'YES';

Sql Trace ile Sql kontrolü
BEGIN
execute_immediate ('ALTER SESSION SET TRACEFILE_IDENTIFIER= REAL_RUN');
execute_immediate ('ALTER SESSION SET SQL_TRACE=TRUE');
END;
C:appoeripekproduct11.2.0client_1BIN>tkprof C:UsersoeripekDesktopORCL_j003.trc C:DISKdeneme.out
TKPROF: Release 11.2.0.1.0 - Development on Pzt Eyl 22 16:16:25 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. C:appoeripekproduct11.2.0client_1BIN>
ora_541211_err.trc
deneme.out
SELECT value
FROM v$parameter
WHERE name LIKE '%max_dump_file_size%'
Özellikle db Paket’lerinde çokça geçen sql’lerimizi detaylı incelemek için trace açabiliriz.
Oluşacak trace logların boyutuna dikkat etmeliyiz. Çok fazla log üreteceksek
max_dump_file_size değerimiz küçük olmamalıdır. > 1 GB veya > 3 GB vs. gibi olabilir.

Sql Profile ile set edilen Sql hint kontrolü
DECLARE
clsql_text CLOB;
BEGIN
SELECT sql_fulltext INTO clsql_text FROM V$sqlarea where sql_id = '9ymwq4t1v1k8n';
dbms_sqltune.import_sql_profile(sql_text => clsql_text,
profile=> sqlprof_attr('FIRST_ROWS PUSH_PRED(@SEL$3) PUSH_PRED(@SEL$4) INDEX(@SEL$3 A_NDX1)
INDEX(@SEL$2 TABL0_@SEL$2 A_NDX2)'),
name=>'PROFILE_9ymwq4t1v1k8n',
force_match=>true);
end;
select * from DBMSHSXP_SQL_PROFILE_ATTR where profile_name like '%9ymwq4t1v1k8n%';
select ADDRESS, HASH_VALUE from V$SQLAREA where SQL_ID like '%9ymwq4t1v1k8n%';
exec sys.DBMS_SHARED_POOL.PURGE ('07000012B66E3230,4036285191', 'C');
EXEC DBMS_SQLTUNE.DROP_SQL_PROFILE('PROFILE_9ymwq4t1v1k8n');
Zamanla sql profile’da sql için set ettiğimiz hint eskisi gibi performans sağlamayabilir. Bu Hint’i
değiştirmek veya sql profile tanımını drop edebiliriz.

Schema veya Tablo istatistik kontrolü
BEGIN
DBMS_STATS.gather_schema_stats (
ownname => 'SCHEMA',
method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO',
cascade => TRUE,
estimate_percent => 10,
no_invalidate => FALSE,
force => TRUE,
degree => 16);
END;
BEGIN
DBMS_STATS.gather_table_stats (
ownname => 'ORHAN',
tabname => 'TEST_LOG_TABLE',
method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO',
cascade => TRUE,
estimate_percent => DBMS_STATS.auto_sample_size,
no_invalidate => TRUE);
END;
BEGIN
DBMS_STATS.gather_table_stats (
ownname => 'ORHAN',
tabname => 'TEST_LOG_TABLE',
partname => 'P201601',
estimate_percent => dbms_stats.auto_sample_size,
granularity => 'PARTITION',
no_invalidate => TRUE,
cascade => Dbms_stats.AUTO_CASCADE,
degree => 8);
END;
Tablo ve index’lerin istatistikleri
güncel olmalıdır ki Cost-Based
Optimizer (CBO) bu güncel bilgilerle
doğru Cost- maliyet üretebilsin. Aksi
halde yanlış sql planları oluşturarak
performansız sorgularla karşı karşıya
gelebiliriz.

Partition kontrolü: Partition’lı tablolarımız hangileri? Eksik partition’ı olanlar
var mı? Otomatik Part add mekanizmamız varsa partitionları eklemiş mi?
SELECT DISTINCT table_owner, table_name
FROM all_tab_partitions
WHERE table_name NOT LIKE 'BIN$%'
AND table_owner NOT IN ('SYS', 'SYSTEM‘,...);
 Partition ekledikten sonra tablo indexleri unusable’a düşebilir, kontrol edilmeli,
unusable olanlar rebuild edilmelidir.
 OLTP db’lerde boyutu çok büyük tablolarda online split partition yapabilmenin bir diğer
yöntemi de redefinition table ‘dır. DBMS_REDEFINITION paketi ile Oracle bu desteği
vermektedir.

Resource Manager’a set ettiğimiz değerler kullanıcı kaynak kısıtlamalarını sağlıyor mu?
 Kaynak tüketim saatlerini gözeterek gündüz ve gece planları veya da belirli saatler aralığında
çalışacak planlar oluşturabiliriz. Bu aktif resource planlarımızın istatistiğini Enterprise
Manager (veya EM Cloud Control)’dan veya sql sorgularıyla görebiliriz.
SELECT TO_CHAR (m.begin_time, 'HH:MI') time,
m.consumer_group_name,
m.cpu_consumed_time / 60000 avg_running_sessions,
m.cpu_wait_time / 60000 avg_waiting_sessions,
d.mgmt_p1
* (SELECT VALUE
FROM v$parameter
WHERE name = 'cpu_count') / 100 allocation
FROM v$rsrcmgrmetric_history m, dba_rsrc_plan_directives d, v$rsrc_plan p
WHERE m.consumer_group_name = d.group_or_subplan AND p.name = d.plan
ORDER BY m.begin_time, m.consumer_group_name;
 CPU, IO ve parallelik derecelerini istediğimiz gibi set edebiliyoruz. Bu set ettiğimiz
değerlerle doğru kaynak paylaşımı yapmış mıyız yoksa adil paylaşım yapamamış mıyız? Bu
durumda faydadan çok sorun yaratmış olabiliriz. Titizlikle kontrol edilmesi gerekmektedir.

Profile, Role kontrolleri, otomatik yetki atamaları sağlıklı çalışıyor mu?
Bilgi güvenliği kriterlerine uyumlu olacak şekilde ve veritabanının kontrollü
yönetilebilmesi için;
 kullanıcı profillerine göre roller oluşturulmalı,
 her yeni kullanıcı için otomatikmen role atanmalı veya deactive edilecek kullanıcılar
için role geri alınmalı,
 yeni tablolar eklendikçe otomatikmen ilgili role yetkilerinin otomatik eklenmesi ve
kullanıcıların otomatik lock’lanması veya unlock edilmesi
gibi otomatize ettiğimiz jobların kontrolü önemlidir.

Yetkisiz yetkilendirmeler var mı?
Yetkisiz kullanıcı girişleri için DBA_AUDIT_TRAIL view’inin logon/logoff bilgilerini ve
oluşturacağınız white list / black list tablolarınızı kullanarak sch. Job oluşturabilir,
hatalı girişlerde otomatik mail ile bilgilendirilebilirsiniz.
«... tarihinde ... kullanıcısı ... veritabanına hatalı giriş / yetkisiz giriş yaptı»
Veya
«... tarihinde ... kullanıcısı... veritabanında...tablosuna insert/update/delete
girişiminde bulundu.» gibi.

Active / Inactive sesssion sayısı kontrolü?
Public yetkilendirmeler var mı?
SELECT spid AS thread,
osuser,
s.program,
s.LOGON_TIME,
s.STATUS,
p.PROGram,
s.SID
FROM v$process p, v$session s
WHERE p.addr = s.paddr AND s.status NOT IN ('ACTIVE')
ORDER BY 2 DESC;
SELECT *
FROM dba_tab_privs
WHERE grantee = 'PUBLIC'
AND owner NOT IN
('SYS', 'SYSTEM', 'SYSMAN', ...)
ORDER BY owner;

Lock’lı tablolar ve sessionlar kontrolü
-- tabloda lock var mı?
SELECT s.inst_id,
l.SID,
s.serial#,
l.TYPE,
d.object_name,
s.username blocking_session,
s.osuser,
l.LMODE
FROM gv$lock l, dba_objects d, gv$session s
WHERE d.object_id = l.id1
AND s.SID = l.SID
AND s.inst_id = l.inst_id
AND d.object_name LIKE UPPER ('%TEST_TABLE%')
ORDER BY inst_id;
-- locklı sessionları kill et
SELECT 'ALTER SYSTEM KILL SESSION '
|| CHR (39)
|| s.SID
|| ','
|| s.SERIAL#
|| CHR (39)
|| ';',
'kill -9 ' || p.spid,
osuser,
d.object_name,
s.*,
c.*
FROM gv$session s,
gv$process p,
gv$locked_object c,
dba_objects d
WHERE s.paddr = p.addr
AND s.sid = c.session_id
AND c.object_id = d.object_id

Asm disk ve db size kontrolü
SELECT name,
total_mb / 1024 AS total_gb,
TRUNC (cold_used_mb / 1024) AS used_gb,
ROUND (free_mb / 1024) AS free_gb
FROM v$asm_diskgroup;
SELECT ROUND (SUM (used.bytes) / 1024 / 1024 / 1024) AS db_size_gb,
ROUND (SUM (used.bytes) / 1024 / 1024 / 1024)
- ROUND (free.p / 1024 / 1024 / 1024)
used_space_gb,
ROUND (free.p / 1024 / 1024 / 1024) AS fre_space_gb
FROM (SELECT bytes FROM v$datafile
UNION ALL
SELECT bytes FROM v$tempfile
UNION ALL
SELECT bytes FROM v$log) used,
(SELECT SUM (bytes) AS p FROM dba_free_space) free
GROUP BY free.p;
ASMCMD> lsdg
State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED EXTERN N 512 4096 1048576 409600 46594 0 46594 0 N ASM_DATA/
ASMCMD>

Veritabanı tablo ve indexlerin boyutları kontrolü
select
owner, segment_name as table_name,
sum(bytes)/(1024*1024*1024) table_size_gb
from
dba_extents
where
segment_type in ('TABLE', 'TABLE PARTITION')
group by owner,segment_name,bytes
having sum(bytes)/(1024*1024*1024)>50
order by table_size_gb desc;
select
owner, segment_name as index_name,
sum(bytes)/(1024*1024*1024) index_size_gb
from
dba_extents
where
segment_type in ('INDEX', 'INDEX PARTITION')
group by owner,segment_name,bytes
having sum(bytes)/(1024*1024*1024)>50
order by bytes desc;
Boyutu çok büyük tablo veya index’ler için özel çalışma yapılabilir. Bunların listesi
çıkarılmalı, gözetlenmelidir.

Fragmante olmuş tabloların kontrolü
FRAGMENTED_SPACE size’ı büyük tablolar uygun zamanda önce test sonra prod ortamda
shirink yapılarak fragmante olan block yapıları sıkıştırılarak tablolar olması gerektiği size’a
getirilebilir. Alternatif olarak tablolar drop-create edilebilir veya başka bir tablespace’e
move edilebilir.
select owner,table_name,
'alter table '
|| owner
|| '.'
|| table_name
|| ' shrink space cascade;' "SHRINK",
round(((blocks*8/1024))) "TOTAL_SIZE_MB",
round((num_rows*avg_row_len/1024/1024)) "ACTUAL_SIZE_MB",
round(((blocks*8/1024)-(num_rows*avg_row_len/1024/1024)))
"FRAGMENTED_SPACE_MB"
from all_tables where owner not in ('SYS','SYSTEM')
and round(((blocks*8/1024)-(num_rows*avg_row_len/1024/1024)))>100
order by "FRAGMENTED_SPACE_MB" desc

Geçici, atıl durumda kalan tabloların belirlenerek temizlenmesi kontrolü
SELECT *
FROM (SELECT owner,
object_name,
object_type,
created,
last_ddl_time
FROM dba_objects
WHERE object_name LIKE '%TEST%'
OR object_name LIKE '%DENEME%'
OR object_name LIKE '%SIL%'
OR object_name LIKE '%GECICI%');
TEST, DENEME, SIL, GECICI, vs. gibi ifadeler geçen tablolar belirlenmeli, gereksiz
oldukları belirlenenler drop edilmelidir.

Haftalık veya aylık veritabanı büyümesi kontrolü
SELECT systarih,
tablespace_name,
TRUNC (GBYTE_used, 1) AS GBYTE_used,
TRUNC (GBYTE_free, 1) AS GBYTE_free,
TRUNC (GBYTE_sum_area, 1) AS GBYTE_sum_area,
TRUNC (percent_used, 1) AS percent_used
FROM ( SELECT SYSDATE AS systarih,
a.tablespace_name,
a.BYTES / 1024 / 1024 / 1024 AS GBYTE_used,
b.BYTES / 1024 / 1024 / 1024 AS GBYTE_free,
( (a.BYTES / 1024 / 1024 / 1024)
+ (b.BYTES / 1024 / 1024 / 1024))
AS GBYTE_sum_area,
ROUND ( ( (a.BYTES - b.BYTES) / a.BYTES) * 100, 2)
AS percent_used
FROM ( SELECT tablespace_name, SUM (BYTES) BYTES
FROM SYS.dba_data_files
GROUP BY tablespace_name) a,
( SELECT tablespace_name,
SUM (BYTES) BYTES,
MAX (BYTES) max_free_area
FROM SYS.dba_free_space
GROUP BY tablespace_name) b
WHERE a.tablespace_name = b.tablespace_name
ORDER BY ( (a.BYTES - b.BYTES) / a.BYTES) DESC)
SELECT RECORD_DATE, SIZE_IN_MB / 1024
FROM MYDB_TABLESPACE_SIZES
WHERE TABLESPACE_NAME = 'TOPLAM'
AND RECORD_DATE BETWEEN '24/03/2016'
AND '24/04/2016';

.log dosyaların kontrolü
adrci> show tracefile %.log
diag/asm/+asm/+ASM1/trace/alert_+ASM1.log
diag/clients/user_oracle/host_2010429000_11/trace/sqlnet.log
diag/clients/user_oracle/host_2010429000_80/trace/sqlnet.log
diag/rdbms/rac/node1/trace/alert_RACPROD.log
diag/rdbms/rac/node1/trace/sbtio.log
diag/tnslsnr/rac_pc/listener/trace/listener.log
diag/tnslsnr/rac_pc/listener2/trace/listener2.log
diag/tnslsnr/rac_pc/listener_rac_pc/trace/listener_rac_pc.log
diag/tnslsnr/rac_pc/listener_scan1/trace/listener_scan1.log
diag/tnslsnr/rac_pc/status/trace/status.log
adrci>
adrci (Automatic Diagnostic
Repository Command
Interface) kullanarak log
dosyaların dizinlerini
görebilir, «show incident»
ve «show alert» ile hatalı
kayıtları inceleyebiliriz.
Aynı şekilde eğer RAC mimarisi kullanıyorsak Cluster loglarını da kontrol etmemiz
gerekiyor. RAC node’ları arasındaki load balance – yük dağılımı normal mi vs.

Rman backup log kontrolü: hata almış mı başarılı bitmiş mi? rman backup süreleri,
backup validate, Rman backuplar ve test ortamlarına restore edilerek test edilmesi
-- alınan RMAN Backuplar
SELECT TO_CHAR
(start_time, 'dd.mm.yyyy hh24:mi:ss') start_time,
TO_CHAR (end_time, 'dd.mm.yyyy hh24:mi:ss')
end_time,
status,
object_type,
output_device_type
FROM v$rman_status
WHERE OPERATION = 'BACKUP'
ORDER BY start_time DESC;
-- çalışan RMAN Backup işleri ve statüleri
SELECT *
FROM ( SELECT TO_CHAR (
start_time, 'DD-MON- YY HH24:MI') "Start",
TO_CHAR (end_time, 'DD-MON-YY HH24:MI') "End",
time_taken_display "Time",
input_bytes_display "Input",
output_bytes_display "Output",
input_bytes_per_sec_display "Input/sec",
output_bytes_per_sec_display "Output/sec",
output_device_type,
status,
input_type,
ROUND (elapsed_seconds / 60, 2) "Elapsed Min",
Optimized,
ROUND (compression_ratio, 2) "Compress Ratio"
FROM v$rman_backup_job_details
ORDER BY session_key DESC)

Exportlar ve importlar: ne kadar sürede alındığı? hata almış mı? başarılı bitmiş mi?
Dump file set for SYS.TESTDB_EXP_201602202102 is:
/oracle/export/testdb_20160220_2102_datapump01.dmp
/oracle/export/testdb_20160220_2102_datapump02.dmp
Job "SYS"."TESTDB_EXP_201602202102" successfully completed at 22:12:10
Export veya import işleri tamamlandığında otomatik mail ile bilgilendirilmek oldukça
faydalı olur. Özellikle başarılı tamamlanmış mı yada hata almış mı görebilmek için
log’larının kontrolü önemlidir.
ORA-31693: Table data object "TEST"."TEST_890536" failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-39826: Direct path load of view or synonym (TEST.TEST_890536) could not be resolved.
veya

Alert.log kontrolü
 Veritabanı ORA- hata durumlarını, alter system, alter database komutlarıyla yapılan
değişiklikleri, veritabanı açılması-kapanması bilgilerini tutan bu log dosyasını inceleyerek
problemleri, uyarıları inceleyebiliriz. Çoğu zaman ilk kontrol etmemiz gerekenlerden
biridir.
 Sqlplus’tan «show parameter background» ile, EM ile, adrci ile, v$diag_info ile veya
v$parameter ile alert.log dizinini görebiliriz.
 Veritabanı sistemi üzerinde çalışma yaparken de aşağıdaki gibi açarak arka planda neler
yapıldığını sürekli izleyebiliriz;
tail -10f alert_testdb.log
 Alert.log dosyasının daha kolay okunabilmesi için external table create ederek tablodan
sorgulayabiliriz.

OEM Cloud Control ile Performans İzleme

OEM Cloud Control ile Alert ve Uyarı Mekanizması - Metricler

AWR (Automatic Workload Repository) Raporu
27
 MMON istatistikleri üretir, bu bilgiler
saat başı alınan snapshot’larda
kaydedilir, problem anında belli
snapshot’lar arasındaki veritabanı
durumunu AWR raporları detaylı açıklar.
 Top 5 Events, Wait Events, Load Profile,
System- I/O-Memory- Sql Statistics en
önemli bölümleridir.
 $ORACLE_HOME/rdbms/admin/awrrpt.
sql (RAC ise awrgrpt.sql ) scripti ile, Toad
vb. toollar ile veya EM -> ‘Automatic
Workload Repository’ ile AWR
raporlarını oluşturabiliriz.

DB time kontrolü
SELECT I.INSTANCE_NAME INSTANCE_NAME_PRINT, S.SNAP_ID SNAP_ID,
TO_CHAR (S.STARTUP_TIME, 'mm/dd/yyyy HH24:MI:SS') STARTUP_TIME,
TO_CHAR (S.BEGIN_INTERVAL_TIME, 'mm/dd/yyyy HH24:MI:SS')
BEGIN_INTERVAL_TIME,
TO_CHAR (S.END_INTERVAL_TIME, 'mm/dd/yyyy HH24:MI:SS')
END_INTERVAL_TIME, ROUND (
EXTRACT (DAY FROM S.END_INTERVAL_TIME - S.BEGIN_INTERVAL_TIME) * 1440
+ EXTRACT (HOUR FROM S.END_INTERVAL_TIME - S.BEGIN_INTERVAL_TIME) * 60
+ EXTRACT (MINUTE FROM S.END_INTERVAL_TIME - S.BEGIN_INTERVAL_TIME)
+ EXTRACT ( SECOND FROM S.END_INTERVAL_TIME - S.BEGIN_INTERVAL_TIME) / 60, 2)
ELAPSED_TIME, ROUND ( (E.VALUE - B.VALUE) / 1000000 / 60, 2) DB_TIME,
ROUND (
( ( ( (E.VALUE - B.VALUE) / 1000000 / 60)
/ ( EXTRACT ( DAY FROM S.END_INTERVAL_TIME - S.BEGIN_INTERVAL_TIME)* 1440
+ EXTRACT ( HOUR FROM S.END_INTERVAL_TIME - S.BEGIN_INTERVAL_TIME) * 60
+ EXTRACT ( MINUTE FROM S.END_INTERVAL_TIME - S.BEGIN_INTERVAL_TIME)
+ EXTRACT ( SECOND FROM S.END_INTERVAL_TIME - S.BEGIN_INTERVAL_TIME) / 60)) * 100), 2)
PCT_DB_TIME
FROM DBA_HIST_SNAPSHOT S, GV$INSTANCE I, DBA_HIST_SYS_TIME_MODEL E, DBA_HIST_SYS_TIME_MODEL B
WHERE I.INSTANCE_NUMBER = S.INSTANCE_NUMBER
AND E.SNAP_ID = S.SNAP_ID AND B.SNAP_ID = S.SNAP_ID – 1 AND E.STAT_ID = B.STAT_ID
AND E.INSTANCE_NUMBER = B.INSTANCE_NUMBER AND E.INSTANCE_NUMBER = S.INSTANCE_NUMBER
AND E.STAT_NAME = 'DB time'
ORDER BY DB_TIME DESC;
Db time’ın en yüksek olduğu saat aralığı gözetlenerek o saat aralığının AWR raporlarına bakılabilir.

Db Server CPU, IO, Swap, Memory, Disk periyodik kontrolü (PRTG, nagios, nmon, ..)
Bazen db’de aldığımız hatalar db kaynaklı olmayabilir. Server veya ağ kaynaklı da olabilir,
şüpheci davranıp tüm bu ortamları kontrol etmekte fayda var. Mümkünse db server
haftalık rapor grafikleri incelenmelidir.

ORAchk - Healt Check Raporu ile genel db kontrolü
 Oracle veritabanı ve sunucusu
üzerinde kontroller yaparak
bulgularını tespit eder,
tavsiyelerde bulunur.
 Default değerleri sunmasının
yanında Best Practices’ler ve
SR linkleri verir.
 RACchk ve Exachk tool’ları da
vardır.
 Doc ID 1268927.2 linkinden
son versiyonu indirebilirsiniz.

OS Watcher ile db server kaynak kullanım kontrolü
 Oracle db sunucusunun CPU, DISK, Memory.. gibi kaynaklarının istatiksel bilgilerini toplar ve grafiksel olarak sunar.
 Bu tool belirli aralıklarla (default 30 saniye) ps, top, vmstat, iostat gibi Unix komutlarını kullanarak log toplar.
Örneğin, OSWatcher’ ı 60 sn aralıkla ve 3 gün boyunca(3*24 saat) archive tutacak şekilde kurgulayabiliriz;
OSW_DIRECTORY = /u01/oswatcher/oswbb
OSW_DATA DIRECTORY = /u01/oswatcher/data
OSW_START_COMMAND = nohup sh startOSWbb.sh 60 72 gzip /u01/oswatcher/data
OSW_INTERNAL = 60 seconds
OSW_RETENTION = 72 hours
OWS_COMPRESSION = gzip
 Doc ID 1531223.1 metalink’ten son versiyonu indirebilirsiniz.

TFA (Oracle Trace File Analyzer)
 Oracle ve Grid altındaki logları tek komutla toplamak ve analiz etmek için kullandığımız bir tool’dur
 TFA tool’u ORAchk, EXAchk, oswacher, procwather,..vb. tool’ları da kapsar
 Oracle ‘a SR açtığımızda çoğu zaman bizden TFA çıktılarını da ister
 TFA Collector - TFA with Database Support Tools Bundle (Doc ID 1513912.1) Oracle metalink dokumanından detaylı
bilgilere ulaşabilirsiniz
 Aşağıdaki gibi belirli bir tarih aralığı için TFA raporu çıkarabilirsiniz:
[root@testdb]# cd /u01/app/oracle/tfa/testdb/tfa_home/bin
[root@testdb bin]# ./tfactl diagcollect -tag SR_3_13379477661 -from "Sep/28/2016 13:00:00" -to "Sep/28/2016
15:00:00"
....
...
Logs are being collected to: /u01/app/oracle/tfa/repository/ SR_3_13379477661
/u01/app/oracle/tfa/repository/ SR_3_13379477661 /testdb.tfa_Tue_Nov_29_11_25_16_+03_2016.zip

Önce ORA- hatasının araştırılması sonra Oracle’a açılan SR’ların kullanımı ve kontrolü
 Hata alındığında eğer 30 dk. içinde çözüm sağlayamıyorsak vakit kaybetmeden aynı
zamanda metalinkten Oracle’a SR açmalıyız
 Açtığımız SR’a alert.log, trace.log’un yanısıra varsa screen shot’lar veya ilgili olabilecek
çıktıları eklemeliyiz
 Mümkün olduğunca detay bilgi verebilirsek daha az karşılıklı yazışma olur
 Eğer hatamızın çözümü bug ile fix edilecek ise bug’ın tüm semptonlarını incelemek ve
mümkünse öncelikle test ortamında uygulayarak sonuçlarını izlemek gerekir
 Bazen küçük hatalar kısa zaman sonra büyük hataları doğurabilir. Bu yüzden küçük büyük
demeden tüm ORA- hatalarını detaylı incelemek için metalinkte ve/veya varsa
https://community.oracle.com ‘daki çözüm yollarına bakmak gerekir.

İdeal Checklist tecrübelerle olgunlaşır. Doğru olmayan Checklist’lerimizden sorumlu
olacağımız için dikkatli hazırlamalı ve fayda sağlayacak listeler oluşturmalıyız.
Veritabanında kontrol edilmesi gereken birçok nokta var, tüm hepsini aynı anda
aklımızda tutamayabilir bazı noktaları kontrol etmeyi unutabiliriz. Eğer bu alışkanlık
haline gelirse o zaman sonuç daha kötü. Dolayısıyla elimizin altında buna benzer bir
kontrol listemizin olması işimizi oldukça kolaylaştıracaktır.
Zamanla listelerimizdeki bazı maddelerin çıkarılması veya yeni maddelerin
eklenmesi gerekebilir. Sürekli güncel tutmamız önemli. Yani kontrol listelerimizi de
kontrol etmeliyiz. Bu şekilde ideal Checklist’imiz olur.
Kontrol listemizin güncellenmesi (Checklist check)

Referanslar:
• https://blogs.oracle.com/db/entry/oracle_resource_manager_and_dbms
• https://support.oracle.com

Oracle veritabani performans kontrol listesi

Oracle veritabani performans kontrol listesi

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (15)

En vedette

En vedette (20)

Similaire à Oracle veritabani performans kontrol listesi

Similaire à Oracle veritabani performans kontrol listesi (20)

Oracle veritabani performans kontrol listesi