Never given it a try. I'm also looking for suggestions on tuning pctfree/pctused and based on the contents of my clobs, whether or not to store them inline or out of line. any recommendations? On Fri, Apr 9, 2010 at 7:09 AM, Craig Hagan <hagan@xxxxxxx> wrote: > Why not dbms_redefine? > > On 4/8/10, Neil Kodner <nkodner@xxxxxxxxx> wrote: > > I have a letters table, it's 5.6M rows, 405 avg row len, 2837038 8k > blocks. > > 2 LOBs. the lobs are in-line. For whatever reason, these LOBS are > mostly > > NULL. Out of 5.6M rows, one of the lobs has 205,398 values, 7900 of > which > > are larger than 4000 characters. The other lob has 4.5M values, only 2 > of > > which are larger than 4000. This table takes FOREVER to full-scan, be it > an > > analyze or an export, select count, or anything else that requires a full > > scan. Additionally, queries against indexed columns result in long run > > times with a lot of LIO/PIO. > > > > I'm having some row chaining/migration problems with this table and it > > appears to be a good candidate for a rebuild, with a new values for > PCTFREE > > /PCTUSED. The table currently has a PCT_FREE of 40 and PCT_USED is not > set. > > > > > > I dont know if the fact that the lobs are inline(or the lobs in general) > are > > causing issues, or if the values for pctfree/pctused is. I can say that > > this is the worst performing table in my application. Im thinking of > > export/truncate/import this weekend but want to make sure its done > > correctly. I thought a value of 40 would be ok for pctfree. The lobs > and > > how they're being used, with all of the NULLS are throwing me for a loop. > > I'd appreciate some help in configuring this table for export/import. > > > > -- > Sent from my mobile device > > .- ... . -.-. .-. . - -- . ... ... .- --. . > > Craig I. Hagan > hagan(at)cih.com > > "Tout ce qui est exagéré est insignifiant.": ("All that is > exaggerated is insignificant.") > > Talleyrand >