In article <87imgm$usi$1_at_nnrp1.deja.com>,
muppetsrule_at_my-deja.com wrote:
> I have a very large table (100+ million rows 700+ columns) that I need
> to access as quickly as I can. I have read in several spots that
stored
> procedures can improve performance, but I have not seen that. I only
> need to do selects from the table, but I need to do them as quickly
as I
> can. The box that I am running on will have 16Gb of RAM, and four
> processors, and I can use as much as the box as I can. I am not the
> DBA, so DB tuning is out of my control, but I have done some testing
> with different ways to retrieval to the database. I tried straight
> PRO*C first, and it was the slowest by far (~800 transactions / sec)
> PRO*C + stored procedure was not much faster (~825), but PL/SQL was
> fastest (~3700), PL/SQL + stored procedure was a little slower
(~3200),
> but these tests were done on a one row, one column table so that I
could
> test the interface. When I begin accessing the real tables, will I
see
> the difference that a stored procedure will make that might not be
> reflected in such a small table? Also, one method that I have not
> looked into is Native Dynamic SQL....is this worth taking them time to
> benchmark? Thanks for any suggestions!
>
> Sincerely,
> Andy Schaefer
>
Is this table a good canidate for partitioning? If the majority of
your queries will go after multiple rows of data that exist in one
partition performance gains are possible. But queries that cross
partions will probably run slower than the same query against an un-
partitioned table. Actual performance depends on how the table is
accessed and on if you used parallel query etc....
--
Mark D. Powell -- The only advice that counts is the advice that
you follow so follow your own advice --
Sent via Deja.com http://www.deja.com/
Before you buy.
Received on Sun Feb 06 2000 - 13:13:52 CST
