- 3,734,281 Users
- 2,246,937 Discussions
- 7,857,218 Comments
- 380.9K All Categories
- 2.1K Data
- 203 Big Data Appliance
- 1.9K Data Science
- 446.1K Databases
- 220.4K General Database Discussions
- 23 Multilingual Engine
- 506 MySQL Community Space
- 459 NoSQL Database
- 7.7K Oracle Database Express Edition (XE)
- 2.8K ORDS, SODA & JSON in the Database
- 438 SQLcl
- 3.9K SQL Developer Data Modeler
- 185.4K SQL & PL/SQL
- 20.8K SQL Developer
- 291.3K Development
- 6 Developer Projects
- 117 Programming Languages
- 288.1K Development Tools
- 96 DevOps
- 3K QA/Testing
- 645.2K Java
- 18 Java Learning Subscription
- 36.9K Database Connectivity
- 149 Java Community Process
- 104 Java 25
- 22.1K Java APIs
- 137.7K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 12 Java Essentials
- 138 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 195 Java User Groups
- 180 LiveLabs
- 34 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 165 Deutsche Oracle Community
- 1.2K Español
- 1.9K Japanese
- 225 Portuguese
Find if temporary objects created before TEMP_UNDO_ENABLED is set
Version : Oracle 12c (126.96.36.199) - EE 2-node RAC, active DG
I'm trying to reduce REDO and archive logs generated for my application and measure using V$SYSSTAT and corresponding archive logs using DBA_HIST* views.
In my application code on DB side, I'm using the session level setting of
TEMP_UNDO_ENABLED to direct UNDO for gtt into temporary tablespace. The specific feature noted here.
ALTER SESSION SET TEMP_UNDO_ENABLED = TRUE; INSERT INTO my_gtt VALUES...
I see the documentation has this quote:
..if the session already has temporary objects using regular undo, setting this parameter will have no effect
If I use a pure database session, I can ascertain that since no other temporary tables have been created/used before setting the parameter, the REDO logs generated are minimal. I can use a simple (
select value from V$SYSSTAT where name= 'redo size') to see the difference.
However the actual application (Java) triggers this code through a JDBC session. As such, I'm unable to ascertain if before the call to '
ALTER SESSION..' there were any GTT or other temporary objects previously created/used in the session. The consequence of this is, if say a GTT was already used, then the call to '
ALTER SESSION SET TEMP_UNDO_ENABLED = TRUE' simply ignores the setting without an indication. The code will continue logging UNDO & REDO in the normal tablespace, which is unintended.
Is there any way to query if this parameter TEMP_UNDO_ENABLED is already set/unset within the session, so that before I do a
ALTER SESSION SET TEMP_UNDO_ENABLED = TRUE I'll know for sure this 'will' or 'will not' have an effect?
Thanks in advance for inputs.