Oracle Veritabanı: Süresi Bitmiş ve Kilitli Kullanıcılar - Expired ve Locked Kullanıcılar

Hesap Kilitlenmesi (Account Locking)

Bir hesap ya bir dba tarafından ya belli parametrelere bağlı olaraktan (örnek olarak:failed_login_attempts, password_lock_time) kilitlenebilir. Password_lock_time'a göre kilitlenirse Locked(timed)  olarak account status de gözükür.

 select * from dba_users where account_status='LOCKED'; 

Hesap Nasıl Unlock Edilir?

Hesapları unlock etmek için ya yukarıda verdiğimiz 2 parametreyi failed_login_attempts ve password_lock_time'ı unlimited'a çeker ve toad'da kullanıcının üzerine sağ tıklayıp unlock ederiz ya da aşağıda yazdığımız sorgunun çıktılarını kopyalayıp çalıştırırız.

 select 'alter user ' ||username || ' account unlock; ' from dba_users where account_status='LOCKED';

Şifrelerin Expire olması (Password Expiration)

Şifrelerin expire olma durumu password_lifetime parametresine göre belirlenir.

Şifreler Nasıl Normal Statülerine Döndürülürler?

Şifrelerin expire olması durumunda tekrar kullanıcılara şifre vererek "expire" statüsünü değiştirebiliriz.

 alter user kullanıcı_adı identified by şifre ;  

Yeni şifreler verilirken ise bazı profil değerleri vardır. Yeni verilecek şifreler bunlara göre verilmelidirler.

Bu parametrelere örnek olarak Password_reuse_time,password_reuse_max'ı örnek gösterebiliriz.

Oracle E-Business Suite: Profil Değerlerini Set Eden Sql

Geçenlerde Oracle E-Business Suite'de yaşadığım bir problemden dolayı Application'a bağlanamadım. Bu problemin sorunu yaşamadan önceki yaptığım profil ayarlarıyla ilgili olduğunu düşündüm. Nitekim haklıymışım ama bunu çözene kadar ecel terleri döktüm. Size önerim profile değerlerini test ortamlarda mutlaka test ederek uygulayın. Profil değerlerinin sisteme etkisi çok büyük.

Aşağıdaki sql ile uygulamada kayıtlı bütün profil değerlerini bulabiliriz. Bu sayede eski değiştirdiğim profili ve değerini bulabildim. Bu script'in genel olarak kullanışlı olduğunu düşünüyorum çünkü bu sayede sisteme yüklenen ve kontrol edilmesi istenen profiller ve değerleri kolayca bulunabilinirler.

Script'de istenen başka değerleri sonuçları kısarak aramak için aşağıda comment'li olan yerlerde bazı kısımların commentlerini  ihtiyacınıza göre kaldırabilirsiniz.

 select p.profile_option_name SHORT_NAME, n.user_profile_option_name NAME,  
 decode(v.level_id, 10001, 'Site', 10002, 'Application',   
 10003, 'Responsibility', 10004, 'User', 10005, 'Server',   
 10007, 'SERVRESP', 'UnDef') LEVEL_SET,   
 decode(to_char(v.level_id), '10001', '',   
 '10002', app.application_short_name,   
 '10003', rsp.responsibility_key,  
 '10005', svr.node_name,  
 '10006', org.name,  
 '10004', usr.user_name,  
 '10007', 'Serv/resp',  
 'UnDef') "CONTEXT",  
 v.profile_option_value VALUE  
 from fnd_profile_options p,  
 fnd_profile_option_values v,  
 fnd_profile_options_tl n,  
 fnd_user usr,  
 fnd_application app,  
 fnd_responsibility rsp,  
 fnd_nodes svr,  
 hr_operating_units org  
 where p.profile_option_id = v.profile_option_id (+)  
 and p.profile_option_name = n.profile_option_name  
 and upper(n.user_profile_option_name) like upper('%&profile_name%')  
 and usr.user_id (+) = v.level_value  
 and rsp.application_id (+) = v.level_value_application_id  
 and rsp.responsibility_id (+) = v.level_value  
 and app.application_id (+) = v.level_value  
 and svr.node_id (+) = v.level_value  
 and org.organization_id (+) = v.level_value  
   
 -- Buradaki ayarda eğer profil değerlerini biliyorsak tırnak içerisine   
 -- istediğimiz değeri atayabiliriz.  
 -- and v.profile_option_value=' '  
   
   
 -- Hangi level'da olduğunu da ayarlayabilmek için gereklidir.  
 -- Eğer aradığımız profilin hangi level için set edildiğini biliyorsak buradan   
 -- o level comment'ini kaldırırız.  
 --and v.level_id='10001' -- Site  
 --and v.level_id='10002' -- Application  
 --and v.level_id='10003' -- Responsibility   
 --and v.level_id='10004' -- User  
 --and v.level_id='10005' -- Server  
 order by short_name, level_set;  

Değerleri bulduktan sonra sıra o profili yeni değerinden daha küçük bir değere geri döndürmeye gelmişti. Bunun için de aşağıdaki scripti kullandım.  Bu script sayesinde OAM dashboard'una girmeden işimi halledebildim. Aşağıdaki script ile ayrıca klon alımı gibi durumlarda hızlıca kurumsal değişiklikler yapılabilinir.

 DECLARE  
 stat boolean;  
 BEGIN  
 dbms_output.disable;  
 dbms_output.enable(100000);  
 stat := FND_PROFILE.SAVE('profil_adı', 'profil_degeri', 'seviyesi');  
 IF stat THEN  
 dbms_output.put_line( 'Stat = profile guncellendi' );  
 ELSE  
 dbms_output.put_line( 'Stat = HATA - profile guncellenmedi' );  
 END IF;  
 commit;  
 END;  
 /  

Örnek Kullanım:

 DECLARE  
 stat boolean;  
 BEGIN  
 dbms_output.disable;  
 dbms_output.enable(100000);  
 stat := FND_PROFILE.SAVE('GL_DEBUG_MODE', 'No', 'SITE');  
 IF stat THEN  
 dbms_output.put_line( 'Stat =  profile guncellendi' );  
 ELSE  
 dbms_output.put_line( 'Stat = HATA - profile guncellenmedi' );  
 END IF;  
 commit;  
 END;  
 /  

Oracle Veritabanı: ASH - Active Session History

ASH verisi active database session'ından her saniye alınan bilgiler doğrultusunda oluşturulur. Bu database session bilgileri v$session ve v$session_wait view'larından alınır. Bu bilgiler hafızada bulunur. ASH verilerine v$active_session_history_view view'ından erişilir. AWR snapshot'ından alınan bilgiler ASH bufferından alınır. MMNL process'i tarafından yönetilir.

ASH için gereken snapshot'lar 30 dakika boyunca her saniye boyunca çekilir ve v$active_session_history view'ına konur. Bu süre geçtikten sonra AWR'ın kullamına açılır. (dba_hist_active_sess_history) ASH ve AWR arasındaki temel fark baktıkları zaman aralığıdır.

ASH default olarak ayarlanmaktadır; ancak lisanslı bir üründür.

ASH raporları Enterprise Manager'dan çalıştırılmak istenirse şu sıra izlenebilinir. Oracle Database> Performance> Availability> Schema> Administration altından belirli bir zaman seçilerek ASH raporu alabiliriz.

ASH Raporu Nasıl Çalıştırılır? 

$ORACLE_HOME/rdbms/admin altındaki ashrpt.sql çalıştırılınca ASH raporunu sqlplus'tan çalıştırmış oluruz. Yukarıda da Enterprise Manager'dan nasıl çalıştırılabileceğini göstermiştik.

Bu raporu çalıştırdığımızda bize bazı detaylar sorulacaktır. Bunlar:

- Report Type: [html|text]
- Instance Number : Rac için farklı bir değer verilebilinir. Rac değilse 1 default değeri seçilir.
- Begin Time : İncelemek için nereden başlanılacağı sorulur. Default değeri -15 dakikadır.
- Duration : İnceleme süresini belirtir. Standart olarak sysdate- begin time şeklide kabul edilir. Böylece o ana kadarki rapor incelenebilinir.
- Report Name : Rapor Adı

DBA_HIST_ACTIVE_SESS_HISTORY:

DBA_HIST_ACTIVE_SESS_HISTORY tablosu hafızadaki active session history bilgilerini daha dar kapsamlı bir şekilde tutar. V$ACTIVE_SESSION_HISTORY tablosundan alınan snapshotlardan oluşur.

V$ACTIVE_SESSION_HISTORY:

Oracle yakın zamanda gerçekleşmiş session bilgilerini belirli bir süre için v$active_session_history tablosunda tutar. Her session için her saniye bir snapshot alınır.

Oracle Veritabanı: DBVERIFY Nedir?

DBVERIFY bir komut satırı aracıdır. Fiziksel data'da bir bozukluk olup olmadığını kontrol eder. DBVERIFY online veya offline database'ler üzerinde veya backup'lar üzerinde kullanılabilir. Bu aracın ilk amacı bir database'in backup'ının kullanılabilir olup olduğunu kontrol etmek, restore yapmadan önce uygulanabilir olup olmadığına bakmaktır. Database'in offline olması integrity check'lerin daha hızlı yapılmasını sağlar.

DBVERIFY'ın hedefi datablock'larıdır. Controlfile ve redo logs'lar üzerinde işe yaramazlar.

DBVERIFY'ın kullanım örneği:

dbv FILE=users.dbf FEEDBACK=100  blocksize=8192

Bu ekranda "Pages" olarak nitelenen şey "block"'lardır. Toplam bir dosyada incelenen block'lar "Total Pages Processed (Data)" kısmında ise incelenen datafile içindeki block sayısı, altında da bunlardan corrupt olan'lar belirtilmiştir.

"Total Pages Influx", database açıkken dbverify çalıştırıldığında bazı bloklar kullanıldığı için dbverify tool'u birden fazla okuma yapar. Bu yüzden bazı blokları birden fazla görüntüsünün alınması gerekir. Bu birden fazla okunan bloklar Total Pages Influx kısmında belirtilir.

Referans:
http://docs.oracle.com/cd/B10501_01/server.920/a96652/ch13.htm
http://onlineappsdba.com/index.php/2008/07/03/how-to-check-corruption-in-database-using-dbverify/
http://www.dba-oracle.com/tips_oracle_dbv_verify.htm
http://www.orafaq.com/wiki/DB_Verify

Oracle Veritabanı: Block Checking ve Block Recovery

Block Media Recovery'nin amacı corrupt olmuş data block'ların recover edilmesidir.  Mean Time To Recover(MTTR) zamanınu indirger.

Eğer sadece bir tane bile blok bile corrupt olursa bütün datafile offline'a çekilmesi gerekir ve backup dönülmesi gerekir. Buna  karşılık block media recovery ile datafile'ı offline'a çekmeden sorunun düzeltilmesini sağlar.Block Media Recovery ile recovery sırasında datafile'ın online kalmasını sağlar. Fiziksel bozulma olaylarında bizim işimize çok yarar.

Corrupt Block'lar Nasıl Belirlenir?

V$DATABASE_BLOCK_CORRUPTION tablosunda database tarafından belirlenen bloklar listelenir.

-Fiziksel Bozulma:

Database Checksum'ı sonucunda eğer bloklarda sorun olursa blok "physical corruption" olarak listelenir. Checksum işlemi database'de default olarak ayarlıdır. Eğer checksum işlemi disable edilip,  cpu overhead'ini azaltmak istersek database backup'ında "nochecksum" parametresini kullanabiliriz; ancak genel olarak database kontrolü sırasında yapılmasını engelleyemeyiz.

-Mantıksal Bozulma:

Database Checksum işlemini yaptığında her zaman bazı blokların değeri doğru çıksa da içerik olarak istikrarsız olabilir. Block Media Recovery ile bu düzeltilemez.

Mantıksal bozulma kontrolü default olarak set edilmemiştir. Onun yerine backup'taki checklogical  parametresi ile, restore, recover ve validate komutlarında  bunu sağlayacak işlemler vardır. Bu yazımızda logical corruption düzeltme metodu hakkında bilgiler bulabilirsiniz.

Database'de fark edilen corrupt olmuş blok'lar ise v$database_block_corruption'da bulunmazlar.

Block Media Recovery İçin Gereklilikler:

Database archivelog'da bulunmalıdır ve mount mode'da veya open olarak çalışmalıdır. Database Archivelog Mode'a Nasıl Alınır?

Datafile'ların backup'ları full ve level 0 backup'lar olmalıdır ve corrupt block'tan daha eski backup'lar olmalıdır.

Rman sadece archived redo log'ları kullanarak recovery yapabilir. Buradan da tekrar archivelog yedeklemenin önemini görebiliriz.  Archivelog yedeklenmesi

(Opsiyonel)Flashback Database'in enabled olması lazımdır; eğer rman'in flashback log'larına bakıp buradaki sağlam versiyonlarına göre düzeltilmesi isteniyorsa.

Block Corruption Nerelerden Görülebilinir?

-List Failıre,Validate, Backup .. Validate gibi komutların sonucunda görülebilinir.
-Alert log'larında  belirtilir.
-v$database_block_corruption view'ında belirtilir.
-Trace File'larında bulunur.
-Analyze Table ve Analyze Index sonuçlarında çıkabilir.
-DBVERIFY komutuyla (dbv)
(dbv file= BLOCKSIZE=8192
LOGFILE=test.log)

Block'lar Nasıl Recover Edilir?

Bütün corrupted olarak işaretlenmiş block'ların recovery'si için rman'e bağlanıp "recover corruption list" komutuyla düzeltebiliriz.

RMAN>recover corruption list;  

veya

 RMAN>BLOCKRECOVER corruption list;  

Bu işlemden sonra veritabanındaki  v$database_block _corruption view'ın bilgiler silinir.

select * from v$database_block_corruption  

Oracle Veritabanı: Rman Best Practises - Rman'de Tavsiye Edilen Aksiyonlar

1- Block Checking Özelliği Açılır.

Block Checking sayesinde corrupt block'ları  fark edebiliriz. Corrupt block'lar bizim data okuyamamıza veya data kaybımıza neden olabilir.

Corrupt Block'lar Logical veya Physical şekilde olabilir. Bu block'lar keşfedildikleri durumda rman'le kolayca düzenlenebilirler.

 SQL>alter system set db_block_checking = true scope=both;  

Scope=both diyerek hem session bazlı hem de kalıcı olarak parametremizi set ederiz. Bu parametrenin set edilmesi demek database'imizin zaman zaman block'ların checksum'ını kontrol etmesi demektir. Bu da bizim sistemimizde performans artışlarına neden olabilir.


2- Rman Backup'ları için Block Tracking Özelliğinin Açılması:

Rman backup'larında en son alınan backup'takine göre değişmiş olan blokların backuplanmasını sağlar. Bu işlemde backup alımındaki zamanı azaltırken yine performansta bir düşüşe neden olabilir.

Rman'de backup set alınırken zaten boş block'lar backup'lanmazken sadece dolu olanlar backup'lanmaktaydı. Bu özelliği kullanırsak bu dolu olanlardan da sadece en son backup'a göre değişmiş olanları backup'larız. Bu sayede backup size'ları önemli oranda değişebilir.

 SQL>alter database enable block change tracking using file '/u01/tracking/change_tracking';

Yukarıdaki komutumuzda Linux işletim sistemizde bulunan bir dosyada saklanmak üzere block tracking işlemini gerçekleştiririz.

3- Log Gruplarının ve Üyelerinin Çiftleştirilmesi ve Archive Log Destination Parametresinin Arttırılması:

Log dosyalarının çoğaltılması işlemleri archivelogların corrupted olması, onların bulunduğu disk'lerin çökmesi durumunda bize geri dönüş için bir seçenek oluşturur.

SQL> alter system set log_archive_dest_2='location=+ARCHLOG2' scope=both;  
SQL> alter database add logfile member '+ARCHLOG2/redo21.log' to group 1; 

Buradaki örneğimizde hem log grubumuzu çoğaltırız hem de gruplarımıza ekstra bir eleman ekleriz.

Log yönetimi 1 ve  log yönetimi 2 yazılarımızdan daha fazla bilgi edinebiliriz.

4- Database Backup'ı Gerçekleştirilirken "Check Logical" Paramtresi Kullanılmalı:

Bu parametre aşırı önemlidir. Genelde backup örneklerinde çok rastlanılmaz. Bu parametrenin kullanılması mantıksal  olarak block corruption aramasını gerçekleştirir. Böylece aldığımız bir backup'ın başarılı olduğundan emin olabiliriz çünkü backup'lar completed olsalar bile logical corruption içerebilirler.

RMAN>backup check logical database plus archivelog delete input; 

Bu örneğimizde database'in archivelog ile beraber bir backup'ı alınırken backup'ın corruption'lara karşı bir check'i gerçekleştirilir. Ayrıca archivelog'lar backup'landıktan sonra kopyalar diskten silinir ve diskten yer açılır.

5- Backup'ların Test Edilmesi:

Backup'ımızın tamamen kullanılabilir olmasının test edilmesi validate komutuyla olur. "Validate" komutunun birden fazla kullanım yöntemi vardır.

İlkinde Rman'e girip backupları validate edebiliriz.

RMAN> VALIDATE DATABASE;  
   
RMAN> VALIDATE BACKUPSET 22;  
   
RMAN> VALIDATE DATAFILE 1 BLOCK 10;  

İkinci komutumuzu "Backup Validate"'dir. Bu komut'da gerçekten backup alınmaz. Sadece backup alınması durumunda herhangi bir sorunla karşılaşılıp karşılaşılmayacağını kontrol eder.

Hem physical hem de logical block check yapan ve corruption arayan komut aşağıdaki gibidir.

RMAN> BACKUP VALIDATE   
  CHECK LOGICAL   
  DATABASE   
  ARCHIVELOG ALL;  

Üçüncü komutumuz "Restore Validate"'dir. Bu komutumuzda da aldığımız backup'ı geri dönmeden önce  validate ederiz. Bu komutla gerçekten restore etmeyiz. Restore edilmesi durumunda çıkacak sorunlar için kontrol yaparız.

RMAN> RESTORE DATABASE VALIDATE;  
RMAN> RESTORE ARCHIVELOG ALL VALIDATE; 

.
6- Her Backup Piece'de Sadece Bir Datafile Bulunması

Her backup piece'te bir tane datafile bulunması demek  full restore yapmadığımız zamanlar için bize kolaylık sağlar. Partial Recovery yapıldığında database recovery yapılacak datafile'a ihtiyaç duyar. Eğer biz o partial recovery yapılacak datafile'ını birden fazla parçaya bölersek bu durumda recovery daha uzun sürer.

RMAN>backup database filesperset 1 plus archivelog delete input;  

7-  Rman Catalog'unun Yönetilmesi

Rman Backup'ları Catalog'a kaydedilerek yönetilir. Catalog'dan ise merkezi bir politika oluşturabiliriz. (Rman Catalog Nedir?)

Peki Merkezi Olarak Ne Yapabiliriz?
Öncelikle düzenli olarak "Delete Obsolete;" komutunu çalıştırırız. Bu şekilde retention policy dışında kalan backupları sileriz ve yer kazanırız.

RMAN>Delete Obsolete;  

Rman backup'ları crosscheck edebiliriz. Crosscheck işlemi rman catalog ile controlfile kayıtlarını karşılıklı olarak eşler. Eğer arada eksik varsa o kayıt  expired olarak isimlendirilir. Expired backup'ları aşağıdaki komut ile silebiliriz.

RMAN> crosscheck backup;  
RMAN>  delete expired backup;  

Retention Policy to Redundancy seçeneğini ayarlayarak backup'ların tutulma süresini ayarlayabiliriz.

 RMAN>show retention policy  
 RMAN>CONFIGURE RETENTION POLICY TO REDUNDANCY 2;  

Ancak bu ayarı ayarladıktan sonra mutlaka control file record keep time parametresini de set etmeliyiz. Yoksa bazı backup'ların redundancy durumu geçebilir. O yüzden iki ayarında birbiri ile aynı olduğunu kontrol etmeliyiz.

SQL> alter system set control_file_record_keep_time=21 scope=both;

8- Recovery'nin Test Edilmesi:

Yukarıda 5. adımda restore, backup  normal olarak database'in validate edilmesinden bahsetmiştik. Bir başka doğruluk kontrolünü recovery aşamasında da yapabiliriz. Bu işlemde de gerçekten recovery yapılmaz. Sadece yapılması durumunda neler olacağını inceler.

 RMAN> recover database test;  

9- Controlfile Autobackup'ının Set Edilmesi:

Bu aksiyonda controlfile'ın kaybedilmesinin önüne geçilebilir. Controlfile'ın backup'ı backup işleminin sonunda gerçekleştirilir.

 RMAN> configure controlfile autobackup on;  

Oracle Veritabanı: Flash Recovery Area Nasıl Açılır?

Flash recovery area'nın ayarlanması için parametre dosyasında ayarlamalar yapılması gerekir.    Bu ayarlamalar 2 parametreyle ilgilidir.

1 - DB_RECOVERY_FILE_DEST_SIZE:

Disk hacmini belirler. Bu hacim kullanılabilecek maksimum alanı belirler.  Bu parametre eğer standart file system'dan asm'e geçilme çalışması yapılıyorsa DB_RECOVERY_FILE_DEST'den önce yapılmalıdır.

Örnek:

 DB_RECOVERY_FILE_DEST_SIZE = 10G  

2- DB_RECOVERY_FILE_DEST:

Bu parametrede recovery file destination yani recovery area'yı belirler. DB_RECOVERY_FILE_DEST_SIZE eğer var olan alandan büyükse değişiklik gerçekleşmez.

 DB_RECOVERY_FILE_DEST='+DATA'

3- DB_FLASHBACK_RETENTION_TARGET: (Opsiyonel)

Dakika bazında ne kadar geriye gidilebileceğini belirtir. Parametre eğer database "FLASHBACK" modunda ise etkinleşir. Flashback alanında ne kadar data tutulacağınıda indirekt olarak etkiler.

Flash Recovery Area Location ve Size Set Edilmesi:

İlk olarak database kapatılır ve parametre dosyasında değişiklik yapılır. Ertesinde de sqlplus'tan  aşağıdaki komut çalıştırılır.

 ALTER SYSTEM SET   
  DB_RECOVERY_FILE_DEST_SIZE = 10G   
  SCOPE=BOTH SID='*';  

Size belirlendikten sonra  yine aynı şekilde ya parametre dosyasından database kapalıyken location değişikliği yapılır ya da database açık iken aşağıdaki komut çalıştırılır.

 ALTER SYSTEM SET  
  DB_RECOVERY_FILE_DEST = '+DATA'   
  SCOPE=BOTH SID='*'; 

(Database Flashback Mode'a Nasıl Alınır?)


Flash Recovery Area(FRA) Oluşturulurken Değerlendirilmesi Gerekenler:

Flash recovery area'nın database alanının dışında bir alana kurulması Oracle tarafından tavsiye edilir. Database alanı olarak belirtilen yer ise datafile'ların, control file'ların ve online redo log'ların tutulduğu yerdir. Eğer flash recovery area, database alanıyla aynı diske set edilirse bu durumda hem database'in hem de backup'ların kaybedilme ihtimali doğabilir.

Database dosyalarının FRA'ya set edilmemesi için DB_CREATE_FILE_DEST ve DB_CREATE_ONLINE_LOG_DEST_n parametrelerinin DB_RECOVERY_FILE_DEST parametresinden farklı olmaları gerekir. Bununla birlikte disklerin file system'larının ASM olması önerilir.

Oracle Veritabanı: Alter System Switch Logfile ve Alter System Archivelog Current

Alter system switch logfile ve alter system archivelog current ifadelerinin ikiside  log switch sağlar.

Alter system switch logfile'da var olan transaction'ların bitmesi beklenmeden logfile dosyası switch eder. Archivelog current'lı komutumuz ise direk transaction'ların bitmesini bekler. Bu durum biraz daha uzun sürebilir ancak daha güvenlidir.

Buna karşılık alter system switch logfile'da komut çok hızlı bir şekilde gerçekleşir. Database'e checkpoint gönderip hemen direk redo log'lara yazmaya başlar. 

Alter system archivelog current komutu senkron olarak çalışır. Redo log file system'a yazılana kadar bekler. Bu yüzden daha güvenlidir. 

Oracle Veritabanı: Database'in Archivelog Mode'a Alınması

Çoğu Oracle High Avalibility işlemleri bizim database'imizin "ARCHIVELOG" mode'da olmasını gerektirir. Bu veritabanının bu moda alınması demek redo log arşivlenir. Bu mode'da olmasydı veritabanı var olan log'ların üzerine yazardı. Archive log'lar RMAN, Data Guard, Flashback ve diğer bir sürü High Availabilty ürünü tarafından kullanılır.

Bizim için önemli olan bir database'i archivelog mode'a almadan önce database'in kapatılması gerekir. Böylece bütün değişikliklerimiz database'e yazılır. Düzgün ve istikrarlı bir şekilde database kapandıktan sonra temiz bir cold backup alınması yani datafile ve controlfile'ların manuel olarak kopyalanması ve bir yerde tutulması tavsiye edilir.

 $ sqlplus / as sysdba  
   
  SELECT LOG_MODE FROM SYS.V$DATABASE; 

 SELECT name, value  
 FROM gv$parameter  
 WHERE name LIKE '%arch%';  
   

Buradaki işlemlerde ise pfile değişikliklerimizi yapmadan önce bir kere daha archivelog modunun kontrolünü yapmaktayız.


Backup alındıktan sonra pfile'ımızda bazı önemli değişiklikler yaparız. Bu değişiklikler database log'larının arşivlendiğinde nerede depolanacağı ve archive işlemine başlanabileceğini gösteren değişikliklerdir.

log_archive_dest_1='location=+FRA'  
 log_archive_start=TRUE  

Yukarıdaki pfile değişikliklerimizde archive'larımızın log'landığında ASM disklerimizden +FRA disk grubunda depolanacağını beliritiriz. Pfile değişikliklerimiz yapmadan önce database'in mutlaka kapalı olması gerekir.

     
  startup mount;   
     
  alter database archivelog;   
     
  alter database open;   
     
  archive log list;   
     
  alter system switch logfile;   
    
  alter system archive log current;  

Database'i kapatıp pfile değişiklikleri yapıldıktan sonra database mount mode'da açılır ve  archivelog komutu çalıştırılır. Sonrasında database açılır.

Linux / Unix Komutu : Xargs Kullanımı

Xargs komutu argüman listesi oluşturmak için kullanılır. Oluşturulan argüman listesine göre de başka komutları tetikler. Argüman listesi demek başka komutların kullanımı sonucu çıkan sonuçların listelenmesidir.
Bu çıkan sonuçlar xargs tarafından okunur ve bunları pipe "|"  ile birleştirilen devamındaki komutla çalıştırır. Xargs en iyi örneklerle açıklanabilinir.

Xargs Kullanımı 

$ echo 1 2 3 4 5 6 | xargs echo  

veya

$ echo 1 2 3 4 5 6 | xargs 

Yukarıdaki örnekte echo ile birlikte gelen ifadeler xargs tarafından argüman olarak okunur ve echo ile ekrana basulır. Xargs komutu burada bütün argümanları tek bir ifade olarak algılar. Eğer bunların teker teker limitlenmesini istiyorsak "-n 1" şeklinde bir ifade eklemeliyiz. :

 $ echo 1 2 3 4 | xargs -n 1  
 1  
 2  
 3  
 4  

Başka bir örnekte daha iyi anlamamız için ls komutunu xargs ile birlikte kullanırız. Burada ls -lart komutuyla çıkan sonuçlardan aldığımızı veriyi xargs -n 1 ile teker teker ekranda gösteriririz.:

ls -lart | xargs -n 1  
 total  
 16  
 -rwxr--r--  
 1  
 root  
 system  
 1188  
 Sep  
 28  
 2012  
 vrt_monitor.sh  
 drwxr-xr-x  
 2  
 root  
 system  
 256  
 Sep  
 28  
 2012  
 logs  
 drwxr-xr-x  
 3  
 root  
 system  
 256  
 Sep  
 28  
 2012  
 .  
 -rwxr-xr-x  
 1  
 root  
 system  
 1219  
 Sep  
 28  
 2012  
 twm_vfb.sh  
 drwxr-xr-x  
 6  
 applmgr  
 dba  
 256  
 Sep  
 16  
 14:14  
 ..  

Bu örneğimizde ise .bak uzantılı dosyalar bulunur ve silinir.

find . -name "*.bak" -type f -print | xargs /bin/rm -f  

Aşağıda sendmail komutuyla aldığım process bilgilerini kullanıp buradan awk komutuyla pid bilgisini alıp silebiliriz.

ps -ef |grep sendmail | awk '{print $2}' | xargs  kill -9  

Oracle Veritabanı: Rman'de Backup'ların Alınması

Daha önceden rman'de ayarların nasıl yapıldığından bahsetmiştik. Bu konfigürasyon düzenlerinde backup'lar alınırken bakılacak default opsiyonlar bulunmaktadır. Örneğin alacağımız backup'ın backupset ya da image copy olması veya backup'lar alınırken kaç paralel çalışılacağı gibi ayarları set edebiliriz.

Full Backup Nasıl Alınır?

Full database backup'ı "backup database" denilerek alınır. Burada bahsettiğimiz full database backup'ın içinde archivelog'lar bulunmamaktadır. Aşağıdaki örnekte "default behavior" yani standart aksiyon olarak alınan "image copy" backup özelliği "override" yani ezilmektedir.

 RMAN> BACKUP AS BACKUPSET DATABASE  

Eğer direk backup database dersek default olarak ne belirlendiyse, bu durumda image copy olarak backup alır. 

 RMAN> BACKUP DATABASE  

Full Backup ve Archivelog Backup'ın Alınması:

Bu komutla birlikte database'imizin image copy olarak hem datafile'larının hem de archivelog'larının backup'larını alırız.

BACKUP DATABASE PLUS ARCHIVELOG;  

"Plus Archivelog"  ile Rmande  aşağıdaki işlemler otomatik olarak yapılır.

1- Alter system archivelog current; --çalışır.
2- Backup Archivelog all -- çalışır.
3- Backup komutundaki dosyalar backup'lanır.
4- Alter system archive log current; -- çalışır.
5- Backup sırasında yaratılmış archivelog'ların backup'lanması gerçekleştirilir.

Bir Tablespace'in Backup'ının Alınması:

BACKUP TABLESPACE HR;  

Backup'lara Tag Name Atanması:

Çok fazla alınan backup alınan ortamlarda backup'ların düzenli tutulması ve kolay yönetilebilmesi için backup'lara isim verilmesini sağlar. 

BACKUP AS BACKUPSET TAG 'HR_BCK' TABLESPACE HR;  

veya 

BACKUP  TAG 'HR_BCK' TABLESPACE HR;  

Backup İsimlendirme Format'ının Değiştirilmesi:

Rman konfigürasyon ayarları içinde backup'ları isimlendirmeyle ilgili bir seçenek vardır.  Bu seçenek ile birlikte backup'larımıza isim verebiliriz kendi isteklerimize uygun olarak

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT  "+ASM/backup/rman/backup_%u_%s_%p" MAXPIECESIZE 2048 M; 

Backup format spec olarak belirtilen bu %u,%s,%p gibi ayarları  "http://docs.oracle.com/cd/B28359_01/backup.111/b28273/rcmsubcl010.htm" adresinden görebiliriz.

Rman Backup'ın Compress Edilmesi: 

Backup'larımızı backup set alarak size'ını küçülttükten sonra bu backup'ları compress ederek daha fazla yer kazanabiliriz. Bunun için komutlarımızda "AS COMPRESSED" ifadesini kullanırız.

 BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;  

Backup'ların Compress edilmesinin bir kötü yanı performansta düşüş yaşatmasıdır. Compress edilirken daha fazla kaynak kullanılacağı için performansta azalma yaşanabilir. Bu durumda her zaman parallelism kullanılabilinir.

Archived Log'ların Backup'larının Alınması ve Depolanması :

Rman sayesinde archivelog'lar direk olarak tape'e alınabilinir. Eğer backup komutumuzda "Delete input" şeklinde bir opsiyon belirtirsek, rman archivelog'ların bir kopyasını alıp archivelog'ları backup'ladıktan sonra bu kopyayı siler.

RMAN> BACKUP ARCHIVELOG ALL DELETE INPUT; 

Sonuç olarak backup'lar alındıktan sonra backup'lanmış archivelog'ların bulunmasını ve yer kaplamasını istemiyorsak bu komutu kullanırız.

Bütün Online Redo Log'ların Backup'lanması:

Her backup'ın öncesinde "Alter system archive log current" dersek  sistem o anda kullanılan log'u switch edip kullanılan log'u backup'lar.

 Alter system archive log current;

Oracle Veritabanı: Full ve Incremental Database Backup'ları

Rman'de backupları ya full database olarak alabiliriz ya da incremental database olarak alabiliriz.

Full alinan bir database backup'ında bütün kirli(used) data block'larının backup'ı alınır. Eğer full backup image copy olarak alınırsa bütün içerik aynen kopyalanıp yapıştırılır. Yani işletim sistemi komutlarıyla bile yapılabilinir.  Eğer backup set olarak alınsaydı bu full database kullanılmamış, içinde veri olmayan block'ları backup içerisine eklemezdi. Bu davranış rman backup set'lerinin default hareketidir. Backup set'lerinin boyut olarak küçük olmalarının nedeni budur. Bu yüzden daha hızlı restore edilirler.

Incremental olarak alınan bir backup' ise en son alınan backup'tan itibaren değişen block'ların kopyasını alır.
Incremental Backup'lar her zaman backup set olarak tutulurlar O yüzden genelde daha küçüktürler. Rman sadece datafile'ların incremental backuplarını alabilir,archive redo log'ların ya da diğer dosyların incremental backuplarını alamaz.


Boyut olarak Sıralanırlarsa:

Full Database Image Copy > Full Database Backup Set => Incremental  Level 0 Backup Set > Incremental Level 1 Backup Set

Oracle Veritabanı: Rman Nedir? - Rman Konfigürasyonları

Bu yazının öncesi buradadır. - Oracle Veritabanı: Rman Nedir? - Rman Recovery Catalog Nedir?


RMAN Konfigürasyonu - Rman Ayarlarının Belirlenmesi

Rman ayarlarının belirlenmesi önemli bir konudur. Var olan ayarları "show all;" komutuyla rman'de görebiliriz. Bu ayarlar arasında backupların ne kadarının tutulması gerektiği, standart backup alma aracının ne olduğu veya control file autobackup'ının alınıp alınmaması gerektiği gibi ayarlar vardır.

Örnekler:

Bütün ayarların görülmesi:

SHOW ALL;

RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(OB_DEVICE=tape1)';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/disk1/oracle/dbs/snapcf_ev.f'; # default

Bütün disk backup'ları /tmp klasörünün altına %U olarak yani unique olarak yazılsın.

 RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/tmp/%U';

Rman controlfile autobackup'ının alınması:

 RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;   

Controlfile autobackup'larının diskte belirli bir klasör altına alınması:

 RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT   
      FOR DEVICE TYPE DISK TO '/cfilebackups/cf%F';  

Rman'in belirli bir süre boyunca bütün backupları tutması:

 RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

Her backuptan 3 tane farklı versiyon bulunması ve korunmasının sağlanması:

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;  

Eğer default backup yeri FRA(Flash Recovery Area) ya da başka bir yer ise
Disk yerine default backup yerine backup alınmasını sağlar:

 RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT CLEAR; 

Tape'lere alınan backup'ların 2 paralel çalışmasını sağlar.

 RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 2;  

Rman'de Ayarlar Nasıl Değiştirilir?

Rman de varolan bir ayarı değiştirmek için komutun başına configure ifadesi konur, sonrada ayar adı yazılır. Ayar adı yazılırken içeride istenen değişiklik yapılır. Örneğin backup alınacak yerin değiştirilmesi için:

CONFIGURE DEFAULT DEVICE TYPE TO DISK  

Rman Ayarlarının Görüntülenmesi:

Rman ayarlarıyla ilgili viewlar ve tabloları

 RC_RMAN_CONFIGURATION   
   
 V$RMAN_CONFIGURATION

Backup'ların Lokasyonlarının Ayarlanması:

Aşağıdaki ifadeyle ayarlanabilinir. Tape'e alınması isteniyorsa "disk" "sbt" ile değişitirilir.

 CONFIGURE DEFAULT DEVICE TYPE TO DISK  

Bu ayarlar istenildiğinde "override" edilebilir yani ezilebilinir.

 Backup device type sbt database;

Backup'ların Tiplerinin Ayarlanması:

2 tane backup tipi bulunmaktadır. Backup sets ve Image Copies. Image Copy sadece disk'e alınabilinir. Bu yüzden tape'e sadece backupset alınır.

Image Copy nedir?

Image Copy database'in birebir kopyasıdır.  Rman image copy'leri rman repository'sine yazılırken, database'i kapatıp alacağımız bir copy paste işlemi repositorde yer almaz.

Backup set nedir?

Backup set; backup ile ilgili bilgilerin mantıksal bir yapıda depolanmış halidir. Backup set'ler de birdeb falza datafiles veya archived redologs veya control files veya spfile bilgisi yer alır.

Backup set'ler backup piece denen rman'e özel dosyalardan oluşur. Örnek olarak 10 datafiledan oluşan bir database bir backup içinde bir backup piece'e sığacak şekilde backuplanabilinir.

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; 

Rman Channel'ları Hakkında:

Rman channel device'tan data'ya giden direk bir veri hattıdır. Server Session olarak tanımlanır. Server Session'da kullanıcı process'lerinin database process'leriyle iletişim kurmasıyla oluşur.

Çoğu Rman backup ve recovery işi server session'lar tarafından halledilir.

Rman Channel'ları ayarlamak için "Configure Parallelism" komutunu kullanırız. Böylece kaynaklarımızı paralel işleyerek işimizi kısaltabiliriz. Eğer komut listesinde özellikle belirtilmemiş ise rman configuration içerisindeki ayarlara bakılarak kanallar ayarlanır.

 CONFIGURE DEVICE TYPE DISK PARALLELISM 2;  
 CONFIGURE DEVICE TYPE DISK PARALLELISM 3; 

Parallelism ayarıyla kaç tane paralel session yaratılacağı ayarlanır.

Örnek Kod:

 RUN  
 {  
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt;  
  ALLOCATE CHANNEL c2 DEVICE TYPE sbt;  
  ALLOCATE CHANNEL c3 DEVICE TYPE sbt;  
  BACKUP DATAFILE 5,6,7;  
 }  

Yukarıdaki örneğimizde "Allocate Channel" ifadesiyle manuel olarak açtığımız bir channel'a isim vermiş oluruz. Örnekte tape'e alınan bir backup için 3 tane; c1,c2 ve c3 adlı kanal oluşturulmuştur. Bu işin otomatik olarak düzenlenmesini isteseydik aşağıdaki parametreyi set edebilirdik.

 RUN  
 {  
  ALLOCATE CHANNEL ch1 DEVICE TYPE DISK;  
  ALLOCATE CHANNEL ch2 DEVICE TYPE DISK;  
  ALLOCATE CHANNEL ch3 DEVICE TYPE DISK;  
  BACKUP   
   (DATAFILE 1,2,3,4    # CH1 datafile'ları yedekler  
   CHANNEL ch1)  
   (CONTROLFILE   
   CHANNEL ch2)       # CH2 controlfile için  
   (ARCHIVELOG FROM TIME 'SYSDATE-14'  
   CHANNEL ch3);      # CH3 archivelog için  
 }  

Yukarıdaki örnekte ise channel'ların nasıl kullanılacağı da belirtilir. Örnek olarak ch3  archivelog için kullanılır.

Backup İsimlendirme Format'ının Değiştirilmesi:

Rman konfigürasyon ayarları içinde backup'ları isimlendirmeyle ilgili bir seçenek vardır.  Bu seçenek ile birlikte backup'larımıza isim verebiliriz kendi isteklerimize uygun olarak

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT  "+ASM/backup/rman/backup_%u_%s_%p" MAXPIECESIZE 2048 M; 

Backup format spec olarak belirtilen bu %u,%s,%p gibi ayarları  "http://docs.oracle.com/cd/B28359_01/backup.111/b28273/rcmsubcl010.htm" adresinden görebiliriz.

Oracle Veritabanı: Rman Nedir? - Rman Recovery Catalog Nedir?

Rman Nedir?

Rman (Recovery Manager) Oracle veritabanında 8.versiyondan itibaren bulunan bir tool'dur. Bu tool ile backup'lar alınır ve restore-recover işlemleri yapılır. Oracle'ın tavsiye ettiği backup alma ve restore tool'udur.

Rman bağlantıları database'e giderken, sqlplus bağlantıları gibi giderler. Rman bağlantılarının farkı target veya auxiliary database'e giderken sysdba yetkisi gerektirmeleridir; ancak bağlanırken "as sysdba" ima edilir direkt olarak syntax içinde konulmaz. Bu yüzden aşağıdaki örnekte rman target'a bağlanırken aşağıdaki gibi sysdba yetkilerine sahip sys kullanıcısını kullanarak belirtiriz.

 rman target sys/oracle

ya da E-Business Suite bağlamında aşağıdaki gibi kullanılabilinir.

 rman target apps/apps

Rman Hangi Dosyalar Backup'layabilir?

Rman bütün database dosyalarını, datafile'ları, control file'ları, spfile'ları, archive log ları ve diğer backup dosyalarını backuplayabilir.


Recovery Catalog Nedir?

Rman catalog genel olarak bir database schema'sıdır. Bu schema'da rman repository bilgileri bulunur. Rman'de birden fazla Oracle Database bilgileri bulunabilir. Recovery catalog ile rman repository için redundancy oluşturur. Recovery catalog ile normalde control file'da saklanan rman repository yedeklenmiş olunur.

Recovery Catalog ile backup'ların ve database'lerin metadata'ları control file ile tutulabilinceğinden daha uzun tutulur. Bu özellik ile normalde çok geri bir zamandan geri dönülmesi gerekmesi halinde, backuplardan restore yapılabilinir.

Başka başarılı bir özellik ise rman script'lerinin sadece recovery catalog'da tutulabiliniyor olmasıdır. Recovery Catalog'a eklenen bütün database'ler tarafından kullanılabiliceği için genel olarak geçerli script'ler konulabilinir.

Catalog'da bulunan metadata'lar:

• Datafile'lar, archived redo log backup set'leri ve backup piece'leri
• Datafile kopyaları
• Archived redo log'ları ve kopyaları
• Veritabanının yapısı (Tablespace'ler ve Datafile'lar)
• Kaydedilmiş Rman Script'leri 
• Rman Configuration ayarları

Oracle bütün target database'lerin tek bir database de (catdb)'de  tek bir kullanıcı tarafından (catowner) yönetilmesini tavsiye etmektedir. Bu database'in de farklı bir makine de olması önerilmektedir.

Recovery Catalog Nasıl Yaratılır?

Rman Catalog'umuz için bir tablespace yaratırız. Bu tablespace'i kullanacak bir kullanıcı ekleriz. En son olarak da "create catalog" diyerek catalog yaratırız. (Tablespace yaratılması)

 create tablespace rman datafile size 20M autoextend on;

Tablespace yaratıldıktan sonra kullanıcımızı yaratır ve kullanıcımıza "create catalog" yetkisi veririz.

create user rman identified by berke  
     temporary tablespace temp  
     default tablespace rman  
     quota unlimited on rman;  
   
 grant recovery_catalog_owner to rman;  
 quit;  

Recovery Catalog' kullanıcısını tablespace ile birlikte yarattıktan sonra rman'e şimdi yarattığımız kullanıcıyla bağlanarak rman catalog'umuzu yaratırız.

 rman catalog rman/berke  
   
 create catalog;  
   
 quit;

İlgili Tablolar:

  RC_DATABASE              V$DATABASE  
  RC_DATABASE_INCARNATION  V$DATABASE_INCARNATION 

Database Nasıl Register Edilir?

Rman'e sysdba yetkisine sahip bir kullanıcıyla tekrar bağlanırız.  Ertesinde cataloga bağlanarak database'imizi register ederiz.

 rman target sys/oracle@orcl

Target session'ımızdan catalog'a bağlanmamız gerekir database'imizi kaydetmek için. Eğer catalog'umuz farklı bir db'de ise oraya service_id'si ve tns bilgileriyle bağlanırız. Catalog'umuz aynı database'de ise direk bağlanabiliriz.

--Eğer farklı bir database yoksa

 connect catalog rman/berke;  
 register database;  
 quit;

--Eğer farklı bir catalog database'i varsa

 connect catalog rman/berke@catdb;  
 register database;  
 quit;

Her database eğer catalog'da takip edilecekse kaydedilmelidir.

Eski Backup'lar Rman Catalog'una Nasıl Register Edilir?

Eski dosyaları ve backupları Recovery Catalog'una eklemek için "Catalog" komutunu kullanabiliriz.

 RMAN> CATALOG DATAFILECOPY '/dev/sda1/old_datafiles/users01.dbf';  
   
 RMAN> CATALOG ARCHIVELOG '/dev/sda1/backups/archive1_731.bkp' '/dev/sda1/arch_logs/archive1_732.dbf';  
   
 RMAN> CATALOG BACKUPPIECE '/dev/sda1/backups/abc1.bkp';  
   
 RMAN> CATALOG START WITH '/disk1/backups/';  

Rman 'de en genel backupları cataloğ'a register etme komutu "Catalog start with '/dizin_adı/' " 'dir. Bu şekilde dizin altında bulunan bütün backuplar kaydedilir.


Yazının devamı - Oracle Veritabanı: Rman Nedir? - Rman Konfigürasyonları

Oracle E-Business Suite: Maintenance Mode Scripti - Sql Script to Enable/Disable The Maintenance Mode

Oracle E-Business Suite'de sistemin patch işlemleri için "Maintenance Mode"'a alınması gerekir. Bu moda alınması için 2 yöntem vardır. Bir tanesi Ad Utility (adadmin)'dir. Diğeri de OAM yani Oracle Applications Manager'dır.

OAM'dan yapmak için Ad Administration'a girip oradan "Change Maintenance" seçeneğini seçeriz. Ancak genelde önce sistemi kapadığımız için bu yol çok kullanılmaz.

 Adadmin'i çalıştırmak için terminal'e bağlanıp "adadmin" komutunu çalıştırırız.

 adadmin  

Adadmin'de maintenance mode'a alınırken bir sql çalışır. O sql:

 $AD_TOP/patch/115/sql/adsetmmd.sql   

Bu sql'i eğer elimizle çalıştıracaksak eğer:

 cd $AD_TOP/patch/115/sql/    
  sqlplus apps/apps @adsetmmd.sql 

Yukarıdaki sql'i çalıştırınca bizden "ENABLE" veya "DISABLE" şeklinde bir cevap ister. Amacımıza göre ENABLE veya DISABLE diyerek sistemimizi maintenance mode'a alabiliriz.

Sistemin hangi mode'da olduğunu görmek için aşağıdaki sorguyu kullanabiliriz.

sqlplus apps/apps  
   
 SQL> select fnd_profile.value('APPS_MAINTENANCE_MODE') from dual;

Oracle E-Business Suite : AutoPatch Error: Missing File Format ID In File applcust.txt Hatası ve Çözümü

Oracle E-Business Suite için Patch geçerken karşılaşabilinen bir hatadır. Ben de EBS için geçilen bir patch sırasında karşılaştım. Patch için önce Oracle EBS'i kapatmam gerekiyordu.

 cd $ADMIN_SCRIPTS_HOME  
   
 ./adstpall.sh apps/****  
   
 kill -9 -1 -- Geride hiç bir process kalmaması için  

EBS'i kapattıktan sonra patch'imin bulunduğu lokasyona gittim ve orada adpatch'imi çalıştırdım.

 cd p16712784_R12.XLA.B_R12_AIX64-5L  
   
 vi Readme.txt  
   
 adpatch  

Adpatch sırasında ise "AutoPatch Error: Missing File Format ID In File applcust.txt" hatasıyla karşılaştım. Bu hata çok basit bir şekilde çözülebiliyormuş.

/orappl/$SID/apps/apps_st/appl/admin/ klasörün altında applcust.txt adlı dosyanın applcust.txt.bak şeklinde rename edilmesiyle halloluyormuş.

 cd /orappl/$SID/apps/apps_st/appl/admin/  
 mv applcust.txt applcust.txt.bak  

Bu işlemden sonra patchimizin bulunduğu klasöre tekrar dönerek adpatch'imizi başlatırız.

Oracle Veritabanı: DBNEWID Aracı ve NID

DBNEWID Oracle Database'de bulunan bir araçtır. Bu araç ile DBID(Internal Database Identifier) ve database ismi (DBNAME) değiştirilir.

DBNEWID'den önce database ismini değiştirmek için database'in kopyasını alıp yeni bir control file yaratılırdı ancak DBID değiştirilemezdi. DBID her database için özel olan bir tanımlayıcıdır. DBNEWID aracıyla bu problem çözülmüştür. Bundan böyle DBID ve DBNAME parametreleri ayrı ayrı ya da birleşik olarak değiştirilebilinir.

DBID ve DBNAME Değiştirmenin Sonuçları

Bir database'in DBID'si değiştirilirse bütün eski backup'lar ve archive log'lar kullanılamaz hale gelir. DBID değiştirildikten sonra database resetlogs ('Alter database open resetlogs') modunda açılmalıdır.Bu şekilde redolog'lar tekrar yaratılır ve sequence numaraları 1'e resetlenir. Sonrasında da hemen veritabanının backup'ı alınmalıdır.

DBNAME'i DBID değiştirmeden farklı bir isme set etmek veritabanını resetlogs ile açmamızı gerektirmez. DB_NAME parametresini spfile veya pfile da(hangisi kullanılıyorsa) değiştirmek gereklidir. Böylece DBNAME parametresi etki eder.

DBNAME ve DBID Nasıl Değiştirilir?

Önce mutlaka full bir backup alınmalıdır. Bu adım zaten bütün büyük veritabanı işlemlerinden önce mutlaka kontrol edilmesi ve eğer yoksa backup yoksa uygulanması gereklidir.

Veritabanı consistent yani düzgün bir şekilde kapatılmalıdır.

 SHUTDOWN IMMEDIATE  
 STARTUP MOUNT  

Artık DBNEWID aracımızı kullanmaya hazırız. Bu aracı kullanırken mutlaka "SYSDBA" yetkisine sahip bir kullanıcıyla çalıştırmalıyız. Aşağıdaki örneğimizde sadece DBID değiştirilir.

 nid TARGET=SYS/oracle@orcl 

DBNAME'imizi de değiştirmek için bu sefer DBNAME parametresini vermeliyiz. Bu şekilde artık database'in adı berke olmuş olur. Buradaki örneğimizde ise DBID ve DBNAME değiştirilir.

 nid TARGET=SYS/oracle@orcl DBNAME=BERKE 

Nid komutuyla datafile ve controlfile header'ları değiştirilir. Bütün datafiler için dbid'ler değiştirilir ve sonra da çıkılır.

Sadece DBNAME'i değiştirmek için:

 nid TARGET=SYS/oracle@orcl DBNAME=BERKE SETNAME=YES LOGFILE=dbid.out  

Başarıyla Nid komutunu çalıştırdıktan sonra database kapatılır ve tekrar Mount modda açılır. Ertesinde resetlogs modunda veritabanı açılır. "Alter system"'lı komutumuz dbname değişikliğini geçerli kılmak için yapılır.

 SHUTDOWN IMMEDIATE  
 STARTUP MOUNT;  
 ALTER SYSTEM SET DB_NAME=BERKE SCOPE=SPFILE;--DBNAME Değişikliği olduğunda kullanılır.  
 SHUTDOWN IMMEDATE;  
   
 STARTUP MOUNT    
 ALTER DATABASE OPEN RESETLOGS;  

Sonrasında database'in backup'ı alınır.

Oracle Veritabanı: Linux / Unix Ortamda Oracle 11g nin Kaldırılması

Linux ve Unix ortamlarda Oracle'ı kaldırmak için bazı dosyaları kaldırmamız ve ertesinde de bazı lokasyonlara yazılan kayıtları silmemiz gerekir.

Database silinmeden önce temiz bir şekilde kapatılır.

 sqlplus / as sysdba  
 SQL> shutdown abort;  
 SQL> exit  
 kill -9 -1 

Database kapatıldıktan sonra kill komutunu veririz. Böyle database'i açan kullanıcının bütün process'leri kill edilir. "Kill -9 -1" tehlikeli bir komuttur. Root kullanıcısıyla çalıştırılmamalıdır. Oracle kullanıcısıyla çalıştırılmalıdır. (Çalışan Oracle Process'leri nasıl bulunur? Oracle Processleri) (Kill Komutu Kullanımı)

Yukarıda söylediğimiz gibi Oracle veritabanı ile ilgil bazı kayıtlar "/etc" altına yazılır. "oraInst.loc" klasöründe orainventory path'i bulunur. Oracle_Base altında değilse silinmesi gerekir.

 ls -lrt /etc/ora*  
 -rw-r--r--  1 root   system      53 Dec 28 2011 /etc/oraInst.loc  
 -rw-rw-r--  1 grid   oinstall    883 Sep 27 2012 /etc/oratab  
 -rw-rw-r--  1 oracle  oinstall     61 Jul 22 14:10 /etc/oragchomelist  
   
 rm -rf /etc/ora* 

 Bundan sonraki adım Oracle dosyalarını silmektir. $ORACLE_BASE, $ORACLE_HOME'yu kapsadığı için kökten silebiliriz yani $ORACLE_BASE'i kaldırırız.

 rm -rf $ORACLE_BASE 

Database'in açık bir session'undan kalmış aşağıdaki dosyalar da silinir.

 rm -rf /tmp/.oracle  
 rm -rf /var/tmp/.oracle  

Bu işlemlerin ertesinde sistemde set edilmiş parametreler silinir. Bu parametreler genel olarak .bash_profile,.bashrc,.profile veya .bash altında bulunur.( Shell'ler )


Referans:
http://docs.oracle.com/cd/B28359_01/install.111/b32002/remove_oracle_sw.htm#LADBI402

Oracle Veritabanı: Oracle 11g Grid Agent Blocked - Grid Agent'ın Kilitlenmesi

Oracle veritabanında database bilgilerini enterprise manager'a gönderen araca agent deriz. Oracle Enterprise Management Console'da bir organizasyonun bütün database'lerinden bilgi almak için kullanılan agent'lar için bir kontrol mekanizması vardır. Bu agent'lar host makinalarıyla haberleşemedikleri zaman sistem tarafından bir güvenlik açığı vermemek için kilitlenirler. Hata mesajı tam olarak aşağıdaki gibidir.

"Agent is blocked. Blocked reason is: Agent is out-of-sync with repository. This most likely means that the agent was reinstalled or recovered. Please contact an EM administrator to unblock the agent by performing an agent resync from the console"

 Bu sorunu çözmek için aşağıdaki adımları izlemeliyiz.

  emctl status agent   -- Agent statusu
  emctl stop agent  -- Agent durdurulması
  #Dosyaların Silinmesi (Opsiyonel) 
  cd $AGENT_HOME/sysman/emd/upload #ve
  cd $AGENT_HOME/sysman/emd/state  
  emctl clearstate agent   
  emctl start agent  
  emctl pingOMS 

Yukarıdaki gibi agent'ımızı açtıktan sonra, agent bloke olduğu için, agent'ı "unblock" etmemiz lazım. Bunun için enterprise manager'e gidip Setup>Agents'a gidip istediğimiz bloke olmuş agent'lı database'i seçip orada "Agent Resyncronization" tıklanır. Oradan da "unblock" yapılır. En sonda da test etmek için aşağıdaki komut kullanılır.

emctl upload agent  

Oracle Veritabanı: AWR - Automatic Workload Repository - 2

Bu yazının öncesi buradadır.

AWR Kurulumu:

AWR'ımız aktive etmek için sistem parametrelerimizde "statistics_level" parametresini set etmeliyiz. Bu parametreyi 3 değere set edebiliriz.

• basic - AWR'ı kapatır
• typical - Default olarak seçili gelir. Standard istatistik toplanması anlamına gelir. 
• all - typical'a ek olarak işletim sisteminden ek planlar ve zamanlama istatistikleri toplanır.

 --Açık Durumlar  
 alter system set statistics_level = typical;  
 alter system set statistics_level = all;  
   
 --Kapalı Durumlar  
 alter system set statistics_level = basic;  
   
 --İstatistik parametresi nasıl görüntülenir?  
 SQL>show parameter statistics_level;  

Snapshot Ayarları:

Var olan snapshotlar ve ayarları:

 select * from dba_hist_wr_control;  
 select * from dba_hist_wr_control where dbid = (select dbid from v$database);  
 

Snapshot Retention Period nasıl bulunur:

 select  
   extract( day from snap_interval) *24*60+  
   extract( hour from snap_interval) *60+  
   extract( minute from snap_interval ) "Snapshot Interval",  
   extract( day from retention) *24*60+  
   extract( hour from retention) *60+  
   extract( minute from retention ) "Retention Interval"  
 from   
   dba_hist_wr_control;  

Snapshot yaratılması:

  exec dbms_workload_repository.create_snapshot;  

Snapshot silinmesi:

 exec dbms_workload_repository.drop_snapshot_range (low_snap_id=>1077, high_snap_id=>1078);   

Snapshotların gösterilmesi:

Display snapshots     select snap_id, begin_interval_time, end_interval_time from dba_hist_snapshot order by 1; 

Snapshot'ların ayarlanması:

 execute dbms_workload_repository.modify_snapshot_settings (  
   interval => 60,  
   retention => 1576800);  

Burada ayarlanan snapshot'ın veritabanındaki korunma süresidir. "Retention" olarak belirtilen parametre dakika cinsindendir. 3 yılı temsil eder. "Interval" ise snapshot'ların alınma sıklığını gösterir.

Kullanışlı Tablo ve View'lar:

 dba_hist_active_sess_history     -- ASH Bilgileri  
 dba_hist_baseline       -- Baseline Bilgileri  
 dba_hist_database_instance     -- İnstance Bilgileri  
 dba_hist_sql_plan       -- Sql Kullanım Bilgileri  
 dba_hist_wr_control       -- AWR Ayarları  
 dba_hist_snapshot     -- AWR 'deki Snapshot Bilgileri

AWR Raporları:

Bir AWR raporı çalıştırmak için 2 yol vardır. Enterprise Manager veya işletim sistemindeki scriptler.

AWR raporu Enterprise Manager'dan Performance tab'ından çalıştırılır.

İşletim sisteminde ise 2 tane ana script bulunmaktadır.  Bunlar Linux veya Unix bir sistemde $ORACLE_HOME/rdbms/admin altında bulunur.  Aşağıdaki şekilde bir raporu çalıştırabiliriz. Aşağıda awrrpt.sql için bir örnek verilmiştir.

cd $ORACLE_HOME/rdbms/admin  
 sqlplus / as sysdba  
 SQL>@awrrpt.sql  

awrrpt.sql : Html veya text tipinde bir rapor istenilip istenilmediğini sorar. Sonrasında snapshot zamanına bağlı olarak kaç gün snapshotların listelenmesi istendiği sorulur. Listelenen snapshotlardan başlangıç ve bitiş için birer tane snapshot id'si girilir. Böylece istenen aralık incelenebilinir.

awrrpti.sql : Direk html tipinde çıkartır. Çıkan sonuçlar aynı dizinde ya awr_report_(begin_snapshot_id)_(end_snapshot_id) olarak kaydedilir ya da bizim vereceğimiz bir dizin ve bir isimle kaydedilir. Eğer özel bir klasör verilmezse $ORACLE_HOME/rdbms/admin/ klasörü altında isimlendirerek yaratır.

Diğer Az Bilinen AWR Raporları:

awrsqlrpt.sql
awrinfo.sql - Genel awr bilgisi
awrddrpt.sql - seçili snapshotlar arasında karşılaştırma

Oracle Veritabanı: AWR - Automatic Workload Repository

AWR (Automatic Workload Repository) SYSAUX tablespace'ine yerleştirilmiş bir repository'dir. Bilgileri SYSAUX tablespace'inde saklanır. Oracle veritabanı düzenli aralıklarla bütün veritabanının bir snapshot'ını çeker. Snapshot olarak bahsettiğimiz istatistiklerin ve workload bilgilerinin alınmasıdır. Bu bilgiler içerisinde ayrıca problem çözümü için önemli ve database'in tune edilmesine yarayacak gerekli veriler vardır. Sonrasında bu alınan veriler AWR'da depolanır.

AWR'da database'in sessionlarına istinaden sistemden toplanan bilgilerde bulunmaktadır. Sadece AWR reportları tarafında bu bilgiler kullanılmaz. Aynı zamanda SQL Tuning Advisor ve Segment Advisor  tool'ları bu bilgilere erişir.

AWR ilk olarak Oracle 10g de sunulmuştur. Daha önceden bulunan statspack paketinin üzerine geliştirilmiştir. Statspack paketiyle veritabanı performans istatistikleri toplanmaktaydı.

AWR ile çalışan başka bir tool'da ADDM'dir.(Automatic Database Diagnostic Monitor) ADDM her AWR raporundan sonra çalışır ve AWR raporlarının okunabilir hale getirilmesini sağlar.

AWR Mimarisi:

MMON process'i memory'den gerekli istatistikleri toplamaktan ve onları SYSAUX tablespace'ine kaydetmekten sorumludur.

AWR V$SYSSTAT ve V$SESSTAT view'larından bazı istatistikleri alır. Ayrıca SQL istatistiklerini, database object kullanım istatistiklerini, wait istatistiklerini, ASH istatistiklerini ve işletim sistemi bilgilerini alır.

AWR'ın Kullandığı Tablolar

v$sys_time_model : time model istatistikleri (db time, java execution time, pl/sql execution time)

v$osstat : işletim sistemi  (avg_busy_ticks, avg_idle_ticks)

v$service_stats : wait istatistikleri  ( db cpu, app wait time, user commits)

v$systat : sistem verileri

v$sesstat : session verileri

Database Performans İstatistikleri içinde 3 tane kategori bulunmaktadır.

• Cumulatif olarak toplanan değerler, belirli bir dönem boyunca alınan bilgilerden yola çıkılarak belirlenir.
• Metric değerler toplanan verilerin kullanılıp belirli bilgileri işaret eden değerlerdir.
• Parçalı Data ise belirli bir zamanda içinden kesit alınarak gösterilen değerlerdir.

Bu yazının devamı buradadır.

Oracle Veritabanı: ADDM - Automatic Database Diagnostic Monitor

AWR sisteme ait istatistiksel dataları otomatik olarak toplayıp sysaux tablespace'ine attıktan sonra bu bilgiler ADDM tarafında kullanılır. ADDM  bu bilgileri alıp var olan problemleri ve problemler için yapılması gerekenleri sıralar. AWR performans istatistiklerini birer saatlik aralıklarla  MMON process'i aracılığıyla alması sayesinde ADDM gerekli bilgi arşivine ulaşır ve enterprise manager'ın home sayfasında yayınlar.

ADDM'in amacı DB Time metriği olarak adlandırılan bir değeri düşürmektir. DB Time olarak bahsettiğimiz değer, database'in gerçekten kullanıcı ihtiyaçlarını karşılamak için çalıştığı, bunun dışında CPU'u beklemediği ve kendi kaynaklarıyla çalıştığı zamandır. DB Time arka plan process'lerinin çalıştığı zamanı kapsamaz.

ADDM'in kapsamı içine:

• Sql ve Java İfadeleri
• I/O Performans Sorunları
• Lock'lar
• Parse İşlemler ve Sql Path'ler
• Fazla Checkpoint'lar, Logfile Switch'ler
• Kaynak Kısıtları
• Bağlantı Sorunları ve Logon ve Logoff Aktiviteleri

girer.

ADDM'in açılması AWR'a bağlıdır. AWR açıldığında açılır. 

 --Açık Durumlar  
 alter system set statistics_level = typical;  
 alter system set statistics_level = all;  
   
 --Kapalı Durumlar  
 alter system set statistics_level = basic;  
   
 --İstatistik parametresi nasıl görüntülenir?  
 SQL>show parameter statistics_level;  

ADDM ile İlgili Tablo ve View'lar

DBA_ADVISOR_FINDINGS     --ADDM Bulguları  
 DBA_ADVISOR_OBJECTS     --Bulgularda Çıkan Nesneler  
 DBA_ADVISOR_RECOMMENDATIONS     -- ADDM Tavsiyeleri  
 DBA_ADVISOR_RATIONALE     --ADDM Bulgularının Mantığı  
 DBA_SCHEDULER_JOBS    --Snapshot Joblarını Gösterir.  
 dba_hist_baseline     -- Baseline 'ları Gösterir.  
 dba_hist_snapshot      --Kullanılabilir Snapshotlar  
 dba_hist_wr_control      --Snapshot Ayarları  
 v$sys_time_model     --Veritabanındaki Operasyonlar İçin Toplanmış Genel İstatistikler  
 v$sess_time_model      --Sessiondaki Operasyonlar için Toplanmış Genel İstatistikler 

ADDM Raporları

ADDM raporu çalıştırmak için AWR raporları çalıştırırken yaptığımız gibi tekrar $ORACLE_HOME/rdbms/admin altına gidip addmrpt.sql dosyasını çalıştırırmamız gerekir. addmrpt.sql'ini çalıştırdığımızda bize listelenen snapshotlar içinden iki tane biri begin_snapshot_id, diğer end_snapshot_id olmak üzere bilgi istenir. 

En sonunda da raporun çıkacağı yer sorulur. Bu bilgileri verdikten sonra çıkan raporda çeşitli operasyonlar ve işlemlerle ilgili raporlar verilir ve tavsiyeler sıralanır.


ADDM Raporlarının Kontrolü:

Dba_advisor_tasks adlı tablodan addm raporlarımızın düzgün tamamlanıp tamamlanmadığını kontrol edebiliriz.

 select * from dba_advisor_tasks where advisor_name='ADDM';

Linux / Unix İşlem: Oracle Shell Scripting ve Loglama

Windows

Windows'ta Oracle Script'leri çalıştırmak için  ilk önce komutlarımızı windows'ta bir dizine kaydetmemiz lazım. Göstereceğimiz ilk örnek sql scripti yazmak ve çalıştırmak olacaktır.

Sql Script İçeriği:,

Sql scriptimizde bu örneğimizde basit bir işlem yapacağız. Sonrasında bunun çıktılarını göreceğiz. Aşağıda yazdığımız scriptimizi "C:\abc.sql" olarak kaydedelim.

CONNECT berke/berke
 SPOOL C:\abc.log  
 SET LINESIZE 100  
 SET PAGESIZE 50  
 SELECT *  
 FROM hr.employees;  
 SPOOL OFF  
 EXIT;  

Yukarıdaki script'de basitçe sample schema'mızdaki employees tablosuna bir select atarız.Çıkan sonuçları da C:\ dizinindeki abc.log 'unun içine atarız. Bağlanırkenki kullanıcı adı ve şifrenizi değiştirmeyi unutmayın. Buradaki kullanıcı hr tabloları üzerinde yetki sahibi bir kullanıcıdır.

Bu scriptimizi istersek sqlplus'ta çalıştırabiliriz. 

 cd C:\  
   
 sqlplus berke/berke  
 SQL>@abc.sql  

Kendimizi yukarıdaki kodlardan da kurtarabiliriz. İşlemlerimizi daha otomatik bir hale getirmek için bir batch file yaratabiliriz. Bat dosyamızı C:\abc.bat olarak yaratalım.

  
 cd C:\  
 sqlplus /nolog @C:\abc.sql  

Bat dosyamız içerisine yukarıdaki kodları yazıp çalıştırırsak programımız istediğimiz gibi çalışır.

Peki bu bat file'ın otomatik çalıştırılması için ne yapılması gerekir?

Windows'ta bu işlem "Scheduled Tasks Wizard" adlı yerden gerçekleştirilir. (Start > Programs > Accessories > System Tools > Scheduled Tasks)

Unix ve Linux(Method 1)

Unix örneğimizde de yukarıda yazdığımız sql script örneğimizi kullanacağız. Sql scriptimizi alıp Linux veya Unix ortamlarda da aynı şekilde çalıştırabiliriz.  Windows ortamdan farklı olarak batch dosyası yaratmak yerine bir script dosyası yaratırız.

 #!/bin/bash  
 sqlplus /nolog @/home/oracle/Desktop/abc.sql  

Bu script dosyasını yarattıktan sonra abc.sh olarak kaydederiz. Bununla birlikte scriptimize çalıştırmak için chmod ile yetki vermemiz gerekir.

 chmod 777 /home/oracle/Desktop/abc.sh  

Unix ve Linux(Method 2)

Linux'taki başka bir metod ise yukarıdaki gibi bir tane sql dosyası bir tane de script dosyası yaratmak yerine sadece bir script dosyası yaratıp yukarıdaki işlerden kendimizi kurtarmamızı sağlar.

 #!/bin/bash  
 sqlplus /nolog << EOF  
 CONNECT berke/berke  
  SPOOL /home/oracle/Desktop/abc.log   
  SET LINESIZE 100   
  SET PAGESIZE 50   
  SELECT *   
  FROM hr.employees;   
  SPOOL OFF   
  EXIT;   
 EOF  

Buradaki script'imizede yukarıdaki örneğimizde verdiğimiz gibi tekrar chmod ile yetkilerini verdikten sonra çalıştırabiliriz. Bu methodumuzu Windows'ta da uygulayabiliriz. Yani orada da bir bat dosyası bir sql dosyası yaratmak yerine sadece bir bat dosyası çalıştırıp, bat dosyası içine aşağıdaki bilgileri bu örnek için yapıştırabiliriz.

 cd C:\   
  sqlplus /nolog <

Unix ve Linux'ta Script'ten Nasıl Değer Döndürebiliriz?

Yazdığımız scriptlerde amacımız eğer bir değer geri döndürmek ise sorgumuzun sonuçlarını alıp ekrana basmamız ve script içinde bu değeri işlememiz gerekir. Aşağıdaki örnekte employees tablosundan çektiğimiz sonuçları x değişkenimizin içine atarız. Sonrasında sql scriptinin içi bittiğinde console a geri döner ve eğer hiç bir sonuç yoksa bunu ekrana basar.

Script'lerden değer döndürmede sorun birden fazla satır ve değer geldiğinde oluşmaktadır. Bu durumda sonuçların parse edilmesi ve istenen sonucun ayrılması gerekmektedir; ancak tek sonuç geliyorsa işimiz kolaydır.

#!/bin/bash  
 x=`sqlplus -silent berke/berke <

Oracle Veritabanı: Uzun Süren İşlemler - V$SESSION_LONGOPS

Veritabanındaki sorgularımız her zaman kısa sürelerde sonuçlanmayabilirler. Sorgularımız bütün tabloyu full scan yaparak tararlarsa ve o tablolar içerisinde cok  büyük miktarda veri varsa, sorgulanan tablolarda gerekli index`ler yoksa, o zaman sorgularımızın bitmesi çok uzun sürebilir. Aşağidaki sorgumuz ile uzun suren sql ifadelerimizi bulabiliriz.

SELECT s.username,  
     sl.sid,  
     sq.executions,  
     sl.last_update_time,  
     sl.sql_id,  
     sl.sql_hash_value,  
     opname,  
     target,  
     elapsed_seconds,  
     time_remaining,  
     sq.sql_fulltext  
  FROM v$session_longops sl  
  INNER JOIN v$sql sq ON sq.sql_id = sl.sql_id  
  INNER JOIN v$session s ON sl.SID = s.SID AND sl.serial# = s.serial#  
  WHERE time_remaining > 0 

Uzun Süren İşlemler:

Uzun süren işlemler sadece sql`ler olmayabilir. Backup`larin alınması, import export işlemleri gibi database`i ilgilendiren işlemler de aşağidaki sorgumuzda bulunabilinir. Sadece geçen zamani değil aynı zamanda kalan işlem süresini de görebiliriz.

 SELECT osuser,  
     sl.sql_id,  
     sl.sql_hash_value,  
     opname,  
     target,  
     elapsed_seconds,  
     time_remaining  
  FROM v$session_longops sl  
 inner join v$session s ON sl.SID = s.SID AND sl.SERIAL# = s.SERIAL#  
 WHERE time_remaining > 0  

Uzun Süren Sessionlar ve Onların Kill Edilmesi:

Yukarıdaki gibi uzun süren işlemleri bulduktan sonra aşağıdaki gibi herbirini kill edecek sorgularımızı da çıkartacak bir sorgu yazabiliriz. Aşağıdaki sorgumuz bu işi görmektedir. Çıkan sonucu alıp hepsini bir kere de execute edebiliriz.

select  
 s.username,  
 s.sid,  
 s.serial#,  
 s.last_call_et seconds_running,  
 q.sql_text,  
 'Alter system kill session '''||s.sid||','||serial#||''' immediate;' as SQL_to_kill_long_running_sqls  
 from  
 v$session s join v$sqltext_with_newlines q on s.sql_address = q.address  
 where  
 status='ACTIVE'  
 and  
 type<>'BACKGROUND'  
 and  
 last_call> 10 --saniye  
 order by  
 sid,  
 serial#,  
 q.piece;  

10 Saniyeden Uzun Süre Çalışan Session'lar:

Aşağıdaki sorgumuzla da gerektiğinde 10 saniyeden uzun süre çalışan bütün sesssionları kill edebiliriz.

 select  
 s.username,  
 s.sid,  
 s.serial#,  
 s.last_call_et seconds_running,  
 q.sql_text  
 from  
 v$session s join v$sqltext_with_newlines q on s.sql_address = q.address  
 where  
 status='ACTIVE'  
 and  
 type <>'BACKGROUND'  
 and  
 last_call > 10 --saniye  
 order by  
 sid,  
 serial#,  
 q.piece

Uzun Süren İşlemlerin Sql'llerinin Bulunması:

Uzun süren işlemler sorgumuzundan gelen SID ve SERIAL# bilgilerini DBA_HIST_ACTIVE_SESS_HISTORY tablosunda sorgulayarak ilgili SQL_ID'yi bulabiliriz. Bu SQL_ID bulunduktan sonra da v$sql'den SQL_ID ile sorgulayabiliriz.

Aşamalarımızı özetlersek yukarıdaki long session ops'taki sid ve serial# bilgilerini  aşağıdaki sorgumuzda kullanıp ilgili sql_id'yi buluruz.

 select   
 *  
 from DBA_HIST_ACTIVE_SESS_HISTORY  
 where   
 sample_time>sysdate-1  
   
 and instance_number in (1,12)  
 and session_id='2857'  
 and session_serial#='9617'  
 order by sample_time,instance_number,SESSION_ID;  

Aldığımız SQL_ID bilgisini v$sql tablosunda sorgulatırız.

select * from v$sql where sql_id='0p1cypdyjuf2y';  

Referans:

http://www.mydbanotes.com/2010/06/identify-oracle-long-running-sessions.html
http://www.gplivna.eu/papers/v$session_longops.htm