Heap Organized Table Ve Index Organized Table

Üç tür tablo çeşiti vardır.

Bunlar;

•       Heap organization table

•       Index organization table

•       External organization table  

Biz burada sadece HOT ve IOT indeks yapılarını analiz edeceğiz. Ve karşılaştırmasını yapacağız.

Öncelikle  team tablosu oluşturacağız. Heap organized table’da Create cümlesinin sonunda “organization Heap” demeye gerek yoktur. Yazmadığımız zaman da bu HOT table olur. Default olarak tüm tablolar HOT’dur.

Sorgunun çalıştırılmasında kullanılan execution planda sorgunun erişiminde Index rowid’si kullanılmıştır. Yani indeks segmentindeki kayıtlı index bloğu kullanılmıştır.

Aşağıdaki tabloda HOT(heap organization table) ‘un index yapsını şeması vardır. Yani bir index segmenti içerisindeki index tablosundaki index bloğunun yapısını anlatmaktadır. 2 byte Row header’ a sahiptir ve 6 byte row id adresi tutulur.

HOT tablolarda ise table blok yapısı aşağıdaki gibidir. 3 byte Row Header’ a sahiptir.

Örnek bir IOT tablolardaki index yapısı aşağıdaki gibidir.

•          Burada sadece bir index row header’a sahiptir. Index  uzunuluğu 3 karakter ve bilgisi FER dir.IOT için , Create table ifadesinden sonunda Organization Index zorundayız. Fiziksel table Rowid lerdetutulmazlar ,index Rowidlerde tutulur.
•         IOT’ lar ayrı bir Table segmentine ihtiyaç duymaz. Primary Key  Constrainti almak zorundadır. İndex segment ismi primary key Constraint’ine bağlıdır.ismini oradan alır.( SYS_IOT_TOP_<object_id>)
•          IOT’ lar LONG türünde kolonlar içermezler. Reversed index olamazlar. Yerden tasarruf sağlamak için sıkıştırılabilirler.
•          IOT Tablolarda eğer primary key kolonu ilk sırada tanımlanmamışsa oracle bu yapıyı tekrardan bir reorder yapacaktır.

IOT Overflow table:

• Çok büyük satırları IOT’ larda tutmak verimsiz bir davranıştır. Bu yüzden bu tür satırları overflow segmentinde saklamak daha mantıklıdır.
•   Primary key  satırları indeks segmentinde bulunur. Non-key olan satırlar indeks  segmenti yada  overflow segmentinde bulunur. 
• Overflow segmenti ilave extra bir table segmentidir. Bir indeks overflow için  row 6 byte Rowid içerir.

Aşağıda örnek bir IOT overflow index bloğu verilmiştir.

d

Karşılaştırma:

HOT ve IOT'u karşılaştıracak olursak daha az leaf kullancağından bilginin aranıp bulunması daha kısa sürer.

           

        

Resim Kaynakları: Julian Dyke

        

Enterprise Manager Console ‘de ERROR: NMO not setuid-root (Unix-only) sorunu

Enterprise Managerda host bazı önemli işlerde host credintials girişler gerekmektedir. Dolayısıyla veritabanının kurulu olduğu ve sahiplenildiği user ‘ın login olması gerekmektedir.

Ve geçenlerde almış olduğum bir hatayı sizinle paylaşmak istiyorum. Linux işletim sistemi üzerinde mevcut oracle kullanıcımızın password ‘unu değiştirmiştim. Fakat enterprise manager’ da host credentials ekranında login olmak isterken ERROR: NMO not setuid-root (Unix-only) şeklinde bir hata aldım.

Ve aşağıdaki şekilde root olarak sisteme bağlanarak ve aşağıdaki işletim sistemi komutlarını girelim.

root#>

cd $ORACLE_HOME
chmod 6750 bin/nm?
chmod 700 bin/emdctl
chmod 700 bin/emagent
chown root bin/nm?

daha sonra oracle kullanıcına bağlanarak

oracle $>

emctl stop dbconsole
emctl start dbconsole

komutlarını girerek enterprise manager’i ayarların etkili olması için yeniden başlattım. Ve artık sorun çözülmüş oldu.

ADDM Nedir?

Automatic Database Diagnastic Monitor(ADDM)
Her bir AWR snapshot’u alındığında son iki snapshot ‘a karşılık periyodun analizini yapar.

• Her AWR snapshotundan sonra çalışır

• Instance ‘i monitor eder ve oluşacak darboğazları tespit eder.

• Sonuçları AWR’ da depolar.

ADDM tarafından belirlenen bazı ortak sorunlar şunlar olabilir.

• Cpu bootlenecks

• Lock Contention

• IO Kapasite sorunu

• High- Load SQL statements

• High PLSQL and JAVA

• Çok hızlı Checkpoint gerçekleşmesi

• Oracle Net Bağlantı sorunları

ADDM aşağıdaki dynamic Performance view leri yada Enterprise Manager Konsolu ile hem bulgularını hemde tavsiyelerini görebiliriz.

ADDM Views

View Name	Description
DBA_ADVISOR_TASKS	Provides information about existing task, like – task id, name, etc.
DBA_ADVISOR_LOG	Contain the current task information such as status, progress, error messages, and execution times.
DBA_ADVISOR_RECOMMENDATIONS	Complete result of diagnostic task.
DBA_ADVISOR_FINDINGS	Display all symptoms and specific recommendations.

Genel olarak ADDM tavsiyeleri(Recommendation) şunlardır:

• Schema Changes

• Hardware Changes.

• Application Changes

• Database Configuration

• Diğer Advisorları tavsiye eder.

Diğer Advisorlar ise

SQL Tuning Advisor, tek bir SQL statementi analiz eder. Bu statementin performansını arttıracak tavsiyeler verir. Instance Konfigrasyosyon değişimi, Statement’in yeniden yazılması yada SQL profile, Index Ekleme gibi tavsiyeler verir. Daha çok tek bir SQL cümlesi yerine Tuning Setler oluşturarak performans talebinde bulunuruz.

SQL Access Advisor, perfromansı geliştirecek materialized view yada materialized log yada ilave index oluşturmamasını tavsiye eder. Verilen bir zamanda girilmiş tüm SQL statementleri analiz eder.

Memory Advisor(SGA Advisor, PGA advisor), Instance tarafından kullanılacak toplam memory için en ayarları bulup tavsiye eder.)SGA advisorunda altında çalışan alt advisorlar vardır.(Shared Pool advisor,Java Pool Advisor, Buffer Cache Advisor, Strams pool advisor gibi)

Segment Advisor verimsiz kullanılan alan tüketimini kontrol eder. Öneride bulunur. Shrink, Reorganize gibi tavsiyeleri vardır.

Undo data ile ilgili sorunlarda Undo Advisor

Backup – Rocovery de oluşacak sorunlarda MTTR (Mean time to Recovery) advisor’ ı

tavsiye eder. Genel olarak Instance crash olduktan sonra bir database recovery için gerekli zaman ayarıdır.

Automatic Workload Repository

Genel olarak Self-Tuning amaçlı, problem belirleme özelliği olan ve istatistik toplama ve saklama özelliği olan bir altyapıdır.Her 60 dk ‘da ( default) Database otomatk olarak SGA’dan istatistik bilgilerini alır ve AWR içerisinde Snapshot formatında saklar. Default olarak AWR içerisinde bu snapshotlar 8 gün saklanır. Saklanma süresini yada default snapshot aralığını değiştirebiliriz.

Oracle 11g ’de SYSAUX tablespace’ nde depolanan ve SYSMAN shemasına ait yüzlerce tablo bulundurur. DBMS_WORKLOAD_REPOSITORY paketiyle yada Enterprise Manager Konsol ile Repository ‘ kullanabiliriz. Oracle da zaten bu iki yöntemi tavsiye etmektedir.

AWR tablolarına karşı gelen DML istekleri desteklenmez. Sadece okunur.

AWR yapısı ikiye ayrılır.

1. Memory’ de saklanan istatistikler vardır.

Bu istatistikler performans nedenlerinden ötürü memory de saklanır.

Dinamik performance view’ ler (V$ )ile memory de saklanan database istatistiklerine erişilebilir.

2. AWR içerisinde saklanan istatistikler kalıcı olarak saklanan istatistiklerdir. İstatistikler birkaç nedenden dolayı kalıcı olarak saklanmaya ihtiyaç duyulur.

a. Bir instance crash(çökmesine )karşı istatistik ihtiyacı duyulur.

b. Bazı analizler, bir Baseline karşılaştırması için Historical bir dataya ihtiyaç duyulur.

Memory Monitor (MMON) proces’i tarafından Memory’ deki Instance istatistiği kalıcı olarak saklamak için diske yazılır.

Baseline, AWR snapsotların bir kümesidir. Başlangıç ile bitiş snapshotların arası  performans kıyaslaması yapılması için kullanılır

Create Baseline:

BEGIN
DBMS_WORKLOAD_REPOSITORY.create_baseline (
start_snap_id => 200,
end_snap_id => 220,
baseline_name => ‘Test_baseline);
END;
Delete Baseline:
BEGIN
DBMS_WORKLOAD_REPOSITORY.drop_baseline (
baseline_name => ‘test_baseline’,
cascade => TRUE);
END;
/
Retention Period: Default 8 gündür ve sonsuza kadar saklama seçenekleri vardır.
Collection Interval: Snapshot aralığıdır. default olarak 60 dk dır.
Collection Level: İstatistik toplama seçenekleridir. Basic seçeneğinde ADDM fonksiyonunu kapatır. Yani Self tuning disable olacak. Typical yada All seçenekleri tavsiye edilir
Örneklerle anlatırsak.
SQLplus ‘a bağlanalım
$>sqlplus / as sysdba
SQL>Select * from DBA_HIST_WR_CONTROL;
DBID SNAP_INTERVAL RETENTION TOPNSQL
--------- ------------------ -------------------- ---------
1272787738 +00000 01:00:00.0 +00008 00:00:00.0 DEFAULT
2189780853 +00000 01:00:00.0 +00008 00:00:00.0 DEFAULT
Sonuç olarak iki tane DB var. Ve bunların snapshot aralığı 1 saat. Retention (saklama) 8 gün olarak görünüyor.

Önemli AWR View’ leri

View Name	Description
V$ACTIVE_SESSION_HISTORY	Displays the active session history (ASH) sampled every second.
V$METRIC	Displays metric information.
V$METRICNAME	Displays the metrics associated with each metric group.
V$METRIC_HISTORY	Displays historical metrics.
V$METRICGROUP	Displays all metrics groups
DBA_HIST_ACTIVE_SESS_HISTORY	Displays the history contents of the active session history.
DBA_HIST_BASELINE	Displays baseline information.
DBA_HIST_DATABASE_INSTANCE	Displays database environment information.
DBA_HIST_SNAPSHOT	Displays snapshot information.
DBA_HIST_SQL_PLAN	Displays SQL execution plans.
DBA_HIST_WR_CONTROL	Displays AWR settings.

Renaming Database Name

Renaming Database Name:

Burada nid utility kullanarak mevcut bir veritabanın adını değiştirmeyi göreceğiz.

Öncelikle database’ i backup almanızı öneririm. Temiz bir backup alındıktan sonra database kapatılır. Ve mount modunda açılır.

Not:(koyu yazılan komut girişleridir.)

SQL> shu immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Total System Global Area 1121554432 bytes

Fixed Size 1336008 bytes

Variable Size 889195832 bytes

Database Buffers 218103808 bytes

Redo Buffers 12918784 bytes

Database mounted.

SQL> exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

With the Partitioning, Automatic Storage Management, OLAP, Data Mining

and Real Application Testing options

[oracle@mhm /]$ nid target=sys/Oracle_4u@ORCL dbname=NewORCL

DBNEWID: Release 11.2.0.1.0 - Production on Sun Oct 23 22:34:28 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Connected to database ORCL (DBID=1272787738)

Connected to server version 11.2.0

Control Files in database:

+DATA/orcl/controlfile/current.260.745007003

+FRA/orcl/controlfile/current.256.745007003

Change database ID and database name ORCL to NEWORCL? (Y/[N]) => Y

Bilgisi girilir.

Sqlplus ‘a sysdba olarak girilir. Ve

SQL> ALTER SYSTEM SET DB_NAME=neworcl SCOPE=SPFILE;

SHUTDOWN IMMEDIATE

Daha sonra database kapatılır.

SQL> shu abort;

Bu şekilde kapanmazsa abort modunda kapatmaya zorlanır.

Bir sonraki adım yeni bir password dosyası oluşturulur.

[oracle@mhm /]$ orapwd file=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/pwdneworcl.ora

password=password entries=10

bir sonraki adım çalıştığımız spfile dosyasına yeni DBNAME i set etmek. Bunun için

SQL>sqlplus / as sysdba

SQL>create pfile=’initneworcl.ora’ from spfile;

Sonra $ORACLE_HOME/dbs altında yeni oluşan initneworcl.ora dosyasını bir text editor ile açın. Ve DBNAME alanını yeni isimle değiştirin.

Daha sonra database shutdown yapın.

oracle@mhm /]$ ORACLE_SID=neworcl

oracle@mhm /]$ export ORACLE_SID

daha sonra yeni database name’i tnsnames.ora ve listener.ora dosyalarına işletmek için lsnrtl reload yapılır.

Lsnrctl reload

Son olarak da veritabanını RESETLOGS ile açın.

SQL> startup mount;

SQL> alter database open resetlogs;

Kayıp bir datafile kurtarmak.

Örnek olarak datafile dosyalarımızdan birisini sileceğim. Ve daha önce almış olduğum bir full backuptan restore ederek datafile dosyalarının nasıl kurtarıldığını görebileceğiz.

Database ait tüm datafile görmek için v$datafile dinamik view' den sorgulayabiliriz.

SQL> Select name from v$datafile;

NAME

--------------------------------------------------

/export/home/oracle/datafile/system01.dbf

/export/home/oracle/datafile/undotbs01.dbf

/export/home/oracle/datafile/sysaux01.dbf

/export/home/oracle/datafile/users01.dbf

/export/home/oracle/datafile/example01.dbf

/export/home/oracle/datafile/deneme01.dbf

Dosyayı siliyorum.

$ rm /export/home/oracle/datafile/deneme01.dbf

Şimdi RMAN’ a bağlanıyorum .

$ rman target /

RMAN> report schema;

Report of database schema

List of Permanent Datafiles

===========================

File Size(MB) Tablespace RB segs Datafile Name

---- -------- -------------------- ------- ------------------------

1 500 SYSTEM *** /export/home/oracle/datafile/system01.dbf

2 35 UNDOTBS1 *** /export/home/oracle/datafile/undotbs01.dbf

3 250 SYSAUX *** /export/home/oracle/datafile/sysaux01.dbf

4 5 USERS *** /export/home/oracle/datafile/users01.dbf

5 100 EXAMPLE *** /export/home/oracle/datafile/example01.dbf

6 100 DENEME *** /export/home/oracle/datafile/deneme01.dbf

Var olan backupsetten deneme01.dbf dosyasını yüklemek için restore komutunu kullanıyoruz.

RMAN> restore datafile 6;

Starting restore at 09/08/2011

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=154 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

restoring datafile 00006 to /export/home/oracle/datafile/deneme01.dbf

channel ORA_DISK_1: reading from backup piece /export/home/oracle/FRA/ORA10GR2/b ackupset/2011_08_09/o1_mf_nnndf_TAG20110809T011841_740r61n9_.bkp

channel ORA_DISK_1: restored backup piece 1

piece handle=/export/home/oracle/FRA/ORA10GR2/backupset/2011_08_09/o1_mf_nnndf_T AG20110809T011841_740r61n9_.bkp tag=TAG20110809T011841

channel ORA_DISK_1: restore complete, elapsed time: 00:00:15

Finished restore at 09/08/2011

Şimdi burada 6 numaralı datafile sadece backup anındaki durumunu kopyalıyoruz. Backup tan sonraki değişikliği ise Recover komutuyla gerçekleştiririz.

Recover komutu ise kullandığımız backup dosyasından sonra yapılan değişiklikleri datafile eşitlemek için kullanılan komuttur. Yani log (archive) dosyalarını yada incremental backupları işletme komutudur.(bende fazla bir değişiklik olmadığından kısa sürdü)

RMAN> recover datafile 6;

Starting recover at 09/08/2011

using channel ORA_DISK_1

starting media recovery

media recovery complete, elapsed time: 00:00:01

Finished recover at 09/08/2011

Böylece artık deneme01.dbf dosyası yerinde ve son commite kadar olan değişikliğini de içermektedir.

System Global Area (SGA) Nedir?

System Global Area denilen veritabanımızın Instance' da yer alan ve içinde shared Pool, large Pool, Database Buffer Cache, Java Pool, Stream Pool ve database ile bu yapılarla arka planda faaliyet gösteren SMON, PMON, CKPT,DBWRn, LGWR gibi back ground proces' lerden oluşan Memory' deki ayrılmış bölgedir.



Database Instance iki bölümden oluşur. Birisi SGA, diğeri ise PGA(program global area). PGA konusuna ayrı bir konu alarak ele alacağımdan şimdilik SGA ile ilgili bilgiler vermek istiyorum. Database Instance'nın Memory'e yüklenmesi Veritabanının çalışmasındaki ilk safhadır.Yani Database ilk açılışında başlangıç parametrelerine göre açılacaktır. Ve bu açılışta bu değerler memory' de instance oluşturacaktır.

Önemli sayacağımız konulardan bir tanesi de SGA' nın yönetimidir. SGA_TARGET initilization parametresine verilen değerle SGA' nin Memory de ne kadar yer allocate(ayrılacağını) edeceğini belirlemiş oluruz. Örneğin SGA_TARGET=2G dersek memory'de 2GB lik bir hafızayı SGA ve bileşenleri için ayırmış olacağız. Diğer bir husus, SGA bileşenleri nasıl yönetilecek? otomatik mi yoksa manuel mi? yani Large Pool yada shared Pool un memorydeki boyutu nasıl olacak. işte buna bizim karar vermemiz gerekiyor.Automatic Shared Memory Management (ASMM) şayet SGA için aktif edilirse SGA_TARGET parametresine bir değer verilir. SGA bileşenleri database çalışma esnasında ihtiyaca göre paylaşımlı olarak bu değeri kullanırlar.Direct I/O işlemleri ve Backup işlemi belleğin Large Pool bileşeninde gerçekleşeceğinden işlemin daha hızlı gerçekleşmesi için daha fazla belleğe ihtiyaç duyacağından diğer bileşenlerde daha az işlem yapılıyorsa o bileşenlerden belleğin bir kısmı alınıp large pool' a o anlık dahil edilir.
SGA_TARGET parametresini 2GB vermişsek ve ASMM enabled ise de SGA bileşenlerini sorguladığımızda şayet bu bileşenler için bir alt değer set etmemişsek, değerleri 0 sıfır görülecektir.
Temel olarak SGA bileşenlerini inceleyecek olursak;
Shared Pool:içerisinde Library cache,Data dictionary cache vardır.
Library Cache, SQL statementlerin Execution planları ve yol haritaları bulunur.Execution planlar, optimizer tarafından toplanan istatistiklere göre oluşturulur. Sorgu sonucunun daha hızlı çalışması için kullanılır.Database performansını ciddi ölçüde etkiler.
Data Dictionary cache ise o anda alınan SQL statement için yetki, rol, erişim izni, hangi indexi kullanacak gibi dataların kontrol edildiği yerdir.
Bu bileşenin bellek miktarını SHARED_POOL_SIZE parametresiyle belli edebiliriz.
Database Buffer Cache: çalışacak SQL statement yada statementler şayet bu bellek bloklarında yok ise datafile de okunarak buraya getirilerek çalıştırılır. İçerisinde SQL statementlerinin çalıştırılma sıklığına göre takip eden bir LRU algoritması vardır. İsteğe görede SQL statementini sakla diyebilirsiniz.DB_BUFFER_CACHE_SIZE parametresiyle bellek alanı verebiliriz yada öğrenebiliriz.
Java Pool : java paketlerini bulundurur. JAVA_POOL_SIZE parametresi ile değer verebiliriz yada öğrenebiliriz.
Large Pool : I/O işlemlerinin , Backup-Recovery işlemlerinin, direct read-write işlemlerinin yapıldığı bileşendir. Örneğin elimizde çok büyük bir datanın güncellenmesi gerekiyor. Ve bu dataya baktığımızda buffer cache deki boş alandan daha fazla bir boyuta sahipse yapılan işlemler buffer cache değil, Large pool da yapılır. yani datafile direkt erişim sağlanır.
LARGE_POOL_SIZE parametresi ile bellek boyutunu öğrenebiliriz. yada belirli bir değer set edebiliriz.
Redo Log buffer cache: database de yapılan tüm değişiklikler redo log bufferda tutulur. örneğin siz bir insert işlemi yaptınız. yapılan değişiklik redolog buffer cache de tutulur. LGWR processini tetikleyen bir olay olduğunda redolog bufferi kalıcı olarak redolog dosyalarına yazılır ve redolog buffercache boşaltılır, yeni değişiklikleri yazmaya tekrar başlar.
Redo loglar database de bir recovery işleminde gerekli olan dosyalardır. Database' deki önemli olmazsa olmaz 3 dosyadan birisidir.
Stream Pool: ise streaming işlemleri için yani lokalde yada lokal dışındaki başka bir yere database replikasyonu esnasında data gönderme/alma işleminde kullanılan bileşendir.

Makaleme başlarken ilk başta database mimarisi ile ilgili temel kavramların tanıtılmasını ve anlaşılmasının iyi olacağını kanaatindeyim.Fazlada ayrıntıya girmeden temel düzeyde bırakmak istedim. Umarım yararlı olmuştur.