Instance ve Media Bozukluklarını Inceleme

  • 99 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
99
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Anar Godjaev http://anargodjaev.wordpress.com/ Instance ve Media Bozukluklarını inceleme Oracle‟nın genel çalışma mantığı aşağıdaki gibidir. V$SGA: Sorgulanması sonucunda bize shared pool, log buffer, data buffer cache,ve fixed memory sizes hakkında bilgi verir. V$INSTANCE: Sorgulanması sonucunda instance‟ın statüsü, instance mode, instance name, startup time, ve host name hakkında bilgi verir. V$PROCESS: Sorgulanması sonucunda background veserver processes leri hakkında bilgi verir. V$BGPROCESS: Sorgulanması sonucunda background processes hakkında bilgi verir. V$DATABASE: Sorgulanması sonucunda database hakkında Lists status ve recovery information bilgisi verir. Database name, the unique database identifier, the creation date, the control file creation date and time, the last database checkpoint, ve diğer bilgileri içerir. V$DATAFILE: Sorgulanması sonucunda database de bulunan datafile ların içerik ve size bilgisini, creation date, status(online yada offline), enabled (read-only, read-write), last data file checkpoint bilgisini bulabiliriz. SGA(system Global Area), içersinde veri barındıran bir grup paylaşımlı bellek yapısı(shared memory structure) ve Oracle veritabanı instance‟ı hakkında kontrol bilgileri taşıyan bellek kısmıdır.Aynı instance „a bağlanan birden fazla kullanıcı SGA‟da bulunan veriyi paylaşır. (SGA‟ya Shared Global Area da denir.)SGA ve Oracle işlemleri bir Oracle instance‟ını oluşturur.Bu instance başlatıldığı anda SGA bellek alanı tutulur ve instance kapatılınca SGA alanı işletim sistemi tarafından bırakılır.(Her bir instance‟ın kendi SGA‟sı vardır)SGA‟da hem okuma hem de yazma işlemleri vardır.Kullanıcılar SGA da bulunan bilgileri okur, aynı anda da pek çok işlem SGA ya çalışma zamanları boyunca yazma işlemi gercekleştirir. Java Pool : Java ile ilgili kod ve veriler için ayrılan alandır.
  • 2. Anar Godjaev http://anargodjaev.wordpress.com/ Large Pool : Sistem ve kullanıcı işlemleri için tanımlanan isteğe bağlı bir alandır.Örneğin bu alan backup ya da restore işlemlerinde fazladan alan ihtiyacı için kullanılabilir.LRU gibi bir listesi yoktur.LARGE_POOL_SIZE parametresi ile büyüklüğü düzenlenebilir.RMAN bu parametreyi kullanarak BAckup ve Recovery yapar.Minimum 300k,Max 2 Gb olabilir. SQL > SELECT * 2 FROM v$sgastat 3 WHERE pool = ‟large pool‟; sorgusu ile kontrol edilebilir. DBWR_IO_SLAVES parametresi ile ARCN proseslerinin disk üzerinde ne kadara (kaç DBWn) IO yapacağını gösterir default olarak 0 dır,eğer RMAN kullanılacaksa 4 yapılır. BACKUP_TAPE_IO_SLAVES ise backup tapelerinin kullanımı içindir.Değeri True yapılırsa ,tapeler üzerinden okuma yazma yapılır.Yine aynı şekilde RMAN içindir. Database Buffer Cache : Datafile‟dan okunan veriler SGA içersinde bu alanda tutulur. Mantıksal olarak kendi içinde parçalara ayrılarak kullanılır.Veritabanı üzerinde işlem yapan tüm kullanıcılar burayı kullanırlar.Bu durumda yapılan işlemlerin belli bir sistematikte yapılması gerekmektedir.Bunu sağlamak için database buffer cache‟te “yazma listesi(Write List)” ve “en son kullanılanları tutan liste(List Recenlty Used-LRU- list)” olmak üzere 2 ayrı liste tutulur. “Write List” , “dirty buffer” olarak adlandırılan üzerinde değişiklik yapılmış ama diske(datafile‟a) henüz yazılmamış tampon alanları tutar.LRU listesi ise boş tampon alanları (free buffers) ,henüz “write list”‟e gönderilmemiş “dirty buffer” alan bilgilerini ve “pinned buffer” denilen o an işlem gören alanları tutar. Kullanıcının veri okuma isteği olduğunda önce bu cache‟te varmı diye bakılır.Var ise(cache hit) veri hafızadan direk okunur.Eğer yok ise (cache miss) veri ilgili data bloktan buraya okunur.Ama bunu yapabilmesi için önce hafızada boş alan bulunması gerekir.Bunun için LRU listesine bakılır. Boş bir alan bulunana ya da tanımlı bir eşik değere ulaşıncaya kadar arama sürer. LRU listesinde ”Dirty buffer” bulunca bu alan “write liste” alınır ve arama işlemi sürdürülür, boş alan bulununca burası LRU listesinin en sonuna atılarak ,veri , bulunan boş alana okunur.Boş alan bulunamadığı esnada belirlenen eşik değerine ulaşılınca LRU listesinde arama bitirilir ve DBW0 arka plan işlemcisine (background process) bir takım “dirty buffer” alanını diske yazması için sinyal gönderilir. RedoLog Buffer : INSERT,UPDATE,DELETE,CREATE,ALTER ve DROP işlemleri sonucu meydana gelen değişiklikleri hafızada tutulduğu kısımdır.Yapılan değişikliklerin geri alınmasında ve gerektiğinde “recovery” işlemleri için kullanılır.Sıralı ve doldugunda başa dönecek şekilde bir yapısı vardir. Bu alanda tutulan bilgiler “Log Writer Process(LGWR)” ile redo log dosyalarına yazılır.LOG_BUFFER parametresi redo log alanının büyüklüğünü belirler.Büyük değer alması I/O mailiyeti düşürür. Shared SQL Area ve Shared Pool: Paylasilmis SQL Alani, Oracle „in özel SQL deyimlerini çalistirmak için kullandigi bilgileri içerir. Bir SQL sorgusu isletilmeden önce ayristirilir ve bu sorgunun çalistirilmasi için bir çalisma plani hazirlanir. Isletilen sorgular bu alanda saklanir. Ayni sorgu birkez daha isletilmek istenirse bu çalistirma plani dogrudan uygulanabilir.Büyüklüğü SHARED_POOL_SIZE parametresi ile belirlenir.Varsayılan olarak 32 bit sistemler için 8MB, 64 bit sistemler için 64MB‟dır. Paylasilmis SQL Alani, SGA içindeki Paylasilmis Havuz „un bir parçasidir. Paylasilmis Havuz; SQL ve PL/SQL deyimlerini SQL ve PL/SQL deyimlerinin ayristirilmis hallerini SQL ve PL/SQL deyimleri için çalistirma planlarini veri sözlügü (data dictionary) önbellegini (cache) içerir.
  • 3. Anar Godjaev http://anargodjaev.wordpress.com/ Data Dictionary Cache : “Data Dictionary” bilgileri Oracle tarafından çok sık kullanıldığından hafızada tutulması mantıklıdır.İşte bu bilgilerin hafıza da tutulduğu yere “dictionary cache” denir.Bu bilgiler bir de “library cache”‟te de tutulmaktadır.Her iki alana tüm kullanıcı işlemleri ulaşmaktadır. Program Global Area – PGA : PGA, tek bir kullanici yada sunumcu görevi hakkindaki verileri yada kontrol bilgisini içeren yazilabilir fakat paylasilmamis bir bellek alanidir. Kullanici görevi Oracle veritabanina baglandigi ve bir oturum (session) baslatigi zaman bu alan bellekte ayrilir (allocate) . PGA yigit alani (stack space) oturum degiskenlerini ve dizileri tutmak için ayrilan bellek alanidir. Kullanici oturum verileri (user session data) oturum için fazladan bellek alanidir. PMON (Process Monitor) - Anormal bir sekilde kesilen baglantilari temizler. - Commit edilmemis degisiklikleri eski haline getirir (rollback). - İşletimi kesilen görevin tuttugu kilitleri kaldirir. - Çakilan görev için ayrilan SGA kaynaklarini serbest birakir. - Kilitlenmeleri (deadlock) otomatik olarak yakalar ve islemi geri döndürerek (transaction rolling back) çözümler. SMON (System Monitor) - Otomatic instance kurtarmayi gerçeklestirir. - Geçici segment alanini geri elde eder. - Kontrol kütügünün sürekliligini saglar. - Sistemde kullanilabilir durumdaki serbest alanin kaydini tutar. DBWR: DBWR görevi, kullanici görevlerinin her zaman bos bellek alanu bulabilmeleri için database buffer cache „i yönetir. degisiklige ugramis tüm verileri veri kütüklerine yazar. Yakin zamanda kullanilan veri bloklarini bellekte tutmak için LRU (Least Recently Used) algoritmasini kullanilir. Giris/çikis islemlerini eniyilestirebilmek için bazi yazma islerini erteler.
  • 4. Anar Godjaev http://anargodjaev.wordpress.com/ LGWR: LGWR ,redo log buffer „larini su durumlar olustugunda diske yazar; commit görüldügünde , redo log buffer dolulugu esik degerine ulastigi zaman. DBWR checkpoint için buffer bloklarin temizlemeye gerek duyarsa , time-out görülürse , Her Oracle instance „i için bir tane LGWR görevi vardir. Bir transaction redo log kütügüne islenmeden commit edilmis sayilmaz. DBWR görevi, veri bloklarini veritabanina geri yazmadan önce yapilan degisiklikleri korumak amaciyla LGWR görevine redo log buffer „larini bosaltmasi sinyalini gönderir. Arcn: ARCH görevi aslinda seçimlik bir arka plan görevi olmasina ragmen bir çok sistem için özellikle tavsiye edilir. Eger bu görev çalistiriliyorsa veritabani ARCHIVELOG kipinde çalisiyor demektir. Bu seçenek; tablespace „lerin çevrim-içi (on-line) yedeklenmesine medya failure „dan çevrim-içi kurtarmaya , günlük kütüklerinin otomatik olarak arsivlenmesine izin verir. ARCH görevi, günlük kütüklerinin kopyalarini, yerleri daha önce belirlenmis disk ya da teyp birimleri üzerine çikarir.
  • 5. Anar Godjaev http://anargodjaev.wordpress.com/ CKPT: checkpoint görevi, LGWR üzerindeki yükü azaltmak için kullanilir. Datafile ve redologlarda değişiklik olduğunda bunu bir SCN numarası ile control file lara yazmak zorundadır. Check point şu durumlarda oluşur. Her log switch aşamasında Log_checkpoint_interval parametresi ile belirtilen aralık gerçekleşti zaman Tablespace offline olduğunda ve online backup başladığında Alter system checkpoint komutu gerçekleştiğinde RECO: kurtarici (recoverer) görev, çakilmis dagitik transaction „lari çözümler. Snnn: multi-threaded sunumcuda kullanilan paylasilmis sunumcu görevleri. Dnnn: multi-threaded sunumcuda kullanilan dispatcher görevleri. SNPn: (snapshot) tazeleyici görevler. LCKn: parallel server seçimligi kullanildiginda instance „lar arasi kilitlemeyi kontrol eden görev. Oracle‟ın diğer fiziksel yapısıda aşağıdaki gibidir. Datafiles :(Binary) Her Oracle Veritabanı bir ya da daha fazla sayıda datafile içerebilir. Tablo, indeks gibi matıksal yapıların barındırdığı fiziksel bilgileri tutar.Belli başlı özellikleri: • Bir datafile sadece bir veritabanı ile ilişkilidir. • Bir ya da daha fazla datafile mantıksal yapılardan olan tablesace‟leri oluştururlar. • Gerektiğinde kendilerini otomatik olarak büyütme(extend) özellikleri vardır. Örneğin bir tablodan veri okunmak istediğinde bu hafızada(memory) yoksa ilgili datafile‟dan okunarak hafızaya çekilir ve okunur.Datalar üzerinde değişiklik yapıldığında ise hemen datafile‟a bu değişikşik yansıtılmaz.I/O miktarını düşük tutmak amacıyla bu işlem “Database Writer Process(DBWn)” adı verilen bir arkaplan işlemi (background process) tarafından karar verilen anlarda yapılır. Control Files : (Binary) Her Oracle veritabanının bir “control file”‟ ı vardır.Veritabanının fiziksel yapısı
  • 6. Anar Godjaev http://anargodjaev.wordpress.com/ hakkındaki (database adı, datafile ve redo log file‟ların adı ve yerlerinin bilgisi vb…) bilgileri tutar. Bu dosyadaki bilgiler çok önemli olduğu için Oracle bu dosyayı çoğullama özelliğine sahiptir.Eş zamanlı olarak dosyaları güncel tutar. Her Oracle instance başladığında bu dosyadan bilgiler okunur.Yeni datafile ya da redo log dosyası database‟de tanımlandığı anda Oracle control file‟ı günceller.(Ayrıca bu dosya kurtarma(recovory) durumunda da kulanılır.) SQL> SELECT name FROM v$controlfile; control filerların durumu hakkında bilgi alırız Control FileÇoğaltma $ SQLPLUS /NOLOG SQL> CONNECT SYS/ORACLE@NEWDB as sysdba; SQL> shutdown immediate; SQL> startup nomount; SQL>ALTER SYSTEM SETcontrol_files=„d:oracleoradatanewdbCONTROL01.CTL‟,‟d:oracleoradatanewdbCONTROL02.CTL‟ ,‟d:oracleoradatanewdbCONTROL03.CTL‟ , ‟d:oracleoradatanewdbCONTROL04.CTL‟ SCOPE=SPFILE; SQL> ALTER DATABASE MOUNT; SQL> ALTER DATABASE OPEN; Daha sonra SQL> shutdown immediate; İşletim sisteminden control file ın kopyası alınır. Daha sonra SQL> startup; SQL> ALTER DATABASE BACKUP CONTROLFILE TO 'FILENAME' SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE; SQL> show parameter user_dump_dest; SQL> SELECT name FROM V$CONTROLFILE; SQL> SELECT name, value from V$PARAMETER WHERE name = 'control_files'; SQL> SELECT type, record_size, records_total, records_used FROM v$controlfile_record_section WHERE type=‟DATAFILE‟; Redo Log Files :(Binary) Veriye yapılan tüm değişiklik işlemlerini tutmakla yükümlüdür.Datafile‟lara (bir şekilde) değişen bilgi yazılamadığı durumlarda redo loglardan bu işlemler görülebilir ve yapılan işlemin kaybı önlenir. Bu dosyalarında çoğullanma imkanı vardır.Farklı diskler üzerinde 2 ya da daha fazla kopyası tutulabilir.
  • 7. Anar Godjaev http://anargodjaev.wordpress.com/ Bu dosyanın amacı özetle sistem ya da donanım kaynaklı(harddisk göçmesi vs.) olası hatalarda datafile‟lara kalıcı şekilde yazılamayan bilgileri kurtarmaktır.Örneğin bir elektrik kesintisinde henuz datafile‟lara yazılmayan ve memory de bulunan bilgiler kaybedilir.Sistem tekrar ayağa kalktığında Oracle ilk önce redo log lara bakar.Kalıcı olarak datafile‟a yazılamayan bilgi olduğunu görür ve yarım kalan işlemi sonlandırır.Bu sayede veritabanı elektrik kesintisi olmadan evvelki konuma gelinmiş olur. Redo log file dolduğu zaman LGWR işlemcisi yeni bir gruba yazdırır. SQL> ALTER SYSTEM SWITCH LOGFILE; diyerek yeni bir logfile geçiş yapılır. FAST_START_MTTR_TARGET parametresi ayarlanarak switch süresi saniye süresinden belirlenir. SQL> select * from v$logfile; Logfiller hakkında bilgi alırız. SQL> select * from v$log_history; Control filelar üzerinde log fileların bilgilerini alırız. SQL> select * from v$log; Logfiller hakkında bilgi alırız. Yeni Bir LOG File eklemek ----------------------------------SQL> shutdown immediate; ////GEREK YOK SQL> startup nomount newdb;////GEREK YOK SQL> ALTER DATABASE ADD LOGFILE GROUP 4 („D:oracleoradatanewdbREDO04_a.LOG', 'D:oracleoradatanewdbREDO04_b.LOG') SIZE 100M; SQL> Alter database open; SQL> ALTER DATABASE ADD LOGFILE MEMBER '$HOME/ORADATA/u04/log1c.rdo' TO GROUP 1, '$HOME/ORADATA/u04/log2c.rdo' TO GROUP 2, '$HOME/ORADATA/u04/log3c.rdo' TO GROUP 3; SQL> ALTER DATABASE DROP LOGFILE GROUP 3; SQL> ALTER DATABASE DROP LOGFILE MEMBER '$HOME/ORADATA/u04/log3c.rdo'; SQL> ALTER DATABASE CLEAR LOGFILE
  • 8. Anar Godjaev http://anargodjaev.wordpress.com/ '$HOME/ORADATA/u01/log2a.rdo'; Archive Log Files : (Binary) Oracle veritabanı ARCHIVELOG modunda ise redo log dosyaları bu dosyalara otomatik olarak arşivlenir. Parameter Files (PFILEs):(TEXT) Veritabanı ve çalışan instance ile ilgili konfirigasyon parametrelerini içerir.”init.ora” bir parameter file‟dır. init.ora server tarafta bulunur.Ancak client‟tan (uzak erişim) ile veritabanın ulaşmak için gereklidir, static‟tir.Gerektiğinde (text dosya olduğundan) elle de değişiklik yapılabilir. 9i sürümüyle birlikte “Server Parameter File(SPFILE)(Binary)” kavramı geldi.SPFILE PFILEs‟dan oluşturulabilir.Bu PFILE gibi bir text dosya değil binary bir dosyadır ve sadece “ALTER SYSTEM SET” komutu ile değişir.Lokal makinadan veritabanını başlatmak için bir kopyasını lokalde tutmaya gerek kalmamaktadır. SPFILES kullanmak PFILE kullanmaktan daha avantajlıdır.Çünkü : • RMAN ile backup‟ı alınabilir.(RMAN, PFILE backup‟ı alamaz) • Server tarafında tutulduğundan ve değişiklik yapılıpta olur verilmeden evvel sistem tarafından kontrol edildiğinden insan kaynaklı hataların önüne geçilmiş olur. • Uzaktan veritabanını başlatmak için lokal makina da bir dosya tutulmasına gerek kalmaz. Oracle veritabanı PFILE‟dan ya da SPFILE‟dan başlatılmış olabilir.bunu anlamak için aşağıdaki sorgu kullanılabilir : SELECT DECODE(value, NULL, „PFILE‟, „SPFILE‟) “Init File Type” FROM sys.v_$parameter WHERE name = ‟spfile‟; PFILE‟dan SPFILE ya da SPFILE‟dan PFILE oluşturmak mümkündür : • CREATE PFILE FROM SPFILE; • CREATE SPFILE FROM PFILE; • CREATE SPFILE=‟/oradata/spfileORCL.ora‟ from PFILE=‟/oradata/initORCL.ora‟; Alert ve Trace Log Files :(TEXT) Her bir server ya da arka planda çalışan işlemlerin kendileri ile ilişkili bir “trace” dosyası vardır.Örneğin herhangibir hata (internal error) durumunda ilgili trace dosyasına ilgili bilgiler yazılır.Bunun dışında instance ve uygulamaları iyileştirmek için de referans olarak kullanılırlar. Alert dosyaları(log) ise özel trace dosyalarıdır.Veritabanın mesaj ve hatalarını kronolojik sırada tutarlar. Password Files : (Binary)Kullanıcının yaptığı bazı işlemleri saklar,örneğin database‟i kim açtı,kim kapadı,kim recover etti. DATABASE SENKRONİZASYONU Database açıldığı anda read only ve offline datafilelar hariç hepsi database ile senkronize olmalıdır. Senkronizasyon SCN numarası temel alınarak yapılır Redologların içindeki değiikliğe uğramış kayıtlar Datafilelara senkronize olmalıdır. Redologlar otomatik olrak Oracle server tarafından sorgulanır.
  • 9. Anar Godjaev http://anargodjaev.wordpress.com/ 1-)Datafilelar henüz senkronize olmamıştır,Oracle Server bu aşamada herhangi bir recovery olup olmadığına bakar. 2-)Son checkpointten itiaren değişkliğe uğramış datalar redologlardan ilgili datafilelara yazılmaktadır 3-)Datafilelar bu anda commit edilmiş ve edilmemiş dataları içermektedirler. 4-)Transactioon recovery veya rollback aşamasında,herhangi bir değişiklik yani commit edilmiş datalar rollback edilecektir. 5-)Datafile lar bu aşamada sadece gerçek commit edilmiş dataları taşıyacaktır. Instance Recovery Performansı Inıtıalization parametreleri doğru olarak ayarlayıp recovery işlemi hızlanabilir,Redologların boyutlarını ayarlayıp checkpoint süresini blli aralığa bağlayabiliriz.Sql statemntlarını düzgün ayarlayıp checkpoint süresini düzeltebiliriz.İnstance recovery paraelize ederek performansı arttırabiliriz. FAST_START_MTTR_TARGET parametresi İnstance recovery süresi sınırlama imkanı sunar.Saniye cinsinden süresi vardır. LOG_CHECKPOINT_TIMEOUT Bu süre ise Check pointler arasında geçen maximum zaman aralığıdır. LOG_CHECKPOINT_INTERVAL Bu süre ise checkpoint‟in ne zaman da bir oluşacağını belirten bir süredir. RECOVERY_PARALLELISM recover yapmak için atanacak server proseslerinin sayısını belirtir.