DB_Writers or IO_Slaves ?

Hi All,
I have a concern regarding init.ora parameters "DB_WRITER_PROCESS" & "DBWR_IO_SLAVES".
Please suggest which parameter must be set to speed up the data loading rate, assuming I am using PL/SQL to load data from DW.
I am using Oracle version 10.2.0.2 on RHEL 4
Server has 4 CPU & 8GB RAM
ASM is on place but I cannot modify here as the same instance is used by another production db on same machine.
Thanks in advanced
Regards,
Bhupinder

http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams058.htm#sthref239
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm#sthref1003
To quote the propaganda:
Choosing Between Multiple DBWR Processes and I/O Slaves
Configuring multiple DBWR processes benefits performance when a single DBWR process is unable to keep up with the required workload. However, before configuring multiple DBWR processes, check whether asynchronous I/O is available and configured on the system. If the system supports asynchronous I/O but it is not currently used, then enable asynchronous I/O to see if this alleviates the problem. If the system does not support asynchronous I/O, or if asynchronous I/O is already configured and there is still a DBWR bottleneck, then configure multiple DBWR processes.
Note:
If asynchronous I/O is not available on your platform, then asynchronous I/O can be disabled by setting the DISK_ASYNCH_IO initialization parameter to FALSE.
Using multiple DBWRs parallelizes the gathering and writing of buffers. Therefore, multiple DBWn processes should deliver more throughput than one DBWR process with the same number of I/O slaves. For this reason, the use of I/O slaves has been deprecated in favor of multiple DBWR processes. I/O slaves should only be used if multiple DBWR processes cannot be configured.

Similar Messages

  • FASTER THROUGH PUT ON FULL TABLE SCAN

    제품 : ORACLE SERVER
    작성날짜 : 1995-04-10
    Subject: Faster through put on Full table scans
    db_file_multiblock_read only affects the performance of full table scans.
    Oracle has a maximum I/O size of 64KBytes hence db_blocksize *
    db_file_multiblock_read must be less than or equal to 64KBytes.
    If your query is really doing an index range scan then the performance
    of full scans is irrelevant. In order to improve the performance of this
    type of query it is important to reduce the number of blocks that
    the 'interesting' part of the index is contained within.
    Obviously the db_blocksize has the most impact here.
    Historically Informix has not been able to modify their database block size,
    and has had a fixed 2KB block.
    On most Unix platforms Oracle can use up to 8KBytes.
    (Some eg: Sequent allow 16KB).
    This means that for the same size of B-Tree index Oracle with
    an 8KB blocksize can read it's contents in 1/4 of the time that
    Informix with a 2KB block could do.
    You should also consider whether the PCTFREE value used for your index is
    appropriate. If it is too large then you will be wasting space
    in each index block. (It's too large IF you are not going to get any
    entry size extension OR you are not going to get any new rows for existing
    index values. NB: this is usually only a real consideration for large indexes - 10,000 entries is small.)
    db_file_simultaneous_writes has no direct relevance to index re-balancing.
    (PS: In the U.K. we benchmarked against Informix, Sybase, Unify and
    HP/Allbase for the database server application that HP uses internally to
    monitor and control it's Tape drive manufacturing lines. They chose
    Oracle because: We outperformed Informix.
                             Sybase was too slow AND too
    unreliable.
                             Unify was short on functionality
    and SLOW.
                             HP/Allbase couldn't match the
    availability
                             requirements and wasn't as
    functional.
    Informix had problems demonstrating the ability to do hot backups without
    severely affecting the system throughput.
    HP benchmarked all DB vendors on both 9000/800 and 9000/700 machines with
    different disks (ie: HP-IB and SCSI). Oracle came out ahead in all
    configurations.
    NNB: It's always worth throwing in a simulated system failure whilst the
    benchmark is in progress. Informix has a history of not coping gracefully.
    That is they usually need some manual intervention to perform the database
    recovery.)
    I have a perspective client who is running a stripped down souped version of
    informix with no catalytic converter. One of their queries boils down to an
    Index Range Scan on 10000 records. How can I achieve better throughput
    on a single drive single CPU machine (HP/UX) without using raw devices.
    I had heard rebuilding the database with a block size factor greater than
    the OS block size would yield better performance. Also I tried changing
    the db_file_multiblock_read_count to 32 without much improvement.
    Adjusting the db_writers to two did not help either.     
    Also will the adjustment of the db_file_simultaneous_writes help on
    the maintenance of a index during rebalancing operations.

    2)if cbo, how are the stats collected?
    daily(less than millions rows of table) and weekly(all tables)There's no need to collect stats so frequently unless it's absolute necessary like you have massive update on tables daily or weekly.
    It will help if you can post your sample explain plan and query.

  • ORACLE PROCESS의 DISK I/O PERFORMANCE CHECK

    제품 : ORACLE SERVER
    작성날짜 : 2003-06-27
    ORACLE PROCESS 가 I/O 를 과도하게 사용할 경우 조치 방법
    =======================================================
    I/O 가 heavy 하여 database 의 performance 가 떨어질 경우,
    원인을 확인하는 방법은 다음과 같습니다.
    먼저, i/o 를 빠르게 하기 위한 async I/O 가 setting 되어 있는지 확인합니다.
    async I/O 란 사용하는 H/W level 에서 제공하는 것으로, 동시에 하나 이상의
    I/O 를 할 수 있도록 해 줍니다.
    SVRMGRL 또는 SQLDBA> show parameter asyn
    NAME TYPE VALUE
    async_read boolean TRUE
    async_write boolean TRUE
    위의 값이 false 이면, H/W 가 Async I/O 를 제공하는지 확인한 후에,
    $ORACLE_HOME/dbs/initSID.ora 에 위 값을 True 로 setting 하고
    restartup 해 줍니다.
    (Async I/O 가 제공되지 않을 경우, OS channel 한개 당 하나의
    dbwr process 가 기동되도록 할 수 있습니다. db_writers 를 늘려주는 방법
    을 고려할 수도 있습니다.)
    두 번째 방법은 각 데이타 화일의 I/O를 확인해서, I/O 가 빈번한 데이타 화일을
    찾아 disk 를 옮겨 주거나 table을 다른 데이타 화일로 move해줍니다.
    다음 결과에 의해 각 datafile 의 access가 다른 datafile의 수치와 비슷할 때,
    데이타들이 잘 분산되어 I/O 병목 현상이 없는 것입니다.
    다음은 datafile 6, 7번에 read 가 집중되어 있습니다.
    만약, I/O 속도의 향상을 원한다면, 자주 read 되는 table 을 찾아서 다른 disk의
    datafile 로 옮겨 주는 것이 좋은 경우입니다.
    SQL> select file#, phyrds, phywrts from v$filestat;
    FILE# PHYRDS PHYWRTS
                  1              61667             26946
                  2              2194               58882
                  3              1972                189
                  4              804                   2
                  5              7306               13575
                  6              431859            21137
                  7              431245            3965
                  8              307                  19
    마지막으로, I/O 가 빈번한 session 을 찾아 내어 어떤 작업을 하는지
    확인하는 방법입니다.
    Session ID를 알 수 있으므로, 이 session 의 SQL 문을 확인한 후에
    I/O 를 줄일 수 있는 SQL 문으로 조정하십시오.
    (tkprof 를 이용하여 plan 과 소요 시간을 확인할 수 있습니다.)
    SQL> select sid, physical_reads, block_changes from v$sess_io
    SID PHYSICAL_READS BLOCK_CHANGES
                  1                0                0
                  2                0                0
                  3                0                0
                  4               15468          379
                  5                67               0
                  6                0                6
                  7                1               105
                  8               2487          2366
                  9               61               14
                  11             311              47

    I have seen slow iSCSI performance but in all cases it is slow on OS level already. You measurements indicate however that this is not the case but that the performance is slow just from within the guests when iSCSI disks are used.
    Two thoughts:
    - try to disable Jumbo frames. They are not standardized. While incompatible Jumbo frames typically result in a total loss of communication there might be an issue with the block sizes. Your dd tests could have been fast because of the 4K block sizes you use but the iSCSI initiator of VB may use a different block size which does not work well with Jumbo frames.
    - test the iSCSI with dd a little bit more. Use a file created from /dev/random (you can't use /dev/random directly as this is dead slow) instead of /dev/zero to avoid any interference from possible optimizations along the way. Test with different block sizes with and without Jumbo frames. What I typically get (w/ Jumbo frames) is:
    bs OSOL AR
    512 14:43 9:13
    4096 1:57 1:44
    8192 1:18 1:09
    16384 1:14 1:06
    32768 1:08 1:04 <--- sweet spot
    65536 1:08 1:08
    131072 1:14 1:11
    1048576 1:38 1:32
    Good luck,
    ~Thomas

  • 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

  • Same Query...Same DB Instance....Different results

    Hi,
    I'm running into an issue in which I'm seeing inconsistent results. If I run a query against a static table (fully committed) sometimes I receive one result set and at other times I receive another result set.This does not seem to be limited to a particular table or query. The database has been setup for a data warehouse for a client using the following init params....
    cursor_space_for_time=true
    db_block_size=16K
    db_file_multiblock_read_count=32
    db_writer_processes=[number of CPUs]
    filesystemio_options=asych
    statistics_level=ALL
    star_transformation_enable=true
    We have implemented this database/setup at least a dozen times with no issues. Does anyone have any suggestions on how to approach identifying the source of this problem? We are unable to duplicate it outside of this environment....making it difficult for us to open a TAR. The client is using Oracle 10g with all of the latest service packs.
    Any assistance would be greatly appreciated.
    Thanks!

    Hi,
    I'm running into an issue in which I'm seeing
    inconsistent results. If I run a query against a
    static table (fully committed) sometimes I receive
    one result set and at other times I receive another
    result set.This does not seem to be limited to a
    particular table or query. The database has been
    setup for a data warehouse for a client using the
    following init params....
    There have been bugs in 10g which have this effect - and I came across one quite recently. I wasn't aware of any that were still around in 10.2.0.4, though. Raise an SR with Oracle.
    cursor_space_for_time=true
    db_file_multiblock_read_count=32
    db_writer_processes=[number of CPUs]
    statistics_level=ALLProbably not relevant to your problem but these are all slightly suspect settings. You don't usually need to lock cursor frames in a data waarehouse - getting the right execution plan is usually more important than sharing existing cursors.
    10gR2 the ideal is to reset db_file_multiblock_read_count and let the Oracle maximise the efficiency of multiblock reads by itself.
    db_writers > 1 is rarely needed, and setting it to match the CPU_COUNT can be positively counter-productive (see http://kevinclosson.wordpress.com for further commentary).
    Statistics_level = all enables rowsource execution statistics and can, depending on the cost of calling the system timer, be extremely CPU intensive. (See http://jonathanlewis.wordpress.com/2007/04/26/heisenberg/ for an example).
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    "The greatest enemy of knowledge is not ignorance,
    it is the illusion of knowledge." (Stephen Hawking)

  • Write/open error

    Dear Colleagues,
    I have Oracle 7.3.4 with Sco Open Server.
    Here is a record from alert.log:
    KCF: write/open error dba=0x2800bd49 block=0xbd49 online=1
    file=5 /usr2/oradata/bb/users.ora
    error=7374 txt: 'Additional information: 48457'
    May be somebody khows what's going on?
    null

    Do you have your datafile extends through autoextend with multiple db_writers ?
    If yes it looks like a SCO specific issue
    (Bug# 916018). You can use a workaround:
    disable "autoexend"
    or
    we suggest that you first upgrade to 7.3.4.4
    and then apply the fix for this bug
    <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Yuri Khupchenko ([email protected]):
    Dear Colleagues,
    I have Oracle 7.3.4 with Sco Open Server.
    Here is a record from alert.log:
    KCF: write/open error dba=0x2800bd49 block=0xbd49 online=1
    file=5 /usr2/oradata/bb/users.ora
    error=7374 txt: 'Additional information: 48457'
    May be somebody khows what's going on?<HR></BLOCKQUOTE>
    null

  • RMAN shared_pool or large_pool

    Hi, I want RMAN to use LARGE_POOL to allocate buffers instead of SHARED_POOL.
    I use :
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    PL/SQL Release 10.2.0.1.0 - Production
    CORE 10.2.0.1.0 Production
    TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    On Windows 2000.
    SQL> show parameters large_
    NAME TYPE VALUE
    large_pool_size big integer 52M
    SQL> show parameters io_slaves
    NAME TYPE VALUE
    backup_tape_io_slaves boolean FALSE
    dbwr_io_slaves integer 1
    So after reading notes : 134214.1 47326.1 and 73354.1 I thought that RMAN will use the large_pool but when I check using:
    select * from v$sgastat where pool='large pool';
    POOL NAME BYTES
    large pool krcc extent chunk 2068480
    large pool PX msg pool 206208
    large pool CTWR dba buffer 385024
    large pool free memory 51866240
    and run a RMAN backup, the free memory does not decrease,
    but
    select * from v$sgastat where pool='shared pool' and name='free memory' decrease during backup and increase when RMAN finished.
    So from my point of views RMAN still use the shared_pool.
    Did I miss something or miss understood something ?
    Regards

    Hi Aron, no BACKUP_TAPE_IO_SLAVES = FALSE because I use disks backup only.
    I found in note 336313.1 that my sizing for large_pool_size was not enought:
    LARGE_POOL_SIZE = (No:channels * (16 + 4)) +16 Mb
    I use 2 disk channels so my 52Mb was not good I increase to 60Mb
    SQL> show parameters larg
    NAME TYPE VALUE
    large_pool_size big integer 60M
    But the result is still the same when RMAN run :
    SQL> select * from v$sgastat where pool='large pool';
    POOL NAME BYTES
    large pool krcc extent chunk 2068480
    large pool PX msg pool 206208
    large pool CTWR dba buffer 385024
    large pool free memory 60254848
    I can find KSFQ buffer in this pool.
    when I do :
    SQL> select * from v$sgastat where name like '%KSFQ%';
    POOL NAME BYTES
    shared pool X$KSFQP ANCHOR 52
    shared pool KSFQ buffer pool 2376
    We can see that only few bytes are allocated in the shared_pool.
    I have no errors in the alert.log during backup nor at RMAN level.
    I just want to know how to check where RMAN buffers are allocated.
    Regards

Maybe you are looking for