Shared pool issues

Hi,
In recent we are getting shared pool exhaust issue. I am interested to know which objects occupying more share pool.Do we have any queries which can show the most space occupied objects in shared pool
do we have any monitoring tools(or queries) using which we can findout once shared pool usage has gone to 70%.I guess OEM automatically alert this if we confgiure it for
I heard that "alter system flush share_pool" doesn't work properly.there is bug in that.After executing this also it wont release shared pool.Is it true ??
Thanks for your information.
Thanks
Anand

In recent we are getting shared pool exhaust issue. I am interested to know which objects occupying more share pool.Do we have any queries which can show the most space occupied objects in shared poolThis if V$DB_OBJECT_CACHE helps for this.
I heard that "alter system flush share_pool" doesn't work properly.there is bug in that.After executing this also it wont release shared pool.Is it true ??Not sure about the bug, do you have the bug number handy. Also, what do you mean by - "it wont release shared pool"...it doesn't release the entire memory allocated to shared pool.
Thanks
Chandra

Similar Messages

  • Issue with shared pool size while upgrading from 10.2.0.4 to 11.2.0.2

    Hi Team,
    Below is my issue
    I am running dbua as part of the upgrade from 10.2.0.4 to 11.2.0.2. Its almost 59% and nothing is happening on the instance. The logs directory contian the below
    -bash-3.00$ ls -ltr
    total 280
    -rw-r----- 1 ora8014 ems8014 3662 Oct 16 08:58 upgrade.xml
    -rw-r----- 1 ora8014 ems8014 1127 Oct 16 09:00 Upgrade_Directive.log
    -rw-r----- 1 ora8014 ems8014 7452 Oct 16 09:00 mapfile.txt
    -rw-r----- 1 ora8014 ems8014 297 Oct 16 09:04 SpaceUsage.txt
    -rw-r----- 1 ora8014 ems8014 9803 Oct 16 09:04 PreUpgradeResults.html
    -rw-r----- 1 ora8014 ems8014 1572 Oct 16 09:06 PreUpgrade.log
    -rw-r----- 1 ora8014 ems8014 2850 Oct 16 09:06 Oracle_Text.log
    -rw-r----- 1 ora8014 ems8014 157816 Oct 16 09:09 trace.log
    -rw-r----- 1 ora8014 ems8014 71368 Oct 16 09:09 sqls.log
    -rw-r----- 1 ora8014 ems8014 339 Oct 16 09:09 Oracle_Server.log
    -bash-3.00$ date
    Sat Oct 16 22:54:27 PDT 2010
    -bash-3.00$ pwd
    /slot/ems8014/oracle/app/ora8014/cfgtoollogs/dbua/ebs11i10/upgrade1
    It seems its almost more 12 hrs nothing has happened. When I check the oracle_server.log it has the error
    -bash-3.00$ tail Oracle_Server.log
    ERROR at line 1:
    ORA-01034: ORACLE not available
    Process ID: 0
    select count(*) from v$instance
    ERROR at line 1:
    ORA-01034: ORACLE not available
    Process ID: 0
    ORA-00371: not enough shared pool memory, should be atleast 424463564 bytes
    Hence I started the Db in 10g oracle home to check and below is the details.
    SQL> select * from V$SGAINFO;
    NAME BYTES RES
    Fixed SGA Size 1267908 No
    Redo Buffers 11313152 No
    Buffer Cache Size 614400000 Yes
    Shared Pool Size 301989888 Yes
    Large Pool Size 8388608 Yes
    Java Pool Size 67108864 Yes
    Streams Pool Size 50331648 Yes
    Granule Size 4194304 No
    Maximum SGA Size 1056964608 No
    Startup overhead in Shared Pool 188743680 No
    Free SGA Memory Available 0
    11 rows selected.
    I tried to increase the space of shared pool as below
    SQL> ALTER SYSTEM SET shared_pool_size ='301M' SCOPE=MEMORY SID='ebs11i10';
    ALTER SYSTEM SET shared_pool_size ='301M' SCOPE=MEMORY SID='ebs11i10'
    ERROR at line 1:
    ORA-02097: parameter cannot be modified because specified value is invalid
    ORA-04033: Insufficient memory to grow pool
    I am stuck and cant proceed further. Could you please help me on this issue so that I overcome this and proceed further.
    Thanks
    Shyam.

    These are the logs. Could you please let me know which one you want.
    -bash-3.00$ pwd
    /slot/ems8014/oracle/app/ora8014/cfgtoollogs/dbua/ebs11i10/upgrade1
    -bash-3.00$ ls -ltr
    total 280
    -rw-r----- 1 ora8014 ems8014 3662 Oct 16 08:58 upgrade.xml
    -rw-r----- 1 ora8014 ems8014 1127 Oct 16 09:00 Upgrade_Directive.log
    -rw-r----- 1 ora8014 ems8014 7452 Oct 16 09:00 mapfile.txt
    -rw-r----- 1 ora8014 ems8014 297 Oct 16 09:04 SpaceUsage.txt
    -rw-r----- 1 ora8014 ems8014 9803 Oct 16 09:04 PreUpgradeResults.html
    -rw-r----- 1 ora8014 ems8014 1572 Oct 16 09:06 PreUpgrade.log
    -rw-r----- 1 ora8014 ems8014 2850 Oct 16 09:06 Oracle_Text.log
    -rw-r----- 1 ora8014 ems8014 157816 Oct 16 09:09 trace.log
    -rw-r----- 1 ora8014 ems8014 71368 Oct 16 09:09 sqls.log
    -rw-r----- 1 ora8014 ems8014 339 Oct 16 09:09 Oracle_Server.log

  • Shared Pool error in Oracle 10.1.0.5

    Setup : 3-node RAC clustered databases
    OS version : RHEL 4.5
    DB version : 10.1.0.5
    Storage : ASM diskgroups for C/R/D files & archivelogs on SAN box
    applications : no. of OLTP applications running on a separate app server
    We are getting ORA-04031 SHARED POOL MEMORY error . There are three nodes : node1, node2 & node3 each running on RHEL AS4 OS . The sga components are not tuned automatically i mean there is no automated sga tuning or resizing . We have set each SGA component manuallay when required. All the c/r/d files are stored on ASM Diskgroups .
    From last night we are facing the SHARED POOL MEMORY issue . There are number of OLTP applications running at front end and the load is more on node3 . Due to the saturation of shared pool it affected the applications and the CPU utilization on App server was almost 90%. But the CPU utilization on each rac node was just below 30%. The Client's complained slow performance of applications and in fact few user sessions hung up.
    What we found in the alert log is the ORA-04031 shared pool error . Which was casuing the problem and the applications started to work very slowly . For workaround we increased the size of the SHARED_POOL_SIZE parameter as well as we flushed the shared pool memory . Now the applications were running fine. I have also observed that there were 454 INACTIVE sessions in the node3. Will these sessions have any impact on performance?
    But i dont know whether it will be fixed for future as well. But Can anyone suggest me how could i approach for resolving this issue permanently ?
    I know that we are still using 10.1.0.5 release and also one more thing is that the SWAP space in one of the node is 4GB short compared to other two nodes swap space. I cant post you the logs please.Whatever i have observed and done i have posted here.
    Any suggestions will be hugely appreciate. Thanks taking out sometime to helping me out.
    Regards,
    imran khan

    I understand SB and i know that 10gr1 is going to be de-supported in dec,2011. But for atleast we can fix the problem for more two months . There are few critical applications which required minimal downtime but at present the client doesn't want to have any outage. Please help.
    Thanks.

  • Contention for latches related to the shared pool was consuming significant

    We are having performance issue on our database. When I look at the AWR, I see that there is a contention for latches. Below is the AWR Report.
    ADDM Report for Task 'ADDM:1775307360_12808'
    Analysis Period
    AWR snapshot range from 12807 to 12808.
    Time period starts at 10-MAY-11 01.00.15 PM
    Time period ends at 10-MAY-11 02.00.23 PM
    Analysis Target
    Database 'ADVFDWP' with DB ID 1775307360.
    Database version 11.1.0.7.0.
    ADDM performed an analysis of all instances.
    Activity During the Analysis Period
    Total database time was 27827 seconds.
    The average number of active sessions was 7.71.
    Summary of Findings
    Description Active Sessions Recommendations
    Percent of Activity
    1 Shared Pool Latches 6.43 | 83.42 0
    2 Top SQL by DB Time 2.41 | 31.24 3
    3 "Concurrency" Wait Class 2.18 | 28.22 0
    4 PL/SQL Execution 1.53 | 19.86 1
    5 "User I/O" wait Class 1.33 | 17.24 0
    6 Hard Parse 1.24 | 16.14 0
    7 Undersized Buffer Cache .83 | 10.73 0
    8 CPU Usage .7 | 9.02 0
    9 Top SQL By I/O .31 | 4.04 1
    10 Top Segments by I/O .24 | 3.12 1
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Findings and Recommendations
    Finding 1: Shared Pool Latches
    Impact is 6.43 active sessions, 83.42% of total activity.
    Contention for latches related to the shared pool was consuming significant
    database time in some instances.
    Instances that were significantly affected by this finding:
    Number Name Percent Impact ADDM Task Name
    1 ADVFDWP1 99.31 ADDM:1775307360_1_12808
    Check the ADDM analysis of affected instances for recommendations.
    Finding 2: Top SQL by DB Time
    Impact is 2.41 active sessions, 31.24% of total activity.
    SQL statements consuming significant database time were found.
    Recommendation 1: SQL Tuning
    Estimated benefit is 1.07 active sessions, 13.82% of total activity.
    Action
    Run SQL Tuning Advisor on the SQL statement with SQL_ID "fdk73nhpt93a5".
    Related Object
    SQL statement with SQL_ID fdk73nhpt93a5.
    INSERT INTO SFCDM.F_LOAN_PTFL_MOL_SNPSHT SELECT * FROM
    F_LOAN_PTFL_MOL_SNPSHT_STG
    Recommendation 2: SQL Tuning
    Estimated benefit is 1 active sessions, 12.96% of total activity.
    Action
    Tune the PL/SQL block with SQL_ID "7nvgzsgy9ydn9". Refer to the "Tuning
    PL/SQL Applications" chapter of Oracle's "PL/SQL User's Guide and
    Reference".
    Related Object
    SQL statement with SQL_ID 7nvgzsgy9ydn9.
    begin
    insert into SFCDM.F_LOAN_PTFL_MOL_SNPSHT select * from
    F_LOAN_PTFL_MOL_SNPSHT_STG;
    end;
    Recommendation 3: SQL Tuning
    Estimated benefit is .4 active sessions, 5.2% of total activity.
    Action
    Investigate the SQL statement with SQL_ID "fcvfq2gzmxu0t" for possible
    performance improvements.
    Related Object
    SQL statement with SQL_ID fcvfq2gzmxu0t.
    select
    a11.DT_YR_MO DT_YR_MO,
    a11.IND_SCRTZD IND_SCRTZD,
    a13.CD_LNSTAT CD_LNSTAT_INTGRTD,
    sum(a11.CNT_LOAN) WJXBFS1,
    sum(a11.AMT_PART_EOP_UPB) WJXBFS2,
    sum(a11.AMT_LST_VLD_PART_UPB) WJXBFS3
    from
    SFCDM.F_LOAN_PTFL_MOL_SNPSHT
    a11
    join
    SFCDM.D_DETD_LNSTAT_CURR
    a12
    on
    (a11.ID_CYCL_CLOS_DETD_LNSTAT_SRGT = a12.ID_DETD_LNSTAT_SRGT)
    join
    SFCDM.D_LNSTAT_CD
    a13
    on
    (a12.ID_LNSTAT_CD_SRGT = a13.ID_LNSTAT_CD_SRGT)
    join
    SFCDM.D_LOAN_CHARTC_CURR_MINI
    a14
    on
    (a11.ID_LOAN_CHARTC_SRGT = a14.ID_LOAN_CHARTC_SRGT)
    where
    (a11.DT_YR_MO in (201103)
    and a14.CD_SFCRM_LOAN_BUS_LI not in ('L', 'T', 'W')
    and a13.CD_LNSTAT in (14)
    and not exists
    (select * from SFCDM.F_LOAN_PTFL_MOL_SNPSHT s
    where s.id_loan_syst_gend = a11.id_loan_syst_gend
    and s.dt_yr_mo

    It is worth checking the actual size of the shared pool e.g.
    select pool,sum(bytes)/1024/1024/1024 from v$sgastat group by pool;
    the parameters you ahve posted suggest you have set a minimum but no maximum, so it could very large.
    Next up is looking for unhared SQL i.e.
    select column1 from some_table where column2='A_VALUE';
    select column1 from some_table where column2='Another_Value';
    where the code should be using binds instead of literals for security and performance reasons, a simple way to find this is to look in v$sql for sql having the same plan_hash_value but different sql_Ids and compare the sql_fulltext of each statement.
    Also a possibility is sql with many child cursors, this is trickier as the cause may vary and may not be easy to fix. check th econtents of v$sql for sql that have high values in the child_number column anmd investigate the contents of v$sql_shared_cursor for the reason there are multiple child cursors.
    Chris

  • Large shared pool

    I am running a DW application on 11.2.0.1, linux, using AMM. We have 64G memory, of which 45G is (theoretically) allocated to ORACLE.
    I have noticed that the PGA size has increased substantially ( I'd expect this, being a DW with an MDX miiddle ), to about 40G, but I also notice that the SGA has remained static at about 20G (it was 25G). I've ailso noticed that the shared pool has ballooned from a few hundred MB to 7Gb in a matter of months. This is definitely increasing I/O which is unwanted.
    Why does the shared pool get so big ? We are not a high turnover/large user number operation and parse times are a very small proportion of overall query time. Will a flush shrink the shared pool memory allocation or will it jsut clear the space ?

    OK, the allocated PGA will of course increase in response to demand, but I do not believe that the total PGA + SGA will ever break your 45G limit, and never has. I guess OEM is mis-representing something.
    wrt the performance issue, I would question whether the size of the shared pool is in fact impacting on performance. The way I look at it is that no end user ever telphoned the help desk to say "the shared pool is too big" or "disc I/O is excessive". They may telephone to say "my queries are too slow". This throws you into the realm of query tuning, which would be a different topic.
    wrt to memory usage and AMM, I believe that AMM does tend to assign more memory than needed to the shared_pool. If this really is a problem in your instance (and we don't know this yet) then you can set minimum values for the other SGA structures (usually, db_cache_size) to prevent this.
    Hope this helps.
    J.

  • Shared pool request_failures

    Hello,
    Does any one ever faced the problem of REQUEST_FAILURES in shared pool? If yes, please share your experience(s). We have this issue every now and then, and I am just fed up of this alarm. Sometimes request_failures are over thousand.
    This occurs in both 10g (10.2) and 11g DB (11.2.0.3) OS=RHL data guard setup
    SYS@db AS SYSDBA> select request_failures from v$shared_pool_reserved; ---Primary DB
    REQUEST_FAILURES
               52
    SYS@db AS SYSDBA> show parameter shared_pool_reserved_size
    NAME                         TYPE                           VALUE
    shared_pool_reserved_size          big integer                      348966092
    SYS@db AS SYSDBA> select free_space,avg_free_size,used_space,request_failures,requests,max_free_size,request_misses from v$shared_pool_reserved;
    FREE_SPACE AVG_FREE_SIZE USED_SPACE REQUEST_FAILURES   REQUESTS MAX_FREE_SIZE REQUEST_MISSES
    236005496    241314,413    5668264            57           0       6713160             0Thanks a lot.
    Best Regards
    Edited by: K-Saf on Sep 4, 2012 12:46 PM
    Edited by: K-Saf on Sep 4, 2012 12:46 PM
    Edited by: K-Saf on Sep 4, 2012 1:00 PM

    Hello Kuljeet Pal,
    Thanks a lot. Here is the result of your suggested queries. Please have a look and suggest.
    - AS SYSDBA>  SELECT shared_pool_size_for_estimate, estd_lc_size, estd_lc_time_saved FROM v$shared_pool_advice;
    SHARED_POOL_SIZE_FOR_ESTIMATE ESTD_LC_SIZE ESTD_LC_TIME_SAVED
                    2816            455            819115
                    3584           1222            819732
                    4352           1990            824577
                    5120           2758            837826
                    5376           3014            848912
                    5504           3142            854454
                    5632           3270            860003
                    5760           3398            865548
                    5888           3526            871084
                    6016           3653            876620
                    6144           3780            882158
                    6272           3908            887700
                    6400           4036            893245
                    6528           4164            898789
                    6656           4292            904342
                    6784           4420            904351
                    6912           4548            904351
                    7040           4676            904352
                    7168           4804            904353
                    7296           4932            904354
                    7424           5060            904355
                    7552           5188            904356
                    7680           5316            904356
                    7808           5444            904356
                    8192           5828            904356
                    8960           5888            904356
                    9728           5888            904356
                   10496           5888            904356
                   11264           5888            904356
                   12032           5888            904356
                   12800           5888            904356
                   13568           5888            904356
    32 rows selected.
    COMPONENT                 OPER_TYPE       PARAMETER                INITIAL_SIZE TARGET_SIZE FINAL_SIZE STARTED                                                              ENDED
    streams pool                 GROW            streams_pool_size           134217728   268435456     268435456 03-sep-2012:14:07:44                                                         03-sep-2012:14:07:44
    DEFAULT buffer cache            SHRINK            db_cache_size               3,4226E+10  3,4091E+10 3,4091E+10 03-sep-2012:14:07:44                                                         03-sep-2012:14:07:44
    java pool                 STATIC            java_pool_size                     0   134217728     134217728 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    streams pool                 STATIC            streams_pool_size                0   134217728     134217728 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    DEFAULT buffer cache            INITIALIZING    db_cache_size               3,4226E+10  3,4226E+10 3,4226E+10 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:31
    ASM Buffer Cache            STATIC            db_cache_size                     0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    DEFAULT buffer cache            STATIC            db_cache_size                     0  3,4226E+10 3,4226E+10 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    DEFAULT 2K buffer cache        STATIC            db_2k_cache_size                 0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    DEFAULT 4K buffer cache        STATIC            db_4k_cache_size                 0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    DEFAULT 8K buffer cache        STATIC            db_8k_cache_size                 0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    DEFAULT 16K buffer cache       STATIC            db_16k_cache_size                0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    DEFAULT 32K buffer cache       STATIC            db_32k_cache_size                0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    KEEP buffer cache            STATIC            db_keep_cache_size                0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    RECYCLE buffer cache            STATIC            db_recycle_cache_size                0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    shared pool                 STATIC            shared_pool_size                 0  6979321856 6979321856 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    large pool                 STATIC            large_pool_size                     0   134217728     134217728 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
    16 rows selectedBest Regards

  • Shared pool size

    Hi All,
    DB:oracle9iR2
    os:solaris
    how to get the shared_pool usage,free total size and hit ratio in oracle 9i R2?,can any one help to me....
    POOL BYTES MB
    shared pool used :
    shared pool free :
    shared pool (Total):
    =================
    Shared_pool hit ratio:
    thanks.

    Hi All,
    thank you for all the responses..
    Db:oracle 9iR2
    os :solaris
    Actually i am facing below problem..
    prob: ORA-00604: error occurred at recursive SQL level 2
    ORA-04031: unable to allocate 4224 bytes of shared memory ("shared pool","select obj#,type#,ctime,mtim...","sga heap(1,0)","library ca
    che")
    Wed Feb 8 19:33:43 2012
    Errors in file /ora/admin/cddp/bdump/cddp_cjq0_2601.trc:
    ORA-00604: error occurred at recursive SQL level 2
    ORA-04031: unable to allocate 4224 bytes of shared memory ("shared pool","select obj#,type#,ctime,mtim...","sga heap(1,0)","library ca
    che")
    Wed Feb 8 19:33:43 2012
    Errors in file /ora/admin/cddp/bdump/cddp_cjq0_2601.trc:
    ORA-00604: error occurred at recursive SQL level 2
    ORA-04031: unable to allocate 4224 bytes of shared memory ("shared pool","select obj#,type#,ctime,mtim...","sga heap(1,0)","library ca
    che")
    Wed Feb 8 19:33:48 2012
    Errors in file /ora/admin/cddp/bdump/cddp_cjq0_2601.trc:
    ORA-00604: error occurred at recursive SQL level 2
    ORA-04031: unable to allocate 4224 bytes of shared memory ("shared pool","select obj#,type#,ctime,mtim...","sga heap(1,0)","library ca
    che")
    ========================================
    i was running with 200MB size of share pool....couple of days back un expectdly i got above error....for temparory solution i did shared pool flush...
    again nexday same error got repeated....for that i increased shared pool size to 420 MB....
    while monitoring db it is using shared pool memory up to 400MB with avg shared pool hit ratio of 94.5 %..(database started recently)...
    Earlier shared_pool size:200MB
    Now:420 MB
    Avg usage:up to 400MB
    my question is :
    1)if we have many different sql statements in shared pool ..won't
    oracle flush share pool (ie aged out based on LRU or some alogorithm) if any program need memory in shared pool?
    2) Any data Fragmentation will cause@above error?
    3)can any one please explain..... how to check whats going on in Shared_pool(internally)...why it is using 400MB while compare to erlier avg usage 170MB .....any idea...(how to find root cause)..?
    4)will plan table cause any issue ?
    can any one explain to me...
    thanks..
    Edited by: kk001 on Feb 11, 2012 4:54 PM
    Edited by: kk001 on Feb 11, 2012 4:56 PM

  • Flush shared pool

    Hi,
    ALTER SYSTEM FLUSH SHARED POOL;
    when we issue the above command, it will fulsh the shared pool. it means, it will remove all the stored/parsed sql statements from shared pool. if any new query comes, first it has to parse and execute and show it to user.which will take time....
    So, in what scenarios we do flush the shared pool...how do we know there is fragmentation is shared pool....
    i am not experienced Performance Analayist..please share your experience.

    How can you reconcile what you wrote with the above statement from the Oracle docs?Um, because it's true?
    It's realy clear to me that you don't have much job experience with Oracle (also evidence by your hiding your credentials and work history).
    Back before cursor_sharing, the only way to relieve library cache stress was to make the shared_pool very small (see Metaink for the official recommendation), and the same holds true today for systems with ad-hoc query tools that can take-up 90% of the library cache with executions=1.
    BTW, Mr. Morgan, I WANT MY MONEY BACK for your con-job on me.
    When you told me that PSOUG was offering RAC classes, you knew that I believed that you were graciously volunteering a sevice to the community, and that's why you got all of those RAC books for your class at-cost, I wanted to help a good cause.
    Of course, now we know that it was all a ruse, and that you were profiting from the PSOUG training.
    When are you going to pay me back for those books that you conned me out of?
    Message was edited by:
    burleson

  • Increased Shared Pool size longer hot backup time?

    Hello,
    I have hot backup that usually took 2 hours to complete. Then we had to increase Shared pool size from 280Mb to 380Mb due to some performance issue.
    One week after increase of size the hot backup is taking 4 hours to complete. Since there was no other changes to the system I am suspecting size increase
    of Shared Pool from 280Mb to 380Mb might be is reason for such drastic increase of backup time.
    I would like to get your comments on my suspicion to the problem.
    thank you

    Paul.S wrote:
    One week after increase of size the hot backup is taking 4 hours to complete. Since there was no other changes to the system I am suspecting size increase of Shared Pool from 280Mb to 380Mb might be is reason for such drastic increase of backup time.Hmm... at first glance it does not seem that this is the problem.. but perhaps it contributes to it.
    When a SQL hits the SQL engine, the 1st thing the SQL engine does is determine if there is an existing parsed and ready-to-use copy of that SQL. If there is, that existing SQL is re-used - thus the name SQL Shared Pool. The resulting soft parse of the SQL is a lot faster (or should be) than a hard parse . A hard parse is where there is no re-usable copy, and the SQL needs to be parsed, validated and execution plan determined, etc.
    Kind of like re-using an existing compiled program (with different input data) versus compiling that program before using it. (and that is what source SQL is - a program that needs to be compiled).
    Okay, now what happens if there 100's of 1000's of SQLs in your shared pool? The scan that the SQL engine does to determine if there is a re-usable cursor, becomes pretty slow. A soft parse quickly becomes very expensive.
    The problem is typically clients that create SQLs that are not sharable (where the input data is hardcoded into the program, instead of input variables to the program). In other words, SQLs that do not use bind variables.
    Each and every hardcoded SQL that hits the SQL engine, is now a brand new SQL. And requires storage in the SQL Shared Pool. Shared Pool footprint grows and you start getting errors like insufficient shared pool memory.. and increase the shared pool which means even more space to store even more unique non-sharable SQLs and making soft and hard parses even more expensive.
    Like moving the wall a few metres further and then running even faster into it. !http://www.pprune.org/forums/images/smilies2/eusa_wall.gif!
    Now if the backup fires off a load of SQLs against the SQL engine, the fast soft/hard parses can now be a lot slower than previously, thanks to a larger shared pool that now caters for more junk than before.
    Unsure if this is the problem that you are experiencing.. but assuming that your suspicion is correct, it offers an explanation as to why there can be a degradation in performance.

  • Buffer, library,dictionary, shared pool, redo log buffer chache hit ratios

    Can please one provide information and sql queries to calculate Buffer, library,dictionary, shared pool, redo log buffer chache hit ratios and if any other ratio for investigation of performance issues in oracle 10g database (10g.1 and 10g.2 both). thanks in advance.

    In and by themselves most of the standard ratio calculations are useless to misleading. All the ratios should always be considered in relation to other data such as total requests for a resource, existence of any outlying values in the associated events, etc ....
    The proper warning being given then you can find most of the standard ratios mentioned with SQL for their calculation in the Performance and Tuning manual for your version of Oracle.
    HTH -- Mark D Powell --

  • Increase Shared Pool for erorr # ORA-04031

    hi,
    what do i need to look at before i increase the shared pool of our database?
    there is just the one database instance on the machine.
    i am concerned about the repurcussions on the server.
    i hope the information below is of help.
    db version: 10.2.0.1.0
    os: Red Hat Linux 3
    SQL> select name, value from v$parameter where name like '%pool%';
    name value
    shared_pool_size 150994944
    large_pool_size 33554432
    java_pool_size 50331648
    streams_pool_size 0
    shared_pool_reserved_size 10066329
    buffer_pool_keep
    buffer_pool_recycle
    global_context_pool_size
    olap_page_pool_size 0
    thanks,
    santosh sewlal

    Hi Santosh,
    This is what i faced last two days back! Now i am monitoring the Issue! If you got any solutions please let me know how to avoid this!
    ORA-04031 error can be due to either an inadequeate sizing of the SHARED POOL size or due to heavy
    fragmentation leading the database to not finding large enough chuncks of memory.
    You can monitor this with the two events...
    alter system set events '4031 trace name errorstack level 3';
    alter system set events '4031 trace name heapdump level 3';
    Fragmentataion is one of the causes of ora 4031
    Please refer these.
    1.Article-ID: Note 146599.1
    Title: Diagnosing and Resolving Error ORA-04031
    2.Article-ID: Note 62143.1
    Title: Understanding and Tuning the Shared Pool
    3.Article-ID: Note 61623.1
    This is paticular for Oracle 9i Rel 2, Hope the same for Oracle 10 G
    Regards
    Ravi

  • Shared Pool utilisation

    Hello Team:
    I ran a metalink script to report the shared pool utilization recently. I took this output when the database was on peak load.
    SQL> /
    Obj mem: 66435759 bytes (63.36MB)
    Shared sql: 324219036 bytes (309.2MB)
    Cursors: 341207073 bytes (325.4MB)
    Free memory: 67228508 bytes (64.11MB)
    Shared pool utilization (total): 468785754 bytes (447.07MB)
    Shared pool allocation (actual): 754974720bytes (720MB)
    Percentage Utilized: 91%
    does this mean I have to add more space to shared pool. If so what is the threshold value?
    Regards,
    Bala

    Bhawani nandan Prasad - Principal DBA -- See a to z diagnostics about Shared pool
    1. Memory     2
    a. Shared Pool     2
    1. Introduction     2
    2. Architecture     2
    3. Scripts for different DBA tasks:     5
    a.Measure object usage inside the shared pool and Tune shared pool     7
    b.Check reload problem in library cache     12
    c.Find the large queries in the shared pool library cache (using > 4mb each)     13
    d.Find objects that can be considered pining into the shared pool     13
    e.LRU work and objects were loaded and flushed     13
    f.How much are waiting for Library Cache Latch     14
    g.Queries identical but aren’t shared.     14
    h.Get Biggest chunk of free memory.     14
    i.Check the shared pool reserved size status     16
    j.When having multiple subheaps:     16
    k.Check shared pool at first glance quick diagnostics     17
    l.Memory Usage - object list level view     17
    m.Loads Number of times object has been loaded     17
    n.Check number of times and object has been executed     18
    o.Check shared pool in more details     18
    p.Library Cache Statistics     18
    q.Reserve Pool Settings     19
    r.Pinned Objects     19
    s.Finding literal SQL     19
    t.Finding the Library Cache hit ratio     19
    u. Row Cache Misses – Dictionary cache stats     19
    v. Checking hash chain lengths     20
    w. Checking for high version counts     20
    x. Finding statement/s which use lots of shared pool memory     20
    y. Allocations causing shared pool memory to be 'aged' out     21
    z. Issues in various Oracle Releases     21
    4. Terminology     22
    5. Oracle 11g Caching and Pooling – SQL Result Cache     27
    6. References     37
    2. SQL     38
    3. Statistics     38
    4. Wait events     38
    5. Schema     39
    6. General     39
    a. Scripts     39
    1. accept.sql     39
    1. Memory
    a. Shared Pool
    1. Introduction
    Shared pool is used to cache different types of data such as textual and executable forms of PL/SQL blocks and SQL statements, dictionary cache data, and other data in SGA. Additional shared memory needed in the SHARED POOL if using ASM storage. Gathering schema/database stats (table/index stats) makes database query performance better and it reduce utilization of shared pool. Hence, practice to schedule job to gather stats regularly which suites your database performance. If you use shared pool effectively you can reduce resource consumption in at least four ways
    1.     Parse overhead is avoided if the SQL statement is already in the shared pool. This saves CPU resources on the host and elapsed time for the end user.
    2.     Latching resource usage is significantly reduced, which results in greater scalability.
    3.     Shared pool memory requirements are reduced, because all applications use the same pool of SQL statements and dictionary resources.
    4.     I/O resources are saved, because dictionary elements that are in the shared pool do not require disk access.
    This sharable area of memory is managed as a sophisticated cache and heap manager rolled into one. It has 3 fundamental problems to overcome:
    1.     The unit of memory allocation is not a constant - memory allocations from the pool can be anything from a few bytes to many kilobytes
    2.     Not all memory can be 'freed' when a user finishes with it (as is the case in a traditional heap manager) as the aim of the shared pool is to maximize share of information. The information in the memory may be useful to another session - Oracle cannot know in advance if the items will be of any use to anyone else or not.
    3.     There is no disk area to page out to so this is not like a traditional cache where there is a file backing store. Only "rewriteable" information can be discarded from the cache and it has to be re-created when it is next needed.
    Oracle 10g architecture of Shared pool:
    Library Cache     Shared SQL Area (Hash Value, SQL source, Execution plan)
    Data Dictionary Cache
    Enqueues     Fixed Area     Other
    Latches          
    Oracle 11g architecture of Shared pool:
    Library Cache     Shared SQL Area (Hash Value, SQL source, Execution plan)
    Data Dictionary Cache
    Result Cache
    Enqueues     Fixed Area     Other
    Latches          
    1. Library Cache
    Shared Sql Area: contains Parsed SQL and execution Plans for statements already run against the database. This area allows SQL execution plans to be reused by many users.
    Private SQL Area: Private SQL areas are non-shared memory areas assigned to unique user sessions.
    Pl/sql Area: contains the recently executed Procedures, Functions and Packages.
    Control Structures: Common control structure information example Memory for Latches and locks, sequence cache.
    2. Dictionary cache known as the row cache.
    Dictionary cache stores all the metadata info of tables and views in the database, Names and data types of the columns in the database, Object and system privileges of all the Users. Oracle maintains the stats of all the objects in the shared pool, if any of the memory objects are not used from the last 3 seconds, these memory objects will be aged out and will be removed from the cache. All the Shared Pool Structures are maintained by a LRU (least recently Used) algorithm, by which Oracle removes the objects from the shared Pool, until there is enough free space in the shared Pool to keep new Object.
    3. Scripts for different DBA tasks:
    Dictionary Views for shared POOL:
    NON-RAC
    V$DB_CACHE_ADVICE
    V$DB_OBJECT_CACHE
    V$DLM_LATCH
    V$DLM_LOCKS
    V$LATCH
    V$LATCHHOLDER
    V$LATCHNAME
    V$LATCH_CHILDREN
    V$LATCH_MISSES
    V$LATCH_PARENT
    V$LIBRARYCACHE
    V$LOCK
    V$LOCKED_OBJECT
    V$LOCKS_WITH_COLLISIONS
    V$LOCK_ACTIVITY
    V$LOCK_ELEMENT
    V$OPEN_CURSOR
    V$PROCESS
    V$PX_PROCESS
    V$PX_PROCESS_SYSSTAT
    V$PX_SESSION
    V$PX_SESSTAT
    V$ROWCACHE
    V$ROWCACHE_PARENT
    V$ROWCACHE_SUBORDINATE
    V$SESSION
    V$SESSION_CONNECT_INFO
    V$SESSION_CURSOR_CACHE
    V$SESSION_EVENT
    V$SESSION_LONGOPS
    V$SESSION_OBJECT_CACHE
    V$SESSION_WAIT
    V$SESSTAT
    V$SESS_IO
    V$SGA
    V$SGASTAT
    V$SGAINFO
    V$SGA_DYAMIC_COMPONENTS
    V$SGA_DYNAMIC_FREE_MEMORY
    V$SGA_RESIZE_OPS
    V$SGA_CURRENT_RESIZE_OPS
    v$shared_pool_advice
    V_$SHARED_POOL_ADVICE
    V$SHARED_POOL_RESERVED
    V$SHARED_SERVER
    V$SORT_SEGMENT
    V$SORT_USAGE
    V$SQL
    V$SQLAREA
    V$SQLTEXT
    V$SQLTEXT_WITH_NEWLINES
    V$SQL_BIND_DATA
    V$SQL_BIND_METADATA
    V$SQL_CURSOR
    V$SQL_SHARED_CURSOR
    V$SQL_SHARED_MEMORY
    V$STATNAME
    V$SUBCACHE
    V$SYSSTAT
    V$SYSTEM_CURSOR_CACHE
    V$SYSTEM_EVENT
    V$SYSTEM_PARAMETER
    X$KSMSP
    RAC
    GV$LATCH
    GV$LATCHHOLDER
    GV$LATCHNAME
    GV$LATCH_CHILDREN
    GV$LATCH_MISSES
    GV$LATCH_PARENT
    GV$LIBRARYCACHE
    GV$LOCK
    GV$LOCKED_OBJECT
    GV$LOCKS_WITH_COLLISIONS
    GV$LOCK_ACTIVITY
    GV$LOCK_ELEMENT
    GV$PROCESS
    GV$PX_PROCESS
    GV$PX_PROCESS_SYSSTAT
    GV$PX_SESSION
    GV$PX_SESSTAT
    GV$ROWCACHE
    GV$ROWCACHE_PARENT
    GV$ROWCACHE_SUBORDINATE
    GV$SESSION
    GV$SESSION_CONNECT_INFO
    GV$SESSION_CURSOR_CACHE
    GV$SESSION_EVENT
    GV$SESSION_LONGOPS
    GV$SESSION_OBJECT_CACHE
    GV$SESSION_WAIT
    GV$SESSTAT
    GV$SESS_IO
    GV$SGA
    GV$SGASTAT
    gv$shared_pool_advice
    GV$SHARED_POOL_RESERVED
    GV$SHARED_SERVER
    GV$SORT_SEGMENT
    GV$SORT_USAGE
    GV$SQL
    GV$SQLAREA
    GV$SQLTEXT
    GV$SQLTEXT_WITH_NEWLINES
    GV$SQL_BIND_DATA
    GV$SQL_BIND_METADATA
    GV$SQL_CURSOR
    GV$SQL_SHARED_CURSOR
    GV$SQL_SHARED_MEMORY
    GV$STATNAME
    GV$SUBCACHE
    GV$SYSSTAT
    GV$SYSTEM_CURSOR_CACHE
    GV$SYSTEM_EVENT
    GV$SYSTEM_PARAMETER
    GV$WAITSTAT
    GV$_LOCK
    a.Measure object usage inside the shared pool and Tune shared pool
    set pagesize 132
    column owner format a16
    column name format a36
    column sharable_mem format 999,999,999
    column executions format 999,999,999
    prompt
    prompt Memory Usage of Shared Pool Order - Biggest First
    prompt
    column name format 45
    select owner, name||' - '||type name, sharable_mem from v$db_object_cache
    where sharable_mem > 10000
    and type in ('PACKAGE', 'PACKAGE BODY', 'FUNCTION', 'PROCEDURE')
    order by sharable_mem desc
    prompt
    prompt Loads into Shared Pool - Most Loads First
    prompt
    select owner, name||' - '||type name, loads , sharable_mem from v$db_object_cache
    where loads > 3
    and type in ('PACKAGE', 'PACKAGE BODY', 'FUNCTION', 'PROCEDURE')
    order by loads desc
    prompt
    prompt Executions of Objects in the Shared Pool - Most Executions First
    prompt
    select owner, name||' - '||type name, executions from v$db_object_cache
    where executions > 100
    and type in ('PACKAGE', 'PACKAGE BODY', 'FUNCTION', 'PROCEDURE')
    order by executions desc
    select 'If the values for the EXEC and LOADS close increase SHARED_POOL_SIZE!' from dual ;
    set feedback off
    set linesize 80
    set pagesize 52
    clear columns
    clear breaks
    col executions HEADING EXEC
    col sharable_mem heading SHAMEM
    col owner format a8
    col name format a30
    col type format a12
    set numwidth 8
    ttitle center 'Data Base Objects Owned by All Users Statistics' skip 2
    select name, type, sharable_mem, loads, executions, pins
    from sys.v_$db_object_cache ;
    b.Check reload problem in library cache
    select namespace, pins, reloads from v$librarycache;
    show parameters shared_pool
    select bytes/1024/1024 from v$sgastat where pool='shared pool' and name='free memory';
    c.Find the large queries in the shared pool library cache (using > 4mb each)
    SELECT sql_text "Stmt", count(*), sum(sharable_mem) "Mem",
    sum(users_opening) "Open", sum(executions) "Exec"
    FROM v$sql GROUP BY sql_text HAVING sum(sharable_mem) > 4096000;
    d.Find objects that can be considered pining into the shared pool
    column name format a40
    column owner format a15
    select owner, name, executions, locks, pins, loads, kept from v$db_object_cache where loads > 10;
    create temp table and insert records of candidates to be pinned.
    CREATE TABLE LRU_TMP AS SELECT * FROM X$KSMLRU;
    INSERT INTO LRU_TMP SELECT * FROM X$KSMLRU;
    Use the LRU_TMP table for analysis.
    SELECT USERNAME, KSMLRCOM, KSMLRHON, KSMLRNUM, KSMLRSIZ, SQL_TEXT
    FROM V$SQLAREA A, LRU_TMP K, V$SESSION S WHERE KSMLRSIZ > 3000
    AND A.ADDRESS=S.SQL_ADDRESS AND A.HASH_VALUE = S.SQL_HASH_VALUE
    AND SADDR=KSMLRSES;
    You can see the candidates to pin from the query below
    COL STORED_OBJECT FORMAT A40;
    COL SQ_EXECUTIONS FORMAT 999,999;
    SELECT /*+ ORDERED USE_HASH(D) USE_HASH(C) */ O.KGLNAOWN||’.'||O.KGLNAOBJ STORED_OBJECT, SUM(C.KGLHDEXC) SQL_EXECUTIONS
    FROM SYS.X$KGLOB O, SYS.X$KGLRD D, SYS.X$KGLCURSOR C
    WHERE
    O.INST_ID = USERENV(’INSTANCE’) AND
    D.INST_ID = USERENV(’INSTANCE’) AND
    C.INST_ID = USERENV(’INSTANCE’) AND
    O.KGLOBTYP IN (7, 8, 9, 11, 12) AND
    D.KGLHDCDR = O.KGLHDADR AND
    C.KGLHDPAR = D.KGLRDHDL
    GROUP BY O.KGLNAOWN, O.KGLNAOBJ
    HAVING SUM(C.KGLHDEXC) > 0
    ORDER BY 2 DESC;
    How to pin object
    EXECUTE SYS.DBMS_SHARED_POOL.SIZES(150);
    EXECUTE SYS.DBMS_SHARED_POOL.KEEP('SYS.STANDARD');
    EXECUTE SYS.DBMS_SHARED_POOL.UNKEEP('SYS.STANDARD');
    e.LRU work and objects were loaded and flushed
    LRU work in the shared pool KSMLRNUM stores the number of objects that were flushed to load the large object. KSMLRISZ stores the size of the object that was loaded (contiguous memory allocated)
    column ksmlrcom format a20
    column username format a5
    select username,sid,KSMLRCOM,KSMLRSIZ,KSMLRNUM, KSMLRHON, KSMLROHV, KSMLRSES from x$ksmlru , v$session where KSMLRSES=SADDR and KSMLRNUM >2 ;
    f.How much are waiting for Library Cache Latch
    select count(*),event from v$session_wait where event not like '%SQL%' and event not like '%ipc%' and event not like '%timer%' GROUP BY EVENT;
    select count(*),wait_time from v$session_wait where event='latch free' and p2=106 group by wait_time;
    select sid,wait_time,seconds_in_wait from v$session_wait where event='latch free' and p2=106 and WAIT_TIME>1;
    g.Queries identical but aren’t shared.
    SELECT address, hash_value, version_count , users_opening , users_executing,
    substr(sql_text,1,240) "SQL" FROM v$sqlarea WHERE version_count > 10;
    h.Get Biggest chunk of free memory.
    select sysdate, decode( sign(ksmchsiz - 812), -1, (ksmchsiz - 16) / 4,
    decode(sign(ksmchsiz - 4012),-1, trunc((ksmchsiz + 11924) / 64),
    decode(sign(ksmchsiz - 65548), -1, trunc(1/log(ksmchsiz - 11, 2)) + 238,254))) bucket,
    sum(ksmchsiz) free_space, count(*) free_chunks, trunc(avg(ksmchsiz)) average_size,
    max(ksmchsiz) biggest from x$ksmsp
    where inst_id = userenv('Instance') and ksmchcls = 'free' group by
    decode(sign(ksmchsiz - 812),-1, (ksmchsiz - 16) / 4,
    decode(sign(ksmchsiz - 4012),-1, trunc((ksmchsiz + 11924) / 64),
    decode(sign(ksmchsiz - 65548),-1, trunc(1/log(ksmchsiz - 11, 2)) + 238,254 ))) ;
    SELECT KSMCHCLS CLASS, COUNT(KSMCHCLS) NUM, SUM(KSMCHSIZ) SIZ,
    To_char( ((SUM(KSMCHSIZ)/COUNT(KSMCHCLS)/1024)),’999,999.00′)||’k’ “AVG SIZE”
    FROM X$KSMSP GROUP BY KSMCHCLS;
    CLASS     NUM     SIZ     AVG SIZE
    freeabl     19010     34519404     1.77k
    recr     23581     24967956     1.03k
    R-freea     68     1632     .02k
    perm     22     39801268     1,766.75k
    R-free     34     7238192     207.90k
    free     2389     36075980     14.75k
    Watch for trends using these guidelines:
    a) if ‘free’ memory is low (less than 5mb or so) you may need to increase the shared_pool_size and shared_pool_reserved_size. You should expect ‘free’ memory to increase and decrease over time. Seeing trends where ‘free’ memory decreases consistently is not necessarily a problem, but seeing consistent spikes up and down could be a problem.
    b) if ‘freeable’ or ‘perm’ memory continually grows then it is possible you are seeing a memory bug.
    c) if ‘freeabl’ and ‘recr’ memory classes are always huge, this indicates that you have a lot of cursor info stored that is not releasing.
    d) if ‘free’ memory is huge but you are still getting 4031 errors, the problem is likely reloads and invalids in the library cache causing fragmentation.
    -Note says that this query can hang database on HP platforms
    See the shared pool parameters
    column name format a30
    select name,value from v$parameter where name like '%shared_pool%' ;
    select x.ksppinm, y.ksppstvl from x$ksppi x , x$ksppcv y where x.indx = y.indx and lower(x.ksppinm) like '%spin%';
    SELECT count(*) FROM v$latch_children WHERE NAME = 'library cache';
    Shrinking and growing operations from V$SGA_RESIZE_OPS dynamic view:
    select to_char(end_time, ‘dd-Mon-yyyy hh24:mi’) end, oper_type, initial_size, target_size, final_size from V$SGA_RESIZE_OPS where component=’shared pool’ order by end;
    #shared_pool_summary.sql -get an overview of chunks in the shared pool
    select
    ksmchcom contents,
    count(*) chunks,
    sum(decode(ksmchcls, 'recr', ksmchsiz)) recreatable,
    sum(decode(ksmchcls, 'freeabl', ksmchsiz)) freeable,
    sum(ksmchsiz) total
    from
    sys.x_$ksmsp
    where
    inst_id = userenv('Instance') and
    ksmchcls not like 'R%'
    group by
    ksmchcom
    #reserved_pool_summary.sql - get an overview of chunks in the reserved pool
    select
    ksmchcom contents,
    count(*) chunks,
    sum(decode(ksmchcls, 'R-recr', ksmchsiz)) recreatable,
    sum(decode(ksmchcls, 'R-freea', ksmchsiz)) freeable,
    sum(ksmchsiz) total
    from
    sys.x_$ksmspr
    where
    inst_id = userenv('Instance')
    group by
    ksmchcom
    #save_sqlplus_settings.sql -reset sqlplus settings
    set termout off
    store set sqlplus_settings replace
    clear breaks
    clear columns
    clear computes
    set feedback off
    set verify off
    set termout on
    set define "&"
    #restore_sqlplus_settings.sql -reset sqlplus settings
    set termout off
    @sqlplus_settings
    clear breaks
    clear columns
    clear computes
    set termout on
    i.Check the shared pool reserved size status
    SELECT free_space, avg_free_size, used_space, avg_used_size, REQUEST_MISSES, request_failures, last_miss_size FROM v$shared_pool_reserved;
    An ORA-04031 error referencing large failed requests, indicates the Reserved Area is too fragmented. The reserved pool is small when: REQUEST_FAILURES > 0 (and increasing), The DBA should Increase shared_pool_reserved_size and shared_pool_size together. It is possible that too much memory has been allocated to the reserved list. The DBA should Decrease shared_pool_reserved_size, If: REQUEST_MISS = 0 or not increasing
    FREE_MEMORY = > 50% of shared_pool_reserved_size minimum
    col free_space for 999,999,999,999 head “TOTAL FREE”
    col avg_free_size for 999,999,999,999 head “AVERAGE|CHUNK SIZE
    col free_count for 999,999,999,999 head “COUNT”
    col request_misses for 999,999,999,999 head “REQUEST|MISSES
    col request_failures for 999,999,999,999 head “REQUEST|FAILURES”
    col max_free_size for 999,999,999,999 head “LARGEST CHUNK”
    select free_space, avg_free_size, free_count, max_free_size, request_misses, request_failures from v$shared_pool_reserved;
    TOTAL FREE     AVERAGE
    CHUNK SIZE     COUNT     LARGEST CHUNK     REQUEST
    MISSES     REQUEST
    FAILURES
    7,238,192     212,888     34     212,888     0     0
    You should also use hidden and unsupported parameter “_shared_pool_reserved_pct” to control reserved pool. This parameter controls the allocated percentage of shared pool for reserved pool. By default it is %5 of the shared pool and if you use ASMM for memory management you can set this value higher like 10 to allocate reserved pool dynamically. When you set the parameter you will see the shared_pool_reserved_size parameter will be adjusted to the new setting. The parameter can not be modified when instance is started. You can use the query below to see the current value
    select a.ksppinm “Parameter”, b.ksppstvl “Session Value”, c.ksppstvl “Instance Value” from sys.x$ksppi a, sys.x$ksppcv b, sys.x$ksppsv c where a.indx = b.indx and a.indx = c.indx and a.ksppinm = ‘_shared_pool_reserved_pct’;
    Parameter     Session Value     Instance Value
    sharedpool_reserved_pct     10     10
    j.When having multiple subheaps:
    select KSMCHIDX, ksmchcom ChunkComment,
    decode(round(ksmchsiz/1000),0,'0-1K', 1,'1-2K', 2,'2-3K', 3,'3-4K',4,'4-5K',5,'5-6k',6,'6-7k',7,'7-8k',8,'8-9k', 9,'9-10k', '> 10K'), count(*), ksmchcls Status, sum(ksmchsiz) Bytes
    from x$ksmsp where KSMCHCOM = 'free memory' group by KSMCHIDX,ksmchcom, ksmchcls, decode(round(ksmchsiz/1000),0,'0-1K', 1,'1-2K', 2,'2-3K', 3,'3-4K',4,'4-5K',5,'5-6k',6,'6-7k',7,'7-8k',8,'8-9k', 9,'9-10k','> 10K');
    SubPool     SGA_HEAP     CHUNKCOMMENT     size     COUNT(*)     STATUS     BYTES
    1     sga heap(1,0)     free memory     > 10K     34     R-free     7238192
    1     sga heap(1,0)     free memory     3-4K     2     free     6284
    1     sga heap(1,0)     free memory     > 10K     241     free     35707400
    1     sga heap(1,0)     free memory     8-9k     1     free     7712
    1     sga heap(1,0)     free memory     2-3K     4     free     6752
    1     sga heap(1,0)     free memory     0-1K     2090     free     133288
    1     sga heap(1,0)     free memory     9-10k     21     free     188676
    1     sga heap(1,0)     free memory     1-2K     30     free     25868
    If you see lack of large chunks it is possible that you can face with ORA-04031 in near future.
    k.Check shared pool at first glance quick diagnostics
    select 'You may need to increase the SHARED_POOL_RESERVED_SIZE' Description, 'Request Failures = '||REQUEST_FAILURES Logic
    from      v$shared_pool_reserved where      REQUEST_FAILURES > 0
    and      0 != (select      to_number(VALUE) from      v$parameter
    where      NAME = 'shared_pool_reserved_size')
    union
    select 'You may be able to decrease the SHARED_POOL_RESERVED_SIZE' Description,'Request Failures = '||REQUEST_FAILURES Logic
    from      v$shared_pool_reserved where      REQUEST_FAILURES < 5
    and      0 != (select      to_number(VALUE) from      v$parameter
         where      NAME = 'shared_pool_reserved_size')
    l.Memory Usage - object list level view
    •     Owner - Owner of the object
    •     Object - Name/namespace of the object
    •     Sharable Memory - Amount of sharable memory in the shared pool consumed by the object
    select OWNER, NAME||' - '||TYPE object,SHARABLE_MEM
    from      v$db_object_cache where SHARABLE_MEM > 10000
    and     type in ('PACKAGE','PACKAGE BODY','FUNCTION','PROCEDURE')
    order by owner asc ,SHARABLE_MEM desc
    SELECT * FROM (SELECT ROW_NUMBER () over (PARTITION BY NAMESPACE ORDER BY SHARABLE_MEM DESC) ROW_within , NAMESPACE, SHARABLE_MEM, SUBSTR(NAME,1,40) NAME FROM V$DB_OBJECT_CACHE ORDER BY SHARABLE_MEM DESC) WHERE ROW_WITHIN <= 2 ORDER BY NAMESPACE, ROW_WITHIN;
    ROW_WITHIN NAMESPACE SHARABLE_MEM NAME
    1 CLUSTER 2794 C_OBJ#_INTCOL#
    2 CLUSTER 1684 SMON_SCN_TO_TIME
    1 RSRCPLAN 5117 SYS_GROUP

  • Uanble to drop table/ flush shared pool

    I have a table that I'm not able to drop. When I query for this table, it exists. But when I try to drop it, I kept getting a "table does not exists". Someone suggested that I flush the shared pool. I didn't want to do this but I had to in order to drop this table. It worked but I'm not comfortable with this method.
    Is there a better way to do this ?

    Flushing the shared pool will mean nothing when deleting a table. It will only clear the memory reserved for the recently used cursors, but it won wipe your table away.
    Please post the exact command you issue, it could either be a synonym what you are trying to drop or it could be a table spelled in a mix with upper/lowercase letters.
    ~ Madrid
    http://hrivera99.blogspot.com/

  • Oracle 9i shared memory issue

    Below mentioned is the error raised during retrieval of content details from XMLDB
    StatementCallback; uncategorized SQLException for SQL [Select count(1) from BRSK.medv_brpubdoc_tab e where extractValue(value(e),'/brpubdoc/relationdoc/@document_number')='BR-RELATE-100002-TEST']; SQL state [61000]; error code [4031]; ORA-04031: unable to allocate 3286464 bytes of shared memory ("shared pool","Select count(1) from BRSK.me...","sql area","kkdoattds : qcdogtld").
    We faced the similar during registration of schema and to resolve the issue we did the below mentioned changes towards the oracle 9i database instance (Onsite)
    1) increased shared_pool_reserved_size from 8M to 16M,
    2) java_pool_size from 150M to 200M
    3) db_cache_size from 300M to 350M.
    4) increased shared_pool_size from 150M to 250M.
    we are facing this error frequently.Would like to know about the required parameter values related to memory that need to be configured for xml db.Please help me out on this ASAP.
    Thanks
    Srinivas

    Be aware that you could be hitting a bug. Because 9i is not supported anymore I would suggest to upgrade to 10.2.0.3
    Don't be afraid to increase you memory structures a little bit more ;-)
    What do you thing about a shared_pool_size of >= 500 Mb.
    What database version are you working with?

  • Oracle shared pool fragmentation

    We are running Identity Manager 7.0 using an Oracle database repository. We've been seeing shared pool fragmentation in the database resulting in various java.io.IOException: ORA-00600: internal error code messages when using bulk actions to create and remove accounts. Flushing the oracle shared pool is the only way we've found to clear these errors. Has anyone run into similar problems and found any solution other than increasing the size of the shared pool and issuing an 'alter system flush shared_pool' command periodically?

    Scott Heaton wrote:
    We have an application running WebLogic 5.1 against an Oracle 8.1.7.4 database
    and are seeing very rapid fragmentation of the Oracle database shared pool, ultimately
    resulting in an ORA-04031 error (unable to allocate xxxx bytes of shared memory).
    I'm curious if there are are known issues with WebLogic 5.1 regarding the database
    shared pool, retaining a handle to SQL statements issues (so that they cannot
    be released), or anything similar? Thanks.What sp level of 5.1? We are caching prepared statements in the later versions,
    so for every pooled connection there will be up to 10 (or whatever cache size
    you set) prepared statements cached for re-use, and each of these will retain
    a DBMS-side cursor. I am not an oracle DBA so I don't know if this relates directly
    to the shared pool fragmentation...
    Joe

Maybe you are looking for