Re: [GUSDEV] GUS 3.5 installation success

[Ed R. <ero...@ug...>]

Yes, but explicitly separating your tables spaces gives you
much more flexibility in your management options.  Everyone
who is using GUS has a different server set-up, so you want to
give their DBAs options.  Separating your tablespaces is
simple standard practice that should be maintained in the
architecture.

-ed


---- Original message ----
>Date: Tue, 28 Jun 2005 09:52:15 -0400
>From: Michael Saffitz <msa...@pc...>  
>Subject: Re: [GUSDEV] GUS 3.5 installation success  
>To: Haiming Wang <hw...@ug...>
>Cc: Jian Lu <jl...@vb...>, Steve Fischer
<sfi...@pc...>, Gusdev gusdev-gusdev
<gus...@li...>
>
>
>
>
>On 6/28/05 9:27 AM, "Haiming Wang" <hw...@ug...> wrote:
>
>> According to the Optimal Flexible Architecture (OFA)
standard for Oracle
>> , it would be a best practice for having separate indexes
from the data.
>> Create your primary key and all other indexes in a separate
tablespace
>> and put that on a separate disk and controller.
>
>A single tablespace can span multiple disks.  I think the
only advantages to
>multiple tablespaces for GUS are:
>
>1) When dictated by varying storage demands, such as the
example below
>
>2) Administrative ease.  For example, we regularly migrate
our data from
>build to production.  On production, we simply drop the
"gusver" tablespace,
>containing the version tables that we don't need available
publicly.  I
>think there's a trade-off here, however.  I'd much prefer to
manage 1
>tablespace than the 10~12 tablespaces (as the default in 3.0).
>
>--Mike
>
>> 
>> Thanks for adding this support in the next GUS release.
>> 
>> -Haiming
>> 
>> On Tue, 2005-06-28 at 09:09, Michael Saffitz wrote:
>> 
>>>> 1) 3.0 has separate tablespaces for each name space and
its index. Do
>>>> you want to keep those tablespaces or merge them into one?
>>> 
>>> We anticipate that most installations of GUS really only
need one
>>> tablespace, since data storage parameters are likely to be
the same for all
>>> GUS tables.  This being said, I could foresee someone
wanting to run
>>> standard tables in archivelog mode, and version tables in
noarchivelog mode.
>>> One of my to do items for the next release is to better
support the multiple
>>> tablespaces.
>> 
>> 
>> 
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward
articles,
>> informative Webcasts and more! Get everything you need to
get up to
>> speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
>from IBM. Find simple to follow Roadmaps, straightforward
articles,
>informative Webcasts and more! Get everything you need to get
up to
>speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Gusdev-gusdev mailing list
>Gus...@li...
>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
-----------------
Ed Robinson
Center for Tropical and Emerging Global Diseases
University of Georgia, Athens, GA 30602
ero...@ug.../(706)542.1447/254.8883