Dbwr_io_slaves or db_writer_processes

Im having a little trouble understanding the situations in which using dbwr_io_slaves would be better than db_writer_processes, it would be nice if someone could explain it clearly or point me to documentation that explains it cleary.
I have a secondary question which im pretty sure is related, which is, one of the databases that I deal with has a large number of dirty buffers (ie: > 600,000) at the moment the only way I know to clear this and reduce the number is to restart the database from time to time (this is not something I want to be doing and need a better solution).
Some background information:
The database gets information loaded into it in batches on a nightly basis, the server the database runs on has two dual core cpu's with 8gb of ram, there are also a couple of other databases running on these systems as well.

With DBWR I/O Slaves, you have one dbwr processes that gathers dirty blocks from the cache and shares them out to the I/O slaves to write. This emulates asynchronous I/O for operating systems that don't have it, and probably isn't needed on any modern system.
With multiple database writers you break the cache into smaller pieces (working data sets) and each DBWn is responsible for keeping part of the cache clean - this improves scalability for extreme cases but if you read Kevin Closson's blog (The index http://kevinclosson.wordpress.com/kevin-closson-index/general-performance-and-io-topics/ has a number of posts on over-configuring dbwr processes) you will see why this isn't often necessary.
Your 600,000 dirty blocks is a big number - how big is the entire buffer cache, and how are you checking that number ? One possibility for the size is that consistent read copies of dirty current blocks don't seem to get their dirty bit cleared on some versions of Oracle. If you refine you test to show the block state, you may find that most of the dirty blocks are CR copies.
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.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

Similar Messages

  • Imm op in Top 5 wait event

    Hi,
    I found the event: "imm op" in the top of the "top 5 wait event" , at the awr report (10204 version) .
    Is it an idel event ? is related to the fact that the database is bening backedup at the same time (event Backup: sbtbackup ) ?
    Is there somthing i can do to reduce it value ?
    Thanks
    Top 5 Timed Events                                         Avg %Total
    ~~~~~~~~~~~~~~~~~~                                        wait   Call
    Event                                 Waits    Time (s)   (ms)   Time Wait Class
    imm op                                5,936       5,879    990   68.8      Other
    Backup: sbtbackup                         8       5,752 ######   67.3 Administra
    db file scattered read              200,642       3,335     17   39.0   User I/O
    CPU time                                          3,177          37.2
    log file parallel write             150,271       1,822     12   21.3 System I/O
              -------------------------------------------------------------

    Hi Werner,
    BACKUP_TAPE_IO_SLAVES is set to TRUE in the case of a RMAN backup if dedicated I/O slave processes are to copy backup write processes to tape and not the Oracle shadow processes. In this case, "imm op" waits only affect the backup runtime, but not the live system.My init.ora parameter are as followed:
    backup_tape_io_slaves TRUE
    dbwr_io_slaves 0
    db_writer_processes 1
    I dont know the reason why backup_tape_io_slaves is set to TRUE.
    Would you suggest me to set it to FALSE and test it again ?
    Thanks
    End value
    Parameter Name                Begin value                       (if different)
    aq_tm_processes               0
    background_dump_dest          C:\ORACLE\ADMIN\XXX\BDUMP
    backup_tape_io_slaves         TRUE
    compatible                    10.2.0
    control_files                 D:\ORADATA\XXX\CONTROL01.CTL, D:
    core_dump_dest                C:\ORACLE\ADMIN\XXX\CDUMP
    db_block_size                 8192
    db_cache_size                 8388608
    db_domain
    db_file_multiblock_read_count 16
    db_name                       xxxx
    db_recovery_file_dest         T:\oradata\XXX\archive
    db_recovery_file_dest_size    1073741824
    dispatchers                   (PROTOCOL=TCP) (SERVICE=XXXXDB)
    fast_start_mttr_target        300
    instance_name                 xxxx
    java_pool_size                0
    job_queue_processes           3
    large_pool_size               0
    local_listener                LISTENER_xxxx
    log_archive_dest_1            LOCATION=T:\oradata\XXX\archive
    log_archive_format            %t_%r_%s.dbf
    max_dump_file_size            UNLIMITED
    nls_length_semantics          BYTE
    open_cursors                  1200
    processes                     150
    query_rewrite_enabled         FALSE
    remote_login_passwordfile     EXCLUSIVE
    resource_limit                TRUE
    resource_manager_plan
    session_cached_cursors        300
    session_max_open_files        20
    sga_target                    838860800
    shared_pool_size              0
    sort_area_size                524288
    star_transformation_enabled   FALSE
    streams_pool_size             50331648
    timed_statistics              TRUE
    undo_management               AUTO
    undo_retention                3600
    undo_tablespace               UNDOTBS1
    user_dump_dest                C:\ORACLE\ADMIN\XXX\UDUMP
              -------------------------------------------------------------

  • Trying boost the performance of RMAN on AIX5L

    Hi all,
    I need to find the best "number" for my test environment:
    I'm looking for opinions based on knowledge of who has experience with RMAN.
    I'm trying find better numbers of channels, maxopenfiles and additional parameters.
    I accept the recommendation of changing the parameters of Operating System or Database
    Environment Info:
    DB:  10.2.0.5
    ASM: 10.2.0.5
    OS:  AIX 5L
    CPUs: 16 
    DISKGROUP: 1 (with 16 ASMDISK)
    Adapter: 4 HBA (4GBIT)I want to find out what the maximum rate that can be achieved, then this test I will use only "BACKUP VALIDATE" When I get the best number i'll go to TSM the backup will be done via LAN-FREE.
    Below the results of the tests using BACKUP VALIDATE:
    =====================================================
    1° Test
    Database Parameter
      backup_tape_io_slaves=TRUE
      dbwr_io_slaves=0
      db_writer_processes=6
      tape_asynch_io= TRUE
      disk_asynch_io= TRUE
    RMAN Parameter
      4 Channel
      4 MAXOPENFILES for each Channel
    TIME: 01:08:13
    SIZE IN:892.11GB     
    RATE: 223MB/s
    =====================================================
    =====================================================
    2° Test
    Database Parameter
       backup_tape_io_slaves=TRUE
       dbwr_io_slaves=0
       db_writer_processes=6
       tape_asynch_io= TRUE
       disk_asynch_io= TRUE
    RMAN Parameter
       4 Channel
       3 MAXOPENFILES for each Channel
    TIME: 00:57:42
    SIZE IN:892.11GB     
    RATE: 264MB/s
    =====================================================
    =====================================================
    3° Test - Here my best number
    Database Parameter
      backup_tape_io_slaves=TRUE
      dbwr_io_slaves=0
      db_writer_processes=6
      tape_asynch_io= TRUE
      disk_asynch_io= TRUE
    RMAN Parameter
      4 Channel
      2 MAXOPENFILES for each Channel
    TIME: 00:53:01
    SIZE IN:892.11GB     
    RATE: 287MB/s
    =====================================================I ran other test with 2 Channels and 3 MAXOPENFILES and perfomance was like 3° Test - about 54 minutes
    I could not understand why using the maximum of 2 MAXOPENFILES and 4 Channels = 8 MAXOPENFILES is more performatic than if I increase the number parallelism of the datafiles reads.
    My 1° test i can get 784 GB/hour
    My 3° test i can get 1009 GB/hour
    It's a big difference, because this test database (~ 900GB) is small compared with the production.
    What makes sense for this to be optimal number (8 MAXOPENFILES)?
    Thanks,
    Levi Pereira

    Hi Dude,
    Thanks for the input.
    Dude wrote:
    I think the difference could be memory and process related combined with hardware limitations. RMAN will read the datafiles from disk into memory. Doesn't parallelism introduce additional channels and each channel writes to a separate backupset? From what I understand, too many I/O channels can reduce overall performance and cause additional overhead in particular if the media or disk is the bottleneck. On the other hand, If the cpu was the bottleneck, more cpu or processes can boost performance. When processes run on different cpu's, caching is less effective. The same applies to your HBA adapter. I monitored the whole process of backup and saw that the issue was always associated with performance of I/O the RMAN not was waiting for the CPU and also had no waits on disks. I knew I could increase my throughput but I do not know how. (i.e Resources was left over but did not know how exploring them.)
    >
    As a rule, the number of channels used in carrying out an individual RMAN command should match the number of physical devices accessed in carrying out that command. Striped disk configurations involve hardware multiplexing, so that the level of RMAN multiplexing does not need to be as high and a smaller MAXOPENFILES setting can results in faster performance.
    I can use up to 4 Drives (4 Channels) that are LTO-5 that may have an acceptable rate of 120MB/s, so I can go up to 480Mb/s I know it's not exact, there are several extra factors.
    I wish be sure which was the highest rate I could get by using four channels.
    It remains unknown (x =?) this math.
    16 (asmdisk) + 2 (HBA) + 256 (Datafiles) its ok to use 4 Channel + 2 MAXOPENFILES + 12 DB_WRITE
    If I knew the math to find the ideal number of channels and maxopenfiles would be my great discovery.
    I guess you already checked the Tuning Backup and Recovery chapter of the Database Backup and Recovery Advanced User's Guide, which also shows that you can use the V$BACKUP_SYNC_IO and V$BACKUP_ASYNC_IO views to determine the source of backup or restore bottlenecks and to see detailed progress of backup jobs. http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmtunin.htm#i1006195
    I add more notes than I used:
    RMAN Performance Tuning Using Buffer Memory Parameters [ID 1072545.1]
    RMAN Performance Tuning Diagnostics [ID 311068.1]
    Advise On How To Improve Rman Performance [ID 579158.1]
    Using V$BACKUP_ASYNC_IO / V$BACKUP_SYNC_IO to Monitor RMAN Performance [ID 237083.1]
    http://levipereira.wordpress.com/2010/11/20/tuning-oracle-rman-jobs/
    I tried one more change:
    On large workloads, the database writer may become a bottleneck. If it does, then increase the value of DB_WRITER_PROCESSES. As a general rule, do not increase the number of database writer processes above one for each pair of CPUs in the system or partition.
    http://download.oracle.com/docs/cd/B28359_01/server.111/b32009/appa_aix.htm#BEHGGBAJ
    I changed DB_WRITE_PROCESSES from 6 to 12.
    My last RATE: 305MB/s.
    Cheers,
    Levi Pereira

  • Checkpoint not complete + db_writer_processes/dbwr_io_slaves

    Hi,
    Oracle Database 11g Release 11.1.0.6.0 - 64bit Production With the Real Application Clusters option.
    After I noticed this error into the alert log:
    Thread 2 cannot allocate new log, sequence 152831
    Checkpoint not complete
    Current log# 17 seq# 152830 mem# 0: +ONLINELOG/evodb/onlinelog/group_17.272.729333887
    Thread 2 advanced to log sequence 152831
    Current log# 14 seq# 152831 mem# 0: +ONLINELOG/evodb/onlinelog/group_14.269.729333871
    And read a lot to understand the real cause (for the moment I increased the the redolog file from 5 to 7 (250mb each)).
    As it seems I've no problem with the ARCH processes, I read that the cause can be the DBWR0 process that is not "fast" enough to write block I've into redos, and free them for archiving.
    I read then something about the asynchronous I/O, and how db_writer_processes/dbwr_io_slaves can simulate the async write to disk.
    I think I understood the difference between db_writer_processes and dbwr_io_slaves.
    My question is how I can understand if my database needs more DBWR process.
    At the moment my configuration is:
    db_writer_processes 1
    dbwr_io_slaves 0
    Thanks in advance,
    Samuel

    Hi Samuel,
    There is still a major confusion on your side concerning the DBWR. It will NOT write data from your redo buffers to the redo logs, since it is the job of the LGWR.
    When a log switch occurs (so, you will use a different redo group), then it is the job of the ARCn process(es) to backup the 'used' redo log to a archive log.
    When your ARCn process(es) are not fast enough, and a log swicth occurs, it may happen that you have no inactive (read archived) redo group.... then Oracle 'hangs' till it can find such a redo group available.
    So, you may want to add 1 (or more) redo group, or increase the size of the redo log files, or have more archiver processes.
    DBWr job is to write dirty database blocks back to datafiles.
    CKPT also works independently of the LGWR and DBWR.
    Check this:
    http://www.dbasupport.com/forums/archive/index.php/t-5351.html
    And another couple of links:
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/process.htm
    Concepts of checkpoint, dbwr, lgwr processes
    HTH,
    Thierry
    Edited by: Urgent-IT on Feb 10, 2011 5:33 PM
    Added mote about CKPT + link
    Edited by: Urgent-IT on Feb 10, 2011 5:37 PM
    Added another 2 links

  • Db_writer_processes & dbwr_io_slaves

    what is the main use of db_writer_processes & dbwr_io_slaves in oracle 10g and what impact can be on database after increasing this.

    http://www.fors.com/velpuri2/PERFORMANCE/ASYNC
    hare krishna
    Alok

  • ORACLE8에서의 DBWR (DBWR_IO_SLAVES와 DB_WRITER_PROCESSES)

    제품 : ORACLE SERVER
    작성날짜 : 2002-08-12
    Oracle 8에서의 DBWR (dbwr_io_slaves와 db_writer_processes)
    Oracle 7에서의 db_writers는 master-slave processing을 통해, async I/O를
    simulate하기 위해 사용되었다고 볼 수 있다. Oracle 8에서 DBWR의 write
    processing에 더 나은 성능을 제공하기 위해 복수 개의 database writer를 사용
    하는 방법은 다음과 같이 두가지로 나눌 수 있다.
    1. DBWR IO slaves (dbwr_io_slaves)
    Oracle7에서의 mulitple DBWR process들은 단순히 slave process로서, asynch
    I/O call을 수행할 수는 없었다. Oracle 8.0.3부터, slave database writer code
    가 kernal에 포함되었고, slave process의 async I/O가 가능하게 되었다. 이것은
    init.ora file 내에 dbwr_io_slaves라는 parameter를 통해 가능하며, IO slave가
    asynchronous I/O가 가능하여 I/O call 이후에 slave가 block되지 않아 더 나은
    성능을 제공한다는 것을 제외하고는 Oracle7과 매우 유사하다. slave process는
    instance 생성 시기가 아닌 database open 시에 start되기 때문에 oracle process
    id가 9번부터 할당되며, o/s에서 확인되는 process 이름도 ora_i10n_SID와 같은
    형태가 된다.
    dbwr_io_slaves=3으로 지정한 경우, 아래와 같은 oracle background process가
    구동되며, ora_i101_V804, ora_i102_V804, ora_i103_V804이 dbwr의 slave
    process들이다.
    tcsol2% ps -ef | grep V804
    usupport 5419 1 0 06:23:53 ? 0:00 ora_pmon_V804
    usupport 5429 1 1 06:23:53 ? 0:00 ora_smon_V804
    usupport 5421 1 0 06:23:53 ? 0:00 ora_dbw0_V804
    usupport 5433 1 0 06:23:56 ? 0:00 ora_i101_V804
    usupport 5423 1 0 06:23:53 ? 0:00 ora_arch_V804
    usupport 5431 1 0 06:23:53 ? 0:00 ora_reco_V804
    usupport 5435 1 0 06:23:56 ? 0:00 ora_i102_V804
    usupport 5437 1 0 06:23:56 ? 0:00 ora_i103_V804
    usupport 5425 1 0 06:23:53 ? 0:00 ora_lgwr_V804
    usupport 5427 1 0 06:23:53 ? 0:00 ora_ckpt_V804
    2. Multiple DBWR (db_writer_processes)
    multiple database writer는 init.ora file내의 db_writer_processes라는
    parameter에 의해 구현되며, 이것은 Oracle 8.0.4부터 제공되었다. 이것은
    기존의 master-slave 관계가 아닌 진정한 의미의 복수개의 database writer를
    사용하는 것이며, database writer process들은 PMON이 start된 후에 start되어
    진다.
    이름은 ora_dbwn_SID 형태이며, 아래에 db_block_lru_latches=2,
    db_writer_processes=2로 지정한 경우 구동된 oracle background process들의
    예이다. 여기에서 ora_dbw0_V804, dbw1_V804이 dbwr process들이다. 만약
    db_writer_processes를 지정하지 않으면 기본값은 1인데 이 때도 Oracle7과 같이
    ora_dbwr_SID 형태가 아닌 ora_dbw0_SID 형태의 process가 구동된다.
    usupport 5522 1 0 06:31:39 ? 0:00 ora_dbw1_V804
    usupport 5524 1 0 06:31:39 ? 0:00 ora_arch_V804
    usupport 5532 1 0 06:31:39 ? 0:00 ora_reco_V804
    usupport 5528 1 0 06:31:39 ? 0:00 ora_ckpt_V804
    usupport 5530 1 0 06:31:39 ? 0:00 ora_smon_V804
    usupport 5526 1 0 06:31:39 ? 0:00 ora_lgwr_V804
    usupport 5520 1 0 06:31:39 ? 0:00 ora_dbw0_V804
    usupport 5518 1 0 06:31:38 ? 0:00 ora_pmon_V804
    db_writer_processes로 지정된 각 writer process는 하나의 latch set에 할당된다.
    그러므로 db_writer_processes를 db_block_lru_latches으로 지정되는 LRU latch의
    갯수와 같은 값으로 지정하는 것이 권장할 만하며, 단 CPU의 갯수를 초과하는 것은
    바람직하지 않다.
    [참고] 현재까지 init.ora file내에 구동되는 dbwr의 갯수는 db_block_lru_latches
    parameter에 의해 제한된다. 즉 db_writer_processes 값을 db_block_lru_latches
    보다 크게 하여도 db_block_lru_latches로 지정
    된 수의 dbwr process가 기동된다.
    Oracle8에서 DBWR I/O slave나 복수개의 DBWR를 제공하는 방법 중 좋은 점은
    이 기법을 제공하는 것이 kernal 안에 포함되어 기존의 OSD layer로 구현되었던
    것보다 port specific한 부분이 없고 generic하다는 것이다.
    3. 두 가지 방법 중 선택 시 고려사항
    이러한 두가지 형태의 DBWR 기법이 모두 도움이 되기는 하지만, 일반적으로
    어느 것을 사용할 것인지는 OS level에서 asynchronous I/O가 제공하는지와
    CPU 갯수에 의존한다. 즉, system이 복수 개의 CPU를 가지고 있으면
    db_writer_processes를 사용하는 것이 바람직하며, aync I/O를 제공하는 경우
    두 가지 모두 사용에 효과를 얻을 수 있다. 그런데 여기서 주의할 것은
    dbwr_io_slaves가 약간의 overhead가 있다는 것이다.
    slave IO process를 가능하게 하면, IO buffer와 request queue의 할당을 위해
    부가적인 shared memory가 필요하다.
    multiple writer processes와 IO slave는 매우 부하가 많은 OLTP 환경에서
    적합하며, 일정 수준 이상의 성능을 요구할 때만 사용하도록 한다. 예를 들어
    asynch I/O가 사용 가능한 경우, I/O slave도 사용하지 않고 하나의 DBWR만을
    asynch I/O mode로 사용하는 것이 충분하고 바람직할 수 있다. 현재의 성능을
    조사하고 bottleneck이 되는 부분이 DBWR 부분인지 정확히 조사한 후 사용하여야
    한다.
    [참고] 이 두 parameter를 함께 사용하면 dbwr_io_slaves만 효과가 있다.
    이것은 dbwr_io_slaves는 master dbwr process를 db_writer_proceses에 관계 없이
    하나만 가지도록 되어 있기 때문이다.

    http://www.fors.com/velpuri2/PERFORMANCE/ASYNC
    hare krishna
    Alok

  • Db_writer_processes vs dbwr_io_slaves

    Hi All
    Could please let me know how these two parameters can be used efficiently
    we have our DB on Unix Oracle 8,9, 10
    thanx
    Kedar

    Not meaning to be condescending, but if you have a system that needs this sort of tuning then I think you need to take a slightly more 'scientific' approach (And please lets's not turn this into another argument about the use of the term scientific in regards to Oracle!) as well as get thoroughly acquainted with the documentation (Concepts guide if you need it, then the tuning guide).

  • Oracle db_writer_processes

    Hi,
    When one of process ran in 11.5.10.2, DBWR0 process get loaded since that process execute INSERT internally. I'm thinking to increase db_writer_processes process to 3. The current parameter value is 1.
    Does this help ?
    or in what situation we need to have more db_writer_processes processes.
    Thanks

    Hi,
    Please refer to the following documents for guidelines about setting this parameter.
    Note: 164768.1 - Diagnosing High CPU Utilization
    Note: 62172.1 - Understanding and Tuning Buffer Cache and DBWR
    Note: 97291.1 - DB_WRITER_PROCESSES or DBWR_IO_SLAVES?
    Note: 67422.1 - Init.ora Parameter "DB_WRITER_PROCESSES" Reference Note
    Regards,
    Hussein

  • Increase the db_writer_processes

    My DB is giving the free buffer waits..
    In parameter file
    DB_writer_processes =1,
    DBwr_IO_slaves =0
    I think I need to increase the db_writer_processes.. How to increase it?
    I am using Spfile for starting the DB

    I will suggest reading Kevin Closson's articles on DBWR
    http://kevinclosson.wordpress.com/2007/08/10/learn-how-to-obliterate-processor-caches-configure-lots-and-lots-of-dbwr-processes/

  • DBWR_IO_SLAVES について

    ORACLE:11.2.0.3 OS:Linux
    DBWR_IO_SLAVESについて調べていて、下記のような記述を見つけたのですが
    あまり理解出来ていません。
    DBWR_IO_SLAVESを設定すると、DBWRに対し設定した数のI/O SLAVEが起動されます。I/O SLAVEはDISK I/OのみをDBWRと並行に行います。
    BUFFERのFLUSHなどのDBWRとしての動作は、DBWR本体が行います。
    DBWR_IO_SLAVES を設定すると、DBWRは1つしか起動されません。 DBWRのI/Oスレーブプロセスが複数起動されます。
    DB_WRITER_PROCESSES と DBWR_IO_SLAVES を同時に指定するとDBWR_IO_SLAVES の値が優先されます。
    Q1.そもそもI/O SLAVEとはなんでしょうか?非同期I/Oという記述もあったのですがこちらも意味が分かりません。
    Q2.「BUFFERのFLUSHなどのDBWRとして~」という記述について
      結局はDBWR_IO_SLAVESを設定してもしなくてもDBライターの動きは同じなのでしょうか?
    Q3.DBWR_IO_SLAVESを設定するメリットは何になるでしょうか?
    「非同期I/O」という意味が理解出来ていないので、噛み砕いた表現をして頂けると嬉しいです。。。
    宜しくお願い致します。

    Q1.そもそもI/O SLAVEとはなんでしょうか?非同期I/Oという記述もあったのですがこちらも意味が分かりません。非同期I/Oの技術的な説明はこちらが良いですかね。。
    <<http://lab.klab.org/files/alm/20070806/aio.pdf>>
    I/O SLAVEはアプリケーションから渡されたDISK I/OをDBWRが一つのプロセス上で全て処理するのではなく、それぞれのI/O SLAVEに渡す事で、アプリケーション側からはDBWRはあたかも並列で非同期にI/Oを処理しているかのように見せる技術と理解してます。
    Q2.「BUFFERのFLUSHなどのDBWRとして~」という記述について
      結局はDBWR_IO_SLAVESを設定してもしなくてもDBライターの動きは同じなのでしょうか?DISK I/OのみをSLAVEに実行させる、とあります。
    BUFFERのFLUSH処理等は設定していてもしていなくても変わらないが、DISK I/Oの動作はSLAVE経由になるので変わる、という理解です。
    Q3.DBWR_IO_SLAVESを設定するメリットは何になるでしょうか?非同期I/Oが使えない環境において、DBWRのDISK I/O処理がボトルネックになっている場合に、DISK I/O処理を分散させる事でそのボトルネックを解消する事ができると考えてます。
    基本的に11.2.0.3が入るLinuxであれば、libaioが入っていると思いますので、非同期I/Oが可能だと考えてます。
    <<http://docs.oracle.com/cd/E16338_01/server.112/b56317/appc_linux.htm#BABIIHEJ>>

  • DB_WRITER_PROCESSES in Oracle 10.2.0.4 HP UX

    Hi all,
    I noticed that asynchronous i/o cannot be used with regular filesystem on HP UX (only raw devices).
    As far as I know what I can do is to configure multiple db writers with DB_WRITER_PROCESSES parameter.
    DB has CPU_COUNT in 16, but 2 db writers (default value = CPU_COUNT / 8).
    Will I have any benefit by increasing DB_WRITER_PROCESSES?
    Or only if there is a bottleneck in writing dirty buffers?
    Thanks

    >
    If bottleneck exists it would be at the disk end & not the CPU end.
    Server processes are at least 1000 times faster than mechanical disk drives.
    a single DB_WRITER could keep 10 disk controllers busy & not be a bottleneck.Well, then why does Oracle default to 1 process every 8 cpus?
    DBWn also handles checkpoints, file open synchronization, and logging of Block Written records, according to [url http://docs.oracle.com/cd/E11882_01/server.112/e25513/bgprocesses.htm#BBBDIIHC]the docs. On hp-ux Oracle does file handles oddly - see MOS How to Disable Asynch_io on HP to Avoid Ioctl Async_config Error Errno = 1 [ID 302801.1] if you (the OP) haven't already.
    So on hp-ux you have a potential problem of the architecture assuming asyncronicity but the dickering between dbw, lgwr and ckpt turning into bickering. Just because something is 1000 times faster doesn't mean it isn't doing 1000 more operations. In real life, you wind up with Oracle telling you to ignore Private strand flush not complete errors, because there are no actual lgwr problems unless switches are slow.

  • Db_writer_process and async IO??

    we have ORACLE 10Gr2 on Redhar AS LInux server version 4.X. I checked one of database init.ora have following setup:
    db_writer_processes = 2
    filesystemio_options = asynch
    DISK_ASYNCH_IO = true
    TAPE_ASYNCH_IO = true
    Based on what I know "db_writer_processes " and "filesystemio_options = asynch" are exclusive. Can anyone tell me database will use whiche one?
    Thanks.

    Based on what I know "db_writer_processes " and "filesystemio_options = asynch" are exclusiveWhere did you get the information these two parameters are exclusive?
    HTH -- Mark D Powell --

  • Initial Parameter DB_WRITER_PROCESSES Doesn't work

    I set the initial parameter DB_WRITER_PROCESSES as 5 in init.ora file. But when I restarted the database, I found the parameter show as 1 and only DBW0 existed.
    I don't know the reason, would you please help me?
    Thanks and Best Regards,
    Su Qian

    Did you get a message in the alert log about starting dbwr processes failed?No, I havn't gotten the message.
    Also, having multiple writers on a single cpu system could bring performance down. I think one rule of thumb is to have 4 cpus per writer.Thanks for your message. I will not re-set the parameter.
    First, I'd like to let you know that the environment of my production database are as follows:
    OS: HP-UX
    Database Version: Oracle8 Enterprise Edition Release 8.0.4.2.1 - Production
    The setting of DB Block: 2K
    The main problem I come across is when running application the response speed of DB is very slow.
    The first step I adopted was checking free space. After checking I thought it was sufficient. But when I adopted the second step checking v$system_event, I found the wait time of following events is high.
    EVENT TOTAL_WAITS TOTAL_TIMEOUTS TIME_WAITED AVERAGE_WAIT
    db file parallel write 471 1 128370 272.547771
    log file parallel write 30307 0 51440 1.69729765 (For reference)
    pmon timer 37189 36806 11111071 298.773051
    rdbms ipc message 142737 112253 66295957 464.462312
    rdbms ipc reply 296 0 7167 24.2128378
    smon timer 372 369 11082933 29792.8306
    write complete waits 75 37 5149 68.6533333
    According to the above message, I decided to tune I/O first. Is my thought right?
    If dbwr is rather slow, these events should give som hints: free buffer waits, rdbms ipc reply, log file switch (checkpoint incomplete).Yes, when I had a look at the alert.log I found the error message: checkpoint incomplete. So I created a new log group.Perhaps the problem was too few log groups and not dbwr. If you do not have high free buffer waits dbwr should be ok :)I agree with you. I havn't high free buffer waits, so the main problem could be too few log groups. But I don't understand two points as follows.
    1. Last Friday I had 4 log groups and the size of every group is 2M. when getting the message "Thread 1 cannot allocate new log, sequence 87816 Checkpoint not complete", I created a new log group of 2M. Normally, this operation should improve performance, but when I observed the statistics I found the average wait time of "db file parallel write" became more longer. (Please refer to the following list)
    EVENT TOTAL_WAITS TIME_WAITED AVERAGE_WAIT DATE LOG_GROUPS
    db file parallel write 471 128370 272.547771 2002-08-05 5
    db file parallel write 798 88568 110.987469 2002-08-03 4
    2. I think the shortage of log groups is caused by the archive of log group don't complete before overwirting. From the alert.log file I found the time of log switch is about 20 minutes. From my viewpoint 20 minutes is enough for log archive. Why is the log groups still short?
    In addition, according to the setting of checkpoint parameters I think the checkpoint should occur only at the time of log switch.
    NAME TYPE VALUE
    db_block_checkpoint_batch integer 8
    log_checkpoint_interval integer 1000000
    log_checkpoint_timeout integer 0
    db_block_max_dirty_target integer 4294967294
    db_block_buffers integer 153600 (For reference)
    Do you know the meaning db_block_checkpoint_batch? (I can't find it in the document of 8i, because it is obsoleted.)
    From the alert.log file, I got the following errors.
    1. Fri Aug 2 17:10:36 2002
    Errors in file /lims/oradata/lab1/udump/ora_10976.trc:
    ORA-00600: internal error code, arguments: [1237], [], [], [], [], []
    (I got the error message occasionally.)
    2. Fri Aug 2 16:57:37 2002
    ORA-1652: unable to extend temp segment by 256 in tablespace TEMP
    (I don't understand it clearly, because the size of temporary tablespace is 400M. I think it is large enough.)     
    3. Fri Jul 26 12:00:17 2002
    Thread 1 cannot allocate new log, sequence 87816
    Checkpoint not complete
    Current log# 1 seq# 87815 mem# 0: /u02/oradata/lab1/db/redolab101.log
    Looking forward your reply.
    Thanks and Best Regards,
    Su Qian

  • DB_WRITER_PROCESSES

    What is the maximum number of DB_WRITER_PROCESSES can allow?
    How can we increase the number of DB_WRITER_PROCESSES?
    Is there any performance issue allowing more DB_WRITER_PROCESSES?
    Regards

    I just want to note the fact that there are some arguments about the appropriate count of dbwr.
    These days, almost every enterprise level file system(whatever it is called) provides high performance asynchronous I/O capability. Do multiple dbwr processes have meaning here? Especially when your I/O request is handled at asynchronous way?
    What do you think about this?

  • In synch_io mode is db_writer_processes=cpus ok or do I need dbrw_io_slaves

    Using 11.2.0.3.0 on sun unix sprac server, 8 cpus. Due to OS bug we can not run in asynch i/o mode (we set disk_asynch_io = false). Our next window for OS fix is June.
    in meantime DBA says that setting db_writer_processes = # of cpus(8) is all we need. i mentioned that docs say that dbrw_io_slaves should be set to > 0 but he says that that setting is depreciated and not needed that db_writer_processes is all we need. In fact he says that he doesn't think that going back to async i/o is going to make much difference. now management is thinking if it aint broke why fix it, why risk OS upgrade if things aren't broken. I brought that on our db log file synchs are 100 to 1 to db sequential and scattered reads and that that is not good, and that we are about to hit our busiest time.
    So is db_writer_processes setting all we need to deal with running in synch I/O mode or will setting dbrw_io_slaves be a plus. Unfortunately we do hav a window to test different settings and their impact on performance. I respect the people here and so do my bosses.

    Hi,
    Could you please use the code tags to format your code? Read about how to do that in the [url https://forums.oracle.com/forums/help.jspa]FAQs. It makes it a lot easier for everyone and you will get more responses.
    You mean the top 5 sessions over the last 3 days for the log file sync wait event? I assume you've said 3 days because you are looking at the v$system_event view which is cumulative since startup? Please confirm.
    The response times look pretty bad for the log file sync event - I'm looking at the average_wait time there, which is in milliseconds. On my system, for example, we have 1ms response time and we generate 5MB of REDO a second. Obviously there are many factors to consider but you wnat to get it as low as possible.
    How does the load on the disks look? Do you have your REDO logs on the same drives as your data files?
    Feel free for someone else to correct me if you think I'm wrong on this but my thoughts are that you have two issues.
    1) Async vs sync for I/O. I would say async is better but you'd have to test it for your application and load profile
    2) High log file sync wait event, which is synchronous because of what I mentioned earlier so I don't rhink running in async mode would help here
    Do you have an AWR report you can paste out here (using the code tags)? Not the whole thing, just the key parts at the top of the report.
    Rob

Maybe you are looking for