Pages

20 Nisan 2011 Çarşamba

Oracle muteksler

Mutex(mutual exclusion-karşılıklı dışlama), kısa formu karşılıklı dışlamaktır. Mandallarla benzerlik gösteren mutex, SGA alanındaki paylaşımlı veri yapısına kontrollü erişim için kullanılan düşük seviyeli bir serileştirme mekanizmasıdır.  Serileştirme, bir objeyi aşağıdakilerden korumak için gereklidir:

  • Ayrılırken birisi objeye eriştiğinde
  • Obje okunurken başkası tarafından düzenlendiğinde
  • Obje düzenlenirken başkası tarafından okunduğunda 
Muteks tarafından korunan her yapının kendine ait bir muteksi vardır(mesela, ebeveyn(parent) imlecin kendine ait bir muteksi vardır ve her bir yavru(child) imlecinde kendine ait muteksi vardır. Her bir yapı, her bir muteksin bu yapının değişik bir parçasını korumasıyla birden çok muteks tarafından korunabilmektedir. Şimdi bu paragrafı teker teker açalım.

Bir muteks, birden fazla yapıyı koruyabilir. Hem muteksler hemde mandallar serileştirme mekanizmaları olmasına rağmen, muteksler mandalların yapamadığı belirli özelliklere sahiptir.

  • Daha küçük ve daha hızlı
Muteksler, mandallara iyi bir alternatiftir, çünkü daha küçük ve daha hızlı olmasından dolayı daha kolay alınırlar. Muteks alımı, mandal alımı ile kıyaslandığında daha az talimat kullanmaktadır.

  • Daha düşük yanlış çekişme oranı
Mandal, genellikle birçok objeyi korumaktadır. Mandal, bir veya birden fazla “sıcak” objeyi korurken, mandalın kendisi, bu mandal tarafından korunan bir objeye erişirken serileştirme noktası meydana gelir. Bu olay, çekişmenin erişilmeye çalışılan hedef obje için olmasından ziyade, koruma mekanizması için(bu da mandaldır) olmasından dolayı "yanlış çekişme noktası" olarak adlandırılır. Mandalların aksine, muteksler ile her bir korunan yapı için muteks oluşturmak mümkündür.  Bu da demek olurki, her bir yapı kendine ait muteks tarafından korunabildiğinden, daha az yanlış çekişme meydana gelebilmektedir.

  • Mandallar ve pinlerin yerine
Bir muteks, pekçok oturum tarafından, tüm oturumların S(Shared) modda muteksi temin etmesi ile eşzamanlı olarak başvurulanabilir. S modda mutekse başvuran toplam oturum sayısı başvuru miktarı ("ref count") olarak adlandırılır. Bir muteks için “ref count” sayısı muteksin kendisi içinde saklıdır. Ayrıca bir muteks, tek bir oturum tarafından X(Exclusive) modda da tutulabilir.

Mutekslerin ikili bir yapısı vardır. mandallar gibi serileştirme mekanizması olarak işlev yapabildiği gibi, bir objenin library cache içinde bütünlüğünü yitirmesini(aged out) engelleme gibi pin işlevide yapabilir. Örneğin; bir muteksin “ref count” miktarı, library cache pin olayı yerine geçmektedir. Her bir oturum bir imleci çalıştırırken, “library cache pin”i oluşturmak ve silmek yerine, “ref count” miktarını arttırır ve azaltır. Böylece “ref count” deyimi “n distinct pin” ile yer değiştirmiş olur.

19 Nisan 2011 Salı

"MEMORY_TARGET not supported on this system - ORA-00845" hata mesajı

Oracle 11g versiyonundan itibaren otomatik bellek yönetimi özelliği MEMORY_TARGET ve MEMORY_MAX_TARGET parametrelerince tanımlanmaktadır. Otomatik bellek yönetimi(AMM) hem SGA hemde PGA’yı yönetir. MEMORY_TARGET için bir değer girilir ve bellek tahsisi için maksimum olarak MEMORY_MAX_MEMORY parametresi sınırına kadar genişleyebilir.  MEMORY_TARGET değeri ayarlandığı zaman Oracle, SGA_TARGET ve PGA_AGGREGATE_TARGET içinde optimal işyüküne uygun değerler tanımlar. Oracle, SGA_TARGET ve PGA_AGGREGATE_TARGET değerini otomatik olarak kontrol ettiğinden, manuel olarak bu değerlerinin üstünde bir değer atanmasına gerek yoktur.

Linux tabanlı sistemlerde paylaşımlı bellek dosya sistemi /dev/shm üzerinde mount edilmelidir. MEMORY_MAX_TARGET değeri /dev/shm üzerinde mount edilen paylaşımlı bellekten daha az olmalıdır. Bu sebeple paylaşımlı bellek dosya sisteminin AMM’nin çalışması için yeterli büyüklükte olduğundan emin olunması gerekir.
Linux tabanlı sistemlerde paylaşımlı bellek dosya sistemini mount etmek için önce root hesabıyla oturum açılır.

Aşağıdaki örnekte, Linux sistemde 4,5GB bir paylaşımlı bellek dosya sistemi mount edilmektedir.

# umount tmpfs
# mount -t tmpfs shmfs -o size=4500m /dev/shm

Bu paylaşımlı bellek dosya sisteminin her açılışta kalıcı olarak aktif olması için /etc/fstab dosyasına aşağıdaki giriş eklenir.

shmfs /dev/shm tmpfs size=4500m 0 

ORA-00845 hatası genellikle MEMORY_MAX_TARGET değerinin, /dev/shm için tahsis edilen bellek toplamına eşit veya daha fazla olması durumunda meydana gelmektedir. Böyle durumda /dev/shm nin mount edildiğinden ve AMM nin çalışması için yeterli belleği bulundurduğundan emin olmak gerekmektedir. Ayrıca, MEMORY_MAX_TARGET ve MEMORY_TARGET parametrelerinde tanımlanan değerlerin /dev/shm üzerinde mount edilen miktardan az olduğundan emin olunması gerekir.

18 Nisan 2011 Pazartesi

V$ACCESS görünümü kullanarak kilit tutan objelerin tespiti üzerine bir inceleme

Geçtiğimiz günlerde OTN’de bir soru ve cevabı dikkatimi çekti. Soru;”V$ACCESS görünümü kullanarak kilitli objelerin tespit edilmesi” ile ilgiliydi ve cevap veren gurulardan birisinin cevabı V$ACCESS görünümü ile kilitli objelerin görülemeyeceği şeklindeydi. V$ACCESS görünümünü daha önceden bende kilit tutan objelerin tespitinde kullanılır diye bildiğimden, bu cevap hakkında kafamda kuşkular oluştu. Aslında V$LOCKED_OBJECTS gibi bir görünüm daha fazla kilit hakkında bilgi tuttuğu için benimde tercihim olmasına rağmen, bu cevap ile ilgili bugün test ortamında bir deneme yaptım ve sonucunu bu yazı ile paylaşıyorum.

Oracle dökümanlarında V$ACCESS hakkında bulduğum bir paragraf;

"V$ACCESS görünümü, library cache üzerinde mevcut durumda uygulamaya girmiş kilitler hakkında bilgi vermektedir."

V$ACCESS görünümü oturumlar tarafından belirli instance için library cache seviyesinde hangi objelerin erişim erişim yaptığı ve kilit tuttuğu ile ilgili bilgi vermektedir. Bu görünüm kilit tutulup tutulmadığı ile ilgili bilgi içermez. Aşağıdaki örnekte test1 ve scott adlı 2 farklı oturumdan işlemler yapacağım ve V$ACCESS görünümü bilgilerini alacağım.

15 Nisan 2011 Cuma

Oracle veritabanında yanıt süresini iyileştirme modeli - LOGOFF tetikleyicileri

Kullanıcılarınıza performansın ne anlama geldiğini sorduğunuzda muhtemelen hemen hemen hepsinin cevabı yaptıkları işlemlerin yanıt zamanı veya tamamlanma zamanı esnasında geçen süre olacaktır. Kullanıcılar bizleri performans problemleri için aradığında, işlemin yanıt süresi veya veri işlem ile ilgili yaşadıkları darboğazdan şikayet ederler. Bir kısım veritabanı hit ratio durumlarının kötü olduğu, aşırı önbellek tampon işlemleri olduğu, çok fazla fiziksel okuma meydana geldiği veya SQL komutlarının çok fazla CPU kullandığı gibi teknik sorunlardan şikayet etmezler elbette.

OWI(Oracle Bekleme Arayüzü), veritabanı yanıt sürelerini belirlemek için çok önemli bir rol oynamaktadır. OWI, bir oturumun açık olduğu süre boyunca karşılaştığı darboğazları belirlemek için yüzyüze kalınan bekleme olaylarını ve bu esnada geçen zamanı izler. Veritabanı yanıt süresi “hizmet süresi” ve “bekleme süresi” parametrelerini içermektedir.

Yanıt süresi = Hizmet Süresi + Bekleme Süresi

Yanıt süresi, bir prosesin CPU üzerinde harcadığı zamanın toplamıdır. Bekleme süresi ise, bir prosesin işleme devam etmeden önce çeşitli kaynakların uygun olması esnasında beklediği toplam süredir.  Bu formül, herhangi bir zamanda, bir prosesin ya CPU üzerinde bir isteği hizmete aktif olarak sunması yada CPU dışında hizmete sunması ve bekleme durumunda olması şeklinde bir kanıya dayanmaktadır. Bu durumda veritabanı yanıt süresini, hizmet süresini veya bekleme süresini veya her ikisini kısaltarak iyileştirebiliriz.

14 Nisan 2011 Perşembe

Oracle veritabanında kuyruğa ekleme(enqueue) olayları - Bölüm 2

Çeşitli tipte kuyruğa ekleme tipleri olmasından dolayı, bir kuyruğa ekleme bekleme olayı farklı sebeplerden meydana gelebilir. Yaygın sebepler ve bunlara karşı alınacak olan önlemler, farklı oturumlar tarafından çekişme yaşanan kuyruk ekleme tipine ve moduna göre değişmektedir. Oracle, her bir kuyruk ekleme tipi için X$KSQST yapısı içinde istek sayısı ve beklemelerin instance seviyesinde istatistiğini tutar.

select *
from   v$enqueue_stat
where  cum_wait_time > 0
order by inst_id, cum_wait_time;

   INST_ID EQ TOTAL_REQ# TOTAL_WAIT#  SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
---------- -- ---------- ----------- ---------- ----------- -------------
         1 SQ      66551         437      66551           0           498
         1 CU      64353         133      64353           0          1616
         1 HW     453067       18683     453067           0         11811
         1 CF     119748          76     119605         143         37842
         1 TX   22687836        9480   22687758          71        672435
         1 TC       3620         724       3620           0        679237
         1 TM   89822967          91   89817200           5       4056333

Yukardaki alınan sonuç ile kullanıcıların hangi tip ve modda kuyruğa ekleme beklemeleri ile yüzyüze kaldığını tespit edebilirsiniz. Can acıtan nokta, kullanıcılar bu beklemeler sebebiyle herhangi bir hata mesajı almazlar ve oturumları donar. Zaten, arandığınızda söylenende oturumların ansızın donduğu ve cevap vermediği şeklindedir.

Tüm kuyruğa eklemeler hakkında detaya girmeyeceğim, çünkü bir kısmının gereksiz olduğunu düşünüyorum. Ancak, en sık ve yaygın karşılaşılan kuyruğa ekleme beklemelerine detaylı olarak aşağıda odaklanacağım.

Mod 6 TX kuyruğa ekleme bekleme olayı
Mod 6 TX kuyruğa ekleme beklemesi(P1= 1415053318, P1RAW= 54580006) en yaygın karşılaşılan kuyruğa ekleme bekleme olayıdır(Oracle Database 10g itibariyle enq: TX—row lock contention.) Bu bekleme olayı satır seviyesinde çakışma olduğuna işaret eder. Bu beklemeye olayı, satırlar bir işlem için kilitlendiği zaman, bu esnada başka bir işlemin aynı satırlara güncelleme veya silme işlemi yapmaya çalışmasında meydana gelir. Bu genellikle program tabanlı bir hatadır. Bu durumda bekleyen oturum, bloklayan oturumun işlemi için işleme(commit) veya geri alma(rollback) yapana kadar bekleyecektir. Kilidi, bloklayan oturumun sonlandırılması dışında, serbest bırakacak başka bir yol yoktur. Tabii, eğer bu bloklayan oturum sonlandırılırsa(kill) yaptığı işlem geri alınacak ve bu işleme bağlı girişlerde ortadan kalkacaktır. Bu genelde istenmez. Aşağıdaki liste mod 6 TX kuyruğa ekleme beklemesi için bir örnektir.

ADDR     KADDR    SID TY    ID1    ID2 LMODE REQUEST CTIME BLOCK
-------- -------- --- -- ------ ------ ----- ------- ----- -----
A3950688 A395069C  10 TM 188154      0     3       0     3     0
A304E2A0 A304E2B0  10 TX  65585 147836     0       6     3     0
01AD23D4 01AD24A4  20 TX  65585 147836     6       0    10     1
A3950A28 A3950A3C  20 TM 188154      0     3       0    10     0

13 Nisan 2011 Çarşamba

Oracle veritabanında kuyruğa ekleme(enqueue) olayları - Bölüm 1

Oracle 9i itibariyle “kuyruğa ekleme (enqueue)”  bekleme olayı parametrelerinin isimleri mod, ID1 ve ID2 dir. Oracle 10g itibariyle ise ilk parametre aynı kalmasına rağmen ikinci ve üçüncü parametreler temsil ettikleri kuyruğa ekleme işlemi için özel bilgileri vermektedir. Kuyruğa ekleme, bekleme olayına bağlı olarak yönetim, uygulama, konfigürasyon,uyumluluk ve diğer bekleme sınıfları altında toplanır. Kuyruğa ekleme bekleme olaylarının üstesiden gelirken aşağıdaki önemli noktaları göz önünde bulundurmanız gerekmektedir.

  • Kuyruğa eklemeler, veritabanı nesnelerine uygulanan kilitlerdir.
  • Kuyruğa eklemeler hareketlidir, uygulama tarafından başlatılır.
  • Oracle oturumu belirli bir kuyruğa ekleme işlemi elde etmek için bekler. Kuyruğa ekleme ismi ve modu, P1 parametresi içinde kayıtlıdır. İlgili işlem için harekete geçme, rekabet olan kuyruk bekleme tipine bağlıdır.
  • Oracle 10g itibariyle tüm kuyruğa eklemeler bağımsız bekleme olayı olarak listelenmektedir. 
Kuyruğa ekleme nedir?
Kuyruğa ekleme, kullanıldığı ortama bağlı olarak değişik anlamlar taşır. Fiil olarak kullanıldığında, bir  kuyruğa kilit yerleştirme hareketi olarak ifade edilir. Sıfat olarak kullanıldığında ise TX kuyruğa eklemesi gibi özel bir kilit olayını ifade eder.

Kuyruğa eklemeler, şema nesneleri, arkaplan görevleri ve redo mesaj dizileri(threads) gibi pekçok paylaşımlı kaynağa erişimi yöneten sofistike kilitleme mekanizmasıdır. Oracle, kuyruğa eklemeyi iki amaç için kullanmaktadır. Birincisi, kilit modları uyumlu olmadığında bir çok eşzamanlı oturumun aynı kaynağı paylaşmasını önlemek için kuyruğa eklemeler devreye girer. İkincisi, oturumların kilit modları uyumlu olduğunda aynı kaynağı paylaşmasına izin vermek için kullanılır. Bir oturum, bir nesnenin tümü veya bir kısmı için kilit talep ettiğinde ve talep edilen kilit modu başka bir oturum tarafından tutulan mod ile uyumlu olmadığında, talep eden oturum bu kilit isteğini kuyruğa sokar(yani kuyruğa ekleme) ve işlem sırasına göre hizmete girmesini bekler.  Bu olay, “kuyruğa ekleme beklemesi” olarak adlandırılır.  Kuyruğa ekleme beklemeleri  tampon(buffer) beklemeleri dışındaki çeşitlli lokal kilitler için olan beklemelerdir. 

Kuyruğa ekleme kaynağı nedir?
Kuyruğa ekleme kaynağı, kuyruğa ekleme kilidince etkilenen veritabanı kaynağıdır. Oracle, kuyruğa ekleme kaynaklarını X$KSQRS(kernel servisi kuyruğa ekleme kaynağı) veya V$RESOURCE görünümleri üzerinden görülebilen dahili dizin yapısını kullanarak yönetir.

select * from v$resource;

ADDR                TY     ID1       ID2
----------------    ---    -------   -------
C000000047BE4D40    TX     4980825   115058
C00000003FEB4A58    TM     6112      0
C00000004262E758    WL     1         25603
C00000004AD99538    TX     327726    202076
C00000004A5C6CE8    TM     507       0
C00000003FB7C4F8    TX     5898241   23053
C00000004BB3A968    DX     28        0

. . .

12 Nisan 2011 Salı

Oracle Latches

Latches  nedir??
Mandallar(latches), Oracle paylaşımlı bellek alanlarını(SGA) koruyan serileştirme mekanizmalarıdır. Basit anlamda mandallar iki prosesin aynı SGA alanını eşzamanlı güncellemelerinden ve muhtemelen bu olaya bağlı bozulmalardan korur. Mandallar, birden fazla kullanıcı prosesinin belirli bir zamanda aynı kod parçasını çalıştırmasını önlemek için kullanılmaktadır.

Oracle oturumları neredeyse tüm veritabanı işlemleri için SGA’dan okumak veya SGA’yı güncellemek ihtiyacı duyar.  Örneğin;

  • Bir oturum diskten bloğu okurken, bu oturum önbellek tamponunda serbest bloğu değiştirir ve önbellek tampon LRU(en son kullanılan) zincirini düzeltir.
  • Bir oturum SGA’dan bir blok okuduğunda, LRU zinciride değiştirilir. Yeni bir SQL komutu ayrıştırıldığında(parsed) SGA deki library cache’e eklenir.
  • Bloklarda değişiklikler yapıldığı gibi, girişlerde redo tamponuna yerleştirilir. Veritabanı yazıcısı periyodik olarak kirli tamponları önbellekten diske yazar ve statülerini “kirli” den “temiz” e değiştirmek zorundadır.
  • Redo log yazıcısı, girişleri redo tampondan redo log dosyalarına yazar.
Mandallara karşılık kuyruğa alma(enqueues)
Kuyruğa almalarda(enqueues), Oracle içindeki diğer bir kilitleme mekanizmasıdır. Kuyruğa alma  daha gelişmiş bir mekanizmadır ve birçok eşzamanlı prosesi, bilinen kaynakların değişik derecelerde paylaşımına olanak verir.
Eşzamanlı kullanılabilen herhangi bir nesne kuyruğa almalarla korunabilir. Tablolarda değişik seviyelerde paylaşımlara izin verilir, örneğin iki proses paylaşımlı modda veya paylaşımlı güncelleme modunda bir tabloyu kilitleyebilir.Kuyruğa almanın bir farklılığı, işletim sistemi kilitleme mekanizması kullanılarak elde edilmesidir. Kuyruğa alma ile bir değerin kilit içinde saklamansına izin verilir. İşletim sistemi kilit yöneticisi, kilitlenmiş kaynakların izini tutar. Eğer bir proses, talep edilen modun uyumsuzluğu sebebiyle ve bir bekleme için kilit talep edildiğinde bu kilidi kabul edemezse, işletim sistemi bekleyen prosesi FIFO içinde servis edilen bekleme kuyruğuna koyar. Mandallar ve kuyruğa almaların arasındaki diğer bir fark ise, mandallarda kuyruğa almalardaki gibi sıralanmış kuyruk bekleyicileri yoktur. Mandal bekleyicileri uyanmak ve yeniden denemek için ya zamanlayıcıları yada  sadece çoklu işlemcilerde kullanılmak üzere devirleri kullanır.  Tüm bekleyicilerin zamanlayıcıya bağlı eşzamanlı yeniden denemesinden itibaren herhangi biri mandalı alabilir ve makul olarak en son alan olur.

8 Nisan 2011 Cuma

"SQL*Net more data to client" paket cevap süresi optimizasyonu hakkında bir çalışma

Bu yazıda bu hafta başında başıma gelen, network paketlerinin gecikmesi neticesinde Oracle kullanıcıların işlemlerinde yaşağıdığı ani yavaşlamayı, sebebi ve sonuç analiz metodu ile birlikte açıklayacağım. Aslında olayın hikayesi, bazı kullanıcıların bu Salı günü aniden kullandıkları programın cevap süresinin ani olarak yavaşladığından şikayet etmesiyle başladı. Kullanılan program istemci/veritabanı yapısında bir programdır ve bu programı AR-GE bölümünde sınırlı sayıda kullanıcı kullanmaktadır. Kullanılan Oracle 10g veritabanı ise dedicated yapıda ayrı bir Linux sunucu üzerinde hizmet vermektedir.

İlk iş olarak toolkit’lerimi kullanarak paylaşımlı havuzdan aşırı önbellek kullanan işlem olup olmadığını tespit ettim, ancak gerek proses başına, gerekse SQL ve PL/SQL işlemi başına önbellek kullanımında bir anormallik yoktu. Ayrıca, SGA alanında ve belli başlı hit oranlarındada geçtiğimiz haftaya göre bir farklılık yoktu. Bunun ardından AWR raporunu hem geçen hafta Pazartesi-Salı günlerini kapsayacak şekilde, hemde bu hafta Pazartesi-Salı günlerini kapsayacak şekilde 2 sefer çalıştırdım.

Geçen hafta Pazartesi-Salı günlerini kapsayan AWR raporu;

Top User Events
Event
Event Class
% Activity
Avg Active Sessions
CPU + Wait for CPU
CPU
18.16
0.19
db file sequential read
User I/O
14.10
0.12
db file scattered read
User I/O
11.30
0.08
log file sync
Commit
4.03
0.03
enq: TX - row lock contention
Application
1.96
0.06

Top Background Events
Event
Event Class
% Activity
Avg Active Sessions
db file parallel write
System I/O
2.92
0.03
CPU + Wait for CPU
CPU
8.65
0.03
log file parallel write
System I/O
3.51
0.02
reliable message
Other
1.75
0.01


Bu hafta Pazartesi-Salı günlerini kapsayan AWR raporu:

Top User Events
Event
Event Class
% Activity
Avg Active Sessions
CPU + Wait for CPU
CPU
14.16
0.18
db file sequential read
User I/O
12.10
0.12
db file scattered read
User I/O
8.30
0.07
log file sync
Commit
3.17
0.02
enq: TX - row lock contention
Application
1.64
0.02

Top Background Events
Event
Event Class
% Activity
Avg Active Sessions
db file parallel write
System I/O
2.62
0.04
CPU + Wait for CPU
CPU
9.54
0.04
log file parallel write
System I/O
2.43
0.05
reliable message
Other
1.98
0.02


Yukardada görüldüğü üzere bu haftaki bekleme olayları, geçen hafta aynı periyoda nazaran yaklaşık %10 daha iyi. Peki o zaman sorun nerede???

7 Nisan 2011 Perşembe

Oracle veritabanında sürdürülebilir alan tahsisi (resumable space allocation)

Oracle veritabanındaki görevlerin(job) hata vermesine sebep olan disk alanı problemleri üç kategoriye ayrılmaktadır.

1. Segmentleri genişletememe durumunda
Eğer bir görev, içinde tanımlanan işlem neticesinde ilgili segment için yeni extent oluşturamaz veya tahsis edemezse bu görev askıya alınır ve Oracle buna bağlı hata raporlar. Oracle hata mesajı segment adını ve tablespace ismini göstermektedir. ORA-1650’dan ORA-1655’e kadar olan hatalar bu kategori içinde yer almaktadır.

2. Maksimum sayıdaki extent sayısı aşıldığı durumda
Eğer bir görev içinde tanımlanan işlem neticesinde ilgili segmentin extent sayısı  maxextents parametresindeki maksimum değeri aşarsa, görev askıya alınır. Oracle mesajı segment ismi boyunca maksimum sayıdaki extentleri göstermektedir. ORA-1629’dan ORA-1632’e kadarki Oracle hataları bu kategori içindedir.

3. Kota alanı aşıldığı durumda
Kullanıcı, görevin ilgili olduğu tablespace için kendisine atanan alan kotasını aştığında görev askıya alınır ve aşağıdaki hata raporlanır.

     ORA-01536-“space quota exceeded for tablespace ’xxx’’’

Aşağıda sürdürülebilir alan tahsisi olmadığında meydana gelen hata mesajları yer almaktadır.

 ORA-1653 unable to extend table ... in tablespace ...
 ORA-1654 unable to extend index ... in tablespace ...
 ORA-1650 unable to extend rollback segment ... in tablespace ...
 ORA-1628 max # extents ... reached for rollback segment ...
 ORA-1654 max # extents ... reached in index ...
 ORA-1631 max # extents ... reached in table ... 

Paralel Çalışma ve Sürdürülebilir Alan Tahsisi
Paralel çalışma durumlarında, eğer bu paralel çalışma sunucu proseslerinden birisi bir hata ile karşılaşırsa, bu sunucu prosesi çalışmasını askıya alacaktır. Diğer paralel çalışma sunucu prosesi ise bir hata ile karşılaşana kadar veya askıdaki sunucu prosesi tarafından direkt veya indirekt olarak bloklanana kadar, kendi görevini çalıştırmaya devam edecektir. Bu düzeltilebilir hata çözümlendiğinde, askıdaki proses çalışmasına kaldığı yerden devam edecek ve paralel operasyon çalışmaya devam edecektir.Eğer askıdaki proses sonlandırılırsa, paralel operasyon kesintiye uğrayacak ve kullanıcıya hata döndürecektir.

Farklı paralel çalışma sunucu prosesleri bir veya birden fazla düzeltilebilir hata ile karşı karşıya kalabilir. Bu durum AFTER SUSPEND tetikleyicinin birçok kez paralel olarak ateşlenmesinden kaynaklanabilir.

5 Nisan 2011 Salı

Bir DBA’in penceresinden UNIX/LINUX sistem performansını izleme araçları



IBM AIX için;

  • IBM AIX sistemlerde en son kullanılan ve yoğun CPU çalıştıran kullanıcı proseslerini bulma 
#  ps -ef | egrep -v "STIME|$LOGNAME" | sort +3 -r | head -n 15

  • Thread ve proseslerin sınırlandığı thread ve CPU ları listeleme. TID kolonu threadID’yi belirtir.Thread kavramını kısaca açıklamak gerekirse; thread, bir program aracılığıyla kontrol sıralı akış demektir. Thread’ler pek çok açıdan faydalıdır. Birden fazla CPU üzerinde paralel olarak çalışabilmekte ve böylece tek bir programın çalışmasını, birden fazla CPU arasında bölümlendirebilmektedir. Bunun yanında veritabanı performansında önemli olan, örtüşen eşzamanlı olmayan I/O işlemleri (ASYNC I/O) ve grafiksel kullanıcı arayüzleri gibi bazı sunucu programlarında da, pekçok thread işbirliği yaparak bu tarz programların daha efektif çalışmasını tetikler.
#  ps -efmo THREAD

  • Oldukça yüksek CPU kullanan prosesleri listeleme
#  ps -eo pid,pcpu,args | sort +1n

  • CPU kullanmakta olan bilinen bir prosesin thread ID sini(TID) bulma
#  ps -mp <PROSES_PID_NO> -o THREAD

  • Yüksek fiziksel bellek tüketen prosesleri listeleme
#  ps -eo pid,vsz,args | sort +1n

  • Top prosesler, CPU kullanımı, fiziksel bellek tüketimi, sanal bellek kullanımı, paging alanı ve I/O yüklemesi gibi sunucu kaynak kullanımı gözlemleme
#  topas

  • IBM AIX sistemlerde paging alanını en fazla kullanan 10 kullanıcıyı listeleme
#  svmon -Pgt 10

  • IBM AIX sistemlerde en fazla fiziksel bellek kullanan 10 kullanıcıyı listeleme
#  svmon -Put 10

  • IBM AIX sistemlerde fiziksel bellek kullanımını izleme
#  svmon -u | more
#  svmon -P | more

  • IBM AIX sistemlerde en fazla bellek tüketen prosesleri bulma
#  svmon -P -t 1
#  svmon -Pau 1

2 Nisan 2011 Cumartesi

Oracle 11g Recycle Bin (Geri Dönüşüm Kutusu)

Recycle bin(Geri Dönüşüm Kutusu) düşürülmüş objelerin bilgilerini tutan bir çeşit veri dizin tablosudur. Silinmiş tablolar ve bu tablolara bağlı olan indeskler, kısıtlayıcılar, nested tablolar ve diğerleri gibi objeler silinmez ve hala alan kaplar. Geri dönüşüm kutusundan silinmeden veya tablespace alan kısıtlamaları gibi sebeplele veritabanından kalıcı olarak silinmeden, bu objeler hala kullanıcı alan kotası dahilinde yer kaplar.

Her kullanıcı kendine ait geri dönüşüm kutusu olduğunu düşünür, çünkü bir kullanıcı SYSDBA haklarına sahip olmadan Geri dönüşüm kutusu içerisinde erişebildiği ve gördüğü objeler kendi sahip olduklarıdır. Aşağıdaki komut ile her kullanıcı geri dönüşüm kutusu içindeki silinen objelerini görebilir.

SELECT * FROM RECYCLEBIN;

Bir tablespace içerikleri ile beraber düşürüldüğünde bu tablespace’e ait objeler geri dönüşüm kutusu içerisinde yer almaz. Veritabanı aynı zamanda geri dönüşüm kutusu içinde bu düşürülen tablespace’e ait olan nesneleride kalıcı olarak siler.

  • Bir kullanıcıyı düşürdüğünüzde bu kullanıcıya ait objeler geri dönüşüm kutusu içerisine yerleştirilmez ve geri dönüşüm kutusunda bu kullanıcıya ait olan objeler varsa bunlarda kalıcı olarak otomatikman silinir.
  • Bir küme(cluster) düşürüldüğünde bu kümenin üye tabloları geri dönüşüm kutusu içerisine yerleştirilmez ve geri dönüşüm kutusu içinde varsa üye tablolar bunlarda otomatikman kalıcı silinir.
  • Bir tip(type) düşürüldüğünde ise bu tipe bağlı alt nesneler geri dönüşüm kutusuna yerleştirilmez ve herhangi bir alt nesne varsa geri dönüşüm kutusunda, kalıcı olarak otomatikman silinir.