RE: DROP LMT TBS internals.

yea, I conflated a couple things creating confusion, but "yes", I had to drop things with 150,000+ extents by doing truncate...reuse... and then "alter...deallocate" judiciously. We used to have millions of used and free extents, but now since global=>partitioning conversion, have only about 140K total. Much nicer, but...i think the damage has been done in C_TS# and C_FILE#_BLOCK#.

total PITA.

LMTs rock, totally. So looking forward to being on 92 on real CPUs (non SPARC, whooppee!) and new DataDict...

-----Original Message-----

From: Mark W. Farnham [mailto:mwf_at_rsiz.com] Sent: Tuesday, September 21, 2004 11:45 AM To: oracle-l_at_freelists.org
Subject: RE: DROP LMT TBS internals.

oops. I didn't mean a Wolfgang (10053), I meant 10046.

mwf

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Mark W. Farnham
Sent: Tuesday, September 21, 2004 9:37 AM To: oracle-l_at_freelists.org
Subject: RE: DROP LMT TBS internals.

I'm not sure what would hold up dropping an LMT tablespace other than dictionary operations on the names of the objects in the LMT. In the case of LMTs, I'm not sure whether extra work is avoided by taking the tablespace off-line and using offline drop including contents. That should, however, short circuit transactions from interfering with the dictionary actions on the objects in the tablespace, so if you offline the tablespace first and then drop it you should be able to isolate where the wait is between references to the segments in the tablespace and the mechanics of the drop itself. I've never Wolfganged a drop tablespace (I did truss one long ago but that was dictionary and before 10046 was available, and the output was too long to analyze usefully.) I would think the operation in lieu of segment reference interference would be so short that it wouldn't be worth detailed research. Since you're having an actual problem, maybe it is worthwhile.

Now if you really are looking for a metric on progress similar to watching uet$ or fet$ for dictionary managed spaces, I suppose that if you count from dba_segments where the storage is that tablespace you should see the count drop. Of course that metric might slow down the operation.

Regards,

mwf

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of SJHussain_at_alfransi.com.sa
Sent: Sunday, September 19, 2004 3:21 AM To: oracle-l_at_freelists.org
Subject: DROP LMT TBS internals.

Hello List,

If I am dropping a LMT Tablespace and it takes a long time, how can I know that the process is running, not hanged. Can anyone let me know what are the internal functionality of drop tablespace. I know that we can check fet$ for DMT TBS, how about LMT TBS?

Best Regards,

Syed Jaffar Hussain

Visit us on www.alfransi.com.sa
====== Banque Saudi Fransi - Privacy Notice ====== This message is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any use of this information by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete the material from your computer. Any opinions and other information contained in this message that do not relate to the official business of Banque Saudi Fransi shall be understood as neither given or endorsed by it. Although precautions have been taken to ensure no viruses are present in this email, BSF cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ====== Banque Saudi Fransi - Privacy Notice ======

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l Received on Tue Sep 21 2004 - 11:31:40 CDT