DBAsupport.com Forums - Powered by vBulletin
Results 1 to 6 of 6
  1. #1
    Join Date
    Nov 2000

    I have build a partitioned table with 193 milion rows and each partition has around 20million rows. If i analyze the table partition by partition and compute statistics, it gives ora-600 : [1113]
    unable to exten temp segment in TS temp.
    My temp ts is now 4 gig, i started it with 1G.

    When increasing the temp TS didn't solve the problem then i did analyze with estimate statistics.

    Is it Okey to work with estimate statistics instead of compute statistics.

    Is compute statistics give more performance than estimate statitics ?.

    What kind of index would give best performance on zip code (varchar2(5)) column in the above table ?.

    Thanks in advance for help.


  2. #2
    Join Date
    Feb 2001
    For Ora600 , you should contact Oracle.
    Estimate staistics with 50% works fine usually.
    The type of index depends upon the type of transactions on table and selectivity of column.

  3. #3
    Join Date
    Mar 2001
    To quote Oracle from their Metalinks site:

    Yes, this is bug 1307247 which will be fixed in Oracle9i and Oracle These versions/patchsets are not yet available.
    The ETA for is the end of February 2001. You would of course, have to upgrade to 8.1.7 before applying this patchset.

    ...and an additional quote:

    This bug can cause a system hang. It did on one of ours instances twice. Oracle has a patch for this bug for

    I had to use the patch to fix a totally different ORA-600 bug myself. I think ORA-600 is Oracle speak for "We'll fix it later."

  4. #4
    Join Date
    Nov 2000
    Thanks all of you for a prompt help.

    My oracle veriosn is

    Should i wait for the upgrade/patch or should i open a TAR ?

    I tried both indexes, normal and bitmap on zip code, and bitmap is much faster.

    Thanks and Regards,


  5. #5
    Join Date
    Jul 2000
    Oxford, OH
    Just a quick observation...

    It sounds like you are running a DSS application from the size... I doubt 4GB for TEMP is going to be anywhere near enough space...I've got about 40GB allocated to mine so far. It does depend on the application and what you are doing but 4GB seems like a small amount if you are running really large queries. Have you tuned your sort_area_size and TEMP tablespace? Also make sure that you create the temporary tablespace as type TEMP so Oracle will dynamically allocate and deallocate the space. Finally there is an issue with PMON not keeping up with cleanup. There is a way to force PMON to work a little harder to clean the space up - it is described on Steve Adams (author of OReilly's "Oracle 8i Internal Services for Waits, Locks, and Memory) Oracle internals site and a script is provided.

    Finally ESTIMATE STATISTICS at 50% will actually do a compute statistics because the overhead isn't much different. I believe this happens at anything over 30% (it might be 40%, I can't remember, I'll go back and look it up later) but I know positively that 50% will just give you the same issue.

    Joe Ramsey
    Senior Database Administrator
    dbaDirect, Inc.

  6. #6
    Join Date
    Nov 2000
    Thanks Joe, for your input. My system is a DSS database and now the size of the biggest table is 150G. The sort_area_size is 20M at present according to some of the queries.

    Can you suggest some of the common things to be taken care of for a table of this size, to acheive the best performance for queries.

    It would be great if you could write the site of Steve Adams.

    Thanks and Regards


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Click Here to Expand Forum to Full Width

We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.