Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle 7.3 Very Large Tables

Re: Oracle 7.3 Very Large Tables

From: BobH <b-horton_at_worldnet.att.net>
Date: Mon, 04 May 1998 22:37:12 -0400
Message-ID: <6ilu2b$lgi@bgtnsc03.worldnet.att.net>


Keith Fulton wrote:
>
> I am currently working on an Oracle 7.3.4 application on a Sequent NUMA-Q with
> heavy batch TP requirements at night, and heavy reporting and inquiry during
> the day. Our most detailed tables are projected to grow approximately 9
> million rows / month, and we need to keep 12-18 months of history online for
> inquiry purposes.
>
> We have several DBAs who are saying that Oracle cannot support this
> requirement, and that Oracle really can't handle more than about 25 million
> rows in a table, but this seems much smaller than a lot of data warehouses and
> other big installations. So first I would like to know if anyone out there
> has guidelines on just how big tables can get before Oracle will "break" or
> non-linearly degrade performance.
>
> Those same DBAs recommended that we use O7.3 table partitioning with views to
> accomplish the scalability we need, and (not to my surprise) that was a factor
> of 10 slower than just the big table. Now they are saying the only solution
> is to go to Oracle8, which handles partitioning much better (but which I
> think is still not mature enough).
>
> Another idea we had to accomplish our scability and history needs are to split
> up these tables into 2 parts--a) the 'current' data for say the last 60 days,
> and b) historical data only there for inquiry purposes. This solution, in
> effect, splits the table into the TP and data warehouse pieces, and seems
> better, but leaves the data warehouse piece at 100+ million rows.
>
> Any feedback on this sort of problem would be greatly appreciated.
>
> KWF
  Do you have/use the Parallel Server option?

 One thing where I would agree with your DBAs is to separate your OLTP processing from your OLAP. The history should be relativly 'static'. Optimize the OLAP for your history querys, OLTP part for the TP processing.
  The partitioning of tables and indexes in ORACLE8 would be great if you have it. But if you are like me you have to work woth what you have at the time.
luck! Received on Mon May 04 1998 - 21:37:12 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US