NoSQL database nedir ?

Oracle veritabanı uzmanı olarak son zamanlarda katıldığım çoğu oracle seminerinde Oracle Cloud üzerine hazırlanmış sunumlar dinliyorum. Cloud teknolojisini konuştuğumuz zaman çoğu meslektaşım gibi benim de aklıma 'iyi de cloud, oracle tarafından hayal edildiği kadar popüler olursa biz DBAler ne iş yapacağız? ' sorusu geliyor. Bu durumla ilgili  olarak çıkış yolu olarak oracle becerilerimizin yanına nosql, postgresql yada bigdata gibi bazı konu başlıklarında iyice tecrübe edinmek gerekiyor fikri sohbetlerimizin kapanış cümlesi oluyor. İyi de nosql db ile ilgili okuduğum bir çok kaynak da (hele ki developer kökenli insanlar tarafından yazılmışsa) yaşasın dba bağımsız uygulama geliştirme nidalarıyla nosqle dört elle sarılıyor. Neyse biz üzerimize düşeni yapalım da, elbet dbdeki hatayı restart ile çözemedikleri bir durumda bize işleri düşer :)

NoSQL nedir?
İlişkisel veritabanlarının aksine veriyi şema ve tablo bazında tutmayan, json veya xml formatında ve yapısal olmayan datayı tutan database sistemleridir. İnternet datasının hızla büyümesi ve bu dataya hızla erişme ihtiyacının ortaya çıkması bu sistemlerin geliştirilmesinin temel sebeplerindendir. İlişkisel veritabanlarında verinin doğruluğu ve tutarlı olarak saklanması prensibilyle geliştirilmişlerdir. Buna karşın nosql databaseler hızın önemli bir kriter olduğu sistemlerde kullanılır. İlişkisel veritabanlarının güçlü ve maliyetli sunucularının yerine küçük küçük yatay olarak kümelenmiş sunucularla, high availability özellikleri yazılım geliştirme teknolojileri ile sağlanır.
Veri saklama metodları yüzünden çok büyük datayı ilişkisel saklama ihtiyacı olmadan, veriye hızlı erişim amacı ile tasarlanmıştır. Birden çok nosql database tipi bulunmaktadır, document base, graph stores, key-value stores, wide-column stores  olarak kendi içinde ayrılır. Mongo, cassandra en popüler olan nosql databaselerdir.

Read More

Yum local repository oluşturulması

Oracle paketlerini yum ile yüklerken dvd'den bir repository oluşturabiliriz. Oluşturduğumuz local repository sayesinde paketlerin kurulumunu kolayca yapabiliriz.

/etc/yum.repos.d dizininde dvd. repo adlı yeni bir dosya oluşturup içeriğini aş.gibi düzenliyoruz.

[dvd]

name=Oracle Linux Installation DVD
baseurl=file:///mnt/cdrom
enabled=0

Yum ile dvdden yüklemek istediğimiz paketi aş. gibi yükleyebiliriz.

# yum install --enablerepo=dvd oracle-rdbms-server-12cR1-preinstall-1.0-4.el7.x86_64.rpm

Read More

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

Read More

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

Read More

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

Read More

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)

Read More

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

Read More