Re: truncate has execessive row cache wait

  • From: ~Jeff~ <jifjif@xxxxxxxxx>
  • To: zhuchao@xxxxxxxxx, oracle-l@xxxxxxxxxxxxx
  • Date: Mon, 22 Sep 2008 21:46:47 +1200

I stand corrected - it was actually an "alter table xxx deallocate storage
keep xxx" run dozens of times with smaller and smaller keep clauses,
following on from a "truncate ... reuse storage"

Sorry, it was quite a few years ago!

2008/9/22 <zhuchao@xxxxxxxxx>

> Truncate reuse storage does not touch fet/uet.
> You must be using drop storage that time?
>
> Sent via BlackBerry by AT&T
> ------------------------------
> *From*: ~Jeff~ <jifjif@xxxxxxxxx>
> *Date*: Mon, 22 Sep 2008 15:49:31 +1200
> *To*: <oracledbaquestions@xxxxxxxxx>; <oracle-l@xxxxxxxxxxxxx>
> *Subject*: Re: truncate has execessive row cache wait
>
> if this is DMT, there can be performance issues with large numbers of
> extents. Very slow recursive lookups hitting sys.uet$ and fet$.
>
> I once had to truncate a table gradually over 24 hrs (..reuse storage..)
> because it had >30,000 extents, ugh :P
>
> -Jeff
>
>
>

Other related posts: