|
We are considering changing our on-prem Sybase SQL Anywhere 17 database host from Windows 2016 to Linux. We are virtualized (VMWare), and the datastores are on an iSCSI SAN connected with 10Gb. The motivation is the quest for increased performance, for the most part. I've been doing some on-line research, but haven't really found a definitive answer to a couple questions:
Debian is our preferred distro. I found it interesting that it is not on the approved list for SQLAnywhere. |
|
I've decided that while this would be an interesting technical exercise, I don't have time or resources to experiment and test. Thanks to all who responded. |
> is it worth it?
It could be, but... I have never heard anyone say "I switched from Windows to Linux and my SQL Anywhere databases performed better"... not even once.
> is there a definitive guide?
Other than the SAP Help Portal, no; see help.sap.com/viewer/product/SAP_SQL_Anywhere/17.0/en-US?q=linux.
> same key work with Linux?
It should, which probably means it won't... licensing is one area that SQL Anywhere breaks the rule "do things the way they should be done" :)
> not on the approved list
That's not just interesting, it is terrifying.
Some questions for you: Have you looked for the reasons behind your unsatisfactory database performance? Are there bottlenecks that need removing? Is VMWare tuned for maximum database performance, or is it starving dbsrv17.exe? Is intra-query parallelism helping or hurting? ...stuff like that.
What is Foxhound telling you?
Fun fact: Debian is supported for SA on ARM...
I'm by no means a Linux expert (not even a user) but as Ubuntu is a Debian derivate and is supported, chances might be Debian should do, too...
Knowing Ubuntu's pedigree is why I thought it odd that Debian is not on the list
The Windows vs. Linux point was the most important to me. If there's no evidence of a gain, I won't spend work hours on it, thought I might experiment in my home lab.
I'm not really trying to solve bad performance, just seeing if better is possible. Foxhound is invaluable, and looking at (what I believe are) the important metrics, we are in pretty good shape: Cache satisfaction is at or near 100%, only rarely is there an unscheduled request, CPU hovers between 70%-90%, with occasional spikes and dips, wait time is usually in the dozens of milliseconds, but occasionally goes to 1s.
We do occasionally get a 'database not responsive' alert, but I think I've tracked that to a design flaw with our ERP software. Rather than leveraging autoincrement primary key fields, it has a separate table that stores the next numeric primary key for the tables. When a new record is created in a table, it first fetches/updates the value for that table from the key table. For large batch transaction like posting to GL, it locks the key table until the entire batch is processed. Because other user's operations also need access to the key table, we get blocked connections.
I'll have to go read up on intra-query parallelism. I have no idea what that is.
I appreciate the feedback.