While the internals of the utility are not disclosed, we see these parameters that effect the execution of the v$db_cache_advice.  (Note:  These may not be used within the historical data buffer reports):

• _db_cache_advice_batch_size

• _db_cache_advice_sample_factor

• dba_cache_advice=on or ready

First, there are several versions of the data buffer cache advisor:

• Real-time - The v$db_cache_advice utility samples data from the SGA in real-time, and creates a limited elapsed-time report from the SGA accumulators and addition memory from the dba_cache_advice settings.
  

• Historical with AWR and STATSPACK - It appears that the AWR and STATSPACK data buffer advisories use the DBA_HIST and STATSPACK table data for the report.

We also see some limitations to the accuracy of the data buffer advisor because of the architecture:

• Limited deltas - Using only two observations for logical reads and physical I/O are not enough data for a meaningful prediction.  The "current workload" assumption has a wide variance, and the numbers for a one minute report will be quite different from  a one hour report.
   

• Limited metrics - All of the advice from the data buffer cache advisory is limited to logical I/O and physical I/O at the system-wide level.
   

• Assumption of optimization? - The AWR data buffer cache advisor (and possibly the related v$db_cache_advice utility), only uses limited data points and some experts suggest that it assumes that the existing data buffer size is already optimal (the point at which the working set of frequently-used data blocks are cached, and additions to the data buffer result in marginally declining reductions in physical reads).

Hence, on the margin, the data buffer cache advisory is inaccurate for database with an undersized db_cache_size (and db_keep_cache_size, etc.).  With the data buffer set to a very small size, a small increase to the size of the RAM data buffers results in a large reduction in Disk I/O.

The data buffer cache advisory may underestimate the benefits with a too-small cache

However, the high reduction in Disk I/O does not continue ad infinitum. As the RAM size approaches the database size, the marginal reduction in Disk I/O is smaller because all databases have infrequently accessed data.

Using v$db_cache_advice

You enable the v$db_cache_advice with the db_cache_advice parameter.  The values are ready, on and off, and they can be set in the init.ora file, or dynamically enabled with an "alter system set db_cache_advice" command. 

MOSC Note:148511.1 says that the v$db_cache_advice view contains these columns, and the the main predictor (estimated physical read factor), is the ratio of estimated disk reads for each of the listed cache sizes:

• id - This is the ID number for the buffer pool, (values from 1 to 8). 
   

• name - Oracle allows for multiple data buffer pools as set by (db_cache_size, db_keep_cache_size, db_recycle_cache_size, and the instantiated blocksize buffers db_2k_cache_size, db_4k_cache_size, db_8k_cache_size, db_16k_cache_size and on non-Windows platforms, db_32k_cache_size).
   

• block_size - The blocksize for the data buffer (2k,  4k, 8k, 16k and 32k).
   

• advice_status - On of Off.
   

• size_for_estimate - This is the baseline cache size for the prediction. (e.g. 100m)
   

• buffers for estimate - The number of data buffers (e.g. 512).
   

• estd_physical_read_factor - The ratio of the number of estimated physical reads to the number of reads
  in the real cache.
   

• estd_physical_reads - This is the guess about the number of disk reads for each listed cache size (from 0.1 to 2.0).

Data buffer cache advisory usage notes

When using the v$db_cache_advice report, the DBA sets db_cache_advice=on, Oracle will steal RAM pages from the shared pool RAM area, often with disastrous result to the objects inside the library cache. For example, if the existing setting for db_cache_size is 500 MB, Oracle will steal a significant amount of RAM from the shared pool.

To avoid this problem, the DBA should set db_cache_advice=ready in the init.ora file, but only when using the advisory (always turn off the RAM overhead by setting (db_cache_advice=off) when your data buffer optimization is complete. When this is done, Oracle will pre-allocate the RAM memory at database startup time.

Internals of the AWR report for the data buffer advisor

The DBA invokes the standard awrrpt.sql in the $ORACLE_HOME/rdbms/admin directory.  The awrrpt.sql script, in turn, calls awrrpti.sql, which actually pulls the report.  Unfortunately, they use an internal query, so the internal machinations are hidden:
 
select output from table(dbms_workload_repository.&fn_name( :dbid,
                                                           :inst_num,
                                                           :bid, :eid,
                                                           :rpt_options ));

Overhead of v$db_cache_advice

MOSC Note:148511.1 says that the there will be additional CPU overhead when running the data buffer cache advisor, and that the largest resource overhead would be the 100 bytes of additional RAM overhead that is applied to each buffer whenever the utility is invoked (or when you have set db_cache_advice=on or db_cache_advice= ready).
 

"The advisory requires memory to be allocated from the shared pool (of the order of 100 bytes per buffer)."

In sum, the usefulness of a data buffer cache advisory is undisputed, but the true way to a successful predictive model is to use the scripts from my book "Oracle Tuning: The Definitive Reference". 

These provide a valid time-series analysis since the single delta values in the advisory are not sufficient.  Using STATSPACK data for consistent gets and physical reads, statistically significant trends can be established.