| Directory/Executable/File | Purpose |
|---|---|
| /opt/oracle | Top level directory containing Oracle storage server software |
| /opt/oracle.cellos | Directory containing Exadata cell software and utilities |
| /opt/oracle.cellos/cell.conf | Cell configuration file |
| /opt/oracle.cellos/CheckHWnFWProfile | Utility to validate hardware profile |
| /opt/oracle.cellos/ExadataDiagCollector.sh | Utility to collect cell diagnostics data, valuable for SRs |
| /opt/oracle.cellos/functions_cellos | Contains various Cell OS function calls |
| /opt/oracle.cellos/imageinfo | Shows current image information |
| /opt/oracle.cellos/imagehistory | Shows image history |
| /opt/oracle.cellos/ipconf[.pl] | Displays or configures cell network environment |
| /opt/oracle.cellos/iso | Contains kernel ISO images |
| /opt/oracle.cellos/make_cellboot_usb.sh | Creates a USB rescue image |
| /opt/oracle.cellos/MegaCli64 | MegaCLI—also in /opt/MegaRAID/MegaCli |
| /opt/oracle.cellos/patch | Directory for staged patches |
| /opt/oracle.cellos/restore_cellboot.sh | Restores from USB rescue image |
| /opt/oracle.cellos/validations_cell | Directory containing output from cell server validations |
| /opt/oracle.cellos/vldconfig | Configures cell validation |
| /opt/oracle.cellos/vldrun | Runs cell validation scripts and logs to /opt/oracle.cellos/validations_cellw |
| /opt/oracle/cell | Symlink to /opt/oracle.cell[VERSION] |
| /opt/oracle/cell[VERSION] | Directory containing current cell software. For example, /opt/oracle/cell11.2.2.4.2_LINUX.X64_111221 |
| /opt/oracle/cell[VERSION]/cellsrv | Directory containing cellsrv software |
| /opt/oracle/cell[VERSION]/cellsrv/deploy/config | Configuration deployment files for active cell image |
| /opt/oracle/cell[VERSION]/cellsrv/deploy/config/cellinit.ora | Cell initialization parameter file |
| /var/log/oracle | Directory containing cell server log files, alerts, and trace files |
| /var/log/oracle/cellos | Directory containing log and trace files for Cell Services utilities, validation framework, and cell server startup/shutdown events |
| /var/log/oracle/diag/asm | Directory containing log and trace files for cell storage-related events in your cell |
5 key features that empowers this engineered system:
1. Smart Flash Cache
The Exadata Storage Server layer includes some flash storage as a hardware component, which has been implemented as a set of PCI flash cards. The main benefit of that is of course faster access than standard, disk-based access. In some cases you can order Exadata to KEEP whole table in Smart Flash Cache which speeds up database layer access with Full Table Scans. On the other hand in Write-Back mode you can empower DBWR or LGWR performance by putting written data on flash cache first, and afterwards sync it with regular hard drives, which of course is transparent to database engine.
2. Storage Indexes
It is absolutely unique to Exadata. Storage Indexes are an intelligent storage implementation. Generally speaking classic database index by it definition is created to efficiently provide a location of a certain data key. To be honest Storage Indexes in Exadata are focused on eliminating areas on storage as possible place where data might exist. Online data maps which are completely transparent for database layer are stored on the Flash Cache of Exadata Storage Servers. To make the story short, when Exadata Storage Server scans through the Storage Index and identifies the regions where predicate value falls within the MIN/MAX for the region, only for the identified regions physical I/O occurs. And as a consequence, even Full Table Scan has been planned by CBO on Database Server layer, limited I/O operations use to be proceed.
3. Smart Scans and Cell Offloading
Offloading use to be called as secret sauce of Oracle Exadata. The main concept of Offloading is to move processing from DB Nodes (Database Servers) to the intelligent storage layer. What is even more important Offloading means the reduction in the volume of data that returns to database server, which is one of the major bottlenecks in terabytes or even more bigger databases. To eliminate the time spent on transferring completely unnecessary data between storage and the database tier is the main issue that Oracle Exadata has been built to solve. Keep in mind that Offloading and Smart Scan terms could be used somewhat interchangeably.
4. Hybrid Columnar Compression
Also known as HCC, Hybrid Columnar Compression is one of the key features of Oracle Exadata, and it is only available on this engineered system. HCC format of compression will be used only when data arrives with direct path loads. There are four levels of compression QUERY LOW (LZO, 4x), QUERY HIGH (ZLIB, 6x), ARCHIVE LOW (ZLIB, 7x) and ARCHIVE HIGH (Bzip2, 12x). Keep in mind that HCC is not a good option for OLTP systems. In case of HCC mechanics, HCC store data in nontraditional format. Even data resides in Oracle blocks, with block header for every block, in HCC data storage has been organized in logical structures called compression units (CUs). Each CU consists of multiple Oracle blocks.
5. IORM
I/O Resource Manager (IORM) is a Oracle Exadata features which enriches Oracle Resource Manager from Database layer. IORM only actively manages I/O requests when needed and when Storage Server is not fully utilized, it provide data immediately. But when a disk is under heavy utilzation, Storage Server software redirects the I/O requests to the appropriate IORM queue and schedules I/O from there according to the policies defined in your IORM plans. Generally IORM policies open the way to prioritize databases on intelligent storage layer, which enable workload optimization.