Performane Tuning

Question

Hi to all...
please somebody help me to how we make performance tuning in Pl/sql.
i read many documents in google but didnt get the proper idea.Last week when i attend one interview there also ask about how you do the performance tuning in codes?
Please give the idea about the tuning and how we do it in our codes?
Thanks in Advance

Answer 1

881760 wrote:
am asking about both sql and pl/sql.. if somebody ask about how you do the performane tuning then i dont know how i explain it?SQL and PL/SQL are two different languages.
PL/SQL itself integrates the SQL language with the PL (Ada based) programming language.
So there are 3 areas that one needs to look at performance.
SQL. As the SQL language is used, you need to make sure that your SQL is designed and written optimally, that the database structures are logical (properly modelled) and correctly implemented (using features like index organised tables, indexes, partition tables, table clusters, etc). One of the important things here is that SQL cannot be fast and scalable when the underlying data model is poorly designed. SQL can only be as good and as fast as the data model allows. Thus SQL performance goes hand-in-hand with how well the data model is designed.
PL/SQL. The PL/SQL language is a formal declarative procedural language with object orientation features. It has much in common with languages like C/C++, Pascal/Object Pascal and so on. Thus the same basic rules for designing and writing optimal code in these languages, also applies to PL/SQL. Fundamentals like modularisation, code instrumentation and so on. My rules for writing in such a language is to be able to explain WHAT each and every line of code does (in detail), and explain WHY you have written that line of code.
The last performance area is the integration of the SQL language with the PL/SQL language. When you write SQL code inside PL/SQL, it means that the PL/SQL engine must make a call to the SQL engine. It needs to bind PL/SQL variables to the SQL. It needs to interact with SQL cursor created. It needs to fetch data from the cursor. Etc.
This interaction requires context switching from the PL/SQL engine to the SQL engine. Context switching happens in most/all languages to some extent. Some at quite a technical level (like switching between CPU rings), some at a higher s/w level like between the PL/SQL and SQL engines. Context switching is often a necessary, but expensive and slow, overhead. Within PL/SQL you need to make minimal context switching between the PL/SQL and SQL engines.
For example, do not use SQL function to assign a value to a PL/SQL variable when the function can be called natively from PL/SQL itself. Use bulk collection and bulk processing to reduce context switching when dealing with SQL cursors.
The most common problem with performance in the above 3 areas is incorrectly using the PL/SQL and SQL languages. Using PL/SQL to filter rows from a table, or perform a nested loop join between two cursors, when SQL can do that far better and faster. Using SQL to assign sysdate to a PL/SQL variable, when PL/SQL is perfectly capable of doing it.