Results 1 to 8 of 8
  1. #1
    Join Date
    Oct 2002
    Location
    SPAIN
    Posts
    4

    Angry Unanswered: Table growing extremely

    Hello,

    We have a very big DB (since my experience :-)) with SIEBEL (CRM... 1 TeraByte data, 2000 users, more than 20 Gb. tables...) and we have a question than nobody can explain...

    For de first installation, we'd configured our DB whith DB_BLOCK_SIZE of 16Kb and try that one tablesize was 16 Gb (pctfree 40). Due to political instructions, we are trying to traspass this DB to DB_BLOCK_SIZE of 8Kb and the same table acquire the monstruous size of 26 Gb.!!! You can imagine that suppose a query in it!!! (the indexes for this table have 2 Gb. size!!!). This table has the same pctfree (40) and there is not chained rows in it ? (our first theory).

    Have you casually any theory or idea that what can occur with it???

    Thank's in advance for your patience!...

  2. #2
    Join Date
    Oct 2002
    Location
    Malaysia
    Posts
    2

    Post Re: Table growing extremely

    Try to disable the autoextend.
    And resize the table.

  3. #3
    Join Date
    Oct 2002
    Location
    SPAIN
    Posts
    4

    Unhappy Re: Table growing extremely

    Originally posted by cyliew
    Try to disable the autoextend.
    And resize the table.
    Hi!,

    Thank's for your answer...

    When we create it we put this parameter to OFF for the tablespaces/datafiles...
    In the attach file, you can see this table script creation (columns, indexes,etc.). This table have more than 10 millions rows!!!... and this actual size is 26Gb (old size, with the same configuration, except DB_BLOCK_SIZE = 16 Gb).
    Tell me if you need more information or more "clues" for it and I try to send to you.

    Thank's in advance,

    Falkian.
    Attached Files Attached Files

  4. #4
    Join Date
    Oct 2002
    Location
    Malaysia
    Posts
    2

    Post Re: Table growing extremely

    Hi Falkian,

    May I know what exactly the issue that u are facing besides from what I can deduct about the latency of performance?
    There can be lots of ways to troubleshoot the problem. if it's OS level, probably u can migrate the whole database to raid 0+1 from the normal disk configuration..
    Do let me know the further clue and expectations.

    regards
    cyliew

  5. #5
    Join Date
    Apr 2002
    Location
    California, USA
    Posts
    482

    Cool

    You got to start thinking of partitioning these huge tables, or users will keep calling you all the time when you are on your desk.

    With such many records, you will have fragmentation soon or later too. So migrating the tablespaces to LMT would be another task you have to do.

    Also from your posts is not so clear what you are trying to do exactly. Can you make it more clear, so we can post specific recommendations?

    Hope that helps,

    clio_usa
    OCP - DBA

    .

  6. #6
    Join Date
    Oct 2002
    Location
    SPAIN
    Posts
    4
    Thank's a lot Cyliew and Clio,

    I'll try to explain the scenary:

    Our DB Oracle 8.1.7.4 is over Symmetrix raid 0+1.
    The application is Siebel version 7.0.4 (that no accept partitioned tables due to internal configuration).
    All the application tablespaces are configured whith Locally Managed Tablespaces, Autoallocate at first, converted to Dictionary Managed and later to Locally Managed, because at this time, we can modify the next extent for TABLES/INDEXES that we decides.
    Our Siebel application has a lot of objects (tables/indexes) with more than 1Gb in size!!!... but only one (the biggest!)... has this monstruous size (26 Gb). This table has 2Gb extent size!!!.

    Thank's in advance,

    Falkian

  7. #7
    Join Date
    Mar 2002
    Location
    Reading, UK
    Posts
    1,137
    Are you sure it wont like partitioned tables (does it do DDL itself to look after tables & indexes). Most apps work transparently with partitioning without too many problems. You will also find that if you can use locally partioned indexes you can make things a lot more managable aswell as improving performance.

    One other thing is you might be able to do is to reduce the index size by using compression on large indexes.

    Alan

  8. #8
    Join Date
    Oct 2002
    Location
    SPAIN
    Posts
    4

    Smile

    Hi Alan,

    Yes, partitioned tables is transparent to the application, but our problem is that to migrate (across SIEBEL) the project between platforms dev-int-prod... then, SIEBEL only recognize traditional tables (not partitioned) and it's the reason that we can't use partitioned tables.

    Thank's!,

    Falkian.

Posting Permissions

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