Skip to Main Content
  • Questions
  • Force Full Database Caching in Oracle Database 12c

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Mohammad.

Asked: March 09, 2016 - 2:51 pm UTC

Last updated: March 12, 2016 - 1:12 am UTC

Version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

Viewed 1000+ times

You Asked

Hi,

Can you please advise regarding Force Full Database Caching new feature in Oracle Database 12c?

I applied all required steps to get this feature active, and the the database has SGA and DB_CACHE_SIZE parameters greater than entire database instance.

After test application after caching, nothing was changed, and elapsed time still the same as before enabling this feature.

Please, clarify reasons, or if there are prerequisites before enable this feature.

Thanks in advance.

Regards,

and Chris said...

Full Database Caching just means that Oracle will keep all objects in the buffer cache.

Of course, it's possible that your whole database (or just those bits relevant to your queries) is already in the buffer cache. In this case you're not going to notice any difference.

As it says in the docs:

To improve database performance for table scans and LOB data access, especially for workloads that are limited by I/O throughput or response time, consider using force full database caching mode whenever the size of the database buffer cache is greater than the size of the database.


https://docs.oracle.com/database/121/TGDBA/tune_buffer_cache.htm#TGDBA95405

So if your queries only do index lookups and read no LOBs you may not notice any difference.


Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Some Clarifications

Mohammad Awadallah, March 11, 2016 - 6:08 am UTC

Dears,

Thanks for your reply, appreciated.

Could you please find my inquiries and practical case i encountered below, and clarify it:

As mentioned in document that i read and find also in attached link for your response:

"
13.5.3 Determining When to Use Force Full Database Caching Mode
To improve database performance for table scans and LOB data access, especially for workloads that are limited by I/O throughput or response time, consider using force full database caching mode whenever the size of the database buffer cache is greater than the size of the database.

Consider using force full database caching mode in the following situations:

The logical database size (or actual used space) is smaller than the individual buffer cache of each database instance in an Oracle RAC environment. This is applicable for non-Oracle RAC database as well.

1. The logical database size is smaller than 80% of the combined buffer cache sizes of all the database instances for well-partitioned workloads (by instance access) in an Oracle RAC environment.

2. The database uses SGA_TARGET or MEMORY_TARGET.

3. The NOCACHE LOBs need to be cached. The NOCACHE LOBs are never cached unless force full database caching is used.
"

What I did:

- I ran 52 queries related to some business with no Force Full Database caching, and i got 37 sec as elapsed time. And i monitor Physical and Logical reads using:

select name,value
from v$mystat natural join v$statname
where name in ('physical reads',
'physical reads direct','session logical reads');

and i got physical reads after execution query twice or more.

After that, I set Force Full Database Caching parameter to True, with the following parameter values:
db_cache_size=12000m
sga_target=18000m
memory_target=20000m

and the whole size of Database is 11000m.

I ran same query again, first time i had Physical reads and with elapsed time 38 sec.

I ran queries again with 0 physical reads, But, the same elapsed time.

Please advise regarding that. and if you clarify the 3 points mentioned in paragraph.

Excuse me a second question,,,

What is the best solution especially in 12c to get very small response time:
- Full Database caching
- In-memory
- Using Solid Disks

Thanks in advance, and appreciate your response.

Regards,



Connor McDonald
March 12, 2016 - 1:12 am UTC

I have a friend who says "Everything is a CPU problem".

Here's a blog post I made showing how I/O is not *everything* when it comes to reponsse time:

https://connormcdonald.wordpress.com/2013/11/24/once-youve-done-your-io-theres-still-more-to-do/

In-memory is probably the biggest performance booster out there, because its *not* just about putting things into memory - its about compression, restructuring the rows, using special CPU optimizations etc.