Oracle 11.2 veritabanında DBMS_SPACE_ADMIN paketi ile kullanılmayan segmentlerin düşürülmesi

Oracle 11.2.0 sürümü ile DBMS_SPACE_ADMIN paketi içerisinde gömülü gelen DROP_EMPTY_SEGMENTS prosedürünü kullanarak önceki sürümlerden migration sonucu gelen boş tablo ve partitionlara ait segmentleri düşürerek boş alan kazanabilmekteyiz. Bu prosedür ile bu boş tablolara bağlı olan index segmentleri gibi ilişkili objelerde düşürülmektedir. DROP_EMPTY_SEGMENTS prosedürünü kullanabilmek için veritabanının 11.2 uyumluluk seviyesinde olması gerekmektedir.

Aşağıdaki örnekte veritabanındaki her tablo taranarak boş segmentler düşürülmektedir.

BEGIN

DBMS_SPACE_ADMIN.DROP_EMPTY_SEGMENTS();

END;

Aşağıdaki örnek ise UXR şemasının TBLSTRSC tablosundaki boş segmentleri ilgili objeler(index vs.) ile birlikte düşürmektedir.

BEGIN

DBMS_SPACE_ADMIN.DROP_EMPTY_SEGMENTS(

schema_name => 'UXR,

table_name => 'TBLSTRSC);

END;

Oracle 11.2 Dataguard ortamında Oracle Restart servisi ile Fast Application Notification(FAN) olayları

Oracle 11g Dataguard mimarisinde FAN(Fast Application Notification) olaylarının Oracle Restart servisi yoluyla etkinleştirilmesi için öncelikle Oracle Restart sunucularını ve entegre istemcilerini içeren Oracle Notification Service(ONS) networkunun oluşturulması gerekmektedir. Bu entegre istemciler Oracle Bağlantı Yöneticisi(CMAN), Java Veritabanı Bağlayıcısı(JDBC) veya Universal Connection Pool(UCP) istemcileri olabilir.  ONS networku ile primary veritabanında meydana gelen bir failover durumunda, FAN olayları DOWN durumunu işaret ederek standby sunuculara Dataguard Broker tarafından yayınlanacaktır. CMAN, JDBC ve UCP ile bağlı olan uygulamalar, Fast Connection Failover(FCF) özelliği kullanılarak, failover durumundan etkilenmeden otomatik olarak yeni primary veritabanına bağlantı açarlar.

Oracle Restart primary veritabanını izleyerek DOWN olayı meydana geldiğinde istemcilere, bu düşen veritabanı ile bağlantılarını sonlandırması için FAN duyurusu yapar ve UP olayı meydana geldiğindede yeni bir FAN duyurusu ile yeni primary rolüne bürünenen eski standby veritabanı üzerinden yeni bağlantılar açılır.

Oracle 11g Dataguard platformunda, Oracle Restart servisinin etkinleştirilerek ASM, listener ve servislerin otomatik olarak başlatılması için gereken yapılandırma ile birlikte FAN olaylarının Oracle Restart içerisinde kayıt edilmesi adımları aşağıda yer almaktadır. Senaryoda Oracle Restart özelliği Dataguard yapılandırmasından sonra etkinleştirilmiştir.

1. Primary ve standby sunucularda Oracle DataGuard Broker kurulduğundan emin olun. Oracle DataGuard kurulumu ile ilgili yazımı inceleyebilirsiniz.
2. Hem primary hem standby sunucularda root hesabından oturum açarak,Oracle Restart özelliği etkinleştiriliyor. Böylece sunucunun her açılışında açılışı sağlayacak olan Oracle High Availability Servisi, namı diğer “Oracle Restart” otomatik başlamaya ayarlanmış oluyor.

# crsctl enable has

CRS-4622 Oracle High Availability Services autostart is enabled.

3. Primary sunucu üzerinde, ilgili primary veritabanı Oracle Restart konfigürasyonuna eklenmelidir. Ardından, bu primary sunucu üzerindeki Oracle Restart konfigürasyonuna varsa ASM instance ve listenerda eklenmelidir.

$ srvctl add database -d orcldg –r primary -o /u01/app/oracle/product/11.2.0/db_1 à DB_UNIQUE_NAME=orcldg olan ve –o ile belirtilen db_home dizininde primary rolünde olan veritabanı Oracle Local Registry(OLR) içine ekleniyor

Oracle 11g Query Result Cache ile sorgu sonuçlarının önbelleklenmesi

Result Cache özelliği nedir?

Cache(Önbellek): Oracle dünyasında pek çok önbellek çeşidi vardır: library cache, buffer cache, dictionary cache, database cache, keep cache, recycle cache, etc. Çok uzun zamandan beri Oracle mimarisindeki ana hedef, en iyi performansı yakalamak için verileri önbelleklemektir.

Bir sorgu ilk kez çalıştırıldığında kullanıcının prosesi bu veriyi “database buffer cache” içinde arar. Eğer bu veri buradaysa(başka birileri bu veriyi daha önce çağırdıysa) bunu kullanır. Aksi takdirde, bu veriyi önbelleğe almak için veri dosyasına I/O işlemi yapar ve bu veriden final sonuç seti oluşturulur.

Daha sonra, eğer başka bir sorgu aynı veri setine ihtiyaç duyarsa bu kullanıcı tarafından ihtiyaç duyulan sonuç setini inşa etmek için önbellekteki bu veri ilgili kullanıcı prosesince kullanılır. Eğer önbellek tampondaki veri tekrar kullanılabilmekteyse, o zaman nedir peki bu yeni gelen “Result Cache” özelliği? Basit kavramla Result Cache, önbellek içerisinde sonuç setlerini tutan bir önbellek alanı olarak adlandırılabilir - yani paylaşımlı havuz içinde çalıştırılmış olan sorgu sonuçlarını tutan bir alan-

Peki bu demektir? Gelin bunu bir örnek üzerinden netleştirelim. Aşağıdaki örnek Oracle Database 11g Release 2 veritabanında çalıştırılıyor:

SELECT OL_NUMBER, SUM (OL_AMOUNT), SUM (OL_QUANTITY)

FROM   ORDER_LINE OL, ORDERS ORD

WHERE  OL.OL_O_ID = ORD.O_ID AND

       OL.OL_W_ID = ORD.O_W_ID AND

       OL.OL_D_ID = ORD.O_D_ID

GROUP BY OL_NUMBER;

Trace dosyasının tkprof rapor çıktısı, sorgunun 347,000 satırdan daha fazlası üzerinden geçiş yaparak sonuç seti olan 300 satırlık veriyi içeren sonuç çıktısını sağladığını ortaya koymaktadır.

call     count       cpu    elapsed       disk      query    current        rows

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

Parse        1      0.01       0.02          0          0          0           0

Execute      1      0.00       0.00          0          0          0           0

Fetch       21     33.04      96.12     346671     347172          0         300

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

total       23     33.06      96.14     346671     347172          0         300

Başka bir kullanıcı aynı sorguyu çalıştırdığı zaman ne olmaktadır? Kullanıcı oturumu, önbellek tamponu içindeki tüm satırlar üzerinden geçiş yaparak, final sonucu olan 300 satıra erişecektir. Peki, bu 300 satırı ikinci seferde direkt getirecek bir metod olsaydı? Aslında, bu veriyi tutacak yeterli büyüklükte önbellek olursa bu mümkün olabilmektedir. İşte bu olay tam olarak “Result Cache” adını verdiğimiz özelliktir.

Türkiye Bilişim Derneği 2011 yılı faaliyet takvimi

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

Data Guard Broker mimarisinde Fast-Start failover özelliğinin etkinleştirilmesi

Primary veritabanına olan bağlantı kaybolduğu durumlarda daha önceden seçilen standby veritabanına Data Guard Broker prosesinin otomatik olarak failover işlemini yapması özelliğidir.  Fast-Start Failover özelliği sadece Data Guard Broker yapılandırması içinde kullanılır ve DGMRL komut satırı veya Enterprise Manager konsolu üzerinden etkinleştirilir.

Hem maksimum erişilebilirlik hemde maksimum performans modunda çalışabilmektedir.Maksimum erişilebilirlik modu seçili olduğunda sıfır veri kaybı garanti edilmektedir.  Maksimum performans modu seçili olduğu durumda ise FastStartFailoverLagLimit konfigürasyon parametresi ile belirlenen saniye içerisindeki veriden daha fazlasının kaybı önlenmiş olmaktadır.

Herhangi bir failover durumunda broker’ın kesintisiz çalışmasını sağlamak için, gözlemciyi primary ve standby veritabanları dışında bir makineye kurmak faydalı olacaktır. Hem Dataguard Broker hemde standby veritabanı, primary veritabanı ile bağlantıyı FastStartFailoverThreshold parametresinde belirlenen süreden daha uzun sürede kaybettiği zaman, broker standby veritabanına doğru fast-start failover işlemini tetikler. Buna ilaveten, eğer FastStartFailoverPmyShutdown parametresi TRUE olarak ayarlanmışsa, FastStartFailoverThreshold parametresindeki süreden daha uzun süreli kesinti durumunda primary veritabanı kapatılır.

Data Guarda bağlı bekleme olayları

Primary veritabanından standby veritabanına redo gönderirken ayrılan zaman iki ana bölüme ayrılır, networkun bir ucundan diğer ucuna geçerken zaman ve standby sunucu üzerinde diske yazarken geçen zaman. I/O olurken geçen zaman esnasında primary veritabanında sağlanan toplam zamanı ele geçiren bekleme olayları standby üzerinde izlenebilir.

Primary veritabanınından standby veritabanına ARCH veya LGWR prosesleri ile redo gönderirken meydana gelen bekleme olayları altta yer almaktadır. Bu veriler primary veritabanından elde edilir.

Olay İsmi	Proses	Tanımı
ARCH wait on ATTACH	ARCH	Bu bekleme olayı tüm arşivci prosesler tarafından yeni RFS bağlantıları meydana getirme süresindeki geçen süreyi izler.
ARCH wait on SENDREQ	ARCH	Bu bekleme olayı tüm arşivci prosesler tarafından arşiv dosyalarını standbya yazmakla birlikte lokal diskede yazma esnasında geçen süreyi izler.
ARCH wait on DETACH	ARCH	Bu bekleme olayı tüm arşivci prosesler tarafından RFS bağlantısını silme esnasında geçen süreyi izler.
LNS wait on ATTACH	LGWR	Bu bekleme olayı tüm LNS prosesleri tarafından  yeni bir RFS bağlantısı meydana getirme süresindeki geçen süreyi izler.
LNS wait on SENDREQ	LGWR	Bu bekleme olayı tüm LNS prosesleri tarafından alınan redoları diske yazmakla birlikte standby arşiv redo dosyalarını açmak ve kapatmak sırasında geçen süreyi izler.
LNS wait on DETACH	LGWR	Bu bekleme olayı tüm LNS prosesleri tarafından RFS bağlantısını silme sürecindeki geçen süreyi izler.
LGWR wait on LNS	LGWR	Bu bekleme olayı LNS prosesinden alınan mesajları beklerken LGWR prosesince geçen süreyi izler.
LNS wait on LGWR	LGWR	Bu bekleme olayı LGWR prosesinden alınan mesajları beklerken LNS prosesince geçen süreyi izler.
LGWR-LNS wait on channel	LGWR	Bu bekleme olayı  LGWR tarafından geçen zamanı veya mesajları almak için bekleyen LNS prosesleri tarafından geçen süreyi izler.

Bunun yanında primary veritabanında izlenmesi gereken önemli I/O olayları ise altta yer almaktadır.

Maksimum Erişilebilirlik Mimarisinde OCI bağlantılarında SCAN kullanımı

Bu konuyu anlatmak için geniş yelpazade dağıtık bir maksimum erişilebilirlik mimarisi senaryosu üzerinden gitmek daha faydalı olacak diye düşünüyorum, şöyleki...

Yukardaki örnekte primary sitede 6 düğüm, standby sitedede 6 düğüm mevcut. Toplamda 6 servis oluşturulacak. 3 servis primary site üzerinde yazma amaçlı, 3 serviste raporlama amaçlı standby site üzerinden kullanılacak. Server pools teknolojisi kullanarak servislerin işyüküne uygun olarak donanımsal kaynak tahsisi yapacağız. Dataguard broker gözlemcisi primary siteyi izleyecek ve servislerden birinde düşme meydana gelirse otomatik olarak failover işlemini tetikleyecek.

Primary sitede;

3 sunucu havuzu olacak. Öncelik sırası ise SALES>CRM>MRP

MRP servisi için à En az 1, en fazla 2 server tahsisi gerekli

SALES servisi için à En az 2, en fazla 3 server tahsisi gerekli

CRM servisi için à En az 2, en fazla 3 server tahsisi gerekli

1 sunucu boşta olacak ve gerektiğinde devreye girecek…

Standby sitede;

3 sunucu havuzu olacak. Öncelik sırası ise MRP>CRM>SALES

MRP_READ servisi için à En az 2, en fazla 2 server tahsisi gerekli

SALES_READ servisi için à En az 1, en fazla 3 server tahsisi gerekli

CRM_READ servisi için à En az 2, en fazla 3 server tahsisi gerekli

1 sunucu boşta olacak ve gerektiğinde devreye girecek…

Bu senaryoyu gerçeğe dönüştürürken 3 aşamalı bir iş akışı üzerinden gideceğim.

1. İlgili servislerin ve TAF işlevinin eklenmesi
2. tnsnames.ora dosyalarında gerekli değişikliklerin yapılması
3. Server pools oluşturulması ve ilgili servislerin eklenmesi

Sonraki yazılarımda her üç aşamayı teker teker açacağız…

Oracle 11.2 Dataguard Broker ile RAC kümelerine JDBC bağlantılarında kusursuz application failover yapılandırması

Oracle 11.2 sürümü ile gelen SCAN(Single Class Access Name), küme içindeki her bir düğüm isminin istemciler tarafından bilinmesine gerek kalmadan, en optimal iş yükünün otomatik olarak DBA'ye ihtiyaç duymadan hesaplanarak, istemcinin en uygun düğüme yönlendirilmesini sağlayan bir prosesdir. Bu sayede istemci tarafındaki yük dengelemesi yönetimi DBA ler için ızdırap olmaktan çıkıp, clusterware tarafından otomatik olarak yönetilmektedir. Sunucu tarafındaki yük dengelemesi ise, talep edilen servis için en az yüklü instance bulmak amacıyla SCAN tarafından kontrol edilir ve bu düğümün lokal listenerına bu talep yönlendirilir. Rol bazlı veritabanı servisleri, Oracle Clusterware veya Oracle Restart içerisinden yapılandırılır. Oracle Dataguard,  Oracle Clusterware veya Oracle Restart ile etkileşime geçerek primary-standby rol değiş tokuşu sonunda gerekli servislerin aktif olmasını sağlar, böylece sistemi başlatma olayı için herhangi bir trigger yazılmasınada gerek kalmaz. Yapılandırma adımları için daha önceki yazılarıma bakabilirsiniz.

Aşağıdaki örnekte 2 düğümlü RAC adlı primary veritabanında “HR_APP” adlı servis primary rolde aktiftir. 2 düğümlü RACSTD adlı standby veritabanında da “HR_REPORT” adlı servis ise raporlama hizmetleri yapmak üzere fiziksel standby rolünde aktiftir.

[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_APP -l PRIMARY -q TRUE -e SELECT –m BASIC -w 10 -z 150

[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_REPORT -l PHYSICAL_STANDBY -q TRUE –e SELECT -m BASIC -w 10 -z 150

Herhangi bir switchover/failover durumunda HR_APP servisinin primary olarak hizmet vermeye devam etmesi için RACSTD adlı standby veritabanındada aşağıdaki gibi servisler eklenmiştir.