TUNNING FOR ORACLE

tunning an application can be a very interesting thing indeed.sql-trace may also be enabled at the system or session level.

it generates so much output and is such a performance impact that you will almost selectively enable it ,if ever, enable it for

the system in the init.ora file. sql_trace has two settings as well. v$parameter is useful to find various setting relevant to

tunning such as the block size, the sort area size and so on. its relevance to tuning is that it contaions all the init.ora

parameter values and many of these will have a bearing on our performance.

oracle allows a developer to save a set of hints to the server describing how to execute a specific sql statement in the

database. this feature is referred to as optimizer plan stability and is implemented via a stored query plan outline,similar to

an outline for a book. for a given query or set of sql statements , optimizer plan stability allows us to save the optimal set of

hints for their runtime execution, without having to hint the query ourselves in the application. a key point to remember

about optimizer plan stability is that it is implemented viw hints. hints are not mandates ;hints are not rules. while the hinting

mechanism used by optimizer plan stability is a stronger one than is expected to us via the documented hinting

mechanism, the optimizer is still as always free to follow them or not at run-time. there are only two views to consider with

wuery outlines and they exhibit a master-detail relationship. the master table is the outlines tables. the detail table is

outline_hints. these views show the number of stored outlines in the datbase.dbs_outlines has an entry for each and every

stored outline by user whereas all_ and user_outlines will only expose the rows relevant to the current user.
the outline_hints views show the actual hints that must be applied to various internal phase of the developed query plan.

the server internally rewrites our submitted query with these hints embedded in it in the appropriate locating,giving us the

query plan we desire. we will never see these hints in the query text itself. this is all done against internal query plan

structures. there are various ranking functions that are useful for finding the answer to top-n type queries. there are

windowing functions which are useful for computing various aggregates. there are various reporting functions. these are

very similar to the window functions above. the partition by clause logically breaks a single result set into n groups

according to the criteria set by the partition expressions.

partinioning is designed to facilitate the management of very large tables and indexes by implementing the divide and conquer logic. dynamic sql is a natural choice in api approaches to databse programming.static sql on the other hand is more natural in precompiler environments. the dbms_sql package is a supplied built in package with the database. dbms_sql is a procedural approach to dynamic sql. in general, a process using dbms_sql will have the following structure:call open_cursor to obtain a cursor handle; call parse to parse a statement. a single cursor handle may be used with many different parsed statements; call bind_variable or bind_array to supply any input to the statement.