v$shared_pool_reserved
Hi,
I'm looking at v$shared_pool_reserved view in 9.2.0.6, specifically the columns: -
REQUEST_FAILURES
LAST_FAILURE_SIZE
SQL> select REQUEST_FAILURES,LAST_FAILURE_SIZE from v$shared_pool_reserved;
REQUEST_FAILURES LAST_FAILURE_SIZE
---------------- -----------------
1572 62087712
In the 9.2.0.6 documentation , it states the below.
REQUEST_FAILURES - Number of times that no memory was found to satisfy a request (that is, the number of times the error ORA-04031 occurred)
LAST_FAILURE_SIZE - Request size of the last failed request (that is, the request size for the last ORA-04031 error)
So request_failures on our database looks extremely high (suggesting we need to increased our shared_pool_reserved size), however we have no reported ORA-04031 errors from any applications or in the alert log from failed DBMS jobs. I also notice that these figures fluctuate (up and down) whenever I re-run this query. So I'm wondering what these figures are actually telling us about shared pool reserved? Is something really trying to use a 62M chunk of the reserved shared pool - if so, how can we see what is trying to allocate 62M and why we can see no evidence of processes
I'm looking at v$shared_pool_reserved view in 9.2.0.6, specifically the columns: -
REQUEST_FAILURES
LAST_FAILURE_SIZE
SQL> select REQUEST_FAILURES,LAST_FAILURE_SIZE from v$shared_pool_reserved;
REQUEST_FAILURES LAST_FAILURE_SIZE
---------------- -----------------
1572 62087712
In the 9.2.0.6 documentation , it states the below.
REQUEST_FAILURES - Number of times that no memory was found to satisfy a request (that is, the number of times the error ORA-04031 occurred)
LAST_FAILURE_SIZE - Request size of the last failed request (that is, the request size for the last ORA-04031 error)
So request_failures on our database looks extremely high (suggesting we need to increased our shared_pool_reserved size), however we have no reported ORA-04031 errors from any applications or in the alert log from failed DBMS jobs. I also notice that these figures fluctuate (up and down) whenever I re-run this query. So I'm wondering what these figures are actually telling us about shared pool reserved? Is something really trying to use a 62M chunk of the reserved shared pool - if so, how can we see what is trying to allocate 62M and why we can see no evidence of processes
0