Whilst NonStop remains the world’s No.1 choice for Mission-Critical systems, identifying and retaining resource with the...
SQL/MX Update – Frans Jongma (HPE)
Let me start with congratulating NonStop Insider with their first anniversary. I think this format is great to provide information at a regular –i.e. monthly- basis. This year was also a very good year for NonStop SQL/MX. Release 3.5 came out in the beginning of the year with L17.02 and was followed with an update, release 3.5.1, in August.
The 3.5 release is a milestone, because it provides new compatibility features that make migration of applications to NonStop easier. Ease of migration has two sides; one is the speed that an application can be migrated because of common APIs. A more important aspect is the speed in which developers can become productive. They are used to certain API calls beyond the simple SELECT, UPDATE and DELETE statements that everybody knows. And the more common functions a DBMS supports, the easier it is for a programmer to use a new database system. SQL/MX Release 3.5 implemented a set of functions that are common in Oracle and developers that know Oracle will welcome functions like TO_DATE, TO_CHAR and TO_TIMESTAMP, to name a few.
Don’t get me wrong, a migration is still not a no-brainer, because there will always be a big difference between the SMP-based RDBMSes and the MPP, or clustered, nature of NonStop. I prefer to call NonStop Clustered, rather than MPP, simply because nearly everyone today uses clusters whether explicitly configured for e.g. High Availability in the enterprise data center or implicitly in a cloud environment.
Now that the word ‘cloud’ is mentioned: SQL/MX 3.5 is also a milestone because it provides Database as a Service (DBaaS) functionality in SQL/MX DBS (Database Services). No, this is does not make it possible to provision a NonStop SQL database on Amazon in the public cloud. SQL/MX DBS will allow provisioning of a database on a NonStop server (be it a system-as-you-know-it or a virtualized NonStop) with just a single command or a few clicks from a browser. The system administrator does not have to create Guardian user IDs, does not have to arrange subvolumes or assign Safeguard permissions. This is all done by SQL/MX DBS.
DBS is the part of SQL/MX that I like very much because I spent a great deal of my time in getting it designed, proven and released. We have created a Proof of Concept on a lab machine in the ATC to experiment with how we could use much of the MXCS subsystem. Then SQL/MX development created the product as it now has been released. SQL/MX DBS provides multi-tenancy where users share the database software and Operating System, but are otherwise isolated from each other.
To show another aspect of compatibility, this picture shows the databases that are on the menu for the internal HPE-IT group. Developers log into a portal and select database services and can chose from either of these databases. The databases get provisioned from the same portal. Once provisioned they can use a DBA or query tool, such as dbVisualizer, SQuirreL or DBeaver, to connect to the database and start getting productive! This implementation is in line with a multi-tier application design: web or mobile User Interface tier, one or more application tiers and a database tier, where NonStop SQL provides the scalable always-on persistence layer.
SQL/MX DBS differs from a virtualized NonStop system in that it restricts user access to the actual system. All user access is through JDBC and ODBC and NonStop SQL maintains the user names and access levels to the database, while Safeguard allows uses access to only their assigned volumes. The applications are hosted on Linux, Windows or other devices that support Java or have an ODBC/MX driver.
If an application needs to run on the NonStop platform, using other proven software infrastructure, such as TS/MP for application salability and availability, and there are many examples of those applications, then a virtualized system may be a good choice. And SQL/MX DBS can be implemented on virtualized systems the exact same way as is done on converged systems.
While I am very happy with the functionality of SQL/MX DBS, I know that this implements a good first set of requirements. Further use will create new ideas, uncover missing functionality and suggestions to improve. I can only advise you as customers to put it in place, configure a few volumes for DBS use and start using it. A development system might be an excellent place to kick the tires and build knowledge.
To learn more about NonStop SQL/MX DBS you can read the Sept-Oct issue of The Connection which can be found at:
I presented DBS earlier this year on eBITUG in London. I saved a copy on my slideshare at https://www.slideshare.net/fjongma . And of course, there is a manual that describes SQL/MX DBS on the HPE documentation portal that has the easy to remember URL https://www.hpe.com/info/nonstop-ldocs.