1Z0-052 · Question #211
Users complain about the slow response time of queries. While investigating the cause you find that the Oracle Instance is not configured to cache all of the data blocks to satisfy the users'…
The correct answer is H. Database buffer cache. The database buffer cache is the SGA component that caches data blocks from data files in memory, and increasing its size reduces physical disk I/O to improve query response time.
Question
Users complain about the slow response time of queries. While investigating the cause you find that the Oracle Instance is not configured to cache all of the data blocks to satisfy the users' queries. Which component of the Oracle Instance would you change to improve performance?
Options
- AJava pool
- BLarge pool
- CShared pool
- DStreams pool
- ELibrary cache
- FRedo log buffer
- GData dictionary cache
- HDatabase buffer cache
How the community answered
(61 responses)- C3% (2)
- E7% (4)
- F2% (1)
- H89% (54)
Why each option
The database buffer cache is the SGA component that caches data blocks from data files in memory, and increasing its size reduces physical disk I/O to improve query response time.
The Java pool allocates memory for Java VM session state and Java stored procedure execution and has no role in caching data blocks for SQL queries.
The large pool is used for RMAN backup buffers, shared server session memory, and parallel query messaging, not for caching data blocks accessed by user queries.
The shared pool caches parsed SQL statements and PL/SQL code to avoid repeated parsing overhead but does not cache the actual data blocks that SQL queries retrieve.
The streams pool is reserved for Oracle Streams and Advanced Queuing memory buffers and is entirely unrelated to caching user data blocks.
The library cache is a subdivision of the shared pool that stores parsed SQL cursors and execution plans, not the data blocks returned when those queries execute.
The redo log buffer holds change vectors (redo entries) temporarily before LGWR flushes them to disk and plays no part in caching data blocks for read operations.
The data dictionary cache stores metadata rows such as table definitions and user privileges to speed up internal Oracle lookups, not the user data blocks accessed by application queries.
The database buffer cache holds copies of data blocks read from disk so that repeated access to the same blocks is served from memory rather than from disk. When the buffer cache is undersized, Oracle must continually evict and re-read blocks, causing high physical I/O and slow queries; increasing DB_CACHE_SIZE allows more blocks to remain in memory and directly resolves the performance problem.
Concept tested: Oracle SGA database buffer cache sizing for performance
Source: https://docs.oracle.com/en/database/oracle/oracle-database/19/cncpt/memory-architecture.html
Topics
Community Discussion
4
Anjali D.Jun 19, 2026The correct answer is H, the Database Buffer Cache. This is the component of the SGA that holds copies of data blocks read from the datafiles, so when a query needs data, Oracle checks here first before doing expensive physical disk reads. If the buffer cache is too small to hold enough blocks for your workload, Oracle constantly has to evict blocks and re-read them from disk, which is exactly the slow response pattern users are describing. Sizing it up via the DB_CACHE_SIZE parameter (or letting the Automatic Memory Management handle it if you have AMM enabled) is the right lever to pull here. The distractors are worth a quick mention for anyone who got tripped up. The Shared Pool and its subcategories like the Library Cache and Data Dictionary Cache are about caching SQL execution plans and metadata, not actual row data. The Large Pool is for things like RMAN and parallel query memory, the Java Pool is for JVM session state, the Streams Pool is for Advanced Queuing and Streams, and the Redo Log Buffer is about change vectors going to the redo logs, none of those touch data block caching at all. If your study group is seeing slow queries tied to high physical reads in the AWR report, the buffer cache hit ratio is the first stat to check.
Nina C.Jun 20, 2026I kept second-guessing myself on C because the shared pool sounds big and general enough to cover everything, but the question says data blocks specifically, and the database buffer cache is the one memory component that actually holds copies of data blocks read from disk, so H is where I landed. Can someone confirm that is the right way to think about it, because I want to make sure I am not just memorizing the answer but actually understanding why the other pools are off the table here?
Viktor S.Jun 27, 2026I'll be honest, I glanced at "data blocks" and my eyes jumped straight to the Shared pool because it holds parsed SQL and the data dictionary, which sounds adjacent to "cached data." That was sloppy thinking on my part. The question is right there in the wording: data blocks. The Database buffer cache, option H, is literally the region of the SGA that holds copies of data blocks read from the datafiles, and when it is too small, Oracle keeps re-reading blocks from disk every time a query needs them, which is exactly the slow-response symptom you are describing. The Java pool, Streams pool, Large pool, none of those touch data blocks at all, and the Library cache lives inside the Shared pool and handles parsed SQL cursors, not the block-level data itself. If you are sizing the SGA and you want fewer physical reads showing up in your AWR report, the Database buffer cache is the knob you turn.
Nina C.Jun 28, 2026Right, and a detail worth knowing for the exam is that Oracle provides V$DB_CACHE_ADVICE, a view that models how your physical read count would change at different cache sizes, so there is an actual tool to justify resizing that region rather than just guessing.