Basically, a table is a "heap".  We stick data WHERE EVER. an index is a structure, we have to stick data where it belongs.

When we take an index block off of the free list -- it is "empty".  We will then totally fill it up  until we have to split it.  It only goes back onto the free list when it is empty again.  We cannot  put a block on the freelist unless it is empty -- the fact that the INDEX IS A STRUCTURE, prevents us from sticking just any data on the block.  Only data that can go onto that block can go there.  
It is just "not a heap". 

The first important advance in Oracle optimization technology follows from a simple mathematical observation:

You can't extrapolate detail from an aggregate.

Here's a puzzle to demonstrate my point. Imagine that I told you that a collection of 1,000 rocks contains 999 grey rocks and one special rock that's been painted bright red. The collection weighs 1,000 pounds. Now, answer the following question: "How much does the red rock weigh?" If your answer is, "I know that the red rock weighs one pound," then, whether you realize it or not, you've told a lie. You don't know that the red rock weighs one pound. With the information you've been given, you can't know. If your answer is, "I assume that the red rock weighs one pound," then you're too generous in what you're willing to assume. Such an assumption puts you at risk of forming

conclusions that are incorrect—perhaps even stunningly incorrect.

The correct answer is that the red rock can weigh virtually any amount between zero and 1,000 pounds. The only thing limiting the low end of the weight is the definition of how many atoms must be present in order for a thing to be called a rock. Once we define how small a rock can be, then we've defined the high end of our answer. It is 1,000 pounds minus the weight of 999 of the smallest possible rocks. The red rock can weigh virtually anything between zero and a thousand pounds. Answering with any more precision is wrong unless you happen to be very lucky. But being very lucky at games like this is a skill that can be neither learned nor taught, nor repeated with acceptable

reliability.

Gap can occur if LNS is unable to keep pace and the log buffer is recycled before the redo can be transmitted to the standby.

so how can we detect gap on our Dataguard environment?
some people use this method.

SQL> archive log list;

SQL> select  max(sequence#) from v$archived_log;

SQL> select sequence#, archived, applied from v$archived_log where applied='YES' order by 1;

Oracle Data Guard provide us with a simple view to detect a gap. we just need to query to that views.

SQL> select * v$archive_gap;

if there's no row selected, you have no gap in your oracle data guard.
don't forget to check your alert log

tail -10000f "your alert.log location"

for simplicity, Gap is a range of archived redo logs that were created at a time when the standby database was not available to receive them.
in many pratices it happen because the network problems.

We have 3 method to resolving this problem. i'll dispatch it to two main methods,

1. Manually resolving
2. Automatic resolving : Using log switched and FAL configuration

1. start with detecting gaps in the redo logs by querying the v$archive_gap

SQL> select * from v$archive_gap;

thread#   low_sequence#   high_sequence#
-------- ----------------  ------------------
         1                     30                      34 

   the output indicates our standby database is currently missing log files from sequence 30 to
   34.

2. issue following statement on primary database to locate the archived redo log files. assuming  
    the local archive destination on primary is LOG_ARCHIVE_DEST_1

SQL> select name from v$archived_log where thread#=1 and dest_id=1 and sequence# between 30 and 34; 

name
----------------------------------

/u02/oraarchive/DB01/arch_t1_s30.dbf  

/u02/oraarchive/DB01/arch_t1_s31.dbf  

/u02/oraarchive/DB01/arch_t1_s32.dbf  

/u02/oraarchive/DB01/arch_t1_s33.dbf  

/u02/oraarchive/DB01/arch_t1_s34.dbf 

3. stop the automatic recovery (MRP) of the data guard

SQL> alter database recover managed standby database cancel;

4. transfer manually the archived log files shown on the step 2 to standby database
5. register that archived log files on standby database

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s30.dbf'; 

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s31.dbf'; 

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s32.dbf'; 

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s33.dbf'; 

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s34.dbf'; 

6. put the standby database into automatic recovery managed mode

 SQL> alter database recover managed standby database disconnect from session;

7. verify that the gap gets resolved on standby database

SQL> select sequence#, applied from v$archived_log order by sequence#; 

now you figure it out, that your archived log files (ARCLs) has been synchronize with your primary database. as a DBA you must take a notice at log using this SQL statement

SQL> select message from v$dataguard_status where severity like 'Warning';

also on your alert.log


hope it will make your day easier.


Best Regards,
Dev Yudh

Background Proses

Untuk memaksimalkan kinerja dan untuk mengakomodasi kepentingan banyak user, sistem Multiproses Oracle menggunakan proses yang disebut background process, proses-proses yang ada disini berfungsi sebagai penjembatan antara Instance (SGA & PGA) dengan database (datafiles, control files, redo log files). Sistem oracle dapat mempunyai banyak background process, tergantung dari konfigurasinya. Background process tersebut adalah sebagai berikut:

• Database Writer (DBWR)
• Log Writer (LGWR)
• Checkpoint (CKPT)
• System Monitor (SMON)
• Process Monitor (PMON)
• Archiver (ARCH)
• Recoverer (RECO)
• Lock (LCKn)
• Snapshot Refresh (SNPn)
• Shared Server (Snnn)
• Dispatcher (Dnnn)
• Parallel Query (Pnnn)

Proses PMON dan SMON berfungsi untuk me-reclaim sumber daya database yang tidak dibutuhkan lagi oleh seorang user.

PMON (Process Monitor)

• me-Clean up hubungan yang diputuskan secara tidak normal
• me-Rollback transaksi yang belum di commit
• me-Release locking yang dipegang oleh suatu proses yang terminated
• Membebaskan sumber daya SGA (Memori SGA) yang dialokasikan pada proses yang gagal
• Me-restart proses server shared yang gagal dan men-dispatch proses-prosesnya.

SMON (System Monitor)

• Melakukan recovery instance secara otomatis.
• me-Reclaim space yang digunakan oleh Temporary segment yang tidak digunakan lagi
• Melakukan merge free space area pada datafile.

Empat Mandatory Process

• PMON, SMON, DBWR dan LGWR adalah proses mandatory yang harus dijalankan pada suatu instance Oracle. sementara proses lain nya optional
• PMON, SMON, DBWR dan LGWR tidak bisa dikendalikan dengan mengubah parameter inisialisasi

Jika ada salah satu dari empat proses yang gagal, instance akan crash dan harus direstart.

Proses RECO, LCKn, Pnnn dan SNPn
RECO, LCKn, Pnnn, dan SNPn akan dicreate ketika menggunakan salah satu Add On Option.


Proses

• Reco me-resolce kegagalan yang terlibat dalam suatu transaksi terdistribusi
• LCKn melakukan interinstance locking pada suatu sistem server paralel
• Pnnn menyediakan query paralel, pembuatan index paralel, loading data paralel, dan kemampuan CREATE TABLE AS SELECT paralel.
• SNPn melakukan refresh secara otomatis dari snapshots (table replikasi read-only). Proses tersebut juga akan bertanggung jawab pada antrian pekerjaan server dan antrian replikasi.

Options

• Paralel Query Option adalah suatu licensed product yang terpisah
• Procedural Option dibutuhkan untuk snapshots. hal itu termasuk dalam Oracle7 Server
• Distributed Option dibutuhkan untuk transaksi terdistribusi. Option ini adalah licensed product yang terpisah.
• repilcation Option adalah suatu licensed product yang terpisah.

Proses User

Suatu proses user digunakan ketika seorang user menjalankan suatu program aplikasi. proses User:

• Menjalankan tool / application atas pertimbangan client. contohnya Server Manager, Oracle Forms dan Pro*C.
• mem-pass SQL ke proses server untuk mendapatkan hasil..

Proses Server

sebelum data dapat diakses, sebuah proses server harus menempatkan data terlebih dahulu ke Database Buffer Cache. Untuk memproses perintah SQL, proses server akan menggunakan shared memory dalam SGA.


Task Proses Server

• Melakukan parsing dan mengeksekusi perintah SQL
• membaca blok data dari disk ke buffer database (Database buffer cache) shared di SGA
• mengembalikan hasil dari perintah SQL ke proses USer.

asa

Arsitektur Database Oracle terdiri dari 2 bagian:

• Instance Database
• Database

Instance database adalah segala hal yang berhubungan dengan Memory.

Sedangkan Database adalah bentuk Physical dari database oracle, dimana terdapat 3 bagian, yakni: Datafiles, Controlfiles dan Redo logfiles.

Instance Database Structure

Instance database terdiri dari blok besar SGA (Shared/System Global Area) dan PGA (Private Global Area).

Blok Database Instance.

from docs.oracle.com

Di dalam SGA Terdapat : 

• Mandatory: Shared Pool, Database Buffer Cache, Redo Log Buffer, Streams Pool 
• Optional : Large Pool dan Java Pool

Jadi, SGA adalah kumpulan (group) dari struktur shared memory yang memuat data dan informasi pengendali untuk suatu Sistem Basisdata Oracle. SGA harus selalu berada di dalam memori yang non-paged atau non-swapped. jika banyak user yang terhubung bersamaan, maka data pada SGA akan di shared diantara user-user tersebut. Ini mengapa SGA banyak diartikan sebagai (Shared Global Area).

Shared Pool

Shared Pool adalah suatu bagian dari SGA yang memuat konstruksi shared SQL Area dan Data Dictionary Cache.

** Shared SQL Area: adalah bagian dari SGA yang berisi segala macam sintaks SQL yang pernah dilakukan atau di eksekusi oleh USER. Setiap shared SQL area mengandung informasi yang digunakan untuk menjalankan suatu perintah SQL tunggal. proses-proses yang berjalan akan mengeksekusi perintah-perintah SQL identik yang informasinya di share. suatu perintah SQL ditempatkan pada suatu shared SQL Area berdasarkan pada suatu algoritma hashing yang diterapkan pada perintah tersebut. oleh karena itu, hanya perintah-perintah yang sama seluruhnya yang akan dialokasikan ke lokasi memori yang sama. bisa juga disebut Library Cache

** Private SQL Area: adalah bagian dari PGA yang berisi segala sintaks Private SQLS (Explicit cursor SQLs) yang dilakukan di tiap session.

beda dari keduanya adalah, Shared SQL Area dilakukan pada arsitektur multi-threaded dimana yang menangani proses session adalah SGA, sedangkan untuk Private SQL Area adalah bila sebuah session dijalankan pada sebuah arsitektur Dedicated (diambil alih oleh PGA = Private Global Area)

** Data Dictionary Cache

Data Dictionary merupakan suatu kumpulan tabel dan view basisdata yang mengandung referensi informasi tentang basis data, struktur, dan user. data yang disimpan dalam data dictionary adalah sebagai berikut:

• Nama dari semua tabel dan views dalam basis data
• Nama dan tipe data dari kolom dalam tabel basis data
• Privileges dari semua user Oracle

Content Shared Pool

• Teks perintah SQL atau PL/SQL
• Hasil parsing dari perintah SQL atau PL/SQL
• Rencana eksekusi dari perintah SQL atau PL/SQL
• Data Dictionary cache yang mengandung baris dari informasi data dictionary

Jadi, bila seorang user login ke database atau aplikasi yang terhubung ke database, dan melakukan eksekusi. maka SQL sintaks tersebut pertama kali akan diakses oleh Shared Pool ini. Meskipun sebelumnya, pada saat dia eksekusi SQL sintaks akan di cek dulu user tersebut login dari arsitektur multi-threaded (ditangani langsung SGA) atau dedicated (ditangani oleh PGA).

Database Buffer Cache

Database buffer cache adalah bagian dari SGA yang berfungsi untuk menyimpan copy dari blog data yang dibaca dari disk. semua user yang terhubung ke sistem memperoleh sharing untuk mengakses database buffer cache.

Pengaksesan Data

• Cache Miss : Terjadi pada saat pertama kali seorang User mengakses suatu bagian data, proses harus meng-copy data dari disk ke cache sebelum mengakses nya.
• Cache Hit : Terjadi ketika sebuah proses mengakses bagian data yang sudah ada di cache, proses tersebut dapat membaca data dari memori secara langsung.

sebuah pengaksesan data melalui cache hit akan berlangsung lebih cepat daripada pengaksesan data melalui suatu cache miss. karena cache memiliki keterbatasan ruang, maka semua data pada disk tidak dapat dimasukkan dalam cache. Ketika cache penug, subsekuen cache misalnya akan memberikan intruksi untuk menuliskan data yang sudah ada di cache ke disk untuk membuat tempat bagi data baru. dan akan menyebabkan suatu cache miss (karena data baru di tulis ke disk tuk pertama kali).

Database Buffer Cache akan dikunjungi jika seorang user melakukan query SQL setelah melewati Shared Pool.

Redo Log Buffer

Redo Log Buffer adalah suatu circular buffer yang berisi informasi tentang perubahan-perubahan yang terjadi di database, tugas Redo Log Buffer adalah:

• Mencatat semua perubahan yang terjadi pada basis data dalam redo log buffer
• merekonstruksi perubahanyang terjadi pada entry-entry basis data dan rollback segment pada saat terjadi proses recovery
• dapat di bypass menggunakan kata kunci UNRECOVERABLE pada perintah CREATE TABLE dan CREATE INDEX
• dapat di bypass oleh ORACLE data Loader