Index, Hints, etc

Question

All,
I was wondering whether you could please help out on the following points:
(a) In the query below, what might be the suitable (and why?) indexes to be built?
=======================================
SELECT CONTRACT_PAY_GROUPS.CPG_AMOUNT_CY_AP,
CONTRACT_PAY_GROUPS.CPG_AMOUNT_EU_AP,
CONTRACT_PAY_GROUPS.CPG_TOTAL_ELIGIBLE_AREA
FROM CONTRACT JOIN CONTRACT_PAY_GROUPS ON CONTRACT.AC_SEQ = CONTRACT_PAY_GROUPS.CPG_CON_SEQ
WHERE CONTRACT.AC_START_YEAR = 2005
AND CONTRACT.AC_APPLICANT_NUMBER = '50614'
AND CONTRACT_PAY_GROUPS.CPG_SCHEME = 'Ε'
AND CONTRACT.AC_STATUS <> 2
=======================================
(b) Can the query below be (re-)written in any better way, in terms of performance (that is, which ---type of--- indexes and/or hints might be important to be created)?
=======================================
SELECT LYALLPLOTS.CP_END_YEAR
FROM (SELECT TYPLOTS.CP_PE_PLOT_ID FROM (SELECT CP_PE_PLOT_ID,
CP_PE_PT_SEQ,
AC_APPLICANT_NUMBER,
AC_START_YEAR,
AC_END_YEAR,
AC_STATUS,
AC_TYPE
FROM CONTRACT JOIN CONTRACT_PLOT ON CONTRACT.AC_SEQ = CONTRACT_PLOT.CP_CON_SEQ
JOIN APPLICATIONS ON CONTRACT.AC_APPL_SEQ = APPLICATIONS.APPL_SEQ
WHERE APPLICATIONS.APPL_YEAR = 2005
AND CP_PE_PT_SEQ IS NOT NULL ) TYPLOTS JOIN
(SELECT PT_SEQ, PT_PLOT_ID, PT_FROM_APPL_NUM, PT_TO_APPL_NUM FROM PLOTS_TRANSFER) TRPLOTS
ON TYPLOTS.CP_PE_PT_SEQ = TRPLOTS.PT_SEQ) TYTRANSFERS
JOIN (SELECT CP_PE_PLOT_ID, AC_APPLICANT_NUMBER, CONTRACT_PLOT.CP_END_YEAR FROM CONTRACT_PLOT JOIN CONTRACT
ON CONTRACT_PLOT.CP_CON_SEQ = CONTRACT.AC_SEQ
WHERE CONTRACT.AC_START_YEAR = 2004) LYALLPLOTS ON TYTRANSFERS.CP_PE_PLOT_ID = LYALLPLOTS.CP_PE_PLOT_ID
WHERE TYTRANSFERS.CP_PE_PLOT_ID = '5101-53/16--143'
GROUP BY LYALLPLOTS.CP_END_YEAR;
=======================================
(c) In general, could you please provide any insight on which types of indexes and/or hints (UNNEST, HASH_AJ, etc) might be needed in the case we are joining tables?
Any clue/support will be greatly appreciated. Thank you,
-Pericles Antoniades.

Answer 1

I'll echo sven's advice about not using hints unless you need to. I'm not telling you not to use hints. I am telling you to explore other solutions first, for the reasons sven mentioned.
An indexing strategy can be tricky to come up with. There are guidelines to follow (which follow), but also exceptions to those guidelines. Your own observations may differ from I'm going to describe. Also, I only glanced at your posting and possibly missed something. I'm going to describe btree indexes. Bitmap indexes work a bit differently.
Generally, indexes help do two things: get back small amounts of data quickly, and enforce uniqueness. Small amounts of data is sometimes considered to be between 15-20% of the rows in a table in 9i/10g; more than this and you might be better off with direct table access. Indexed lookups work well with nested loops joins (this is where the execution plan becomes useful) or direct table access, while other join methods (usually hash joins) may be more efficient when joining most of the rows from two tables.
What columns should you index? That's a matter of some debate. You can search OTN for other ideas. The best candidates for indexing are columns used in your WHERE clauses and/or those that make up a unique key. In your example
ON CONTRACT.AC_SEQ = CONTRACT_PAY_GROUPS.CPG_CON_SEQ WHERE CONTRACT.AC_START_YEAR = 2005 AND CONTRACT.AC_APPLICANT_NUMBER = '50614' AND CONTRACT_PAY_GROUPS.CPG_SCHEME = 'Ε' AND CONTRACT.AC_STATUS <> 2
I personally get the best results by listing the indexes in the order of most to last restrictive, but that's a matter of some debate.
I would consider putting indexes on contract.ac_seq, contract.ac_start_year contract.ac_applicant_number, and contrct.ac_status (composite), as well as contract_pay_groups.cpg_scheme and cpg_con_seq (composite). Then I would check to see if they were being used from an execution plan, ultimately using timings and run statistics from SQL*PLUS AUTOTRACE to decide if they were helping.