|
SQL Anywhere 17.0 introduces several product-wide new and changed features to learn about, in addition to component-level changes.
Deprecated features will be removed in future versions. Alter your applications to use recommended feature replacements instead of relying on deprecated features.
Check the readme.txt file for additional information about the software, including feature information that was added after the documentation was completed.
The Cockpit is a database server monitoring tool that provides an up-to-date view of the availability, capacity, and performance of your database server. It runs in a browser and can provide information to the SAP DB Control Center. See SQL Anywhere Cockpit.
Use the Cockpit to track who is logged on to a database server; display both database server and client statistics, and disconnect users from databases.
The Cockpit runs on the same database server, which you want to monitor. It is light-weight and is designed to run continuously in the background so that it is always available. But, you can also easily start and stop it to investigate issues.
The Cockpit supports version 17 and version 16 databases running on a version 17 database server. As described below database users must have the COCKPIT_ROLE user-defined role to connect to the Cockpit.
The following changes have been made to support the SQL Anywhere Cockpit:
Use sa_server_option system procedure and the Cockpit parameter to start and stop the Cockpit on a running database server. See sa_server_option system procedure.
To connect to the Cockpit, users must have exercise rights to the COCKPIT_ROLE user-defined role. Newly created databases include this user-defined role, but by default no user is granted the exercise rights to this role. To use the Cockpit with version 16 databases running on a version 17 database server, add the COCKPIT_ROLE to the database, and then grant users the exercise right to this role.
For convenience in the sample database the DBA user is granted exercise rights to this role.
By default, the COCKPIT_ROLE user-defined role includes all the system privileges required to perform actions within the Cockpit. See COCKPIT_ROLE user-defined role.
Control whether users can start or stop the Cockpit, with the -sf database server option. This feature controls whether users can run the sa_server_option system procedure with the CockpitDB option. See -sf database server option and Cockpit security.
The CockpitURL database server property returns the URL to access your Cockpit. The CockpitDB database server property returns the set of Cockpit options currently being used by the database server. See List of database server properties.
The Cockpit replaces the graphical administration tool dbconsole, which has been removed from the software.
The Profiler is a development tool for tuning and troubleshooting your database applications. Use it to quickly view SQL statements that are currently running in your database, compare run times of stored procedures, and analyze how the objects in your database interact with each other. The Profiler supports version 17 databases.
The Profiler replaces most of the application profiling administration tools in SQL Central.
The following changes have been made to support the Profiler.
The Application Profiler and the SQL Anywhere Performance Monitor in SQL Central have been removed from the software and have been replaced with the Profiler. If you open Profiler and connect to a pre-version 17 database, the Application Profiling tools are not available. Similarly, if you open a database server, the Performance Monitor tab has been removed.
If you want to use these features with a pre-version 17 database, use the version of SQL Central that matches the version of your database.The database tracing feature is deprecated. The diagnostic tracing levels optimization_logging and optimization_logging_with_plans are ignored by the software. The Database Tracing Wizard in the SQL Anywhere plug-in for SQL Central has been removed. The new Profiler contains the ability to a record and view database operations.
The Deadlocks tab and Auditing tabs in the SQL Anywhere plug-in for SQL Central have been removed. The new Profiler contains a Blocking tab that shows both blocking and deadlock information. You can still generated auditing information, use the CREATE TEMPORARY TRACE EVENT SESSION statement to generate an ETD file, and then view the file using the dbmanageetd utility.
New SYS_RUN_PROFILER_ROLE system role is required to connect to the Profiler Newly created databases include the user-defined role SYS_RUN_PROFILER_ROLE system role. This role is required to connect to the Profiler. By default no user is granted the exercise rights to this role. For convenience in the sample database the DBA user is granted exercise rights to this role.See System roles.
Previously, when you created a new database, if you did not specify a DBA user for the database, a user was automatically created with user ID DBA and password sql. Now, the database server requires you to supply a user ID and password. In addition, the minimum password length for users has changed from 3 to 6, but you can override this length at database creation time.
These changes are designed to improve security in new databases. If you have databases with a DBA/sql user ID, then change it because this is the user login that a malicious user is likely to try when attempting to access a database.
The DBA USER and DBA PASSWORD clauses, used for specifying the user ID and password for initial database DBA user, are now required when creating a database. Also, a new optional clause, MINIMUM PASSWORD LENGTH, has been added to allow you to override the (new) default minimum password length of 6. See CREATE DATABASE statement
The -dba option, used for specifying the user ID and password for initial database DBA, is now required when creating a database. Also, a new option, -mpl, has been added to optionally allow you to override the (new) default password length of 6. For example, -mpl 3 sets the minimum password length to 3. See Initialization utility (dbinit).
The default length for the min_password_length database option is now 6 instead of 3. See min_password_length option.
The -su database server option, used to set the password for the utility database (utility_db), now accepts the option of specifying password; user-ID, password; or, alternatively, none. The password must be 6 characters or longer. This restriction is true even when using the personal database server (dbeng17.). See -su database server option and The utility database (utility_db).
The support for the util_db.ini file, deprecated in version 10, has been removed. Use the -su option to set the password for the utility database (utility_db). See -su database server option.
The sample database (demo.db), used extensively throughout the documentation examples and tutorials, as well as by many of the software samples, continues to have a DBA/sql user to allow continued compatibility. This is true for any database created using the newdemo.bat script (newdemo.sh on Linux). As well, databases created using newdemo.bat have a minimum password length of 3 instead of 6. See The sample database.
Previously, when using the SQL Anywhere Demo ODBC data source to connect to the demo.db database in the administration tools, utilities, or in SQL statements, you did not need to specify the password (sql) because the password was stored as a setting in the ODBC data source. Now the database requires the password sql when you use the SQL Anywhere 17 Demo ODBC data source.
Previously, when using the SQL Anywhere CustDB ODBC data source to connect to the demo.db database in the administration tools, utilities, or in SQL statements, you did not need to specify the MobiLink user ID (ml_server) and password (sql) because the user ID and password were stored as a setting in the ODBC data source. Now the database requires the user ID ml_server and password sql when you use the SQL Anywhere 17 CustDB ODBC data source.
Any SQL, command line, or programming examples in the documentation that show connections to, or creation of, SQL Anywhere databases other than the sample database specify a user ID and password for a DBA user. Previously, these examples either did not specify a DBA user, or gave DBA/sql for the user ID and password. In the latter case, the examples have been changed to use DBA/passwd for the DBA user ID and password, to satisfy the new default password length requirement of 6.
All other documentation examples that connect to the sample database, or any database created using the newdemo script (for example, the database used in the application profiling tutorials) remain the same, since these databases continue to have the DBA/sql user ID and password.
This includes tutorials and examples in products like MobiLink and UltraLite, where connections to, or creation of, SQL Anywhere databases take place.
There are no changes to these products as a result of changing the default password length, or eliminating the default DBA/sql user ID and password when initializing a database.
Whenever possible, the samples included with the software are designed to demonstrate best practices regarding the handling of database passwords. For security reasons, you should never include passwords within your application code. Therefore most samples avoid embedded passwords. When a password is necessary to build or run a sample, you are required to provide the database password.
For example, many samples use a demonstration database (demo.db) that is included in the root of the samples directory. For this database, the database administrator user ID is DBA and the password is sql (note that passwords are case sensitive).
In some sample Microsoft Visual Studio projects, database credentials are still included in configuration files to support Microsoft Visual Studio design-time features which require the ability to connect to the sample database in the background. Good practice dictates that this sensitive configuration information be removed from the application project once software development has been completed.
SSL version 3.0 is no longer supported. Use TLS version 1.0 or later instead.
SQL Anywhere version 16.0 up to build 1695 and version 12.0.1 up to build 3986 included a Certicom encryption module that provided strong encryption used throughout the software. Now, SQL Anywhere includes an OpenSSL encryption module for the strong encryption. The Certicom encryption module has been removed.
Read the following descriptions to determine how you may be impacted by this change.
OpenSSL supports FIPS-certified AES encryption for the private key of an identity file. New servers using the FIPS-certified OpenSSL encryption module will not start when using an identity file that has its private key encrypted with 3DES. You must re-encrypt the identity file using AES. To do this, run a command similar to the following using an upgraded viewcert utility:
viewcert -p -o new-file-name -op new-password -ip old-password old-file-name
The new and old passwords can be the same. See Certificate Viewer utility (viewcert).
The sample server identity file (rsaserver.id) and client identity file (rsaclient.id) have been modified so that the private keys are encrypted using AES rather than 3DES.
Trusted root certificate files specified using trusted_certificates do not need to be modified.
Versions of the server that use the Certicom encryption module do not start when using an identity file that has its private key encrypted using AES.
See also FIPS-certified encryption technology.
With Certicom, a client could trust any certificate in the signing chain and the TLS handshake would succeed. With OpenSSL, the client must trust the root certificate in the chain.
Self-signed certificates must now have the Certificate Signing attribute set when using the identity encryption option (for example, the -x mlsrv and -xs dbsrv options). To determine if a certificate the Certificate Signing attribute is set, use the viewcert utility and look for the Certificate Signing attribute in the Key Usage portion of the output. If your self-signed certificates do not have the Certificate Signing attribute set, then regenerate the certificates.
The Create Certificate utility (createcert) now uses AES rather than 3DES encryption for encrypting the private key in the server identity file.
A new option, -3des, has been added to the Create Certificate utility. This option creates a 3DES-encrypted server identity file that can be used by database servers in previous releases. New servers using FIPS-certified encryption cannot start using 3DES-encrypted certificates; however, if you are not using FIPS-certified encryption, then you can use 3DES-encrypted certificates. See Certificate Creation utility (createcert).
The View Certificate utility (viewcert) now uses AES rather than 3DES encryption when you specify the -p option to PEM-encode the output and when you specify the -ip and -op options to set the password.
The View Certificate utility supports a new option, -3des, that encrypts output and passwords using 3DES instead of AES.See Certificate Viewer utility (viewcert).
Previously, the 32-bit database server loaded the FIPS-certified encryption libraries on Windows only when needed. Now, on 32-bit Windows, the server always attempts to load these libraries at startup. If loading fails, then no error is returned unless an attempt is made to use FIPS-certified encryption. On 64-bit Windows, the 32-bit database server no longer supports FIPS-certified encryption. Use the 64-bit database server instead. FIPS-certified encryption is separately licensed.
If you are deploying FIPS-certified encryption, then there are new shared libraries to deploy; these files are included in your software. The former files, sbgse2.dll and libsbgse2.so, are no longer installed by the software. The new files to deploy are:
64-bit Windows: libeay32.dll, ssleay32.dll, and msvcr100.dll
32-bit Windows: libeay32.dll, ssleay32.dll, and msvcr90.dll
Linux: libcrypto.so and libssl.so
TLS connections to a MobiLink server using client-side certificates now require the client-side certificate to have the Digital Signature attribute set. If the attribute is not set, then the connection will fail.
To determine if a certificate has the Digital Signature attribute set, use the View Certificate utility (viewcert) and look for the Digital Signature attribute in the Key Usage portion of the output. If your client-side certificates do not have the Digital Signature attribute set, then you must regenerate the certificates. See Certificate Viewer utility (viewcert).
If the private key file provided to a MobiLink server by the e2ee_private_key file option of the -x command-line option is encoded using 3DES and the server is using FIPS-certified encryption, then the private key file needs to be regenerated with the private key encrypted using AES.
These steps update the client identity certificates twice if the Digital Signature attribute is missing from client-side identity certificates. This procedure can make the update less disruptive because synchronizations can continue without having to coordinate the client-side and server-side updates to occur at the same time.
UltraLite no longer supports FIPS-certified encryption on Windows Mobile.
Previously, registry entries were recorded under Software\Sybase. Now, these registry entries appear under Software\SAP.
For example, HKEY_LOCAL_MACHINE\Software\Sybase\SQL Anywhere\16.0 becomes HKEY_LOCAL_MACHINE\Software\SAP\SQL Anywhere\17.0.
For 64-bit Windows, Software\Wow6432Node\Sybase becomes Software\Wow6432Node\SAP.
Previously, the software included an Oracle JRE for clients to use. Now, the software uses the SAP JRE.
The SAP JRE may perform differently than the Oracle JRE. Use the java_vm_options option (SQL Anywhere), and/or the -sl java option (MobiLink) to optimize your Java VM startup settings.
Previously, version 1.7.0 of the Java Development Kit (JDK 7) was recommended for use in JDBC applications. Now, JDK 8 is recommended.
SQL Anywhere is no longer supported on Windows XP.
SQL Anywhere is no longer supported on Windows Vista.