Re: Quick question about table partitioning?

Don't know. But have you considered a used Sun-Solaris box? They are available from dealers and from places like eBay.

Daniel A. Morgan

"Kev.-" wrote:

> I agree about the windows thing but I dont have the money at this time
> to buy a solaris box. Now I could move it over to Solaris on Intel.
> Would that be any good?
>
> Thanks,
>
> Kev.-
>
> On Tue, 17 Apr 2001 22:18:33 -0700, "Daniel A. Morgan"
> <dmorgan_at_exesolutions.com> wrote:
>
> >Personally I don't think partitioning is going to give you much bang for the
> >buck though others that have worked with something similar to what you have
> >may disagree ... and if they have an environment more like yours listen to
> >them ... not me.
> >
> >In your situation I would absolutely get the thing off of anything named
> >Windows. Solaris is a good choice. I would go for a minimum Enterprise 450
> >with 4 CPUs and at least 2 GB RAM. By logically mapping your disk array of 9
> >GB or 18 GB drives to u03, u04, etc. you will effectively partition your
> >table across multiple physical drives without having to do any real mapping.
> >
> >With respect to your bitmapped index the two criteria are volatility (how
> >often is the index modified) and cardinality. If you have high cardinality,
> >lots of different values, a bitmap index is a bad idea. If this is the case
> >go to BTree indexes.
> >
> >I will be watching to see what others suggest.
> >
> >Daniel A. Morgan
> >
> >
> >
> >
> >"Kev.-" wrote:
> >
> >> Hello Daniel,
> >>
> >> Right now the database is about 1 million rows about 2 gigs in size.
> >> It is an NT server for now but will be changing to Solaris in the
> >> furture. The system has almost a gig a ram. The database is pretty
> >> much reads. Very few writes.
> >>
> >> The user base at this time is unknown but say for starters about
> >> 25-50.
> >>
> >> The table is structure is 4 numeric fields for lookups, one date
> >> field, a varchar2 500, 250, 250 and one CLOB to hold the articles.
> >>
> >> The search can be either on the articles or on the varchar2 500 field
> >> with a numeric field id to help filter the selection.
> >>
> >> I had the CLOB in a seperate table but the perfrmance when I joined to
> >> it was horrible so I brought it over a one table design hopeing it
> >> would help increase performance. It is a little better but still
> >> slow. I also tried a bitmap index on the filter field but not much
> >> improvement. I am using intermedia to search the CLOB and the numeric
> >> field at the same time for narrowing down the results.
> >>
> >> Thanks,
> >>
> >> Kev.-
> >>
> >> On Mon, 16 Apr 2001 20:35:31 -0700, "Daniel A. Morgan"
> >> <dmorgan_at_exesolutions.com> wrote:
> >>
> >> >The answer is far more complex than the question. What operating system
> >> >on what platform with how much RAM? How many users are simultaneously
> >> >accessing the table, what SQL is being run against it? What indexes are
> >> >on it? And other than the CLOB field, how big is the row?
> >> >
> >> >Daniel A. Morgan
> >> >
> >> >
> >> >
> >> >"Kev.-" wrote:
> >> >
> >> >> Hello,
> >> >>
> >> >> The table I have will become very large over time 50+ million rows.
> >> >> Would I be better off partitioning the table to get better
> >> >> performance? If I do this how much speed can I gain from it?
> >> >>
> >> >> Also I know I have to re-create the table but can I do an insert into
> >> >> select * from x even though there is a CLOB column invloved?
> >> >>
> >> >> I figure if I have the partitions on the category ids this would help
> >> >> the query as it would only have to search on that category within the
> >> >> partition. but how would it work if I wanted to search across
> >> >> multiple categories at one time?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Kev.-
> >> >
> >
  Received on Thu Apr 19 2001 - 00:25:38 CDT