FAQ
Oracle 10.1.0.4

HPUX 11.11

Backups with RMAN



We have two 250gb RAID 5 mount points that are made up of 5 disk drives each.
We have been discussing the pros and cons of the following:



Creating 1 large locally managed tablespace (uniform extent size of 4m) with
a datafile on each mount point for all of our data and indexes. Interesting.

Creating lots of locally managed tablespaces with different uniform extent
sizes (128k, 4m, 128m) with datafiles on each mount point.

Certainly option 2 is the more traditional approach but is there anything wrong
with option 1. Is it slower? Harder to maintain? Any type of file locking
problems?



Thanks,

Tom

Search Discussions

  • Jared Still at Nov 14, 2005 at 12:44 pm
    Hi Tom,

    The primary reason for multiple tablespaces is management, not performance.

    Case in point - a large table that grows extensively and has large amounts
    of data periodically removed. Managing space for this table and it's indexes
    is less work for the DBA if it is separated from more stable objects in the
    DB.

    Need to reclaim the space from removing half the data in the table?
    No problem - build it in a new tablespace and blow the old one away.
    This becomes a bit more work if there are other objects in the TBS.

    Partitioning is another example.

    HTH

    Jared
    On 11/14/05, Terrian, Tom (Contractor) (J6D) wrote:

    Oracle 10.1.0.4 <http://10.1.0.4>

    HPUX 11.11
    Backups with RMAN

    We have two 250gb RAID 5 mount points that are made up of 5 disk drives
    each. We have been discussing the pros and cons of the following:

    1. Creating 1 large locally managed tablespace (uniform extent size of
    4m) with a datafile on each mount point for all of our data and indexes.
    Interesting.

    2. Creating lots of locally managed tablespaces with different uniform
    extent sizes (128k, 4m, 128m) with datafiles on each mount point.

    Certainly option 2 is the more traditional approach but is there anything
    wrong with option 1. Is it slower? Harder to maintain? Any type of file
    locking problems?

    Thanks,

    Tom
    --
    Jared Still
    Certifiable Oracle DBA and Part Time Perl Evangelist

    --
    http://www.freelists.org/webpage/oracle-l
  • Bill thater at Nov 14, 2005 at 12:49 pm

    1. Creating 1 large locally managed tablespace (uniform extent size of 4m)
    with a datafile on each mount point for all of our data and indexes.
    Interesting.



    2. Creating lots of locally managed tablespaces with different uniform
    extent sizes (128k, 4m, 128m) with datafiles on each mount point.



    Certainly option 2 is the more traditional approach but is there anything
    wrong with option 1. Is it slower? Harder to maintain? Any type of file
    locking problems?
    you get the standard Oracle answer "it depends.";-)

    the problem i can see with option 1 is that there would be a lot of
    lost space if the data doesn't fint into the 4m size. my preference
    is for option 2 for the reason i can taylor the extent sizes to match
    the type of data i'm putting in them. however this is a moot point if
    the data you're dealing with fits the larger extent sizes well.

    --
    --
    Bill "Shrek" Thater ORACLE DBA
    shrekdba_at_gmail.com
    ------------------------------------------------------------------------
    "Zen is not easy.
    It takes effort to attain nothingness.
    And then what do you have?
    Bupkes." -- The Goddess
    --
    http://www.freelists.org/webpage/oracle-l
  • Powell, Mark D at Nov 14, 2005 at 1:18 pm
    If you just one large tablespace I vote for auto-allocate; otherwise I
    might go with one large object and one small to medium object tablespace
    using uniform extents. For the large object I would use an extent size
    somewhere between 5M and 20M depending on the object sizes. For the
    small object tablespace I would use something between 64K and 512K again
    depending on the sizes of the objects to be stored.

    Probably 64K and 5M based on the initial 4M estimate.

    HTH -- Mark D Powell --

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of bill thater
    Sent: Monday, November 14, 2005 1:47 PM
    To: Tom.Terrian_at_dla.mil
    Cc: oracle-l_at_freelists.org
    Subject: Re: One large tablespace.
    1. Creating 1 large locally managed tablespace (uniform extent size
    of 4m) with a datafile on each mount point for all of our data and indexes.
    Interesting.

    2. Creating lots of locally managed tablespaces with different
    uniform extent sizes (128k, 4m, 128m) with datafiles on each mount point.
    Certainly option 2 is the more traditional approach but is there
    anything wrong with option 1. Is it slower? Harder to maintain? Any
    type of file locking problems?
    you get the standard Oracle answer "it depends.";-)

    the problem i can see with option 1 is that there would be a lot of lost
    space if the data doesn't fint into the 4m size. my preference is for
    option 2 for the reason i can taylor the extent sizes to match the type
    of data i'm putting in them. however this is a moot point if the data
    you're dealing with fits the larger extent sizes well.

    --
    --
    Bill "Shrek" Thater ORACLE DBA
    shrekdba_at_gmail.com
    ------------------------------------------------------------------------
    "Zen is not easy.
    It takes effort to attain nothingness.
    And then what do you have?
    Bupkes." -- The Goddess
    --

    --
    http://www.freelists.org/webpage/oracle-l

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedNov 14, '05 at 12:37p
activeNov 14, '05 at 1:18p
posts4
users4
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase