Database Resident Connection Pooling(DRCP) ile bağlantı havuzu oluşturma

Bu yazıda Oracle 11g ile birlikte gelen yeni bir özelliği inceleyeceğiz. Database Resident Connection Pooling(DRCP), tipik web uygulamalarında kullanılan veritabanı içinde bağlantı havuzu oluşturma metodudur. Kullanılan web uygulamasının veritabanı bağlantısını kısa süreli bağlantı için kullanıp, çalışmasını bitirince bağlantıyı serbest bırakan tarzda uygulama türleri için ideal bir bağlantı havuzu metodudur. DRCP, dedicated sunucuları toplar. “Pooled server(toplu sunucu)”, sunucu arkaplan prosesleri ve veritabanı oturumu kombinasyonu ile aynı anlama gelmektedir.

DRCP, aynı middle-tier sunucu üzerindeki middle-tier prosesler üzerinden veritabanı bağlantısı paylaşımını etkinleştirebildiği gibi, gerektiğinde middle-tier hostlar üzerindende bağlantı paylaşımını etkinleştirebilmektedir. Bu olay, geniş sayıda istemci bağlantılarını desteklemek için gereken veritabanı kaynaklarında inanılmaz derecede yük azalmasına sebebiyet verir, böylece veritabanında bellek talebinde azalma olur ve hem veritabanı katmanında, hemde middle-tier katmanında ölçeklenebilirlik artar. Halihazırda uygun bir sunucu havuzunun olması, aynı zamanda istemci bağlantısı oluşturma ve devre dışı bırakma maliyetini azaltmak yoluyla ilave katma değerlerde sağlar.

DRCP, middle-tier katmanında bağlantı havuzu oluşturma imkanının olmadığı çoklu prosesli ve tekil thread uygulama sunucuları(PHP/Apache gibi) gibi mimarilerde oldukça kullanışlıdır.

DRCP kullanıldığında oturum belleği için PGA’dan alan tahsis edilir. İstemci tarafından ilk bağlantı talebi alındığında “Connection Broker” uygun bir toplu(pooled) sunucuyu alır ve istemci bağlantısını bu toplu sunucuya  devreder. Eğer uygun bir toplu sunucu yoksa, DRCP bir tane oluşturur. Eğer havuz, maksimum sayıyı aştıysa bir toplu sunucu boşa çıkıncaya kadar, bu istemci bağlantısı kuyrukta beklemeye alınır. Veritabanı kaynakları serbest bırakıldığında, bu toplu sunucu tekrar havuza serbest bırakılır. Bellek gereksinimi toplu sunucu sayısı ve onların oturumları ile orantılıdır.Her bir toplu sunucu için bir oturum vardır.

Oracle 11g R2 (11.2.0.2) RAC mimarisinde Data Guard kurulumu ve yönetimi

Bu yazıda Oracle 11g R2 RAC mimarisini hem primary hemde standby veritabanı olarak kullanarak, cluster çapında Data Guard yapılandırmasını ve yönetim tekniklerini inceleyeceğiz. Aslında bu incelemeyi migration testleri kapsamında 2010 Temmuz ayında Hollanda’da datacenterımızda yapmıştım, bu sebeple o zamanki test sonuç analiz notlarımı bulup harmanlayarak bu yazıyı hazırladım. Ancak unutmadan belirtmek isterim, Swingbench adlı stres testi aracı ile 1,000 kadar sanal kullanıcıya oturum açtırıp eşzamanlı hem primary siteden INSERT-UPDATE işlemleri  yapıp hemde standby siteden SELECT  sorgularını sorunsuz yapabildiğimi söyleyebilirim ve bu sürede cluster CPU, bellek ve I/O performanslarıda oldukça iyiydi.

Bu inceleme için o tarihte kullandığım fiziksel kaynaklar; 4 adet Sun SPARC Enterprise M3000 Server ve 1 adet Sun Storage 6180 Array ünitesinden oluşmaktadır. Sunucularda, Oracle Enterprise Linux 5.4 ve Oracle 11.2 Grid Infrastructure yazılımı kurulu ve Oracle depolama sistemi olarak Oracle ASM kullanılmaktadır.

RAC kullanılacak olan primary ve standby sitelerindeki sunuculara Oracle 11gR2 GI ve RDBMS yazılımlarının kurulmuş olmalıdır. Primary sitede ayrıca bir RAC veritabanının hizmet veriyor olması gerekmektedir. Daha önce yayınlanan Oracle 11g R2 RAC kurulum adlı yazıyı referans alarak clusterware kurulumunu 2 farklı sitede ve 2 ayrı yapıda aşağıdaki mimaride gerçekleştiriyoruz.

Benim yukardaki sistemimde;

LINUX1_RACPRIM à RAC1 adlı instance içermektedir

LINUX2_RACPRIM à RAC2 adlı instance içermektedir

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

Primary site içerisinde RAC adlı cluster primary veritabanını bulunur ve SCAN adresi rac-scan olmuştur. DATA ve DGSTDBY adlı ASM diskgruplar mevcuttur.

LINUX1_RACSTD à RACSTD1 adlı instance içerecektir.

LINUX2_RACSTD à RACSTD2 adlı instance içerecektir.

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

Standby site içerisinde RACSTD adlı cluster standby veritabanını bulunacaktır ve SCAN adresi racstd-scan olacaktır. DATA adlı disk grubu önceden mevcuttur.

Önce isterseniz RAC ve Dataguard ne anlama gelmekte ve her ikisi birlikte kullanıldığında ne gibi avantajlar sağlanmaktadır.

Üst sürümlerden alt sürümlere EXPORT ve IMPORT işlemleri

Export aracı ile Oracle alt sürümlerde oluşturulan dump dosyalar, tüm üst Oracle sürümlerine import ile sorunsuzca taşınabilmektedir. Ancak, üst sürümlerden export edilen dump dosyaların alt sürümlere import edilebilmesi noktasında bir takım kısıtlamalar mevcuttur. Alt versiyon uyumlu dump dosyası elde edebilmek için aşağıdaki adımlara uyulması gerekmektedir.

• Data Pump export  kullanırken mevcut versiyonun datapump export aracını kullanın , ancak VERSION parametresinde hedef veritabanının eski sürümünü işaret edin.
• Export aracı kullanılacaksa, export işleminin yapılacağı veritabanında hedef veritabanı ile uyumlu versiyonda export aracını yükleyip bu export (exp) aracını kullanarak dump dosyası oluşturun. Sonra, hedefte orijinal import aracı ile dump dosyasını import edin.Örneğin; Oracle 10g veritabanının export aracı ile export editen bir dump dosyasını Oracle 9i üzerinde import aracı ile import edemezsiniz. Bu durumda Oracle 10g veritabanı üzerine Oracle 9i uyumlu exp aracının yüklenmesi ve bu araç ile export işleminin yapılması gerekmektedir.

Aşağıda üst sürümlerden alta sürümlere yapılacak export/import işlemlerinde kullanılacak VERSION bilgileri yer almaktadır.

Yukardaki tabloda yer alan herhangi bir üst sürümden uyumlu bir alt sürüme yapılacak export işleminde, öncelikle export işlemi yapılacak üst sürüm veritabanında CATEXP.SQL scripti çalıştırılmalıdır. Bu scriptin, hedefteki alt sürüm veritabanından export işleminin yapılacağı üst sürüm veritabanına kopyalanmış olması gerekmektedir. Bu script çalıştırıldıktan sonra expdp aracı ile export işlemi yapılabilir.

Oracle 11g R2 RAC yapısında düğümlerin birinde oluşan “CRS-0184 Cannot communicate with the CRS daemon” hatası ve çözümü

Oracle Grid Infrastructure ve Oracle yazılım kurulumu başarılı şekilde tamamlandı ve Oracle RAC veritabanı oluşturuldu. Kurulumdan CRS hizmetlerini kontrol ederken servislerin başarılı şekilde online durumda olduğunuda görmekteyiz.

# crsctl check crs

CRS-4638: Oracle High Availability Services is online

CRS-4537: Cluster Ready Services is online

CRS-4529: Cluster Synchronization Services is online

CRS-4533: Event Manager is online

Ancak, ne oluyorsa cluster içindeki ikinci düğümü yeniden başlattıktan sonra oluyor. Birinci düğümde cluster hazır servisi(crs) başarıyla çalışmasına rağmen ikinci düğümde bir türlü başlayamıyor. Aşağıda örnekte 2. düğümün CRS durumu yer alıyor.

# crs_stat -t

CRS-0184: Cannot communicate with the CRS daemon.

Oracle 11g R2 RAC mimarisinde "server pools"

Sunucu havuzları(server pools) Oracle 11g R2 ile yeni gelen özelliklerden bir tanesidir ve cluster ortamında iş yükünün mantıksal dağıtımı ile ilgili clouding(bulut) teknolojisi hizmetleri getirmektedir. Sunucu havuzlarının kullanımının sağlanması, ilke bazlı(policy based) cluster yönetimi adı altında bir metot ile sağlanmaktadır.Hem uygulamaları, hemde veritabanları ilke bazlı yönetilebilmektedir. Bunun için RDBMS sürümünün 11.2.0 veya üzeri olması gereklidir.

Sunucu havuzu, aslında RAC ortamında clusterware hizmetinde arzu edilen mantıksal işyükünü sağlayacak olan düğüm sayısını optimal seviyede tutarak(aktif/aktif), varsa diğer düğümleride yedekte bekleterek(pasif), bir felaket anında <- havuz içindeki düğümlerden birisi erişilemez olursa -> bu yedekteki düğümü havuza dahil ederek mantıksal işyükünü her daim optimal seviyede bulundurmayı sağlamaktadır. Bu şekilde, havuzlar mantıksal olarak işlevsellik yapmakta olup, aslında kümelerin cluster içindeki yönetimini sağlamaktadır.

Sunucu havuzu mimarisi 4 bölümden oluşmaktadır;

-  Sunucu havuz ismi

-  Havuz içinde bulunacak minimum sunucu sayısı

-  Havuz içinde bulunacak maksimum sunucu sayısı (varsayılan değer 0’dır)

-  Sunucu havuzları arasındaki öncelik oranı (varsayılan değer 0’dır)

Sunucu havuzu mimarisinde yukardaki bölümlerin ne anlama geldiğine bakalım.Farzedinki, 6 düğümlü cluster sisteminizde 2 tane farklı RAC veritabanı vardır, her zaman 1 düğümün pasif olarak yedekte beklemesini ve düğümlerden birisi down olduğu zaman bu boştaki düğümün havuza dahil olmasını istiyoruz. Birinci RAC veritabanında arzu edilen işyüküne cevap vermesi için en fazla 3 düğümün işleme girmesini, ikinci RAC veritabanında arzu edilen işyükü 2 düğümle karşılanabilecektir. Bu maksatla sunucu havuzları aşağıdaki gibi düzenlenmektedir.

Sunucu havuzu adı= POOL1               Sunucu havuzu adı= POOL2
MIN_SERVERS = 2                              MIN_SERVERS = 2
MAX_SERVERS=3                               MAX_SERVERS= 2
ÖNCELİK=3                                         ÖNCELİK=2

Yukardaki iki sunucu havuzunda önceliği yüksek olan sunucu havuzu POOL1 olduğundan dolayı(değeri yüksek olan yüksek önceliklidir) cluster hizmet sırasındaki ilk 2 düğüm POOL1 sunucu havuzuna kayıt olacak, sonraki 2 düğüm POOL2 sunucu havuzuna kayıt olacaktır. Cluster öncelik listesindeki 5. düğüm MAX_SERVER değeri 3 olan POOL1 havuzuna kayıt olacaktır. 6. düğüm ise boşta bekleyecektir.

rac1, rac2,rac5 --> POOL1
rac3, rac4 --> POOL2
rac6 --> free

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

Oracle 11g RAC mimarisinde GCS ve GES performansını izleme ve iyileştirme tavsiyeleri

Oracle 11g RAC mimarisinde performans izleme ve iyileştirme noktasında GCS ve GES servislerinin iyileştirilmesi, private bağlantının(interconnect) network performansının artırılması önem kazanmaktadır. Bunları detaylı olarak aşağıda incelemeye başlayalım.

Global Cache Services(GCS) kalıcı okumalarının(cr) izlenmesi

Kalıcı okumaların(consistent read-cr) performansını izlemek için alttaki formül kullanılır.

 (gc cr block receive time × 10) / (gc cr blocks received)

Yukardaki formulün sonucunda instance için milisaniye değerinde kalıcı blok okuması taleplerinin ortalama zamanı dönmektedir ve Enterprise Manager RAC performans görünümlerinde gözlemlediğimiz global bellek blok transfer oranı (Global Cache Block Transfer Rate) metrikidir. Bu değer interconnect performansını belirlemek için kullanılan en önemli değerdir.

Veri blokları için global kaynak talepleri, talep eden instance’ın ön belleği içinde meydana gelir. Talep, GCS talep kuyruğuna girmeden önce Oracle, SGA içinde talebin durumunu izleyecek ve bu kaynak yapıları üzerinde istatistik toplayacak veri yapılarını tahsis eder.

SQL> SELECT

> gc_cr_block_receive_time AS "Receive Time",

> gc_cr_blocks_received AS "Blocks Received",

> (gc_cr_block_receive_time * 10) /

> gc_cr_blocks_received AS "Average Latency (MS)"

> FROM

> (

> SELECT value AS gc_cr_block_receive_time FROM v$sysstat

> WHERE name = 'gc cr block receive time'

> ),

> (

> SELECT value AS gc_cr_blocks_received FROM v$sysstat

> WHERE name = 'gc cr blocks received'

> );

Alttaki sonuç yukardaki raporun çalışması sonucu alınan bir örnek sonuçtur:

Receive Time   Blocks Received          Average Latency (MS)

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

5405                    3869                            23.9681803

Oracle 11g RAC "Cache Fusion" Teknolojisi

Oracle RAC veritabanı sisteminde iki önemli servis vardır. Bunlar  Global Cache Service (GCS) ve Global Enqueue Service (GES) dir. Bu ikisi temelde arkaplan proseslerinin koleksiyonudur. Her iki proses birlikte toplam "cache fusion" prosesini, kaynak transferlerini ve instancelar üzerinden kaynak tırmanmasını kapsar ve yönetir.

Global Kaynak Dizini (Global Resource Directory)

GES ve GCS prosesleri beraberce, kaynak ve kuyruğa ekleme bilgilerini kaydetmek için Global Kaynak Dizinini(GRD) oluştururlar. GRD, bellek içinde yer alır ve tüm instanceler üzerinde saklanır. Her instance dizinin bir parçasını yönetir.Bu dağıtık sadelik, RAC’ın fault tolerance yapısı için anahtar noktayı oluşturmaktadır.

Global Kaynak Dizini (GRD), veri bloklarının mevcut durumunu kaydeden ve saklayan dahili bir veritabanıdır. Bir blok, bulunduğu instance içindeki lokal bellekten diğer instance’ların belleğine transfer olur olmaz GRD güncellenir. GRD içinde aşağıdaki kaynak bilgileri yer almaktadır.

OE Linux 5.3 üzerine iki düğümlü Oracle 11g R2 RAC kurulumu - adım adım

OE Linux 5.3 üzerine iki düğümlü Oracle 11g R2 Real Application Clusters(RAC) kurulumu 4 safhaya ayırmaktayım.

A. Linux üzerinde kurulum öncesi yapılandırma.

B. Oracle Grid Infrastructure yazılımının kurulumu.

C. Oracle Database yazılımının kurulumu.

D. Oracle veritabanı oluşturma.

Her bir adımın uygulamasına geçmeden önce Oracle 11g R2 RAC konseptine kısa bir göz atalım.

Oracle 11g R2 RAC mimarisi konsepti ve gelen yenilikler

Oracle Database 11g Release 2 itibariyle, Oracle Clusterware ve Oracle ASM, grid home olarak adlandırılan aynı tekil dizine kurulmaktadır. Oracle grid mimarisi kombine ürünlerin kurulumuyla adlandırılmaktadır. Ancak, Oracle Clusterware ve Oracle ASM ayrı ürünlerdir.

Oracle Clusterware sunuculara host veya düğümler olarak bakarak birden fazla sunucunun tek bir sunucu gibi işlev görmesine imkan vermektedir. Halbuki sunucular bağımsızdır ve her bir sunucunun diğer sunucular ile iletişimini sağlamak için ilave prosesleri vardır. Bu şekilde tek bir veritabanı birden fazla sunucunun üzerinde düğümler olarak adlandırılan yapıda çalışırken her bir sunucunun donanım kaynakları ayrı ayrı paylaşımda olmaktadır. Böylece birden fazla sunucudan oluşan düğümlerde paylaşımlı bellek ve prosesleri için tahsis edilen kaynaklar düğüm sayısına parallel arttığından bellek ile proses tahsis ve kullanım performanslarındada iyileşmeler meydana gelmektedir. Oracle Clusterware yazılımı Oracle Real Application Clusters hizmetinin çalışması için gerekli mimariyi desteklemektedir.

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.

Oracle 11g R2 RAC veritabanının başka bir sunucuya single instance veritabanı olarak kopyalanması

Oracle 11g sürümü herhangi bir yedek kullanmadan Oracle Net yoluyla veritabanın kopyalanmasına imkan vermektedir. Bunun için kaynak veritabanının açık ve arşiv log özelliği etkin olmalıdır veya temiz bir kapatma sonrasında MOUNT modda açık tutulmalıdır.

Bu yazıda çift düğümlü Oracle 11.2 RAC veritabanının, başka bir sunucuda tekil instance olarak çalışmak üzere kopyalanması işlemini adım adım yapılandıracağız.

$ olsnodes -n
rac1    1
rac2    2

RAC veritabanında iki tane ASM disk grubu vardır;

Verilerin tutulduğu diskgrubu:+DATA

flash recovery alanı: +FLASH

1. Kopyalanacak veritabanın bulunacağı sunucu üzerinde Oracle yazılımı (Enterprise veya Standard, kaynak ile aynı olmalı) yüklenmelidir. Yükleme için blogta yazılarım mevcuttur. Aynı zamanda audit trail (adump dizini) ve kontrol dosyalarının tutulacağı fiziksel dizinin oluşturulması gerekmektedir.

Network linki kullanarak EXPDP ve IMPDP işlemlerinin yapılması

Export ve import pompalama işlemlerinde kaynak veriyi hedef veritabanı sunucusuna taşımak için network bağlantısı methodunu kullanmak faydalı olabilmektedir.impdp işleminde veritabanından başka bir veritabanına herhangi bir aracı dosya kullanmadan direk taşıma yapılabilmektedir. Bu işlemin adım adım uygulandığı bir senaryo aşağıda yer almaktadır.

1. Kaynak veritabanında tnsnames.ora dosyası içinde hedef veritabanı için bir TNS girişi oluşturuyoruz ve bu TNS girişini kullanarakta bir veritabanı linki oluşturuyoruz.

TARGET_DB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.20.2)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = testdb2)
) )

SQL> create database link target_db connect to hr identified by hr using 'TARGET_DB';

2. Bu veritabanı linkini impdp veya expdp komutunda belirtiyoruz.

Standby veritabanında bazı data dosyalarına redo uygulamasının durması

Eğer primary veritabanı üzerinde FORCE LOGGING etkin değilse, kullanıcıların NOLOGGING takısını kullanarak yapacakları girişler standby sunucuda ilgili tablonun veya tablolaların tutulduğu veri dosyalarına taşınmayacaktır. Bu durumdada standby üzerinde bu veri dosyalarında blok bozulmaları meydana gelecektir. Fiziksel standby veritabanındaki veri dosyalarının bir kısmının log transferini yapamadığı durumlarda bu veri dosyalarını en son SCN ye güncelleme ve kesintisiz loglamaya devam etmesini sağlamak için aşağıdaki adımları uygulayabiliriz. Tabii bu olay ile karşılaşmamak için eğer primary veritabanında FORCE LOGGING etkin değilse etkinleştirilmelidir.

1. Öncelikle standby üzerindeki hangi veri dosyalarının redo uygulamasında eksik kaldığını tespit etmemiz gerekecektir. Bunu bulmak için aşağıdaki örnekte görüldüğü üzere V$DATAFILE görünümüne sorgu çekmemiz gerekmektedir.

SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE

        2> WHERE FIRST_NONLOGGED_SCN > 0;

FILE#              FIRST_NONLOGGED_SCN

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

   3                   145957

   4                   150164

Farklı platformlar arasında Oracle veritabanını taşıma

Aynı endian formatına sahip işletim sistemleri arasında Oracle veritabanını tümüyle taşımak Oracle 10g R2 sürümünden itibaren gerçekleştirilebilmektedir. Örneğin, Windows platformunda çalışıp performans sıkıntısı yaşadıktan sonra Linux’a geçiş yapmak isteyenler için oldukça basit ve hızlı bir çözüm olmaktadır. Bunun yanında, benimde kısa zaman once başıma gelen,  kurumsal enterprise anlaşmalarında üretici firma değişikliği sonucunda, donanım ve işletim sistemlerinin radikal olarak değiştiği durumlarda Oracle DBA lere gerçekten  faydalı ve kestirme çözümler sunmakta.

Tabii, burada unutulmaması gereken en önemli nokta hedef ve kaynak işletim sistemlerinin aynı debian formatında olmasıdır. Farklı olduğu durumda taşınabilir tablespace metodunu kullanmak gerekecektir. Her iki platformun atnı debian formatında olup olmadığını  anlamak için V$TRANSPORTABLE_PLATFORM görünümüne sorgu çekmek yeterli olacaktır.

Senaryomuz gereği Windows 2003-32 bit platformdan Linux x86-64 bit platformuna  Oracle 10g R2 veritabanının nasıl taşınacağını adım-adım inceleyelim.

İlk aşamada DBMS_TDB.CHECK_DB prosedürü çalıştırılarak veritabanının hedef platforma taşınmasının mümkün olup olmadığının anlaşılması gerekecektir.Bu prosedürü çalıştırmadan once veritabanını Windows sunucuda READ ONLY modda yeniden başlatıyoruz.

RAC veritabanına yeni bir ASM disk eklerken karşılaşılan sorunlar

Solaris 10 üzerinde çalışan bir RAC veritabanına yeni bir ASM disk eklemeye çalışıldığında aşağıdaki gibi hata mesajları ile karşılaşabilir ve muhtemelen bu yeni ASM diski ekleyemeyiz.

ORA-15075 “disk(s) are not visible cluster-wide”

ORA-15020 “discovered duplicate ASM disk “DISK1″ and

ORA-15054 “disk “ORCL:DISK1″ does not exist in diskgroup “DG1″.

Disk grubunu yeniden dengelemek(rebalance) veya nomount-mount işlemi yapmak veya FORCE takısını kullanarak bu yeni diski ilave etmekte sonuç vermeyebilir. Bu durumu bir senaryoda uygulayarak nasıl çözüme kavuşturacağımıza bir göz atalım.

Oracle 11g üzerinde tablespace şifreleme metodu

Oracle 10g sürümünde Transparent Data Encryption (TDE) özelliği hayatımıza girdi. Ancak bu güzelliğin eksik yanı şifrelemenin sadece tekil tablo kolon seviyesinde yapılabilmesiydi. Artık Oracle 11g sürümünden itibaren şifrelemeyi tablespace seviyesinde etkinleştirebilmekte ve böylece şifreleme tablespace bünyesindeki her tabloya otomatik olarak miras kalmaktadır.

Şimdi tablespace seviyesinde şifrelemenin adımlarını inceleyelim.

Farklı endian formatında işletim sistemleri arasında tablespace taşıma

Oracle 10g sürümünden itibaren farklı endian formatına sahip işletim sistemi platformları arasında tablespace taşıması yapılabilmektedir. Farklı endian formatına sahip işletim sistemi platformlarında taşınabilir tablespace ihraç ve ithal aşamaları aşağıdadır.

Adım 1: Hedef ve kaynak veritabanında işletim sistemi byte sıralamasını buluyoruz.

SQL > select * from v$transportable_platform

            order by platform_id;

PLATFORM_ID                   PLATFORM_NAME                          ENDIAN_FORMAT
-----------------                         --------------------------                             -------------------------
1                                              Solaris[tm] OE (32-bit)                         Big
2                                              Solaris[tm] OE (64-bit)                         Big
3                                              HP-UX (64-bit)                                     Big
4                                              HP-UX IA (64-bit)                                 Big
5                                              HP Tru64 UNIX                                    Little
6                                              AIX-Based Systems (64-bit)                 Big
7                                              Microsoft Windows IA (32-bit)              Little
8                                              Microsoft Windows IA (64-bit)              Little
9                                              IBM zSeries Based Linux                    Big
10                                            Linux IA (32-bit)                                   Little
11                                            Linux IA (64-bit)                                   Little
12                                            MS Windows 64-bit for AMD                Little

Aynı endian formatındaki işletim sistemleri arasında tablespace taşıma

Transportable(taşınabilir) tablespace export ve  import işlemleri farklı platformlar arasında yapılabilmektedir,ancak sadece meta verisi ihraç edilmektedir. Farklı işletim sistemlerinde verilerin taşıması basit ve hızlı olmaktadır. Bu mod için EXP_FULL_DATABASE rolüne üye olunması gerekmektedir.

Farklı platfomlar arasında taşınabilir tablespace meta verisinin ithal ve ihraç işlemleri için aşağıdakilerin gözönünde bulundurulması gerekmektedir.

1. Kaynak ve hedef veritabanı aynı karakter setinde ve ulusal karakter setinde olmalıdır.

2. Hedef veritabanında aynı isimde tablespace bulunmamalıdır.

3. Taşınabilir tablespace ihracı durduğu zaman tekrardan başlatılamaz.
4. Hedef veritabanı kaynak veritabanı ile aynı sürümde veya daha üst sürümde olmalıdır.

Aynı endian formatına sahip farklı işletim sistemleri arasında tablespace taşıması aşağıda adım adım anlatılmaktadır;