This content has been marked as final. Show 8 replies
There could be that this job is not the only one needing undo space in production. In pre-prod you're probably "alone" .
agreed with above, cant relate activity in a prod to preprod. see support note
How To Size UNDO Tablespace For Automatic Undo Management [ID 262066.1]
If youre still crashing at 60gb, increase to 70gb. It needs what it needs.
All the database parameters in both production and UAT environment are same-Whats the value of undo retention.
Also check is there any other exiting session in PROD which may consuming undo as well.
Kuljeet Pal Singh
No,there is no other process that is using the Undo table in production.I can confirm that.
The Undo Retention is 4 hours in both UAT and production.
Hi,1 person found this helpful
Please check what else is occupying the undo during the running of this load. If possible try and reschedule the load to a different time when the db is quiet. If you are licensed for it, try generating an awr during the run. Check undo_retention times, retention_guarantee, etc. Increase undo size or assign it to an undo group. Check for inefficient code aswell...
Could you please give me an idea:
Our query is using ,at this moment,over 119GB of Undo tablespace.We are looking at records between 220 million and 240 million.Does oracle really take this much of Undo space for these many records?In our procedure,we have done commits after every insert statement.Then why isn't the Undo tablespace not freeing its space,as it should normally?
user1128836 wrote:BAD, BAD, Bad bad implementation.
we have done commits after every insert statement.
NEVER do COMMIT inside LOOP!
Then why isn't the Undo tablespace not freeing its space,as it should normally?post SQL & results that show above is true.