Mutlu yıllar !

2012 yılında tüm düşlerinizin gerçekleşmesi dileğiyle!

Oracle 11g de PGA ve SGA tavsiyecileri arasında bellek dağıtımı hesaplamaları ve AMM

Oracle 11g de PGA ve buffer cache tavsiyecileri arasındaki bellek dağıtım prosedürü daha az karmaşıktır. Ortalama direkt IO zamanını hesaplamak veya PGA tavsiyecisi verisini bytes değerinden tamamlanma süresine çevirmek gerekli değildir, çünkü V$PGA_TARGET_ADVICE view görünümü zaten tamamlanma süresi beklentilerini dahil etmektedir. Bu sebeple Oracle 10g den daha az karışık olan aşağıdaki sorgu kullanılarak her iki tavsiyeci direkt olarak kıyaslanabilmektedir:

Oracle 10g için PGA ve Buffer Cache bellek dağıtımlarında tavsiyecilerin kullanımı

IO bekleme olayları sıklıkla bizi doğru bellek iyileştirme yönüne yönlendirmektedir. Örneğin tüm bekleme olayları tampona alınmış IO için ise, PGA yı artırmak muhtemelen yardımcı olmayacaktır. Ancak, hem geçici segment beklemeleri hemde tampona alınmış IO beklemeleri önemli  ise, en iyi deneme bile belirgin değişme yapmayabilir.

V$PGA_TARGET_ADVICE ve V$DB_CACHE_ADVICE görünümleri  artan veya azalan bellek veya PGA boyutunun muhtemel etkisini belirlemek için tavsiyeler sunmaya yardımcı olmaktadır.  Bu görünümleri kullanarak PGA ve SGA arasında nasıl en iyi bellek tahsisini belirleyebileceğimizi görebiliriz.  

Oracle 10g’de, bu prosedür oldukça komplike hale getirilmiştir, çünkü PGA tavsiyecisi geçen süre ile ilgili tahminler içermemektedir.  Oracle 10g de ideal prosedür aşağıdaki gibidir:

1.       Geçici segment direkt IO işlemleri için ortalama süre ve blok sayısı belirlenmektedir.

2.       Bu ortalamalar kullanılarak V$PGA_TARGET_ADVICE  içindeki byte miktarı, geçen süreye dönüştürülür.

3.       V$DB_CACHE_ADVICE  içindeki bu PGA tamamlanma  süreleri, tampon önbellek tavsiyeci tamamlanma süresi ile birleştirilerek, hangi hedef birleşmelerinin tüm tamamlanma süreleri içinde azami artış gösterdiğinin belirlenmesi sağlanır.  

Başka bir veritabanından Statspack verisinin import edilmesi

Analiz etmek için Statspack verisini bir veritabanından başka bir veritabanına taşımak istenebilir. Şöyle diyelim; üretim veritabanının PERFSTAT şeması ayda bir sefer export ediliyor, ardından yer kazanmak için Statpack tabloları TRUNCATE ile  düşürülüyor. Bu silinen snapshotlar, geçmiş snapshotlara ihtiyaç duyulduğu zamanlarda(mesela geçen ayın snapshotlarına bakılmak istendiğinde) başka bir veritabanına import edilebilir. Açık olarak,devam eden snapshot yakalama prosesinde karışıklık yaratabileceğinden dolayı bu import işleminde üretim veritabanı hedef olamaz.  

Örnekteki senaryoda hesaba katılması gereken; STATS$IDLE_EVENT adlı Statpack tablosu belirli Statpack sürümünde eksik olan ilave bekleme olaylarını içerebilmektedir. PERFSTAT sahipliğindeki tabloların kaba kuvvetle düşürülmesi yaklaşımı ve ardından import işlemi ile bu tabloların tekrar oluşturulmasına izin verilmesi bu özelliği ortadan kaldırmaktadır. Bu sebeple bundan sonraki yaklaşım herhangi bir Statpack tablosunu düşürmez.  Bunun yerine bütünlük kısıtlamalarını(integrity constraints) devredışı bırakır, sptrunc.sql ile tabloları düşürür ve mevcut tablolara veriyi import etmek için IGNORE=Y import takısını kullanır.

Başlangıç noktası olarak, spcreate.sql ile Statspack kurulu bir veritabanı gerekmektedir. Bu hedefteki Statspack sürümü export edilen dump dosyasının Statspack sürümü ile aynı olmalıdır. Otomatik snapshot yakalama özelliği devredışı bırakılmış olmalı ve öncelikle sptrunc.sql ile tüm mevcut snapshotlar sistemden temizlenmelidir.

TROUG üyelerine PACKT Oracle Kitaplarında %22 İndirim

Türk Oracle Kullanıcı Grubu üyeleri artık “Packt Publishing” yayınevinin Oracle teknolojileri konulu kitaplarını satın alırken 22% indirim hakkına sahip! Bu indirimden faylanmak isteyen TROUG üyeleri, TROUG iletişim sayfasından üyelik için kullandıkları e-mail adreslerini belirterek, indirim kuponlarını talep edebilirler. Üyeler, internet üzerinden verecekleri siparişlerde bu indirim kuponu kodlarını kullanarak 22% indirim sağlayabilecekler.

Packt Publishing IT teknolojileri üzerine 600’den fazla, Oracle teknolojileri üzerine ise 100’e yakın kitap yayınlamış, sektörün önde gelen yayınevlerindendir. Packt’in Oracle teknolojilerine ilişkin kitaplarının listesine şu linkten ulaşılabilir: http://www.packtpub.com/books/oracle

TROUG’ye ücretsiz üye olmak için: http://apex.oracle.com/pls/apex/f?p=38448:1

Oracle 11g Dataguard mimarisinde medya recovery hizmetlerinin iyileştirilmesi

Media recovery hizmetlerinin amacı, bir veritabanını uygun zaman dilimine geri döndürmek veya primary veritabanındaki tüm aktif işlemlerin birebir olarak fiziksel standby veritabanındada uygulanmasıdır. Zaten bu yazınında amacı Data Guard mimarisinde primary veritabanındaki işlemlerin fiziksel standby veritabanınında da uygulanması esnasında muhtemel darboğazlarını işaret etmek ve bunlarla ilgili gerekli iyileştirme işlemlerinin neler olduğunun gösterilmesidir.

Açık ve önbelleklenmiş imleçlerin izlenmesi

Açık imleçler(cursors) library cache içinde yer tutmaktadırlar. Pekçok oturumunun, library cache içini tepeleme doldurmasının önüne geçmek için veya CPU’nun milyonlarca çözümleme(parse) çağrıları ile tıkanmasını önlemek için, OPEN_CURSORS parametresi ayarlanır.

OPEN_CURSORS parametresi, her bir oturumun oturum başına açabileceği maksimum imleç sayısını belirtir. Mesela, eğer OPEN_CURSORS parametresi değeri 1,000 olarak ayarlanırsa, bu durumda her bir oturum bir seferde en çok 1,000 imleci açabilir. Eğer tek bir oturum OPEN_CURSORS parametresince belirlenen değeri aşarsa, bu açacağı imleçler esnasında ORA-01000 hata mesajını alacaktır.

OPEN_CURSORS parametresinin varsayılan değeri 50’dir, ancak  pek çok uygulama için bu sayının en azından 500, hatta pek çok yeni nesil web uygulamalarında yüzlerce kullanıcı oturumunun paylaşımlı havuzları sık şekilde kullanmasından dolayı bu sayının 1,500 olması tavsiye edilir.

Eğer SESSION_CACHED_CURSORS parametresi ayarlanmazsa, değeri 0 olarak ayarlanır ve oturum için hiç bir imleç önbelleklenmez. Tabii, imleçler paylaşımlı havuzda öncelleklenecek, ancak bunları bulmanız gerekecektir ve bu durum en iyimser yaklaşımla bolca yumuşak çözümleme(soft parse) olayına sebep verecektir. Eğer bu parametre ayarlanırsa Oracle, library cache içine bakacak ve bu SQL komutu için 3 seferden fazla çözümleme(parse) çağrısı yapılıp yapılmadığına bakacaktır. Eğer yapılmışsa, Oracle bu komut ile ilişkili oturum imlecini oturum imleç önbelleği içine taşıyacaktır.  Bu oturum tarafından ilgili SQL komutu için yapılan daha sonraki çözümleme çağrıları oturum imleç önbelleğinden doldurulacak, böylece yumuşak çözümleme(soft parse) olayından bile kaçınılmış olunacaktır. Bu noktada çözümleme işleminden kaçınmak mümkün değildir ve “daha yumuşak” çözümleme olayları, daha az CPU tüketimi ve çok daha hızlı çözümleme anlamına gelecektir.

Optimizer’ın doğru indeksi kullanmama sebepleri

Bazı durumlarda SQL komutu indeks kullanmadığından veya doğru indeksi tercih etmediğinden kötü performans gösterebilmektedir. Eğer uygun bir indeks yoksa, optimizer muhtemelen full tablo taraması(FTS) yapacaktır. Bazen çoğunlukla ideal olduğu düşünülen indeks yerine başka bir indeks seçilip kullanılacaktır. Eğer optimizer bir indeks kullanmıyor veya yanlış olduğu düşünülen bir indeks kullanıyorsa, aşağıdaki durumların gözden geçirilmesi gerekmektedir:

  v Uygun indeksin var olduğundan emin olun. Uygun indeks, SQL komutunun filtre kısmındaki şartların, mümkün olan en fazla sayıda sorgudaki filtre sırasına uygun olarak, kolon isimlerini karma indeks şeklinde barındıran indekstir. Eğer bu şekilde bir indeks yer almıyorsa, optimizer atlanan kolonların benzersiz değerleri başına efektif olarak “index range scan” işlemi çalıştıran indeks ile INDEX SKIP SCAN işlemini kullanabilecektir. Bu gibi operasyonlar, atlanan kolonların benzersiz değerlerinin sayısı düşük olduğunda değer kazanacaktır. Aksi takdirde,  bu operasyon verimsiz olma eğilimine girecektir. Atlanan kolon sonrası veya eşitsizlik kıyaslamasında kullanılan kolon sonrasında indeks tanımına dahil olan herhangi bir kolon, taranacak indeks yaprak blok sayısını azaltmak için kullanılamayabilir. Bu durum çalıştırma planında “predicate information” bölümünü incelerken görülebilmektedir. İndeks bloklarına direkt olarak erişmek için kullanılamayacak olan kolonlar indekse etki eden ilave FILTER yüklemi olarak belirecektir.

CPU üzerinde “çözümleme zamanı” sorunu

Bir komutun çözümlemesi, bir PARSE çağrısının parçası olarak gerçekleştirilmesi için zorunlu olarak gerekmemekte, ancak başlangıç çözümlemesinden itibaren imlecin geçersiz olduğu durumlarda EXEC çağrısı vasıyasıyla da tetiklenebilmektedir. Bu demektirki, izleme dosyasında pek çok PARSE çağrısı görülmemesine rağmen “çözümleme” ile ilişkili performans sorunlarınız olabilmektedir. TKPROF aracı üzerinden görülebilen bununla ilgili istatistikler, çözümleme esnasında library cache içindeki kayıplar(misses) olarak ve çalıştırma esnasında ise library cache içindeki kayıplar(misses) olarak görülmektedir.  

Burada bunların görülme sayısı, komutun optimizasyon aşamasıda dahil ne kadar sayıda “full parse-tam çözümleme” ihtiyacını duyduğunu temsil ederken, halbuki TKPROF çıktısındaki çözümleme istatistiklerinde görülebilen “hafif çözümleme-soft parse” çağrıları daha düşük kaynak tüketim hassasiyetindedir.

İdeal olarak, bir uygulama imleci bir sefer çözümleyerek hem “hafif”,  hemde “sert” çözümleme çağrılarının üstesinden gelebilir ve aynı imlecin daha sonraki çalıştırma işlemleri için gerekli olan en uzun sürede bu imleci açık olarak tutmaktadır.  İmlecin geçersiz(invalidated) olmasının önlemi alındığında, imleç bir sefer çözümlenecek ancak pek çok kez çalıştırılabilecektir.

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

Oracle ASM Cluster Dosya Sistemi (ACFS)

ASM Cluster Dosya Sistemi ilk olarak Oracle 11.2.0.1 sürümü ile Linux sistemler üzerinde desteklenecek şekilde hizmete girmiş, Oracle 11.2.0.2 sürümü ile Solaris, AIX,HP-UX ve Windows platformlarınada bu destek hizmete girmektedir. Oracle 11.2.0.2 sürümü ile ACFS yapısına replikasyon, etiketleme, şifreleme ve realm tabanlı güvenlik özellikleride ilave edilmiştir.

ACFS sadece ASM volumleri desteklemektedir, ancak ASMLib sürücüleri ile kullanılamaz ve fdisk gibi formatlama araçları ile bu ACFS volumleri formatlanmamalıdır. ACFS, Oracle external binary veri dosyaları (LOB dosyalar ve BFile gibi), external dizinler, Oracle veritabanı home dizin dosyaları, izleme dosyaları gibi çeşitli paylaşılabilir dosyalara senkronize erişimi desteklemektedir. ACFS üzerinde Oracle’nın desteklemediği dosyalar, ASM diskgrupları bünyesinde tutulan kontrol dosyaları, SPFILE dosyaları, redo log dosyaları, arşiv log dosyaları,clusterware dosyaları(OCR ve voting dosyaları) ve veri dosyalarıdır.

Standby üzerinde backup retention ilkesinin değiştirilmesi

Standby veritabanı oluşturulduğu anda yedek alıkoyma(retention) ilkesini değiştirmek mümkün olmamaktadır. Standby sunucu üzerindeki disk alanı yetersiz duruma geldiğinde veya diğer başka kısıtlamalar sebebiyle, primart veritabanından yedek alıkoyma ilkesinin değiştirilme ihtiyacı duyulabilmektedir. Bu değişiklik işlemi  esnasında ise aşağıdaki hata mesajı ile karşılaşılmaktadır.

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 days;

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of configure command at 08/18/2011 14:42:35

RMAN-05021: this configuration cannot be changed for a BACKUP or STANDBY control file

Yedekleme alıkoyma ilkesinin –eğer mümkünse- değiştirmenin en kolay yolu; bir switchover işlemi(standby veritabanını primary yapmak), ardından alıkoyma ilkesini değiştirmek ve sonrada orjinal primary veritabanına bir switchover işlemi yapmaktır. Ancak, bu her sefer mümkün olmamaktadır, özellikle dataguard yapılandırması asimetrik ise ve standby sistem daha çok bir felaketten geri kurtarma senaryosu için “veri koruma” modunda kullanılmaktaysa...

RMAN raporlaması

Her firma için en değerli nokta verilerdir ve en iddialı iş ise bir felaket anında bu verilerin en kısa sürede herhangi bir kayıp yaşanmadan sisteme geri yüklenmesidir. Pek çok durumda veritabanı yöneticileri hangi veri dosyalarının yedeğinin alınmasının gerektiğini bilmeden ve hangi veri dosyalarının yedeklendiğini bilmeden eksik geri kurtarma işlemi yapmaktadırlar. Veritabanının etkili olarak yedeklendiğinin ve gerektiği zamanda da başarılı şekilde geri yükleme yapılacağından emin olunması gerekmektedir. RMAN raporlaması, başarılı geri yükleme için veritabanı yedeklerini belirlemede en etkili ve en kolay yolu sağlamaktadır.

Genellikle, bir katalog görünümü(view) tüm veritabanlarının metadatasını içermektedir ve kullanışlı yedek bilgisini alabilmek için komplike bir sorgu yazılması gerekmektedir. Ancak, RMAN raporlaması ile LIST ve REPORT komutlarını kullanarak aynı bilgiler daha kolay yoldan elde edilebilmektedir.  RMAN raporlaması, Oracle sürümleri arttıkça gelişme göstermekte ve artık hangi veri dosyalarının yedeğinin alınmadığını veya başarılı bir geri yükleme için hangi yedekler gerekecektir gibi pek çok sorunun cevabını belirlemede oldukça yararlı olmaktadır. 

RMAN raporlamasını verimli kullanarak, nelerin yedeklendiği ile ilgili tereddütlü durumların üstesinden gelinmekte ve eksik geri kurtarma gibi can sıkıcı durumlardan kurtulunabilmektedir. Yedekleme ve geri kurtarma stratejesinin bir parçası olarak, bu raporlar aşağıdaki durumları tespit etmek amacıyla belirli periyotlarla çalıştırılmalıdır.

1) Neyin yedeğinin alındığını gözlemlemek.
2) Hangi veri dosyalarının yedeğinin alınması gerekmekte veya güncel olarak hangi veri dosyasının yedeği alınmamış.
3) Bir problem meydana geldiğinde RMAN hangi yedeği kullanarak geri kurtarma yapabilecek.
4) RMAN görevlerinin geçmiş bilgisinin gözlemlenmesi

Oracle 11.2 Grid mimarisinde RAC düğümlere ilave SCAN listener ekleme

Geçenlerde test ortamda yapılandırdığım Oracle11gR2 grid yapılandırması aşağıdaki loglarda görüldüğü gibi sadece tek bir SCAN listener ile tamamlandı. Oracle 11.2 RAC yapılandırması iki düğümden(rac01 ve rac02) oluşan bir test platformunda yapıldı. Bu yazıda Oracle 11.2 Grid ortamında RAC düğümlere nasıl ilave iki SCAN listener daha eklenecek, onu inceleyeceğiz.

[grid@rac01 grid]$ srvctl config scan
SCAN name: rac-scan, Network: 1/192.168.38.0/255.255.255.0/eth2
SCAN VIP name: scan1, IP: /rac-scan.bugra.com/192.168.67.192

[grid@rac01 grid]$ srvctl config scan_listener
SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521

[grid@rac01 grid]$ ping rac-scan.bugra.com
PING rac-scan.bugra.com(192.168.67.193) 56(84) bytes of data.
From rac01.test.ant(192.168.38.50) icmp_seq=2 Destination Host Unreachable
From rac01.test.ant(192.168.38.50) icmp_seq=3 Destination Host Unreachable
From rac01.test.ant(192.168.38.50) icmp_seq=4 Destination Host Unreachable

— rac-scan.bugra.com ping istatistikleri —

6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5000ms
, pipe 3

Dataguard ortamında RMAN silme(deletion) ilkesinin yapılandırılması

Dataguard ortamında RMAN arşivlog silme(deletion) ilkesini tek bir merkez noktadan kontrol etmek için aşağıdaki adımlar izleyenebilir.

“Archivelog deletion” ilkesinin yapılandırılması

APPLIED ON STANDBY – Zorunlu standby olarak belirlenen standby sunucusu üzerinde uygulanan arşivlenmiş logları silmek üzere flash recovery alanını etkinleştirir.

NONE – Üçüncü derece cihazlara yedeklenen ve yapılandırılmış backup retention ilkesina bağlı olarak geçerliliğini yitirmiş arşivlenmiş logları silmek üzere flash recovery alanını etkinleştirir. Bu varsayılan ayardır.

CLEAR – Silme ilkesini temizler ve konfigürasyonu varsayılan değere döndürür.

Oracle network konfigürasyonun optimizasyonu

Oracle veritabanları büyük ölçekli firmalarda genellikle coğrafik olarak farklı bölgelere dağıtılmıştır, böylece Oracle veritabanları uzmanları için veritabanının network bağlantılarından nasıl etkilendiğinin anlaşılması önemli bir görev olmaktadır. Oracle tarafından sağlanan Transparent Network Substrate(TNS), veritabanları arasında dağıtık bağlantılara izin vermektedir.

 
Dağıtık işlemlerin performansı bu yazıda yer alan bazı değişiklikler ile arttırılabilecektir. Bu değişiklikler sqlnet.ora, tnsnames.ora ve protocol.ora dosyaları içindeki parametreler olacaktır. Bu parametreler, konfigürasyonu ve TCP paketlerinin boyutunu değiştirmek için kullanılır. Bu parametrelerin ayarlanmasının, tüm Oracle işlemlerinin çıktısını geliştirmek için, temel network taşıma katmanı üzerinde çok yoğun bir etkisi vardır.  

Oracle Net, veritabanı uzmanlarına temel network ayarlarını iyileştirebilecek yeterliliğe izin vermez ve network trafiğinin çoğunluğu Oracle yapısı içerisindende iyileştirilmez. Çünkü Oracle Net, OSI modeli içinde network spesifik protocol yığını üstünde bulunur.

Network paketlerinin sıklığı ve büyüklüğü Oracle DBA tarafından kontrol edilir. Oracle, paket sıklığı ve büyüklüğünü değiştirmek için zengin araçlara sahiptir. Network üzerinden paket taşımasının sıklığı ve büyüklüğü, aşağıdaki parameter dosyaları içinde yer alan ayarları kullanılarak etkilenir:

• protocol.ora dosyası - tcp.nodelay parametresi
• sqlnet.ora server dosyası - automatic_ipc parametresi
• tnsnames.ora ve listener.ora dosyaları - SDU ve TDU parametreleri

protocol.ora dosyası içindeki tcp.nodelay parametresi
Oracle Net, varsayılan olarak verinin iletilmesinden önce tampon dolana kadar bekler. Bu yüzden, talepler hedeflerine her zaman anında gönderilmemektedir. Bu olay, çoğu zaman büyük miktarda verilerin bir sondan bir diğerine akıp gittiği zamanda yaygın bir olaydır ve Oracle Net tampon dolana kadar paketleri işlemez. protocol.ora dosyası eklemek ve tampon taşıma gecikmelerini durdurmak için tcp.nodelay değerinin belirtilesi bu sorunun üstesinden gelebilir.

protocol.ora dosyası tüm TCP/IP yapılandırmaları için veri tamponlamasının olmamasını göstermek için belirtilir. Bu parameter, hem istemci hemde sunucu üzerinde kullanılabilir.  protocol.ora içinde bu  parametrenin kullanımı:

         tcp.nodelay = yes

Bu paramerenin tanımlanması TCP tamponlamanın es geçilmesine sebep olur, böylece tüm talepler hemen ve anında gönderilir. Ancak unutmamak gerekirki, network trafiği daha küçük ama sık paket işlemesi sebebiyle artar, bu da networkte ağırlaşmaya sebep olur. tcp.nodelay parametresi, sadece TCP zaman aşımı ile karşılaşıldığı zamanlarda kullanılmalıdır. tcp.nodelay parametresinin ayarlanması, veritabanı sunucuları arasında yüksek hacimde trafik olduğunda performansı aşırı oranda geliştirmeye sebep olabilir.

Sqlnet.ora dosyasındaki “automatic_ipc” parametresi

automatic_ipc parametresi network katmanını atlar, böylece veritabanına local bağlantıları hızlandırır. automatic_ipc değeri ON olarak ayalandığında, Oracle Net local veritabanının aynı alias ile belirtilip belirtilmediğini kontrol eder. Eğer aynı alias ile belirtilmişse, bağlantı direkt olarak local IPC bağlantılarına çevrildiğinden network katmanları atlanır. Bu veritabanı sunucuları için kullanışlıdır, ancak Oracle Net istemcileri için kesinlikle gereksizdir.

“Oradebug hanganalyze” komutunun incelemesi

Oradebug özelliği yeterli döküman kaynağı olmadığından dolayı “gizli” kategoride yer almaktadır. Oysaki Oracle 8.1 sürümünden beri SQL*Plus üzerinden çalıştırılmaktadır. Bu özellik kullanıcı oturumlarını izleyebildiği gibi global olarakta veritabanı izleme işlevlerini sağlamaktadır.

Oradebug komutu çalıştırılmak için SYSDBA hakkına gerek duymaktadır. Bu komut ile yapılacak pek çok faydalı işlemlere gelirsek;

• Başka kullanıcının oturumu için SQL izlemesinin etkinleştirilmesi veya devredışı bırakılması
• Yoğun prosesleri askıya almak
• Paylaşımlı bellek ve semaforlar hakkında bilgileri bulmak
• İzleme dosyasını kapatmak suretiyl yenisinin oluşturulmasını sağlamak
• Dahili yapılar ile oynamak ve yığınlar oluşturmak
• Prosesleri uyandırmak

HANGANALYZE özelliğinin kullanımı

HANGANALYZE özelliği oradebug komutu ile veritabanının askıya alındığı zamanlarda oldukça güçlü ve kullanışlıdır.

HANGANALYZE çıktısı yığın şeklinde değildir. “user dump destination” dizininde bir çıktı oluşturur, kullanıcıların okuyabileceği formattadır. Genel sentaks aşağıdaki gibidir;

Standby veritabanında “ORA-02290: check constraint (RMAN.AL_C_STATUS) violated” hata mesajı

Bu hata mesajı ile birkaç hafta önce uzun bir tatil dönüşü sonunda bir yedekleme sorunu üzerinde çalışırken karşılaştım. Yedek, standby veritabanında alınmakta ve recovery katalog kullanılmaktaydı. Oracle sürümü ise Oracle 10.2.0.4

Stanby veritabanında RMAN operasyonu ile katalog veritabanı bağlantı denemeleri aşağıdaki hata mesajı ile sonlandırılmaktaydı:

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of list command at 06/27/2011 09:01:57

RMAN-03014: implicit resync of recovery catalog failed

RMAN-03009: failure of partial resync command on default channel at 06/27/2011 09:01:57

ORA-02290: check constraint (RMAN.AL_C_STATUS) violated

Görünüşe göre hiçbir yedek yok! Halbuki primary veritabanında aynı işlemi yaptığımda bir hata ile karşılaşmıyorum, ancak primary üzerinde ise yedek almak için yeterli boş alan yok.

Büyük partition tablolarda istatistiklerin toplanması

Genellikle büyük partition tablolarda optimizer istatistiklerinin toplanması ve sürdürülmesi ile ilgili pek çok yeni DBA’nin kafasında soru işaretleri vardır. Bu soruları aslında iki konu etrafında toplayabiliriz:

1. Sorgular, eskimiş veya varolmayan partition seviyesi istatistiklerine erişirken menzil dışı değerler sebebiyle bir alt optimal planı alabilir.
2. Global istatistik toplaması zaman ve sistem kaynakları açısından aşırı derecede pahalıdır.

Bu yazıda bu iki sorunu tanımlayıp Oracle 10g ve Oracle 11g sürümlerinde bu iki sorunun temelini inceleyeceğiz.

Menzil dışı (out of range) değerler
Büyük tablolar sıklıkla, sorgu performansını artırmak ve veri yönetimini kolaylaştırmak için “partition” olarak adlandırılan daha küçük bölümlere ayrıştırılır. Oracle sorgusu, SQL sorgusu için iyi bir çalıştırma planı seçmek için hem bütün tablonun istatistiklerini(global istatistikler), hemde bireysel partitionların istatistiklerini(partition istatistikleri) değerlendirmeye almaktadır. Eğer sorgu sadece tekil bir partitiona erişmek ihtiyacı duyarsa, optimizer sadece bu erişilen partition’un istatistiklerini kullanmaktadır. Eğer sorgu birden fazla partitiona erişirse, global ve partition istatistiklerinin kombinasyonunu kullanılmaktadır. Partition kolonların minimum ve maksimum değerlerini şu şekilde düzeltir; İlk partition kolonun maksimum değeri olarak yüksek sınır bölümlendirmesini kullanır ve “range partitioned” tablolar için ilk bölümlendirilmiş kolonun minimum değeri olarak bir önceki partitionun yüksek sınır bölümlendirme değerini kullanır. İsteğe bağlı olarak, hedefin blok sayısı, satır sayısı gibi diğer bazı istatistikleride devredışı bırakır.

Farzedinki STOK adlı tablonun STOK_GIRIS kolonundan dörtte bir oranında “range partition” şeklinde bölümlendirilmiş bir tablo mevcut. Her günün sonunda veri en son partition içine yüklenmekte, ancak istatistikler sadece partitionun tamamen dolduğu yılın dörtte birlerinde toplanmakta. Global ve partition seviyeli istatistiklerin(sadece tamamen dolu partitionlar için) güncel olduğunu varsayarak, alt-optimal planının “menzil dışı” olmasını önlemek için aşağıdaki adımlar izlenebilir.

LOG_ARCHIVE_MAX_PROCESSES değerinin ayarlanması

Oracle LOG_ARCHIVE_MAX_PROCESSES parametresi Oracle tarafından başlangıçta çağrılan aktif ARCH proseslerinin(ARC0-ARCn) sayısını belirtir. LOG_ARCHIVE_MAX_PROCESSES parametresinin değeri,Oracle 10g itibariyle LOG_ARCHIVE_START başlangıç parametresinin geçersiz olmasına rağmen TRUE olarak ayarlandığında değerlendirmeye alınır. Oracle’da yüksek uygunluğa erişmek, Oracle’ı enterprise veritabanı olarak kullanan herkesin hayalidir ve bu hedefe ulaşmak için öncelikle LOG_ARCHIVE_MAX_PROCESSES parametresinin değerinin yükseltilmesi sıklıkla tavsiye edilmektedir. Bu yazıda, LOG_ARCHIVE_MAX_PROCESSES parametresinin değerinin yükseltilmesinin her zaman veritabanı sisteminde en iyi çözüm olmadığını ve LOG_ARCHIVE_MAX_PROCESSES  değerini ayarlarken neden dikkatli olunmasını inceleyeceğiz.

TEMP tablespace büyüme sorunu

TEMP tablespace büyüme sorunu pek çok DBA tarafından karşılaşılan ve sıkıntı yaratan bir sorundur. Temporary(geçici) tablespace aşırı büyüdüğünde veritabanında geçici tablespace alanı tükenebilmektedir. Bu yazıda, bu gibi durumlarda geçici tablespace alanını arzu edilen boyuta kavuşturulacağı ile ilgili bir takım ipuçları yer alacaktır.

Geçici tablespace hakkında bilgi almak:

Aşağıdaki komutu kullanarak geçici tablespace hakkında bilgi alınabilir.

SELECT TABLESPACE_NAME, FILE_NAME FROM DBA_TEMP_FILES;

TABLESPACE_NAME   FILE_NAME

---------------   -----------
TEMP              /u01/oracle/oradata/arda/TEMP01.DBF

Tempfile dosyasının yeniden boyutlandırılması:

Pek çok durumda ALTER DATABASE TEMPFILE komutu ile geçici tablespace’in alanını artırmak metodu seçilebilmektedir.

Ancak, geçici tablespace dosyalarının(tempfile) yeniden boyutlandırılması sıklıkla ORA-03297 hata mesajının alınması ile sonuçlanmaktadır. Bu gibi durumda TEMP veri dosyasının oto genişleyebilir(auto-extensible) olması gerekmekte ve maxbytes/maxblocks değerinin çok düşük olmadığından emin olunması gerekmektedir. Benzer olarak TEMP tablespace’in büyük yığınlarını tahsis etmekten sorumlu olan SQL sorgularının belirlenmesi ve iyileştirilmeside gerekmektedir.

ALTER DATABASE TEMPFILE ‘/u01/oracle/oradata/arda/TEMP01.DBF' RESIZE RESIZE 250M
*
ERROR AT LINE 1:
ORA-03297: FILE CONTAINS USED DATA BEYOND REQUESTED RESIZE VALUE

Eğer ALTER DATABASE TEMPFILE komutu sonunda ORA-032297 hata mesajı ile karşılaşılırsa aşağıdaki adımları izleyerek temp dosyasının boyutu sorunsuzca arzu edilen boyuta kavuşturulur.

Sıcak blok kavramı üzerine bir inceleme

Ön bellek içinde muhtemel “sıcak bloklar” CACHE BUFFERS CHAINS mandalında yüksek veya hızla artış gösteren bekleme sayılarından belirlenebilmektedir.

Bu mandal, tampon bellek içerisinde önbelleklenmiş data bloklarını araştırırken elde edilir. Tampon bellek, blok zincirlerinin toplamı olarak uygulandığından itibaren, her bir zincirin taranması gerektiğinde alt bir mandal tarafından korunmaktadır. Bu mandal içindeki içerik, tekil bir bloğa çok yüksek sayıda erişimden kaynaklanmaktadır. Bu durum, uygulamanın yeniden gözden geçirilmesini gerektirebilir.

 
Bu mandal üzerindeki beklemeler incelenerek, aşağıdaki sorgularda kullanılarak ilgili segment ve spesifik blok hakkında bilgiler elde edilebilir.

Önce, bu mandal için uyku sayısı incelemesiyle hangi mandal ID(ADDR) lerinin etkilendiği belirlenmelidir. Yüksek uyku sayısı, daha etkili mandal IDsi(ADDR)ni işaret etmektedir:

select CHILD#  "cCHILD", ADDR    "sADDR",     
       GETS    "sGETS" , MISSES  "sMISSES",
       SLEEPS  "sSLEEPS"
from v$latch_children
where name = 'cache buffers chains'
order by 4, 1, 2, 3;

En fazla sürekli uyku sayısına sahip mandal IDsi(ADDR) oluşturmak için yukarıdaki sorgu sıklıkla çalıştırılabilir. En yüksek uyku sayısına sahip ID bulunduğunda, sonrasında bu mandal tarafından korunan tampon bellek içindeki mevcut bloklar hakkında daha fazla detay almak için bu mandal adresi kullanılabilir.

 
En yüksek uyku sayısına sahip ID yi belirledikten sonra aşağıdaki sorgu çalıştırılmalıdır.

     select /*+ RULE */
       e.owner ||'.'|| e.segment_name  segment_name,
       e.extent_id  extent#,
       x.dbablk - e.block_id + 1  block#,
       x.tch,
       l.child#
     from
       sys.v$latch_children  l,
       sys.x$bh  x,
       sys.dba_extents  e
     where
       x.hladdr  = 'ADDR' and
       e.file_id = x.file# and
       x.hladdr = l.addr and
       x.dbablk between e.block_id and e.block_id + e.blocks -1
     order by x.tch desc ;

SEGMENT_NAME  EXTENT#  BLOCK#   TCH    CHILD#
------------  -------- -------- ------ ---------
SCOTT.EMP_PK  5        474      17      7,668
SCOTT.EMP     1        449       2      7,668

TCH kolonuna bağlı olarak bir “sıcak blok” belirlenebilir. TCH kolonun değerinin yüksekliği neticesinde, SQL cümlelerince erişilen en sık blok anlaşılır. “Sıcak blokları” bulmak için aşağıdaki sorgu çalıştırılabilir.

Oracle 11g aktif standby veritabanında otomatik blok bozulması tamiri işlemi

Oracle 11g Active Data Guard özelliğinde gerçek zamanlı sorgu yeteneğinin yanında, Otomatik Blok Medya Düzeltme(Automatic Block Media Repair) özelliği ile daha yüksek erişilebilirlik yeteneği olduğu gözükmektedir. Primary veritabanındaki veri blok bozulmalarını standby siteden bu bozulan blokları elde etmek suretiyle ABMR arkaplan prosesi tarafından tamir edilebilmektedir.

Aynı fonksiyon, aktif standby sitedeki blok bozulmalarını primary siteden aynı şekilde bozulmamış blokların elde edilmesiyle tamir edilmesi yoluylada  kullanılabilmektedir. Aşağıdaki senaryoda bu durumu test edeceğiz.

Bu test senaryosunda kullanılmak üzere bir tablo oluşturup USERS tablespace içine atayacağız.

SQL> create table testtbl
tablespace users
as select * from hr.emp;

Table created.

DBMS_ROWID fonksiyonunu kullanarak bu tablonun kullandığı blokları belirliyoruz.

SQL> select * from
(select distinct dbms_rowid.rowid_block_number(rowid)
from testtbl)
where rownum < 6;

DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------
12
13
14
15
16

Ardından bu bloklardan herhangi birisini bozuyoruz (senaryomda 13 numaralı bloğu bozuyorum, bu testi kesinlikle gerçek üretim veritabanınızda yapmayın!)

Eşzamanlı redo taşıma cevap süresinin izlenmesi

V$REDO_DEST_RESP_HISTOGRAM görünümü her bir redo taşıma hedefi için taşıma esnasındaki cevap süresi bilgilerini kaydeder. Bu cevap süresi verisi, eşzamanlı redo taşıma yöntemiyle gönderilen redo taşıma mesajlarında iyileştirme yapmak amacıyla kullanılmaktadır. Bilhassa birden fazla standby veritabanı olan ve primary veritabanı ile WAN bağlantısı yoluyla veri iletişimi yapan standby sunucularda bu değerin ölçümü proaktif iyileştirme için önem kazanmaktadır.

Her istikametteki veri, her bir cevap süresi bir satırdan olmak üzere dizi dizi satır serilerinden meydana gelir. Kayıt tutmayı kolaylaştırmak için 300 saniyeden düşük cevap süreleri en yakın tam sayıya yuvarlanır. 300 saniyeden büyük cevap süreleri ise 600,1200,2400 veya 9600 saniyeye yuvarlanır.

Sistem aktivite raporu(SAR) ile CPU kullanımını izleme

UNIX ve Linux sunucularda sar komutunu –u parametresi ile kullanarak CPU kullanımını izleyebiliriz. sar komutu ne kadar CPU kaynağının çıkmaza girdiğini veya kullanıldığını ile ilgili hızlı bir snapshot çeker. Sisteminiz yavaşladığı zaman bu komutu çalıştırarak pekçok darboğazın kaynağını gözlemleyebilirsiniz.

sar –u <nümerik_değer1> <nümerik_değer2>

nümerik_değer1: sar okumaları arasındaki saniye değeri

nümerik_değer2: sar komutunun kaç sefer çalıştırılacağını belirten değer

$ sar -u 10 5
Linux 2.4.21-37.0.0.1.4.ELhugemem (ap6188rt)    01/06/2011

10:48:24 PM      CPU    %user     %nice   %system   %iowait   %idle
10:48:34 PM       all       22.07      0.00     14.36         0.03         63.54
10:48:44 PM       all       16.70      0.00     13.93         0.17         69.20
10:48:54 PM       all        8.80       0.00       8.15         0.25         82.80
10:49:04 PM       all        2.52       0.00       3.55         0.00         93.92
10:49:14 PM       all        2.05       0.00       4.00         0.00         93.95
Average:             all       10.43      0.00       8.80         0.09         80.69

Shared server yapısında başlangıç dispatcher sayısını ayarlama

Instance başladığında işleme girecek dispatcher sayısının kontrolü DISPATCHER sıfatı ile kontrol edilir. Başlangıç dispatcher sayısını hesaplamak için alttaki formül kullanılabilir.

 dispatcher sayısı  =  maksimum eşzamanlı oturum sayısı / her bir dispatcher için bağlantı sayısı

• Örneğin, TCP/IP üzerinden 3,000 eşzamanlı bağlantı ve her bir proses için 1,000 bağlantının destekleneceği shared server mimarisinde en az 4 dispatcher ayarlanmalı ve spfile içerisinde alttaki gibi eklenmelidir. Performansa bağlı olarak dispatcher sayısı arttırılabilir.

“CPU Time” Oracle bekleme olayı ve CPU önceliklerinin değiştirilmesi

“CPU Time” olayını, performans olaylarını incelerken genellikle Top5 bekleme olayı listesi içinde gözlemleriz. DBA penceresinden bakınca yaygın düşünce, CPU bekleme olayının bir darboğaz olduğu şeklindedir.  Aslında Oracle dökümanlarında da CPU tüketimi ilgili bir takım bekleme olaylarının darboğaz oluşturduğu şeklinde açıklamalar vardır.

Peki eğer sistem içindeki istatistiklerde CPU Tüketimi(%Util ve Çalışma Kuyruğu) kabul edilebilir seviyeler içindeyse ve yeterli kapasiteye sahiplerse, ancak Oracle hala CPU Time bekleme olayını Top 5 bekleme olayı içerisinde listeliyorsa ne yapılmalıdır?

Bu arada yüksek derecede istemsiz içerik değişmesi(Solaris üzerinde mpstat ile) veya içerik değişmesi(Linux üzerinde vmstat ile) gözlemlenebilir.  Burada açık olarak söylemek gerekirse bazı şeylerin doğru hesaplanmadığı anlaşılmaktadır.

CPU süresi, bir prosesin aşağıdaki iki noktadan birisi anlamına geldiğini gösterir;

• CPU üzerinde bu proses için zamanlanmış bir çalışma kuyruğu beklemesi vardır.
• Veya, proses bir CPU üzerinde halihazırda çalışmaktadır. 

Aslında bir DBA olarak bu durumda bizi ilgilendiren noktalar;

• Çalışma kuyruğu üzerinde bekleme süresini azaltarak, oturumun CPU üzerinde en kısa süre içinde çalışabilmesini sağlamak. Bu prosesin önceliğinin ele alınmasıyla ayarlanabilir.
• CPU üzerinde çalışmaya başlangıcından görev sonlanana kadar bir prosesin kesintiye uğramadan çalışmasının sürdürülmesi. CPU üzerinde proses için uygun zaman miktarı “Time Quanta-Zaman Ayarı” olarak tanımlanmaktadır.

Yukardaki her iki görüşte OS Zamanlayıcısı veya OS Dispatcher tarafından kontrol edilmektedir. Aşağıda bilgisayar terminolojisinde zamanlamanın(scheduling) ne anlama geldiğini açıklayan bir açıklama yer almaktadır.

DBMS_XPLAN paketi kullanarak çalıştırma planlarını farklı fonksiyonlar ile görüntülemek

DBMS_XPLAN paketi EXPLAIN_PLAIN komutu çıktılarını bir çok önceden tanımlanmış formatta görüntülemek için kullanılan oldukça kullanışlı bir PL/SQL paketidir. Ayrıca DBMS_XPLAN paketi kullanılarak bir SQL iyileştirme seti içinde veya AWR snapshotları içinde bulunan SQL komutlarının görüntülenmesinde de kullanılabilir.Bunun ilerisinde,  V$SQL_PLAN ve V$SQL_PLAN_STATISTICS_ALL görünümleri içerisinde saklanan bilgilere dayalı olarak, önbelleklenmiş SQL imleçleri içinde çalıştırma zamanı istatistiklerini ve SQL çalıştırma planını görüntülemeye yaramaktadır. Oracle 11.2 sürümünden itibaren iki farklı SQL planının farklılıları kolayca kıyaslanabilmekte, AWR snapshotu içinde hash id değerlerine göre farklı SQL planlarıda kıyaslayabilmektedir. Sonuçta, bir SQL planından çalıştırma ve açıklama planlarını görüntüleme imkanı veren bir pakettir.

DBMS_XPLAN paketi 10 tablo fonksiyonu sağlamaktadır, son 5 fonksiyon Oracle 11.2 sürümünden itibaren hizmettedir.

• DISPLAY - Bir plan tablosunun içeriğini gösterir ve formatlar.
• DISPLAY_AWR - AWR içerisinde saklanan SQL komutunun çalışma planı içeriklerini listeler ve formatlar.
• DISPLAY_CURSOR - Herhangi yüklenmiş bir imlecin(cursor) çalıştırma planı içeriklerini görüntüler ve formatlar.
• DISPLAY_SQL_PLAN_BASELINE - Eldeki SQL planınca tanımlanan SQL komutu için bir veya daha fazla açıklama planını görüntüler.
• DISPLAY_SQLSET - SQL iyileştirme seti içinde saklanan komutların çalıştırma planı içeriklerini görüntüler ve formatlar.
• DIFF_PLAN_CURSOR - Girilen child imleç numarasından türetilen iki SQL planının farklılıklarını kıyaslar.
• DIFF_PLAN_AWR - Girilen farklı hash id değerlerince tanımlanan iki SQL planının farklılıklarını kıyaslar.
• DIFF_PLAN - İki SQL planının referans planını kıyaslar.
• DIFF_PLAN_SQL_BASELINE - plan_names parametresi vasıtasıyla belirtilen 2 SQL planını kıyaslar.
• DIFF_PLAN_OUTLINE - Girilen özet tarafından oluşturulan iki SQL planını kıyaslar. 

Oracle 11g sürümünde DBMS_STATS.SET_*_PREFS prosedürü

Oracle 11g öncesi sürümlerde DBMS_STATS.SET_APRM prosedürünü kullanarak DBMS_STATS.GATHER_*_STATS prosedürünce kullanılan parametrelerin varsayılan değerini değiştirmek için kullanılmaktaydı. Yapılan herhangi bir değişikliğin kapsama alanı tüm sonraki operasyonlardır. Oracle 11g sürümünde DBMS_STATS.SET_PARM prosedürü artık kullanılmamaktadır ve tablo, şema, veritabanı ve global seviyedeki herhangi bir parametre için öcelik atamaya izin veren bir dizi prosedür ile yer değiştirmiştir. Bu yeni prosedürler DBMS_STATS.SET_*_PREFS olarak adlandırılır ve daha iyi ayrıntılı kontrol sunar.

Ancak, hangi prosedürün ne zaman kullanılması gerektiği ve bu prosedürler üzerinden hangi hiyerarşinin olduğu noktasında bazı karışıklıklar olabilmektedr. Bu yazıda DBMS_STAT.SET_*_PREFS  prosedürü kullanılarak nasıl değişiklikler yapılacağına göz atacağız

Oracle proseslerinin bellek kullanımının izlenmesi

Oracle prosesleri tarafından kullanılan belleği anlamak için öncelikle Linux ps komutu ile işletim sistemi seviyesinde proses bazında bellek kullanım listesini alıp, ardından Oracle içerisinden aynı proseslerin arkaplanda kullanıldığına bakmamız gerekmektedir. Kısaca, smon Oracle arkaplan prosesine ps komutu ile bakalım ve ardından SQL*Plus üzerinden aynı prosesin programlar içerisinde görelim.

# ps -afe | grep ora_smon

oracle    2944     1  0 07:02 ?        00:00:01 ora_smon_aysun

root      3181  3148  1 07:28 Pts/2    00:00:02 grep ora_smon    

SQL> SELECT spid,program,background

       FROM v$process

      WHERE spid = 2944;

SPID  PROGRAM                                  BACKGROUND

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

2944  oracle@linux2.localdomain(SMON)          1

Bu iki sorgu sonucunda anahtar nokta, UNIX proses ID ve Oracle SPID değerlerinin aynı olmasıdır. Bu benzersiz değer kullanılarak, Oracle üzerinden Linux/UNIX’e veya Linux/UNIX üzerinden Oracle’a doğru prosesler araştırılabilir. Bir Oracle instance başladığında veya bir uygulama Oracle veritabanını kullandığında, ilişkili Oracle prosesleri tahsis edilmekte ve bellek tüketmektedir. Bu bellek kullanımına farklı yollardan bakılabilmektedir.

V$PROCESS görünümünde toplam bellek kullanımını raporlayan ilave bazı kolonlar bulunmaktadır. V$PROCESS görünümü, proses için kontrol bilgisi ve veriyi içeren özel bellek bölgesi olan “PGA belleği” üzerinde raporlama yapan kolon setlerine sahiptir. Aşağıdaki sorguyu kullanarak, üstteki SQL örneği sonucu bulunan smon arkaplan prosesine bakabilir ve ne kadar PGA bellek tahsis edildiğini görebilmekteyiz. Sonuçların daha anlaşılır olması için sonuçları byte değerinden MB değerine dönüştürüyorum.