Exadata’s unique sauce relies on the fact that the DB instance can offload work to the CellServers to speed up I/O bound queries. But how do you monitor the health of the CellServers?
A quick and dirty way, especially if you don’t have access to the CellServers is to use AWR in a database that’s currently using those CellServers. Let’s get an AWR report and search for the SMART IO section. It should look like this.
What you want to see here is that % Total MB Requested is evenly distributed across all Cells. The same applies for Storage Index and Flash Cache metrics.
Now this is the interesting part. If you happen to see the Offload % Efficiency dropping for one of the cells, that means that the Cell is sending the complete blocks back to the DB and then the % Passthru metric is going to increase.
You don’t really want the % Passthru to increase as this will have a direct performance is the DBs being served by this Cell.
What are the reasons of this Passthru increasing?
There are 3 reasons for Passthru.
The first one is due to an issue with the Cell itself. The second one is due to issues with DST patches and the third one is related to user queries crashing the Cell.
You should look at the below MOS note in order to gather all the required information and open an SR immediately after you see this behavior.
SRDC - Exadata: Smart Scan Not Working Issues (Doc ID 2310422.1)