Bilişim 2011 kongresi 26-29 Ekim 2011 tarihlerinde JW Marriott Hotel Ankara'da...

Türkiye Bilişim Derneği’nin düzenlediği ve bilişime taraf tüm kesimlerin sinerjisiyle oluşturulacak Bilişim2011, 26-29 Ekim 2011 tarihlerinde JW Marriott Hotel Ankara'da gerçekleştirilecektir. Etkinlikte daha güzel, yaşanılabilir, özgür ve demokratik bir dünya için "İnsan etkileşimi" doğrultusunda "Hukuk”, “Enerji”, “Sosyal Hareketler”, “Eğitim”, “Teknoloji”, “Sağlık” ve “İletişim Teknolojileri” gibi pek çok alanda farkındalık oluşturulmaya çalışılacaktır.

28. Ulusal Bilişim Kurultayın’da  akademik bildiriler, teknolojik ve uygulama bildirilerinden oluşan oturumlar düzenlenecektir. Ayrıca Doktora Tez Konu Tartışmaları adında isteyen doktora öğrencilerinin tez konu önerilerini özetle sunabilecekleri ve tartışılacağı özel oturumlar düzenlenecektir.

Detaylı bilgi için: http://www.bilisim.org.tr/index.html

10g sürümden 11g sürüme yükseltmede SQL çalıştırma planlarında kesintisiz performansın sağlanması

Pek çok DBA in ve PL/SQL geliştiricininde bildiği üzere, veritabanında bir parametre değişikliği tüm veritabanı çapında etkin olmaktadır. Bu durum,  SQL komutlarında kullanılan bir “hint” in, outline nın veya obje güncellemesini kapsayacak istatistikleri etkileyen SQL profilinin tam tersidir.

DBA’in veritabanını 10g sürümlerden 11g sürüme yükseltmesinde beklentilerinden birisi, yükseltme sonundaki platformda 10g deki çalıştırma plan varsayılan ayarlarının muhafaza edilmesidir. Ancak bu, 11g ortamında masum bir beklenti olarak kalacaktır!

Değişikliklerden geri dönülmesi  ve/veya daha önceki sürümlerdeki herhangi bir değişikliğin kaldırılması performansı oldukça etkileyebilecektir. Bu yüzden 10g performans baseline’larını  11g de de aynen alıkoyma fırsatı mümkün olursa, bu durum yükseltme sonunda çalıştırma planı maliyeti ile ilişkili karşılaşılacak sorunlar noktasında en önemli kurtarıcı olacaktır. Bu noktada “10g planları 11g planlarından dahamı iyidir” sorusu kafa karıştırıcı olacaktır. Elbette böyle bir iddia %100 kanıtlanır olmasada, 11g deki pek çok “gizli” parametrenin 10g deki değerlerinden oldukça farklı olması sebebiyle SQL çalıştırma planı performanslarında gerçekten dramatik düşüşler olabilecektedir. Aslında 10g öncesi 9i platformundan yükseltmelerde bu tür sıkıntılar mevcuttu, ancak 11g deki performans kaybı daha önceki sürüm yükseltmelerinden daha dramatik olmaktadır. Bu tür 11g sürümüne yükseltme sonrası çalıştırma planı performans problemlerinin detaylı analizlerine ve teknik incelemelerine, Coşkan Gündoğar'ın aşağıdaki yazı dizilerinden erişebilirsiniz, bu dizilerde oldukça faydalı analizler sebepleriyle beraber yer almaktadır.

·         http://coskan.wordpress.com/2011/03/04/plan-stability-through-upgrade-to-11g-why-is-my-plan-changed-extra-nested-loop/

·         http://coskan.wordpress.com/2011/02/17/plan-stability-through-upgrade-why-is-my-plan-changed-new-optimizer-parameters/

İşte bu tür parametrelerin varsayılan ayarlarındaki bariz değişiklikler yüzünden meydana gelebilecek sıkıntılı durumlarda, DBA lere hızlıca performans iyileştirme imkanı vermek ve aslında 10g deki SQL profillerinde uzun çabalar sonunda erişilen gelişmiş çalıştırma planı performansının 11g’de de aynen devam etmesini sağlamanın en iyi metotlardan birisi; 10g çalıştırma planlarının baseline koleksiyonunu dışarı almak ve sistem 11g sürümüne yükseltildiğinde bu koleksiyonun 11g SQL Plan Baseline içerisine yüklenmesi olmaktadır.

Açık kursör hatalarının çözümü hakkında bir inceleme

Eğer çok sık “Maksimum Open Cursors exceeded error” hata mesajı ile karşılaşılıyorsa, ilk yapılması gereken şeylerden birisi open_cursors başlangıç parametresinin değerinin kontrol edilmesidir. Aşağıdaki gibi açık kursörlerin mevcut değeri görüntülenebilir.

SQL> show parameter open_cursors

NAME         TYPE        VALUE

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

open_cursors integer     300

OPEN_CURSORS parametresi bir oturumun bir seferde maksimum sayıda açabileceği kursör sayısını ayarlar ve açık kursör sayısını kontrol etmek için kullanılmaktadır. Bu değerin çok düşük seviyede ayarlanması ORA-01000 hatasının alınması ile sonuçlanmaktadır. OPEN_CURSORS parametresi için çok büyük bir değerin belirlenmesinin bir zararı yoktur (pek mümkün olmasada tüm oturumların eşzamanlı olarak maksimum kürsör dışarı vereceği beklenmediği durumlar dışında), böylece bu parametreyi daha yüksek bir değere artırarak genellikle kursör tabanlı hatalar kolayca çözülebilir. Ancak, bu değerin arttırlması her zaman bu sorunu çözmeyebilir. Böyle durumlarda bu açık kursörleri kullanan proseslerin hangileri olduğunun bulunması gerekmektedir.  

SQL> select a.value, s.username,s.sid,s.serial#,s.program,s.inst_id

from gv$sesstat a,gv$statname b,gv$session s

where a.statistic# = b.statistic# and s.sid=a.sid

and b.name='opened cursors current';

GV$OPEN_CURSOR (veya V$OPEN_CURSOR) görünümleri her bir kullanıcı oturumunun o an açtığı, çözümlediği(parse) ve önbelleğe aldığı tüm kursörleri göstermektedir. Aşağıdaki sorgu kullanılarak yüksek sayıda açık ve çözümlenmiş veya önbelleğe almış oturumlar belirlenebilmektedir.

SQL> select saddr, sid, user_name, address,hash_value,sql_id, sql_text

from gv$open_cursor

where sid in

(select sid from v$open_cursor

group by sid having count(*) > &esik_degeri);

Bu sorgu tanımlanan eşik değerinden daha yüksek sayıdaki açık kursörler için bütün oturumları listelemektedir. Bu şekilde, sorgu çıktısı sınırlandırılabilmekte ve açık, çözümlenmiş veya yüksek sayıda  kursörleri önbellekleyen oturumlar üzerine odaklanılabilmektedir.

Yukardaki sorgu sonucunda sorunlu oturum için gerçek SQL kodu ve açık kursör sayısı aşağıdaki gibi elde edilebilmektedir:

ASM disk ve disk grubu I/O performansının izlenmesi

Oracle 11.2 sürümü ile gelen iostat özelliği ile disk başına okuma ve yazma işlemleri gerek I/O operasyonu olarak gerekse bytes değeri şeklinde listelenebilmektedir.

iostat [-et][--io] [--suppressheader] [--region] [-G diskgroup] [interval]

-e  takısı hata istatistiklerini gösterir (yazma/okuma)

-t  TIMED_STATISTICS değeri TRUE olarak ayarlandıktan sonra saniyenin yüzdesi değerinde toplam I/O zamanını veren zaman bazlı istatistik.

-G  izlenecek disk grubunun adı

-interval   komutun x saniye aralıklarla tekrarı

Pek çok iostat komutu gibi ilk aralıkta çalışma işlemi toplam istatistikleri getirmektedir ve arkadan gelen aralıklar önceki rapordan itibarenki süreyi kapsar.

ASMCMD> iostat -t -G DATA01 5

Group_Name  Dsk_Name                    Reads         Writes        Read_Time     Write_Time

DATA01        DATA01 _CD_00_ED2HCELL12  368823115776  398765133824  15652.064264  115609.999195

DATA01        DATA01 _CD_00_ED2HCELL13  360830513152  399665251328  15293.415546  108496.371997

Group_Name Dsk_Name                 Reads   Writes  Read_Time Write_Time

DATA01     DATA01_CD_00_ED2HCELL12   0.00      0.00  0.00      0.00

DATA0      DATA01_CD_00_ED2HCELL13   0.00   6553.60  0.00      0.00

Bu bilgi V$ASM_DISK_IOSTAT görünümünden de çıkarılmaktadır.

Paralel sorgu proseslerinin SQL_TRACE metodu ile izlenmesi

Bir veya daha fazla sayıda belirli paralel sorgu prosesinin SQL_TRACE ile izlemesini yapabilmek için, öncelikle aşağıdaki gibi izlenmesi gerekecek paralel sorgu proseslerinin tespit edilmesi gerekmektedir.

SQL> select inst_id,p.server_name,

p.status as p_status,

p.pid as p_pid,

p.sid as p_sid

from gv$px_process p

order by p.server_name;

Yukardaki sorgu sonucu p002 ve p003 adlı proseslerin izlenmesine karar verildiğini farzederek, aşağıdaki komutu kullanarak sadece bu iki proses için SQL_TRACE izlemesi etkinleştirilebilir.

SQL> alter system set events ‘sql_trace {process: pname = p002 | p003}’;

İzleme işlemi tamamlandığında ise aşağıdaki gibi devredışı bırakılabilmektedir.

SQL> alter system set events ‘sql_trace {process: pname = p002 | p003} off’;

** “Oracle 11g Performance Tuning Recipes- A problem solution approach” adlı kitaptan bir bölüm **

Oracle 11g çoklu kolon CBO istatistikleri

Oracle 11g, tekil tablo sorgularının “where” kısmında çoklu kolonlar belirtildiği durumlarda, kolon grupları istatistikleri kullanarak maliyet tabanlı geliştirici(cost based optimizer-CBO) nin daha iyi karar almasına yardımcı olacak geliştirilmiş istatistiklerin işleme alınmasına imkan vermektedir. Standart istatistiklere ilave olarak, kolon grubu veri dağıtımında çarpıklık yer aldığında gelişmiş maliyet tahminleri için bu kolon grupları üzerinde histogramlarda oluşturulabilir.

CBO’nun bir sorgu için kendi çalıştırma kararlarını sırayla alması için, muhtemel erişim yolları için maliyet tahminlerini hesaplamak için uygun istatistikleri kullanması ile olur. Eğer kolon histogramları mevcutsa, doğrulanmış değerlerin seçiciliğini hesaplamak için optimizer bu histogramları kullanmaktadır. Bu seçicilik, maliyetlerin tahmin edilmesinde ve sonuçta en iyi erişim yolunun tercih edilmesinde önemli bir etkendir. Oracle 11g öncesinde istatistikler bireysel kolonlardan oluşturulabilmekteydi. Tek bir tablo üzerinde birçok kolon arasındaki ilişkiyi gerçekleştirmek için CBO maliyet hesaplamalarında yetersizlik başlıca bir sınırlama olmaktaydı.

Aşırı CPU tüketen UNIX Proses ID sinden ilgili SQL komutlarının tespit edilmesi

Sistemin yavaşladığı zamanlarda bakılması gereken noktalardan biriside UNIX/Linux proses kullanımında aşırı kaynak tüketen prosesin ID sini bulmak, bunun Oracle SQL prosesi olup olmadığının tespit edilmesi, eğer SQL prosesi ise bunun hangi SQL komutu olduğunun bulunarak çalıştırma planında ters giden noktaların analiz edilmesidir.

Unix ve Linux ortamlarda, kaynak kullanan proseslerin ID’si(PID) tespit edilince bu PID nin Oracle veritabanı prosesi ile ilişkili olup olmadığıda anlaşılabilmektedir. Bu süreç en baştan sona doğru aşağıdaki gibidir;

1.    Unix/Linux sistem komutu ile kaynak kullanan prosesler ve ilişkili ID leri belirlenmelidir.

2.    Veritabanı ile ile ilişkili prosesler belirlenmelidir.

3.    Bu proses hakkındaki detaylar veritabanı data dictionay görünümlerinden ortaya çıkarılmalıdır.

4.    Eğer bu proses bir SQL komutu ise, bunun detayları alınmalıdır.

5.    İlgili SQL komutu için çalıştırma planı oluşturulmalıdır.

Bununla ilgili bir örnek göstermek gerekirse, ps komutu ile işletim seviyesinde en çok CPU tüketen sorguları bulmak istediğimizi varsayarak:

Dünün STATSPACK snapshotlarındaki bekleme olayları delta değişimlerinin e-mail ile otomatik olarak alınması

Bir gün evvel STATSPACK snapshotlarından bekleme olaylarının delta değişimlerinin email ile otomatik olarak alınması için aşağıdaki shell script kullanılabilir ve ardından bu script crontab içerisine eklenerek her gün çalıştırılması sağlanabilir. Bu tip shell scriptleri içine istenen SQL sorguları eklenebilir ve bu şekilde proaktif bir performans izleme yolu kolayca devreye alınabilir.

#!/bin/bash
if [ $# -ne 1 ]; then
echo "Usage: $0 SID"
exit 1
fi
# source oracle OS variables
. /var/opt/oracle/oraset $1
#
BOX=`uname -a | awk '{print$2}'`
#
sqlplus -s <<EOF
/ as sysdba
spo $HOME/bin/log/statspackdelta.txt
set lines 80
set pages 100
SELECT s1.snap_time,
w1.event,
s1.snap_id,
ROUND((w1.time_waited_micro/1000000/total_waits),4) "Avg_wait_sec",
LAG(ROUND((w1.time_waited_micro/1000000/total_waits),4))
OVER (ORDER BY ROUND((w1.time_waited_micro/1000000/total_waits),4)) prev_value,
ROUND((w1.time_waited_micro/1000000/total_waits),4) - LAG(ROUND((w1.time_waited_micro/1000000/total_waits),4))
OVER (ORDER BY ROUND((w1.time_waited_micro/1000000/total_waits),4)) delta_value
FROM stats\$snapshot s1,
stats\$system_event w1
WHERE s1.snap_id between (SELECT MIN(snap_id) FROM stats\$snapshot WHERE  snap_time>=TRUNC(sysdate-1)+5/1440)
AND (SELECT MIN(snap_id) FROM stats\$snapshot WHERE snap_time>TRUNC(sysdate)+5/1440)
AND s1.snap_id = w1.snap_id
ORDER BY 1 desc,4 desc,6 desc;
EOF
cat $HOME/bin/log/statspackdelta.txt | mailx -s "Statspack wait event delta report on DB: $1 $BOX" u.inal@xxx.com
exit 0

Ardından crontab içine günlük rütin çalışması için eklenir.

# Wait event delta degisim rapor
16 11 * * * /orahome/oracle/bin/statspackdelta.bsh DBA1

Sistem ve oturum istatistiklerinden delta değerlerin izlenmesi

Oracle üzerindeki bazı görünümler sistem çapında ve oturum seviyesinde istatistiksel bilgileri göstermektedir. Bu görünümler genellikle veritabanının en son online olmasından itibaren birikmiş değerleri göstermektedir. Analiz için istatistiklere bir değer katmak için belirlenen zaman süreleri içinde iki örneklemenin bu istatistiğe dahil olması olması gerekmektedir. İşte bu başlangıç ve bitiş değerleri arasındaki farklılıklar sıklıkla “delta” değerleri olarak bilinmektedir. “Delta” değerler bir bekleme olayının kesin olarak anlaşılması ve pek çok durumda bu kronik sorunların üstesinden gelmekte oldukça ufuk açıcı bilgiler sunmaktadır.

Sistem çapında istatistikleri gösteren yaygın erişilen görünümler, V$SYSSTAT görünümü ile oturum seviyesi bilgileri içeren V$SESSTAT görünümleridir. V$SESS_IO gibi görünümler, öncelikle mantıksal ve fiziksel blok okumaları ve blok değişimlerini içeren V$SESSTAT içinde bulunan istatistiklerin alt kümesini göstermektedir. V$SYSSTAT görünümü içindeki istatistikler genellikle aşağıdaki listeden bir veya iki alt kategoriye veya sınıfa bölünmektedir. user (1), redo (2),enqueue (4), cache (8), OS (16), RAC (32), SQL (64) ve debug (128). Eğer bir sınıf birçok alt sınıfa bölünürse CLASS kolonuna atanan değer, her bir sınıf tipi ile ilişkili değerlerin toplamı olmaktadır. Tamamlanma(elapsed) süresini işaret eden istatistik (DB time, parse time cpu, parse time elapsed, redo synch time, redo write time, v.b) centisaniye olarak belirtilir.

Belirlenen iki STATSPACK snapshotu arasındaki bekleme olaylarının delta farklılıklarıda STATS$SNAPSHOT ve STATS$SYSTEM_EVENT görünümleri birleştirilerek aşağıdaki sorgu ile tespit edilebilir;

Segment Tavsiyecisi raporlarının otomatik olarak e-mail ile gönderilmesi

Segment Tavsiyecisinin otomatik olarak öneri raporları hazırlaması ve bu çıktıları email ile otomatik olarak almak için bir shell script içine Segment Tavsiyecisi çıktısını gösterecek SQL eklenebilir. Aşağıda bununla ilgili bir shell script örneği yer almaktadır.

#!/bin/bash

if [ $# -ne 1 ]; then

echo "Usage: $0 SID"

exit 1

fi

# source oracle OS variables

. /var/opt/oracle/oraset $1

#

BOX=`uname -a | awk '{print$2}'`

#

sqlplus -s <<EOF

dba1/dbapasswd

spo $HOME/bin/log/seg.txt

set lines 80

set pages 100

SELECT

'Segment Advice --------------------------'|| chr(10) ||

'TABLESPACE_NAME : ' || tablespace_name || chr(10) ||

'SEGMENT_OWNER : ' || segment_owner || chr(10) ||

'SEGMENT_NAME : ' || segment_name || chr(10) ||

'ALLOCATED_SPACE : ' || allocated_space || chr(10) ||

'RECLAIMABLE_SPACE: ' || reclaimable_space || chr(10) ||

'RECOMMENDATIONS : ' || recommendations || chr(10) ||

'SOLUTION 1 : ' || c1 || chr(10) ||

'SOLUTION 2 : ' || c2 || chr(10) ||

'SOLUTION 3 : ' || c3 Advice

FROM

TABLE(dbms_space.asa_recommendations('FALSE', 'FALSE', 'FALSE'));

EOF

cat $HOME/bin/log/seg.txt | mailx -s "Seg. rpt. on DB: $1 $BOX" uinal@hotmail.com

exit 0

Yukardaki shell script, aşağıdaki gibi “cron” aracı ile rütin aralıklarla çalışacak şekilde zamanlanmış görev olarak atanabilir, böylece performans problemine sebebiyet vermeden proaktif sorun çözüm önlemi alınmış olacaktır.

# Segment Advisor report

16 11 * * * /orahome/oracle/bin/seg.bsh DWREP