Printable View
Hallo,
my DB is running with two CPUs. For more efective writing data to RAID 5 discs I try to start 4 db_writer_processes. I can start 2 but not 4 of them. Is there any rule I do not now?
Please help me! Christian
Oracle9i Release 9.2.0.1.0 - Production
PL/SQL Release 9.2.0.1.0 - Production
CORE 9.2.0.1.0 Production
TNS for 32-bit Windows: Version 9.2.0.1.0 - Production
NLSRTL Version 9.2.0.1.0 - Production
Hallo aus Heidelberg!
go check out this on meta link it should answer your problem
Hallo aus Berlin ;-)
I can´t open this link. How can I get an Oracle Support contract or the artikel?
Thank you for help!
Christian
raid 5 ?? immmm very bad for performance.Quote:
Originally posted by ckiltz
Hallo,
my DB is running with two CPUs. For more efective writing data to RAID 5 discs I try to start 4 db_writer_processes.
Last month only I say BYEBYE to Raid 5.
Now in 0,1.
Sleeping well in night.
consider changing 5.
in order to access metalink you have to have a CSI number. Whomever bought Oracle at your shop would have this information. Simply goto http://metalink.oracle.com and register an account there. It takes all of about 5 minutes to do.
If you don't have a CSI number reply back here and I'll cut and paste the note.
... It was not my decision to take RAID 5. I red in "Oracle9i Performance Tuning" RAID 5 is slow in writing but fast in reading in combination with Oracle.Quote:
Originally posted by engiri
raid 5 ?? immmm very bad for performance.
Last month only I say BYEBYE to Raid 5.
Now in 0,1.
Sleeping well in night.
consider changing 5.
Greetings from Christian
not all the oracle files in 5.
isn't it?
Sorry but I don't have a CSI number.
I only have to eMail Oracle and get one?
Christian
If your redologs are on RAID-5, moving them to RAID-1 or multiplexed non-RAID will probably help more than more db writers.
You can only have as many dbwrites as you have db_block_lru_latches. Check this parameter and increase through your init.ora if necessary. However, bumping your dbwrites past 2 on a 2 cpu box will make them compete with each other if you in fact dbwriter can't get enough CPU already AND your on non-async filesystems.
Is the parameter db_block_lru_latches an Oracle9i-Parameter?
select * From V$parameter
where name like 'db_block%';
I can not find him ...
Christian
Sorry, didn't realize you were on 9i.
... and how can I solve the problem in cunjunction with Oracle9i?
Has some body a clou?
Christian
Here, lets finish this. Here's the meta link article.
DB_WRITER_PROCESSES ===================
Multiple database writers is implemented via the init.ora parameter db_writer_processes. This feature was enabled in Oracle8.0.4, and allows true database writers; i.e., no master-slave relationship. With Oracle8 db_writer_processes, each writer process is assigned to a LRU latch set. Thus, it is recommended to set db_writer_processes equal to the number of LRU latches (db_block_lru_latches) and not exceed the number of CPUs on the system. For example, if db_writer_processes was set to four and db_lru_latches=4, then each writer process will manage its corresponding set. The parameter db_block_lru_latches has been made hidden in oracle 9i.
Things to know and watch out for.... ==================================== --
1. Multiple DBWRs and DBWR IO slaves cannot coexist. If both are enabled, then the following error message is produced: ksdwra("Cannot start multiple dbwrs when using I/O slaves.\n"); Moreover, if both parameters are enabled, dbwr_io_slaves will take precedence. --
2. The number of DBWRs cannot exceed the number of db_block_lru_latches. If it does, then the number of DBWRs will be minimized to equal the number of db_block_lru_latches and the following message is produced in the alert.log during startup: ("Cannot start more dbwrs than db_block_lru_latches.\n"); However, the number of lru latches can exceed the number of DBWRs. --
3. dbwr_io_slaves are not restricted to the db_block_lru_latches; i.e., dbwr_io_slaves >= db_block_lru_latches.
Should you use DB_WRITER_PROCESSES or DBWR_IO_SLAVES? =====================================================
Although both implementations of DBWR processes may be beneficial, the general rule, on which option to use, depends on the following :
1) the amount write activity;
2) the number of CPUs (the number of CPUs is also indirectly related to the number LRU latch sets);
3) the size of the buffer cache;
4) the availability of asynchronous I/O (from the OS). There is NOT a definite answer to this question but here are some considerations to have when making your choice. Please note that it is recommended to try BOTH (not simultaneously) against your system to determine which best fits the environment. -- If the buffer cache is very large (100,000 buffers and up) and the application is write intensive, then db_writer_processes may be beneficial. Note, the number of writer processes should not exceed the number of CPUs. -- If the application is not very write intensive (or even a DSS system) and async I/O is available, then consider a single DBWR writer process; If async I/O is not available then use dbwr_io_slaves. -- If the system is a uniprocessor(1 CPU) then implement may want to use dbwr_io_slaves. Implementing db_io_slaves or db_writer_processes comes with some overhead cost. Multiple writer processes and IO slaves are advanced features, meant for high IO throughput. Implement this feature only if the database environment requires such IO throughput. In some cases, it may be acceptable to disable I/O slaves and run with a single DBWR process.
Other Ways to Tune DBWR Processes =================================
It can be easily seen that reducing buffer operations will be a direct benefit to DBWR and also help overall database performance.
Buffer operations can be reduced by:
1) using dedicated temporary tablespaces
2) direct sort reads
3) direct Sqlloads
4) performing direct exports.
In addition, keeping a high buffer cache hit ratio will be extremely beneficial not only to the response time of applications, but the DBWR as well.