Locally Managed Tablespaces
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 6 of 6

Thread: Locally Managed Tablespaces

  1. #1
    Join Date
    Dec 1999
    Posts
    217
    Has anybody been using the locally managed tablespaces feature of 8i? I am trying to gather some information on this feature but I have only been able to find the advantages of this feature. Can any of you guys tell me what might be the downside to this feature? I want to know if this feature is worth trying in a production environment. Yes, I will try it in a pre-production environment before I put it in the production environment.

    Thanks,
    Chintz

  2. #2
    Join Date
    Feb 2000
    Location
    Washington DC
    Posts
    1,843
    Personaly I don't see anything downside. If not for data, best bet for ROLLBACK and TEMP tablespaces. I will be implementing the same accross enterprise soon.
    Reddy,Sam

  3. #3
    Join Date
    Aug 2000
    Posts
    194
    just a note,
    I read somewhere there are some bugs having the locally managed tablespaces for RBS (in 8.1.5).


    I used it for TEMPorary tablespace and haven't found any downsides yet.

  4. #4
    Join Date
    Jun 2000
    Location
    Madrid, Spain
    Posts
    7,447
    I have used it for temporary tablespace only since I dont have experience yet to deal with recoveries if a data tablespace crashes and it is locally managed I would guess it's same but just in case :D

  5. #5
    Join Date
    Nov 2000
    Posts
    212
    I found it beeing nice: fast and defragmented.
    And no problems with exporting/importing test(development) schemas to production database and vice versa: storage parameters like initial extents are ignored.



  6. #6
    Join Date
    Oct 2000
    Location
    Saskatoon, SK, Canada
    Posts
    3,925
    I hope by now most of us know what is the difference between the Locally managed table space and the data dictionary.

    In case here is the differences:

    Dictionary-Managed: when ever a tablespace is set to dictionary managed, it ends up using the data dictionary to manage its extents and forces the oracle server to update the appropriate tables in the data dictionary when ever an extent is allocated or deallocated.

    Locally Managed: These tablespaces manages their own extents by maintaining a bitmap in each datafile to keep track of the free or used status of blocks in that datafile. As a result it sets each bit in the bitmap to block or group of blocks and as a result it just modifies the bits when ever an extent is allocated or freed.

    Now Considering the advantages of Locally managed tablespaces:

    It avoids recursive space management operations.

    Since they do not record the free space in the data dictionary, it avoids/reduces the contentions on these tables.

    Since they keep track of their ajacent free space, they avoid coalece of free extents

    All extents can have the same extent size

    Finally the changes to the extent bitmap do not generate rollback information, since they do not update tables in the data dictionary.

    As a result of the above said advantages they promiss a better performance. One thing it is worth the notice is that
    "Locally managed tablespace cannot be used for the system" and for every thing else it can be used to reap the performance.

    So far, as every one had pointed out we haven't seen any down side of using this, unless and other wise oracle introduces some kind of bug in the future relseases

    Sam
    Thanx
    Sam



    Life is a journey, not a destination!


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