1Z0-043 · Question #195
You enabled Automatic Shared Memory Management. The initialization parameters are set as shown below: SGA_TARGET = 10GB SGA_MAX_SIZE = 14GB STREAMS_POOL_SIZE = 1GB SHARED_POOL_SIZE = 3GB Which two…
The correct answer is C. The value for SGA_TARGET can be increased up to a maximum of 14 GB. E. Increasing the value for SGA_TARGET to 12 GB will automatically increase the memory allocated. See the full explanation below for the reasoning.
Question
You enabled Automatic Shared Memory Management. The initialization parameters are set as shown below:
SGA_TARGET = 10GB SGA_MAX_SIZE = 14GB STREAMS_POOL_SIZE = 1GB SHARED_POOL_SIZE = 3GB Which two statements are correct in this scenario? (Choose two.)
Options
- AA total of 14 GB memory will be allocated to the automatically tuned memory components.
- BReducing the value for SGA_TARGET to 9 GB will automatically decrease the memory allocated
- CThe value for SGA_TARGET can be increased up to a maximum of 14 GB.
- DA maximum of 3 GB can be allocated to shared pool.
- EIncreasing the value for SGA_TARGET to 12 GB will automatically increase the memory allocated
- FIncreasing the value for SGA_TARGET will automatically increase the memory allocated for
How the community answered
(59 responses)- A5% (3)
- B2% (1)
- C73% (43)
- D7% (4)
- F14% (8)
Community Discussion
8
Bao N.Jan 17, 2026C and E are your answers here. With ASMM enabled, SGA_TARGET controls how much memory Oracle dynamically distributes across the auto-tuned components, and it can be raised dynamically up to the hard ceiling set by SGA_MAX_SIZE, which in this case is 14 GB, so C holds. E is correct because bumping SGA_TARGET to 12 GB does cause Oracle to automatically expand the auto-tuned pools to fill that new target, that is literally what ASMM is designed to do. A is wrong because it is SGA_TARGET, not SGA_MAX_SIZE, that governs the actual allocation right now, and D trips people up because SHARED_POOL_SIZE set manually just acts as a minimum floor with ASMM, not a ceiling, so Oracle can actually allocate more than 3 GB to the shared pool if demand requires it.
Luis F.Dec 28, 2025Yeah C and E are definitely the right picks here. SGA_TARGET can go up dynamically as long as it stays at or below SGA_MAX_SIZE, which is 14GB in this case, and bumping SGA_TARGET to 12GB gives ASMM more room to work with so it automatically redistributes that extra memory across the auto-tuned components like the buffer cache. One thing that tripped me up at first is D, because SHARED_POOL_SIZE = 3GB is a minimum floor, not a ceiling, so it is not limiting the shared pool to 3GB max.
Bao N.Dec 28, 2025Solid breakdown, and the D trap gets a lot of people because they read SHARED_POOL_SIZE as a cap when it is really just the lower bound that ASMM will not dip below, so the shared pool can still grow beyond 3GB as needed.
Dragan P.Jan 3, 2026C and E are your answers, and the key mechanic is that SGA_TARGET is a dynamic parameter bounded by SGA_MAX_SIZE, so you can slide it anywhere between its current value and 14GB at runtime without a bounce, while the auto-tuned components redistribute accordingly. Quick check for your understanding though: if SHARED_POOL_SIZE is already pinned at 3GB as a manually set minimum, what does ASMM actually do with that component, and does that explain why D is wrong?
Anjali D.Jan 5, 2026Dragan nailed the core mechanic, and to answer his follow-up, ASMM will honor that 3GB floor for the shared pool as a minimum guarantee but can still grow it beyond that if memory pressure warrants it, which is exactly why D falls apart since it assumes ASMM loses all control over a pinned component entirely.
Fatima Z.Jan 1, 2026I kept circling D until I pictured SGA_MAX_SIZE as the ceiling, and boom, C and E clicked.
Anjali D.Jan 23, 2026Hey everyone, catching up on where the group landed with this one. I went back and forth on it but I keep coming back to A and C as my picks, and I want to share why I am still holding onto A even though I know some folks pushed back on it. My thinking on A is this: when you set SGA_MAX_SIZE to 14 GB, that ceiling defines the total addressable space for the SGA, and with ASMM enabled, the automatically tuned components are going to fill up to whatever SGA_TARGET allows, but the hard upper bound on what can ever be allocated across all SGA components is that 14 GB figure. So saying 14 GB is the total that can be allocated feels right to me because SGA_MAX_SIZE is literally the cap on the whole structure. I know the argument is that SGA_TARGET at 10 GB is what actually gets handed out right now, but the question asks what is correct in this scenario, and the scenario includes a 14 GB max size that defines the ceiling of possible allocation. C feels solid and less controversial since Oracle explicitly ties the maximum dynamic increase of SGA_TARGET to the SGA_MAX_SIZE value, so you can push SGA_TARGET all the way to 14 GB without bouncing the instance. Curious if anyone who picked C and E instead of C and A can walk me through why E is better than A, because E and F both seem incomplete or circular to me. Weigh in if you have a different read.
Dragan P.Jan 23, 2026Anjali, A trips you up because SGA_MAX_SIZE is not what Oracle allocates, it is only the ceiling that protects you from ever exceeding 14 GB, and the memory Oracle actually hands out to the auto-tuned components right now is governed by SGA_TARGET, which is where E comes in. E is correct precisely because it identifies SGA_TARGET as the parameter defining the current total size of the auto-tuned SGA, making C and E the pair that accurately describes the behavior in this scenario.