1Z0-064 · Question #81
You are administering a database that supports an OLTP workload. An application regularly creates global temporary tables and a large number of transactions are performed on them. You notice that…
The correct answer is C. Enable temporary undo. https://docs.oracle.com/cd/B13789_01/server.101/b10739/undo.htm
Question
You are administering a database that supports an OLTP workload. An application regularly creates global temporary tables and a large number of transactions are performed on them. You notice that performance is degraded because of excessive generation of undo due to a large number of transactions on the global temporary tables. What is the recommended action to improve performance? (Choose the best answer.)
Options
- AIncrease the size of the undo tablespace and enable undo retention guarantee.
- BIncrease the size of the database buffer cache.
- CEnable temporary undo.
- DIncrease the size of the temporary tablespace or make it autoextensible.
- EEnable Automatic Segment Space Management (ASSM) for the undo tablespace.
How the community answered
(36 responses)- A11% (4)
- B3% (1)
- C81% (29)
- D6% (2)
Explanation
https://docs.oracle.com/cd/B13789_01/server.101/b10739/undo.htm
Topics
Community Discussion
6
Yusuf A.May 5, 2026C is the right call here. When you enable temporary undo (TEMP_UNDO_ENABLED=TRUE), Oracle stores the undo for global temporary tables in the temp tablespace instead of the undo tablespace, which cuts down that excessive undo generation your OLTP workload is drowning in and gives you a real performance boost without touching the undo tablespace size at all.
Nina C.May 7, 2026Good point, and worth adding that TEMP_UNDO_ENABLED=TRUE also reduces redo generation on top of that, since undo records for global temporary tables no longer need redo protection once they move to the temp tablespace, so you actually get a two-for-one I/O benefit.
Dervla O.May 2, 2026C is the right call here, and the reasoning comes down to where undo for global temporary tables actually lives once you flip that switch. Before you defend that answer on the real exam, though, can you explain what specifically changes about the undo storage location when temporary undo is enabled, and why that reduces pressure on the undo tablespace rather than just shifting it somewhere else?
Nina C.May 5, 2026When temp undo is enabled, undo for GTTs moves into the temp tablespace instead of the undo tablespace, and the real relief comes from the fact that temp tablespace blocks are not subject to undo retention requirements and get reclaimed automatically when the session ends, so you're not just moving the data, you're removing the retention overhead entirely.
Nina C.May 18, 2026Before I answer, can I ask, when you say the undo is getting generated for the global temporary tables, do you know if the database is on Oracle 12c or later? I ask because the fix here depends on a feature that was introduced in 12c, and if you are on an older version the option I am thinking of would not even be available to you. That said, the reason performance is hurting is that global temporary table data is session-private, so there is no real need to write undo for it into the regular undo tablespace where it competes with every other transaction. All that undo generation is pure overhead in this case. The recommended fix is to enable temporary undo, which is option C, because that redirects the undo for global temporary tables into the temporary tablespace instead, keeping it out of the undo tablespace and reducing contention significantly. Options A and D both throw more space at the wrong part of the problem, and E (ASSM for undo) does not address where the undo is being written, only how space is managed inside that tablespace.
Yusuf A.May 20, 2026Good catch on the version gate, Nina, and yeah temporary undo (option C) is the right call, though I would also mention that you still need to set TEMP_UNDO_ENABLED = TRUE at the session or system level or the feature just sits there doing nothing even on 12c and above.