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 47I 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) -
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?
nullDo 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 ?
RegardsHi 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
-
Problem with Java Studio Creator and Tomcat Server
Hi Gays , I have problem: here is the error from tomcat 5 com.sun.rave.web.ui.appbase.ApplicationException: org.apache.jasper.JasperException: java.lang.RuntimeException: java.sql.SQLException: statement handle not executed: getMetaData com.sun.rave.
-
How do I check the current number of users connected to the application?
Hi there, I would appreciate that you advise me on how to know how many users are accesing an application I've got in production, powered by BEA WebLogic Server 6.1. In the Administration console, I go to the specific server, and inside the tab "moni
-
Problems with reinstalling Office 2010 for windows 7
So, I had Office 2010 installed on my PC. Then for some problems with other programs, I had to format my PC. Then, I opened Microsoft Office 2010 to reinstall it, then I inserted the product key I've written on a sheet, and it gave me error: the prod
-
HI, I've been having trouble with ( IE) Internet Explorer 11 version:(11.0.9600.17207IS )-(KB2962872) for over a year on my desktop with ANZ Internet banking, when i go into this website, it freezes and comes up" Anz isn't responding" and then in
-
Strange PCI inventory from prtdiag -v on E2900
I am attempting to solve a performance issue on a E2900 server. Line traces of the Fibre Channel are pointing towards bus congestion inside the host. (Incoming frames are being processed slowly, and outgoing frames are dribbling out, one-by-one.) I h