Query running sometimes slow and sometimes fast on both prod and dev. Help

Question

We are running a job that is behaving so inconsistently that I am ready to jump off the 19th floor. :-)
This query that goes against one table, was just coming to halt in production. After 4 days of investigation we thought it was the resource on production box. Now we have another dev box where we were also having the same issue. This box gets updated with production data everyday. There is a 3rd box. DBA ran update statistics on the 3rd box and the job was never slow there. When we updated 2nd box (dev) with statistics from th 3rd box, the job also ran fine. So we thought we know for sure that it is the statistics that we need to up. Now for business testing, the 2nd and 3rd box got updated with data and statistics from production box (the troubled one). We thought surely we will see issues on the 2nd and 3rd box, but the job was just running fine on these boxes. As I said, the 2nd box gets updated with production data everyday. After last night's refresh this job is running long on the 2nd box again. We are really puzzled. Has any one experience anything like this before?
thanks in advance.
Reaz.

Answer 1

We got our dba who is checking the plan when ever we run the job.
The dba is running the trace right now. Here is the trace result from the trace:
SELECT STATUS_FLAG, FSI_TID, FSI_REC_TID, AREA, VALUE_DATE, CANCEL_DATE,
TO_DATE(ENTRY_DATE_TIME), PRODUCT, CUST_TID
FROM
ORD_FX WHERE WSS_GDP_SITE = :B3 AND DEAL_NUMBER = :B2 AND TICKET_AREA = :B1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 514 0.23 0.27 0 0 0 0
Fetch 514 253.40 247.44 0 16932188 0 514
total 1028 253.63 247.71 0 16932188 0 514
Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 26 (recursive depth: 1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
latch: cache buffers chains 2 0.00 0.00
no IO issue in any database at any time. We saw a little high IO in production yesterday so we thought we are looking at a resource issue, but today the system is fine and we had no luck with the job.