Hi Everyone. I was looking for some advice on this error with regarding to disk maintenance and it's influence on the DB2 databases.

I have migrated my DB2 data between two SAN disks (LUNs). The SQLLIB Bins are all on a local disk, only the data and logs are on a SAN drive. This is an operation we have tested on a Staging environment without problem at all so I believe it might be related to the data itself or it's organisation or lack of it

Basic procedure:

1. Attach a new bigger SAN disk to the DB2 server.
2. Copy all the data from the existing disk (N: ) to new drive (P: )
3. Rename the drives of the new P: SAN disk to become N:
4. Restart the DB2 which remains unaware of the disk change (or supposed to be).

After this operation the production server was able to perform small searches without too much hassle but if i used a really broad search (*) after 20-30 seconds I receive:

SQL0980C A disk error occurred. Subsequent SQL statements cannot be processed via the Content Manager 8.3 interface.

When I rolled back the change, the previous SAN disk can easily be reattached and swapped out, it's all back to normal.

So am I missing some critical requirement to reorganise my data, I have no clue why DB2 would run some easy searches but barf on larger ones. DB2 starts fine, appears to operate absolutely normally form the Control Centre. Previously the bigger searches did work, they might take 30seconds or so from a cold start.

Any tips?

Thanks
Oli

Check db2diag.log for a more detailed error message.

Permission issue?
If you copied the Files with a different user than DB2 is using, then DB2 might have insufficient permissions. (Just a guess)

Hi Guys,

I have quite a lot of incident report paperwork on this issue but at a glance I can't see anything weird in the DB2DIAG.log level3 (warnings and errors) but I need more time to really dig, I can't believe nothing was logged.

Re: Permissions. The strange thing is that DB2 was basically fully operational for light weight searches and returned results quick enough to appear to be a success. It was only when I did a * (which I guess is a table scan) it barfed with the disk error.

My early guess is that I need to do some sort of data manipulation in order to acustome DB2 to it's new IO and disks subsystems. Maybe activities like REORG, RUNSTATS and REBIND might be required but as I don't understand why i'm not keen to risk it on production.

I'm also asking the Infrastructure teams if that the new SAN disk (on HP 8100 ) might be killing the IO because it thinks it rogue process where as the old disk (on Pillar Axiom) would quite happy serve IO for searches that took 45minutes.

The mystery continues.