O/S Caching may or may not be the problem here. It may still be a device error related to running on a VM and the application you are running.
Are you properly allocating enough physical memory, CPU, etc. to the ASE guest instance?
Could there be any issues related to the ASE guest being swapped out of host memory when connections are dropped?
Did this happen when the ASE was run on a physical box? What is the setting of 'runnable process search count'? I assume at some point the ASE ran on physical hardware and has been virtualized, in preparation for the move. What needs to be understood is that older ASEs were not good candidates for virtualization without a lot of tuning. You need to still map physical resources 1:1 (e.g. memory and disk).
Your original question related to zombie processes holding locks. I hit a situation at a customer many years ago that might relate here. This is my thinking:
- ASE 12.5.4 still had APL locking on system pages
- Many stored procedures and applications use temporary tables but do not clean up.
- Clean-up is left to the SPID when the connection is dropped.
- In a high-concurrency environment, there is then contention on the APL system tables of the tempdb. The removal of the session temp tables is not completed due to the contention on the tempdb system catalogs - I believe this is the root of your zombies.
- Another side effect seen at the time was the reduction of free space in tempdb over time, requiring a reboot of the ASE eventually.
How this relates to the 1450 error, I am not sure, but the second error - 823, might be related. I wonder if the virtualization is part of the issue here (perhaps the VM is not persisting changes to the tempdb device before swapping the ASE out of memory - hence my question on resources).
Regardless, if the root cause is the concurrency into tempdb and need to clean up, you can fix this simply by dropping #temp tables in the same sp that creates them, thereby reducing the need to clean up tables at the end of the connection. It is always a best practice anyway.
If you don't want to change code, start the move to a more recent ASE anyway. To be honest you might be wasting your time and newer ASE has DRL catalogs. You need the time to look at the optimizer differences instead. (HINT: do NOT rely on 'compatibility mode').
Chris