By now you’ve probably heard about the recently release version 15.5 of ASE. The main feature of ASE 15.5 is its In-Memory Database feature, for delivering ‘Extreme Performance’ (more information is here).
However, there is another interesting feature in ASE 15.5 which is worth mentioning: the so-called ‘Incremental Data Transfer Utility’. This feature offers a new way of extracting data from an ASE table, which is much faster than can be achieved by classic methods, like BCP-out. Moreover, it’s not just faster (more…)

So, it has been a while since I wrote one of these – needless to say, I have been busy and have been to some interesting places in between. One of those places is the synthesis for this post while working with Adaptiver Server Enterprise.

There I was – thousands of miles away from home at a customer site having performance issues with the staff pointing out physical reads in sp_sysmon on devices there should have been no reads on as the tables should be in cache. I was pretty certain that it was system table accesses (and such physical reads were helping slow the system) and that this was more a symptom of a bigger problem than a root cause……so, I suggested creating a named cache just to hold the common system tables. This is a trick that many larger customers have done for years – create a separate named cache just for system tables – as there is a distinct difference between metadata cache and system table contents. So, we started to create the system named cache – but as with syslogs, you can’t bind system tables to a named cache with the applications online as the database needs to be in single user mode. And as with any self-respecting 24×7 system, that means waiting for months until the next down time….except this customer was following a really great strategy of switching their primary database between two systems via Replication Server every week or two (a very good strategy I have seen at other customers and wish all did it) – so we could set it up on the standby and when the next flip occurred it would be there. But, like most experienced DBA’s, the customer just didn’t want to do something just because I suspected something – they wanted to see if that actually was part of the problem and wanted to learn how to spot it…..especially as the next scheduled flip wouldn’t happen until after I was gone….and if that wasn’t the problem….weeelllllllll…..we all know the fall-out from that.

I really hate that – “prove it” becomes kinda like “stump the chump”.
(more…)