ORACLE Database Health & Query Tuning

y y y y y y y y y y

Database Health Check (ORACLE) Why to go to DB Health Check Oracle V$ views & Sys tables used to create the Sample Script for DB Health Check. Benefits Oracle Query Tuning How to use Explain Plan Usage of Hints General Hints Do and Don¶t of using Hints Q&A


Database Health Check

Goal: Reduce Time between Problem Reporting to Problem Resolution By Regular Database health Check


v_$instance :- This view give us the information about db instance. The following script will help you in deriving the Total Days including Hours minutes and seconds from when this instance of database is started.

prompt #### Instance Up Time #### select 'Hostname : ' || host_name ,'Instance Name : ' || instance_name ,'Started At : ' || to_char(startup_time,'DD-MON-YYYY HH24:MI:SS') stime ,'Uptime : ' || floor(sysdate - startup_time) || ' days(s) ' || trunc( 24*((sysdate-startup_time) trunc(sysdate-startup_time))) || ' hour(s) ' || mod(trunc(1440*((sysdate-startup_time) trunc(sysdate-startup_time))), 60) ||' minute(s) ' || mod(trunc(86400*((sysdate-startup_time) trunc(sysdate-startup_time))), 60) ||' seconds' uptime from sys.v_$instance;

ORACLE V$ Views & Sys Tables


sys.dba_tablespaces :- Dictionary view provides the list of all tablespaces present in the database. sys.dba_data_files :- Dictionary view provides the list of all physical datafiles and their size. DBA_DATA_FILES also provides the path of the data files in the system. Each data file is associated with only one tablespace. But a tablespace is associated with more than one data file. ´Bytes´ column present in DBA_DATA_FILES denote the total bytes allocated to a data file. sys.dba_free_space :- Dictionary view provides the free space information associated with each data file. ´Bytes´ column present in DBA_free_space denote the total free space in bytes available in a data file.



ORACLE V$ Views & Sys Tables

tablespace_name = c.dba_data_files a GROUP BY tablespace_name) a.tablespace_name(+) AND a. This script will help in determining the free space available for tablespace and can alarm team before ending up in tablespace issues. 2) mb_allocated.tablespace_name = b. 0) BYTES FROM SYS.BYTES).BYTES.dba_tablespaces c WHERE a. 2) tot_pct_free. 2) mb_free.tablespace_name(+) AND a. ROUND ((a.BYTES / a. ROUND (a. ROUND (b.file_id = b.BYTES / 1048576. ROUND (b. 2) * 100 tot_pct_used FROM (SELECT tablespace_name. (SELECT a. total free space from dba_free_space view.. NVL (SUM (b.y Below query calculates the total file size allocated from dba_data_files view. ROUND ((a. 2) mb_used. SYS. .BYTES / 1048576.b. and then calculates the sum by grouping the data files associated with a tablespace.tablespace_name) b. SYS.BYTES) / 1048576.BYTES) / a.BYTES . SELECT * FROM (SELECT c.file_id(+) GROUP BY a.b.dba_data_files a.. SUM (a.tablespace_name.tablespace_name.BYTES * 100.dba_free_space b WHERE a.tablespace_name = b.contd.BYTES) BYTES FROM SYS. .BYTES .tablespace_name) WHERE tot_pct_used >= 0 ORDER BY tablespace_name ORACLE V$ Views & Sys Tables .

Details about the user created tables. SUBSTR(object_name. COUNT(*) cnt FROM user_objects GROUP BY object_type. SELECT owner. which is portioned table use & query.status.1.contd. SELECT object_type.dba_objects WHERE status='INVALID' ORDER BY object_type.y user_objects . SELECT table . y user_tables :. status..dba_objects :.It provides the details about each object present in user schema (user_objects) or complete schema (sys. .30) object_name FROM sys. sys. object_type. name FROM user tables WHERE partitioned='YES'.dba_objects). To find ORACLE V$ ViewsbelowSys Tables ..

ANY partitioned Object approaching TO MAX extents: SELECT PARTITION_NAME..dba_segments :.dba_segments WHERE max_extents-NVL(next_extent..0) FROM sys.y Sys. Checking Max Extents Status: SELECT segment_name.MAX_EXTENTS. max_extents FROM sys. SQL File .contd. .Storage allocated for all database segments. extents.dba_segments WHERE max_extents-extents<100. max_extents-NVL(next_extent. y Sample Script Attached for DB Health Check :- ORACLE V$ Views & Sys Tables .NEXT_EXTENT.0) < 1000 AND partition_name IS NOT NULL.EXTENTS. segment_type.

y Monitor the size of the database which can avoid the tablespace issues. Make you DB clean by validating invalid Objects. Reduction in US DBA dependency Monitor the performance of database. y y y Benefits for DB Health Check .

y y y y y y Why Tuning is Required :To Improve Response Time To Improve Batch throughput To ensure scalability To reduce system load To avoid hardware upgrade. Oracle Query Tuning .

Create Cursor Parse SQL Bind Variable Execute Cursor Allocate Memory for Cursor Check Syntax and Security Associate Program Variable with SQL Execute DML Statement or Prepare to Query Query ? Fetch Rows Retrieved one or more rows Close Cursor SQL Execution Ended Oracle Query Tuning.. Re-execute Cursor Re-execute SQL statement Close Cursor De-allocate Cursor memory and discarded .SQL TuningProcessing .

y The Combination of steps Oracle uses to execute statement is called Execution Plan It is the process of determining the ³Optimal path´ to retrieve Data.Based on predefined set precedence rule. y Execution Plan & Query Optimization . y Rule based :.Takes into account statistical information related TuningOracle Query to volume and distribution of Tuningdata with in table. There are following approach for Query Optimization. Does not take into account the ³volume of data´. y Cost Based :.

.This specify the cost based approach if any table is analyze.y y Goals of Query Optimization Rule :.This specify that optimizer has to take rule based approach to optimization. y Oracle Query Tuning.Query TuningOptimization Choose :. If no table is analyze then use rule based approach.

Query particular SQL statement with specified Optimization ± Cost Based plan.Cost Based Approach :y The cost based approach used the statistics to estimated the cost of each execution plan. y y These stats are generated using ³Analyze´ command. Using these Statistics. y .CPU Time Oracle Query required to execute the Tuningand memory are Tuning.Statistics . the optimizer estimates how much the I/O.

The rule chosen is based strictly on query structure and pays no attention to the number of rows. . partitioning or other query specific features and statistics.Query Tuning ± Rule Based Approach y Rule based optimizer uses a set of 15 rules to determine how to best process a query.

The information includes the distribution of data. the number of rows in the table and other important statistics. To compute statistics: ANALYZE TABLE tablename COMPUTE STATISTICS.y y y y y Query Tuning ± Analyze Command The analyze command within the Oracle database collects statistics about an object. . If you are using the cost-based optimizer you must analyze your database objects. This information is collected and supplied to the optimizer to allow for the best possible execution path of a SQL statement. you should regularly schedule to re-analyze your tables and indexes. To estimate statistics: ANALYZE TABLE tablename ESTIMATE STATISTICS SAMPLE 30 PERCENT. As well when you are analyzing your objects your should tell the database the size of the sample it should use if you wish to have the database estimate statistics (this is a faster method). You should also remember that statistics get old and dated. If you wish for an exact computation of statistics you would use the "compute" argument.

DBA_INDEXES USER_TABLES. an entire object is scanned to gather data about the object. This data is used by Oracle to compute exact statistics about the object. DBA_TAB_COLUMNS . the larger the size of an object. COMPUTE STATISTICS :When computing statistics. estimated statistics about the object. ALL_INDEXES. the more work that is required to gather the necessary information. so an object can be analyzed quickly. This subset of information provides reasonable. Because an entire object is scanned to gather information for computed statistics. The accuracy of estimated statistics depends upon how representative the sampling used by Oracle is.Query Tuning ± Analyze Command contd. ALL_TABLES. ESTIMATE STATISTICS :When estimating statistics. DBA_TABLES USER_TAB_COLUMNS. Slight variances throughout the object are accounted for in these computed statistics. You can optionally specify the number or percentage of rows that Oracle should use in making the estimate. Oracle gathers representative information from portions of an object. Viewing Object Statistics:The statistics can be queried using the following data dictionary views: USER_INDEXES. ALL_TAB_COLUMNS. Only parts of an object are scanned to gather information for estimated statistics.

This can lead to inaccuracies for some statistics. number of blocks currently containing data. the table statistics gathered by DBMS_STATS include the number of rows. average free space. or number of unused data blocks. and average row length but not the number of chained rows. .DBMS_STATS gathers statistics only for cost-based optimization. such as the number of distinct values.y Statistics Details: Number of used blocks in each table Number of rows in each table Number of distinct values for each column Number of nulls in each column Average length of each column Number of branch levels of index Number of leaf-blocks in index Clustering factor of index y DBMS_STATS and Analyze command: The advantage of DBMS_STATS is . Query Tuning ± Analyze Command contd. For example. DBMS_Stats won't do that. .can analyze external tables.can gather system statistics ( 9i onwards ) . ANALYZE calculates global statistics for partitioned tables and indexes instead of gathering them directly. it does not gather other statistics.easier to automate .

Check syntax + semantics Generate plan description Execute the plan Transform Query plan Tuning ±Optimizer into ³executable´ Overview .

Step [7] is the execution of the statement.QEP = Query Evaluation y y Query Tuning ± Explain Plan Plan Steps [1]-[6] are handled by the parser.Rewrites query transforming some complex constructs into simpler ones where appropriate (e. .Checks that all objects exist and are accessible [3] View Merging :. subquery merging. [6] QEP Generation :. Query processing can be divided into 7 phases: [1] Syntactic :. The explain plan is produced by the parser.Determines the optimal access path for the query to take.QEP = Query Evaluation Plan [7] QEP Execution :.y y An explain plan is a representation of the access path that is taken when a query is executed within Oracle. With the Cost Based Optimizer (CBO) we use statistics to analyze the relative costs of accessing objects. Once the access path has been decided upon it is stored in the library cache together with the statement itself. in/or transformation) [5] Optimization :.g.Rewrites query as join on base tables as opposed to using views [4] Statement Transformation :.Checks the syntax of the query [2] Semantic :. With the Rule Based Optimizer (RBO) it uses a set of heuristics to determine access path.

rows Driving Table :.Cost Based Optimization y y y y y Query Tuning ± Explain Plan Terminology y .Rule Based Optimization CBO :.where clause of a query Tuples :.A set of rows used in a query may be a select from a base object or the result set returned by joining 2 earlier row sources.This is the row source that we use to seed the query.This is the object we lookup data in after we have retrieved relevant key data from the driving table. Predicate :.y Row Source :. RBO : . If this returns a lot of rows then this can have a negative affect on all subsequent operations Probed Table :.

The smallest amount of data read is a single Oracle block. the largest is constrained by operating system limits (and multiblock i/o). y y y How does Oracle access data? At the physical level Oracle reads blocks of data.Query Tuning ± Explain Plan ± contd.. Logically Oracle finds the data to read by using the following methods: Full Table Scan (FTS) Index Lookup (unique & nonunique) x x x x index unique scan index range scan index full scan index fast full scan Rowid .

The resultant row source is passed up to the next level of the query for processing. This statement means we are doing a full table scan of table LARGE.y y y y y y Query Tuning ± Explain Plan Understanding y y Simple Explain Plan :Query Plan ----------------------------------------SELECT STATEMENT [CHOOSE] Cost=1234 TABLE ACCESS FULL LARGE [:Q65001] [ANALYZED] In this case TABLE ACCESS FULL LARGE is the first operation. [ANALYZED] indicates that the object in question has been analyzed . (SELECT STATEMENT) [CHOOSE] is an indication of the optimizer_goal for the query Explain plan below indicates the use of the CBO because the cost field has values SELECT STATEMENT [CHOOSE] Cost=1234 Explain plan below indicates the use of the RBO because the cost field is Empty SELECT STATEMENT [CHOOSE] Cost= [:Q65001] indicates that this particular part of the query is being executed in parallel.

HWM marks the last block in the table that has ever had data written to it Example FTS explain plan: SQL> explain plan for select * from dual.Data is accessed by looking up key values in an index and returning rowid¶s. Query Plan -----------------------------------SELECT STATEMENT [CHOOSE] Cost=1 TABLE ACCESS BY ROWID EMP [ANALYZED] INDEX UNIQUE SCAN EMP_I1 Notice the 'TABLE ACCESS BY ROWID' section. In this case the rowid has been produced by looking up values in the index first. SQL> explain plan for select empno.Access Methods in detail y Full Table Scan (FTS) :. This is explained below. y Query Tuning ± Explain Plan Access Methods .ename from emp where emp_no =10. The index is being accessed by an 'INDEX UNIQUE SCAN' operation.In a FTS operation. y y y Query Plan ----------------------------------------SELECT STATEMENT [CHOOSE] Cost= TABLE ACCESS FULL DUAL Index lookup :. the whole table is read up to the high water mark (HWM). This indicates that the table data is not being accessed via a FTS operation but rather by a rowid lookup.

.ename from emp where empno > 7876 order by empno. If all the required data resides in the index then a table lookup may be unnecessary and all you will see is an index access with no table access. Query Plan ------------------------------------------------------------SELECT STATEMENT [CHOOSE] Cost=1 TABLE ACCESS BY ROWID EMP [ANALYZED] INDEX RANGE SCAN EMP_I1 [ANALYZED] y y Query Tuning ± Explain Plan Access Methods contd. Query Plan -----------------------------------SELECT STATEMENT [CHOOSE] Cost=1 INDEX UNIQUE SCAN EMP_I1 Indexes are presorted so sorting may be unnecessary if the sort order required is the same as the index.. Notice that no table access takes place: SQL> explain plan for select empno from emp where empno=10. In the following example all the columns (empno) are in the index. SQL> explain plan for select empno.y y y The index name in this case is EMP_I1.

. SQL> explain plan for select /*+ Full(emp) */ empno. There are 4 methods of index lookup: x x x x index unique scan index range scan index full scan index fast full scan Query Tuning ± Explain Plan Access Methods contd. Query Plan ------------------------------------------------------------SELECT STATEMENT [CHOOSE] Cost=9 SORT ORDER BY TABLE ACCESS FULL EMP [ANALYZED] Cost=1 Card=2 Bytes=66 Because we have forced a FTS the data is unsorted and so we must sort the data after it has been retrieved.ename from emp where empno> 7876 order by empno. .y y y y y In this case the index is sorted so there rows will be returned in the order of the index hence a sort is unnecessary.

However this may return > 1 row as the uniqueness will not be guaranteed. Query Tuning ± Explain Plan - Access Methods contd. SQL> explain plan for select empno. Always returns a single value You must supply AT LEAST the leading column of the index to access data via the index. Query Plan -----------------------------------SELECT STATEMENT [CHOOSE] Cost=1 .Method for looking up a single key value via a unique index.y Index unique scan :.ename from emp where empno=10..

> < <> >= <= between) SQL> explain plan for select empno. Query Plan ------------------------------------------------------SELECT STATEMENT [CHOOSE] Cost=1 TABLE ACCESS BY ROWID EMP [ANALYZED] INDEX RANGE SCAN EMP_I1 [ANALYZED] A non-unique index may return multiple values for the predicate col1 = 5 and will use an index range scan SQL> explain plan for select mgr from emp where mgr = 5 Query plan -------------------SELECT STATEMENT [CHOOSE] Cost=1 INDEX RANGE SCAN EMP_I2 [ANALYZED] y Query Tuning ± Explain Plan Access Methods contd..ename from emp where empno > 7876 order by empno.y y Index range scan Method for accessing multiple column values You must supply AT LEAST the leading column of the index to access data via the index Can be used for range operations (e. .g.

y Create concatenated index on big_emp (empno.ename) SQL> explain plan for select empno.Index Full Scan y In certain circumstances it is possible for the whole index to be scanned as opposed to a range scan (i. AccessPlan ----------------------------------------------------------SELECT STATEMENT [CHOOSE] Cost=26 y .ename Query Tuning ± Explain Plan from big_emp order by empno.ename. where no constraining predicates are provided for a table)..e. Query Methods contd.

Query Plan -----------------------------------------Query Tuning ± Explain Plan SELECT STATEMENT [CHOOSE] Cost=1 INDEX Methods contd. Index BE_IX is a concatenated index on big_emp (empno. It is the mechanism behind fast index create and recreate.ename) SQL> explain plan for select empno.ename from big_emp..y INDEX FAST FULL SCAN :.Scans all the block in the index Rows are not returned in sorted order. Access FAST FULL SCAN BE_IX [ANALYZED] y Selecting the 2nd column of concatenated index: .

Joins :. Joins Type :x Sort Merge Join (SMJ) x Nested Loops (NL) x Hash Join y y Query Tuning ± Explain Plan Access Methods contd.A Join is a predicate that attempts to combine 2 row sources.y Rowid :. .This is the quickest access method available Oracle simply retrieves the block specified and extracts the rows it is interested in..

sorted in earlier steps. If the row sources are already (known to be) sorted then the sort operation is unnecessary as long as both 'sides' are y Sorted rows from bothsame key. Presorted row sources include sorted using the sides are then Sort Sort indexed columns and row sources that have already been merged together (joined). the row sources could be accessed in parallel. y Rows from Row Source 2 are then produced and sorted by the same sort key as Row Source 1. . Although the merge of the 2 row y sources is handled serially. y Row Source 1 and 2 are NOT accessed MERGE concurrently.Query Tuning ± Explain Plan Row Row source 1 Access source 2 Methods contd. Sort Merge Join :y Rows are produced by Row Source 1 and are then sorted..

deptno from emp e.dept d where e.d.deptno. . Query Plan ------------------------------------SELECT STATEMENT [CHOOSE] Cost=17 MERGE JOIN SORT JOIN TABLE Explain Plan [ANALYZED] Tuning ± ACCESS FULL EMP .deptno order by e.deptno = d.SQL> explain plan for select /*+ ordered */ e..Access SORT JOIN Methods contd. TABLE ACCESS FULL DEPT [ANALYZED] y Sorting is an expensive operation.deptno.deptno.d.

(ROWID) Methods contd.Nested Loops :y First we return all the rows from row source 1 Then we probe row source 2 once for each row returned from row source 1 y Row source 1 ~~~~~~~~~~~~ Row 1 --------------.Probe Nested Loop > Row source 2 Row 2 --------------..Probe . > Row source 2 Index Access y Row source 1 is known as the outer table Row source 2 is known as the inner table y .Access (Full) Row 3 --------------.Probe Access B > Row Explain Access A Tuning ± source 2 Plan .

dname. b. Methods UNIQUE SCAN PK_DEPT [ANALYZED] .deptno.Access [ANALYZED] INDEX contd.SQL> explain plan for select b.sql from emp a.. Query Plan ------------------------SELECT STATEMENT [CHOOSE] Cost=5 NESTED LOOPS TABLE ACCESS FULL EMP [ANALYZED] TABLE ACCESS BY ROWID DEPT Tuning ± Explain Plan .deptno = b. dept b where a.

Hash Join :y More efficient in theory than NL & SMJ.. y Row source 1 (build input) Row source 2 (probe) Hash table and bitmap filter in MEMORY DISK Output rows . Tuning ± Explain a quick . hash table and are especially useful when the hash table is too large to fit in memory. y Only accessible via the CBO y Smallest row source is chosen and used to build a hash table and a bitmap y The second row source is hashed and checked against the hash table looking for joins.Access y The bitmap is used as Plan lookup to check if rows are in the Methods contd.

dept where emp. Query Plan ---------------------------SELECT STATEMENT [CHOOSE] Cost=3 HASH JOIN TABLE ACCESS FULL DEPT TABLE ACCESS FULL EMP Tuning ± Explain Plan .deptno = dept.. .SQL> explain plan for select /*+ use_hash(emp) */ empno from emp.deptno.Access Methods contd.

ora parameters Nested Loops Any join USE_NL CPU None Sort-Merge Equi joins only USE_MERGE Temporary segments sort_area_size db_file_multiblock_read_count Hash Join Equi joins only USE_HASH Memory hash_join_enabled hash_area_size hash_multiblock_io_count Better than nested loop when indexes is missing or search criteria is not restrictive Can require lot of memory and slow down updates and full table scan Features Works with any join Better than nested loop when indexes is missing or search criteria is not restrictive Must perform an extra sort. Drawbacks Very inefficient when no suitable index exists . Cannot return First rows fast.Join TuningComparisons Type of Join When can be used Optimizer hint Resource concerns init.Query Tuning.

deptno from emp.dept Query Plan -----------------------------SLECT STATEMENT [CHOOSE] Cost=5 MERGE JOIN CARTESIAN TABLE ACCESS FULL DEPT SORT JOIN TABLE ACCESS FULL EMP The CARTESIAN keyword indicate that we are doing a Cartesian product .. y Cartesian Product A Cartesian Product is done where they are no join conditions between 2 row sources and there is no alternative method of accessing the data Not really a join as such as there is no join! Typically this is caused by a coding mistake where a join has been left out.dept.deptno.Access Methods contd. It can be useful in some circumstances .Star joins uses Cartesian products. Notice that there is no join between the 2 tables: SQL> explain plan for select emp.y y y Tuning ± Explain Plan .

and parent_id. named PLAN_TABLE y Arguably.SQL which creates this table. the most important fields within the plan table are operation. You must make sure such a plan table exists. id. option. Tuning ± Obtain Explain Plan y . sql*plus automatically explains the plan for you if autotrace is enabled.y The plan table is the table that Oracle fills when you have it explain an execution plan for an SQL statement. object_name. Oracle ships with the script UTLXPLAN.

HINTS . y The following syntax is used for hints: y select /*+ HINT */ name from emp where id =1. Tuning . Where HINT is replaced by the hint text.Hints are exactly what it means±clues or directives that will assist the optimizer in choosing an execution plan.

. with the execution of the statement. UPDATE. each separated with spaces y Hints are meant for DML statements: INSERT. y Hints are provided in comment format that is embedded in the query. y Multiple hints can be provided in a single comment for a statement. y If a wrong or invalid hint is provided. The optimizer will not notify the user about y .Hints are not orders but directives to the optimizer. DELETE and SELECT y Hints are not case sensitive. the optimizer ignores it and continues Tuning ± HINTS contd.

Commonly Used Hints y FULL y INDEX y ORDERED y USE_NL y PUSH_SUBQ y PARALLEL y ALL_ROWS y FIRST_ROWS(n) y TuningTuning.Common HINTS .

Common HINTS WHERE department_id FROM employees ± department_id > 50.FULL :. SELECT /*+ FULL(e) */ employee_id..The FULL hint explicitly chooses a full table scan for the specified table. y INDEX :.The INDEX hint explicitly chooses an index scan for the specified table.The ORDERED hint causes Oracle to join tables in the order in which they appear in the FROM clause y . contd. last_name FROM employees e WHERE last_name LIKE :b1. TuningTuning. y ORDERED :. SELECT /*+ INDEX (employees emp_department_ix)*/ employee_id.

The PUSH_SUBQ hint causes non-merged subqueries to be evaluated Tuning.order_id = h.USE_NL :.The USE_NL hint causes Oracle to join each specified table to another row source with a nested loops join.Common HINTS ± in the execution plan. SELECT /*+ USE_NL(l h) */ h.quantity FROM orders h . l.order_items l WHERE l. y PUSH_SUBQ :. Select /*+ PUSH_SUBQ */ * from emp where emp_dept_no in (select a_dept_no from a where a_dept_no >10) y .order_id.customer_id.unit_price * the earliest possible step Tuning. contd. using the specified table as the inner table.

salary. last_name.ALL_ROWS :.Common HINTS ± response. contd.The FIRST_ROWS(n) hint instructs Oracle to optimize an individual Tuning. last_name. job_id y . job_id FROM employees WHERE employee_id = 7566.The ALL_ROWS hint explicitly chooses the query optimization approach to optimize a statement block with a goal of best throughput (that is.SQL statement for fast Tuning.. SELECT /*+ ALL_ROWS */ employee_id. salary. choosing the plan that returns the first n rows most efficiently SELECT /*+ FIRST_ROWS(10) */ employee_id. minimum total resource consumption). y FIRST_ROWS(n) :.

y Don't create index on columns that appear in WHERE clause and uses a function other than MAX. y Avoid FTS until its necessary y Use column name in order by and use it y . y Use SET TRANSACTION where possible use ROLLBACK SEGMENT y Retrieve only necessary column y Always use joins instead of sub-quires.Optimize where clause y Truncate table if possible then delete. y Avoid NOT in where clause use between Tuning ± Do and Don¶t Hints ³>=³ etc. MIN. y Don't create index on a column that is modified highly.

1) = µ9¶ y Use: Use: Select * from Account Where ac_acct_no like µ9%¶ y Do Not Use: Use: Select * From fin_trxn Where ft_trxn_ref_no != 0 y Use: Use: Select * From fin_trxn Where ft_trxn_ref_no > 0 Tuning ± Do and Don¶t Hints .1.y Do Not Use: Use Select * from Account Where substr(ac_acct_no.

¶yyyymmdd¶) = to_char(sysdate.¶yyyymmdd¶) y Use: Use: Select * From CLIENT Where CUT_OFF_DATE >= trunc(sysdate) and CUT_OFF_TIME < trunc(sysdate) + 1 Tuning ± Do and Don¶t Hints .y Do Not Use: Use: Select * From account Where ac_type || ac_branch = µsav001¶ y Use: Use: Select * From account Where ac_type = µsav¶ And ac_branch = µsav001¶ y Do Not Use: Use: Select * From CLIENT where to_char(CUTT_OFF_TIME.

¶yyyymmdd¶) y Use: Use: Select * From acct_trxn Where at_value_date >= trunc(sysdate) + 1 y Do Not Use: Use: Select * From acct_trxn Where to_char(at_value_date.¶yyyymmdd¶) > to_char(sysdate.¶yyyymmdd¶) y Use: Use: Select * From acct_trxn Where at_value_date < trunc(sysdate) Tuning ± Do and Don¶t Hints .¶yyyymmdd¶) < to_char(sysdate.y Do Not Use: Use: Select * From acct_trxn Where to_char(at_value_date.

¶yyyymmdd¶) y Use: Use: Select * From acct_trxn Where at_value_date < trunc(sysdate) + 1 Tuning ± Do and Don¶t Hints .¶yyyymmdd¶) y Use: Use: Select * From acct_trxn Where at_value_date >= trunc(sysdate) y Do Not Use: Use: Select * From acct_trxn Where to_char(at_value_date.¶yyyymmdd¶) <= to_char(sysdate.y Do Not Use: Use: Select * From acct_trxn Where to_char(at_value_date.¶yyyymmdd¶) >= to_char(sysdate.

y Do Not Use: Use: Select count( *) From BROKER y Use: Use: Select count(PRIMARY_KEY or a non null INDEX column or 1) From Broker y Do Not Use: Use: select * from account where cust_Active_flag = µy¶ having group = µ001¶ Use: Use: select * from account where cust_Active_flag = µy¶ and group = µ001¶ Tuning ± Do and Don¶t Hints .

y Do Not Use: Use: select * from Student where STUDENT_NUM not in (select STUDENT_NUM from CLASS) y Use: Use: select * from STUDENT C where not exists (select 1 from CLASS A where A.STUDENT_NUM = C.STUDENT_NUM) y Do Not Use: Use: select * from system_user where su_user_id not in (select ac_user from account) y Use: Use: select * from system_user where su_user_id in (select su_user_id from system_user minus select ac_user from account) Tuning ± Do and Don¶t Hints .

Sign up to vote on this title
UsefulNot useful