Yes, consistent gets should equal the sum of those four statistics, and if you look at the equivalent numbers in V$BUFFER_POOL_STATISTICS indeed it does. I suspect that the problem is that the consistent gets statistic in V$SYSSTAT actually counts consistent reads rather than consistent read gets. That is, if a session already has a handle on a CR buffer from an earlier consistent get and re-reads that buffer using its cached buffer handle, then V$SYSSTAT counts that as another get whereas it is not really a get at all.

The APT script tunable_cache_miss_rate.sql avoids V$SYSSTAT by using the V$BUFFER_POOL_STATISTICS data under Oracle8, and the sum of the four consistent read gets statistics previously.

In the "Calculating the Cache Hit and Miss Ratio" discussion, it has been stated that:

"Note, however, that due to a long-standing Oracle bug the consistent gets statistics actually overstates the number of consistent gets very significantly. For this reason, it is better to use the sum of 'no work - consistent read gets', cleanouts only - consistent read gets, rollbacks only - consistent read gets and cleanouts and rollbacks - consistent read gets at this point."