Home » RDBMS Server » Performance Tuning » performance tunning
performance tunning [message #65938] Wed, 02 February 2005 20:36 Go to next message
santosh
Messages: 85
Registered: October 2000
Member
How to speed up the process of fetching all the records from a table. e.g if a table has 10,000 total number of records, then how can u speed up the fetching
Re: performance tunning [message #65939 is a reply to message #65938] Thu, 03 February 2005 04:13 Go to previous messageGo to next message
Mahesh Rajendran
Messages: 10707
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
if you need all the 10,000 records there is no need for an index.
If you need a few of 10,000 records then
create apropriate indexes
write the proper sql
analyze the table and indexes.
run your query.
if you are not happy
Look into the execution plan for the sql or look into statspack / trace files.
do what you can do / need to do to find and fix the bottleneck.
Re: performance tunning [message #65942 is a reply to message #65939] Thu, 03 February 2005 22:29 Go to previous messageGo to next message
santosh
Messages: 85
Registered: October 2000
Member
I want all the records. so obviously I wont be using indexes. Still I want to speed up the process and would like to know what can be done to achieve this.

Thanks
Re: performance tunning [message #65943 is a reply to message #65942] Fri, 04 February 2005 01:48 Go to previous message
Mahesh Rajendran
Messages: 10707
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
1. you can use a parallel query.
2. You can cache the whole table in memory ( but query will the serial )
< quoting docs >
The LRU Algorithm and Full Table Scans

When the user process is performing a full table scan, it reads the blocks of the table into buffers and puts them on the LRU end (instead of the MRU end) of the LRU list. This is because a fully scanned table usually is needed only briefly, so the blocks should be moved out quickly to leave more frequently used blocks in the cache.

You can control this default behavior of blocks involved in table scans on a table-by-table basis. To specify that blocks of the table are to be placed at the MRU end of the list during a full table scan, use the CACHE clause when creating or altering a table or cluster. You can specify this behavior for small lookup tables or large static historical tables to avoid I/O on subsequent accesses of the table.
< /end quoting docs >
Previous Topic: Joining tables - Compare multiple columns of a table with a Single column of oth
Next Topic: COMPUTE and ESTIMATE
Goto Forum:
  


Current Time: Thu Mar 28 16:57:33 CDT 2024