14 Aralık 2015 Pazartesi

RMAN performans ipuçları

Rman backup ve restore işlemleri kendi içinde farklı faz ve bileşenlere ayrılır. Herhangi bir fazdaki en yavaş RMAN job'ı bottleneck olarak tanımlanır. RMAN tuning işlemlerinin temel amacı ise bu jobı tanımlayıp, RMAN komutları, initialization parametreleri ve backup alınan fiziksel mediadaki ayarları değiştirerek performansı arttırmaya dayanır.

Basic Concepts of RMAN Performance Tuning
RMAN performansını nasıl arttırabileceğimizi anlamak için öncelikle RMAN backuplarının nasıl yaratıldığı konusunda fikir sahibi olmalıyız.
RMAN client, tüm backup ve restore işlemlerini gerçekleştiren database server sessionlarını yönetir. RMAN client backup, restore ve recovery gibi işlemleri kendi başına gerçekleştiremez, RMAN ile bir target database'e bağlandığımız zaman RMAN target instance üzerinde server sessionlar allocate eder ve işlemleri gerçekleştirir.
RMAN channel bir database server sessionına karşılık gelen data akış yolu olarak tanımlanabilir. Channel datayı PGA'dan okur, işler ve bu datayı backup device'ına yazar.
Read phase
Data bloklarının RMAN channel tarafından input I/O buffera okunduğu fazdır.
Allocation Of Input Disk Buffers
Database dosyaları ASM, Alternatif bir volume manager veya file sistem tarafından yönetiliyor olabilir. Backup tuning, database dosyalarının ASM ile yönetilip yönetilmediğine bağlı olarak değişir.
Allocation, RMAN'in multiplexing özelliğinin kullanılıp kullanılmadığına bağlı olarak değişir. Multiplexing RMAN'in birden çok datafaileden aynı anda okuma yaparak tek backup piece'e yazmasıdır. Image copy backup asla bu özelliği kullanmaz. Level of multiplexing, anlık olarak kaç dosyadan okuma yapılıp aynı backup piece'e yazılacağını belirler.
Number of files in each backup set : FILESPERSET parametresi ve bir rman channel tarafından okunabilen dosya sayısından minimum olanı bu değeri belirler. FILESPERSET'in default değeri 64'tür.
The level of multiplexing : MAXOPENFILES ve Number of files in each backup set değerlerinden daha küçük olanı bu değeri belirler. MAXOPENFILES'ın default değeri 8'dir.

Bir örnekle açıklayacak olursak; bir rman channel ile 12 datafile'ın backup'ını alıyor olalım. Number of files in each backup değeri 4, ve maxopenfiles değeri 8 olsun. Bu durumda levelof multiplexing değeri 4 olacaktır ve rman channel aynı anda 4 farklı datafiledan okuduğu blokları tek backup piece'e yazabilecektir.
Multiplexing özelliğinin, Input disk buffera nasıl etki ettiğini aş. tablodan inceleyebiliriz. 
Aşağıda gösterilen örnekte ise bir RMAN channel tarafından 4 datafile backup'ı alınıyor. MAXOPENFILES ve FILESPERSET değerleri 4 olarak set edilmiş ve dolayısıyla level of multiplexing değerimiz 4 oluyor. Bu durumda her datafile için 4 MB'lık bir buffer size allocate ediliyor. Allocate edilen toplam Input disk buffer ise 16MB'a denk geliyor.


Eğer bir channel ASMde depolanan dosyaların backupını alıyorsa number of input disk buffers ASM disk grupta yer alan fiziksel disk sayısına eşittir. Backup'ı alınan datafileın store edildiği disk grupta 16 fiziksel disk bulunuyorsa channel 16 input buffers allocate eder.

Synchronous and Asynchronous Disk I/O
Channel diskten okuma veya yazma yaparken I/O işlemi Synchronous veya Asynchronous olabilir. Disk I/O synchronous ise server process aynı anda yalnızca bir işlemi gerçekleştirebilir. Asynchronous I/O ise server process I/O işlemini başlattıktan sonra, bu işlemin tamamlanmasını beklerken başka işleri gerçekleştirebilir.
ASM diskgruptan okuma yapıyorsak, Asynchronous disk I/O kullanmalıyız. Yine aynı şekilde raw device üzerinden okuma yapıyorsak da asynchronous disk I/O kullanmalıyız.

Disk I/O slaves
Asynchronous I/O'nun desteklenmediği işletim sistemlerinde database tarafından özel I/O slave processleri kullanılır. Dinamik olmayan DBWR_IO_SLAVES parametresiyle değeri ayarlanabilir. Default değeri 0'dır. Asynchronous I/O disable durumda ise RMAN DBWR_IO_SLAVES parametresinin herhangi bir nonzero değeri için 4 slave process allocate eder.
I/O slave kullanılmaya çalışıldığında database aş. gibi davranır;
LARGE_POOL_SIZE parametresi set edilmiş durumda ve DBWR_IO_SLAVE parametresi naonzero bir değere sahip ise database large pooldan gerekli memory alanını almaya çalışır. Eğer bu alan yeteri kadar geniş değilse o zaman alert loga error kaydedilir, database shared pooldan memory kullanmaya çalışmaz ve asynchronous I/O kullanılmaz.
LARGE_POOL_SIZE parametresi set edilmemiş veya 0'a set edilmiş durumdaysa database shared pooldan memory kullanmayı dener.

RATE Channel Parameter
Allocate veya Configure Channel komutları kullanılırken RATE parametresi kullanılarak bir channel'ın okuyacağı bytes/second değeri verilebilir. Rman'ın bandwith'i doldurup online performansı düşürmemesi için bu parametre kullanılır.

Copy phase
Datanın input bufferdan output buffera kopyalandığı ve bloklar üzerinde ek processlerin gerçekleştirildiği fazdır. Write Phase; RMAN channels data bloklarını output bufferdan storage mediaya yazar. Burda bahsedilen ekstra işlemler; validation, compression, encryption işlemlerinden biri olabilir.

Write Phase
Data bloklarının output bufferdan, storage mediasına yazılması işlemi bu aşamada yapılır. Bu aşamada kullanılan media tipinin disk veya tape olmasına göre aş. gibi değişiklikler gözlemlenir.

Write Phase For SBT
SBT'ye backup alınırken, RMAN'den media managera doğru byte akışı başlar  ve bu byte streamine unique bir isim verilir. Media manager streamin nerede nasıl depolanacağı hakkında tüm bilgiye sahiptir.

RMAN Component Of Write Phase For SBT
Buffer allocation, slave processes ve synchronous / asynchronous I/O write fazında performansı etkileyen faktörlerdir.

Allocation of Tape Buffers
Tape üzerine backup alıyor yada tapeden restore işlemi yapıyorsak; database default olarak her rman channel için 4 buffer alanı allocate edecektir. Tape I/O buffer ise platforma bağlı olarak değişmektedir. ALLOCATE CHANNEL yada CONFIGURE CHANNEL komutunu kullanırken PARMS ve BLKSIZE parametreleri ile buffer size değerini değiştirebiliriz.













Tape I/O slaves 
Rman tape bufferı SGA veya PGAdan allocate eder. Bu durum I/O slave kullanılıp kullanılmamasına bağlı olarak değişir. BACKUP_TAPE_IO_SLAVES parametresi true olarak set edildiyse Rman bufferı SGA'dan allocate eder. LARGE_POOL_SIZE parametresi set edilmiş durumdaysa rman bufferı lorge pooldan allocate edecektir. BACKUP_TAPE_IO_SLAVES parametresi false olarak set edildiği takdirde rman bufferı PGA'dan allocate edecektir.
I/O slaves kullanıyorsak LARGE_POOL_SIZE parametresini set ettiğimiz takdirde bufferı large pooldan allocate edecektir.

Synchronous and Asynchronous I/O
Bir SBT channel tape'e okuma veya yazma yaparken I/O daima synchronousdur. Tape I/O işlemi için her channel bir server processe karşılık gelir ve channel process diye adlandırılır.
















İşleyiş şu şekildedir;
Channel process tape bufferı besler.
Channel process media manager layerını harekete geçirir ve bufferdaki bloklar yazılır.
Media manager Channel processe yazma işleminin başarılı olduğuna dair sinyal gönderir.
Ve sonraki buffera geçilir.

Media Manager Component of Write Phase for SBT

Network Throughput, tape device network üzerinden erişip data transferini gerçekleştirdiğimiz bir cihaz ise hızlı bir bağlantı üzerinden backup işlemlerini gerçekleştirmek performans açısından önemlidir.

Native transfer rate, sıkıştırma olmadan tape'e yazım hızıdır. Bu hız backup rate'in üst limitini gösterir.

Tape Compression, Tape device iyi bir sıkıştırma seviyesine sahipse backup performansı bundan olumlu olarak fazlasıyla etkilenir.

Physical Tape Block Size, Geniş block size'a sahip tape'ler backup performansını hızlandırır. Fiziksel tape'in block size'ı RMAN tarafından kontrol edilemez.

Write Phase For Disk
Backup işlemlerinde disk kullanıldığı takdirde performansı etkileyen en önemli faktör buffer sizedır. Her channel size'ı 1MB olan  4output buffer allocate eder. Rman diskten asynchronous okuma yapıyorsa diske yazma işlemi de asynchronous olmalıdır.


Rman performansını etkileyen faktörleri RMAN'in çalışma mantığıyla birlikte anlatmış olduk.

İyi çalışmalar..



Referanslar
https://docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmtunin.htm#BABFJAJIhttps://docs.oracle.com/cd/B28359_01/backup.111/b28270/glossary.htm#i432922http://salmandba.blogspot.com.tr/2014/05/rman-backup-performance.htmlhttps://dbasolutions.wikispaces.com/RMAN+Performance+Tuning





24 Temmuz 2015 Cuma

Non-CDB database'in PDB'ye convert edilmesi

Oracle 11gR2 sürümünden 12C'ye upgrade işleminden sonra artık elimizde 12C üzerinde çalışan Non-CDB bir databaseimiz var. 12C'de yeni gelen özelliklerden birtanesi olan pluggable databaseler hakkında geçtiğimiz aylarda bir yazı yazmıştım. (burdan erişebilirsiniz)
12C'de 3 farklı konfigürasyon yapabiliriz ihtiyacımıza göre;
Multitenant özelliklerinden faydalanmak istemiyorsak eski mimari ile alıştığımız 11g database özellikleri ile databaseimizi kurup yönetebiliriz.
İleride bu mimariye geçiş yapma ihtilamine karşılık 12c kurulumu esnasında 1 CDB ve 1PDB ile kurulumu gerçekleştirip, Multitenant architecture in single tenant konfigürasyonunu kullanabiliriz..Bu opsiyon için Multitenant lisans ücreti ödemiyoruz.
Son olarak ise multiple PDB per CDB olarak adlandırılan konfigürasyonla Multitenant özelliğini tam olarak kullanabiliriz,bu konfigürasyon için Multitenant lisansının olması gerekiyor..

Upgrade işleminden sonra biz ilk bahsedilen eski yapıdaki yani NON-CDB olan bir database'e sahibiz. Şimdi ise bu database'i Multitenant mimarisine uygun, pluggable bir database'e convert etmeye çalışalım.

oracle@db01-test ~$ sqlplus / as sysdbaSQL*Plus: Release 12.1.0.2.0 Production on Fri Jul 24 09:27:04 2015Copyright (c) 1982, 2014, Oracle.  All rights reserved.Connected to:Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit ProductionWith the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,Advanced Analytics and Real Application Testing options
SQL> select name, cdb from v$database;
NAME   CDB--------- ---ORCL   NO

 NON-CDB database'imizin adı ORCL, 2 nodelu 12.1.0.2 üzerinde koşuyor. Bu sistem üzerinde yeni bir Conteiner DB yaratıyoruz. DBCA yı çalıştırarak CDB database i oluşturuyoruz


Create database seçeneği ile yeni bir CDB yaratacağız.

 RAC database oluşturacağız.

 Container DB yaratacağımızı bu adımda belirtiyoruz aynı zamanda boş bir CDB yaratabilir yada bu işlemle birlikte bir de PDB yaratılmasını isteyebiliriz.

 Hangi nodelar üzerinde yaratacağımızı belirliyoruz.

 DB nin ASM diskini kullanması için gerekli ayarları bu aşamada yapıyoruz. Compatible.asm parametresi disk grubum için 11.2.0 olduğu için 12.1.0 DByi üzerinde depolamak için bu parametreyi aşağıdaki gibi update ediyoruz.

SQL> ALTER DISKGROUP DATADG SET ATTRIBUTE 'compatible.asm'='12.1';
Diskgroup altered.

 Automatic Memory Management kullanımı ve memory seçeneklerini belirledikten sonra artık kurulum aşamasına geçiyorum ve CDB'yi oluşturuyorum. Kurulum sonrası sqlplus ile instance'a bağlanıp kontrol ediyoruz;

oracle@db01-test ~$ . oraenv
ORACLE_SID = [CDBNEW1] ? 
The Oracle base remains unchanged with value /u01/app/oracle
oracle@db01-test ~$ sqlplus / as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Fri Jul 24 11:08:16 2015
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options
SQL> select name, cdb from v$database;                           

NAME  CDB
--------- ---
CDBNEW  YES

Şimdi NON-CDB veritabanımıza bağlanıp pluggable hale getirmek için gerekli konfigürasyonları yapıyoruz;

Databasei readonly modda açtıktan sonra PDB olarak convert etmek için gerekli xml file'ı oluşturmak için aşağıdaki sqli çalıştırıyoruz.

oracle@db01-test ~$ sqlplus / as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Fri Jul 24 11:11:35 2015
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount exclusive
ORACLE instance started.
Total System Global Area 2516582400 bytes
Fixed Size    2927528 bytes
Variable Size  738198616 bytes
Database Buffers 1761607680 bytes
Redo Buffers   13848576 bytes
Database mounted.
SQL> alter database open read only; 
alter database open read only
SQL> select status from v$instance;  
STATUS
------------
MOUNTED

SQL> alter database open read only;

Database altered.

SQL> exec dbms_pdb.describe(pdb_descr_file=>'/u01/app/oracle/product/12.1.0.2/db_2/noncdb.xml');

PL/SQL procedure successfully completed.

SQL> exit

Bu işlemden sonra CDBNEW veritabanına bağlanıp verilen xml dosyasını kullanarak DB dosyalarının kopyalanmadan orjinallerinin PDB olarak kullanılması seçeneğiyle işlemi yapıyorum. DB dosyalarının orjinallerinin kullanılmasını istemiyorsak file name convert parametresini ekleyerek orjinal dosyalarının birer kopyasının alınarak PDB oluşturulmasını sağlayabiliriz.


SQL> create pluggable database ORCL as clone using '/u01/app/oracle/product/12.1.0.2/db_2/noncdb.xml' nocopy;

Pluggable database created.

Kontrol ettiğimiz zaman PDBlerin durumu aş. gibidir. PDB'yi başlatmak için ise aş. komutu kullanabiliriz..

SQL> SELECT pdb_name, status
FROM   dba_pdbs
ORDER BY pdb_name;  2    3  

PDB_NAME
--------------------------------------------------------------------------------
STATUS
---------
ORCL
NEW

PDB$SEED
NORMAL

PDB1
NORMAL


SQL> ALTER PLUGGABLE DATABASE ORCL OPEN READ WRITE  ;

İyi Çalışmalar..



    23 Temmuz 2015 Perşembe

    Oracle 11gR2 Rac veritabanının 12C'ye upgrade edilmesi


    Merhaba, bu yazımda İki node'lu Oracle 11.2.0.3 RAC veritabanının 12.1.0.2 versiyonuna upgradeini anlatmaya çalışacağım.
    Bu upgrade işlemini iki adımda gerçekleştireceğiz. İlk adımda oracle grid yazılımının upgrade'ini yaparken ikinci adımda oracle database tarafının upgradeini yapacağız.
    http://docs.oracle.com/database/121/UPGRD/preup.htm#BABHGECA dökümanından fayadalanarak upgrade adımlarını detaylı şekilde inceleyebilirsiniz. Oracle database versiyonumuz, 12c sürümüne tek hamlede geçiş yapıp yapamayacağımız konusunda önemli. Bu yüzden Db upgrade path'i incelememizde fayda var. Aşağıdaki şemada 12c'ye geçiş için database'imizi bir ara versiyona yükseltmemiz gerekiyor mu kontrol ediyoruz. Benim Database versiyonum 11.2.0.3 (>11.2.0.2) olduğu için 12'ye direkt upgrade işlemini gerçekleştirebilirim..


    edelivery.oracle.com'dan oracle 12.1.0.2 grid yazılımını download ediyoruz. Rac sistem upgradeini rolling/non-rolling methodlarla yapabiliriz, biz rolling upgrade yapacağız, bu sayede bir node üzerinde upgrade işlemi yapılırken diğer node hizmet vermeye  edecektir. Upgrade işlemlerine başlamadan önce backuplarımızı alıyoruz. Yolunda gitmeyen bir durumda geri dönüşümüzü kolaylaştıracaktır.
    Grid yazılımını indirdikten sonra nodelar üzerinde gerekli dizinleri oluşturuyoruz. Dizinleri oluşturduktan sonra ise 12c grid yazılımını kuracağız. Bu dizinleri RAC sistemimizin çalıştığı iki sunucu üzerinde de oluşturuyoruz.

    # mkdir -p /u01/app/12.1.0.2/grid
    # mkdir -p  /u01/app/grid12c
    Kuruluma başlamadan önce ilgili OS user için aşağıdaki environment değişkenlerini unset ediyoruz.

    # unset ORACLE_HOME
    # unset ORACLE_BASE
    # unset ORACLE_SID
    # unset ORA_CRS_HOME

    Daha sonra indirdiğimiz dosyaları unzip ile açarak ./runInstaller komutunu çalıştırıyoruz ve kurulum başlıyor.

    İlk ekranda karşımıza gelen seçeneklerden Upgrade Oracle grid And ASM seçeneğini işaretliyoruz. Yeni bir grid home üzerine 12c yazılımını kurduktan sonra upgrade scriptlerini çalıştırarak kurulum sonrası upgrade işlemini de gerçekleştirmiş olacağız.



    Daha sonra gelen ekranda dil seçimi yaptıktan sonra next dediğimizde karşımıza RAC sistemimizin koştuğu nodelar gelecektir. Hali hazırda çalışan bir database'imiz olduğu için büyük ihtimalle SSH connectivity nodelar arasında sağlanmış durumdadır. 


    Management için Oracle Enterprise Manager kullanıyorsak yukarıdaki ekran yardımıyla yeni kurduğumuz grid yazılımını EM'e register edebiliriz.


    Kurulumdan önce yarattığımız yeni dizinleri yeni yazılımın kurulacağı lokasyonlar olarak belirliyoruz.


    Kurulum öncesi gereksinimler kontrol ediliyor, fixable olanlar için bize otomatik olarak parametre vb değerlerin değiştirilebileceği bir script yaratıyor bu scripti çalıştırarak varsa düzeltmemiz gereken bir değer kolayca düzeltebiliyoruz.

    Ve yukarıdaki özet sayfasını geçtikten sonra kurulum başlıyor. 

    Son adımda kurulum yaptığımız tüm nodelar üzerinde sırasıyla root userı ile rootupgrade.sh scriptini çalıştırıyoruz..Script sorunsuz bir şekilde çalıştığı zaman çıktısı aş. gibidir.

    root@db01-test app# sh /u01/app/12.1.0.2/grid/rootupgrade.sh 
    Performing root user operation.

    The following environment variables are set as:
        ORACLE_OWNER= crs
        ORACLE_HOME=  /u01/app/12.1.0.2/grid

    Enter the full pathname of the local bin directory: [/usr/local/bin]: 
    The file "dbhome" already exists in /usr/local/bin.  Overwrite it? (y/n) 
    [n]: 
    The file "oraenv" already exists in /usr/local/bin.  Overwrite it? (y/n) 
    [n]: 
    The file "coraenv" already exists in /usr/local/bin.  Overwrite it? (y/n) 
    [n]: 

    Entries will be added to the /etc/oratab file as needed by
    Database Configuration Assistant when a database is created
    Finished running generic part of root script.
    Now product-specific root actions will be performed.
    Using configuration parameter file: /u01/app/12.1.0.2/grid/crs/install/crsconfig_params
    2015/07/22 15:20:37 CLSRSC-4015: Performing install or upgrade action for Oracle Trace File Analyzer (TFA) Collector.

    2015/07/22 15:21:12 CLSRSC-4003: Successfully patched Oracle Trace File Analyzer (TFA) Collector.

    2015/07/22 15:21:17 CLSRSC-464: Starting retrieval of the cluster configuration data

    2015/07/22 15:21:30 CLSRSC-465: Retrieval of the cluster configuration data has successfully completed.

    2015/07/22 15:21:43 CLSRSC-515: Starting OCR manual backup.

    2015/07/22 15:21:47 CLSRSC-516: OCR manual backup successful.

    2015/07/22 15:21:53 CLSRSC-468: Setting Oracle Clusterware and ASM to rolling migration mode

    2015/07/22 15:21:53 CLSRSC-482: Running command: '/u01/app/12.1.0.2/grid/bin/asmca -silent -upgradeNodeASM -nonRolling false -oldCRSHome /u01/app/11.2.0/grid -oldCRSVersion 11.2.0.3.0 -nodeNumber 1 -firstNode true -startRolling true'


    ASM configuration upgraded in local node successfully.

    2015/07/22 15:22:08 CLSRSC-469: Successfully set Oracle Clusterware and ASM to rolling migration mode

    2015/07/22 15:22:08 CLSRSC-466: Starting shutdown of the current Oracle Grid Infrastructure stack

    2015/07/22 15:24:26 CLSRSC-467: Shutdown of the current Oracle Grid Infrastructure stack has successfully completed.

    OLR initialization - successful
    2015/07/22 15:30:33 CLSRSC-329: Replacing Clusterware entries in file '/etc/inittab'

    CRS-4133: Oracle High Availability Services has been stopped.
    CRS-4123: Oracle High Availability Services has been started.
    2015/07/22 15:38:06 CLSRSC-472: Attempting to export the OCR

    2015/07/22 15:38:06 CLSRSC-482: Running command: 'ocrconfig -upgrade crs oinstall'

    2015/07/22 15:38:33 CLSRSC-473: Successfully exported the OCR

    2015/07/22 15:38:40 CLSRSC-486: 
     At this stage of upgrade, the OCR has changed.
     Any attempt to downgrade the cluster after this point will require a complete cluster outage to restore the OCR.

    2015/07/22 15:38:40 CLSRSC-541: 
     To downgrade the cluster: 
     1. All nodes that have been upgraded must be downgraded.

    2015/07/22 15:38:40 CLSRSC-542: 
     2. Before downgrading the last node, the Grid Infrastructure stack on all other cluster nodes must be down.

    2015/07/22 15:38:40 CLSRSC-543: 
     3. The downgrade command must be run on the node db01-test with the '-lastnode' option to restore global configuration data.

    2015/07/22 15:39:11 CLSRSC-343: Successfully started Oracle Clusterware stack

    clscfg: EXISTING configuration version 5 detected.
    clscfg: version 5 is 11g Release 2.
    Successfully taken the backup of node specific configuration in OCR. 
    Successfully accumulated necessary OCR keys.
    Creating OCR keys for user 'root', privgrp 'root'..
    Operation successful.
    2015/07/22 15:39:41 CLSRSC-474: Initiating upgrade of resource types

    2015/07/22 15:40:10 CLSRSC-482: Running command: 'upgrade model  -s 11.2.0.3.0 -d 12.1.0.2.0 -p first'

    2015/07/22 15:40:10 CLSRSC-475: Upgrade of resource types successfully initiated.

    2015/07/22 15:40:17 CLSRSC-325: Configure Oracle Grid Infrastructure for a Cluster ... succeeded


    Upgrade işlemi tamamlandıktan sonra sqlplus ile DB'ye bağlanıp ASM versiyonunu kontrol edebiliriz;

    oracle@db01-test ~$ sqlplus / as sysdba
    SQL> select software_version from v$asm_client;
    SOFTWARE_VERSION
    ------------------------------------------------------------
    12.1.0.2.0

    Cluster upgrade tamamlandıktan sonra şimdi databasein kendisini upgrade edeceğiz. DB tarafında upgrade için Database Upgrade Assistant (DBUA), Manual Upgrade, Export/Import, Data Copying, Golden Gate gibi farklı yöntemler kullanılabilir. Ben upgrade işlemini out of place ve DBUA yöntemi ile gerçekleştirdim. Out of place upgrade yapılacağı için ilk adımda oracle database 12.1.0.2 sürümünü yeni oluşturacağımız bir dizine kuruyoruz.

    # mkdir  /u01/app/oracle/product/12.1.0.2/db_2
    12C için oracle home dizinini yarattıktan sonra kurulum dosyasını oracle user'ı ile unzip edip ./runInstaller'ı çalıştırıyoruz.


    Sadece Database yazılımını yükleyip herhangi bir database oluşturmayacağımız için install software db only seçeneğiyle devam ediyoruz.
     Sistemimiz RAC olduğu için Oracle Rac kurulumunu seçiyoruz.

     Cluster sistem üzerinde db yazılımının kurulacağı nodeları bu sekmede seçiyoruz, ssh connectivity sayesinde dosyalar diğer node'a kopyalanacaktır.

     Oracle 12C sürümü için yeni yarattığımız oracle home dizinini kurulum dizini olarak belirliyoruz ve devam ediyoruz.

    Gelen summary ekranından sonra kurulum başlıyor ve her iki node üzerinde root.sh scriptlerinin çalıştırılmasıyla 12C kurulumunu tamamlamış oluyoruz.

    Bu aşamadan sonra yapacağımız işlem 11.2.0.3 sürümünde çalışan databaseimizin yeni kurduğumuz 12.1.0.2 versiyonu üzerinde çalışmasını sağlamaktır.

    İlk olarak preupgrade scriptini çalıştırarak databasein upgrade için hazır olup olmadığı hakkında bir rapor üretiyoruz. preupgrade.sql scripti yeni kurulan oracle'ın home dizininde rdbms/admin/ altındadır. 11.2.0.3 instance'ımıza sqlplus ile bağlanıyoruz ve bu scripti çalıştırıyoruz. Script çalıştırıldıktan sonra oluşturulan checklist dosyasının dizinini de bize veriyor. Bu dosyadaki upgrade öncesi hazırlıklarına gözatıyoruz.

    SQL> @preupgrd.sql
    Loading Pre-Upgrade Package...
    ***************************************************************************
    Executing Pre-Upgrade Checks in ORCL...
    ***************************************************************************
          ************************************************************
      ====>> ERRORS FOUND for ORCL <<====

     The following are *** ERROR LEVEL CONDITIONS *** that must be addressed
       prior to attempting your upgrade.
       Failure to do so will result in a failed upgrade.

      You MUST resolve the above errors prior to upgrade

          ************************************************************

          ************************************************************

          ====>> PRE-UPGRADE RESULTS for ORCL <<====

    ACTIONS REQUIRED:

    1. Review results of the pre-upgrade checks:
     /u01/app/oracle/cfgtoollogs/ORCL/preupgrade/preupgrade.log

    2. Execute in the SOURCE environment BEFORE upgrade:
     /u01/app/oracle/cfgtoollogs/ORCL/preupgrade/preupgrade_fixups.sql

    3. Execute in the NEW environment AFTER upgrade:
     /u01/app/oracle/cfgtoollogs/ORCL/preupgrade/postupgrade_fixups.sql


    oracle@db01-test admin$ cat /u01/app/oracle/cfgtoollogs/ORCL/preupgrade/preupgrade.log
    Oracle Database Pre-Upgrade Information Tool 07-23-2015 10:41:15
    Script Version: 12.1.0.2.0 Build: 006
    **********************************************************************
       Database Name:  ORCL
      Container Name:  Not Applicable in Pre-12.1 database
        Container ID:  Not Applicable in Pre-12.1 database
             Version:  11.2.0.3.0
          Compatible:  11.2.0.0.0
           Blocksize:  8192
            Platform:  Linux x86 64-bit
       Timezone file:  V14
    **********************************************************************
                               [Update parameters]
             [Update Oracle Database 11.2.0.3.0 init.ora or spfile]
     
    --> If Target Oracle is 32-bit, refer here for Update Parameters:
    WARNING: --> "processes" needs to be increased to at least 300
     
    --> If Target Oracle is 64-bit, refer here for Update Parameters:
    WARNING: --> "processes" needs to be increased to at least 300
    **********************************************************************
    **********************************************************************
                              [Renamed Parameters]
                         [No Renamed Parameters in use]
    **********************************************************************
    **********************************************************************
                        [Obsolete/Deprecated Parameters]
                 [No Obsolete or Desupported Parameters in use]
    **********************************************************************
                                [Component List]
    **********************************************************************
    --> Oracle Catalog Views                   [upgrade]  VALID     
    --> Oracle Packages and Types              [upgrade]  VALID     
    --> JServer JAVA Virtual Machine           [upgrade]  VALID     
    --> Oracle XDK for Java                    [upgrade]  VALID     
    --> Real Application Clusters              [upgrade]  VALID     
    --> Oracle Workspace Manager               [upgrade]  VALID     
    --> OLAP Analytic Workspace                [upgrade]  VALID     
    --> Oracle Enterprise Manager Repository   [upgrade]  VALID     
    --> Oracle Text                            [upgrade]  VALID     
    --> Oracle XML Database                    [upgrade]  VALID     
    --> Oracle Java Packages                   [upgrade]  VALID     
    --> Oracle Multimedia                      [upgrade]  VALID     
    --> Oracle Spatial                         [upgrade]  VALID     
    --> Expression Filter                      [upgrade]  VALID     
    --> Rule Manager                           [upgrade]  VALID     
    --> Oracle Application Express             [upgrade]  VALID     
    --> Oracle OLAP API                        [upgrade]  VALID     
    **********************************************************************
                                  [Tablespaces]
    **********************************************************************
    --> SYSTEM tablespace is adequate for the upgrade.
         minimum required size: 1257 MB
    --> SYSAUX tablespace is adequate for the upgrade.
         minimum required size: 2032 MB
    --> UNDOTBS1 tablespace is adequate for the upgrade.
         minimum required size: 400 MB
    --> TEMP tablespace is adequate for the upgrade.
         minimum required size: 60 MB
    --> EXAMPLE tablespace is adequate for the upgrade.
         minimum required size: 309 MB

                          [No adjustments recommended]

    **********************************************************************
    **********************************************************************
                              [Pre-Upgrade Checks]
    **********************************************************************
    WARNING: --> Process Count may be too low

         Database has a maximum process count of 150 which is lower than the
         default value of 300 for this release.
         You should update your processes value prior to the upgrade
         to a value of at least 300.
         For example:
            ALTER SYSTEM SET PROCESSES=300 SCOPE=SPFILE
         or update your init.ora file.

    WARNING: --> Enterprise Manager Database Control repository found in the database

         In Oracle Database 12c, Database Control is removed during
         the upgrade. To save time during the Upgrade, this action
         can be done prior to upgrading using the following steps after
         copying rdbms/admin/emremove.sql from the new Oracle home
       - Stop EM Database Control:
        $> emctl stop dbconsole

       - Connect to the Database using the SYS account AS SYSDBA:

       SET ECHO ON;
       SET SERVEROUTPUT ON;
       @emremove.sql
         Without the set echo and serveroutput commands you will not 
         be able to follow the progress of the script.


    **********************************************************************
                          [Pre-Upgrade Recommendations]
    **********************************************************************

                            *****************************************
                            ********* Dictionary Statistics *********
                            *****************************************

    Please gather dictionary statistics 24 hours prior to
    upgrading the database.
    To gather dictionary statistics execute the following command
    while connected as SYSDBA:
        EXECUTE dbms_stats.gather_dictionary_stats;

    ^^^ MANUAL ACTION SUGGESTED ^^^


    **********************************************************************
                         [Post-Upgrade Recommendations]
    **********************************************************************

                            *****************************************
                            ******** Fixed Object Statistics ********
                            *****************************************

    Please create stats on fixed objects two weeks
    after the upgrade using the command:
       EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;

    ^^^ MANUAL ACTION SUGGESTED ^^^

    **********************************************************************
                       ************  Summary  ************

     0 ERRORS exist in your database.
     2 WARNINGS that Oracle suggests are addressed to improve database performance.
     4 INFORMATIONAL messages that should be reviewed prior to your upgrade.

     After your database is upgraded and open in normal mode you must run 
     rdbms/admin/catuppst.sql which executes several required tasks and completes
     the upgrade process.

     You should follow that with the execution of rdbms/admin/utlrp.sql, and a
     comparison of invalid objects before and after the upgrade using
     rdbms/admin/utluiobj.sql

     If needed you may want to upgrade your timezone data using the process
     described in My Oracle Support note 1509653.1
                       ***********************************

    Çalıştırdığım bu script sonucu datbase upgradeine başlamadan önce PROCESSES parametresini 300'e çekip, EM konfigürasyonunu kaldırıyorum. 
    DBUA'yı çalıştırıyoruz. karşılama ekranında upgrade oracle database seçeneğiyle devam ediyoruz.



     Bu ekranda sistemimiz üzerinde var olan databaseleri görüyoruz ve hangisini upgrade edeceğimizi seçerek devam ediyoruz.

     Bu adımda bize bize yine upgrade öncesi bir checklist yaratıyor. Biz upgrade öncesi sqlplus ile gerekli değişiklikleri yaptığımız için herhangi bir warning yada error çıkmıyor karşımıza.

     Bu adımda upgrade ile ilgili bazı seçenekler sunuluyor, timezone upgrade edilsin mi, upgrade sırasında user tablespaceler readonly moda alınsın mı, upgrade öncesi istatistik toplansın mı gibi..

     EM configürasyonu yapmak istiyorsak yada var olan EM'e kaydetmek istiyorsak bu seçenekleri kullanıyoruz.


    Olumsuz bir durumda upgrade işlemini geri almak için bir backup belirleyebiliriz yada kendi stratejim var diyerek upgrade işlemi başarısız olursa manuel olarak backuptan dönme seçeneğini işaretleyebiliriz.Bu adımdan sonra upgrade işlemi başlıyor. Başarılı bir şekilde tamamlanan upgrade işlemi tamamlanıyor ve işlemin sonucunu aşağıdaki adımda görebiliyoruz.




    Upgrade işlemi sonrası database'imiz 12C mimarisinde non-CDB olarak bilinen yapıda çalışıyor. İstenildiği takdirde bu database'imizi upgrade işlemi sonrasında Pluggable database'e convert edebiliriz. Bu işlemi bir sonraki gönderide paylaşacağım.

    Database'e sqlplus ile bağlanıp versiyon bilgisini kontrol ettiğimiz zaman 12.1.0.2 olarak görülüyor.
    oracle@db01-test admin$ sqlplus / as sysdba

    SQL*Plus: Release 12.1.0.2.0 Production on Thu Jul 23 13:34:38 2015
    Copyright (c) 1982, 2014, Oracle.  All rights reserved.
    Connected to:
    Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
    With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
    Advanced Analytics and Real Application Testing options


    İyi Çalışmalar

    http://docs.oracle.com/database/121/UPGRD/toc.htm
    www.oracle.com/technetwork/database/upgrade/upgrading-oracle-database-wp-12c-1896123.pdf

    19 Temmuz 2015 Pazar

    Oracle's Optimal Flexible Architecture (OFA)


    Oracle ile ilgilenen herkes OFA diye bir standartın var olduğunu az çok bilir. Peki standart tam olarak nedir? Cary Millshap tarafından Oracle for Open Systems makalesinde yayımlanmış olan bir standarttır. Makalenin 1995 yılında yayımlanan orjinal haline linkten  ulaşabilirsiniz. Çoğu kurulumda yada gündelik işlerimizde kullandığımız bu maddeler ustalarımızdan öğrenip uyguladığımız birer alışkanlık gibi görünse de aslında temeli bu standarta dayanmaktadır.

    1. Unix mount point isimleri  /mountpoint adı + numara şeklinde olmalı. /u01, /u02, /u03

    2. Oracle OS user'ı ORACLE_HOME dizinin sahibi olmalı. /mountpoint/directory/user örneğin /u01/app/oracle

    3. Komut satırından yaptığımız hardcode path tanımları yerine Environment değişkenleri kullanılmalı. 

    4. Her  ORACLE_HOME dizini belirli bir kalıba göre yaratılmalı. /oracle_user_home_directory/product/ versiyon Örneğin /u01/app/oracle/product/11.2.0/dbhome_1

    5. Environmentları ayarlamak için unix profile ve oracle-supplied filelar kullanılmalı.

    6. Bir instance $ORACLE_HOME, $ORACLE_SID ve $HOST_NAME kombinasyonu ile tanımlanmalı.

    7. Datafileların isimlendirilmesinde tablespace_name+number.dbf standartı kullanılmalı, aynı zamanda ORACLE_SID de eklenebilir..

    8. Aynı anda yedeklenen yada aynı amaç için kullanılan db objeleri aynı tablespacede yer almalı. 

    9. Tablespace isimleri 8 karakterle sınırlandırılmalı. (datafile'ına isim verirken zorluk yaşamamak için)

    19 Ocak 2015 Pazartesi

    Oracle 12C In-memory Opsiyonu

    Oracle 12.1.0.2 sürümüyle yeni gelen özelliklerden birtanesi In-Memory opsiyonudur.Tablo, partition yada diğer database objelerinin memory'de tutulmasını sağlar. SGA içerisinde data alışılageldik row formatında değil, Column based olarak tutulur. Tek database üzerinde verilerimizin hem row hem de in memory opsiyonu sayesinde column based olarak tutulması, bize OLTP işlemlerinin yanısıra Analitik işlemleri de performanslı biçimde yapma avantajı kazandırır. Oracle Exalytics ürününü piyasaya çıkardığı yıllarda timesten adı verilen in-memory database sayesinde raporlama datasını memory'den çekerek BI alanında performans bakımından büyük bir adım atmıştı. Exalyticsin bir engineered system olması sebebiyle maliyeti çok yüksekti. 12C ile gelen in-memory opsiyonu sayesinde raporlama işlemlerimizde OLTP veritabanımızı kullanırken Performans bakımından büyük kazanımlar elde etmiş oluyoruz.

    In-memory opsiyonu kullanırken DB buffer cachede tutulan data değiştirilmez,SGA içerisinde yeni bir pool'a istenilen data columnar formatta tutulacak şekilde depolanır. In-memory opsiyonuyla, memoryde tutulan objelerin tekrar DBbuffer cache load edilmesi gereksizdir. Bu opsiyonla sıkıştırılmış veri içerisinde arama yapılabiliyor. Column format sıkıştırma işlemlerini çok performanslı yapabildiği gibi, bir değer önemli avantajıda; donanımın uyumlu olması halinde SIMD vector proccessing'i kullanmasıdır.
    SIMD vector Proccessing (Single Instraction Proccessing Multiple Data Value) : SIMD destekli işlemcilerde 32 bitlik 1 register, 8bitlik 4 register gibi davranır.

    In-memory özelliği ile SGA içerinde önceden varolan buffercahce vb memory alanlarında bir değişiklik olmazken,bu özellik için oracle mimarisine dahil edilen ekstra proces, parametre ve memory alanları mevcuttur. INMEMORY_SIZE parametresini 0'dan farklı bir değere set ettiğimiz zaman bu özellik database'imiz için aktif hale gelmekle birlikte bu parametre, SGA içerisinde memory'e alınacak dataların tutulduğu IN-MEMORY COLUMN STORE alanının size'ını da belirlemiş olur. IMCO(in-memory coordinater) backgorund process'i ise memory'de tutulmasını istediğimi dataları SGA'nın ilgili in-memory column store alanına load eder,her iki dakikada memoryde tutulan datanın refresh edilmesini sağlar, bu processe bağlı SMCO(Space Management Coorinater Process) background processi ve workerlar bulunur.
    Datanın memory'e alınması instance restart edildiğinde yada ilgili dataya erişildiğinde yapılabilir. Database instance başlatıldığı sırada memory'e alınmış data diskten tekrar okunarak in-memory column alanına yeniden yüklenmesi gerekir. Rac databaselerde birden fazla instance mevcuttur ve dolayısıyla instance sayısı kadar IMcolumn store alanı olacaktır. Bir tabloyu memory de tutmak istediğimiz zaman default olarak NO DUPLICATE opsiyonuyla tablonun datası instance'lardan sadece birtanesinin IMcolumn store alanında tutulmak üzere memory'e alınır. Bu sayede partition'lı bir tablomuzun bir partition'ını instance 1'de tutarken, diğer partition'ını ise instance 2'de depolanacak şekilde memory alanına alabiliriz. Yada DUPLICATE opsiyonuyla tabloyu memory'e aktarırken tüm instancelardaki IMcolumn store alanına aynı datanın yüklenmesini sağlayabiliriz.

    Hangi Datanın memroy'e daha önce alınacağını Priorty özelliğini set ederek belirleyebiliriz. Bir objeyi memory'e almak için ilk önce INMEMORY_SIZE parametresini set ederek bu opsiyonu aktif hale getiriyoruz. Statik bir parametre olduğundan restart ettikten sonra bu değişiklik aktif hale gelecektir. Bu tanımlamayı yaparken SGA boyutuna dikkat etmemiz gerekiyor.
    ALTER SYSTEM SET INMEMORY_SIZE=200M SCOPE=SPFILE


    Yukarıda gördüğümüz gibi, bu opsiyonu aktif hale getirdikten sonra databasei açtığımızda SGA altında artık In-Memory Area adı altında bir alanımız da bulunuyor.Şu anda bu bellek bölgesinde herhangi bir data store edilmemektedir. Instance startup'ında bu alana istediğimiz obje datasının load edilmesi için PRIORITY özelliğini set etmeliyiz demiştik. PRIORITY seçeneklerine bakacak olursak;
    NONE: Hiçbir öncelik tanımlamazsak full scan yapan bir sorgu gelmeden memory'ye alınmayacaktır.
    LOW:instance başlatıldığı anda memory'ye yüklenecektir.
    MEDIUM:instance başlatıldığı anda memory'ye yüklenecektir.
    HIGH:instance başlatıldığı anda memory'ye yüklenecektir.
    CRITICAL:instance başlatıldığı anda memory'ye yüklenecektir.  İnstance başlangıcında memorye alınma önceliği tahmin edileceği gibi CRITICAL, HIGH, MEDIUM, LOW şeklindedir

    Inmemory opsiyonunu aktif hale getirdikten sonra bir tabloyu nasıl inmemory'e alabileceğimize bakalım. v$im_segments'den memory'deki objeleri sorgulayabiliriz.
    SQL> select owner,segment_name,inmemory_size,bytes,bytes_not_populated,populate_status from v$im_segments;
    no rows selected

    SQL> alter table oe.customers inmemory priority critical;
    Table altered.
    SQL> select owner,segment_name,inmemory_size,bytes,populate_status from v$im_segments;

    OWNER    SEGMENT_NAME   INMEMORY_SIZE BYTES      POPULATE_STATUS
    ------------
    OE                  CUSTOMERS 1179648   131072        COMPLETED
    Priorty özelliğini none olarak tanımladığımızda ise tabloya full table scan yapan bir sorgu geldikten sonra tablo memoryye alınır..Burda instance restart edildiği zaman memory sıfırlanacak, tekrar bir sorgu gelemeyene kadar oe.customers tablosu memorye load edilmeyecektir.
    SQL> alter table oe.customers inmemory priority none;
    Table altered.
    SQL> select owner,segment_name,inmemory_size,bytes,bytes_not_populated,populate_status from v$im_segments;
    no rows selected

    SQL> select * from oe.customers;

    SQL> select owner,segment_name,inmemory_size,bytes,populate_status from v$im_segments;

    OWNER    SEGMENT_NAME   INMEMORY_SIZE BYTES      POPULATE_STATUS
    ------------
    OE               CUSTOMERS 1179648   131072        COMPLETED

    Memoryde tutulan bir objenin priority'sinin ne olduğunu öğrenmek için ise aşağıdaki sorguyu kullanabiliriz.

    SQL> SELECT OWNER, SEGMENT_NAME, INMEMORY_PRIORITY, INMEMORY_COMPRESSION FROM V$IM_SEGMENTS;

    Bir objenin artık memory'de tutulmasını istemiyorsak  NO INMEMORY sql'ini kullanabiliriz.

    SQL> alter table oe.customers  NO INMEMORY;

    Memory'de tutulacak datayı table olarak belirleyebildiğimiz gibi,bu seçimi kolon bazında da yapabiliriz. İstediğimiz tablonun sadece tutulmasını istediğimiz kolonları için in-memory özelliğini aktif hale getirebiliriz.Önce ilgili tabloyu memory'ye almamız gerekiyor.

    SQL> alter table oe.customers INMEMORY;

     SQL> alter table oe.customers
    (CUST_ADDRESS,PHONE_NUMBERS,NLS_LANGUAGE,NLS_TERRITORY,CREDIT_LIMIT,CUST_EMAIL)
     INMEMORY MEMCOMPRESS FOR CAPACITY HIGH (CUSTOMER_ID,CUST_FIRST_NAME,CUST_LAST_NAME)
     INMEMORY MEMCOMPRESS FOR QUERY HIGH (ACCOUNT_MGR_ID,CUST_GEO_LOCATION,DATE_OF_BIRTH)
     NO INMEMORY (MARITAL_STATUS,GENDER,INCOME_LEVEL);

    Memory'ye aldığımız tablonun kolonlarını aşağıdaki sorgu ile v$im_column_level'dan sorguladığımız zaman aşağıdaki sonucu elde ediyoruz.

    Compression metodlarından bahsedecek olursak;
    NO MEMCOMPRESS: Memoryde tutulacak data üzerinde herhangi bir sıkıştırma uygulanmaz
    MEMCOMPRESS FOR DML: Datayı DML operasyonları için optimize edecek şekilde sıkıştırır. En az sıkıştırma oranı bu metodda uygulanır.
    MEMCOMPRESS FOR QUERY LOW: En iyi query performasını elde edecek şekilde sıkıştırma yapar.Datayı MEMCOPRESS FOR DML'den daha fazla sıkıştırır.
    MEMCOMPRESS FOR QUERY HIGH: QUERY LOW'dan daha yüksek performans sağlar. Datayı query lowdan fazla, memcompress for capacity low metodundan daha az bir sıkıştırma oranı ile sıkıştırır.
    MEMCOMPRESS FOR CAPACITY LOW: İyi bir query performansına sahip olmasının yanında yüksek bir sıkıştırma oranına da sahiptir. Memcompress For query high'dan fazla, memcompress for capacity high'dan daha az sıkıştırma yapar.
    MEMCOMPRESS FOR CAPACITY HIGH: Bu metodda ise en yüksek oranda data sıkıştırması yapılır.

    Aşağıdaki sorgu yardımıyla memorydeki tablonun sıkıştırma methodu ve sıkıştırma oranı hakkında bilgi edinebiliriz..

    SQL> select segment_name, bytes Disk, inmemory_size, populate_status, inmemory_compression COMPRESSION,  bytes / inmemory_size comp_ratio from v$im_segments;

    inmemory_clause_default parametresi IN MEMORY sql'ini kullandığımız zaman default olarak hangi opsiyonlarla bu özelliği aktif hale getireceğimizi belirler. Yani bu parametreyi aşağıdaki gibi set ettiğimizi düşünürsek her bir IN MEMORY cümlesinde default olarak sıkıştırma methodunu query high olarak belirleyecektir..

    SQL> alter system set inmemory_clause_default="INMEMORY MEMCOMPRESS FOR QUERY HIGH" ;


    12C In-memory opsiyonunun karşılaştırmalı performans incelemesi için ise Gökhan Atıl'ın 12C In-Memory sunumunu bu linkten ineceleyebilirsiniz..


    Kaynaklar:
    http://docs.oracle.com/database/121/ADMIN/memory.htm#ADMIN00207
    Gökhan ATIL 12C IN-MEMORY Sunumu (Troug Ankara Etkinliği - http://www.slideshare.net/gokhanatil/oracle-12c-database-in-memory)
    http://oracle-base.com/articles/12c/in-memory-column-store-12cr1.php


    12 Ocak 2015 Pazartesi

    Oracle 12C Yeni CDB ve PDB Oluşturma

    Oracle 12C'de kurulum esnasında bir CDB ve PDB oluşturabildiğimiz gibi kurulumdan sonra da birden çok yöntemle Container Database ve Pluggable Database oluşturabiliriz.

    1) Kurulum Esnasında OUI ile;
    Bildiğimiz 11gR2 OUI'ından farklı olarak aşağıdaki ekranlar eklenmiş ve burdaki seçenekler yardımıyla multitenant özelliğini kullanıp kullanmayacağımızı belirleyebiliyoruz..Kuruluma başladığımız sırada Create and Configure Database seçimiyle devam ettiysek, database oluşturma adımında bizden bir SID istiyor ve bunu Container Database (CDB) olarak kullanıp kullanmayacağımızı soruyor. Eğer CDB olarak oluşturacaksak, altında bir Pluggable database de oluşturuyoruz..



    2) DBCA ile CDB yaratılması
    Aynı şekilde komut satırından dbca komutu ile database configuration assistant'ı çalıştırdığımız zamanda OUI'da yarattığımız şekilde CDB ve PDB oluşturuyoruz. Ancak dbca aracı bize database hakkında daha fazla seçenek sunuyor. DBCA'yı çalıştırdıktan sonra create database seçeneğiyle ilerlediğimizde aşağıdaki ekranda database'in özelliklerini belirliyoruz.CDB yada non-CDB bir database oluşturabiliyoruz.


    Bunun haricinde advance modu seçtiğimiz zaman ise Oluşturacağımız container Database içinde birden fazla Pluggable database oluşturabiliyoruz.Yine burdan istersek boş bir container Database yaratma seçeneği ile devam edebiliyoruz..


    3) CDB'nin Manuel Yaratılması
    Oracle tarafından önerilen, bu işlemin DBCA ile  yapılmasıdır. Ancak manuel olarak sqlplus yardımı ile CDB oluşturmak mümkündür..Sqlplusa bağlanıp nomount adımda database'i başlattıktan sonra CREATE DATABASE keywordü ile CDB'yi yaratıyoruz. Burda system,sysaux,temp ve undo tablespaceleri için Datafileları tanımlıyoruz.Daha sonra karakter seti ve log dosyaları set ediliyor.Bunlar zaten şimdiye kadar manuel DB yaratırken kullandığımız parametrelerdi. Non-CDB veritabanı yaratırken yaptığımız işlemlerden farkı ise;
    ENABLE PLUGGABLE DATABASE cümlesiyle yaratıığımız database'in bir container DB olduğunu söylüyor ve multitenant özelliğini kazandırıyoruz..

    SET VERIFY OFF
    connect "SYS"/"&&sysPassword" as SYSDBA
    set echo on
    spool /u01/app/oracle/admin/cdb1/scripts/CreateDB.log append
    startup nomount pfile="/u01/app/oracle/admin/cdb1/scripts/init.ora";
    CREATE DATABASE "cdb1"
    MAXINSTANCES 8
    MAXLOGHISTORY 1
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 1024
    DATAFILE '/u01/app/oracle/oradata/cdb1/system01.dbf' SIZE 700M REUSE
      AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED
      EXTENT MANAGEMENT LOCAL
    SYSAUX DATAFILE '/u01/app/oracle/oradata/cdb1/sysaux01.dbf' SIZE 550M REUSE
      AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED
    SMALLFILE DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE '/u01/app/oracle/oradata/cdb1/temp01.dbf' SIZE 20M REUSE
      AUTOEXTEND ON NEXT  640K MAXSIZE UNLIMITED
    SMALLFILE UNDO TABLESPACE "UNDOTBS1" DATAFILE  '/u01/app/oracle/oradata/cdb1/undotbs01.dbf' SIZE 200M REUSE
      AUTOEXTEND ON NEXT  5120K MAXSIZE UNLIMITED
    CHARACTER SET AL32UTF8
    NATIONAL CHARACTER SET AL16UTF16
    LOGFILE GROUP 1 ('/u01/app/oracle/oradata/cdb1/redo01.log') SIZE 50M,
    GROUP 2 ('/u01/app/oracle/oradata/cdb1/redo02.log') SIZE 50M,
    GROUP 3 ('/u01/app/oracle/oradata/cdb1/redo03.log') SIZE 50M
    USER SYS IDENTIFIED BY "&&sysPassword" USER SYSTEM IDENTIFIED BY "&&systemPassword"
    enable pluggable database
    seed file_name_convert=('/u01/app/oracle/oradata/cdb1/system01.dbf','/u01/app/oracle/oradata/cdb1/pdbseed/system01.dbf',
                            '/u01/app/oracle/oradata/cdb1/sysaux01.dbf','/u01/app/oracle/oradata/cdb1/pdbseed/sysaux01.dbf',
                            '/u01/app/oracle/oradata/cdb1/temp01.dbf','/u01/app/oracle/oradata/cdb1/pdbseed/temp01.dbf',
                            '/u01/app/oracle/oradata/cdb1/undotbs01.dbf','/u01/app/oracle/oradata/cdb1/pdbseed/undotbs01.dbf');
    spool off

    4)DBCA ile PDB oluşturulması
    DBCA'yı başlattıktan sonra Seçeneklerden Manage Pluggable database seçeneği ile devam ediyoruz.Aşağıdaki ekran karşımıza çıkıyor.Burda Pluggable database ile alakalı, create, delete, unplug ve configure işlemlerimizi gerçekleştirebiliyoruz.Create PDB seçeneğini seçtikten sonraki ekranda Container Database'lerin bir listesi geliyor ve hangi CDB için PDB yaratacağımızı seçiyoruz. Daha sonra bize iki seçenek sunuyor ya unplug edilmiş bir PDB'yi plug ediyoruz, yada yeni bir PDB oluşturuyoruz.


    PDB'nin manuel olarak yaratılması ise create pluggable database cümlesi ile olur..

    Yukarıdaki şemada bir PDB'nin yaratılma yöntemleri gözlemlenebilir.Bir PDB yaratırken kopyalama yada plugin yöntemlerinden bir tanesi kullanılır. Kopyalama yönteminde CDB içerisindeki SEED'den dosyalar kopyalanır hazır bir templateden PDB oluşturulur. Yada Database Clone işlemlerinde olduğu gibi uzak bir sunucudan yada lokalde bulunan bir CDB yahut non-CDB'nin klonlanmasıyla PDB oluşturulabilir. Plugging in yönteminde ise başka bir ortamdan unplug edilen bir PDB plug edilebilir yada Non-CDB bir database PDB olarak plug edilir..

    PDB$SEED'den Pluggable Database oluşturulması; 
    Mimari ile ilgili yazımda (bu linkten ulaşabilirsiniz ) CDB içerisindeki root ve seed kavramlarından bahsederken PDB$SEED için yeni pluggable database'ler oluştururken bu templatedendosyalar kopyalanır demiştik. Yukarıda CDB'nin manuel yaratılması scriptinde seed file'lar içinde lokasyon belirtiliyor dikkat edilirse. Bu sayede rootun yanında PDB$SEED template'i de oluşturulmuş oluyor. CREATE PLUGGABLE DATABASE cümlesiyle oluşturduğumuz PDB, PDB$SEED' deki file'ların kopyalanması yani template yardımıyla oluşturulur.


    CREATE PLUGGABLE DATABASE pdbnew ADMIN USER pdb_vy IDENTIFIED BY password FILE_NAME_CONVERT=('/u01/app/oracle/oradata/cdbvy/pdbseed/','/u01/app/oracle/oradata/cdbvy/pdbnew/');

    Pluggable databaseleri aşağıdaki gibi sorguladığımızda yeni oluşturduğumuz PDB'yi göreceğiz

    SELECT pdb_name, status
    FROM   dba_pdbs
    ORDER BY pdb_name;

    PDB_NAME      STATUS
    -------------------- -------------
    PDB$SEED      NORMAL
    PDB1       NORMAL
    PDBNEW       NEW

    Status NEW olarak geliyor, PDByi açtığımız zaman Status normal olarak değişecektir. PDB'yi read write mode'a çekmek için;

    ALTER PLUGGABLE DATABASE pdbnew OPEN READ WRITE;

    Bir PDB yada Non-CDB'nin Clone'u yardımıyla Pluggable Database oluşturulması
    CREATE PLUGGABLE DATABASE pdb1new from pdbsource;
    cümlesiyle bir PDB'den yada Remote non-CDB'den Pluggable database yaratabiliriz. Burda da  mantık olarak source dosyaların yeni bir lokasyona kopyalanması ile PDB yaratılıyor.

    Plugging-Unplugging yöntemiyle bir PDB oluşturulması
    PDB unplug durumdayken kendi datafilelarının yanında bir de XML metadata dosyası içerir.Bu XML dosyası yardımıyla yeni PDB'yi oluşturuyoruz..
    PDB'yi manuel olarak unplug etmek için aşağıdaki komut kullanılır.

    ALTER PLUGGABLE DATABASE pdbnew CLOSE;
    ALTER PLUGGABLE DATABASE pdbnew UNPLUG INTO '/u01/app/oracle/oradata/cdbvy/pdbnew/pdbnew.xml';

    Aşağıdaki komutla PDB'yi unplug edilmiş PDB'den oluşturuyoruz..

    CREATE PLUGGABLE DATABASE pdbnew2 USING '/u01/app/oracle/oradata/cdbvy/pdbnew/pdbnew.xml'  FILE_NAME_CONVERT=('/u01/app/oracle/oradata/cdbvy/pdbnew/','/u01/app/oracle/oradata/cdbvy/pdbnew2/') ;


    Non-CDB'den bir PDB oluşturulması; 
    12c üzerine veritabanımızı multinenant özelliklerini kullanmadan oluşturduysak ve sonradan Multinenant yapısına geçmeye karar verdiysek bizim için en uygun seçenek bu olacaktır.
    Var olan non-CDB database üzerinde DBMS_PDB.DESCRIBE fonksiyonunu çalıştırıyoruz ve bize bir XML metadata dosyası yaratıyor bu database ile ilgili. Yukarıdaki gibi bu xml dosyasındanPDB'yi oluşturuyoruz.
    Başka bir yöntem olarak datapump'ı kullanarak datalarımızı oluşturduğumuz yeni bir PDB içerisine aktarıyoruz.
    Veya Goldengate replikasyonu kullanarak bu işlemi yapabiliyoruz..
    Bu yöntemlerin dışında PDB oluşturmak- taşımak için SQLdeveloper ve EM 12c'yi de kullanabiliriz.


    Pluggable Database'lerin başlatılması;
    12C'de Container database'i kapattığımız zaman öncesinde tüm PDB'ler kapatılıyor..Ancak Startup komutunu verdiğimiz zaman sadece container DB açılıyor. PDBler'in açılmasını ise aşağıdaki gibi bir trigger yazarak sağlayabiliriz..


    CREATE OR REPLACE TRIGGER open_pdbs 
      AFTER STARTUP ON DATABASE 
    BEGIN 
       EXECUTE IMMEDIATE 'ALTER PLUGGABLE DATABASE ALL OPEN'; 
    END open_pdbs;
    /

    Kaynaklar:
    Oracle Database Concepts 12c Release 1 (12.1)
    http://oracle-base.com/articles/12c/multitenant-startup-and-shutdown-cdb-and-pdb-12cr1.php

    7 Ocak 2015 Çarşamba

    Oracle 12c Multitenant Mimarisi

    Oracle veritabanı 12c sürümüyle gelen en önemli yeniliklerden birtanesi Multitenant mimarisidir.. Basitçe, container adı verilen bir instance'ın pluggable birden çok veritabanını barındırması mantığına dayanıyor. Multitenant container database sıfır,bir veya daha çok user created pluggable database'i barındırabilir. PDB(pluggable database) ise schemaların, schema objelerinin ve nonschema objelerin portable bir koleksiyonu olarak adlandırılabilir.

    12c sürümünde kullanabileceğimiz 3 farklı konfigürasyon tipi vardır;

    • Multitenant özelliklerinden faydalanmak istemiyorsak eski mimari ile alıştığımız 11g database özellikleri ile databaseimizi kurup yönetebiliriz.
    • İleride bu mimariye geçiş yapma ihtilamine karşılık 12c kurulumu esnasında 1 CDB ve 1PDB ile kurulumu gerçekleştirip, Multitenant architecture in single tenant konfigürasyonunu kullanabiliriz..Bu opsiyon için Multitenant lisans ücreti ödemiyoruz.
    • Son olarak ise multiple PDB per CDB olarak adlandırılan konfigürasyonla Multitenant özelliğini tam olarak kullanabiliriz,bu konfigürasyon için Multitenant lisansının olması gerekiyor..


    CDB içerisindeki Container, PDB yada root container(root olarak da adlandırılır) olabilir..Container; schema, obje ve CDB içerisindeki ilişkisel yapılardan oluşur. CDB içerisindeki her container unique bir ID ve isme sahiptir..Container aynı zamanda tenant olarak da adlandırılır. Her CDB aşağıdakilere sahiptir;
    • Root; oracle-supplied metadata ve common userları tutar..Root container CDB$ROOT olarak adlandırılır..Root user datasını tutmaz.
    • Seed PDB; yeni PDB yaratmak için kullanılabilen system-supplied templatedir. PDB$SEED olarak adlandırılır. Seed PDBye obje eklenemez ve var olan objeleri değiştirilemez..
    • Zero or more user-created PDB; Pluggable dblerdir. CDB oluşturulduğunda otomatik olarak oluşturulmaz, kendi gereksinimimize göre PDB'ler yaratabiliriz. PDBler application datasını tutmak, datayı farklı bir CDB'ye taşımak amacıyla kullanılabilir..
    Aşağıdaki şemada gördüğümüz CDB altında root, seed ve iki adet PDB bulunmaktadır. Her PDB'i kendi uygulamasına hizmet vermektedir. Her PDB'nin kendi administrator'ı bulunmaktadır. CDB administrator user'ı herbir PDB'yi yönetebilir..Fiziksel seviyede bakıldığı zaman CDB önceden var olan non-cdb databaseler gibi bir instance ve databasefile'lara sahiptir..Multitenant yapıda Background processleri, shared memory ve Oracle Metadata, redolog,controlfile ve undo tablespaceleri ortaktır. PDBlerde ise application data ve tablespaceleri,Local user ve roller ve local metada tutulur.Gerekli görüldüğü takdirde PDB bazında temp tablespaceler tanımlanabilir.

    The Root

    Multitenant Mimarinin Sağladıkları 
    • Cost Reduction : Kaynakların PDBler arasında paylaşımlı kullanılması maliyeti azaltır.daha az fiziksel sunucu ve daha az yönetim maliyeti ortaya çıkar..
    • Easier and More rapid movement of data : PDB'yi unplug edip başka bir CDB altına plug ettiğimiz zaman datanın hızlı bir şekilde taşınmasını sağlamış oluruz. Plıg/ungplug tekniği transportable tablespace mantığına oldukça yakındır..
    • Easier management and monitoring of the physical db : Non-cdb databaseler'de birçok fiziksel database'in yönetimi ve monitorü zorluğunu ortadan kaldırır. Fiziksel dosyaların ortak kullanımı sayesinde yönetimsel olarak daha az enerji harcanmasını sağlar..
    • Ease of performance tuning : Tek database'in performans metriclerinin toplanacağı için performans tuning işlemlerini kolaylaştırır.
    • Patches and Upgrade : CDB'ye uygulanacak patchler var olan tüm PDB'leri etkileyecektir.

    Naming For PDB
    Unique bir adı olmalıdır.PDB kendisiyle aynı isme ait servicename'e sahip olacaktır.PDB'ler ayrı namespace'lere sahiptir. Ayrı PDB'lerde aynı isme sahip şemalar bulunabilir. Objeler ise PDB içinde unique name'e sahip olmalıdır.

    Data Dictionary Architecture
    CDB içerisindeki her containerın data dictionarysi ayrıdır.Mesela DBA_OBJECTS viewine bir select attığımız zaman farklı PDB'ler için farklı sonuçlar döndürebilir.Dictionarylerin farklı olması sayesinde Her PDB'nin birbirinden ve roottan bağımsız yönetilmesi sağlanır.

    Yeni yaratılmış henüz data içermeyen bir non-CDB databasede data dictionary sadece sistem metadatasını içerir. Örneğin  TAB$ tablosu şu an sadece oracle supplied table'ları içerir.Aşağıdaki grafikte kırmızı çizgiler bu sistem kayıtlarını göstermektedir.

    Non-CDB bir database oluşturduktan sonra user kendi objelerini yaratmaya başladığı zaman, oracle-supplied kayıtların yanında user-created objeler içinde dictionary'de kayıtlar tutulmaya başlanacaktır.


    Şimdi CDB bir databasede durumun nasıl olduğuna bakarsak; Data dictionary metadata root ve PDB'ler arasında ayrılmıştır.User data PDB'de tutulur. PDB'nin usercreated objelerin metadatası tutulurken, oracle-supplied objeler için root'un dictionarysini işaret eder..

    Bu dictionary mimarisi temelde iki önemli avantaj sağlar..
    • Duplication'ı azaltır ; Örneğin DBMS_ADVISOR PL/SQL paketinin her PDB için tutulmasına gerek kalmaz.sadece CDB$ROOT'ta tutulur ve böylece diskten tasarruf sağlanır..
    • Database upgradeini kolaylaştırır ; Yeni sürümlerde meydana gelen değişiklikleri her PDB'ye ayrı ayrı uygulama zahmetinden kurtarır bizi..

    CDB'de servis yaratılması
    Bir PDB yarattığımız zaman database otomatik olarak CDB içerisinde bir servis yaratır ve başlatır.PDB ile aynı isme sahip olan bu servis defaultdur ve drop edilemez.Bu PDB için ayrıca servisler de yaratabiliriz.Servis yaratma işlemi non-CDBlerdeki ile aynı şekilde yapılmaktadır..


    CDB administrator CBD altındaki herhangi bir container'a bağlanabilir.Containerlar arasında geçiş yapmak için ise aşağıdaki komut kullanılır.
    ALTER SESSION SET CONTAINER = ContainerName;

    SQL plus ile databaseimize bağlandığımız zaman default olarak roota bağlanıyor..

    SQL> SHOW CON_NAME

    CON_NAME
    ------------------------------
    CDB$ROOT

    Servisleri sorgulamak için;
    SQL> SELECT NAME, PDB FROM V$SERVICES
    ORDER BY PDB, NAME;    

    NAME                  PDB
    ---------------------------------------------------------------- ------------------------------
    SYS$BACKGROUND CDB$ROOT
    SYS$USERS                  CDB$ROOT
    cdb1                  CDB$ROOT
    cdb1XDB                   CDB$ROOT
    pdborcl                          PDBORCL



    Şuan CDB üzerindeki containerları görmek için aşağıdaki sorguyu kullanabiliriz.

    SQL> SELECT NAME, CON_ID, DBID, CON_UID, GUID FROM V$CONTAINERS ORDER BY CON_ID;

    NAME        CON_ID  DBID    CON_UID    GUID
    --------            ----------    ----------        ----------     --------------------------------
    CDB$ROOT  1         841923413            1   FD9AC20F64D344D7E043B6A9E80A2F2F
    PDB$SEED  2        1497111388 1497111388   0BE96D62907A1C0EE0538338A8C04659
    PDBORCL  3        2980990456 2980990456   0BE9A9F319561EE4E0538338A8C09583



    CDB'de Common Ve Local Userlar
    CDB üzerinde yaratılan common userlar root dahil tüm PDB'lere bağlanabilir ve işlemler yapabilir.Oracle-supplied yada user-created common userlar vardır. Örneğin SYS and SYSTEM oracle-supplied common userlardır..User created common userlar C## veya c## ile başlayan isimlere sahip olmalıdır.Aşağıdaki şemada hrpdb ve salespdb pluggable databaseleri bulunmaktadır, SYS ve c##dba common userlardır.hr ve rep userları ise iki PDB'de de local user olarak bulunmaktadırlar..


    • Common user root dahil create session privilegine sahip olduğu tüm containerlara login olabilir. Common user her container için aynı haklara sahip olmak zorunda değildir. Örneğin hrpdb ve roota bağlanabilirken, salespdb için create session hakkı vermeyebiliriz..
    • Unique ve c## yada C## ile başlayan bir isme sahip olmalıdır. Root içinde bulunur fakat tüm PDBlere aynı kimlikle bağlanır..
    • Common user birden çok PDBye bağlanma hakkına sahip ise o herbir c#dba şeması farklı objeler içerebilir.
    Local User ; yalnızca yaratıldığı  PDB için operasyonları gerçekleştirebilecek userdır.
    • PDB altında kendi şemasına sahiptir.Başka bir PDB yada roota login olamaz.
    • Local user rootda yaratılamaz.Yaratıldığı PDB içerisinde unique bir ismi olmalıdır.
    • Common user  altındaki objelere izinlerine bağlı olarak erişebilir.Örneğin c##dba kullanıcısı kendi şemasında ve hrpdb üzerinde bir tablo yaratırsa, gerekli izinler verildiğinde hr kullanıcısı bu tabloya erişebilir.
    Common  ve Local Roller


    Common Roles oracle-supplied yada user created roller olabilir. DBA ve Public gibi oracle-supplied rollerin hepsi common roldür..User created common roller ,common userda olduğu gibi c## yada C## ile başlamak zorundadır. Common role yaratabilmek için common user create role yetkisine sahip olmalıdır ve SET CONTAINER hakkında sahip olmalıdır.. CREATE ROLE statementında CONTAINER=ALL olarak set edilir ve common role yaratılmış olur.
    Local Roller ise yaratıldıkları PDB içerisinde geçerlidirler.Yine local userlarda olduğu gibi aynı isme sahip roller farklı PDBler altında yaratılabilir..

    Grant işlemleri ise non-CDBlerde olduğu gibi yapılır. Aradaki temel fark ise; local ve common durumudur..Localde bir yetkilendirme yapılacaksa CONTAINER=CURRENT, common bir yetkilendirme işlemi yapılacaksa CONTAINER=ALL opsiyonuyla yapılır.


    CDB'de Database Dosyları
    Fiziksel olarak bakıldığı zaman, her pluggable database kendi tablespace ve data dosyalarına sahiptir.
    Redolog files,Undo tablespace ve control file ise ortaktır..Default olarak CDB içerisinde temp file bulunur ve PDB'ler bunu kullanır. Ancak ihtiyac durumunda local bir temp file yaratılarak ilgili PDB'nin onu kullanması sağlanılabilir.Her PDB kendi SYSTEM ve SYSAUX tablespaceine sahiptir.



    Kaynaklar:
    Oracle Database Concepts, 12c Release 1 (12.1)
    TROUG-LOG Oracle 12c Veritabanının Yeni Özellikleri / Zekeriya Beşiroğlu
    https://blogs.oracle.com/Multitenant/entry/single_tenant_configuration