Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Locally managed tablespaces
Hi I have recently done this for a client and found it to take quite a period of time 3 days actually in this case to do the analysis of the tables to determine to most likely best fit for tables to extent sizes and which extent size to use. We also did use the below mentioned PDF as a guide as to the approach to take for sizing.
You may find that your database grows but this will really depend on the size of tables relative to the extent size of the tablespace you put it in.
Best of luck. I would have been trying this in a development environment before doing it to a live database as you may need to re-run some loads due to insufficient tablespace area. Timing could be an issue for a live system
Cheers
Peter McLarty E-mail: Peter.Mclarty_at_Mincom.com Technical Consultant WWW: http://www.Mincom.com APAC Technical Services Phone: +61 (0)7 3303 3461 Brisbane, Australia Mobile: +61 (0)402 094 238
---------------------- Facsimile: +61 (0)7 3303 3048
"Karniotis, Stephen" <Stephen_Karniotis_at_compuware.com>
Sent by: root_at_fatcity.com
15/12/2001 07:05 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> cc: Fax to: Subject: RE: Locally managed tablespaces
Heather:
Another thing to consider. If the vendor of your student application system has not worked with LMTs, you may encounter support issues should you have problems with database accessibility. I would verify that LMTs are supported before converting.
In terms of usage, LMTs are great as they remove all of the ridiculous I/O encountered by the SYSTEM tablespace for monitoring extent performance, allocation, and deallocation. Denise is correct that uniform extents significantly improve the performance of LMTs, however, multiple uniform extent types can be used. However, if your extent sizes are all over the map, you should create some uniform size and then move to LMT.
Thank You
Stephen P. Karniotis
Technical Alliance Manager
Compuware Corporation
Direct: (248) 865-4350
Mobile: (248) 408-2918
Email: Stephen.Karniotis_at_Compuware.com
Web: www.compuware.com
-----Original Message-----
Sent: Friday, December 14, 2001 3:26 PM
To: Multiple recipients of list ORACLE-L
Heather - Is there a particular reason the consultant is doing this other
than maybe this is the first opportunity to learn this? Just my cynical
side. Mentioning cynical, I was leery of the procedure to convert an
existing dictionary-managed tablespace to a locally-managed one, but we
production DBAs tend to be a conservative lot. If you go that route, be sure
that you end up with uniform extents which I consider the best part of LMT.
Be sure to study the paper "How to Stop Defragmenting and Start
Living: The Definitive Word on Fragmentation" by Himatsingka and Loaiza.
before your consultant comes so that both of you agree on the approach to
take. This is available on Oracle's Web site. The worst circumstance (see
cynical above) would be for one person to create them and the other person
to maintain them, but each with a different philosophy.
I think LMT and uniform extents and extensible tablespaces are the
greatest features Oracle has added recently.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
Sent: Friday, December 14, 2001 8:55 AM
To: Multiple recipients of list ORACLE-L
I have just heard today that an external consultant, who is coming to upgrade software for our Student Records system next week, wants to unload the live, test and training databases, and recreate them using locally managed tablespaces.
I've been reading all the incredibly positive things oracle have to say about this, but has anybody any real experience of using locally managed tablespaces, and if so, are there any major disadvantages or knock-on effects that I should be aware of? Apart from trying to find disk space to unload each database to do this, would it have any additional space implications?
Basically, I need to decide if I should let this go ahead.
Heather
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Docherty, Heather
INET: H.Docherty_at_napier.ac.uk
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists --------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists --------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists --------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
--
This transmission is for the intended addressee only and is confidential information. If you have received this transmission in error, please delete it and notify the sender. The contents of this e-mail are the opinion of the writer only and are not endorsed by the Mincom Group of companies unless expressly stated otherwise.
Received on Sun Dec 16 2001 - 19:38:00 CST
![]() |
![]() |