We are in a production envirnoment using DB2. The loads will vary from time to time and day to day depending on how many orders we have in the system.

We had a system setup with the primary DB2 application and logs on drive 'C' with the active database on drive 'D'. The active database was the ONLY file or use for the 'D' drive. So I decided to move the 'active database' (not knowing the purpose) to the 'C' drive with everything else using the db2relocatetool. This made imaging the drive a little easiler and it seemed to work well with no issue

However, 2 times since the move (two-weeks) the system seemed to slow during very heavy production times where several of 50 computers connected to DB2 having their apps were very slow with slow response. However, this (slowness) has happen on rare occasion before but not 2x in two-weeks.

Does one get better system proformance when the 'active database' is located on a different drive then DB2 itself????? Maybe, this was the original purpose or does it not make a difference? If so I will move it back.

IBM sServer xSeries 345

Any other suggestions if this is a borderline load issue while under heavy use?

Let's think about what a DBMS is doing with respect to disk I/O. Every INSERT/UPDATE/DELETE/... operation that changes something in the database needs to be logged. The logs are needed to ensure no changes are lost. Thus, logs must be written quite often. Since disk access is about 1000x slower than in-memory access, log-writing can quickly become a bottleneck if the system is misconfigured.

So here are a few general guidelines:

• Place logs on a fast disk so that writing to logs does not compete with other disk activities. I would say that pretty much rules out drive C on Windows.
• Putting data on the same disk as logs is usually a bad idea. My first idea would be to attribute the slow-downs you are experience to your relocation.
• Partitioning of a single disk doesn't give you any benefit because disk access still competes for the single resource.
• Use as many physical disks as you can grab. The idea is that multiple disks can be read/written in parallel while a single disk can not.
• If possible, get disks with a large write cache (but the disk must ensure that the data in this cache is eventually be written permanentely - even in a power outage).
• Use DB2's automatic storage mechanisms and, if you have a storage system.

Another problem ....

I went to move my 'active' database back to 'D' from 'C' as it was originally configured:

db2relocatedb -f movedb.cfg

******* movedb.cfg ********
DB_NAME=prod_ph
INSTANCE=DB2
DB_PATH=c:,d:

This was successful but now I get an error because it is looking for the logs on my 'D' drive .....

I never moved the logs path but instead only the DB_PATH to the C drive and now I only reversed what I did before from d:,c: to c:,d:

Any thoughts on why it is looking for my logs on the d: drive now?

What is your DB config parameter "Path to log files" set to?

The logs were set to C:\db_logs

However, the following changed it to D:\db_logs

DB_NAME=prod_ph
INSTANCE=DB2
DB_PATH=c:,d:

I only wanted to change the DB_Path but I guess the logs 'path' went along for the ride.

Can I easily change the logs back to C:\db_logs ???

Yes, you can change the log path back to C:. Just set "NEWLOGPATH" DB CFG parameter. You have to recycle DB2.