21 Şubat 2008 Perşembe

STARTUP ve SHUTDOWN

Merhaba,

Bu yazımda Oracle'ın nasıl kapatılıp açılması gerektiğinden biraz bahsedeceğim. Hazır yeri gelmiş iken, ben yazılarımda Oracle'a tamamen uzak olan insanların da anlayabileceği türden yazmaya çalışıyorum. Daha da sığ olarak anlatmamı isteyenler mail atabilirler. Genelde koddan biraz uzak durmaya çalışmaktayım.

Öncelikli olarak, STARTUP ile başlayalım. Startup, Oracle'da "Instance"ı ve veritabanını açmaya yarayan komuttur. Çeşitli durumlarda ve şekillerde instance'ın öncelikli olarak açılabilmesi için sonuna ek komutlar alabilir.
Başlamadan küçük bir hatırlatma. "select open_mode from v$database" dersek veritabanının hangi aşamada açıldığını görebiliriz.

Kapalı durumda olan veritabanına bir SYSDBA kullanıcısı ile bağlanalım.
C:\> SQLPLUS / AS SYSDBA
Connected to an idle instance.
SQL> STARTUP; --> Şuan veritabanı öncelikle "NOMOUNT" moduna geçer. Ardından MOUNT ve son olarak OPEN.
STARTUP'dan sonra gelen prefixleri sonra detaylı olarak inceleyeceğiz.

NOMOUNT AŞAMASI: Oracle giriş parametre dosyasını okuyor (INITORA, SPFILE). Veritabanının hangi parametrelerle ve boyutlarla açılmasını gerektiğini algılar. Bu durumda Oracle Background Process'leri de çalıştırılır.
Bu kısmı "STARTUP QUIET" diyerek görmeden geçebiliriz.
SQL> STARTUP NOMOUNT QUIET;
ORACLE instance started.
Veritabanımız şuan da nomount modunda bekliyor. Henüz veritabanını açmadık.

MOUNT AŞAMASI: Veritabanı bu aşamada Control dosyalarını okur. Bu dosyalardan, datafile gibi kritik dosyaların yerlerini algılar fakat henüz açmaz. Bu yerlerin algılanmasıda tamamlandıktan sonra artık veritabanımız BG Process'leri ve Control dosyaları ile açılmaya hazırdır.
SQL> ALTER DATABASE MOUNT; -VEYA- STARTUP MOUNT; --> Veritabanımız nomount aşamasında ise ilkini, değilse ikincisini yazabiliriz.
Database mounted.

OPEN AŞAMASI: Şuan veritabanı datafile'lara girişini yaptı ve kullanıma hazır hale getirdi. Kullanıcılar bağlanabilir durumda.
SQL> ALTER DATABASE OPEN; -VEYA- STARTUP; --> Veritabanımız mount aşamasında ise ilkini, değilse ikincisini yazabiliriz.
Database opened.

Özetlemek gerekirse;

1) STARTUP; --> Önce nomount sonra mount ve son olarak open aşamalarını veritabanını taşır (eğer herhangi bir sorun ile karşılaşılmazsa).
2) STARTUP NOMOUNT; --> Veritabanını nomount aşamasına getirir.
MOUNT; --> Veritabanını mount aşamasına alır.
(Default)OPEN; --> 1'inci durum ile aynıdır.

Bunlara ek olarak ise;

1) STARTUP [MOUNT/NOMOUNT/OPEN] RESTRICT; --> Veritabanını restricted modda açmamıza yarar. Yetkili kullanıcılar dışında hiçbir kullanıcı bağlamaz. RESTRICTED SESSION yetkisi olanlar bağlanabilir. Açık veritabanında ise restricted session'ı şu şekilde açıp kapatabiliriz.
SQL> ALTER DATABASE ENABLE RESTRICTED SESSION;
SQL> ALTER DATABASE DISABLE RESTRICTED SESSION;
2) STARTUP [MOUNT/NOMOUNT/OPEN] FORCE; --> Veritabanını "SHUTDOWN ABORT" yaparak kapatır, istenilen şekilde açar. Bu şekilde açılan veritabanının herhangi bir başlangıç paramatresi olmasına gerek yoktur.
3) STARTUP [MOUNT/NOMOUNT/OPEN] EXCLUSIVE; --> Öncelikle belirtelim, startup mount exclusive deprecated edildi ve desteklenmiyor. Bu komut ise veritabanının sadece bu session tarafından mount veya open edilebileceğini gösterir.

Sırada SHUTDOWN komutları var. Detaylı olarak inceleyelim.

C:\> SQLPLUS / AS SYSDBA
Connected to:Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - ProductionWith the Partitioning, OLAP and Data Mining options

Şuan da bağlıyız. Yapabileceğimiz SHUTDOWN olanakları şunlardır;

1) SHUTDOWN [NORMAL]; --> Veritabanını "temiz" şekilde kapatır. Bütün kullanıcıların bağlı oldukları sessionlardan çıkmalarını bekler. Ardından instance'ı ve veritabanını güvenli bir şekilde kapatır. Bu sırada buffer_cache'de yazılmayı bekleyen dirty buffer'lar datafile'lara yazılır. Temiz olarak veritabanını kapatılır. Genelde kullanılmayan bir kapatma metodudur. Yeni kullanıcı kabul edilmez.
2) SHUTDOWN IMMEDIATE; --> Veritabanına bağlı olan bütün kullanıcıları atar ve commit edilmemiş işlemleri rollback yapar. Yeni kullanıcıların girmesini engeller. Shutdown normal'de olduğu gibi datafile'lara veriler yazılır. Veritabanı güvenle ve temiz olarak kapatılır.
3) SHUTDOWN ABORT; --> Veritabanını kapatmanın en hızlı ve aynı zamanda veritabanı için en zor yoludur. Veritabanı anında kapatılır ve bütün işlemler sonra ki Startup'ı bekler. Aslında bu kapatma türü Oracle'ı fazla etkilemez. Bu yöntem kesinkle ilk olarak kullanılacak yöntem olmamalıdır. Temiz bir kapatma metodu Oracle'da önemli rol oynar.
4) SHUTDOWN TRANSACTIONAL; --> Bu kapatma yöntemi ise bazı durumlar çok kritik olarak kullanılabilir. Önemli bir işlem yapılırken girilecek bir shutdown immediate komutu update veya insert yapan kişinin bütün işlemlerini rollback edebilir. Eğer tek kullanıcı ile çalışıyorsak ve işlemini bitirmesini bekliyorsak bu kapatma yöntemini uygulamalıyız. Kullanıcılar COMMIT ettikleri zaman veritabanından atılırlar ve temiz kapatma gerçekleşir. Commit edilmeyen sessionları bekleriz, bu komut ile. Yeni kullanıcılar kabul edilmez.

Genel olarak Oracle veritabanını bu komutlar ile kapatıp açabiliriz. Bu seçimleri yapmak tamamen DBA'in sorumluluğundadır. Hangi durumda hangi metodun kullanılacağına iyi karar vermek gerekebilir.

İyi çalışmalar,

Ogan

18 Şubat 2008 Pazartesi

10g FLASHBACK DATABASE önemli soru #1

Merhaba,

Bir önceki yazımda detaylı bir şekilde FLASHBACK özelliğinden bahsetmiştim.
Tonguç Hocamın bana yazdığı yorumun ufak bir demosunu hazırladım. Öncelikle soruyu tekrarlayalım.

Truncate veya purge edilen bir tablo, restore point aracılığı ile flashback database yapıldığı zaman geri gelir mi ?

Gerçekten çok güzel bir soru ve görelim geliyorlar mı ?

Herşeyden önce veritabanımızın Archivelog ve flashback modunda olup olmadığını kontrol edelim.
C:\> sqlplus / as sysdba

SQL> archive log list;
SQL> select flashback_on from v$database; YES olması gerekli.
SQL> select open_mode from v$database; --> READ WRITE olması gerekli.
SQL> select active_state from v$instance; --> NORMAL olması gerekli.

Bu aşamada herşey normal ise test tablomuzu yaratalım.

SQL> create table deneme tablespace users
SQL> as select * from user_objects;
SQL> select count(*) from user_objects; --> İçerisindeki toplam verileri kontrol edelim ve not alalım.
SQL> select tablespace_name, bytes, blocks, extents
SQL> from user_segments
SQL> where segment_name = 'deneme'; --> Kapladığı alanları bytes, blocks ve extents olarak görelim.
SQL> create restore point HASARDAN_ONCE; --> Şuanda veritabanımız restore point için hazır. HASARDAN_ONCE isimli restore pointimizi yaratalım.
SQL> truncate table deneme; --> Tablomuzda ki bütün verileri sildikten ve High Water Mark'ıda reset ettikten sonra testimize devam edelim (commit gerekmiyor, truncate bir DDL komutudur).
SQL> shutdown immediate;
SQL> startup mount; --> FLASHBACK DATABASE için mount modda olmalıyız.
SQL> FLASHBACK DATABASE TO RESTORE POINT HASARDAN_ONCE; --> Evet şuanda veritabanımızı o noktaya Flashback logları sayesinde geri alabildik.
SQL> ALTER DATABASE OPEN RESETLOGS; --> Flashback database'den sonra resetlogs ile veritabanımızı açıyoruz.
SQL> SELECT COUNT(*) FROM DENEME;
COUNT(*)
----------
22950
1 row selected.

Evet kilit noktaya geldik. Sonucu alabildiniz mi ? Not aldığınız önce ki sayının aynısını görebildiniz mi ? Sonuç olarak durum budur. Başarılı bir truncate table'dan sonra bütün verilerimizi tekrar alabildik. Bu noktada önemli olan şudur. Flashback logları ile undo'lar aslında farklı şeylerdir. undo bize tablonun truncate edildiğini işaret etsede, aslında flashback loglarında o tablo hala orada duruyor.

Sırada drop table purge komutu ile neler oluyor ona bakalım.

Şuanda veritabanımız zaten istediğimiz noktada. Test tablomuzda aynen yerli yerinde duruyor. Şimdide drop table purge diyelim.

SQL> DROP TABLE DENEME PURGE; --> Bunun ne yaptığını bir daha söyleyelim. Tabloyu recyclebin'e gitmeden düşürür. Bütün loglardan tamamen silinir. Peki, bunu flashback truncate table örneğinde olduğu gibi getirebilecek mi ?
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO RESTORE POINT HASARDAN_ONCE;
SQL> ALTER DATABASE OPEN RESETLOGS;
SQL> SELECT COUNT(*) FROM DENEME;
COUNT(*)
----------
22950
1 row selected.

İşte en kritik noktaya geldik. Truncate table ilede drop table purge ilede olsa fark etmez. İki denememizde de sonuç olumlu ve tablomuz hasardan_once restore pointinde olduğu gibi duruyor. Buna bağlı constraintler veya child recorlarda olsa fark etmeyecekti.

İyi çalışmalar,

Ogan

17 Şubat 2008 Pazar

Bir 10g özelliği, FLASHBACK

Merhaba,

Bu yazımda 10gR1 ve 10gR2'de geliştirilen ve sunulan FLASHBACK özelliğinden bahsedeceğim. Bazı özellikleri aslında 9i'de düşünülmüştür ve 11g'de uygulanmıştır. Dikkatlice uygulanması gerekir ve çok kritik durumlarda sizi ve DBA olarak çalıştığınız veri tabanını çok büyük baskı altından kurtarabilir.

FLASHBACK: Kısaca bir 10g özelliği olan "FLASHBACK" belkide bu zamana kadar Oracle'ın geliştirdiği en önemli teknolojilerden birisi. Ne olduğundan bahsedelim sonra da özelliklerine geçelim.

Bir çok çalışmaya göre Oracle'da oluşan hataların büyük bir kısmı kullanıcı hatalarıdır. Tablo düşürmek, içeriğini boşaltmak gibi. Bu tarz beşer hatalarını engellemenin yolları elbette vardır ama sonuçları önemli bir maliyettir. Aynı zamanda da çok zor takip edilebilir.

RESTORE POINT: Bu konuda ilk özelliğimiz yine 10g(release 2) ile gelen "RESTORE POINT" özelliği. PITR(Point In Time Recovery) gereksinimlerinde SCN(System Change Number) numarası veya Timestamp özelliklerinden yararlanılıyordu. DBA olarak SCN notlarını almak istesek içinde kaybolma ihtimalimiz olabilir. Onun yerine kritik zamanlarda kaydedilmiş Restore Pointler olursa, PITR gerçekleştirmemiz çok kolaylaşır. Syntax'i ise şöyledir:

SQL> Create restore point bu_bir_denemedir;
Bu restore point sayesinde az sonra anlatacağım "FLASHBACK DATABASE" konusunda ne kadar rahat dönüldüğünü görebileceğiz. Sonuç olarak Restore pointi çok önemli bir veritabanı uygulamasından önce yaratmak son derece mantıklıdır. Örnek olarak, kritik şema değişimlerinden önce veya flashback yapabilmek için olabilir.

FLASHBACK DATABASE: Oracle'ın bu zamana kadar yarattığı en stabil veritabanı kabul edilen 10g'nin(bir kısım release 1, bir kısım release 2) özelliğidir. Kendi loglarında aktif konuma getirildikten sonra kayıtları tutulan veritabanı değişimleri bu özellik sayesinde tamamen geri alınabilir.
Bütün veritabanını, bütün değişiklikleri ve kullanıcı hatalarını RMAN yedeği almaksızın geriye döndürebiliyoruz. Bu konuda tabii ki çok kritik noktalar vardır. Bütün veritabanını geriye almak, diğer kritik veri güncellemelerininde kaybolmasına sebep olabilir. Aynı zamanda yeni kayıtlarında yok olmasına.En büyük özelliği 10gR2 ile gelmiştir.
Flashback database resetlogs ile gerçektirildiği zaman kendi flashback logların reset olmaması. Restore point ve flashback kayıtları, flashback database gerçekleştirilip redo loglar resetlensede gerçekleştiriliyor ve tekrar dönülebiliyor. Bu bize veritabanı flashback ile geldikten sonrada yine hatalar olduysa geri dönme fırsatı sağlar ki çok avantajları olacaktır.
Gerekli komutlar ise şu şekilde olabilir. Flashback database yapabilmek için veritabanının "ARCHIVELOG" modunda olması gerekir. Ve aynı zaman veri tabanının "MOUNT" modda olması gerekir. Bir kaç tanede parametrenin set edilmesi lazım. Set edilmesi gereken parametrelerin default olarak kullandığını düşünelim.
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE FLASHBACK ON;
SQL> ALTER DATABASE OPEN;
SQL> SHUTDOWN IMMEDIATE; -->Bu noktaya kadar veri tabanı flashback logları üretti. Bir hata oluştu ve geriye dönmek istiyoruz.
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN ;
TO TIMESTAMP

15 Şubat 2008 Cuma

Neden Oracle 10g Release 2?

Merhabalar,


1 saat sonra İstanbul'a doğru her zaman alışkın olduğum günü birlik yolcuğum başlayacak. Benim için çok önemli bir seminere katılıyor olacağım.


Seminer hakkında geniş bilgi için: http://tonguc.blogspot.com/2008/02/neden-oracle-10g-release-2-cretsiz.html
Akşam 19:30 otobüsü ile Ankara'ya geri dönüyor olacağım. Bütün İstanbul yolculuklarım gece otobüste gidip gece otobüste gelerek geçti yahu :) Acaip yorucu oluyor hele ki seminere katılırken...
Seminerde görüşmek üzere!


Ogan

12 Şubat 2008 Salı

SGA & PGA

PGA, yani Program Global Area ya da Process Global Area bir çeşit memory'dir ve Oracle'a her bağlanan kullanıcıya bir miktar ayrılır (varsayılan 5M). Data ve control bilgilerini tutar.
"pga_aggregate_target" parametresi ile dinamik olarak(veritabanı spfile ile başlatıldıysa) ayarlanabilir. PGA düşük verilirse, veritabanına yeni sessionların bağlanması sıkıntı yaratabilir.


SGA, yani System(Shared) Global Area. Oracle instance'ının veri ve kontrol bilgilerini tutan memory gruplarından oluşur. SGA'in bileşenleri ise,
1) Buffer cache (db_cache_size)
2) Redo Log buffer (log_buffer)
3) Shared pool (shared_pool_size)
4) Java pool (java_pool_size)
5) Streams pool (streams_pool_size)
6) Large pool (large_pool_size)


SGA değerlerinin az atanması sonucu oluşabilecek durumlar;
1) I/O'ların artması,
2) Performansın düşmesi,
3) Out of memory hataları.


SGA değerlerinin çok atanması sonucu oluşabilecek durumlar;
1) RAM'in kaybı,
2) Kötü ayarlanması.


Buffer Cache: Bu yapı, Oracle'ın değiştirilen query'lerinin tutulduğu alandır. İçerisinde transactionlar sonucu fiziksel veri dosyalarından (datafile) alınan bilgileri tutar. Oracle bir query'i ilk defa çalıştırdığında bu bir "Physical I/O"'dur. Bu veri, buffer cache'de saklanır. Sonra ki sorguda bu alandan getirilir ve bir "Logical I/O" olur. Kesinlikle çok daha hızlıdır. Buffer cache'in miktarının çok olması saklanan verilerin artmasına ve fiziksel okuma boyutunun düşmesine sebep olabilir. Dolayısıyla performans artabilir. Veritabanı üzerine yapılan güncellemeler buffer cache'de "Dirty buffer" olarak saklanır. Zamanı geldiği zamanda fiziksel dosyaları yazılır. Commit edilmesi buffer cache'deki verileri datafile'lara yazmaz ! Veritabanı açıldığı ve çalıştığı zamanlarda bu alanları kontrol eden background processler vardır (Bknz. SMON, DBWR,CKPT). Bu değer genelde yüksek tutulmaya çalışılır.
Redo Log Buffer: Bu yapı veritabanı üzerinde olan her değişikliği saklar ve en geç üç saniyede bir "Online Redo Log" dosyalarına yazar. Genelde 5-12 M arası bir değer alır. Yüksek ya da düşük olması bekleme olaylarının oluşmasına sebep olabilir.
Shared Pool: SQL ve PL/SQL kodlarının çalışma planlarının oluşturulduğu alandır (Bknz. Bind Variable, Cursor Sharing). Oracle veritabanın ve kullanıcının bütün çalışma planlarının parse edildiği yerdir.
Java Pool: Java procedure'lerinin kullanıldığı alandır. Oracle üzerinde herhangi bir java kodu çalıştırılıyor ise bu memory belirli bir miktarda set edilmelidir.
Streams Pool: Bu alan Oracle'ın streams component'leri içindir. Eğer set edilmezse ve kullanılıyorsa Shared Pool'un %10'u kadar değer alır.
Large Pool: I/O server processleri ve backup/restore operasyonları için ayrılmış alandır (RMAN operasyonları gibi).
Oracle bu değerleri çoğu zaman veritabanı yöneticisinin ayarlamasını beklemez. Aslında bu değerleri dinamik olarak ayarlayacak bir yapıya sahiptir.
SGA_MAX_SIZE: Oracle'ın startup komutu verildiği zaman işletim sisteminden alacağı toplam RAM'i gösterir. Bu RAM'in yetmediği durumlarda Oracle daha fazla RAM alabilir. Eğer LOCK_SGA parametresi TRUE olarak set edildi ise daha fazla RAM alamaz!
SGA_TARGET: Bu parametreki değeri SGA_MAX_SIZE parametresi ile aynı değerde set edersek, Oracle SGA'in componentlerinin otomatik olarak o anki kullanıma göre set edilmesine sağlar. Ve DBA olarak müdahale edilecek durumların azalmasını sağlar. Yoğunlukla kullanılan bir yapıdır. Sonuç olarak DBA'in sürekli bu parametreleri takip etme gibi bir sanşı olmayabilir. SGA_TARGET tanımlanmışken SGA'in bileşenleri 0 dışında bir değere ayarlanmışsa, Oracle o değerden daha düşük ayarlamaz.


SGA ve PGA değerlerinin ilk olarak atanması üzerine çalışmak gerekebilir. 32 bit sistemlerde SGA değerini 1.7G üzerine çıkarmak mümkün değildir. Fakat bir takım ayarlardan sonra bu değer çok ufakda olsa arttırılabilir. 64 bit sistemlerde ise sınırlama yoktur.
SGA ve PGA değerlerinin Oracle tarafından tavsiye edildiği X$, yani sys.v_$, yani v$ viewları ise şunlardır:
v$pgastat, v$pga_target_advice, v$pga_target_advice_histogram.
v$sga, v$sgastat, v$sgainfo, v$sga_dynamic_components, v$sga_target_advice.


İyi çalışmalar,


Ogan

Kullanıcı güvenliği ve yetkileri

Belki de Oracle veritabanında en önemli konulardan birisi kullancıların yetkileridir. Hangi kullanıcıya hangi yetkilerin verildiğinin çok iyi takip edilmesi ve dikkatli verilmesi gerekir.
Bir kullanıcı yaratalım,
SQL> create user deneme identified by deneme default tablespace quota unlimited on ;
Bu yarattığımız kullanıcı üzerine hiçbir yetki bulunmuyor. Şuan da hiçbir şekilde veritabanına bağlanıp objeler yaratamaz. Hatta veritabanına bağlanamaz.
Projenin gerektirdiği kadar "privilege"'a sahip ve proje ile ilişkili bir isimde "role" yaratalım.
SQL> create role developer;
"developer" ismiyle bir role yarattık. Bundan sonra privilegelarımızı bu role'e grant ederek dağıtacağız.
SQL> grant create session to developer;
SQL> grant developer to deneme;
developer role'üne create session privilege'ı verdik ve onuda deneme kullanıcısına verdik. Böylece deneme kullanıcısının üzerine bir tane "create session" yetkili rolü olmuş oldu. Bundan sonra deneme kullanıcısı veritabanına bağlantısını sağlayabilir.
SQL> grant administer database trigger to developer;
otomatik olarak deneme kullanıcısı "administer database trigger" yetkisine sahip oldu.
Bu şekilde yetkilerimizi dağıtırsak, takip etmesi ve tekrar yetkilendirmesi çok daha rahat olacaktır. Kesinlikle tek tek privilege atamayın!

Ve unutmayın, object privilegeları veren user drop edildiği zaman o user tarafından yetkilendirilen kişinin üzerinden de kalkar. Fakat system privilegelar kalıcıdır...

İyi çalışmalar,

Ogan

HWM (High Water Mark)

HWM yani High Water Mark, Oracle'da segmentleri kullanılan ve kullanılmayan bloklar olmak üzere böler. High Water Mark'ın altında kalan blocklarda veri bulunuyor demektir ve silinebilir.
Dolayısıyla Oracle "Full Table Scan" yaparken HWM'ın altında kalan yerleri tarar. Oracle'da HWM asla inmez ve sürekli artan bir grafik çizer. Bu grafik ise kullanıcının tabloya girdiği verilerle ilişkilidir. Tablo extent ve blocklar aldıkça, HWM'da genişlemeye devam eder. Yüksek kayıtlı bir tablonun verileri az kayıtlı bir tabloya göre daha yavaş getirmesinin ana sebebi budur.
Ne yazık ki Oracle'da HWM'ı otomatik olarak düşüren bir yapı yoktur. Bir tablodan "delete from" komutu ile silinen kayıtların HWM'ı her zaman sabit kalır. Ve azalmadığı içinde her zaman full table scan eski HWM kadar kayıt olduğunu zannederek tabloyu tarar. Bundan kurtulmanın bir takım yolları vardır.

"alter table move;" diyerek tablo'nun rowid'lerini değiştirir. Buda öncelikle o rowidler üzerine çalışan index varsa kırılmasına sebep olur. Aynı zamanda da HWM'ın da o an tablodaki kayıt kadar extent ve block'a inmesini sağlar.
Bir başka yol ise "row movement"dır. "alter table enable row movement" diyerek o tablonun rowidlerinin hareket edebilmesini sağlarız. Ardından da "alter table shrink space compact" diyerek HWM'ın gördüğü boş alanlardaki çarpık duran verileri defragment ederiz. Son olarak "alter table shrink space" diyerekde HWM'ın gördüğü yüksek blockları tablonun normal blocklarına indiririz.

HWM, production veri tabanları için çoğu zaman baş ağrısı yaratabilen bir durum olabileceği gibi fark edilmeside zaman alabilir. "user_segments, dba_segments" bunlardan gerekli bilgiler toplanabilir.

İyi çalışmalar,

Ogan

RMAN ile Backup/Restore/Recover

Selamlar,


Öncelikle bu yazının çok daha kapsamlı halini aşağıdaki bağlantıya tıklayarak bulabilirsiniz;



Oracle Recovery Manager (RMAN) - Recovery Catalog Database



RMAN yani Recovery Manager, Oracle veritabanının yedeğinin alınmasını ve yedekten dönülebilmesini sağlar. Temel olarak aslında bu işe yarar. Bunun dışında bir sysdba'in RMAN kullanmasının sebepleri şu şekilde sıralanabilir:
RMAN,


1) Hot(online) yedekleme ve artımlı (incremental) yedekleme yapabilir.
2) Partial(PIT-Point in Time) veya bütün kurtarma (complete recovery) yapabilir.
3) Herhangi bir kısmi yedek (incomplete backup) ile karşılaşılırsa, tamamlayabilir.
4) Spfile ve controlfile'ların yedeğini alabilir.

5) Kaset veya Oracle Secure Backup ünitesine yedekleme yapabilir.
6) Blok tamiri yapabilir.

Rman dışındaki yedekleme sistemlerinde ve tekniklerinde (Cold backup, export/import, data pump) çalışan (online) veritabanının yedeğini sağlıklı bir şekilde asla alamayız. Evet, "tutarlı" olacaktır zira veritabanı kapalıyken ve kapatılırken de normal, transactional veya immediate seçenekleri ile kapatılmış ise kontrol dosyasının, redolog'ların, datafile blok başlıklarının gösterdiği SCN numaraları aynı olacaktır ve bu da veritabanının alınması planlanan yedeğini tutarlı kılmaktadır.
Öncelikle RMAN ile sağlıklı bir şekilde yedek alabilmemiz için, veritabanımızın ARCHIVELOG modunda olması gerekmektedir. Bu esnada konuda biraz uzaklaşıp, archivelog nedir ona bakalım.
Archivelog, veritabanımızda gerçekleşen transaction hareketlerinin geçmişlerini tutan bir log dosyasıdır. Online redolog dosyalarının yedeğidir. Veritabanımıza ait redologların dolmasının ardından diğer redo log'a geçiş yapılırken, geçiş yapılmadan önce kullandığımız redo log'un archivelog'u alınır. Eğer sistemde 3 adet redo log varsa, hepsi bir tur döndükten sonra ilk baştaki veri geçmişinin üzerine yazılmaya başlanır. Archivelog'lu veritabanında bu sıkıntı ile karşılaşılmaz. Redo log grupları dönmeye devam ederken, hepsinin geçmişleri tutulur. Ancak dikkate alınması şart olan husus archivelog'ların tanımlandığı alanların (DB_RECOVERY_FILE_DEST veya LOG_ARCHIVE_DEST_n (1-10 arası)) dolmaması. Eğer bu alanlar dolarsa, redolog'lara yazım, archivelog yazması tamamlanmadığı sürece yapılamayacak ve veritabanı askıya alınacaktır. Veritabanı instance'ı bir arka plan görevinin zorlaması ile sonlandırılmayacak ancak veritabanı üzerindeki hiçbir kullanıcı işlem (transaction) yapamayacaktır.
Veritabanımızı archivelog'a geçirelim (Destination kısmını Oracle default olarak düşünelim).
Veritabanımızın mount modunda açılmış olmasına dikkat edelim.



SQL> shutdown [normal | transactional | immediate];
SQL> startup mount;
SQL> alter database archivelog;

SQL> alter database open;
SQL> archive log list;

Evet bu andan itibaren redo log'larımızın geçmişleri tutuluyor. Artık RMAN ile archivelog yedeği alabiliriz. Bir deneme yapmak istiyorsanız eğer;



SQL> alter system switch logfile;
SQL> archive log list;

Komut satırında veya terminalde iken:


 # rman target username/password (yetkili kullanıcı ile) bağlanalım.


RMAN> BACKUP DATABASE;


dediğimiz anda veritabanımızın online olarak yedeği alınır. Bu yedeğe archiveloglarıda eklemek istersek;

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;


yazmamız gerekir. Bu sayede veritabanımızın yedeği ve bütün archivelogların yedeği alınır. Yedeği alınmış archivelogları, yedek alınırken silmek istersek;


RMAN> BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT;


yazmamız gerekir. Bu sayede bütün veritabanının ve archivelogların yedeği alınır, yedeği alınmış ve artık yer kaplayan duruma gelmiş archiveloglar RMAN tarafından silinir.


Bu sırada archivelog dosyaları elle silinmiş ise (yer problemlerinden dolayı veritabanındaki geçici askıya alınma durumunu gidermek için silinmiş olabilir) şu komutu çalıştırmalıyız;


RMAN> CROSSCHECK ARCHIVELOG ALL;


Bu sistem bizim RMAN ile yapabildiğimiz level 0 yani bütün veritabanı yedeklemesidir. Rman'in bir başka özelliği ise artımlı yedek alabilmesidir. Bu tamamen bir stratejidir ve gerekli durumlarda kullanılabilir.


RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;


bu komut tam yedekleme yapılmasını sağlar. Farkı ise catalog oluşturarak, sonra ki incremental level'ları için bir çeşit flag tutulmasını sağlar. Bunun yanı sıra RMAN, blok sıkıştırma yöntemi ile yedekleme sırasında farkettiği kullanılmayan blokları önce sıkıştırır ve ardından yedeğe dahil edilmesini engeller.


RMAN>BACKUP INCREMENTAL LEVEL 1 DATABASE;


bu komut ile level'lar arasındaki farkın yedeğini almış oluruz. Geliştirilen stratejiye göre seviyeler değiştirlebilir.


Özet olarak bu şekilde veritabanımızın sağlıklı yedeğini alabiliriz. Bu yedeğin düzgün alınıp alınmadığını ise;


RMAN> RESTORE DATABASE VALIDATE;


komutu ile anlayabiliriz.



RMAN> LIST BACKUP;


Yukarıda komut ile de aldığımız yedek(ler) hakkında bilgi elde edebiliriz.

Rman'in çeşitli restore/recover senaryoları vardır. Eğer controlfile'larımız ile ilgili problem yaşadıysak incomplete recovery yapmamız gerekir. Incomplete recovery yapıldığı zaman redo loglardaki tutulan sayılar ile önceden yedeği alınmış controlfile'ların sayıları tutmayacağı için redo log'larımızı resetlememiz, yani sekanslarını sıfırlamamız, içlerini tamamen boşaltmamız ve veritabanını resetlogs komutu ile açmamız gerekir.


Eğer datafile'larımız kayıpsa, sadece restore ve recover database komutları ile veritabanını ayağa kaldırabiliriz.


Rman ile point in time recovery yapılabilir. İstediğimiz bir saate veya istediğimiz bir SCN(system change number)'a dönebiliriz. Bunuda rman, yedeğimizin üzerine archivelog'ları uygulayarak yapar.

Bu noktada en önemli nokta, RMAN yedeğinin mutlaka aynı işletim sistemi ve aynı Oracle versiyonlarında ayağa kaldırılmısı gerektiği. Veriyonu ve işletim sistemi farklı bir sistemde yapılabilecek en mantıklı yedekten dönme export/import olacaktır.

Rman'in yedekleme yapısı ise şöyledir.
Veritabanının ve arşivlerin yedeği alınır,
Backup, veritabanına işlenir,
Üzerine veritabanının yedeğinin alındığı zamandan bu zamana oluşan arşivler uygulanır,
En son commit'e kadar veritabanı getirilir. Tabii bu senaryoda redolog dosyalarının olduğunu veya hiçbir redolog grubundaki üyelerin tamamen yok olmadığını düşünüyoruz. Aksi halde en son yapılan commit'e kadar veritabanını getirmenin imkanı yoktur. Veri kaybı kaçınılmazdır.

Son olarak, archivelog'a alınmamış bir veritabanının %100 sağlıklı ve kullanılabilir yedeğinin alınması kesinkle doğru değildir. Mutlaka RMAN ile yedekleme stratejilerinin geliştirilmesi gerekmektedir. Bu şekilde olası veri kayıplarından veritabanımızı büyük ölçüde korumuş oluruz ve veritabanının çöktüğü anlarda çabuk dönüş gerçekleştirebiliriz.


İyi çalışmalar,

Ogan

SPFILE'da değişiklik yapabilmek.

SPFILE, oracle'ın başlangıç parametrelerinin bulunduğu binary bir dosyadır. Oracle bu teknolojiye 9i versiyonunda geçti. Geçmesinin en büyük sebebi ise INITora dosyasında yapılamayan dinamik parametre değişiklikleri oldu.
Artık "alter system" yazarak spfile ile açılmış veritabanında izin verilen değişiklikleri "scope=both" yazarak hem bulunduğumuz session için hemde sonra ki startuplarda geçerli olmak üzere kaydedebiliyoruz. Bu değişiklikleride istersek initora dosyasında elle yapıp, ardından "create spfile from pfile" diyerek ya da "alter system" komutu ile yapabiliriz.
Oracle veritabanı spfile olmadan 9i'den sonrada açılabiliyor. pfile, yani initora ile veritabanını başlatmamız mümkün. Fakat spfile'ın getirdiği dinamik parametre değişikliğini yapamıyor olacağız.
Spfile'ın bir başka büyük avantajı ise, RMAN(Oracle'ın backup/restore/recover tool'u) ile birlikte yedeğinin alınabilmesi. RMAN, controlfile ve spfile dosyalarının yedeğini 9i versiyonundan bu yana alabiliyor.
Veritabanımızın spfile ile mi yoksa pfile ile mi çalıştığını ise şu şekilde anlayabiliriz:
select name, value from v$parameter where name like '%spfile%';
Eğer value kısmında spfile'ın yeri gösterilmişse veritabanımız spfile parametre dosyası ile başlatılmış demektir.
Veritabanı spfile ile başlatılmış ise, pfile(initora) text bazlı parametre dosyasından açık veritabanına yeni bir spfile yaratamayız. Öncelikle kapatmamız gerekir. Örnek olarak,

SQL> create spfile from pfile;create spfile from pfile
*ERROR at line 1:
ORA-32002: cannot create SPFILE already being used by the instance

Spfile dosyasının, RMAN ile yedek alınan her veritabanında mutlaka yedeğinin controlfile'lar ile birlikte alınması gerekir. spfile ve pfile'ın kaybolması durumunda oluşturulacak, yedeği alınmamış bir pfile'ın veritabanını ilk yüklenmiş haline döndüreceğini unutmayalım. Sonuç olarak kullanılan veritabanındaki bütün memory, ram ve diğer ayarlarını kaybetmiş olacağız.

Son olarak, RMAN'de spfile'ın yedeğini "backup spfile" yazarak alabiliriz.

İyi çalışmalar,

Ogan
Takip et: @oganozdogan