Uptime izleme aracı ile inaktif oturumların izlenmesi

Uptime izleme aracı ile Oracle veritabanında inaktif oturumlar hakkında uyarıları emaille almak oldukça kolaydır. Bu işlem için uptime izleme aracı içinden “Add service monitor” ile Oracle (basic checks) servisini seçmek yeterlidir. Ardından script altından inaktif oturumlar mevcutsa TRUE değerini döndürecek olan SQL komutunu tanımlanabilir. Servis kıyaslama alanında da değer olarak FALSE tanıtılırsa, ters bir durum oluşma durumunda uptime izleme aracı otomatik email ile bu durumu kritik alert seviyesinde ilgili profile bildirecektir.

 Alttaki örnekte 2 saatten fazla zamandır veritabanına bağlı inaktif oturum olduğunda anında emaille alert olarak döndürecek örnek yer almaktadır.

Uptime ile ilgili geniş bilgiye http://www.uptimesoftware.com/resources.php adresinden erişilebilir.

EXACT_MATCHING_SIGNATURE ve FORCE_MATCHING_SIGNATURE hakkında

Oracle dökümanlarında EXACT_MATCHING_SIGNATURE normalize SQL textinde hesaplanan imzadır şeklinde tanımlanmıştır. Buradaki normalizasyon kavramı beyaz alanların çıkarılması ve gerçek olmayan tüm stringlerin büyük harfe dönüştürülmesidir. CURSOR_SHARING parametresi EXACT olarak ayarlandığında bu imza kullanılırken, FORCE_MATCHING_SIGNATURE kolon değeri ise CURSOR_SHARING parametresi FORCE olarak ayarlandığında Oracle’ın hesapladığı imzadır.  

Şimdi bu kolonların alacağı bazı değerleri ve bunların anlamlarını aşağıda inceleyelim.  

I. SENARYO:

EXACT_MATCHING_SIGNATURE  ve FORCE_MATCHING_SIGNATURE değerleri sıfır olarak ayarlanmıştır. Bu senaryo eğer komut tipi PL/SQL paketi, INSERT,ALTER INDEX,LOCK, SET ROLE ve mevcut SYS tablolarından($,# olanlar, ancak görünümler hariç) SELECT/UPDATE işlemleri  veya dahili Oracle komutları içindir.  Bunun yanında daha fazla komut olabilir, ancak Oracle SQL in yeniden kullanılamayacağını düşünecek ve ardından değerleri 0 olarak işaretleyecektir.

Standalone Oracle 10g veritabanının 10g RAC veritabanına dönüştürülmesi

Standalone Oracle 10g veritabanın Oracle 10g RAC veritabanına dönüştürülmesi işlemi öncesinde tüm düğümlerde clusterware yazılımının kurulmuş olması ve sunucuların RAC yapısında hizmet verecek şekilde fiziksel olarak yapılandırılmış olması gerekmektedir. Bu kurulum öncesi işlemlerin tamamlandığından emin olunduktan sonra daha önceden stand alone olarak hizmet veren bir Oracle 10g veritabanının RAC veritabanına dönüştürme işlemi için aşağıdaki adımların uygulanması yeterli olacaktır.

Birleşmelerde sorgu geliştiricinin uygun yürütme planını seçmesi

Sorgu geliştirici, bir yürütme planının seçilmesi esnasında aşağıdakileri değerlendirmeye almaktadır:

·         Sorgu geliştirici, önce en azından bir veya birden fazla tablo birleşmesinin kesinlikle en az bir satır içeren bir satır kaynağı olarak sonuçlanıp sonuçlanmayacağını belirler. Sorgu geliştirici, bu gibi durumları tablodaki UNIQUE ve PRIMARY KEY kısıtlamalarına bağlı olarak  tanımaktadır. Eğer böyle bir durum mevcutsa, o zaman sorgu geliştirici bu tablolaları ilk olarak birleşme sırasına göre yerleştirir. Ardından, geri kalan tablo kümelerinin birleşmesi işlemine gelinir.

·         Dış(outer) birleşme durumları ile birleşme komutları için, dış birleşme operatörü olan tablo, birleşme sırasında bu durum için diğer tablodan daha sonra gelmelidir. Sorgu geliştirici, bu kuralı ihlal eden birleşme sıralarını değerlendirmeye almaz. Benzer olarak,  bir altsorgu yarı birleşme ve anti birleşmelere dönüştürüldüğünde, bu alt sorgunun tabloları dış sorgu bloğunda bağlı olunan veya ilişkideki tablolardan daha  sonra gelmelidir. Ancak, bazı durumlarda karma(hash) anti birleşmelerin ve yarı birleşmelerin(semijoins) bu sıralama durumunu geçersiz kılması mümkün olmaktadır.

Sorgu geliştirici ile muhtemel birleşme sırasına, birleşme metoduna ve uygun erişim yollarına bağlı olarak  bir yürütme planı kümesi oluşturulur. Ardından, herbir planın maliyeti değerlendirilir ve en düşük maliyete sahip olan seçilir. Sorgu geliştirici, bu maliyetleri aşağıdaki şekillerde değerlendirmeye almaktadır:

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.

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.

“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.

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.

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.

Indekslerin daha büyük bloğa sahip tablespace içerisine taşınması ve performanslarının durumu

Eğer bir indeks daha büyük blok büyüklüğündeki tablespace içinde yeniden inşa edilirse IFFS(Index Fast Full Scan) performansında iyi veya kötü yönde bir değişiklik olurmu?

• Rastgele giriş yapılan indeksler %70-75 aralığında PCT_USED değerine sahipken, bu indeksler, doldurulan farklı evreler içinde eş zamanlı olarak rastgele 50-50 blok bölünmesi meydana getirir. Bir indeksi yeniden insa ederek, %15 kadar indeks yoğunluğu artabilir ve böylece tüm indeks büyüklüğü azalabilir. Azalan blok geneli aynı zamanda indeks büyüklüğü ve blok büyüklüklerinin farklılıklarına bağlı olarak, indeksi de bir miktar azaltabilir. Fast Full Index Scan üyelik maliyetleri indeksin tüm büyüklüğü ile orantılı olduğundan, bir indeksi birleştirmek(defragmantation), en fazla potensiyel faydalar sunan erişim yolu olmaktadır. Bir indeksin büyüklüğünü azaltmak bu yüzden daha sonraki performansı etkiler.  Oysaki, mevcut blok büyüklüğünde indeksin yeniden inşası muhtemelen aynı benzer sonuca ulaşır(artı blok genel giderleri), indeksi sıkılaştırır ve potensiyel olarak daha iyi performans ile sonuçlanır. Buna karşın, indeks bloğu bir kez tekrardan bölünmeye başladımı, neticede bu indeks kendisinin önceki durumuna tekrar geri döner. İşte bu yüzden, daha büyük blok büyüklüğünün ötesinde, indeksin birleştirilmesi (defragmentation) genel bir performans iyileştirme yolu olmaktadır.

• İndeksi daha büyük bloğa sahip tablespace içinde saklayarak, bu indeksin ait olduğu tablodan farklı bir fiziksel veri dosyası içinde saklamak gerekmektedir. Bu veri dosyası performansı arttırmak için nispeten daha hızlı bir disk olmalı ve indeksler dışında başka dosyalar içermemelidir. Daha büyük blok büyüklüğünden ziyade, indeksin depolandığı yeni yerin fiziksel karakteristikleri esasında performansı etkiler. Eğer bir indeks aynı blok büyüklüğünde, daha büyük bloğa sahip indeksler ile aynı fiziksel karakteristiklere sahip yerde yeniden inşa edilirse, daha sonraki performans aynı şekilde artar(veya azalır).

Tabii bunun yanında pekçok muhtemel sebepler vardır, sistem daha büyük blok büyüklüğüne sahip indeksler kullanırken, daha az meşgul olmakla beraber indeksin daha büyük kısmı fiziksel olarak önbelleklenir.

Indeks Fast Full Scan, nadirende olsa bir ölçeklenebilirlik sorunudur. Bu noktada, aslında gerçekten kullandığımız uygulamaların yüzlerce büyüklükte eşzamanlı indeks fast full scan yapmasını istermiyiz? Uygulamayı bu gereksiz indeks fast full scan giderlerinden kurtarmak, indeksleri boş yere daha geniş bloğa sahip tablespace içine taşımaktan daha verimli bir yol olacaktır. Tabii bu başka bir yazıda tartışma konusu olur. 

Peki, esas bu yazının ana konusuna gelelim. Indeks Fast Full Scan işleminin performansı indeksin daha büyük bloğa sahip tablespace içine taşınması neticesinde değişirmi? Kesinlikle, değişir…Ancak, bu bahsedilen değişim, indeksin daha büyük bloğa sahip olması sonucunda çoklu blok(multiblock) okuma performansının geliştirilmiş olması anlamına gelmez.  

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.

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.

Oracle 9i veritabanı verilerinin dışarıya CSV formatında taşınması

Oracle 9i veritabanından dışarıya CSV formatında tabloların verilerini almak için alttaki komutu çalıştırırak bir paket oluşturabilir ve ardından hangi tablolardan verilerin dışarıya CSV formatında alınması isteniyorsa o tabloları ve hedef dosya dizinini gösterek dışarıya CSV formatında alma işlemi başarıyla tamamlanır.

SQL Server üzerine migration gibi durumlarda Oracle 9i verilerinin taşınması istendiğinde oldukça hızlı ve eksiksiz bir çözüm sunmaktadır.

create or replace procedure dump_table_to_csv( p_tname in varchar2,

                                                  p_dir   in varchar2,

                                                  p_filename in varchar2 )

       is

          l_output        utl_file.file_type;

           l_theCursor     integer default dbms_sql.open_cursor;

          l_columnValue   varchar2(4000);

         l_status        integer;

           l_query         varchar2(1000)

                          default 'select * from ' || p_tname;

          l_colCnt        number := 0;

          l_separator     varchar2(1);

          l_descTbl       dbms_sql.desc_tab;

      begin

          l_output := utl_file.fopen( p_dir, p_filename, 'w' );

          execute immediate 'alter session set nls_date_format=''dd-mon-yyyy hh24:mi:ss'' ';

         dbms_sql.parse(  l_theCursor,  l_query, dbms_sql.native );

          dbms_sql.describe_columns( l_theCursor, l_colCnt, l_descTbl );

           for i in 1 .. l_colCnt loop

             utl_file.put( l_output, l_separator || '"' || l_descTbl(i).col_name|| '"' );

             dbms_sql.define_column( l_theCursor, i, l_columnValue, 4000 );

             l_separator := ',';

          end loop;

          utl_file.new_line( l_output );

          l_status := dbms_sql.execute(l_theCursor);

           while ( dbms_sql.fetch_rows(l_theCursor) > 0 ) loop

              l_separator := '';

              for i in 1 .. l_colCnt loop

                  dbms_sql.column_value( l_theCursor, i, l_columnValue );

                  utl_file.put( l_output, l_separator || l_columnValue );

                  l_separator := ',';

              end loop;

              utl_file.new_line( l_output );

         end loop;

         dbms_sql.close_cursor(l_theCursor);

          utl_file.fclose( l_output );

          execute immediate 'alter session set nls_date_format=''dd-MON-yy'' ';

     exception

         when others then

              utl_file.fclose( l_output );

  end;

   /

Ardından /tmp/ dizini altında test1.csv adında bir text dosyası oluturulmakta ve MVXCORSA şeması altındaki MITAU adlı tablonun içindeki veriler dışarıya alınmaktadır.

SQL> exec dump_table_to_csv('MVXCORSA.MITAU','/tmp/', 'test1.csv')

Tablespace salt okuma moda getirilirken o an aktif işlemlerin tespit edilmesi ve sonlandırılması

ALTER TABLESPACE...READ ONLY ile tablespaceleri read only moda girişi ancak  o an devam eden tüm işlemlerin ya commit ile onaylanması yada rollback ile değişikliklerin geri alınması sonucunda gerçekleşir. Bazı durumlarda kullanıcılar, salt okuma(read only) durumunda açılacak olan tablespace içindeki tablolarda işlem yapıyor olabilir. İşte bu durumda bu tablespace'ı salt okuma durumuna getirmek için çalıştırılan komut uzun zaman devam ediyorsa ve muhtemelen askıda kalıyorsa, kimlerin on aktif işlem yaptığını tespit etmeniz ve bu kullanıcıların işlemlerini sonlandırmanız gerekmektedir.  

Bu noktada; öncelikle ALTER TABLESPACE...READ ONLY komutunun oturum adresini tespit etmemiz gerekecektir. Ardından aktif oturum adreslerini ve kimlere ait olduğunu bulacağız. Bunun sonucunda ALTER TABLESPACE...READ ONLY  komutunun işaret ettiği oturum adresinden önceki tüm oturum adreslerinin sonlandırılması gerekecektir. Bu işlemleri gerçekleştiren kullanıcılar bilgilendirilerek işlemlerin sonlandırılması talep edilebilir. Akabinde, ALTER TABLESPACE...READ ONLY  komutu başarıyla çalışacaktır.

Aşağıdaki sorgu ALTER TABLESPACE...READ ONLY cümlesinin oturum adresini verecektir.

SELECT SQL_TEXT, SADDR

FROM V$SQLAREA,V$SESSION

WHERE V$SQLAREA.ADDRESS = V$SESSION.SQL_ADDRESS

AND SQL_TEXT LIKE 'alter tablespace%';

SQL_TEXT                                                     SADDR

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

alter tablespace tbs1 read only                       80034AF0

Tüm aktif işlemlerin SCN başlangıcı V$TRANSACTION görünümüde yer almaktadır. Büyükten küçüğe sıralama ile işlemlerin çalışma sırasına göre SCN başlangıçları listelenir. Küçük SCN başlangıçları ALTER TABLESPACE...READ ONLY komutundan önce çalışmaya başlamış aktif işlemlerin oturum adresini işaret edecektir. ALTER TABLESPACE...READ ONLY komutunun çalıştığı andan itibaren bu komutun başarılı şekilde tamamlanıncaya kadar geçen sürede, kullanıcılar tarafından yapılan tüm işlemler geçersiz olacağından bu SQL cümleleri bloklama yapmaz

SELECT SES_ADDR, START_SCNB

FROM V$TRANSACTION

ORDER BY START_SCNB;

SES_ADDR               START_SCNB

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

800352A0                   3621    --> bu işlem tamamlanmayı bekliyor

80035A50                   3623    --> bu işlem tamamlanmayı bekliyor

80034AF0                   3628    --> ALTER TABLESPACE komutunun oturum adresi

Artık bloklamayı yapan kullanıcıları tespit edebiliriz.

SELECT T.SES_ADDR, S.USERNAME, S.MACHINE

FROM V$SESSION S, V$TRANSACTION T

WHERE T.SES_ADDR = S.SADDR

ORDER BY T.SES_ADDR;

SES_ADDR     USERNAME               MACHINE

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

800352A0       USER1                        TEST1   --> Bu kullanıcı ile irtibata geçin…

80035A50       USER2                        TEST2   --> Bu kullanıcı ile irtibata geçin…

80034AF0       DBA01                        LINUX1

Oracle’da birçok farklı blok yapısı ile çalışma performansı ölçümü

Bu yazıda Oracle’nın 8k ve 16k büyüklüğündeki veri blokları ile ilgili performans testlerini yapacağım. Hem 8k hemde 16k büyüklüğündeki veri blokları üzerinde DML işlemleri yapacağım. Bu amaçla; 8k lık veri bloğuna sahip “tbs_8k” adlı tablespace içinde bir  tablo, 16k lık veri bloğuna sahip “tbs_16k” adlı tablespace içerisinde başka bir tablo oluşturacağım. Sonuçta yapacağım test işleminde, büyük bloğa sahip tablolarda UPDATE işlemlerinin daha uzun sürede tamamlanmasına rağmen, INSERT işlemlerinin ise daha kısa zamanda tamamlandığını gözlemleyeceğiz.

A) OMF(Oracle Managed File) dosya sistemi kullanacağım. Veritabanı olarak Oracle 10g R2 sürümünü ve host OS olarak ise Solaris 10 kullanmaktayım. İlk işlem olarak  db_create_file_dest parametresi ile OMF dizinini tanımlıyorum.

SQL> show parameter db_create_file_dest
NAME                         TYPE               VALUE
------------                  ------------      ------------
db_create_file_dest      string                /oradata2

Export ve import işlemleri öncesinde DBMS_FILE_TRANSFER paketi kullanarak ASM’den diğer bir ASM’ye dosya transferi

Oracle 10g sürümünden itibaren DBMS_FILE_TRANSFER paketi ile aracı lokal dosya oluşturmadan direkt olarak ASM’den başka bir sunucu üzeridenki ASM’ye dosya transferi yapılabilmektedir.

Bu transfer işlemi için 2 farklı metot vardır. get_file ile uzak lokasyondan lokal sunucudaki ASM’ye dosya kopyalanabilmekte, put_file ilede lokal sunucudaki  bir dosya uzak bir ASM’ye kopyalanabilmektedir. İsterseniz bu iki farklı metodun uygulamalarını yapalım.