Checksums calculated automatically for critical database pages   The database server records checksums for critical database pages, regardless of whether checksums are enabled for the database. As a result, you may see warnings about checksum violations when you validate your database, even if the database does not have checksums enabled. Additionally, the database server shuts down with a fatal error when it tries to access a corrupt critical page. See Validating checksums.

Applying multiple transaction logs at startup for recovery   By default, you must apply transaction logs individually, in the correct order when recovering a database. When the new -ad, -ar, and -as recovery options specified when starting the database server, you do not need to manually specify the order in which transaction logs are applied to the database. Because the database server and the database are running while the transaction logs are applied, the server's cache remains in a warm state, reducing total recovery time. See -ad dbeng12/dbsrv12 database option, -ar dbeng12/dbsrv12 database option, and -as dbeng12/dbsrv12 database option.

Support for parallel database backups   The SQL Anywhere database server now supports parallel backups for server-side image backups. Parallel database backups take advantage of physical I/O to perform read and write information in parallel, instead of sequentially, which improves performance. You can perform parallel backups in any of the following ways:

• Backup utility (dbbackup)
• BACKUP statement
• db_backup function

Tracking information on the last backup   A new column, LAST_BACKUP, has been added to the ISYSHISTORY system table to store information about the last backup. See SYSHISTORY system view.