The lobsegment contains 8128896 blocks, 1183 extents and the size is around 65GB. We actually truncated the source table and then tried shrinking this lobsegment in order to release the free space.
I did test in development and UAT environments (single instance RAC databases) and it took almost a day and half duration to complete the task. However, the following get stuck on the production:
ALTER TABLE tablename MODIFY LOB (column_name)(SHRINK SPACE) nologging parallel 5;
Due to the bug, I am unable to predict how long this operation would take as no information is listed in v$session_logops dynamic view as well. Unfortunately, Oracle support too can't confirm me when would this operation finishes. The only saving point to me is that the other sessions working on the table works fine. Neither there is any performance impact nor any excessive redo generation causing.
Upon analyzing my trace files, 10046 and oradebug short_stack, Oracle support confirms that the operation is not hanged, it is progressing.
Keeping in view about no impact on the database, they requested me to leave it running as killing session may trigger SMON recovery on this table.
My boss says, whatever I am handling ending up hitting the bug, one of very rare unfortunately days of my life.
Happy reading,
Jaffar
1 comment:
Some times you got to take things politically especially with management. With such managers, always try to find an easy way out, do not overdo the techie stuff, since your manager does not clearly understand the techie part of how oracle database works, feed him with tihings he want to hear and still achieve your target with another approach.
There will always be approach to other alternatives.
If I were you, I would create a window for downtime (think of any reason that he will understand like houskeeping etc and not for a bug), apply the bug patch.
You got to take risks in life.
wish you all the best jaffer
Cheers
Post a Comment