XP256 & Sybase use of raw device files

[Brian T. Borders_1]

Hi,
We have two N4000s and a K580 hooked up to a XP256 via fibre channel through two Brocade FC switches (for redundancy), not in a MC/SG environment.
Whenever one of the channels on the XP256 goes down, everything (OS, Oracle, etc.) fails over, but Sybase has problems.
The only thing we've been able to think of is that Sybase is having problems because it is using the raw device files, not an acutal filesystem.

Can anyone shed some light on this problem? Why would Sybase have problems, while every other application can handle it?
We've asked Sybase, and they haven't come back with an answer yet.

Thanks,
Jeff Norek

[Mark van Silfhout]

Hi Jeff,

It might be that you're using asynchronous access to the raw device files. This is controlled by the devicefile /dev/async, the minor number controls the handling of time-outs.
If you use a minornumber 4, like this:
/dev/async 101 0x000004, disk-timeouts will be reported to Sybase and this will trigger sybase to locate the Sybase mirror database. If you do not have a Sybase mirror database it will most likely corrupt your database.
Here are the options for the minornumbers:

0x000000 default
0x000001 enable immediate reporting
0x000002 flush the CPU cache after reads
0x000004 allow disks to timeout
0x000005 is a combination of 1 and 4
0x000007 is a combination of 1, 2 and 4

Hope this helps,

Mark

[John Tyler]

Jeff,

Did you manage to find a fix for this sybase corruption problem.
We have the same problem on sybase with raw LVs on EMC connected via Brocade Fabric.

Thanks
ven

[Vincent Fleming]

Hmm...

If you're using /dev/rdsk/c?t?d? files for raw access, you're not using PVLinks. You need to fail over to the backup path to the XP.

This can be resolved by creating volume group and LVs (don't forget the PVLinks), and accessing the LV in a raw manner (ie: /dev/sybase_vg/rlvol1).

Good luck

[John Tyler]

We use raw lv "/dev/vgXX/rlvolX" to access the devices. Whenever the primary path fails, the
alternate PV link takes over after the primary path timeout (default 30 secs).

The problem is that sybase configured to use "async i/o" driver corrupts the DB while this pvlink switchover takes place.

One option is to decrease the timeout and force the alternate PV link to take over after a shorter timeout period. But it may trigger false switchover on heavy i/o load.

This is our production and i don't have the option to testing any solution.

[Mark van Silfhout]

Ven,

The problem you describe is probably the minor number of the async driver as I mentioned in my earlier response:
If you use a minornumber 4, like this:
/dev/async 101 0x000004, disk-timeouts will be reported to Sybase and this will trigger sybase to locate the Sybase mirror database. If you do not have a Sybase mirror database it will most likely corrupt your database.
Here are the options for the minornumbers:

0x000000 default
0x000001 enable immediate reporting
0x000002 flush the CPU cache after reads
0x000004 allow disks to timeout
0x000005 is a combination of 1 and 4
0x000007 is a combination of 1, 2 and 4

So ig you use 0x000000 Sybase does not know about the failing link and will wait untill lvm has switched to the alternate path.