| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> LMT and DMT
Morning Tingl,
comments inline as ever !
Cheers,
Norm.
Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com -------------------------------------
-----Original Message-----
From: tingl [mailto:one4all_at_all4one.not]
Posted At: Thursday, February 06, 2003 3:45 AM
Posted To: server
Conversation: LMT and DMT
Subject: Re: LMT and DMT
>> First I have to clarify. Although DMT allows you to create random
size
>> extents, it does not prevent you from sizing extents appropriately.
Fragmentation
>> only becomes a real problem when the extents are unreasonably sized
and segments
>> are being dropped or truncated frequently. This problem is further
minimized
>> by merging smaller extents into larger ones.
Well, as long as you, the dba, prevent people from creating extents in a tablespace, you might just get away with it. If people are allowed to create tables/indexes then you no longer have any control - I know, I've been there. I've lost coun't of the times I've set up a DMT with nicely sized objects only to have some numptie come along and create a table with a wierd set of extent sizes - instantly screwing up all my work. With DMTs you cannot prevent it I'm afraid.
Also, see my previous comments on importing a dump where the export defaulted, or explicitly set the COMPRESS parameter to yes - that really annoys me !
>> Again, how much better LMT is depends on how well or poorly DMT is
sized.
Initially, true, but as I said above, as long as you have users able to create stuff, you are bolloxed :o(
>>I have used DMT for many years and worked just great.
So have I because I had no choice, now I control the sizes of every extent in my tablespaces. No-one can create extents that do not confirm exactly to how I create the tablespace. In otherwords, I'm doing with my LMTs exactly what you are trying to do with your DMTs but I don't have to worry about imports or people creating things !
>> I have heard of that approach before. It will probably result in more
>> tablespaces. Let's say if I have 10 tablespaces for tables and 10 for
indexes. If I
>> divide each one into 3, now I have 30 for tables and 30 for indexes.
To enforce this
>> approach, I have to move objects back and forth between tablespaces
as their sizes
>> change. It just gets worse if I further divide the tablespaces.
You need a maximum (?) of 4 tablespaces. (or 8 if you want to separate out your indexes as well for maintenace purposes, not performance !) See the document on 'how to stop defragmenting and start living' which explains it much better than I can. It's on Metalink at http://support.oracle.co.uk/cgi-bin/cr/getfile_cr.cgi?239049 - reading and understanding this can seriously relieve your workload. And it was written for DMTs !
Regards,
Norm.
Received on Thu Feb 06 2003 - 03:58:21 CST
 |
 |