The following is a list of new features that were introduced in version 1.0 Support Package 3.
A cloud can support multiple versions of cloud server and database software. The following rules apply:
The major and minor version of the database must be equal to or earlier than the major and minor version of the cloud server. For example a version 12 database can run on a version 12 cloud server or on a version 16 cloud server. A version 16 database can run on a version 16 cloud server, but a version 16 database cannot run on a version 12 cloud server.
When a tenant database is involved in a mirroring or read-only scale-out system, then all of its database copies must run on cloud servers that are of the same major and minor version. In a mirroring system, the arbiter server must also be of the same major and minor version as the primary, mirror, and any scale-out database copies.
Databases can be upgraded when added to the cloud and anytime afterward. By default, databases are upgraded to version 16 when they are added to the cloud. Whenever a database is upgraded to a version 16 database, you must specify whether the system procedures execute with the privileges of their owner (definer) or with the privileges of the invoker.
When adding a database or upgrading a database, the system procedures by default retain the same invoker/definer setting as the original database.
Cloud tasks and utilities affected by these enhancements The following changes were made to support this feature.
Upgrading databases You can now upgrade a database to the same software version as the cloud server that it is running on. See UpgradeDatabase task.
Load balancing When redistributing database copies running on overloaded cloud servers to cloud servers that have less activity, database copies are only moved to cloud servers that are of the same major and minor version. See LoadBalanceDatabases task and Balancing database load on cloud servers.
Adding database copies When a database copy is created, the database copy can only run on a cloud server that is of the same major and minor server version as the tenant database. See AddScaleOutDatabaseCopy task.
Moving databases and database copies When a database is moved from one cloud server to another, the version of the target cloud server must either match the major and minor version of the current database or be a later version. When a database copy is moved from one cloud server to another, the major and minor version of the cloud servers must match. See MoveDatabase task and MoveDatabaseCopy task.
Restoring databases from backups (RestoreBackupCopy task and RestoreBackup task) A database copy can only be restored to a cloud server that has the same major and minor version as the cloud server of the other database copies in the tenant database. A database can only be restored to a cloud server whose version either matches or is later than the database major and minor version. See RestoreBackup task and RestoreBackupCopy task.
|-upgrade_to_version [ 16 | 12||
This option is required to upgrade the database to version 12. Specify 12 to upgrade the database to major version 12 and add the database to a version 12 cloud server. Specify 16 to upgrade the database to major version 16 and add the database to a version 16 cloud server. The default is 16.
The -server_list parameter can restrict the cloud server version that the database gets added to; however, the -upgrade_to_version parameter takes precedence.
|-system_procedure_as_definer [ on | off ]||
This option applies when upgrading to a version 16 database. It specifies whether the system procedures are to execute with the privileges of their owner (definer), or with the privileges of the invoker. By default, the system procedures retain the same invoker/definer setting as the original database.
Previously, the number of databases that could be added to a cloud server equaled the maximum number of databases that could run concurrently on the cloud server. For example, on a 64-bit computer, 100 databases could be added to a cloud server. Now, the number of databases that can be added to a cloud server depends on the number of databases that must run concurrently and whether the databases are configured to start and stop automatically.
You can add databases to a cloud server until any of the following limits is reached:
The maximum number of concurrently running databases for the server has been reached.
The number of databases not configured to autostop equals the maximum number of concurrently running databases for the cloud server.
The cloud server has 1000 databases.
The following changes were made to support this feature.
Support for autostart and autostop databases A tenant database can be configured to start automatically during a client connection and to stop automatically after the last client connection disconnects. See Autostart and autostop databases.
|-autostart [ on ]||
When -autostart on is specified, the database being added to the cloud is configured to autostart. When a client attempts to connect to the autostart database, it starts automatically. The default is off.
This option only applies when -autostart on is specified. Use the -autostop_wait_time option to specify the time between when the last client connection disconnects and the database stops. The default is 10 minutes.
Enhancements to configure an existing tenant database to automatically start and stop Alter the database properties to configure an existing tenant database to automatically start and stop. The AlterDatabase task supports the following new parameters:
Set the autostart parameter to 1 to configure the database to start automatically when a Command Sequence communication protocol (TCP/IP) connection is attempted. The default is 0.
This parameter only applies when autostart is set to 1. Specify the time, in minutes, to wait before stopping the database after the last client disconnects. Specify 0 to stop the database immediately after the last client disconnects from the database. Specify -1 to never stop the database. The default is 10.
See AlterDatabase task.
Altering the cloud To specify the maximum time, in seconds, that a connection waits while attempting to auto start a database before it times out, alter the cloud properties or run the AlterCloud task with the autostart_timeout parameter. See AlterCloud task.
Temporarily prevent a database from automatically stopping To temporarily prevent an autostop database from autostopping, manually start the database. To restore the autostopping feature, run the StopDatabase task with the unconditionally parameter set to 0. See Disabling and re-enabling an autostop database from automatically stopping (dbcloudcmd).
Autostart databases cannot be involved in a mirroring or read-only scale-out system An autostart database cannot be part of a mirroring or read-only scale-out system. You cannot add a database copy, or set an arbiter for an autostart database. See SetArbiter task and AddScaleOutDatabaseCopy task.
Maintenance plan tasks Maintenance plans for autostart databases take advantage of the times when the database has not run between backup schedules. See Maintenance plans for autostart databases.
Moving databases An autostart database cannot be moved by using the MoveDatabase task when its move_method parameter is set to mirroring. See MoveDatabase task.
Tenant database upgrades Tenant databases can be upgraded within the cloud. See Upgrading a tenant database.
Redownload software upgrades Cloud software, such as upgrades, can be redownloaded. Redownloading software includes replacing all copies of the software that are stored in the cloud, but it does not involve installing the software. See Downloading and redownloading cloud software support packages.
Improvement to copying software upgrades to multiple hosts for load balancing and redundancy purposes When downloading cloud software upgrades, you can specify multiple hosts to store the software. See Downloading and redownloading cloud software support packages and CopyCloudSoftware task.
Secure feature key restrictions When initializing the cloud, you are prompted to specify a secure feature key to enforce tenant database isolation. The secure feature key is restricted to 7-bit ASCII characters, and it must have a length between 6 and 128 characters.
See Secure feature keys.
The cloud generates a topology file daily that shows the locations of all cloud objects, including servers, tenant databases, and database backups. The file is located in the C:\Users\Public\Public Documents\SQL Anywhere OnDemand 1.0\topology directory.
The topology file can also be generated at any time by clicking View cloud topology on the cloud's Overview panel. See Viewing the cloud's topology.
As a result of this change, the following tasks have been added:
Multiple backups can be deleted simultaneously Select more than one backup on the database's Backup & Restore panel and click Other actions » Delete. See Deleting cloud objects.
Create backup copies for redundancy purposes Create a copy of a backup and store it on a different host. See Creating a backup copy.
Backups and backup copies have names Backups now have names that can be used in searches and parameters for backup-related tasks. See Database backups and maintenance plans.
Maintenance plans can delete expired backups Maintenance plans can delete expired backups for the databases associated with the plan. By default, backups expire and are deleted after seven days, with the exception of the three most recent full backups.
Hosts can be configured to disallow backup storage Specify whether backups can be created on a host by altering the host's properties. See Database backups and maintenance plans.
As a result of these changes, the following tasks have been added:
The following tasks have been removed from the software:
Numerous improvements have been made to the Cloud Console to improve usability including:
Events information now has its own Events panel
Diagnostic log information now has its own Diagnostics log panel with a customizable search text box.
A new Backups panel, where backup history and backups in progress can be viewed.
Discuss this page in DocCommentXchange.
|Copyright © 2013, SAP AG or an SAP affiliate company - SAP Sybase SQL Anywhere, on-demand edition 1.0 Support Package 3|