Determine first if the SQL job is waiting for a locked resource, then examine the resources being consumed by the job, and finally trace the SQL and review the most expensive statements.

Use Lock Manager to check for contention
The SQL process may be waiting for another user or process to release a lock on a table or a row. Lock Manager is provided as a component of the Diagnostics Pack. Note that, for Lock Manager to work, the DBA_OBJECTS, V$LOCK, and V$SESSION views must exist on the database instance.

Use Athene Analyst or equivalent to check the most resource-hungry sessions By using a product like Athene or a similar analysis product you can use the Analyst functions to isolate user sessions that are consuming a large amount of resources. As you explore connected sessions, you can sort sessions based on any of the session statistics, e.g. session logical reads, CPU usage, or open cursors.

Trace SQL from SQL*Plus
You can trace a SQL statement from a SQL*Plus session using the AUTOTRACE command. You must have the PLUSTRACE role and PLAN_TABLE table available to use AUTOTRACE. Simply paste the required statement into SQL*Plus with AUTOTRACE on, execute it and then check the execution plan

Pinpoint problem SQL using SQL Analyze
Oracle SQL Analyze helps you tune the slow-running SQL statements in your SQL job. Analyze enables you to check for statistics, review execution plans, play with hints or walk through execution.

Detailed analysis using Trace and tkprof
The most thorough method to examine your slow-running SQL job is to trace the output and examine the trace with tkprof. You can trace your session with an ALTER SESSION command. This trace creates a file on the server operating system (in the user dump destination). You can read that trace file and perform bottleneck analysis using the tkprof utility.