We got good results when we tweaked the memory within the text index parameters to hundreds of megs (in our case it was about a 50G index). I remember a gotcha something along of the lines that if even if you asked for (say) 500M of memory, then if this exceeded the "global" ctx memory parameter (set with ctx_adm), then it would be silently adjusted down... Plus of course cranking up sort_area_size / sort_area_retained_size parameters, partitions in parallel etc etc hth connor On 5/19/05, Prem Khanna J <premjhere@xxxxxxxxx> wrote: > Hi All , >=20 > One of my collegue has got a problem on index rebuilds. >=20 > *************************************************************************= **=3D > ** > We have a table of 35 partitions with a CLOB column amount to about > 350G of data. Based on the timing for the domain index creation on > the CLOB column in development database with smaller data volume using > parallel degree of 8, I extrapolated (development database is on a > much smaller box and I used linear extrapolation) that it will take > ~53 hours to create the same index in production database, which is > not feasible to do even in a weekend. Are you aware of any "divide > and conquer" or any methods we can explore to create the index in much > less time so that it is feasible to accomplish in a weekend? From > your experiences on other applications, What do other > people/application do if they have a huge index and it gets corrupt > and needs to be rebuilt and the rebuild time normally takes days? > Index online rebuild will not help us because the domain index needs > to be finished completely so that our BREAK generation job can access > the index by key word search. >=20 > DB blocksize is 8k. Will use of larger tablespace or sections reduce > rebuild time? What about future guards against index loss? Any other > thoughts? > *************************************************************************= **=3D > ** >=20 > Any idea and suggestions will be greatly appreciated. Thanks a lot! >=20 > Regards, > Prem J > -- > //www.freelists.org/webpage/oracle-l >=20 --=20 Connor McDonald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D email: connor_mcdonald@xxxxxxxxx web: http://www.oracledba.co.uk "Semper in excremento, sole profundum qui variat" -- //www.freelists.org/webpage/oracle-l