Re: storage parameters

2002-05-29 Thread Tim Gorman
If the uniform-sized extents are sized so that the initial load will have to allocate 50 or 100 or 400 extents, how much processing overhead do you think that dictionary-managed extent allocation operation will really consume, especially if the search of FET$ within those operations is made

Re: storage parameters

2002-05-29 Thread Tim Gorman
We're one game away from beating the Red Wings; how are the Maple Leafs doing? I haven't been paying attention... ...the Red Wings are the better coached and are just the better team, but the Avs are showing enough grit to take the lead in the series. Gotta love it... - Original Message

RE: storage parameters

2002-05-28 Thread DENNIS WILLIAMS
Fawzia - If you're going to this much effort, consider looking into locally managed tablespaces (LMT) with uniform extents. Then you won't have to tidy up again. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Tuesday, May 28, 2002 11:19 AM To: Multiple

Re: storage parameters

2002-05-28 Thread basher 59
No. I can think of several reason when you would not wan them the save. An example: Think of load a lot of data into a table, and then load on a very limited basis. This tells me to create a large first extent that everything can fit into. Example: Say 100M and then you may want to

Re: storage parameters

2002-05-28 Thread Rachel Carmichael
An example: Think of load a lot of data into a table, and then load on a very limited basis. This tells me to create a large first extent that everything can fit into. why? there is no benefit to that --- basher 59 [EMAIL PROTECTED] wrote: No. I can think of several reason when you

RE: storage parameters

2002-05-28 Thread Jay Earle (DBA)
Hi Fazia, I would recommend the following white paper, it advocates using the SAFE methodology. HOW TO STOP DEFRAGMENTIING AND START LIVING Bhaskar Himatsingka, Oracle Corporation Juan Loaiza, Oracle Corporation You can find the paper on Cary Millsap's site. www.hotsos.com Sincerely,

Re: storage parameters

2002-05-28 Thread Igor Neyman
, 2002 2:30 PM To: Multiple recipients of list ORACLE-L Subject: Re: storage parameters An example: Think of load a lot of data into a table, and then load on a very limited basis. This tells me to create a large first extent that everything can fit into. why

RE: storage parameters

2002-05-28 Thread Rachel Carmichael
28, 2002 2:30 PM To: Multiple recipients of list ORACLE-L Subject: Re: storage parameters An example: Think of load a lot of data into a table, and then load on a very limited basis. This tells me to create a large first extent that everything can fit into. why

Re: storage parameters

2002-05-28 Thread Stephane Faroult
Rachel Carmichael wrote: An example: Think of load a lot of data into a table, and then load on a very limited basis. This tells me to create a large first extent that everything can fit into. why? there is no benefit to that Rachel, No benefit when the data is loaded, but

Re: storage parameters

2002-05-28 Thread Rachel Carmichael
but if the load is a one time thing (as he described) then the allocation hit happens only once and I still don't see a benefit and in fact can see how it might hurt -- tablespace fragmentation etc I'd rather see large extents but more of them --- Stephane Faroult [EMAIL PROTECTED] wrote: