Transportable Tablespace

Bu yöntem ile bir platformdan diğer platforma tablespace kolayca taşıyabiliriz.Bu işlemi yaparken export import utility kullanırız. Bunun ile tablespace metadata kopyalarız.Bu yöntem diğerlerine göre daha hızlıdır. Çünkü Oracle sadece tablespace metadatası ile ilgili bir işlem yapmaktadır.Gerekli olan datafile manually olarak migrate ederiz.10g den önceki versiyonlarda bu özelliği kullanabilmek için aynı platformlara sahip olmak gerekirdi. Fakat 10g den sonra bu işlem farklı platformlar arasında da gerçekleştirilmeye başlandı.Burada transportable tablespace işlemini linux bir makinadan windows bir makinaya gerçekleştireceğiz.

1)İlk olarak elimizde bulunan platformların transport işlemi için uygun olup olmadığı ve transport işlemini gerçekleştirebileceksek datafile convert işleminin gerekip gerekmediğini kontrol etmeliyiz.Convert işlemine karar vermek için platformların endian formatlarına bakarız. Endian formatları farklı ise convert işlemi gerekicek aynı ise böyle bir işleme gerek duyulmayacaktır.
Source makina
SQL> column platform_name format a30
SQL> SELECT A.platform_id, A.platform_name, B.endian_format
  2  FROM   v$database A, v$transportable_platform B
  3  WHERE  B.platform_id (+) = A.platform_id;
 
PLATFORM_ID      PLATFORM_NAME                  ENDIAN_FORMAT
-----------                    ------------------------------                  --------------
     13                           Linux x86 64-bit                              Little

      Migrate Database to Another Platform using Rman
Database başka bir platforma taşımadan önce bazı gereksinimlerini kontrol etmeliyiz.Transport işlemini geçekleştirebilmek için iki sistem de aynı endian format biçimine sahip olmalıdır.

1)İlk olarak migrate işlemi için sistemlerin birbirlerine uyumluluğunu öğrenebilmek için platform_name ve  endian formatlarını kontrol ederiz.Ayrıca v$transportable_platforms view kontrol ederek varolan sistem için transport işleminin desteklenip desteklenmediğini öğrenmeliyiz.
Source system
SQL> select platform_name from v$database;
PLATFORM_NAME
--------------------------------------------------------------------------------
Linux x86 64-bit

SQL> SELECT PLATFORM_ID, PLATFORM_NAME, ENDIAN_FORMAT
  2  FROM   V$TRANSPORTABLE_PLATFORM
  3  WHERE UPPER(PLATFORM_NAME) LIKE '%LINUX IA%';
PLATFORM_ID PLATFORM_NAME                  ENDIAN_FORMAT
----------- ------------------------------                             --------------
         10         Linux IA (32-bit)                          Little
         11         Linux IA (64-bit)                           Little

Recovery Online Redo Logs

Database makinasında online redo log lar OS seviyesinde silindikten sonra database nasıl recover edileceğine söz edeceğiz.Redolog lar silindikten sonra alert.log dosyasına aşağıdaki gibi hatalar görülecektir.

ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/orcl/redo01.log'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Clearing online redo logfile 1 /u01/app/oracle/oradata/orcl/redo01.log
Clearing online log 1 of thread 1 sequence number 0
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_8300.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/orcl/redo01.log'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_8300.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/orcl/redo01.log'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Clearing online redo logfile 1 complete

Database Upgrade From 11.1.0.6 to 11.1.0.7

Bu upgrade işlemini single instance database için  gerçekleştireceğim.Bu işlemi gerçekleştirmde önce 11.1.0.6   

sistemde kurulu olmalıdır. Bu sürüm sistemde kurulu olmazsa runInstaller çalıştırdığımızda hata verecektir.

A)Prerequests:Upgrade işlemine başlamadan önce database ile ilgili servisleri kapatmamız gerekiyor.

1)Set ORACLE_HOME and ORACLE_SID
$export ORACLE_SID=ORCL
$export ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1
$export PATH=$PATH://u01/app/oracle/product/11.1.0/db_1/bin

2)Stop all services
$emctl stop dbconsole
$lsnrctl stop

3)Shutdown database instance
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

                     Recover Datafile with Rman

Herhangi bir şekilde silinmiş bir datafile rman ile nasıl recover edileceğinden bahsedeceğim.Sistemimizde varolan datafile bakabiliriz.

SQL>select name,status from v$datafile;
NAME                                          STATUS                          
--------------------------------------------- -------                          
/u01/app/oracle/oradata/databs/system01.dbf   SYSTEM                          
/u01/app/oracle/oradata/databs/sysaux01.dbf   ONLINE                          
/u01/app/oracle/oradata/databs/undotbs01.dbf  ONLINE                          
/u01/app/oracle/oradata/databs/users01.dbf    ONLINE                          

1)İlk olarak test için bir tablespace ederiz.

SQL>create tablespace rectbs datafile '/u01/app/oracle/oradata/databs/recdata.dbf' size 50M;
Tablespace created.

         Rman List,Report,Crosscheck and Delete Command

List Command: Bu komut ile sistemde varolan archivelog ve backup görebiliriz.
RMAN>list backup summary
RMAN>list backup of database
RMAN>list backupset of database;
RMAN>list backup of tablespace 'tablespace name'
RMAN>list backup of datafile 5(datafile number)
RMAN>list backup of controlfile
RMAN>list backup of spfile
RMAN>list backup by file
RMAN>list expired backup
RMAN>list expired archivelog all
RMAN>list archivelog all;
RMAN>list archivelog from time 'sysdate-7'
RMAN>list archivelog until  time 'sysdate-2

                                     
                                RMAN Catalog Database Configuration

     Rman catalog database alınan yedeklerin metadatasını farklı bir database içerisinde tutmaya yarar.Bu metadata normalde database controlfile tutulur. Bu bilgiler yedeğin ne zaman alındığı, hangi veritabanına ait olduğu, hangi dosyaların hangi backupsetin içinde bulunduğu gibi bilgilerdir.Bu catalog bilgileri target database de farklı bir schemanın içerisinde olabilir.Ama bu catalog bilgilerinin  target database den farklı bir database içerisinde olması önerilir.Birde bu yöntem birden fazla database olduğu sistemlerde kullanılır. Tek bir database için bu yapının kullanılması önerilmez.Catalog database kullanılsada alınan yedek bilgileri  control file içerisinde tutulur.Control file içerisinde belirli bir geçmişe kadar olan backup bilgisi tutulabilinir.Ama catalog database keep forever özelliği ile backup bilgisine herzaman ulaşabiliriz.

control_file_record_keep_time initialization parametresi ile backup kullanılmadığında metadatanın control file içerisinde kaç gün süre ile tutulacağını belirtir.Bu değer default olarak 7 gündür.

Catalog Database Configuration:Catalog için kullanılacak olan database target database farklı bir yerde create edilir.Ve bu database içerisinde catalog sahibi ve catalog bilgilerinin tutulacağı tablespace oluşturulur.Catalog bilgileri  bulunduğu schemanın default tablespace inde yer alır.SYS kullanıcısı recovery catalog ların sahibi olamaz.Catalog database oluşturduktan sonra aşağıdaki işlemler gerçekleştirilir.

              Migrate Database From File System to ASM
 1)İlk olarak sistemimizde bulunan spfile ASM içerisine taşımalı ve spfile parametresini yeni spfile gösterecek şekilde set etmeliyiz.İlk olarak var olan spfile ASM içerisine alıyoruz.Bu işlemi gerçekleştirmek için ilk olarak spfile backup alırız.

RMAN> backup as backupset spfile;
Starting backup at 02-JAN-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=38 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 02-JAN-13
channel ORA_DISK_1: finished piece 1 at 02-JAN-13
piece handle=/u01/app/oracle/fast_recovery_area/YADB/backupset/2013_01_02/o1_mf_nnsnf_TAG20130102T103154_8g7w3tnm_.bkp tag=TAG20130102T103154 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 02-JAN-13

                           Recovery Block Corruption   
   Burada media corruption gerçekleştirdiğimiz bir data bloğu rman ile nasıl recovery edebileceğimize bakacağız.İlk olarak block corruption içinde bulunduran datafile bulunduğu bir Rman backup sahip olmalıyız.Corruption işlemini gerçekleştirmeden database full backup almalıyız.

                           Data Block Corruption
Block corruption verinin data block larına yazılması sırasında bir hatadan dolayı yazma işleminin başarısız olmasıdır..Data corruption meydana geldiğinde database çalışmasına devam eder ve corruption olan blok dışındaki data ya ulaşılabilinir.Corruption olan bloktaki data ya ulaşılmak istendiğinde aşağıdaki gibi bir hata alınacaktır.
ORA-01578:ORACLE data block corrupted (file # string, block # string)

1)Physical Block Corruption(Media Corrupt):Bu corruption meydana geldiğinde database data bloklarında bulunan data yı okuyamadığı anlamına gelir..Datablock header da bulunan checksum invalid ve corruption olan data blocğunun tamamı null değer içerir.Physical corruption denetimi default olarak enabledir.Rman de validate yaparken nochecksum option ile physical corruption check disable edilir.Physical corruption alert.log dosyasında belirtilir.Bu tür corruptionlarda block media recovery gerçekleştirilir.Bu yöntem ile tüm datafile recover edilmesi yerine sadece corrupt olmuş blocks recover edilir.Bu sırada datafile geri kalan blocklarına erişim sağlanabilinir.Datafile içerisinde bulunan block da media corruption meydana geldiğinde;
Datafile  Media Recovery kullanılırsa datafile offline moda alınacak ve en son alınan backup tan restore edilecek ve backuptan sonra oluşan redo log uygulanacaktır.Bu sırada datafile tamamına erişim sağlanamayacaktır.
Block Media Recover kullanıldığında sadece corrupt olmuş data block recover edilecektir ve datafile geri kalan kısmına erişim sağlanacaktır.

          Automatic Storage Management(ASM) İşlemleri

1)Create Diskgroup:İlk olarak sqlplus ile ASM instance a bağlanırız.
$export ORACLE_SID=+ASM
$export ORACLE_HOME="Grid_home"
$grid_home/bin/sqlplus / as sysdba
SQL>create diskgroup dnmdisk (external,normal,high) redundancy disk '/dev/raw/raw3-->dnmdisk adında external redundancy yapan bir disk grubu oluşturuldu.Disk grubu oluştururken bir redundancy belirtmeliyiz.3 farklı redundancy kullanılabilinir.
Normal Redundancy:Burada datanın 2 kopyası tutulur.Burada datanın aslı bir disk te tutulurken kopyası başka bir disk te tututlur.Bunun için en az 2 disk gereklidir. Bu disklerin boyutları aynı olmalıdır.
High Redundancy:Burada datanın 3 kopyası tutulur.Burada ise en az 3 diske ihtiyaç vardır.
External Redundancy:Burada disk group mirroring yapılmaz.Bu hardware mirroring kullanılacağı zaman tercih edilir.(RAID)

2)Drop Diskgroup:Kullanmak istenilmeyen diskgroup bu komutla kaldırabiliriz.
SQL>Drop diskgroup dnmdisk--> Varolan dnmdisk grubu silinir.

                    Automatic Storage Management(ASM)
    Oracle 10g ile birlikte gelen ASM database verilerinin tutulduğu disklerin yönetimi için kullanılır.ASM içerisinde gerçekleştirilen işlemler ASM instance tarafından yönetilir.ASM instance database instance gibi düşünülmelidir.Örneğin bu instance içerisinde herhangi bir object oluşturulamaz. ASM varolan fiziksel diskleri logical yapılar olan disk group ları içerisinde tutar.             

ASM Kullanmanın Avantajları:
1)Disklerin diskgroup ile yönetimi kolaylaşır.
2)Disk redundancy yönetilebilinir.
3)Herhangi bir disk disk grubundan çıkarıldığında çıkartılan diskteki data diğer disklere dağıtılır(rebalancing) işlemi yapılır.
4)Cluster yapılarında cluster file system olarakda kullanılabilinir.
6)I/O işlemleri diskgroup içerisinde bulunan diskler arasında ortaklaşa yapılır.Bu yöntem ile performans artışı sağlanır.

              
              Tablespace Point-in-time Recovery(TSPITR)

      TSPITR ile sistemde  zarar görmüş tablespace istenilen zamana a recover edilebilir.Recover işleminde istenilen zaman  için database scn veya istenilen zaman kullanılabilinir.Bunu yaparken diğer tablespace ve objeler bu durumdan etkilenmez.

Ne zaman TSPITR:
1)Yanlışlıkla truncate table uygulandığında
2)Logical corruptionlar yaşandığında.
3)Logical bir sechemayı belli bir zamana recover etmek istediğimizde
NOT:Eğer archive log dosyalarına sahip değilsek TSPITR yapamayız.Yani noarchileog modda olan bir database de TSPITR uygulanamaz.


TSPITR Kısıtlamaları:
1)Drop edilen table recover edilemez.
2)Yeniden adlandırılmış bir tablespace adlandırmadan önceki bir  zamana recover edilemez.Eğer bunu gerçekleştirmeyi denersek backup repository tablespace için yeni adıyla bakacağından dolayı doğru backup bulamayacaktır ve fail olacaktır.
3)Bir tabloyu kendisine bağlı bağlı tablolar olmadan recovery edemeyiz.
4)TSPITR ile bir tabloyu recover etmek istediğimiz zaman o tablonun bulunduğu tüm table space kullanırız.
5)Undo ve roolback segmentlerini içeren tablespace recover edemeyiz.

                  Oracle Shared Server Configuration
 
Shared server modelinde her bir client için server process oluşturmak yerine istenilen sayıda server process oluşturup bu server process client isteklerini yerine getirmesi sağlanır.Gelen client istekleri yönetimi dispatcher lar ile saplanır.

İnitialization Parameters For Shared Server
shared_Servers: Bu parametre shared server enable edileceği zaman kullanılır ve kaç tane shared server kullanılacağını belirtir. Bu değer 0 ise shared server disable dır.Shared server enable edildiği zaman dispatcher konfigurasyonunu gerçekleştirmezsek database otomatik olarak oluşturulacaktır.

max_shared_servers: Shared_servers parametresi ile database instance start edildiğinde kaç tane shared server başlatılacağını belirtir.bu parametre ise aynı anda en fazla kaçtane shared server çalışacağını belirtir.
shared_server_sessions:Shared server aynı anda ne kadar user session tutacağını belirtir.Bu değer session initialization parameter dan küçük olmalıdır.
dispatcher:Shared server yapısı için kullanılacak dispatcher belirtir
max_dispatcher: Aynı anda en fazla kaçtane dispatcher process çalışacağını belirtirir

               Diffrence Between Dedicated and Shared Server

      Bir client database connection gerçekleştireceği  zaman server tarafında  çalışan process genel olarak 3 e ayrılır.
     1) User Process: Bu process user applications çalıştırır.(SQLplus)
     2) Server Process: User process isteklerini yönetir.(SQL sorgusunu çalıştırıp sonuç döndürme)
     3) Background Process: Database çalışması için gerekli gerekli olan proces dir.
Database e gelen istekleri yönetmek için  database iki farklı şekilde çalışır.
    1)Dedicated Server

    2)Shared Server
 
Dedicated Server Model: Client bir connection request gerçekleştirdiği zaman yeni bir server process ve session oluşturulur.Database server her bir server process için resource allocate eder.Ve kullanıcının isteklerini bu server process gerçekleştirir.Memory gereksinimi server ve session sayısı ile doğru orantılıdır.Oluşturulan session için gerekli alan PGA dan oluşturulur.Server process ve session terminate edildiği zaman resources release edilir.Bu yöntem performansın önemli olduğu durumlarda kullanılır.

                     
                    İntegrate 12c Cloud Control with OPS Center

Oracle OPS Center 12c installation

Administration-->Enterprise Controller->Enterprise Manager Cloud Controller

                     Oracle OPS Center İnstallation on Redhat 5.8

          İlk olarak OCDoctor ile sistem prerequest kontrol edilir. https://updates.oracle.com/OCDoctor/OCDoctor-latest.zip  OCDoctor sistemimize indirdikten sonra;

     $unzip OCDoctor-latest.zip

     $cd  OCDoctor

     $./OCDoctor.sh –ec –prereq

 

                        Rman İncomplete Recovery

   İncomplete recovery database in  geçmişte herhangi bir noktaya, herhangi bir SCN numarasına  recover edilmesi anlamına gelir.Normal recovery işlemi ile datafiles ve fiziksel yapıda bir değişiklik varsa control file ve archived redo log dosyaları ile  recovery işlemi gerçekleştirilir.Fakat incomplete recovery işleminde redo log file recover işlemi için kullanılmaz.Eğer archived redo  log files kaybedilirse bu recover işlemi gerçekleştirilir. Veya table space geçmişte herhangi bir zamana recover edilirken bu işlem gerçekleştirilir.İncomplete  recovery işlemi her zaman mount modda gerçekleştirilir.İncomplete recovery işlemi sysdba privilege ile gerçekleştirilir.

                            Flash Recovery Area

    Bu  özellik oracle 10g ile birlikte gelmiştir.Ve database recover işleminde önemli bir yere sahiptir.11gR2 ile birlikte bu alan fast recovery area olarak adlandırılmaya başlandı.Bu alanda database backup ve recovery işlemi ile ilgili dosyalar tutulur.Bu alan birden fazla instance için kullanılabilinir.Flash recovery area aşağıdaki amaçlar için kullanılabilinir;

Automated Disk Based Backup and Recovery:Flash recovery area konfigure edildiğikten sonra backup bileşenleri otomatik olarak oracle tarafından yönetilir.
Automatic Deletion of Backup Component:Rman ile varolan backup uzun süreli kullanılmadığında diğer backup için yeterli disk alanı oluşturmak için otomatik olarak silinebilinir.
Disk Cache For Tape Copies:Disaster recovery stratejisinde backup database server farklı bir ortama alınacaksa flash recovery area backup alınacak yer için disk cahce gibi çalışır.
Flashback Logs:Sistemde Flashback özelliği ebanle edilirses flashback logs tutuluması içinde kullanılır.

                       SCN(System Change Number)

       SCN(System change number)database i herhangi bir anda ki durumunu tanımlayan ve unique olan numeric olan bir değerdir. SCN database de gerçekleştirilen  işlemlere bakmaksızın her 3 saniyede bir update edilir.SCN control file, dafile headers ve redolog dosyalarında tutulur.Bütün datafile header larında bulunan scn eşitdir.Redo log dosyasında high ve low scn kaydı tutulur.SCN database veya instance recovery işleminde de  kullanılır.SCN database consistent veya inconsistent state olup olmadığına karar vermek için kullanılır.