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

Similar Messages

  • 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>>

  • 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

  • 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                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • 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

  • 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).

  • 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

  • 10g db_writer_process

    Hi Brother,
    i am using 10g on T2000 with 16core, would i increase the db_writer_process? default is 2 and would like to change to 8 or 16. pls advise
    Thanks

    take a look at these metalink doc...
    Subject:      Understanding and Tuning Buffer Cache and DBWR
         Doc ID:      62172.1
    Subject:      DBWR in Oracle8i
         Doc ID:      105518.1

  • 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/

  • 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?

  • ORACLE8 OPS BACKUP & RECOVERY

    제품 : ORACLE SERVER
    작성날짜 : 2004-08-16
    ORACLE8 OPS BACKUP & RECOVERY
    =============================
    SCOPE
    Standard Edition 에서는 Real Application Clusters 기능이 10g(10.1.0) 이상 부터 지원이 됩니다.
    Explanation
    OPS에서의 database backup & recovery 방법은 single instance의 backup 방법과
    비슷하다. 즉, Single instance에서의 모든 backup 방법은 ops에서도 지원된다.
    1. Backup 방법
    다음의 backup 방법 모두 사용이 가능하다. 여기서는 2)의 os 명령을 이용한
    backup 방법에 대해 기술합니다.
    1) Recovery Manager (RMAN) : <Bulletin 11451> 참고
    2) OS 명령을 활용한 백업
    Noarchive log mode : full offline backup only
    Archive log mode : full or partial, offline or online backup
    3) export : <Bulletin 10080> 참고 : ORACLE 7 BACKUP 및 RECOVERY 방법
    2. backup 정책 수립 시 고려 사항
    1) disk crash나 user error 등으로 말미암은 손실을 허용하지 않는다면 ARCHIVE
    LOG MODE를 사용해야 한다.
    2) 대부분 모든 instance는 자동 archiving을 사용한다.
    3) 모든 data backup 작업이 어떤 instance 건 가능하다.
    4) media recovery 시 모든 thread의 archive file이 사용된다.
    5) Instance recovery 시 살아있는 instance의 smon에 의해 자동으로 recovery된다.
    3. Noarchive log mode : Full offline backup
    1) 다음의 view들을 query하여 backup이 필요한 file을 알아낸다.
    V$DATAFILE or DBA_DATA_FILES
    V$LOGFILE
    V$CONTROLFILE
    2) 모든 instance를 shutdown한다.
    3) 확인된 file을 backup destination으로 copy한다.
    4. Archive log mode : Partial or Full Online Backup
    1) 백업을 수행하기 전에 ALTER SYSTEM ARCHIVE LOG CURRENT 명령 실행(이 명령을
    실행하여 현재 운영되지 않는 데이터베이스를 포함한 모든 노드의 current redo
    log에 대한 로그 스위치와 그에 따른 아카이브를 모든 인스턴스에서 실행시킨다.)
    2) ALTER TABLESPACE tablespace BEGIN BACKUP 명령 실행
    3) ALTER TABLESPACE 명령이 성공적을 실행될 때까지 대기
    4) OS에서 적절한 명령어를 활용하여 테이블스페이스에 속하는 데이터파일들을 백업
    (tar, cpio, cp 등)
    5) OS 명령을 활용한 백업이 다 끝날 때까지 대기
    6) ALTER TABLESPACE tablespace END BACKUP 명령 수행
    7) ALTER DATABASE BACKUP CONTROLFILE TO filename 이나
    ALTER DATABASE BACKUP CONTROLFILE TO TRACE
    명령을 수행시켜 컨트롤 파일을 백업.
    만약 아카이브 로그 파일을 백업받는다면 END BACKUP 명령을 실행시킨 이후
    ALTER SYSTEM ARCHIVE LOG CURRENT 명령을 실행시켜 END BACKUP 시점까지의
    모든 리두 로그 파일들을 확보한다.
    5. Import Parameter
    1) Controlfile 내의 Redo Log History (MAXLOGHISTORY )
    CREATE DATABASE 명령이나 CREATE CONTROLFILE 명령에서 MAXLOGHISTORY 값을
    지정하여 parallel server에서 다 채워진 리두 로그 파일에 대한 history를
    컨트롤 파일이 저장하도록 할 수 있다. 이미 데이터베이스를 생성한 후라면
    log history 값을 증가시키거나 감소시키기 위해서는 컨트롤 파일을 재생성
    하여야만 한다.
    MAXLOGHISTORY는 컨트롤 파일 내의 archive history를 얼마나 저장할 수
    있는지를 지정하며, 기본값은 플랫폼 별로 다르다. 이 값이 0이 아닌 다른
    값으로 지정된다면 log switch가 발생할 때마다 LGWR 프로세스에서는 컨트롤
    파일에 다음 정보를 기록한다.
    thread number, log sequence number, low SCN, low SCN timestamp, next SCN
    (next log의 가장 낮은 SCN값)
    (이 정보는 리두 로그 파일이 archive된 후가 아니라 log switch가 발생할 때
    컨트롤 파일에 저장된다.)
    MAXLOGHISTORY 값에서 지정한 값을 넘어서 log history가 저장되어야 할 경우
    가장 오래된 history를 overwrite하는 방식으로 저장된다. Log history 정보는
    OPS에서 자동 media recovery 시 SCN, thread number를 기준으로 적절한
    아카이브 로그 파일을 찾아 재구성하는 데 사용된다. 데이터베이스를 exclusive
    모드에서 한개의 쓰레드만 사용하는 환경에서는 log history 정보가 필요하지 않다.
    Log history 관련 정보는 V$LOG_HISTORY를 이용해 조회해 볼 수 있다.
    서버 관리자에서 V$RECOVERY_LOG를 조회하면 media recovery에 필요한 아카이브
    로그에 대한 정보를 얻을 수 있다.
    Multiplex된 리두 로그 파일에 대해서, log history 내에서 여러개의 entry가
    사용되지 않는다. 각각의 entry는 개개의 파일에 대한 정보가 아니라, multiplex
    된 log 파일의 그룹에 대한 정보를 가지고 있다.
    2) Archive Log Mode 시 Parameter
    OPS에서 archive log mode로 변경 시 exclusive mode로 db mount 후에 변경한다.
    a. LOG_ARCHIVE_FORMAT
    파라미터     설명     예
    %T     thread number, left-zero-padded     arch0000000001
    %t     thread number, not padded     arch1
    %S     log sequence number, left-zero-padded     arch0000000251
    %s     log sequence number, not padded     arch251
    이 가운데 %T와 %t는 OPS에서만 유효한 파라미터이다.
    모든 instance의 format은 같아야 하며 OPS 환경에서는 반드시 thread 번호를
    포함시켜야 한다.
    예) log_archive_format = %t_%s.arc
    b. LOG_ARCHIVE_START
    - 자동 archiving : TRUE로 지정한 후 인스턴스를 구동시키면 background process
    인 ARCH에서 자동 archiving을 수행한다. Closed Thread의 경우에는 실행 중인
    thread에서 closed thread를 대신해 log switch와 archiving을 수행한다.
    이것은 모든 노드에서 비슷한 SCN을 유지하도록 하기 위해 강제적으로 log switch
    가 발생할 때 일어난다
    - 수동 Archiving : FALSE이면 archive를 시작하도록 지시하는 명령을 명시적으로
    내리지 않는 이상 동작을 멈추고 대기한다. OPS에서는 각각의 인스턴스에서 서로
    다른 LOG_ARCHIVE_START 값을 사용할 수 있다.
    다음과 같은 방법으로 수동 archiving을 수행할 수 있다.
    ALTER SYSTEM ARCHIVE LOG SQL 명령을 실행
    ALTER SYSTEM ARCHIVE LOG START 명령을 실행하여 자동 archiving을 실행하도록
    지정.
    수동 archiving은 명령을 실행시킨 노드에서만 실행 되며, 이 때 archiving
    작업을 ARCH 프로세스가 처리하지 않는다.
    c. LOG_ARCHIVE_DEST
    archive log file이 만들어질 directory를 지정한다.
    예) log_archive_dest = /arch2/arc
    6. OPS Recovery
    1) Instance Failure 시
    Instance failure는 S/W나 H/W 상의 문제, 정전이나 background process에서
    fail이 발생하거나, shutdown abort를 시키거나 OS crash 등 여러가지 이유로
    인해 instance가 더 이상 작업을 진행할 수 없을 때 발생할 수 있다.
    Single instance 환경에서는 instance failure는 instance를 restart 시키고
    database를 open하여 해결된다. Mount 상태에서 open 되는 중간 단계에서 SMON은
    online redo log 파일을 읽어 instance recovery 작업을 수행한다.
    OPS에서는 instance failure가 발생 했을 경우 다른 방식으로 instance
    recovery가 수행된다. OPS에서는 한 노드에서 fail이 발생했다고 하더라도
    다른 노드의 인스턴스는 계속 운영될 수 있기 때문에 instance failure는
    database가 가용하지 않다는 것을 의미하지는 않는다.
    Instance recovery는 dead instance를 처음으로 발견한 SMON 프로세스에서
    수행한다. Recovery가 수행되는 동안 다음과 같은 작업이 일어난다.
    - Fail이 발생하지 않은 다른 인스턴스에서는 fail이 발생한 인스턴스의
    redo log 파일을 읽어 들여 데이터파일에 그 내용을 적용시킨다.
    - 이 기간 동안 fail이 발생하지 않은 다른 노드에서도 buffer cache 영역의
    내용을 write 하지는 못한다.
    - DBWR disk I/O가 일어나지 못한다.
    - DML 사용자에 의해 lock request를 할 수 없다.
    a. Single-node Failure
    한 인스턴스에서 fail이 난 다른 인스턴스에 대한 recovery를 수행하는 동안,
    정상적으로 운영 중인 인스턴스는 fail이 난 인스턴스의 redo log entry를
    읽어 들어 commit이 된 트랜잭션의 결과치를 데이터베이스에 반영시킨다.
    따라서 commit 된 데이터에 대한 손실은 일어나지 않으며, fail이 난
    인스턴스에서 commit 시키지 않은 트랜잭션에 대해서는 rollback을 수행하고,
    트랜잭션에서 사용 중이던 자원을 release시킨다.
    b. Multiple-node Failure
    만약 OPS의 모든 인스턴스에서 fail이 발생했을 경우, 인스턴스 recovery는
    어느 한 인스턴스라도 open이 될 때 자동으로 수행된다. 이 때 open되는 인스턴스는
    fail이 발생한 인스턴스가 아니라도 상관 없으며, OPS에서 shared 모드
    혹은 execlusive 모드에서 데이터베이스를 mount 하더라도 상관 없이 수행된다.
    오라클이 shared 모드에서 수행되던, execlusive 모드에서 수행되건,
    recovery 절차는 하나의 인스턴스에서, fail이 난 모든 인스턴스에 대한
    recovery를 수행하는지 여부를 제외하고는 동일하다.
    2) Media Failure 시
    Oracle에서 사용하는 file을 저장하는 storage media에 문제가 발생했을 경우
    발생한다. 이와 같은 상황에서는 일반적으로 data에 대한 read/write가 불가능하다.
    Media failure가 발생했을 경우 recovery는 single instance의 경우와
    마찬가지로 recovery가 수행되어야 한다. 두 경우 모드 archive log 파일을
    이용해서 transaction recovery를 수행하여야 한다.
    3) Node Failure 시
    OPS 환경에서, 한 노드 전체에 fail이 발생했을 때, 해당 노드에서 동작하던
    instance와 IDLM 컴포넌트에서도 fail이 발생한다. 이 경우 instance recovery를
    하기 위해서는 IDLM은 lock에 대한 remaster를 시키기 위해 그 자신을
    reconfigure시켜야 한다.
    한 노드에서 fail이 발생했을 때 Cluster Manager 또는 다른 GMS product에서는
    failure를 알리고, reconfiguration을 수행하여야만 한다. 이 작업이 수행되어야만
    다른 노드에서 운영 중인 LMD0 프로세스와의 통신이 가능하다.
    오라클에서는 fail이 발생한 노드에서 잡고 있는 lock 정보를 access할 경우나,
    LMON 프로세스에서 heartbeat을 이용해서 fail이 발생한 노드가 더 이상
    가용하지 않다는 것을 감지할 때 failure가 발생한 것을 알게 된다.
    IDLM에서 reconfigure가 일어나면 instance recovery가 수행된다.
    Instance recovery는 recovery를 수행하는 동안 자원에 대한 contention을
    피하기 위해 전체 데이터베이스의 작업을 일시 중지시킬 수 있다.
    FREEZE_DB_FOR_FAST_INSTANCE_RECOVERY initialization parameter 값을
    TRUE로 지정하며 전체 데이터베이스가 일시적으로 작업을 멈추게 된다.
    데이터 화일에서 fine-grain lock을 사용할 경우 기본값은 TRUE이다.
    이 값을 FALSE로 지정할 경우 recovery가 필요한 데이터만이 일시적으로 작업이
    멈춰진다. 데이터 화일이 hash lock을 사용할 경우 FALSE가 기본 값이다.
    4) IDLM failure 시
    한 노드에서 다른 연관된 프로세스의 fail이나 memory fault 등의 이유로 인해
    IDLM 프로세스만 fail이 발생했다면 다른 노드의 LMON에서는 이 문제를 감지하여
    lock reconfiguration process를 시작한다.
    이 작업이 진행 중인 동안 lock 관련 작업은 처리가 정지되고 PCM lock 또는
    다른 resource를 획득하기 위해 일부 사용자들은 대기 상태로 들어간다.
    5) Interconnect Failure ( GMS failure ) 시
    노드 간의 interconnect에서 fail이 발생하면 각각의 노드에서는 서로 다른
    노드의 IDLM과 GMS에서 fail 이 발생했다고 간주하게 된다. GMS에서는 quorum
    disk나 node에 pinging 등을 수행하는 다른 방법을 통해 시스템의 상태를 확인한다.
    이 경우 Fail이 발생한 connection에 대해 두 노드 혹은 한쪽 노드에서
    shutdown 이 일어난다.
    Oracle 8 recovery mechanism에서는 노드 혹은 인스턴스에서 강제로 fail이
    발생했을 경우 IDLM이나 instance가 startup 될 수 없게 된다. 경우에 따라서는
    노드 간의 IDLM communication이 가용한지 여부를 확인하기 위해 cluster
    validation code를 직접 작성하여 사용할 수도 있다. 이 방법을 사용하여
    GMS에서 제공하지는 않지만, 문제를 진단한 후 shutdown을 수행하도록 할 수 있다.
    이같은 code를 작성하기 위해서는 단일 PCM lock에서 처리되는 단일 data block에
    대해 계속해서 update 를 수행해 보는 루틴이 들어가면 된다. 서로 연결된
    두 노드에서 이 프로그램을 실행시키게 될 경우 interconnect에서 fail이
    난 상황을 진단할 수 있게 된다.
    만약 여러개의 노드가 cluster를 구성할 경우에는 매 interconnect 마다
    다른 PCM lock에 의해 처리되는 data block을 update 함으로써, 어떤 노드와의
    interconnect에 문제가 발생했는지를 알아낼 수 있다.
    7. Parallel Recovery
    Parallel Recovery의 목표는 compute와 I/O parallelism을 사용해서 crash
    recovery, single-instance recovery, media recovery 시 소요되는 시간을 줄이는
    데 있다.
    Parallel recovery는 여러 디스크에 걸쳐 몇 개의 데이터파일에 대해 동시에
    recovery를 수행할 때 가장 효율적이다
    다음과 같이 2가지 방식으로 병렬화시킬 수 있다.
    - RECOVERY_PARALLELISM 파라미터 지정
    - RECOVER 명령의 옵션에 지정
    오라클 서버는 하나의 프로세스에서 log file을 순차적으로 읽어들이고, redo
    정보를 여러 개의 recovery 프로세스에 전달해, log file에 기록된 변동 사항을
    데이터파일에 적용시킬 수 있다.
    Recovery Process는 오라클에서 자동적으로 구동되므로, recovery를 수행할 경우
    한 개 이상의 session을 사용할 필요가 없다.
    RECOVERY_PARALLELISM의 최대값은 PARALLEL_MAX_SERVERS 파라미터에 지정된 값을
    초과할 수 없다.
    Reference Ducumment
    Oracle8 ops manual

    Configuration files of the Oracle Application server can be backed up by "Backup and Recovery Tool"
    Pls refer to the documentation,
    http://download.oracle.com/docs/cd/B32110_01/core.1013/b32196/part5.htm#i436649
    Also "backup to tapes feature" is not yet supported by this tool
    thanks,
    Murugesh
    Message was edited by:
    Murugesan Appukuttty

  • Db_writer_processes alert log message

    Oracle 11.2.0.3 running on HP-UX Itanium RX8640 with 16 CPUs and OS B.11.31
    Upgraded to 11.2.0.3 last night and now I am receiving the following message in alert.log when starting database:
    "NOTE: db_writer_processes has been changed from 4 to 1 due to NUMA requirements"
    Any thoughts on what this means?

    Is your system NUMA-enabled?
    In a NUMA-enabled box, the minimum number of DBWR process is the number of processor groups, oracle MUST start this minimum of DBWR no matter the parameter you set.
    You seem to have the opposite case, as in oracle is forcing it to 1. In this case, I'm led to believe that maybe oracle is mistakenly identifiying your system as NUMA perphaps.
    Upload the results for this:
    select  a.ksppinm  "Parameter",
    b.ksppstvl "Session Value",
    c.ksppstvl "Instance Value"
    from x$ksppi a, x$ksppcv b, x$ksppsv c
    where a.indx = b.indx and a.indx = c.indx
    and a.ksppinm = '_db_block_numa';You may try to do this:
    - Set the following OS variable in your database OS owner user profile: DISABLE_NUMA = true
    - Set the DBWR to 4 in the SPFILE and bounce the database.
    - Verify if the issue continues. In the OS: ps -ef | grep dbwr to see how many dbwr the instance spawned.

  • Async io & dbwr

    my box has Solaris 5.8,veritas FS, ODM,Oracle9206, 56CPU,120G RAM, DSS kind of application but high dataload
    1.db_writer_process(7)
    2.disk_async_io(async)
    3.filesystem_io_option(async)
    4.parallel_automatic_tuning(true)
    5.parallel_min_Servers(16)
    6.parallel_max_servers(160)
    settings. If 2 is async what could be the value of 1 and
    filesystem_io_option(async). my knowledge is multiple writer process will help in no-async environment. Is there any negative impact if 1# is > 1. I have PIOT with buffer busy waits,defile sequential read, To reduce the buffer busy waits and all, shall we do the frequent checkpointing or increase the db_writer process.
    Also I am getting ora-1555 even after increasing undo from 65 to 230G. and retention 6 to 25hr. Most of the queries are parallel queries/sub queries. what could be the proper settings
    thanks

    If you are really using ASYNC IO then you should only
    need one dbwr process.
    HTH -- Mark D Powell --Not quite true
    http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm#sthref909
    10.3.9.3.3 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.

  • MAX DB_WRITER_PROCESSES in 10g

    Hi All,
    I read the doc (Problem statement: [bug# 2441217]) from the metalink on the # of DBWRs. It says that Oracle changed the default # of DBWRs and MAX DBWRs since 9iR2.
    Default: (CPU_COUNT + 7) / 8
    Max: Min (CPU_COUNT / 2, 20)
    Is it right? I tested this on HP
    CPU_COUNT = 16, DB_WRITER_PROCESSES = 14
    Based on the new algorithm MAX DBWRs are 8. But there are 14 DBWR processes up and running.
    I think Oracle uses the privious aloghrithm even in 10g, which is based on dbblock_lru_latches.
    Any idea?

    Hi Sean,
    As I understand it, db_block_lru_latches defaults to the following formula :
    (CPU_COUNT x 6) or (DB_BLOCK_BUFFERS/50), whichever is less.
    In earlier releases it defaulted to CPU_COUNT/2. If you set DB_BLOCK_LRU_LATCHES higher than this max value on systems where it is available (<9i) or set the undocumented parameter DBBLOCK_LRU_LATCHES higher, then Oracle just ignores this and sets it internally to the above calculated value. However it will be set to Num_pools x (CPU_COUNT/2) if multiple buffer pools (default, recycle, keep and any of the multi-block size pools) are setup.
    More notes shere:
    http://www.dba-oracle.com/oracle_tips_cpu_count_wrong.htm

Maybe you are looking for

  • SQL Injection is rampant this week

    Setting of the stage: I am using cf error reporting to send me an email whenever there is an exception error on my site. I am using cfqueryparam to make sure SQL injection is not getting through Trouble: using cfqueryparam to catch the attack causes

  • Java Process in Oracle 10g AS

    Hi, The folowing process takes 50% cpu and sometimes it takes 100% cpu in Oracle 10g AS (OS version 5.8), what is the way to get ride of this problem? /ORACLE_HOME/jdk/jre/bin/java -server -cp /ORACLE_HOME Also, please let me know how to get into ora

  • Reader not honoring Page Display preferences

    Hello. I am using Adobe Reader X on Win7 Ultimate (x64). I have set the following in Edit - Preferences - Page Display: Page Layout:     Single Page Continuous Zoom:               Fit Width Resolution:        Use system setting: (96 pixels/inch) Howe

  • Common distribution channel and devision

    hi  expert i have one sales organization-0001 three Distribution channel- 01,common distribution channel,02-distribution channel,03-distribution channel and 4 divisions. Hz-common divisions.,Oz,AZ,CZ. so my clients requirement is he wants to create c

  • JSP calling a SessionBean

    I'm getting some errors with this JSP page I'm working on. The page is trying to access a sessionbean. The errors are: Error: cannot access class javax.ejb.EJBObject; file javax\ejb\EJBObject.class not found Error: cannot access class javax.ejb.EJBHo