Idera strives to ensure our products provide quality solutions for your SQL Server needs. The following known issues are described in this section. If you need further assistance with any issue, please contact Support (www.idera.com/support).
Installation and configuration considerations
Review application log when install or upgrade fails
Because the SQL Virtual Database setup program runs silently when you choose to install or upgrade this tool, no error messages display to warn you after the install or upgrade fails. Some reasons why an install or upgrade will fail include:
- The target computer does not meet the minimum requirements or prerequisites for this tool
- The default installation drive on the target computer is not
C:\ - The SQL VDB Console is running on the target computer
- The SQL VDB CLI is executing a command on the target computer
- Virtual databases are in the process of being created
- Virtual databases are still attached to the target SQL Server instance
Virtual SQL Server support
You can now deploy SQL Virtual Database to virtual SQL Server instances located on the nodes of a Windows 2003 or Windows 2008 Server Cluster.
Windows Server 2000 support
You cannot install SQL Virtual Database on computers running Windows Server 2000. For more information, see the product requirements.
TSM support
SQL Virtual Database does not support attaching backup files written to a Trivoli Storage Manager (TSM) device. However, you can extract the data files to disk, and then attach the copied data files.
Calculate maximum required memory for attaching backups
Per SQL Safe backup
- Determine the number of threads
If the server has two or less CPUs, then:
number of threads = (number of backup files x 2) + number of CPUs
If the server has more than two CPUs, then:
number of threads = number of backup files x 5 - Calculate the max memory
max memory = 12MB + (2MB x number of backup files x number of threads) + (106KB x number of threads)
Per native backup
- Determine the number of threads
If the server has two or less CPUs, then:
number of threads = (number of backup files x 2) + number of CPUs
If the server has more than two CPUs, then:
number of threads = number of backup files x 5 - Calculate the max memory
max memory = 106KB x number of threads
Per native compressed backup
- Determine the number of threads
If the server has two or less CPUs, then:
number of threads = 2
If the server has more than two CPUs, then:
number of threads = number of backup files - Calculate the max memory
max memory = 1MB + (106KB x number of threads)
Known issues
Using the CLI to remove a failed virtual database does not sync with SQL VDB Console
When you run the CLI REMOVE action to drop a failed virtual database, the SQL VDB Console will continue to display that virtual database as though it is still attached. To work around this issue, remove the virtual database using the Console.
Virtual database status reported as corrupted after cluster node fails over
After a cluster node fails over, SQL Server may incorrectly report that the virtual databases attached to the virtual SQL Server instance hosted on that node are corrupted. This invalid error is most likely to occur during the failover process when the SQL Server Agent restarts before the SQL VDB Service restarts.
Default SQL Server 2012 security model cannot access virtual data files directory
By default, the SQL Server 2012 security model creates a unique, restricted user for each service account. This configuration prevents the SQL Server Service from writing data files to the SQL VDB virtual database file location, causing the attachment of a virtual database to fail.
To work around this issue, assign the appropriate permissions to the default user SQL Server created for the SQL Server Service account.
Previous known issues
Creating a virtual database that contains a large number of transactions
SQL Virtual Database may require more time to create a virtual database when the selected backup files contain a large number of transactions. Because you can select full, differential, and multiple transaction log backups, a significant number of transactions may need to be recovered before the virtual database can be created. This issue is more likely to occur if the corresponding physical database incurred transactions during the backup operation.
For more information about virtual database creation, see how SQL Virtual Database works.
Slow performance when attaching backup files from a network share
You may experience slower performance when attempting to attach a large SQL Safe backup file located on a network share.
Slow performance when attaching backup files that contain multiple data sets
You may experience slower performance when attaching backup files that contain multiple data sets. This issue is more common when attaching SQL Server backups.