From: Connor McDonald Newsgroups: comp.databases.oracle.server Subject: Re: Locally vs dictionary managed tablespaces Date: Wed, 08 Aug 2001 18:51:54 +0100 Organization: OWDS Inc. Lines: 43 Message-ID: <3B717C3A.4E86@yahoo.com> References: Reply-To: connor_mcdonald@yahoo.com NNTP-Posting-Host: 62.172.35.218 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.chatlink.com 997293136 2979 62.172.35.218 (8 Aug 2001 17:52:16 GMT) X-Complaints-To: abuse@chatlink.com NNTP-Posting-Date: Wed, 8 Aug 2001 17:52:16 +0000 (UTC) X-Mailer: Mozilla 3.01 (WinNT; I) Rene Nyffenegger wrote: > > Hi > > Because of another thread in this NG, I wanted to find out > about locally managed tablespaces. The key phrase I found is: > > Locally managed tablespaces track all extent information in the tablespace > itself, using bitmaps, resulting in the following benefits: > > > What does it mean, the extent information is in the tablespace itself. > Where is it stored in dictionary managed tablespaces? What is the > extent information anyway? > > Tnx > > Rene > > -- > Recherchen im Schweizerischen Handelsamtsblatt: > http://www.adp-gmbh.ch/SwissCompanies/Search.php3 By default two tables hold all the bits and pieces (UET$, FET$) being a list of used and free extents respectively. Obviously as you add/remove extents, these tables have to be updated. Similarly if you coalesce then these tables could be updated. What you quickly end up with if you're going hard on the extent (de)allocation, is a bottleneck. A locally managed tablespace plonks this information in a bitmap in each file, thus removing the contention point. I consider dictionary managed tablespace to be virtually obsolete.. hth connor -- ============================== Connor McDonald http://www.oracledba.co.uk "Some days you're the pigeon, some days you're the statue..."