Understand The Oracle Exadata Cell Offload Feature

Oracle Exadata Smart Scan and Cell Offloading

Smart Scan is probably the most important performance component of the software in terms of exceptional performance offered by Exadata. Smart Scan is a cell offloading feature that is to process into storage cells offload of performing block I / O requests at the database layer. The purpose of Smart Scan processing is to perform all “heavy lifting” I / O operations in the storage cell and send data back only to the really necessary and requested compute nodes. This reduces link traffic between the storage grid and database layer, reduces clutter in database buffer cache improves.

Oracle Database Server without Exadata

Systems that are not exadata cannot load processing in a traditional database system (for example, servers that connect to a storage array via the fiber array) because storage is not intelligent and not cell offload. Oracle claims that Exadata storage cells are a “Smart Storage Grid”. The basis of this claim is that each storage cell is actually a server with CPU and operating system running Exadata cell software. Database servers can communicate with cells using a new, special protocol called “Intelligent Database protocol (iDB)” by Oracle. Instead of receiving block-level IO commands in the form of a traditional storage array, iDB allows cells to understand the type of processed workload and – potentially – change their behavior accordingly.

Exadata Cell Offload Operations

Ok well, Let’s create a cell offload table with 18 lac records.

SQL> show parameter cell_offload_processing

NAME TYPE

cell_offload_processing boolean
TRUE

In order to get the exact result regarding the flush scenario;

SQL> alter system flush buffer_cache;
System altered.

SQL> alter system flush SHARED_POOL;
System altered.

Disabling cell_offload_processing and checking the query results

SQL> alter session set cell_offload_processing=FALSE;
System altered.

SQL>set timing on;

SQL> select count() from cell_test where emp_id>1500;

COUNT()
2020000

Elapsed: 00:01:45.40

Ok, Now let’s activate the cell offloading process and check the query output.

SQL> alter system flush buffer_cache;
System altered.

SQL> alter system flush SHARED_POOL;
System altered.

SQL> alter session set cell_offload_processing=TRUE;
Session altered.

SQL>set timing on;

SQL> select count(*) from cell_test where test_id>1500;
COUNT()
2020000

Elapsed: 00:00:41.20

Yes, if you look at the difference between two periods, you can see how much cell unloading affects Exadata performance.

Have a nice day.

Also you can check out my other post: Celldisk and Griddisk are Not Created

Also source link to increase performance on oracle exadata