It means that Oracle Database (hard) parsed the query once and executed it 75,437 times. i.e. of the 75k times your session ran the statement, only on the first run was the statement NOT in the shared pool.
So it only had to go through the full process of checking the statement is valid and producing the execution plan once.
http://docs.oracle.com/database/122/CNCPT/sql.htm#CNCPT1741 https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2588723819082 For example, this block runs "select * from t" 100 times:
create table t (
x int
);
insert into t values (1);
commit;
alter session set tracefile_identifier = chris;
exec dbms_monitor.session_trace_enable ( );
declare
v t%rowtype;
begin
for i in 1 .. 100 loop
select * into v from t;
end loop;
end;
/
exec dbms_monitor.session_trace_disable;
But it only had to load the statement once. So TKPROF for this statement shows:
SELECT *
FROM
T
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 1 0 0
Execute 100 0.00 0.00 0 0 0 0
Fetch 100 0.00 0.00 0 300 0 100
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 201 0.00 0.00 0 301 0 100
Parse = 1, Executions and Fetches both = 100.
In general this is a good thing. Hard parsing is an expensive process. So you want few parses to lots of executions. Which is what you have.
But this doesn't necessarily mean your code is good!
For example, in your output, the query processed 75,437 rows from 75,437 executions. i.e. an average of one row/run. This suggests you may have a loop with 75,437 iterations, fetching one row each time. If this is the case, ask yourself: can you get rid of the loop and rewrite your code to fetch all the rows in one go?