DBWR process

I've set db_writer_processes=2 in my Oracle EE Server 8.0.5.1 init.ora file on RH Linux 6.0.
I start up the base. Everything is OK. I check my ORA processes (by ps command) and see two db writers (ora_dbw0_sid and ora_dbw1_sid).
Some time later (hour, day, some days) I review these processes in system and do not see any of them.
Why?

This is not an interMedia question. I would urge you to ask to other discussion forums such as the Linux forum.

Similar Messages

ORA-00471: DBWR process terminated with error when running mrua.pl

we are upgrading to Portal 10.1.4 from 10.2.0.2.
Right in the middle of the upgrade scripts running get ORA-00471: DBWR process terminated with error...
Any suggestion?
TIA

sorry, it is me agin:
I forgot:
it must a trace file produced by PMON because it was PMON who killed the instance.
These background processes function as watchdogs for each other. If one finds that one of the others is missing it will kill the instance.
Regards,
Lutz

ORA-00471: DBWR process terminated instance with error...

we are upgrading to Portal 10.1.4 from 10.1.2.0.2
Right in the middle of the upgrade scripts running get ORA-00471: DBWR process terminated with error...
Any suggestion?
TIA

the only trace file referred in alert below:
/u01/oracle/infr10.1.2/admin/iaspl14/bdump/iaspl14_pmon_30175.trc
Oracle Database 10g Enterprise Edition Release 10.1.0.4.2 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/oracle/infr10.1.2
System name: Linux
Node name: sandbox3.e-hms.net
Release: 2.6.9-67.ELsmp
Version: #1 SMP Wed Nov 7 13:58:04 EST 2007
Machine: i686
Instance name: iaspl14
Redo thread mounted by this instance: 1
Oracle process number: 2
Unix process pid: 30175, image: [email protected] (PMON)
*** 2007-12-20 11:52:04.239
*** SERVICE NAME:(SYS$BACKGROUND) 2007-12-20 11:52:04.201
*** SESSION ID:(400.1) 2007-12-20 11:52:04.201
error 471 detected in background process
ORA-00471: DBWR process terminated with error

ORA-00471: DBWR process terminated with error

Dear all,
I got this error in alert log and database got down.
ORA-00471: DBWR process terminated with error
Wed May 24 19:17:37 2006
PMON: terminating instance due to error 471
Instance terminated by PMON, pid = 11642
Wed May 24 19:28:15 2006
I am having 10g R1 on LINUX.
To find cause of error.I read somewhere that I should check sid_dbwr_*.trc file.
But there is no file bdump related to DBWR.
According to me there must be atleast one trace file of DBWR in bdump.
Can you tell me why there is no trace file of DBWR in bdump and how can I ensure that i find trace files of dbwr in bdump.
Waiting for your reply,
Regards,
Amit.
Message was edited by:
Amit Singla

sorry, it is me agin:
I forgot:
it must a trace file produced by PMON because it was PMON who killed the instance.
These background processes function as watchdogs for each other. If one finds that one of the others is missing it will kill the instance.
Regards,
Lutz

Multiple dbwr processes

Hi,
just looking for peoples thoughts on how many dbwr processes a system should have.
We have a database instance doing OLTP 24 * 7, with a single dbwr but linux ASYNC I/O enabled.
The server has 8 logical cpus and the thought is that there should be a dbwr process for each cpu.
My understanding however was that with ASYNC I/O enabled at OS level that the database required just a single DBWR process.
regards
Alan

Pavan Kumar wrote:
Hi,
I read this with respect to ORACLE 8i Verison and check with respect 9i.
Will the result of cpu_count parameter be different from the fixed table you mentioned?
Are you sure on this.. ??
Refer : http://www.pvmehta.com/new/db_writer_process%20or%20dbwr_io_slaves.htm (History ;-))
Let me know ur views..waiting for your comments.
- Pavan Kumar NPavan,
AFAIK, the db_writer_processes will be equal to the number o LRU Latches (db_block_lru_latches), since each latch set will be handled by one db_writer process. But From 9i version the "db_block_lru_latches" is hidden and the db_writer_processes must be less than the number of CPUs .Either you read and understood it wrong or I am missing something? Where it is mentioned that LRU latches are going to control the DBWR process?
Here is the link to 8i,
http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76961/ch131.htm#50255
DB_BLOCK_LRU_LATCHES specifies the maximum number of LRU latch sets. The buffers of a buffer pool are equally divided among the working LRU latch sets of the buffer pool so that each buffer is protected by one LRU latch. Normally, the more latches you specify, the less contention exists for those latches. However, too many latches may result in small LRU lists, potentially reducing the cache life of a database block. The maximum of (CPU_COUNT x 2 x 3) ensures that the number of latches does not exceed twice the product of the number of CPUs and the number of buffer pools.LRU latch control the buffers movement in the LRU list within one workarea. Workareas are 2*cpu_count( I need to check that whether the same is true for 10g or not) so this means that there will be 1:1 relationship between LRU latch and one workarea. Now , here there "may be" a possibility that one DBWR may not be sufficient for the entire cache so there may be a need for multiples of them.But still, that doesn't signfy anywhere that the LRU latches and DBWRs are supposed to be in 1:1 ratio or the former control or determines the other.Itmay be a need that one has to go for mor e number of DBWRs. But that still doesn't mean that there must to be a DBWR for one workarea set in correlation with LRU latch.
I couldn't find any given reference in 9i or beyond as the parameter was deprecated from 9i. Can you point me to the 9i docs where it is mentioned?
I didin't understand the link that youhave given.Its seems to be never updated beyond oracle 8 and a lot has changed since.I don't see that its of much use.
Lastly, I asked about the X$ table that you mentioned for the number of CPUs,
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> show parameter count
NAME                                 TYPE        VALUE
active_instance_count                integer
cpu_count                            integer     2
db_file_multiblock_read_count        integer     16
plsql_native_library_subdir_count    integer     0
SQL> select KVIIVAL from X$KVII where KVIITAG='ksbcpu'
2 /
no rows selected
SQL> select KVIIVAL from X$KVII where KVIITAG='KSBCPU';
no rows selected
SQL>I have got no result from the query of yours while simply the parameter is giving number of cpus.
Cheers
Aman....

Motive of checkpoint and SCN using with DBWr and LOGWr processes ??

What checkpoint has to do with log writer process i am not getting exactly ?..
Like see i fire 1 update query and apparently it is generating some redo blocks which in turn will come to my redo log files now in tihs whole cycle where the checkpoint will occur and why??
1)My update query
2) take locks
3)generate redo
4)generate undo
5)Blocks are modified but they are still in redo log buffer...
now this blocks eventually comes to redo log files in this whole way where check pointing take place and why??
checkpoint also takes place when Datablocks are flushed to datafiles again the same reason why??
Same way around the same question the what checkpointing has to do with DBWr process also i am not clear...
Apart from this whole picture SCN is generated when user issue comitts..and we can say SCN can be used to identify that transaction is committed or not.?
So what is the motive of SCN to update in Control file...MAy b to get the latest transaction committed..??
Sorry one thread with so much questionss..but this all things are creating a fuzzy picture i want to make it clear thnx for your help in advance ..
I read documentation but they havent mentioned in depth for checkpointing..??
THANKS
Kamesh
Edited by: 851733 on Apr 12, 2011 7:57 AM

851733 wrote:
What checkpoint has to do with log writer process i am not getting exactly ?..And where exactly did you read that it has anything to do with it? How did you come up to the relation anyways? The time checkpointing would come into the play with the log files would be when there would be a log switch and this would induce a checkpoint, causing/triggering the DBWR to write the dirty buffers to the datafile and allowing the redo log group to be reused. That's about it.
Like see i fire 1 update query and apparently it is generating some redo blocks which in turn will come to my redo log files now in tihs whole cycle where the checkpoint will occur and why??
1)My update query
2) take locks
3)generate redo
4)generate undo
5)Blocks are modified but they are still in redo log buffer...
now this blocks eventually comes to redo log files in this whole way where check pointing take place and why??Read my reply above, at the time of writing the change vectors in the log file, there won't be any checkpointing coming into the picture.
checkpoint also takes place when Datablocks are flushed to datafiles again the same reason why??Wrong, the checkpoint event would make the dirty buffers written to the dataflile. Please spend some time reading the Backup and Recovery guide and in that, instance recovery section. In order to make sure that there wont be much time spent in the subsequent instance recovery, it would be required to move the dirty buffers periodically to the data file. THis would be caused by the incremental checkpoint . Doing so would constantly write the content out of the buffer cache thus leaving few buffers only as the candidate for the recovery in the case of the instance crash.
Same way around the same question the what checkpointing has to do with DBWr process also i am not clear...Read the oracle documentation's Concept guide again and again as long as it doesn't start getting in sync in with you(and it may take time). One of the events , when DBWR writes , is the occurance of the Checkpoint. Whenever there would be a checkpoint, the DBWR would be triggered to write the buffers (dirty) to the datafile.
Apart from this whole picture SCN is generated when user issue comitts..and we can say SCN can be used to identify that transaction is committed or not.? Not precisely since there would be a SCN always there , even when you query , for that too. But yes, with the commit, there would be a commit SCN that would be generated including a commit flag entered in the redo stream telling that the transaction is finally committed. The same entry would be updated in the transcation table as well mentioning that the tranaction is committed and is now over.
So what is the motive of SCN to update in Control file...MAy b to get the latest transaction committed..??Where did you read it?
Sorry one thread with so much questionss..but this all things are creating a fuzzy picture i want to make it clear thnx for your help in advance ..
I read documentation but they havent mentioned in depth for checkpointing..??
Read the book, Expert one on one by Tom Kyte and also, from documentation, version 11.2's Concept guide. These two would be more than enough to get the basics correct.
HTH
Aman....

DBWR / LGWR PROCESSES

Hi,
On what basis dbwr processes and lgwr processes should be increased. Please give me clear understanding of the same. How to identify need of dbwr and lgwr processes should be increased as well how many it should be increased

check :
http://www.dba-oracle.com/t_dbwr_database_writer_tuning_tips.htm
lgwr can be increase pr not

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

High Resident and Virtual memory for DBWR

Hello All
on 64 bit RHEL5 with physical memory of 98gb.
I see in OEM db console for 11gR2 database that dbwr processes is consuming 21gb of Resident and Virtual memory.
There are 3 dbwr processes (all using 21g) running and i see swapping happens even there is not much load on database .
Is it normal for dbwr to allocate such high memory ?
other memory config
sga_max_size big integer 60G
sga_target big integer 39808M
pga_aggregate_target big integer 10G

That is an excellent document.
The one thing you have to remember when looking at memory usage of Oracle processes, is they all attach to the same set of shared memory so your values will look high. For example if you assume your sid is XE and run the following command you can get something like this.
ps -eo pid,pmem,pcpu,rss,vsz,args | grep -i XE
29259 0.3 0.0 15004 869972 xe_j000_XE
29305 0.0 0.0 792 6560 grep -i XE
30927 0.2 0.0 10500 870080 xe_pmon_XE
30929 0.2 0.0 8520 869464 xe_psp0_XE
30931 1.4 0.0 58692 869464 xe_mman_XE
30933 5.9 0.0 241388 894124 xe_dbw0_XE
30935 0.3 0.0 14188 885016 xe_lgwr_XE
30937 0.5 0.0 21372 869984 xe_ckpt_XE
30939 2.8 0.0 114928 871024 xe_smon_XE
30941 0.3 0.0 14420 869464 xe_reco_XE
30943 1.3 0.0 55860 871060 xe_cjq0_XE
30945 1.3 0.0 56168 872216 xe_mmon_XE
30947 0.3 0.0 12360 869464 xe_mmnl_XE
30949 0.6 0.0 28260 870348 xe_d000_XE
30951 6.2 0.0 253720 875060 xe_s000_XE
30953 5.6 0.0 227984 875020 xe_s001_XE
30955 5.8 0.0 239556 875068 xe_s002_XE
30957 5.0 0.0 204960 875056 xe_s003_XE
30959 4.2 0.0 174516 875080 xe_s004_XE
30961 5.7 0.0 232812 875028 xe_s005_XE
30963 4.4 0.0 179788 875004 xe_s006_XE
30965 3.2 0.0 132100 874988 xe_s007_XE
30967 2.5 0.0 101676 874980 xe_s008_XE
30969 2.0 0.0 82304 874976 xe_s009_XE
30973 0.4 0.0 19980 885016 xe_arc0_XE
30975 0.4 0.0 19936 885016 xe_arc1_XE
30979 0.2 0.0 9672 869464 xe_qmnc_XE
30985 0.2 0.0 10932 869460 xe_q000_XE
30987 0.2 0.0 9004 869460 xe_q001_XE
Notice how my virtual size is all close to 875Mb for each process more than available with ram and swap space. That is because they all attach to my SGA thus the OS reports the SGA in it's memory listing.
Edited by: user652447 on Apr 11, 2011 9:56 AM

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.

Kernel: Out of Memory: Killed process 17402 (oracle) on 9.2.0.8.0 - 64bit

Hello,
After two months testing this server, the instance crash due two out of memory conditions.
The alert say :
Pmon end Instance and
ORA-00471: DBWR process terminated with error
Browsing the log at system level I found that kernel oom-killer kill to DBWR and LGWR process, thus crashing the instance.
I'm running a 5 Gygas SGA on a 8gygas RAM memory and the workload is very low, because this server is on testing phase, also the crash was at 4:00 am, not people work at this time.
The linux kernel is :
Linux albor-produccion.asefa.es 2.6.9-89.0.0.0.1.ELsmp #1 SMP Tue May 19 05:31:20 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
And the distribution is Oracle Linux
Red Hat Enterprise Linux AS release 4 (Nahant Update 8).
I've search some for this topic but is not clear the action to take to avoid this condition.
Any would help?
Many thanks
Arturo

Hello,
The parameter is set to kernel.shmmax=4294967295 that is 4GB.
And the SGA (5gygas) is then split:
bash-3.00$ ipcs -ma
---- Segmentos memoria compartida ----
key shmid propietario perms bytes nattch estado
0x00000000 32768 oracle 640 2097152 18
0x00000000 65537 oracle 640 4278190080 18
0x68b09434 98306 oracle 640 985661440 18
0x00000000 491533 root 777 196608 2 dest
The operating system is 64bits and the paratemeter filesystemio_options is set to "setall" this turn on ASYN I/O (The Oracle kernel was releinked manually) and Directo I/O to by pass OS buffer cache.
This server is running under VMWARE virtual env. With 8G ram plus 8 gygas swap.
And when the crash happen the memory demand was very low, because no users/process were active at this time. Then I don't see very clear the memory stress to shoot the oom killer.
Herbert, you talk about some fix to reduce oom-killers. How can I apply this? From OM are not available- bug 7566319,6086839
Thanks
Arturo

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

Physical standby crash leads to peculiar process behavior on primary nodes

Hey all, we had an issue early this morning with our physical standby database in our production environment. It's an odd problem and I thought I'd share it to see if anyone else has come across a similar problem.
Our environment consists of a two node RAC cluster running 10.2.0.2 Enterprise on Red-Hat x86-64 Linux boxes. We have implemented a single physical standby at a remote site using real-time log apply.
Upon arrival this morning I discovered that a large portion of the primary database activity was a wait class event(ARCH wait on SENDREQ). The problem was quickly identified as a network issue between our site and the remote standby. However, the physical standby seemed to be running normal, with no messages in the alert logs regarding network disconnects. Further investigation showed that our log-apply had stopped all together early that morning. It seems the DBWR process crashed around 630am, as per this trace dump:
*** 2008-02-27 06:24:53.667
Waited for detached process: DBW0 for 300 seconds:
*** 2008-02-27 06:24:53.667
Dumping diagnostic information for DBW0:
OS pid = 10587
loadavg : 12.11 11.67 8.95
memory info: free memory = 0.00M
swap info: free = 0.00M alloc = 0.00M total = 0.00M
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
0 S oracle 2448 31813 0 78 0 - 13190 wait 06:07 ? 00:00:00 /bin/sh -c /usr/bin/gdb -quiet -x
/tmp/stacknvvano
/proc/10587/exe 10587 < /dev/null 2>&1
0 S oracle 2449 2448 0 78 0 - 38780 wait 06:07 ? 00:00:00 /usr/bin/gdb -quiet -x
/tmp/stacknvvano /proc/10587
/exe 10587
0 D oracle 10587 1 0 76 0 - 43072 - Jan04 ? 00:04:09 ora_dbw0_schclsdb
So what we did was restart the standby server and the database came up fine. We reinitiated log apply services and both databases did sync up. However
we are still seeing the "ARCH wait on SENDREQ" wait event from ARC0 and ARC1 on both the RAC instances.
We tried reseting the connection to the standby database, however did this not clear up the wait event. The system itself, as far as I can tell is not suffering, and redo logs are going across to the standby database without issue. What could be the problem with the ARC0 and ARC1 processes?
It would probably be helpful to mention that we don't actually use the ARCH processes for the log apply unless the standby falls behind. Archiving is handled by the local LNS process and remote RFS service. A quick instance restart would fix it, to be sure, but since this is happening in a production deployment in a 24x7 environment, I'd rather not have any downtime. A service request is of course filed, but since they have not gotten back to me yet and Metalink hasn't been of much help, I thought I'd see if any of you have seen this before. This giant gray blob on my grid control histogram is quite obnoxious. =) Thanks for taking the time to read. Cheers.
-Jim Henaghan

Just as an update to anyone else who may have this problem, we haven't found a good way to clear up our Archiver issue, so a instance restart will take place. Further research indicates the issue came about from a MRP process crash due to a known bug fixed in 10.2.0.4 (https://metalink.oracle.com/metalink/plsql/f?p=130:14:316259464254960300::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,5894403.8,1,0,1,helvetica)

Concepts about Archieving process and Check point Background process

I am still going through Oracle Architecture and presently on the background oracle process. I got struck about the function of Checkpoint process and how archieving process occurs. Any inputs from my friends here will be highly appreciated.

916438 wrote:
I am still going through Oracle Architecture and presently on the background oracle process. I got struck about the function of Checkpoint process and how archieving process occurs. Any inputs from my friends here will be highly appreciated. Checkpoint is an act of cleaning the dirty blocks from buffer cache to disks in order to make fast recovery(if happens) if crash happens. Having said this, this process will make sure that oracle has to recovery minimum numbers of dirty block on instance recovery phase. So there is periodic flushing of dirty blocks from buffer cache to disks. In this periodic time CKPT process will post to DBWR process to write out the dirty blocks to disks. This is basically called the incremental checkpointing.
In incremental checkpointing oracle will keep the record of most oldest block in controlfile and from this block (which is also called RBA), oracle will start recovering dirty blocks.
There is also a full checkpoint in oracle which happen when redolog switch
Now coming to archiving: An archive log is a copy of redo log files, it includes the sequence number and redo entries. Whenever there is a log switch (redo log files gets filled in circular fashion), then arch process will start archive filled redo log file. So during this process arch process will read the filled redo log files and make the copy of it in archive file. LGWR cannot write this filled redo file until ans unless arch process completes copying of redolog entries to archive log file.
Archive log files are required for recovery if in future we wish to recover database during media/datafile/controlfile failure.
Also see
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:19311485023372 - Checkpoint explained
http://docs.oracle.com/cd/B19306_01/server.102/b14231/archredo.htm - Archives
Edited by: 909592 on Mar 25, 2012 5:34 PM

DBWR Behaviour Change

Hi,
We are currently experiencing a change in behavior on our performance testing environment with regards to the size of the writes issued by the database writer.
In our case we have a table partition which resides on its own LUN and is 100% inserts (no indexexs, constraints etc). Previously the writes to this LUN were approximately 100K as observed in IOSTAT and dba_hist_filestatxs database table. The I/O profile using Sun Storage Performance Analyser (SWAT) also reflects this and indicated the majority of I/O on this LUN is sequential.
We have always had 8K writes to another LUN which does more random I/O.
We are now seeing that the writes sizes have now dropped to approximately 16K indicating that the dbwr is not coaelesing the writes in the same way and the I/O profile appears more random.
Does anybody have any feel for what may influence this behaviour?.
The one change that we are seeing at the I/O level is that our I/O service time has increased, so I am wondering if the DBWR process would change its behaviour if it detected longer response times for db_file_parallel_write events.
Any theories would be appreciated.
Environment
Database Version : 10.2.0.2
OS Version: Solaris 10 SPARC64
CPU Cores : 8
Database Writers: 2
Thanks and Regards
Adrian

Hi,
We are now seeing that the writes sizes have now dropped to approximately 16K indicating that the dbwr is not coaelesing the writes in the same way and the I/O profile appears more random.Do you have problems with that?
Why are you looking at the DBWR performance rather than end-user's?
What is your db_cache_size?
Are you using async IO?
Are you aware of any changes made to the environment?
and, of course, why not 10.2.0.4?

DBWR process

Similar Messages

Maybe you are looking for