Today, Sybase announced the next major version of SQL Anywhere: Version 12. SQL Anywhere 12 has been in development for over two years. This new version includes a great many new features. The common theme running through all these features is our effort to improve the ease-of-use experience and the self-management capabilities of the database server.
There are literally hundreds of new features, but I would like to highlight a few important ones:
Spatial Data Support
We have added comprehensive support for the storage, manipulation, and synchronization of spatial data. You can now store location information, and then access it in your database queries, allowing for very powerful applications. Spatial data and synch is supported on all SQL Anywhere supported platforms, including servers and handheld devices. Both Eric Farrar and myself have written about spatial support previously here and here.
You can now set up a hierarchy of read-only copy nodes to allow offload high volume reporting or web-site applications to access read-only data, without affecting performance on the main server. The tree of read-only nodes provides automatic load balancing, and automatic reconfiguration in the event of one of the nodes going offline.
Support for iPhone
We ship support for iPhone with our UltraLite database and synchronization components. Application developers can now create true enterprise applications that allow data on the device to be seamlessly synchronized to back-end servers. Tom Slee wrote extensively about our iPhone support when we released it in Beta test.
Self Managing Enhancements
SQL Anywhere has always been known for its self managing characteristics, but I think we’ve gone a step further with version 12. A significant new feature, that will work invisibly behind the scenes is our new Server Thread Auto-Tuning capability. This unique feature in the industry allows the SQL Anywhere Server to dynamically change the number of worker threads used inside the server to handle requests. When throughput would be improved with additional threads, more threads are used. When throughput would be increased by decreasing the number of threads, thereby reducing contention and thrashing, fewer threads are used. Previously, administrators had to set the number of threads at server startup time using a “try this guess, and test performance” approach. This becomes a thing of the past. I predict that everyone who knew about these options will pretty soon forget that they even existed.
The other major self management enhancement is the addition of automatic self-healing on statistics used by the query optimizer inside the database. The SQL Anywhere server will monitor itself, and observe when the statistics used by the optimizer significantly differ from the actual results returned by a query. When this happens, the server will undertake an effort to repair the statistics without affecting user performance. Glenn Paulley wrote a comprehensive article on this process here.
Central Admin of Remote Databases
In large scale synchronization environments, there are often small administrative tasks that need to be performed such as schema upgrades, backups, etc. Previously, these tasks presented a challenge to administrators, who had to use additional tools, or otherwise invent something themselves. SQL Anywhere 12 now provides a set of tools to help with these administrative tasks directly.
Scalability Testing of Synchronization Environments
Customers are always asking for guidelines for capacity planning a large scale synchronization setup. Our recommendation is always to test performance of their setup. This has been a challenge in the past. SQL Anywhere 12 now includes a toolset to enable the capture, customization and replay of a synchronization session, and enables simulation of large environments. This can be used to more accurately observe and correct bottlenecks prior to putting a system into production.
Complete details of all the enhancements in SQL Anywhere version 12 are available in our online documentation system: Doc Comment Exchange (DCX), located here.
As well, you might wish to read Breck Carter’s post about performance improvements in proxy tables.