RE: clustered tables question 10g
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <greg@xxxxxxxxxxxxxxxxxx>, <ganstadba@xxxxxxxxxxx>
- Date: Thu, 26 Nov 2009 09:02:05 -0500
Excellent advice.
As an add-on, remember to do the information life cycle planning bit.
Purging gobs of data from clusters is something to consider. Depending on
the size of the cluster compared to your resources, copying what you want to
keep may not be practical for a given archive and purge cycle, and you have
to consider whether to license partitioning, because deletes from a cluster
are no picnic for what the database engine has to do.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Greg Rahn
Sent: Wednesday, November 25, 2009 4:28 PM
To: ganstadba@xxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: clustered tables question 10g
My advice would be this: get in the lab, make two versions of your
tables (clustered and not) and compare them to each other in a
workload simulation test. In almost all cases there are pros and cons
to design decisions but I find it extremely difficult to think of
everything even when I think know it inside and out. I refer to this
as evidence-based design; where you let the performance data decide
what design is best, not something else.
On Wed, Nov 25, 2009 at 11:28 AM, Michael McMullen
<ganstadba@xxxxxxxxxxx> wrote:
> I'm investigating whether it is appropriate to organize some of the tables
into clusters,
--
Regards,
Greg Rahn
http://structureddata.org
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
