Db_CACHE_SIZE

I have it set to 0 which just show that I use it.
This is the output I have now:
select id,name,block_size, current_size,buffers from v$buffer_pool;
3,DEFAULT,8192,4656,578508;
My SGA is 6G.
what will be the optimum size I could resize this parameter to?
Thanks,

Hi
USE v$db_cahce_advice for setting db_cache_size parameter
but this view is available on 9.2 onwards.
Thanks and Regards
Kuljeet Pal Singh

Similar Messages

  • Buffer Qua is 60 % , incre the sga_max_size and db_cache_size on wht basis

    Dear All,
                        In our XI Production system, data buffer quality is 60%, as i found out that sga_max_size(1.1 GB) and db_cache_size(570 MB) not set as per the standard, and also they are less when compared with development(8 GB RAM).
                                                 Our RAM size in PRD is 10 GB,and when i see in topas 90% of RAM is filled, if we increase these parameter by 1GB, i think System's overall  perform will be effected as the total RAM will be filled. Please suggest me how to solve the problem and on what basis these parameters should be set(what percent of RAM).
    OS : AIX 5.3
    SAP XI 7.00
    DB : Oracle
    Please inform whether i have to include any other info
    Regards,
    Balaji Vedagiri

    a) Why was it changed to less than default? Was the purpose to give memory to Java stacks?
    Ans: These parameters are set long back
    tell me how much RAM memory does the ABAP+JAVA stack occupy(minimum), as 90% of  RAM  is filled now.
    b) Is there a performance issue now, XI is not a database heavy applicaton? If not why bother?
    Ans:  Currently there are not performance issues, but in EWA report it is RED and my customer wants it to increase the quality to atleast by 90%.
    c) Why not change it back to default or to the same as QA?
    Ans: As my analysis we need to increae the parameters by 1GB both means, the remaining RAM(1GB) will be filled means, my total RAM will filled this will lead to overall performance problem.
    Regards
    Balaji Vedagiri

  • Slow query - db_cache_size ?

    Hi,
    Oracle 9.2.0.5.0 ( solaris )
    I've got a query which when run on a production machine runs very slow ( 10 hours ), but on a preproduction machine ( with same data ) takes about a 10th of the time. I have confirmed that on both machines we are getting the same plan.
    The only thing I can nail it down to, is that in production I'm seeing lots more "db file sequential read" wait events. Can I assume this is due to the blocks not being in/staying in the cache?
    When running on preprod, the hit ratio for the query is .90 + , on production it drops down to .70 - .80 ( as per query below )
    I have plenty of memory available on the machine, would it be wise to size up the caches? db_cache_size, db_keep_cache_size, db_recycle_cache_size ?
       SELECT (P1.value + P2.value - P3.value) / (P1.value + P2.value)
         FROM   v$sesstat P1, v$statname N1, v$sesstat P2, v$statname N2,
                v$sesstat P3, v$statname N3
         WHERE  N1.name = 'db block gets'
         AND    P1.statistic# = N1.statistic#
         AND    P1.sid = &sid
         AND    N2.name = 'consistent gets'
         AND    P2.statistic# = N2.statistic#
         AND    P2.sid = P1.sid
         AND    N3.name = 'physical reads'
         AND    P3.statistic# = N3.statistic#
         AND    P3.sid = P1.sid
    PRE-PRODUCTION
      call     count       cpu    elapsed       disk      query    current        rows   
      Parse        1      0.64       0.64          0          0          0           0      
      Execute      1      0.00       0.00          0          0          0           0      
      Fetch        2    186.92     329.88     162174    5144281          5           1      
      total        4    187.56     330.53     162174    5144281          5           1      
      Elapsed times include waiting on following events:
        Event waited on                             Times   Max. Wait  Total Waited
        ----------------------------------------   Waited  ----------  ------------
        SQL*Net message to client                       2        0.00          0.00
        db file sequential read                    160098        1.44        162.52
        db file scattered read                          1        0.00          0.00
        direct path write                              27        0.66          3.36
        direct path read                               97        0.00          0.02
        SQL*Net message from client                     2      985.79        985.79
    PRODUCTION
      call     count       cpu    elapsed       disk      query    current        rows
      Parse        1      2.41       2.34         79         16          0           0  
      Execute      1      0.00       0.00          0          0          0           0  
      Fetch        2    844.76   12305.06    1507519    5226663          0           1  
      total        4    847.17   12307.41    1507598    5226679          0           1  
      Elapsed times include waiting on following events:
        Event waited on                             Times   Max. Wait  Total Waited
        ----------------------------------------   Waited  ----------  ------------
        SQL*Net message to client                       2        0.00          0.00
        db file sequential read                   1502104        4.40      11849.13
        direct path write                             361        0.57          3.06
        direct path read                              361        0.05          0.88
        buffer busy waits                              36        0.02          0.17
        latch free                                      5        0.01          0.01
        log buffer space                                2        1.00          1.37
        SQL*Net message from client                     2      687.95        687.95
      Suggestions for further investigation more than welcome.

    user12044475 wrote:
    Hi,
    Oracle 9.2.0.5.0 ( solaris )
    I've got a query which when run on a production machine runs very slow ( 10 hours ), but on a preproduction machine ( with same data ) takes about a 10th of the time. I have confirmed that on both machines we are getting the same plan.
    The only thing I can nail it down to, is that in production I'm seeing lots more "db file sequential read" wait events. Can I assume this is due to the blocks not being in/staying in the cache?
    There are more physical reads, and the average read time is longer. This may simply be a reflection of the fact that other people are working on the production database at the same time and (a) kicking your data out of the cache and (b) causing you to queue at the disc as they do their I/O. A larger cache MIGHT protect your data a little longer, and MAY reduce their I/O at the same time so that the I/Os are faster - but we have no idea what side effects might then appear.
    It's also worth considering whether you did something as you tranferred the data from production to pre-production that helped to improve query performance. (As a simple example, an export/import could have eliminated a lot of row migration - and the nature of your plan means you MIGHT be suffering a lot of excess I/O from "table fetch continued row"). So, how did you get the data from production to test, how long ago, what's happened to it since, and do you have any session statistics taken as you ran the two queries ?
    Since your execution plan (prediction) is a long way off the actual run time, though, (even on the pre-production system), it's probably more important to work out whether you can make your query much more efficient before you make any dramatic changes to the system. I notice that you have three existences subqueries that appear at the end of the plan - such subqueries wreck the optimizer's arithmetic in your version of Oracle and can make it do very silly things. (See for example this blog note: http://jonathanlewis.wordpress.com/2006/11/08/subquery-selectivity )
    The effect of the subqueries may (for example) be why you have a full tablescan on the second table in a nested loop join at one point in your query. The expectation of a vastly reduced number of rows may be why you are seeing nested loops all over the place when (possibly) a couple of hash joins would be more appropriate.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
    There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
    +"I believe in evidence. I believe in observation, measurement, and reasoning, confirmed by independent observers. I'll believe anything, no matter how wild and ridiculous, if there is evidence for it. The wilder and more ridiculous something is, however, the firmer and more solid the evidence will have to be."+
    Isaac Asimov                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • Oracle 9.2.0.8 , decrease db_cache_size ,but OS hasn't freed those memory

    hi,
    anyone ever had the same expierence as me , succeeded in alter system set db_cache_size to a smaller value , and query from v$buffer_pool shows clearly it's in effect now ,
    but , somehow , OS memory utiliztion are still as high as before .
    anyway to release those memory ?
    is it a must to restart the instance ?

    Are you not using oradism utility ? What is your platform ?
    If its sun solaris + 9i, then i have experienced this before if you set SGA_MAX_SIZE parameter. What happens is say your SGA_MAX_SIZE is 4GB and your DB_CACHE_SIZE is 512MB initially. Oracle locks the 4GB into physical memory initially. The oradism utility locks only whats "currently" allocated into physical memory and allocates the rest from swap.

  • Sizing DB_CACHE_SIZE and SHARED_POOL_SIZE

    Hello, is the a good rule to use when sizing DB_CACHE_SIZE and SHARED_POOL_SIZE is terms of a percentage of the total memory you are allocating to Oracle?
    For example I have used the following:
    I take 70% of the total memory on the machine and allocate it to Oracle.
    70% to DB_CACHE_SIZE
    30% to SHARED_POOL_SIZE
    I am looking for the best way to do this as a starting point. Thank you.
    David

    Hi,
    Database concepts
    Database Administrator guide
    Oracle Reference
    are some of the online books.
    You may refer to
    http://www.oracle.com/pls/db92/db92.docindex?remark=homepage
    Also check the documentation for statspack and try installing statspack on your system and see the reports, to identify the bottelnecks and resolve the problems.
    Performance tuning will be a continuous activity till you have a tuned stable system. As other member said, there are no golden rules for the pool sizes.
    Regards,
    Badri.

  • (9I) DYNAMIC SGA : SGA_MAX_SIZE, DB_CACHE_SIZE, DB_KEEP_CACHE_SIZE

    제품 : ORACLE SERVER
    작성날짜 : 2005-01-05
    (9I) DYNAMIC SGA : SGA_MAX_SIZE, DB_CACHE_SIZE, DB_KEEP_CACHE_SIZE
    ==================================================================
    PURPOSE
    Oracle 9i의 새 기능인 동적으로 SGA 파라미터들을 변경하는 방법에
    대하여 알아보기로 한다.
    Explanation
    Oracle 8i까지는 Buffer Cache, Shared Pool, Large Pool 등과 같은 SGA
    파라미터들에 대해 그 크기를 동적으로, db가 운영 중인 상태에서는 변경할
    수가 없었다.
    즉, 이러한 파라미터들을 변경하려면 db를 shutdown하고 initSID.ora 화일에
    서 그 크기를 다시 설정하고, 이 파라미터를 이용해서 db 인스턴스를 restart
    해야만 했었다.
    Oracle 9i에서는 DBA가 ALTER SYSTEM 명령을 이용해서 SGA 파라미터의 크기
    를 동적으로 변경할 수 있게 되었다. 이 특정을 'Dynamic SGA'라고 부른다.
    SGA 전체의 최대 크기(SGA_MAX_SIZE)를 정의하고 그 한도 내에서 파라미터의
    크기를 변경할 수 있는 것이다. 데이타베이스를 shutdown/startup 없이 작업
    이 가능하기 때문에 'Planned Downtime'을 줄이는 한 방법으로도 이해할 수
    있다.
    이 글에서는 SGA에 할당할 수 있는 최소 단위인 'Granule'의 개념을 살펴보
    고, 이 granule이 어떠한 방법에 의해 동적으로 할당되는지에 대해 알아보고
    자 한다.
    또한 Buffer Cache 파라미터 중 새로운 것과 이전 버전에 비해 달라진 내용
    을 소개하기로 한다.
    1. Granule
    Granule은 가상 메모리 상의 연속된 공간으로, dynamic SGA 모델에서 할당할
    수 있는 최소 단위이다. 이 granule의 크기는 SGA 전체의 추정값
    (SGA_MAX_SIZE)에 따라 다음과 같이 구분된다.
    4MB if estimated SGA size is < 128M
    16MB otherwise
    SGA의 Buffer Cache, Shared Pool, Large Pool 등의 파라미터는 이 granule
    단위로 늘어나거나 줄어들 수 있다. (현재 dynamic SGA를 사용할 수 있는
    SGA 관련 파라미터는 Buffer Cache, Shared Pool, Large Pool 세 가지이다.)
    2. Dynamic SGA(DB_CACHE_SIZE, SHARED_POOL_SIZE)
    DBA는 ALTER SYSTEM 명령을 통해 initSID.ora 화일에 정의된 SGA 관련 파라미
    터 값을 동적으로 변경할 수 있다. SGA 파라미터의 크기를 늘려주기 위해서
    는 필요한 만큼의 free granule이 존재해야만 하며, 현재 사용하고 있는 SGA
    의 크기가 SGA_MAX_SIZE보다 작아야 한다. Free granule이 없다고 해서 다른
    파라미터로부터 granule을 free시켜서 그 granule을 이용할 수 있는 것은 아
    니다.
    반드시 DBA가 명시적으로 free/allocate해야 한다.
    다음의 예를 살펴보자. 설명을 단순화하기 위해 이 경우는 SGA가 Buffer
    Cache와 Shared Pool로만 구성되었다고만 하자.
    예) initSID.ora
    SGA_MAX_SIZE = 128M
    DB_CACHE_SIZE = 96M
    SHARED_POOL_SIZE = 32M
    Note : DB_CACHE_SIZE는 Oracle 9i에 새롭게 도입된 파라미터이다.
    위와 같은 상태일 때 동적으로 SHARED_POOL_SIZE를 64M로 늘리면 에러가 발생
    한다.
    SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
    (insufficient memory error message)
    이 에러는 SHARED_POOL_SIZE를 늘림으로써 전체 SGA의 크기가 SGA_MAX_SIZE
    보다 커지기 때문에 발생한다. (96M + 64M > 128M)
    이를 해결하기 위해서는 DB_CACHE_SIZE를 줄인 후, SHARED_POOL_SIZE를 늘린다.
    SQL> ALTER SYSTEM SET DB_CACHE_SIZE=64M;
    SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
    Note : DB_CACHE_SIZE가 shrink되는 동안에
    ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
    를 하면 insufficient error가 발생할 수도 있다.
    이 경우는 DB_CACHE_SIZE가 shrink된 후 다시 수행하면 정상적으로
    수행이 된다.
    Note : 위 예제의 경우 estimated SGA 크기가 128M 이상이므로, granule의
    단위는 16M이다. 따라서 SGA 파라미터의 크기를 16M의 정수배로 했다.
    16M의 정수배가 아닌 경우는 지정한 값보다 큰 값에 대해 16M의
    정수배 중 가장 가까운 값을 택하게 된다.
    즉, 아래 두 문장의 결과는 똑같다.
    SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
    SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=49M;
    Note : LARGE_POOL_SIZE 와 JAVA_POOL_SIZE 파라미터는 동적으로 변경하는
    것이 불가능하다.
    1) Dynamic Shared Pool
    인스턴스 start 후, Shared Pool의 크기는 다음과 같은 명령에 의해 동적으
    로 변경(grow or shrink)될 수 있다.
    ALTER SYSTEM SET SHARED_POOL_SIZE=64M;
    다음과 같은 제약 사항이 있다.
    - 실제 할당되는 크기는 16M의 정수배가 된다.
    - 전체 SGA의 크기는 SGA_MAX_SIZE를 초과할 수는 없다.
    2) Dynamic Buffer Cache
    인스턴스 start 후, Buffer Cache의 크기는 다음과 같은 명령에 의해 동적으
    로 변경(grow or shrink)될 수 있다.
    ALTER SYSTEM SET DB_CACHE_SIZE=96M;
    다음과 같은 제약 사항이 있다.
    - 실제 할당되는 크기는 16M의 정수배가 된다.
    - 전체 SGA의 크기는 SGA_MAX_SIZE를 초과할 수는 없다.
    - DB_CACHE_SIZE는 0이 될 수 없다.
    3. Buffer Cache 파라미터의 변경된 내용
    여기서는 Buffer Cache 파라미터와 관련하여 Oracle 9i에 의미가 없어진 파라
    미터와 새롭게 추가된 파라미터, 그리고 dynamic SGA 중 Buffer Cache와 관련
    이 있는 부분에 대해 기술하고자 한다.
    1) Deprecated Buffer Cache Parameters
    다음의 세 가지 파라미터는 backward compatibility를 위해 존재하는 것으
    로, 차후 의미가 없어진다.
    - DB_BLOCK_BUFFERS
    - BUFFER_POOL_KEEP
    - BUFFER_POOL_RECYCLE
    위의 파라미터들이 정의되어 있으면 이 값들을 사용하게 될 것이다. 하지만,
    다음에 나올 새로운 파라미터들을 사용하는 것이 좋으며, 만일 위 파라미터
    (DB_BLOCK_BUFFERS, BUFFER_POOL_KEEP, BUFFER_POOL_RECYCLE) 값들을 사용
    한다면 이 글에서 설명한 dynamic SGA 특징을 사용할 수는 없다. 또한
    initSID.ora 화일에 위 파라미터들과 새로운 파라미터를 동시에 기술한다면
    에러가 발생한다.
    2) New Buffer Cache Sizing Parameters
    다음의 세 파라미터가 추가되었다. 이 파라미터들은 primary block size에
    대한 buffer cache 정보를 다루고 있다.
    - DB_CACHE_SIZE
    - DB_KEEP_CACHE_SIZE
    - DB_RECYCLE_CACHE_SIZE
    DB_CACHE_SIZE 파라미터에 지정된 값은 primary block size에 대한 default
    Buffer Pool의 크기를 의미한다. 또한 이전 버전과 마찬가지로 KEEP과
    RECYCLE buffer pool을 둘 수 있는데, 이는 DB_KEEP_CACHE_SIZE,
    DB_RECYCLE_CACHE_SIZE 라는 파라미터를 이용한다.
    이전 버전과 다른 점은 이전 버전의 경우 각각의 파라미터
    (DB_BLOCK_BUFFERS, BUFFER_POOL_KEEP,BUFFER_POOL_RECYCLE)에 정의된 값들
    이 buffer 갯수(즉, 실제 메모리 크기를 구하려면 db_block_size를 곱했어야
    했다. )였는데 반해 이제는 구체적인 메모리 크기이다.
    또한 이전에는 DB_BLOCK_BUFFERS가 BUFFER_POOL_KEEP, BUFFER_POOL_RECYCLE
    의 값을 포함하고 있었지만, 이제는 DB_CACHE_SIZE가 DB_KEEP_CACHE_SIZE,
    DB_RECYCLE_CACHE_SIZE를 포함하고 있지 않다.
    즉, 각각의 파라미터들은 독립적이다.
    Note : Oracle 9i부터는 multiple block size(2K, 4K, 8K, 16K, 32K)를 지원한다.
    위에서 언급한 primary block size는 DB_BLOCK_SIZE에 의해 정해진 block
    size를 의미한다. (SYSTEM tablespace는 이 block size를 이용한다.)
    3) Dynamic Buffer Cache Size Parameters
    바로 위에서 언급한 세 파라미터는 아래와 같이 ALTER SYSTEM 명령에 의해
    동적으로 변경 가능하다.
    SQL> ALTER SYSTEM SET DB_CACHE_SIZE=96M;
    SQL> ALTER SYSTEM SET DB_KEEP_CACHE_SIZE=16M;
    SQL> ALTER SYSTEM SET DB_RECYCLE_CACHE_SIZE=16M;
    Example
    none
    Reference Documents
    <Note:148495.1>

    Hello Martin,
    Can I execute by ORA-27102 the following commandos in order to set and use the values of sga_max_size immediately?
    Variant 1)
    >sqlplus /nolog
    >connect / as sysdba
    > startup nomout
    > ALTER SYSTEM SET SGA_MAX_SIZE= ’value’ SCOPE=pfile;
    > shutdown immediate
    > startup
    Variant 2)
    Changing the values of sga_max_size, etc. in init<DBSID>.ora
    >sqlplus /nolog
    >connect / as sysdba
    > startup from pfile = /oracle/<SID>/dbs/ init<DBSID>.ora;
    Thank you very much!
    regards
    Thom

  • Need to increase db_cache_size

    Hi Forum Friends,
    I have one concern, On one production server as per ADDM analysis report we need to increase db_cache_size at db level .
    According to my knowledge, SGA_MAX_SIZE= db_cache_size+shared_pool size + large pool size . Pls correct if i am wrong ?
    As per my DB settings:
    ============================================================
    sga_max_size = 70G
    db_cache_size = 60928M
    shared_pool_size = 8G
    large_pool_size= 0
    sga_target= 0
    As per ADDM report db_cache_size should be 64,768M
    ================================================================================================================
    But If my above statement is correct then we cannot increase db_cache_size untill we will increase sga_max_size  so that all parameter get involved in it ?
    Regards,
    Vishal Raina

    The SGA = Fixed size + Variable size + DB Cache Buffers + Online Redo Buffers.  Try querying v$sga and v$stastat to see how your space is allocated.
    Also Oracle has a strong tendency to over-identify space needs, that is, just because one of Oracle's features suggests more space is needed does not mean it really is.  You may be able to relieve some of the demand on the buffer cache by tuning SQL to be more efficient.  Then see if Oracle still wants more space.
    HTH -- Mark D Powell --

  • Setting Optimal db_cache_size

    How can i do it?
    I've looked at the V$DB_CACHE_ADVICE but don't know how to interpret it (what kind of information is needed to determine db_cache_size)
    Please help!
    Thanks,

    OK.
    Take the contents, and graph them as shown in that section of the doc. The curve has a 'if you double the cache, you get huge benefits' area, and it has a 'if you double the cache, you get almost no added benefits' area.
    Stick to the 'huge benefits' portion, and stop increasing the cache when you get to the 'almost no added benefits' portion.

  • Resizing resize db_cache_size parameter

    Hi
    i'm facing problem of IO and taking statspack report and analyzing it from statspackanalyzer they are advising me to increase db_cache_size to avoid many full table scans. could you help me on how to check an appropriate value of my db_cache_size as my configuration is below:
    OS RHEL 4
    RAM: 4 Gb
    CPU: 8 X Intel(R) Xeon(TM) CPU 3.20GHz
    Oracle dabatsae server 9.2.0.4
    My actual SGA is
    SQL> sho sga
    Total System Global Area 957945792 bytes
    Fixed Size 452544 bytes
    Variable Size 150994944 bytes
    Database Buffers 805306368 bytes
    Redo Buffers 1191936 bytes
    db_cache_size = 805306368
    shared_pool_size = 50331648
    log_buffer = 1048576
    And the v$db_cache_size_advice show me the below output.
    80 10010 1.3576 1442537193
    160 20020 1.3063 1387963597
    240 30030 1.2798 1359825236
    320 40040 1.2475 1325527521
    400 50050 1.2078 1283381091
    480 60060 1.164 1236834685
    560 70070 1.115 1184781753
    640 80080 1.0636 1130102023
    720 90090 1.0224 1086346464
    768 96096 1 1062540512 (Current)
    800 100100 .9814 1042794822
    880 110110 .9547 1014390821
    960 120120 .9343 992724772
    1,040 130130 .8642 918284631
    1,120 140140 .7784 827123440
    1,200 150150 .767 814920392
    1,280 160160 .7597 807265044
    1,360 170170 .7539 801045972
    1,440 180180 .7493 796205111
    1,520 190190 .7456 792210522
    1,600 200200 .7414 787812228
    Thanks for your help.

    Background Wait Events for DB: GABON Instance: gabon Snaps: 12 -13
    -> ordered by wait time desc, waits desc (idle events last)
    Avg
    Total Wait wait Waits
    Event Waits Timeouts Time (s) (ms) /txn
    control file parallel write 1,155 0 434 375 0.5
    db file scattered read 222 0 47 212 0.1
    control file sequential read 773 0 25 33 0.4
    db file sequential read 77 0 3 40 0.0
    log file parallel write 3,246 2,812 0 0 1.5
    db file parallel write 3,104 0 0 0 1.4
    rdbms ipc reply 2 0 0 21 0.0
    db file single write 4 0 0 11 0.0
    log buffer space 6 0 0 4 0.0
    log file single write 2 0 0 6 0.0
    log file sequential read 2 0 0 4 0.0
    direct path read 1,692 0 0 0 0.8
    direct path write 440 0 0 0 0.2
    latch free 6 1 0 0 0.0
    LGWR wait for redo copy 38 0 0 0 0.0
    rdbms ipc message 16,736 5,965 19,462 1163 7.6
    pmon timer 1,432 1,432 3,562 2488 0.6
    smon timer 12 11 3,330 ###### 0.0
    SQL ordered by Gets for DB: GABON Instance: gabon Snaps: 12 -13
    -> End Buffer Gets Threshold: 10000
    -> Note that resources reported for PL/SQL includes the resources used by
    all SQL statements called within the PL/SQL code. As individual SQL
    statements are also reported, it is possible and valid for the summed
    total % to exceed 100
    CPU Elapsd
    Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
    16,712,841 1 16,712,841.0 37.0 771.56 2430.22 2643858346
    Module: sqlservr.exe
    SELECT max(startdate) maxstartdate FROM in_cdr
    1,628,702 1 1,628,702.0 3.6 308.91 429.15 3952595216
    Module: TOAD 8.6.0.38
    select trunc(startdate) reportdate, count(*) calls, sum(duration
    ) actualsecs, sum(cost) revenue, sum(balancebefore-balanceafter)
    calculated_revenue from in_cdr partition(incdr_2010_0401) grou
    p by trunc(startdate) union select trunc(startdate) reportdate,
    count(*) calls, sum(duration) actualsecs, sum(cost) revenue, sum
    1,529,024 1 1,529,024.0 3.4 93.13 567.55 1639719688
    Module: sqlservr.exe
    SELECT max(startdate) maxstartdate FROM voucher_cdr
    952,565 303 3,143.8 2.1 31.82 264.22 485362562
    Module: sqlldr@cdranalysis (TNS V1-V3)
    INSERT INTO IN_CDR (ANUMBER,BNUMBER,STARTDATE,TIMEZONE,DURATIO
    N,CURRENCYTYPE,COST,DEDICATEDACCUSED,BALANCEAFTER,TRAFFICCASE,TE
    LESERVICECODE,LOCATION,DATAVOLUME,NUMBEROFEVENTS,FAFINDICATOR,NE
    TWORKID,SERVICEPROVIDERID,SERVICECLASS,ACCOUNTGROUPID,SERVICEOFF
    ERINGS,SELECTEDCOMMUNITYID,BALANCEBEFORE,BALANCEDEDICATEDAFTER,B
    773,681 3 257,893.7 1.7 30.16 477.10 1041979289
    Module: SQL*Plus
    begin processairdata; end;
    679,361 1 679,361.0 1.5 80.05 124.50 4241315052
    Module: sqlservr.exe
    Select * from SYSADM.subscriberdump where trunc(startdate)= t
    runc(sysdate)-1
    612,387 1 612,387.0 1.4 36.62 91.01 3058615587
    Module: sqlservr.exe
    select startdate,ServiceclassID,subscriberidmsisdn from Subscrib
    erDump where startdate = to_date('2010-06-07','YYYY-MM-DD') and
    subscriberimsi is not null and accountactivatedflag=1
    292,140 32,640 9.0 0.6 11.84 419.64 1609964435
    Module: SQL*Plus
    INSERT INTO ADJUSTMENT_CDR ( NOMINALAMOUNT, MSISDN, S
    ERVICECLASSID, ORIGINNODEID, ORIGINOPERATORID, DESCRIPTION
    , DESCRIPTION2, AMOUNTDA1, AMOUNTDA2, AMOUNTDA3, AMOUNT
    DA4, AMOUNTDA5, startdate, sequencenumber, FILEID )
    VALUES ( :b15 , :b14 , :b13 , :b12 , :b11 , :b10 ,
    194,749 3 64,916.3 0.4 5.11 5.42 2839087957
    Module: SQL*Plus
    SELECT ACDR.transactionamount , ACDR.accountnumber ,
    SQL ordered by Gets for DB: GABON Instance: gabon Snaps: 12 -13
    -> End Buffer Gets Threshold: 10000
    -> Note that resources reported for PL/SQL includes the resources used by
    all SQL statements called within the PL/SQL code. As individual SQL
    statements are also reported, it is possible and valid for the summed
    total % to exceed 100
    CPU Elapsd
    Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
    ACDR.serviceclasscurrent , ACDR.originhostname ,
    ACDR.originoperatorid , ACDR.externaldata1, ACDR.ex
    ternaldata2, ACDR.origintimestamp , ACDR.localsequ
    encenumber, ACDR.ADJUSTMENTAMOUNTDEDICATED1, ACDR.
    184,394 34,508 5.3 0.4 5.96 5.96 2453141568
    Module: SQL*Plus
    DELETE from AIR_CDR where ROWID = :b1
    141,583 39 3,630.3 0.3 3.03 3.93 169629744
    Module: sqlldr@cdranalysis (TNS V1-V3)
    INSERT INTO AIR_CDR (ORIGINNODETYPE,ORIGINHOSTNAME,ORIGINFILEI
    D,ORIGINTRANSACTIONID,ORIGINOPERATORID,ORIGINTIMESTAMP,HOSTNAME,
    LOCALSEQUENCENUMBER,TIMESTAMP,SERVICECLASSCURRENT,TRANSACTIONTYP
    E,TRANSACTIONCODE,TRANSACTIONAMOUNT,TRANSACTIONAMOUNTDEDICATED1,
    TRANSACTIONAMOUNTDEDICATED2,TRANSACTIONAMOUNTDEDICATED3,TRANSACT
    111,639 1 111,639.0 0.2 4.89 121.06 1973241403
    Module: SQL*Plus
    select * from msi_space
    84,898 3 28,299.3 0.2 2.47 2.57 1562134355
    Module: SQL*Plus
    SELECT ACDR.subscribernumber , ACDR.origintimestamp ,
    ACDR.VOUCHERSERIALNUMBER , ACDR.transactionamount,
    ACDR.RECHARGEAMOUNTMARKET, ACDR.VOUCHERGROUP, ACDR
    .localsequencenumber, ACDR.FILEID from AIR_CDR ACDR where
    ACDR.INSERTED = 'N' and ACDR.originnodetype IN ( 'IVR', 'UGW'
    63,675 8,205 7.8 0.1 2.49 2.19 4143084494
    select privilege#,level from sysauth$ connect by grantee#=prior
    privilege# and privilege#>0 start with grantee#=:1 and privilege
    #>0
    50,394 1 50,394.0 0.1 3.07 9.26 4130194716
    Module: sqlservr.exe
    select trunc(startdate)Days,serviceclass,datavolume,nano,bnumber
    ,cost from in_cdr partition (incdr_2010_0607) where teleservicec
    ode in ('5','6')
    40,714 1 40,714.0 0.1 1.40 5.42 5349178
    Module: SQL*Plus
    update infiles set records_loaded = 1072 where filename = '09101
    6-0234-Ccn1CDRFile-100607-1951-503848-7395-08062010130806-MINSAT
    .txt20100608'
    40,714 1 40,714.0 0.1 1.55 2.94 203676107
    Module: SQL*Plus
    update infiles set records_loaded = 984 where filename = '091016
    -0234-Ccn1CDRFile-100607-1917-503784-7274-08062010123948-MINSAT.

  • Cannot increase db_cache_size

    The oracle version is 9.2.0.7
    I want to increase db_cache_size dynamically to 6gb but i cannot increase it to even 2 gb. It is 1.5gb right now. The overall system memory is 16gb.
    Can anyone tell what is the reason
    sys@kishore> alter system set DB_CACHE_SIZE=3000m;
    alter system set DB_CACHE_SIZE=3000m
    ERROR at line 1:
    ORA-02097: parameter cannot be modified because specified value is invalid
    ORA-00384: Insufficient memory to grow cache

    You might have mistaken,
    if you have a 32-bit Oracle instance, the address space is only 2 to the power of 32, or 4 GB, on all platforms (except on Linux/Windows, the address space is actually 2 to the power of 31). So regardless how big your physical RAM is, the max addressable memory to 32-bit Oracle is 4G.
    and check here
    http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0410evans/#PartI
    In general, 32-bit operating system kernels can exploit four gigabytes of real memory (the physical RAM shared by the operating system and the running applications), whereas 64-bit operating system kernels can exploit more than this. Of course, some 32-bit operating system kernels can exploit more than four gigabytes of memory, but don’t do this as well as 64-bit kernels.

  • Set optimal db_cache_size param

    I read this article http://articles.techrepublic.com.com/5100-10878_11-5031958.html because I want to set optimal db_cache_size parameter on my database. But I still don't know which oracle metric should check to draw such chart and choose best value for my database. Could anybody give me some advice?

    The article you read is 8 years old, and doesn't apply to Oracle 10g and beyond, as Oracle 10g and beyond are self-tuning.
    Setting db_cache_size in 10g and beyond will disable self-tuning.
    So if you are running 10g and beyond (yet again you didn't include your version) the best thing you can do is
    - not to read 8 year old articles
    - not to set db_cache_size
    and better still
    be very cautious about anything Donald K Burleson writes, as his tuning approach often includes generic measures, and most other experts like Jonathan Lewis, Tom Kyte, Richard Foote, Cary Millsap and lot of others
    fundamentally disagree with him.
    Finally: how to determine db_cache_size is in the article, so I suggest you re-read it. Hint: especially read the bits on the cache advisor. Try to be not distracted by the impressive multi-color graphs.
    Sybrand Bakker
    Senior Oracle DBA

  • V$db_cache_size

    I am asked by oracle to provide some info using the below query.
    select sum(sharable_mem) from v$db_cache_size where sharable_mem>4100 and <=10000
    Does this view exist? This is on 9.2.0.7.0
    Thanks
    /SKH

    this view doesn't exist.
    db_cache_size itself is a initial parameter
    maybe they refer to v$db_object_cache
    SQL> desc v$db_object_cache
    Name Null? Type
    OWNER VARCHAR2(64)
    NAME VARCHAR2(1000)
    DB_LINK VARCHAR2(64)
    NAMESPACE VARCHAR2(28)
    TYPE VARCHAR2(28)
    SHARABLE_MEM NUMBER
    LOADS NUMBER
    EXECUTIONS NUMBER
    LOCKS NUMBER
    PINS NUMBER
    KEPT VARCHAR2(3)
    CHILD_LATCH NUMBER

  • Pga_aggregate_target & db_cache_size for an Oracle 10g Datawarehouse env

    We have an Oracle 10g Datawarehousing environment , with roughly 180 GB odd data running on 3 - node RAC
    with 16 GB RAM & 4 CPUs each and roughly we have 200 users and night jobs running on this D/W .
    We find that query performance of all ETL Processes & joins are quite slow .Certain packages take 35 min . or so to get executed.
    How much should we modify the value of pga_aggregate_target & db_cache_size parameter for this Datawarehouse environment ? This is a Production database, with Oracle Database 10g Enterprise Edition Release 10.1.0.5.0.
    We use OWB 10g Tool for this D/W.
    Current PGA_AGGREGATE_TARGET is 8589934592, whereas db_cache_size is
    1073741824
    Please suggest ,
    Thanks a lot in advance ,

    It is not clear what is meant by term "packages" in this context - i.e. are these PL/SQL packages or some other bunch of pl/sql statements or whatever else, but simply blindly changing init parameters you won't get anything good in a predictable future.
    You have to find WHAT is slow and tune that, it might very well be that it has nothing to do with pga_aggregate_target or another init parameters.
    Optimizing Oracle Performance by Cary Millsap and Jeff Holt can be the gretest help in this case.
    You can also look at his website www.hotsos.com, it has many whitepapers that can help you if you haven't the book.
    I for example see " 3 - node RAC" in your post and that makes me suspicious because if you are running batch jobs reading/writing the same data on all 3 nodes simultaneously, then the problem might be data pinging among nodes. BUT I DON'T KNOW FOR SURE, as well as you don't know, so the only predictable scenario is to get to know what is the reason.
    Gints Plivna
    http://www.gplivna.eu

  • Resizing db_cache_size parameter

    Hi all,
    i have database performance problem, the server is slow because the RAm is used in 100%, taking statspack report i got the folowing output in instance efficiency:
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 100.00 Redo NoWait %: 100.00
    Buffer Hit %: 14.15 In-memory Sort %: 99.98
    Library Hit %: 98.60 Soft Parse %: 95.77
    Execute to Parse %: 74.71 Latch Hit %: 99.99
    Parse CPU to Parse Elapsd %: 72.98 % Non-Parse CPU: 99.90
    Shared Pool Statistics Begin End
    Memory Usage %: 84.61 89.19
    % SQL with executions>1: 4.97 5.09
    % Memory for SQL w/exec>1: 14.23 16.09
    The Buffer Hit is 14 which seems very slow, from statspack analyzer they are advising to resize the DB_CACHE_SIZE parameter following the DB_CACHE_ADVICE view output below:
    80 10010 1.631 4847378181
    160 20020 1.4917 4433425952
    240 30030 1.4153 4206245775
    320 40040 1.3496 4011022458
    400 50050 1.2544 3727968097
    480 60060 1.1851 3522007360
    560 70070 1.1305 3359950649
    640 80080 1.0732 3189644899
    720 90090 1.0296 3060020775
    768 96096 1 2972013360
    800 100100 .9785 2908132320
    880 110110 .8999 2674444052
    960 120120 .8683 2580516085
    1,040 130130 .8366 2486253576
    1,120 140140 .6408 1904428818
    1,200 150150 .569 1691134670
    1,280 160160 .556 1652315333
    1,360 170170 .5489 1631483768
    1,440 180180 .5448 1619113935
    1,520 190190 .5421 1611045498
    1,600 200200 .5388 1601383512
    can anybody help me on what is the right size of my db_cache_size as i have 4 Gb of RAM and the SGA_MAX_SIZE is set to 2Gb and pga_aggregate_target is set to 0.
    thanks
    Lucien

    Hi Jonathan,
    here is my entire statspack report, please help.
    SQL ordered by Reads for DB: GABON  Instance: gabon  Snaps: 51 -52
    -> End Disk Reads Threshold:    1000
                                                         CPU      Elapsd
    Physical Reads  Executions  Reads per Exec %Total Time (s)  Time (s) Hash Value
             77,007            2       38,503.5    0.9     5.17      5.25 3171232606
    Module: sqlservr.exe
    select trunc(DATELOADED) STARDATE,FILENAME,  RECORDS_IN_FILE,
    RECORDS_LOADED ,filenameid,ABS(RECORDS_IN_FILE-RECORDS_LOADED) D
    ELTA  from  sysadm.infiles   where  to_char(DATELOADED,'YYYYMMDD
    ')='20100617'   and  (RECORDS_IN_FILE <> RECORDS_LOADED OR RECOR
    DS_LOADED=0)and ABS(RECORDS_IN_FILE-RECORDS_LOADED)>1  ORDER BY
             42,729            1       42,729.0    0.5     1.13      1.10  220927140
    Module: SQL*Plus
    select distinct 'Exists' from infiles where filename = '091016-0
    234-Ccn1CDRFile-100629-1140-552795-0670-29062010114304-MINSAT.tx
    t20100629'
             42,729            1       42,729.0    0.5     1.23      1.21  319703435
    Module: SQL*Plus
    update infiles set records_loaded = 952 where filename = '091016
    -0234-Ccn1CDRFile-100629-1140-552797-0677-29062010114405-MINSAT.
    txt20100629'
             42,729            1       42,729.0    0.5     1.11      1.08  398750951
    Module: SQL*Plus
    select distinct 'Exists' from infiles where filename = '091016-0
    234-Ccn1CDRFile-100629-1142-552799-0700-29062010114905-MINSAT.tx
    t20100629'
             42,729            1       42,729.0    0.5     5.05      5.00  585333435
    Module: sqlservr.exe
    select * from  sysadm.infiles   where  to_char(DATELOADED,'YYYYM
    M')='201006'
             42,729            1       42,729.0    0.5     1.23      1.20  670820997
    Module: SQL*Plus
    update infiles set records_loaded = 809 where filename = '091016
    -0234-Ccn1CDRFile-100629-1142-552799-0700-29062010114905-MINSAT.
    txt20100629'
             42,729            1       42,729.0    0.5     1.25      1.22  712766486
    Module: SQL*Plus
    update infiles set records_loaded = 1011 where filename = '09101
    6-0234-Ccn1CDRFile-100629-1138-552792-0668-29062010114246-MINSAT
    .txt20100629'
             42,729            1       42,729.0    0.5     1.25      1.22 1267800290
    Module: SQL*Plus
    update infiles set records_loaded = 928 where filename = '091016
    -0234-Ccn1CDRFile-100629-1142-552798-0690-29062010114841-MINSAT.
    txt20100629'
             42,729            1       42,729.0    0.5     1.24      1.22 1311160266
    Module: SQL*Plus
    update infiles set records_loaded = 959 where filename = '091016
    -0234-Ccn1CDRFile-100629-1139-552793-0675-29062010114350-MINSAT.
    txt20100629'
    SQL ordered by Reads for DB: GABON  Instance: gabon  Snaps: 51 -52
    -> End Disk Reads Threshold:    1000
                                                         CPU      Elapsd
    Physical Reads  Executions  Reads per Exec %Total Time (s)  Time (s) Hash Value
             42,729            1       42,729.0    0.5     1.24      1.21 1402052156
    Module: SQL*Plus
    update infiles set records_loaded = 784 where filename = '091016
    -0234-Ccn1CDRFile-100629-1140-552795-0670-29062010114304-MINSAT.
    txt20100629'
             42,729            1       42,729.0    0.5     1.11      1.09 1617445411
    Module: SQL*Plus
    select distinct 'Exists' from infiles where filename = '091016-0
    234-Ccn1CDRFile-100629-1138-552792-0668-29062010114246-MINSAT.tx
    t20100629'
             42,729            1       42,729.0    0.5     1.11      1.08 1686434310
    Module: SQL*Plus
    select distinct 'Exists' from infiles where filename = '091016-0
    234-Ccn1CDRFile-100629-1142-552798-0690-29062010114841-MINSAT.tx
    t20100629'
             42,729            1       42,729.0    0.5     1.12      1.10 1778534429
    Module: SQL*Plus
    select distinct 'Exists' from infiles where filename = '091016-0
    234-Ccn1CDRFile-100629-1140-552797-0677-29062010114405-MINSAT.tx
    t20100629'
             42,729            1       42,729.0    0.5     1.11      1.08 1800594875
    Module: SQL*Plus
    select distinct 'Exists' from infiles where filename = '091016-0
    234-Ccn1CDRFile-100629-1142-552800-0692-29062010114859-MINSAT.tx
    t20100629'
             42,729            1       42,729.0    0.5     1.11      1.08 1952783295
    Module: SQL*Plus
    select distinct 'Exists' from infiles where filename = '091016-0
    234-Ccn1CDRFile-100629-1139-552794-0671-29062010114326-MINSAT.tx
    t20100629'
             42,729            1       42,729.0    0.5     1.12      1.10 1985306312
    Module: SQL*Plus
    select distinct 'Exists' from infiles where filename = '091016-0
    234-Ccn1CDRFile-100629-1139-552793-0675-29062010114350-MINSAT.tx
    t20100629'
             42,729            1       42,729.0    0.5     1.24      1.21 2073655895
    Module: SQL*Plus
    update infiles set records_loaded = 936 where filename = '091016
    -0234-Ccn1CDRFile-100629-1138-552791-0673-29062010114335-MINSAT.
    txt20100629'
             42,729            1       42,729.0    0.5     1.11      1.08 2132012199
    Module: SQL*Plus
    select distinct 'Exists' from infiles where filename = '091016-0
    234-Ccn1CDRFile-100629-1140-552796-0672-29062010114329-MINSAT.tx
    t20100629'
    SQL ordered by Reads for DB: GABON  Instance: gabon  Snaps: 51 -52
    -> End Disk Reads Threshold:    1000
                                                         CPU      Elapsd
    Physical Reads  Executions  Reads per Exec %Total Time (s)  Time (s) Hash Value
             42,729            1       42,729.0    0.5     1.24      1.21 2179069916
    Module: SQL*Plus
    update infiles set records_loaded = 936 where filename = '091016
    -0234-Ccn1CDRFile-100629-1139-552794-0671-29062010114326-MINSAT.
    txt20100629'
             42,729            1       42,729.0    0.5     1.24      1.21 3172937007
    Module: SQL*Plus
    update infiles set records_loaded = 909 where filename = '091016
    -0234-Ccn1CDRFile-100629-1140-552796-0672-29062010114329-MINSAT.
    txt20100629'
             42,729            1       42,729.0    0.5     1.22      1.21 3567256981
    Module: SQL*Plus
    select distinct 'Exists' from infiles where filename = '091016-0
    234-Ccn1CDRFile-100629-1142-552801-0696-29062010114902-MINSAT.tx
    t20100629'
    SQL ordered by Executions for DB: GABON  Instance: gabon  Snaps: 51 -52
    -> End Executions Threshold:     100
                                                    CPU per    Elap per
    Executions   Rows Processed   Rows per Exec    Exec (s)   Exec (s)  Hash Value
          22,803          22,803              1.0       0.00        0.00 2453141568
    Module: SQL*Plus
    DELETE from AIR_CDR where  ROWID = :b1
          21,452          21,374              1.0       0.00        0.01 1609964435
    Module: SQL*Plus
    INSERT INTO ADJUSTMENT_CDR        ( NOMINALAMOUNT,   MSISDN,   S
    ERVICECLASSID,   ORIGINNODEID,   ORIGINOPERATORID,   DESCRIPTION
    ,  DESCRIPTION2,   AMOUNTDA1,   AMOUNTDA2,   AMOUNTDA3,   AMOUNT
    DA4,   AMOUNTDA5,   startdate,   sequencenumber,   FILEID )
       VALUES       ( :b15 ,  :b14 ,  :b13 ,  :b12 ,  :b11 ,  :b10 ,
           5,268          22,389              4.3       0.00        0.00 4143084494
    select privilege#,level from sysauth$ connect by grantee#=prior
    privilege# and privilege#>0 start with grantee#=:1 and privilege
    #>0
           1,434           1,434              1.0       0.00        0.01 1782899448
    Module: SQL*Plus
    INSERT INTO VOUCHER_CDR        ( MSISDN,   STARTDATE,   SERIALNU
    MBER,   COST,   RECHARGEAMOUNTMARKET,   VOUCHERGROUP,   sequence
    number,   FILEID )        VALUES        ( :b8,   to_date(substr(
    :b7,1,14),'YYYYMMDDHH24MISS'),   :b6,   :b5,   :b4,   :b3,   :b2
    ,  :b1 )
           1,321               0              0.0       0.00        0.00 3611653548
    Module: perl@kgateway (TNS V1-V3)
    ALTER SESSION SET TIME_ZONE='+01:00'
           1,317           5,268              4.0       0.00        0.00  888033327
    select role# from defrole$ d,user$ u where d.user#=:1 and u.user
    #=d.user# and u.defrole=2 union select privilege# from sysauth$
    s,user$ u where (grantee#=:1 or grantee#=1) and privilege#>0 and
    not exists (select null from defrole$ where user#=:1 and role#=
    s.privilege#) and u.user#=:1 and u.defrole=3
           1,020               0              0.0       0.00        0.00 2009857449
    Module: sqlplus@cdranalysis (TNS V1-V3)
    SELECT CHAR_VALUE FROM SYSTEM.PRODUCT_PRIVS WHERE   (UPPER('SQL*
    Plus') LIKE UPPER(PRODUCT)) AND   ((UPPER(USER) LIKE USERID) OR
    (USERID = 'PUBLIC')) AND   (UPPER(ATTRIBUTE) = 'ROLES')
           1,020               0              0.0       0.00        0.00 3096433403
    Module: sqlplus@cdranalysis (TNS V1-V3)
    SELECT ATTRIBUTE,SCOPE,NUMERIC_VALUE,CHAR_VALUE,DATE_VALUE FROM
    SYSTEM.PRODUCT_PRIVS WHERE (UPPER('SQL*Plus') LIKE UPPER(PRODUCT
    )) AND (UPPER(USER) LIKE USERID)
           1,020           1,020              1.0       0.00        0.00 4119976668
    Module: sqlplus@cdranalysis (TNS V1-V3)
    SELECT USER FROM DUAL
           1,020           1,020              1.0       0.00        0.00 4282642546
    Module: SQL*Plusregards
    Lucienot.

  • Reducing db_cache_size

    Hi,
    I try to reduce the db_cache_size to zero (Oracle 10g on Suse 9). Therefore, I've set SGA_TARGET to 0. After issueing alter system set db_cache_size=0;, I got the error message
    ORA-00383: DEFAULT cache for blocksize 8192 cannot be reduced to zero
    The manual says that all tablespaces that use this blocksize should be offlined and then the operation shall be performed again. My problem is that the SYSTEM, TEMP, and UNDOTBS1 cannot be brought offline (at least not with the Enterprise Manager GUI).
    Can anybody help me setting db_cache_size to 0? Thanks in advance!

    Hi,<br>
    <br>
    Very strange manear to tune database... in fact. Will it be only one user to connect to your db ?<br>
    Did you know what is cache size ? I'm not sure, 4Gb seems enormous, and 16Mb seems too small...<br>
    Try to not set this parameter, and Oracle will choose for you the default value, it sometimes a good idea (at least >= 4MB * number of CPUs * granule size).<br>
    Read the following doc, to help you to set a valuable value : Configuring and Using the Buffer Cache<br>
    But, I think that you need to read the buffer cache definition : Database Buffer Cache<br>
    <br>
    Nicolas.

Maybe you are looking for