David,
Definitely Logical logs. Logical logs contains all of the transactions, checkpoint information, and any chunk allocations if needed.
If your database or databases are?? not logged, the Logical logs will not generate much IO since there are not transactions logged; in this case the logical logs dbspace will not be very important as far as IO.
Most of the time the databases are logged, in this case you need to look at the logging mode (Buffered, unbuffered). The buffered mode generates far less IO in the logs since the IO are done when the log buffer is full and not at commit time (less secure in case of a crash). Small transactions generate a lot of IO. Large transactions generate less logs.
I would say:
- no logging databases ==> Physical logs should have a priority
- buffered logging databases => it depends but I give the priority to the logical logs
- unbuffered or ansi mode databases => logical logs should have a priority
However, you should be aware that you can have a mixture of databases in the same instance and you can also have differents logging modes (1 database not logged, 1 database in buffered mode , 1 database in unbuffered mode, etc). Since there is one central logical log (spread in several logs),?? in this case the unbuffered database(s) will win since the commits provoke an IO in the log no matter what was in the log buffer. If you have several databases with differents logging mode, you could may be have different instances?? and group databases by logging mode.
Overall, most OLTP applications should have a priority for the logical logs instead of the physical logs.
Note: DSS databases that do not have transactions do not write in the logical logs if they are only SELECTS or mostly SELECTS. THese databases should be in a separate instance that do not give a priority to the logical logs.
So the decision depends on several things that need to be analyzed.
-- Khaled Bentebal Mobile: 33 (0) 6 07 78 41 97 Email: khaled.bentebal@consult-ix.fr Site Web: www.consult-ix.fr