Tüm kontrol dosyalarının silinmesinden sonra RMAN ile geri kurtarma

Bu senaryoda uygulamak amacıyla TESTTBL adlı bir tablo oluşturacağım ve içini kayıtlarla dolduracağım. En son kontrol dosyalarından veritabanını geri kurtarıp ardından felaket anından tamamlanmamış(incomplete) geri kurtarma uygulaması yapacağım. Linux platformunda Oracle 10g veritabanı kullanmaktayım.

SQL> insert into TESTTBL select * from TESTTBL;

21244 rows created.

SQL> commit;

Commit complete.

SQL> select count(*) from testtbl;

  COUNT(*)

----------

   182659   à Geri kurtarma sonrası bu kaydı kontrol etmemiz gerekecek

SQL> archive log list

Database log mode              Archive Mode

Automatic archival             Enabled

Archive destination            USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence     7

Next log sequence to archive   9

Current log sequence           9

Not: Mevcut log sırası 9 dur ve henüz arşivlenmemiştir, ancak en son COMMIT işleminden sonraki bilgiler bu log dosyası içindedir.

Yaygın Oracle bekleme olayları ve iyileştirme tavsiyeleri

Bekleme Olayı: db file sequential reads
Üst sınır: V$SYSTEM_EVENT içinde ortalama bekleme süresi 15ms yi geçmemeli

Muhtemel sebepler:

• Yanlış index kullanımı
• Fragmente olmuş indexler
• Belirli disk veya raw partitionlar üzerinde aşırı I/O trafiği
• Kullanılan programda tasarım eksikliği
• Index okuma performansı yüksek oranda ortalama bekleme süresine sebep olan yavaş I/O altsistemi ve/veya veritabanı dosyalarının fiziksel yerleşimindeki eksikliklerden etkilenmektedir.

Önbellekte paylaşımlı bellek kullanım büyüklüğüne göre SQL işlemleri

Alttaki sorgu sonucu buffer cache içinde 1 MB 'dan büyük paylaşımlı bellek kullanan sorgular listelenmektedir. Bu sonuç ile SQL Area içinde o an işlem gören SQL cümleleri için tahsis edilen paylaşımlı bellek miktarı yanında hard parse ve execute oranları gözlemlenebilir ve bunun neticesinde hangi SQL cümlesinde iyileştirme yapılması gerektiği anlaşılabilir.

ASM olmayan Oracle veritabanından duplike bir ASM veritabanı oluşturma

ASM olmayan dosya sistemine sahip bir Oracle veritabanından ASM dosya sistemli veritabanı klonlama yapmak veya duplike bir ASM dosya sistemli veritabanı oluşturmak için izlenecek basit adımlar altta yer almaktadır.

1. Hedef makinede statik bir listener.ora dosyası oluşturun.

(SID_DESC =

     (GLOBAL_DBNAME = DUBDB)

     (ORACLE_HOME = /u01/oracle/product/ORCL)

     (SID_NAME = DUBDB)

    )

2. Kaynak makinede tns alias oluşturun.Bu auxiliary veritabanı için kullanılacak.

DUPDBAUX =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = linux1)(PORT = 1521))

    )

    (CONNECT_DATA =

      (SERVICE_NAME = DUBDB)

    )

  )

3. init.ora ve password dosyasını kaynak makineden hedef makinedeki $ORACLE_HOME/dbs dizinine kopyalayın.

Oracle 11g AWR(Otomatik işyükü ambarı) ile performans istatistikleri

Veritabanı istatistikleri veritabanı üzerindeki yük tipi ile ilgili bilgileri ve veritabanı tarafından kullanılan harici ve dahili kaynak bilgilerini sağlar. ADDM kullanarak veritabanı ile ilgili performans problemlerini  tam olarak teşhis etmek için istatistik bilgilerinin olması gerekmektedir.

Oracle 11g veritabanı sistemi, oturumlar ve bireysel SQL durumları ile ilgili çok tipte birikmiş istatistikler oluşturur. Ayrıca, servisler ve segmentler ile ilgilide pek çok birikmiş istatististik tutar. Otomatik İş Yükü Ambarı(Automatic Workload Repository-AWR) veritabanı istatistiklerini, veritabanı problem teşhisi ve kendi kendine ayarlama amaçları için performans istatistiklerini toplayarak, işleyerek ve sürdürerek, tüm adımları tek adımda toparlayıp  otomatikleştirir.

Hoşgeldin oğlum

Hoşgeldin oğlum Arda Efe. Az evvel dünyaya "hoşbulduk" dedin :) Tüm güzellikler ve iyilikler yanından eksik olmasın. Uzun, sağlıklı ve mutlu bir hayat geçirmen ümidiyle... Seni herşeyden çok seven baban

Oracle 9i üzerinde Fiizksel Standby Veritabanı Yapılandırma

Tanımlar:

AFFIRM: Archive logların diske yazıldığını garantiye alır.

MANDATORY: Archive loglar başarılı şekilde oluşturuluncaya kadar redo logların yazılmamasını güvence altına alır. Bu sadece primary veritabanına etki eder.

REOPEN=30’un anlamı; ARCH ve/veya LGWR prosesleri tekrar hata veren MANDATORY hedefe işlem için deneyene kadar 30 saniyelik gecikme olacak demektir.

DELAY: Dakika olarak tanımlıdır ve archive log dosyasının standby sunucuya kopyalanmasını durdurmaz,ancak bunun sonrasında redo uygulaması durar. Primary veritabanı performansına yardımcı olmaz.

Oracle 10g için Linux kernel parametresi hesaplaması

/etc/sysctl.conf içi parametre değeri	Tanımı	MINIMUM Değer	Hesaplama
net.wmem_max	Maksimum gönderilen TCP paket değeri - byte	1048576 (100Mbps bant genişliği ve ortalama 5.2 saniyelik latency değeri için)	>= 1048576 Formulü -> BDP = bant_genişliği_bytedeğeri* RTT(saniye) değeri ile çıkan sonucun 2 katıdır.
net.wmem_default	Varsayılan gönderilen TCP paket değeri - byte	262144	>= 262144 net.wmem_max değerinin dörtte biridir.
net.rmem_max	Maksimum alınan TCP paket değeri - byte	4194304	>= 4194304 net.wmem_max değerinin 4 katıdır.
net.rmem_default	Ortalama alınan TCP paket değeri - byte	262144	>= 262144 net.wmem_max değerinin dörtte biridir.
net.ip_local_port_range	Kullanılacak minumum ve maksimum port sayısı	Minimum: 9000	Ayar yoktur. Sabitleyin
		Maximum: 65500
kernel.shmmni	Sistem tarafında paylaşımlı bellek segment sayısı	4096	4096'ya  fikslenmektedir. PAGE_SIZE değeridir.Huge pages kullanıldığında değer dahada yüksek olacaktır.
kernel.shmmax	Linux prosesisinin ayırdığı maksimum single paylaşımlı bellek segment  boyutu (bytes değeri olarak)	1/2 den 2/3 e kadar fiziksel bellek değeri; 32 bit için max. 4GB -1, 64 bit için max. 4TB.	en yüksek SGA_MAX_SIZE değeri, SGA_TARGET,MEMORY_MAX_SIZE veya tüm instancelerin MEMORY_TARGET değeri
		Varsayılan: 536870912
kernel.shmall	Sistem tarafında kullanabilen paylaşımlı bellek sayfalarının toplam sayısı	2097152	shmmax/PAGE_SIZE
			(PAGE_SIZE değeri Big/Huge Pages kullanılmadığı takdirde genellikle 4096 byte'dır.
			PAGESIZE şu şekil bulunur:
			"getconf PAGESIZE"
kernel.sem:semopm	semop çağrısı olarak maksimum operasyon sayısı	100	semmsl değerine eşit
kernel.sem:semmsl	Her set için toplam semaphores	256. Enaz 100 tavsiye edilir.	Maksimum(PROCESS değeri) +10
kernel.sem:semmns	Sistem tarafında toplam semaphores sayısı	32000	semmsl * semmni
kernel.sem:semmni	Toplam semaphores seti	128. Enaz 100 olması tavsiye edilir.	semmsl / semmns
kernel.msgmax	Maksimum mesaj kuyruk boyutu	8192	Fiziksel RAM değeri (MB olarak)
fs.file-max	Sistem tarafında maksimum açılacak dosya sayısı	327679	512 * PROCESSES
kernel.sem	Eşzamanlı bekleyen I/O çağrıları	250 32000 100 128	250 değerinin olduğu kısım SEMMSL değeridir ve 64 bit Oracle 10g platformunda PROCESSES parametre değerinin on katı olması lazımdır. 32000 değerinin olduğu kısım SEMMSL*SEMMNI değeri çarpımı çıkan değer olması gerekir. 100 değerinin olduğu kısım SEMOPM değeridir ve SEMMSL ile aynı değerde tutulması tavsiye edilir.

Oracle 9i buffer cache(ön bellek) içindeki objeler

Oracle üzerinde sys kullanıcısı ile oturum açıldığı zaman erişilen v$bh görünümü data buffer içeriği ile birlikte bufferdaki her segment tipine ait blok sayısını göstermektedir.

V$bh görünümü özellikle veritabanında multiple data buffer poollardaki tablo ve index belelkleme(caching)değerlerini görmek için kullanışlıdır.Örneğin, geniş blok boyutunda ayrı index bufferlara sahip olmak Oracle index yapısını iyileştirmektedir. v$bh görünümü aynı zamanda optimizer_index_caching parametresi için olması gereken optimal değeride bizlere verebilmektedir. Bu sayede buffer cachede veritabanındaki ne kadar indexin buffer cachede bulundurulacağı garanti edilir.

"ORA-01555 Snapshot Too Old" mesajı

ORA-01555 Snapshot Too Old hata mesajı undo segmentin yeterli büyüklükte olmaması veya undo retention parametresinin değerinin düşük olmasından kaynaklanmaktadır.

Eğer undo segmentiniz yeterli büyüklükte ise bu durumda undo retention değerini alttaki sorgu sonucunda tavsiye edilen optimal değere  "ALTER SYSTEM SET UNDO_RETENTION = <optimal_undo_retention_value>" ile yükseltmeniz tavsiye edilir.

SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
ROUND((d.undo_size / (to_number(f.value) *
g.undo_block_per_sec))) "OPTIMAL UNDO RETENTION [Sec]"
FROM (
SELECT SUM(a.bytes) undo_size
FROM v$datafile a,
v$tablespace b,
dba_tablespaces c
WHERE c.contents = 'UNDO'
AND c.status = 'ONLINE'
AND b.name = c.tablespace_name
AND a.ts# = b.ts#
) d,
v$parameter e,
v$parameter f,
(
SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
undo_block_per_sec
FROM v$undostat
) g
WHERE e.name = 'undo_retention'
AND f.name = 'db_block_size'

Undo segmentinizin Oracle 9i veritabanınca tavsiye edilen ebadını öğrenmek için ise alttaki sorguyu çalıştırabilirsiniz.

SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
       SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
       (TO_NUMBER(e.value) * TO_NUMBER(f.value) *
       g.undo_block_per_sec) / (1024*1024)
      "NEEDED UNDO SIZE [MByte]"
  FROM (
       SELECT SUM(a.bytes) undo_size
         FROM v$datafile a,
              v$tablespace b,
              dba_tablespaces c
        WHERE c.contents = 'UNDO'
          AND c.status = 'ONLINE'
          AND b.name = c.tablespace_name
          AND a.ts# = b.ts#
       ) d,
      v$parameter e,
       v$parameter f,
       (
       SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
         undo_block_per_sec
         FROM v$undostat
       ) g
 WHERE e.name = 'undo_retention'
  AND f.name = 'db_block_size';

Oracle 9i üzerinde aşırı I/O trafiği sorunu

Oracle 9i datafileler üzerindeki I/O trafiğini gözlemlemek için alttaki sorgu kullanılabilir.

select d.name,s.PHYRDS,s.PHYWRTS
from v$datafile d, v$filestat s
where d.file#=s.file#
order by 1

Bu sorgu sonucunda tablespacelerde yükleme ile denge yoksa trafiğin neden belli datafileler üzerinde olduğunun irdelenmesi ve buna göre iyileştirme yapılması gerekmektedir.

Bu noktada alttaki sorulara cevap vermek gerekmektedir.

Init.ora parameters affecting the library cache

• DB_FILE_MULTIBLOCK_READ_COUNT

db_file_multiblock_read_count is only applicable for tables/indexes that are full scanned. This parameter controls how much data Oracle thinks it can retrieve from the disks in a single trip (during a table/index scan). I/O chunk size for Oracle 9i is 1MB.

DB_FILE_MULTIBLOCK_READ_COUNT = I/0 chunk size / db_block_size

Shared Pool and Library Cache Latch Contention

A main cause of shared pool or library cache latch contention(memory fragmentation) is unnecessary parsing. There are a number of techniques that you can use to identify unnecessary parsing and many types of unnecessary parsing:

• Unshared SQL: Identify similar SQL statements that could be shared if literals were replaced with bind variables.
• Reparsed Sharable SQL: If the parse_calls value is close to the executions value for a given statement, then you might be continually reparsing that statement.

Oracle SQL Tuning Advices

1. Find SQL statements with high IO and some wait metrics that can give us more insight into what Oracle is doing behind the scenes to access the object.  

           Solution: Create indexes, force use with hints

1. Find "unused indexes".

      Solution: Enable collecting statistics on indexes

3. Find large table scans.
4. Find small full table scans and counts

      Solution:Pin those hit tables to buffer pool as KEEP

5. Find index range scans and counts   

      Solution:Pin those hit indexes to buffer pool as KEEP

6. Find index unique scans and counts    

      Solution:Pin those hit indexes to buffer pool as KEEP

7. Check for many indexes on data buffer cache 

      Solution: Adjust parameters OPTIMIZER_INDEX_COST_ADJ=20 and

      OPTIMIZER_INDEX_CACHING with the % of indexes on data buffer  

      cache

8. Analyze indexes with compute (or estimate if the you have more than 100,000 rows in your table). If the PCT_DELETED is 20% or higher, the index is candidate for rebuilding. Leaving indexes with high PCT_DELETED without rebuild might cause excessive redo allocation on some systems.
9. Check for skewed indexes which happen when there are lots of DML activities in tables. If  BLEVEL is higher than 3, those indexes should be re-builded.
10. Enable index monitoring feature on the database to monitor which index are rarely used or never used. Accordingly, tune or remove those indexes.
11. Detect fragmentation on database objects.
12. Identify the amount of memory needed to maintain estimated performance. Solution: DB_CACHE_ADVICE = ON
13. Find hard parsed SQL statements frequently and advice programmers to tune them.
14. Find invalidated SQL statements which cause certain hard parses, and advice programmers to tune them.
15. Find top SQL statements which use high amounts of sharable memory. Also monitor invalidation rate of those statements, and advice programmers to find a solution how those SQL statements can release those shared memories unless they are in use.
16. As many users are connected at a time and only a few of them are active (let's say that they are using a thin-thinking application), we have to make sure database is not using static PGA memory size. Setting PGA_Aggregate_Target will save a lot of memory.

Aynı sunucu üzerinde Oracle 9i veritabanının klonlanması

1. Aynı Windows sunucu üzerinde Database Configuration Assistant kullanarak kaynak veritabanı ile aynı SID de bir veritabanı oluşturun.

2. Hedef veritabanı kurulduktan sonra bu veritabanını kapatın (shutdown immediate)
3. Hedef veritabanını kapatın ve kaynak veritabanı veri dosyalarını kaynak veritabanı veri dosyalarının dizinine kopyalayın.
4. Kaynak veritabanını başlatın.

5. Klon veritabanında kullanılmak üzere alttaki gibi bir backup kontrol dosyası oluşturun.

CREATE CONTROLFILE SET DATABASE "<SID_of_clone_database>" RESETLOGS

NOARCHIVELOG

-- SET STANDBY TO MAXIMIZE PERFORMANCE

MAXLOGFILES 5

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 1

MAXLOGHISTORY 4991

LOGFILE

GROUP 1 'D:\Oracle\Oradata\NUNDQOL\REDO01.LOG' SIZE 100M,

GROUP 2 'D:\Oracle\Oradata\NUNDQOL\REDO02.LOG' SIZE 100M,

GROUP 3 'D:\Oracle\Oradata\NUNDQOL\REDO03.LOG' SIZE 100M

-- STANDBY LOGFILE

DATAFILE

'E:\oracle\oradata\NUNDQOL\SYSTEM01.DBF',

'E:\oracle\oradata\NUNDQOL\UNDOTBS01.DBF',

'E:\ORACLE\ORADATA\NUNDQOL\CWMLITE01.DBF',

'E:\oracle\oradata\NUNDQOL\DRSYS01.DBF',

'E:\ORACLE\ORADATA\NUNDQOL\ODM01.DBF',

'E:\oracle\oradata\NUNDQOL\NUNTQOL.DBF',

'E:\oracle\oradata\NUNDQOL\NUNTQOL_IAM.DBF',

'E:\oracle\oradata\NUNDQOL\INDX01.DBF',

'E:\oracle\oradata\NUNDQOL\TOOLS01.DBF',

'E:\oracle\oradata\NUNDQOL\USERS01.DBF',

'E:\oracle\oradata\NUNDQOL\XDB01.DBF';

6.  Klon veritabanının varsayılan kontrol dosyası lokasyonlarındaki tüm mevcut kontrol dosyalarını silin.
7.  Klon veritabanını NOMOUNT modunda başlatın(STARTUP NOMOUNT).

8.  Klon veritabanında yeni kontrol dosyaları oluşturmak üzere üstte hazırladığınız backup kontrol dosyasını çalıştırın.

9.  Klonlama işlemini başarıyla sonlandırmak için alttaki komutları çalıştırın.
     

     RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE;

     ALTER DATABASE OPEN RESETLOGS;

Oracle 11g üzerinde ASM disk gruplarının yönetimi

ASM disk gruplarını kullanılması veritabanı sistem performansında pek çok yoldan avantajlar sağlar;

·         I/O performansı yükselir.
·         Veritabanı uygunluğu artar.
·         Diskgruplarına ek disk ilave ederek yada yeni disk grupları ile birden fazla veritabanı için kolayca ilave boş disk alanları yaratabilirsiniz.

Bu bölümde, disk grupları ile ilişkili değişik tipte yönetim görevleri gösterilecek, failure gruplara disk eklemelerin nasıl yapılacağı, disk gruplarının nasıl aynalanacağu(mirrored) ve disk gruplarının nasıl ekleneceği, düşürüleceği ve düzenlenebileceği konuları işlenecektir.Bu bölüm komut satırından bu işlemlerin nasıl yapılacağını irdelemektedir.

ASM Disk Grup Mimarisi

Disk grupları, birden fazla diskin tek birim olarak yönetildiği yapılardır. Her ASM diski, veritabanı yöneticisi tarafından veya veritabanı sistemi tarafından otomatik olarak isimlendirilmesi ile oluşturulur.

Diskler içindeki dosyalar birbiri ile 2 türde paylaştırılır.Coerse striping, dosyaların tüm disklerde 1MB birimler halinde serpiştirilmesidir ve genellikle OLTP işlemleri yoğun kullanılacak veritabanları için uygundur. Fine striping mimarisinde ise 128 KB lik birimler halinde serpiştirme yapılır ve genellikle raporlama, OLAP işlemlerinin yoğun kullanıldığı veritabanları için uygundur.

Disk Group Mirroring ve Failure Groups

Bir failure group, disk grubu içinde disk controller gibi ortak bir kaynağı kullanan birden fazla diskten meydana gelir. Herhangi bir felaket anında bu failure grupiçindeki tüm diskler disk grubu için erişilemez olabilir. Aslında bu noktada failure gruplar, sunucu donanımı tabanında oluşturulan RAID-1 diskler olabilir. İşletim sistemi seviyesinde bu RAID-1 ile yapılandırılan 2 fiziksel disk tek bir disk gibi görünür ve algılanır.

Failure gruplar içinde diskler tanımlandıktan sonra oluşturulacak olan ASM disk grubu için mirroring özelliği belirtilebilir. 3 tür mirroring vardır.

·         External Redundancy: Eğer failure grup içindeki diskler herhangi bir RAID controller ile yapılandırılmışsa (örneğin RAID-1) bu seçenek uygundur. Tek bir disk lokasyonu belirtilebilir.

·         Normal Redundancy: Çift taraflı mirroring desteği sunar ve en az 2 failure gruptan oluşan disklerden oluşturulabilir. Failure gruplar içerisindeki disklerden birinin çökmesi disk grubu için işlevselliğin durmasına sebep olmaz ve very kaybı olmaz.

·         High Redundancy: Üç yönlü mirroring özelliği sunar ve bir disk grubu içinde en az 3 failure grup gereksinimi duyulur. 2 failure grup çökse dahi, veritabanında very kaybı olmaz ve çalışmaya devam eder.

Disk Grubu Dinamik Yeniden Balanslama(Rebalancing)

Bir failure grup çıkardığınızda yada bir failure gruptan disk çıkardığınızda veya eklediğinizde disk grubunun yapısında değişiklik meydana gelir. Bu durumda, Oracle eski disklerden yeni disklere orantılı olarak yeniden dağıtmak üzere otomatik olarak yeniden balanslama yapar. Bu yeniden balanslama esnasında veritabanının online olması ve kullanıcıların veritabanına bağlı olmasının I/O performansına etkisini azaltmak için ASM_POWER_LIMIT adlı başlangıç parameter değerinin düşük değerde olması gerekir.

Aşağıdaki sorgu bize disk grupları, bunların ait olduğu failure grupları ve disklerin oluşturulma tarihleri ile isimlerini veren sorgudur.

SQL > select group_number, disk_number, name, failgroup, create_date, path           from v$asm_disk; 

ASM disk gruplarında ne kadar boş alan kaldığını öğrenmek için ise;

SQL > select group_number, name, type, total_mb, free_mb           from v$asm_diskgroup;

Örneğin;  sisteme  2 yeni disk ilave ettikten sonra yeni bir ASM diskgrup oluşturmak için ise;

SQL> create diskgroup data2 normal redundancy          failgroup fg1 disk ‘/dev/sde1’ name d2a          failgroup fg2 disk ‘/dev/sdf1’ name d2b;

Bir ASM disk grubunu içindeki veritabanı objeleri ile beraber düşürmek için ise;

SQL> drop diskgroup data2 including contents;

Disk Group Hızlı Mirror Senkronizayonu

Eğer bozuk disklerden birisi onarılıp yerine takılırsa veya yeni bir disk ile değiştirilirse, verilerin bu diske yeniden “mirror”lanması biraz zaman alabilir. Hızlı mirror yeniden senkronizasyonu Oracle 11g ile gelen bir özelliktir. Bu özelliği etkin kılmak için, geçici bir hata oluştuğunda(planlı yada plansız) ASM ‘nin diski otomatik olarak disk grubu düşürmemesi için bir zaman atanır.

DATA disk grubuna bir zaman atamak için disk grubunun hem RDBMS instance için, hemde ASM instance için uyumluluk seviyesinin 11.1 veya daha üstü seviyeye eşitlenmiş olması gerekmektedir.

SQL> alter diskgroup data set attribute          ‘compatible.asm’ = ’11.1.0.0.0’;

SQL> alter diskgroup data set attribute          ‘compatible.rdbms’ = ’11.1.0.0.0’;

Varsayılan disk onarma süresi 3,6 saattir. Bu süreyi  örneğimizdeki gibi 2.1 saate düşürmek için;

SQL> alter diskgroup data set attribute ‘disk_repair_time’ = ‘2.1 h’;

Disk gruplarını düzenleme

Mevcut disk gruplarında boş alana ihtiyaç duyulduğunda veya mevcut disklerden birisinin yenisi ile değiştirilmesi durumunda kullandığımız disk grubuna aşağıdaki örnekteki gibi ilave failure gruplar ekleyebiliriz. Bu şekilde herhangi bir şekilde ASM disk gruplarını yeniden oluşturmaya gerek kalmaz.

SQL> alter diskgroup data add failgroup deneme1 disk ‘/dev/sdg1’ name d1c;

Bu disk grubunun otomatik yeniden balanslama işlemi 16 dakika kadar surer.Bu süreyi yarı yarıya azaltmak gibi durumlarda manuel olarak yeniden balanslama işlemi yapabiliriz. Aşağıdaki örnekte 8 dakika olmaktadır.

SQL> alter diskgroup data rebalance power 8;

ALTER DISKGROUP komutları    

alter diskgroup … drop disk -> Tanımlanan disk grubundan failure gruplarına ait diskleri çıkarır.     

alter diskgroup … drop … add -> Failure gruptan disk çıkarır ve yerine yenisi eklemek için kullanılır.

alter diskgroup … mount ->Disk grubunu tüm instance lar için erişilir yapar.

alter diskgroup … nomount ->Disk grubunu tüm instance lar için erişilmez yapar.

alter diskgroup … checkall ->Disk grubunun dahili bütünlüğünü check eder.

ASM mimarisinde Linux üzerinde Oracle 11g kurulumu - 2

Bir önceki makelemizde, Vmware ESX Server platformunda kurulu olan Oracle Enterprise Linux(OEL) 5.0 işletim sisteminde yapılandırdığımız ve mühürlediğimiz DATA1, DATA2 ve RECO1 adlı ASM disklerinde Oracle 11g R1 veritabanı kurulumuna başlayacağız.

ASM mimarisinde Linux üzerinde Oracle 11g kurulumu -1

Oracle 11g, Oracle 10g generasyonundan itibaren "kur ve unut" felsefesinin en son durak noktasıdır. Memory yönetiminin otomatikleştirilmesi, yeni bir takım "advisor" ların eklenmesi ve hayran bırakacak şekilde sürdürülebilirliğin arttırılması ve çökme riskinin neredeyse ortadan kaldırılması ile veritabanı teknolojisinde yeni bir süreçtir.
Oracle mimarisinde "database" ve "instance" kavramları farklılık göstermektedir. Diğer veritabanı ürünlerine gore Oracle tarafında bu iki kavram üzerinden hareket edilmektedir.

Oracle 11g versiyonunda Recovery Manager(RMAN) Teknolojisi

Oracle Recovery Manager(RMAN) teknolojisi, veritabanının gerek bütünsel gerekse tablespace bazlı olarak yedeğinin alınması ve felaket anında yedekten belirli zaman dilimine yada SCN numarasına dönülmesi şeklinde özetlenebilir.  Oracle 11g veritabanı sürümü ile RMAN teknolojisine pek çok yenilik eklenmiştir. Data Recover Tavsiyecisi(Advisor), muhtemel oluşabilecek hataları analiz etme ve en azından bir tane tamir seçeneğini sunması ile oluşabilecek herhangi bir uygulama hatasından once problemleri teşhis eder ve böylece veritabanının kesintisiz çalışması ve bütünlüğünün bozulmaması için üst düzey bir koruma saplar. Bu amaçla ise RMAN’ın list failure, change failure, advise failure ve repair failure gibi Oracle 11g ile yeni gelen tamir komutları kullanılır.  RMAN, flashback alanı dolu olduğu takdirde arşivlenlenmiş redo günlüklerini kullanır. Duplicate komutu ile de kopya veritabanı veya fiziksel standby veritabanı, yedek dosyalarına gerek kalmaksızın oluşturulabilir.

Oracle11g Flashback Özellikleri

Oracle 10g sürümü ile ortaya çıkan Flashback özellikleri pek çok yenilik ile Oracle 11g sürümünde de veritabanı yöneticilerine felaket durumlarında yardımlar sağlamaktadır. Flashback Database, Flashback Data Archive, Flashback Query, Flashback Table, Flashback Version Query, Flashback Drop ve Flashback Transaction Query olarak çeşitli türde bölümlendirilmiş ve herbirinin farklı amaçları olmaktadır.

Flashback Database

Flashback özelliklerinden yararlanmak için veritabanının flashback operasyonları için etkinleştirilmiş olması gerekmektedir. Aşağıda bu etkinleştirme adım-adım anlatılmaktadır.