The client cache transparently keeps the result set consistent with
any session state or database changes that can affect its cached
result sets.
When a transaction modifies the data or metadata of any of the
database objects used to construct that cached result, invalidation is
sent to the OCI client on its subsequent round-trip to the server. If
the OCI application does no database calls for a period of time, then
the client cache lag setting forces the next OCIStmtExecute() call to
make a database call to check for such invalidations.
The cached result sets relevant to database invalidations are
immediately invalidated, and no subsequent OCIStmtExecute() calls can
match such result sets. The OCI statement handles currently fetching
from these cached result sets, at the time such invalidations are
received, can continue fetching from this (invalidated) cached result
set.
The next OCIStmtExecute() call by the process may cache the new result
set if there is space available in the cache. The OCI client result
cache periodically reclaims unused memory.
If a session has a transaction open, OCI ensures that its queries that
reference database objects changed in this transaction go to the
server instead of the client cache.
This consistency mechanism ensures that the OCI cache is always close
to committed database changes. If the OCI application has relatively
frequent calls involving database round-trips due to queries that
cannot be cached, (such as DMLs, OCILob calls, and so on) then these
calls transparently keep the client cache up-to-date with database
changes.
Note that sometimes when a table is modified, a trigger can cause
another table to be modified. OCI client result cache is sensitive to
all such changes.
When the session state is altered, for example, if NLS session
parameters are modified, this can cause the query results to be
different. The OCI result cache is sensitive to such changes and on
subsequent query executions, returns the correct query result set. The
current cached result sets are kept (and not invalidated) for any
other session in the process to match; otherwise, these result sets
get "Ruled" after a while. There are new result sets cached
corresponding to the new session state.
If the application must keep track of all such database and session
changes it can be cumbersome and prone to errors. Hence, OCI result
cache transparently keeps the result sets consistent with any database
or session changes.
The OCI client result cache does not require thread support in the
client.
To understand the benefits of the result cache, look at the Validation of the Client Result Cache of the Oracle Call Interface Programmer's Guide referenced earlier.
Best Answer
There are a variety of factors that would cause IT organizations to be cautious about creating databases and giving business users the level of access to those systems that you are, presumably, asking for when you talk about wanting to "play with" the data.
First off, since you're in a company that does trading, that implies that there are dozens of laws and agencies that regulate the company. In order to comply with those laws, your organization undoubtedly has put together dozens if not hundreds of policy documents that undoubtedly include policy statements that say things like only members of the DBA team have superuser privileges to modify data in databases, only changes that go through the official software development lifecycle are promoted to production, a separation of duties ensures that people that administer the database are different from people that code against the database which are different from people that input and maintain the data. The first step of the many, many audits that such an organization goes through is to check to see whether the policies in those documents matches the actual practice. Finding "rogue" databases that exist outside of these policies is a huge red flag in such an audit. Even if your database didn't actually create any real risk, it would create an audit finding because it violated the agreed-upon policies. Theoretically, the IT organization could work with their regulators to amend the dozens of policies to allow this sort of thing in special cases, but that would likely be a tremendous amount of work.
It is unlikely, though, that regulators would view the sort of risk analysis that you're talking about as the sort of thing that might get a pass from the burden of regulation. The process of building risk models and analyzing risk in a trading business is about as core a concern of regulators as you're going to find. Regulators are going to want someone to be able to explain exactly what sort of analysis is being done, what data sources are being used, how that data is being manipulated, etc. They're going to want to know who has access to that data, how it is backed up, etc.
Second, systems like the one you describe have a tendency to grow over time and often get dumped on IT organizations once they become unwieldy or when the original owners move on. A system that you set up today just for yourself to play with can quickly become a system that your department depends on and then a system that is integrated with all sorts of reporting and workflow processes as time goes on. At some point, though, you'll move on to another company or the system will get slower or someone will realize that some critical bit of the business depends on a system that is running with no backups on some guy's machine and then IT will get the call to own the system. Those projects are generally train wrecks. These systems aren't generally designed well (risk analysts generally come up with better software designs than software developers come up with risk models but both pursuits benefit from expert attention up front), they're not properly documented, etc. They also tend to rely on tons of manual processes that scale acceptably when one business user owns the process and understands in detail what the system is doing and why but that scales incredibly poorly when IT folks are trying to simultaneously manage many different systems that they don't understand in deep detail. IT organizations generally do everything they can to prevent these systems from sprouting in the first place because they turn into such hassles in the end.
Third, if the system that you're building is necessary for you to do your job, then it's likely that it needs the attention of IT. It probably needs to be backed up, for example. It probably needs to be added to various proactive and reactive monitoring scripts/ systems that the DBAs monitor in order to ensure that sufficient disk space is available, that the workload of your system isn't crushing other systems, etc. It probably needs to be part of the disaster recovery plan (if only to note that it's a low priority system to restore). It needs to get added to the set of systems that the DBAs patch when security updates come out or when the enterprise upgrades to new versions of the database. It needs to get added to the support contract so that it doesn't raise issues when the company gets audited by the vendor. These things are generally much harder when IT doesn't own the system. But if IT owns the system, it needs to behave like all the other IT systems-- it needs to be developed by developers, used by users, administered by administrators, it needs to have different environments (dev, test, staging, prod) to support the standard development models, etc.
In most IT organizations, if you need this sort of setup, you would need a project to create it (which would include things like assigning development resources, a project manager, etc.) That project obviously needs to be prioritized, implemented, etc.
If you really want "free reign" to do whatever you want without any of the controls that are put on developers, it's possible that you, your manager, and IT could get together and come up with a reasonable compromise. Perhaps you could be given slightly elevated privileges in some database/ schema somewhere along with restrictions in the types of things you're allowed to do (i.e. nothing from what you're doing can feed any other system, nothing can be used in a production process, etc.) It's not uncommon for analysts to have a "playground" where they can create tables to support ad hoc reporting, for example, with the understanding that anything that needs to become part of a production report needs to get built following the full development lifecycle process.