ORACLE - Exadata

EXADATA X2 - has 4 configuration with High Performance or High capacity options:
1) Exadata X2-2 Quarter Rack
2) Exadata X2-2 Half Rack
3) Exadata X2-2 Full Rack
4) Exadata X2-8 Full Rack

Smart Scan is only possible for Full Table Scans or Full Index Scans.• Smart Scan can only be used for Direct-Path Reads:• Direct-path reads are automatically used for parallel queries.• Direct-path reads may also be used for serial queries.
1. Client issue a SELECT statement for few rows and columns
2. DB KERNEL check - EXADATA available - construct a iDB command
3. EXADATA SERVER Software scan the data block to extract rows and columns
4. This is not a NLOCK IMAGE so they are not store it BUFFER CACHE
5. DB KERNEL collect result sets from all cells
6. row are return to Client (using PGA)

Predicate filtering:– Only the requested rows are returned to the database server rather than all the rows in a table.
Column filtering:– Only the requested columns are returned to the database server rather than all the columns in a table.
A compression unit is a logical structure spanning multiple database blocks.
• Each row is self-contained within a compression unit.• Data is organized by column during data load.• Each column is compressed separately.• Smart Scan is supported.　A storage index is a memory-based structure that reduces the amount of physical IO required by the cell. A storage index keeps track of minimum and maximum values from query predicates and builds storage index regions based on usage.
The storage space inside each cell is logically divided into 1Mb chunks called "storage regions"
In each storage region, data distribution statistics are maintained in a memory structure called a region index.
Each region index contains distribution information for up to 8 columns.
The storage index is a collection of region indexes.Fast Mirror Resync: During transient disk failures within a failure group, ASM keeps track of the changed extents that need to be applied to the offline disk. Once the disk is available, only the changed extents are written to resynchronize the disk, rather than overwriting the contents of the entire disk. This can speed up the resynchronization process considerably.
Order of Patches:1.Infinibands Switchs patch: Spine and Leaf
2.Storage Server patch : Cell nodes and Database Minimal Pack in compute nodes
3.Grid home (CRS ASM) and Oracle Home Patch
　XDMG and XDWK background processes/opt/oracle.SupportTools
/etc/oracle/cell/network-config/ceillip.ora and cellinit.ora
IOPS - Disk Bandwidth : OLTP - small random I/OMBPS - Channel Bandwidth: DW - Large sequential I/O


Exadata Log files:

On the cell nodes:
1. Cell alert.log : $CELLTRACE:/opt/oracle/cell/log/diag/asm/cell/{node name}/trace/alert.log
 2. MS logfile : $CELLTRACE:/opt/oracle/cell/log/diag/asm/cell/{node name}/trace/ms-odl.log.
3. OS watcher output data: /opt/oracle.oswatcher/osw/archive/
4. VM Core files :/var/log/oracle/crashfiles
5. SunDiag output files :/tmp/sundiag_.tar.bz2
7. Cell patching issues related logfiles: /var/log/cellos
The major logfile of patch application output you will find in the db node from where you are patching in the location /tmp/<cell version>/patchmgr.stdout and patchmgr.err
8. Disk controller firmware logs:  /opt/MegaRAID/MegaCli/MegaCli64 -fwtermlog -dsply -a0

On the Database nodes:
1. Database alert.log : $ORACLE_BASE/diag/rdbms/{DBNAME}/{sid}/trace/alert_{sid}.log
2. ASM alert.log : $ORACLE_BASE/diag/asm/+asm/+ASM{instance number}/trace/ alert_+ASM {instance number}.log
3. Clusterware CRS alert.log : $GRID_HOME/log/{node name}/alert{node name}.log
4. Diskmon logfiles : $GRID_HOME/log/{node name}/diskmon/diskmon.lo*
5. VM Core files for Linux : /u01/crashfiles