CODEWITHSUNDEEP
performanceoracle-databaseselect
ajay
ajay

Reputation: 11

Oracle select query performance

I am working on a application. It is in its initial stage so the number of records in table is not large, but later on it will have around 1 million records in the same table.

I want to know what points I should consider while writing select query which will fetch a huge amount of data from table so it does not slow down performance.

Upvotes: 1

Views: 6985

Answers (3)

Jason
Jason

Reputation: 3040

A few points to remember:

  • Fetch only the columns you need to use on the client side.
  • Ensure you set up the correct indexes that are going to help you find records. These can be done later, but it is better to plan for them if you can.
  • Ensure you have properly accounted for column widths and data sizes. Don't use an INT when a TINYINT will hold all possible values. A row with 100 TINYINT fields will fetch faster than a row with 100 INT fields, and you'll also be able to fetch more rows per read.
  • Depending on how clean you need the data to be, it may be permissable to do a "dirty read", where the database fetches data while an update is in progress. This can speed things up significantly in some cases, though it means the data you get might not be the absolute latest.
  • Give your DBA beer. And hugs.

Jason

Upvotes: 1

user373455
user373455

Reputation: 13271

To get good performance with a database there is a lot of things you need to have in mind. At first, it is the design, and here you should primary think about normalization and denormalization (split up tables but still not as much as performance heavy joins are required).

There are often a big bunch of tuning when it comes to performance. However, 80% of the performance is determined from the SQL-code. Below are some links that might help you.

http://www.smart-soft.co.uk/Oracle/oracle-performance-tuning-part7.htm
http://www.orafaq.com/wiki/Oracle_database_Performance_Tuning_FAQ

Upvotes: 1

Jonathan Leffler
Jonathan Leffler

Reputation: 754820

First rule:

  • Don't fetch huge amounts of data back to the application.

Unless you are going to display every single one of the items in the huge amount of data, do not fetch it. Communication between the DBMS and the application is (relatively) slow, so avoid it when possible. It isn't so slow that you shouldn't use the DBMS or anything like that, but if you can reduce the amount of data flowing between DBMS and application, the overall performance will usually improve.

Often, one easy way to do this is to list only those columns you actually need in the application, rather than using 'SELECT *' to retrieve all columns when you'll only use 4 of the 24 that exist.

Second rule:

  • Try to ensure that the DBMS does not have to look at huge amounts of data.

To the extent possible, minimize the work that the DBMS has to do. It is busy, and typically it is busy on behalf of many people at any given time. If you can reduce the amount of work that the DBMS has to do to process your query, everyone will be happier.

Consider things like ensuring you have appropriate indexes on the table - not too few, not too many. Designed judiciously, indexes can greatly improve the performance of many queries. Always remember, though, that each index has to be maintained, so inserts, deletes and updates are slower when there are more indexes to manage on a given table.

(I should mention: none of this advice is specific to Oracle - you can apply it to any DBMS.)

Upvotes: 7

Related Questions