1450 Errors in Sybase Errorlog--second opinion

[#1]

01:00000:00000:2016/02/08 16:07:09.91 kernel  sddone: read error on virtual disk 52 block 13933312:
01:00000:00000:2016/02/08 16:07:09.91 kernel  sddone: Windows NT system error 1450: Unforseen error.
01:00000:01245:2016/02/08 16:07:09.96 server  Error: 823, Severity: 24, State: 1
01:00000:01245:2016/02/08 16:07:09.96 server  I/O error detected during read for BUF=0x7F2E7080, MASS=0x7F2E7080, Buf#=0

We have these errors in our ASE 12.5.4 ESD#7 Windows 2003 x86 environment running on VMWare ESX 5

This is a production environment and we are doing POC for upgrade to ASE 16, and from Windows 2003,

so let's leave the upgrade suggestions for this question.

The problem is, that it leads to zombie processes, meaning processes not running but still holding locks. That requires a reboot.

SAP says that 1450 are Windows NT error and wants to raises their hands, call it quits.

The windows eventlog does not have any event, so basically the Microsoft team raises their hands too.

is there any way we can try to pinpoint and fix with evidence?

estimate rogue queries going zombie?

like file descriptors?

paged pool errors? (although there are no events related to paged pool in the eventlog)

your replies would be greatly appreciated.

[former_member188958]

A quick search on Google found this Microsoft writeup for MS SQL Server: https://support.microsoft.com/en-us/kb/2002606https://support.microsoft.com/en-us/kb/2002606

Now, ASE isn't MS SQL Server, but they do share common roots.
The MS SQL Server message suggests it will keep retrying.
I suspect ASE doesn't know how to handle this error and isn't handling not knowing how to handle it well.  Assuming that is the case, there isn't anything that can be done about that because 12.5.4 is end-of-life for engineering support and has been for many years.

However, the MS note does suggest the problem has its roots in file fragmentation.

It might help avoid the issue to do something like this :

Truncate tempdb down to just it's initial allocation on the master device

Reboot ASE.

Drop the tempdb device and delete it from the file system

Use disk init to create a new device

Create a user database on the new device for the full size of the device, this will ensure all the space for the device is actually fully allocated all at the same time.

Drop the user database

Alter tempdb onto the new device (and any other devices it was originally on)

-bret