Expert Oracle Exadata - Parent Directory

CHAPTER 12 MONITORING EXADATA PERFORMANCEas where the percentage taken was from and the real values behind it. You can move your mouse overthe percentage and see the underlying values used for the calculation.So when moving your mouse over the ratio (see Figure 12-7b), you’ll see that the cells did read486GB from disks, but much more data (715GB) was actually sent back and forth over the interconnect.The metric explanations in Figure 12-7b are actually incorrect. The Bytes Read From Disks actuallymeans total bytes of reads and writes that Oracle Database has issued, not just for Smart Scans, but forany reason. And the Bytes Returned From Exadata actually means the total interconnect traffic betweenthe database and the cells, caused by any reason, such as block reads and writes and arrays of returnedrows by Smart Scans.Figure 12-7b. Cell Offload Efficiency ratio in the SQL Monitoring detail pageIf you are wondering why the I/O interconnect bytes is 715GB when the actual database-issued I/Ois only 486GB, the explanation is in how these metrics are measured. The database I/O metric (the BytesRead From Disk in Figure 12-6) is measured by the database layer, while the I/O interconnect bytes ismeasured by the low-level interconnect/Oracle networking layer. And one of the layers in between is theASM layer, which manages the software mirroring, among other things. So the interconnect I/O traffic inthis case is higher than the database traffic thanks to the write operations done by the SQL statement,which had to be mirrored by the ASM layer. So every MB written by database (whether because of directpath load or some work area operation spilling to temporary tablespace) resulted in the writing of 2MBof data thanks to ASM normal redundancy mirroring.There are other reasons why the interconnect traffic may be higher than the actual amount of dataread. One example is HCC compressed tables. If you have compressed your 10GB partition down to 1GB,then you will have to do 1GB worth of I/O to read it. But now if the Smart Scan uncompresses this data inthe cells on the fly and returns all that 10GB of uncompressed data back over the interconnect (assumingno projection or filtration in the cell was done), the I/O interconnect bytes will be much higher than theamount of data read from disks. This would drive the Cell Offload Efficiency down to 10% for thisexample Smart Scan. All this is yet another reason why you shouldn’t focus solely on improving just theCell Offload Efficiency ratio, but should rather look into where response time is spent instead. Time iswhat end users care about.387