Opening and fetching cursor.. what accually happens?

Question

So, if we have an explicit cursor... we open it with open c_cursor_name... and fetches it into some variable...
my question is - what really happens when we open cursor?
does oracle make only instance of cursor object in memory? or... does it reads some basic data about rows that are going to be fetched (rowid's?)..? or what?
also, if we make some insert into a table that is going to be rolled over by cursor (while cursor is fetching..), should cursor read this new data? for example, what is difference if cursor roll over an indexed ID and we make an insert with an ID=10, and cursor is currently on ID=100? or opposite? (commit included in insert)...
oh, so many questions :)
tnx :)

Answer 1

Not really. The same SQL cursor in the shared pool applies.
The difference is on the client side. Each of the methods you've listed is essentially using a different method on the client side to interact with the cursor on the server.
Some methods are more desirable in some cases than another - there's not a single superior method. Each has pros and cons and addresses a specific set of client coding requirements.
There are some preferred methods though on the client. The three primary ones are:
a) use bind variables (enables one to re-use the same SQL cursor)
b) re-use the same client cursor handle for tight loop operations
c) use bulk binding
The first one is kind of obvious - as bind variables creates a cursor "program" that can be called/executed with different values. Like an INSERT cursor for example. The same SQL cursor can be used to insert a million rows, with each execution using different variable values to insert.
The second one is not that applicable to the PL language in PL/SQL - thanks to the integration between the PL and SQL languages. In other client languages though, you want to re-use not only the same server cursor, but the same client cursor handle. As this saves you a soft parse. So instead of this approach:
// pseudo code
for i in 1..count
  CreateCursor( c, <sql statement> );
  BindValue( c, 1, myVariable[i] );
  ExecCursor( c );
  CloseCursor( c );
end loop;..the following is far more efficient:
// pseudo code
CreateCursor( c, <sql statement> );
for i in 1..count
  BindValue( c, 1, myVariable[i] );
  ExecCursor( c );
end loop;
CloseCursor( c );This approach re-uses the client handle - which means a single db parse was needed. The prior approach required a brand new parse for each loop iteration. (even soft parsing is an overhead that should be avoided where possible)
The last primary factor is bulk processing. This is fairly well documented for the PL language - the important bit to remember that bulk processing is only intended to pass more data with a single call between the PL and SQL engines. Nothing more. The price of which is a bigger PGA memory footprint. Thus there is a balance between how much data (rows/variables) one should pass between the two versus the amount of memory that consumes.