SQL virtual database is driven by a unique, patent-pending recovery technology that makes backup files behave like standard physical databases. This technology allows you to create virtual databases by directly attaching backup files to SQL Server without requiring a restore operation. Each virtual database is hosted by the SQL Server instance you specify. All objects and data in the virtual databases are accessible to SQL Server jobs and stored procedures, T-SQL scripts, and other third-party applications. The SQLvdb Engine, which consists of a driver and a service, manages the virtual database and services the SQL Server I/O requests to the virtual data files. As the SQLvdb Engine attaches your selected backup files and creates the virtual database, it consolidates all the transactions and presents them to SQL Server for recovery. During this process, SQL virtual database "maps" the data from the backup files. If the data has already been "mapped," such as through SQLsafe or the Map Generation utility, then SQL virtual database proceeds to the virtual database creation. You can create a virtual database by attaching specific data sets from various full, differential, and transaction log backups. Review collected by and hosted on G2.com.
Equipment: Databases generally require a lot of resources, whether in a real or virtualized system. Virtualized database systems based on Microsoft SQL Server, as well as Oracle and others, need sufficient processing power. If this is not provided by the VM, it may cause significant performance degradation. Licenses: In some cases, such as in older SQL virtual databases, the previous database licenses cannot be transferred 1:1 to a virtualized system because the charges refer to the "potential" performance of the system and not what is actually used. Therefore, it is important before a transition to estimate the environment and consider how many instances and processors will be used in order to get a comparison between the cost of a genuinely existing database server or its virtual counterparts. Ability: Databases are typically complex, and that fact is not changed by virtualization. The new technology comes with an additional layer which adds complexity for database administrators (DBAs). If there is no separation between virtualization administrators and DBAs, then the server needs to gain significant knowledge on database virtualization in addition to their regular "know-how." Responsibility: Many database administrators have no real access to the depths of the virtualization layer, as this will be managed by IT administrators. When issues with a virtual database occur, either by an anomaly in the VM or virtual system, it often results in long delays in resolving the issue. Review collected by and hosted on G2.com.
