In fact, we get a greater insight into how it works if we look at the corresponding functions in OCI (Oracle Call Interface, [2]) . (In fact, there is also an OCI (so-called "thick") JDBC driver for Oracle, but in practice the thin driver is usually used, to which these explanations refer.) Even if you do not program OCI yourself (C/C++), it can be interesting to look at the OCI documentation, since OCI is more "low-level" compared to JDBC and therefore reveals more about the implementation.
To make the following explanation understandable, first a few words about the "cursor". Cursor is an ambiguous word that is used very differently depending on the bulgaria telegram screening context - for example by a DBA or an application developer. Even among developers, the associations will be different, depending on whether you are programming PL/SQL or Java, for example.
In my opinion, the most comprehensive and precise definition is that given by Christian Antognini in his book Troubleshooting Oracle Performance (Apress, 2nd edition 2014): "A cursor is a handle (that is, a memory structure that enables a program to access a resource) that references a private SQL area with an associated shared SQL area."
This means that a cursor is initially a structure (handle/pointer) in the client-side memory. This handle references a location in the private SQL area on the server (in the so-called UGA). And this in turn contains a reference to a structure in the server's shared memory (SGA).