Disaster after i added an index !! pls help

Question

Hi All ,
I almost caused a diaster after i added an index to an existing table which i DO NOT understand. Kindly help me understand so i will not repeat the same mistake and i might probably get sacked if it ever happened again
existing table indexes
pk1 --> lotid(varchar2) , step_begin_time(date)
idx1 --> lotid(varchar2) , step_begin_time(date) , release_time(date) , location
idx2 --> release_time(date) , step_begin_time(date) , completion_class location
idx2a --> step_begin_time (date)
idx2b --> release_time (date)
new indexes
i added idx3 --> LOTID (only)
from what i checked in PL/SQL session it seem to take very long when it uses the step_begin_time ?
how does my action caused the loading that uses the step_begin_time to be that slow ???
if the statement uses step_begin_time , wouldn't it uses pk1 , or idx1 or idx2 or idx2a ??
if so how will the new index idx3 will result in such slowness
and if both lotid & step_begin_time are being used it would have used pk1 or idx1 ??
really need your advise
thankfully i managed to drop that new index and all looks ok (for now at least)
tks & rdgs

Answer 1

The index on LOTID is not necessary. Oracle (even 8.1) will happily use the indexed LOTID from the PK or idx1 if it wasn't for your wrong usage of the date data type.
As Kamal has already pointed out, when you transform the date column into a varchar column, you effectively prevent the usage of idx1 (unless you create a function based index, but that's another story and absolutely not necessary here)
You should rather convert your input parameter :b2 into a date:
WHERE lotid=:b1
AND step_begin_time = to_date(:b2,'DD-MON-YYYY hh24:mi:ss')and then Oracle should use your PK index.
You would have seen this when running explain plan. The details can be found in the manual:
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/statements_911a.htm#2061798
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/ex_plan.htm#PFGRF009
Actually I'd say that idx1 is not needed at all, because the PK will prevent more than one row with the same combination of lotid, step_begin_time so the additionally indexed column in idx1 does not give you any benefits (if that index is used, that a hit will always return a single row, no need to limit that result further by looking at the additional columns.
Did you ever check whether that index (idx1) was used?