* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Data-tier Applications | Microsoft Docs
Survey
Document related concepts
Serializability wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Team Foundation Server wikipedia , lookup
Microsoft Access wikipedia , lookup
Functional Database Model wikipedia , lookup
Oracle Database wikipedia , lookup
Ingres (database) wikipedia , lookup
Concurrency control wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Relational model wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Versant Object Database wikipedia , lookup
Database model wikipedia , lookup
Transcript
Table of Contents Overview DAC Support For SQL Server Objects and Versions Delete a Data-tier Application Deploy a Data-tier Application Export a Data-tier Application Extract a DAC From a Database Import a BACPAC File to Create a New User Database Monitor Data-tier Applications Register a Database As a DAC Unpack a DAC Package Upgrade a Data-tier Application Validate a DAC Package Deploy a Database By Using a DAC Data-tier Applications 3/24/2017 • 8 min to read • Edit Online A data-tier application (DAC) is a logical database management entity that defines all of the SQL Server objects like tables, views, and instance objects, including logins – associated with a user’s database. A DAC is a selfcontained unit of SQL Server database deployment that enables data-tier developers and database administrators to package SQL Server objects into a portable artifact called a DAC package, also known as a DACPAC. A BACPAC is a related artifact that encapsulates the database schema as well as the data stored in the database. Benefits of Data-tier Applications The lifecycle of most database applications involves developers and DBAs sharing and exchanging scripts and ad hoc integration notes for application update and maintenance activities. While this is acceptable for a small number of databases, it quickly becomes unscalable once databases grow in number, size, and complexity. A DAC is a database lifecycle management and productivity tool that enables declarative database development to simplify deployment and management. A developer can author a database in SQL Server Data Tool database project and then build the database into a DACPAC for handoff to a DBA. The DBA can deploy the DAC using SQL Server Management Studio to a test or production instance of SQL Server or Azure SQL Database. Alternatively, the DBA can use the DACPAC to upgrade a previously deployed database using SQL Server Management Studio. To complete the lifecycle, the DBA can extract the database into a DACPAC and hand it off to a developer to either reflect test or production adjustments, or to enable further database design changes in response to changes in the application. The advantage of a DAC-driven deployment over a script driven exercise is that the tool helps the DBA with identifying and validating behaviors from different source and target databases. During upgrades, the tool warns the DBA if the upgrade might cause data loss, and also provide an upgrade plan. The DBA can evaluate the plan and then utilize the tool to proceed with the upgrade. DAC’s also support versioning to help the developer and the DBA maintain and manage the database lineage through its lifecycle. DAC Concepts A DAC simplifies the development, deployment, and management of data-tier elements that support an application: A data-tier application (DAC) is a logical database management entity that defines all SQL Server objects such as tables, views, and instance objects – associated with a user’s database. It is a self-contained unit of SQL Server database deployment that enables data-tier developers and DBAs to package SQL Server objects into a portable artifact called a DAC package, or .dacpac file. For a SQL Server database to be treated as a DAC, it must be registered – either explicitly by a user operation, or implicitly by one of the DAC operations. When a database is registered, the DAC version and other properties are recorded as part of the metadata of the database. Conversely, a database can also be unregistered and have its DAC properties removed. In general, DAC tools are capable of reading DACPAC files generated by DAC tools from previous SQL Server versions, and can also deploy DACPAC’s to previous versions of SQL Server. However, DAC tools from earlier versions cannot read DACPAC files generated by DAC tools from later versions. Specifically: DAC operations were introduced in SQL Server 2008 R2. In addition to SQL Server 2008 R2 databases, the tools support generation of DACPAC files from SQL Server 2008, SQL Server 2005 and SQL Server 2000 databases. In addition to SQL 2016 databases, the tools shipped with SQL Server 2016 can read DACPAC files generated by DAC tools shipped with SQL Server 2008 R2 or SQL Server 2012. This includes databases from SQL Server 2014, 2012, 2008 R2, 2008, and 2005, but not SQL Server 2000. DAC tools from SQL Server 2008 R2 cannot read DACPAC files generated by tools from SQL Server 2012 or SQL Server 2016. A DACPAC is a Windows file with a .dacpac extension. The file supports an open format consisting of multiple XML sections representing details of the DACPAC origin, the objects in the database, and other characteristics. An advanced user can unpack the file using the DacUnpack.exe utility that ships with the product to inspect each section more closely. The user must be a member of the dbmanager role or assigned CREATE DATABASE permissions to create a database, including creating a database by deploying a DAC package. The user must be a member of the dbmanager role, or have been assigned DROP DATABASE permissions to drop a database. DAC Tools A DACPAC can be seamlessly used across multiple tools that ship with SQL Server 2016. These tools address the requirements of different user personas using a DACPAC as the unit of interoperability. Application Developers: Can use a SQL Server Data Tools database project to design a database. A successful build of this project results in the generation of a DACPAC contained in a .dacpac file. Can import a DACPAC into a database project and continue to design the database. SQL Server Data Tools also supports a Local DB for unconnected, client-side database application development. The developer can take a snapshot of this local database to create DACPAC contained in a .dacpac file. - Independently, the developer can publish a database project directly to a database without even generating a DACPAC. The publish operation follows similar behavior as the deploy operation from other tools. Database Administrators: Can use SQL Server Management Studio to extract a DACPAC from an existing database, and also perform other DAC operations. In addition, the DBA for a SQL Database can use the Management Portal for SQL Azure for DAC operations. Independent Software Vendors: Hosting services and other data management products for SQL Server can use the DACFx API for DAC operations. IT Administrators: IT systems integrators and administrators can use the SqlPackage.exe command line tool for DAC operations. DAC Operations A DAC supports the following operations: EXTRACT – the user can extract a database into a DACPAC. DEPLOY – the user can deploy a DACPAC to a host server. When the deployment is done from a manageability tool like SQL Server Management Studio or the Management Portal for SQL Azure, the resulting database in the host server is implicitly registered as a data-tier application. REGISTER – the user can register a database as a data-tier application. UNREGISTER – a database previously registered as a DAC can be unregistered. UPGRADE – a database can be upgraded using a DACPAC. Upgrade is supported even on databases that are not previously registered as data-tier applications, but as a consequence of the upgrade, the database will be implicitly registered. BACPAC A BACPAC is a Windows file with a .bacpac extension that encapsulates a database's schema and data. The primary use case for a BACPAC is to move a database from one server to another - or to migrate a database from a local server to the cloud - and archiving an existing database in an open format. Similar to the DACPAC, the BACPAC file format is open – the schema contents of the BACPAC are identical to that of the DACPAC. The data in a BACPAC is stored in JSON format. DACPAC and BACPAC are similar but they target different scenarios. A DACPAC is focused on capturing and deploying schema, including upgrading an existing database. The primary use case for a DACPAC is to deploy a tightly defined schema to development, test, and then to production environments. And also the reverse: capturing production’s schema and applying it back to test and development environments. A BACPAC, on the other hand, is focused on capturing schema and data supporting two main operations: EXPORT– The user can export the schema and the data of a database to a BACPAC. IMPORT – The user can import the schema and the data into a new database in the host server. Both these capabilities are supported by the database management tools: SQL Server Management Studio, the Azure Portal, and the DACFx API. Permissions You must be a member of the dbmanager role or assigned CREATE DATABASE permissions to create a database, including creating a database by deploying a DAC package. You must be a member of the dbmanager role, or have been assigned DROP DATABASE permissions to drop a database. Data-tier Application Tasks TASK TOPIC LINK Describes how to use a DAC package file to create a new DAC instance. Deploy a Data-tier Application Describes how to use a new DAC package file to upgrade an instance to a new version of the DAC. Upgrade a Data-tier Application Describes how to remove a DAC instance. You can choose to also detach or drop the associated database, or leave the database intact. Delete a Data-tier Application TASK TOPIC LINK Describes how to view the health of currently deployed DACs by using the SQL Server Utility. Monitor Data-tier Applications Describes how to create a .bacpac file that contains an archive of the data and metadata in a DAC. Export a Data-tier Application Describes how to use a DAC archive file (.bacpac) to either perform a logical restore of a DAC, or to migrate the DAC to another instance of the Database Engine or SQL Database. Import a BACPAC File to Create a New User Database Describes how to import a BACPAC file to create a new user database within an instance of SQL Server. Extract a DAC From a Database Describes how to promote an existing database to be a DAC instance. A DAC definition is built and stored in the system databases. Register a Database As a DAC Describes how to review the contents of a DAC package and the actions a DAC upgrade will perform before using the package in a production system. Validate a DAC Package Describes how to place the contents of a DAC package into a folder where a database administrator can review what the DAC does before deploying it to a production server. Unpack a DAC Package Describes how to use a wizard to deploy an existing database. The wizard uses DACs to perform the deployment. Deploy a Database By Using a DAC See also DAC Support For SQL Server Objects and Versions DAC Support For SQL Server Objects and Versions 3/24/2017 • 5 min to read • Edit Online A data-tier application (DAC) supports the most commonly used Database Engine objects. In This Topic Supported SQL Server Objects Data-tier Application Support by the Versions of SQL Server Data Deployment Limitations Additional Considerations for Deployment Actions Supported SQL Server Objects Only supported objects can be specified in a data-tier application as it is being authored or edited. You cannot extract, register, or import a DAC from an existing database that contains objects that are not supported in a DAC. SQL Server 2016 supports the following objects in a DAC. DATABASE ROLE FUNCTION: Inline Table-valued FUNCTION: Multistatement Table-valued FUNCTION: Scalar INDEX: Clustered INDEX: Non-clustered INDEX: Spacial INDEX: Unique LOGIN Permissions Role Memberships SCHEMA Statistics STORED PROCEDURE: Transact-SQL Synonyms TABLE: Check Constraint TABLE: Collation TABLE: Column, including computed columns TABLE: Constraint, Default TABLE: Constraint, Foreign Key TABLE: Constraint, Index TABLE: Constraint, Primary Key TABLE: Constraint, Unique TRIGGER: DML TYPE: HIERARCHYID, GEOMETRY, GEOGRAPHY TYPE: User-defined Data Type TYPE: User-defined Table Type USER VIEW Data-tier Application Support by the Versions of SQL Server The versions of SQL Server have different levels of support for DAC operations. All of the DAC operations supported by a version of SQL Server are supported by all editions of that version. Instances of the Database Engine support the following DAC operations: Export and extract are supported on all supported versions of SQL Server. All operations are supported on Azure SQL Database and all versions of SQL Server 2014, SQL Server 2012, and SQL Server 2008 R2. All operations are supported on SQL Server 2008 Service Pack 2 (SP2) or later, and SQL Server 2005 SP4 or later. The DAC Framework comprises the client-side tools for building and processing DAC packages and export files. The following products include the DAC Framework SQL Server 2014 and SQL Server 2012 includes DAC Framework 3.0, which supports all DAC operations. SQL Server 2008 R2 SP1 and Visual Studio 2010 SP1 included DAC Framework 1.1, which supports all DAC operations except export and import. SQL Server 2008 R2 and Visual Studio 2010 included DAC Framework 1.0, which supports all DAC operations except export, import, and in—place upgrade. The client tools from earlier versions of SQL Server or Visual Studio do not support DAC operations. A DAC package or export file built with one version of the DAC Framework cannot be processed by an earlier version of the DAC Framework. For example, a DAC package extracted using the SQL Server 2014 client tools cannot be deployed using the SQL Server 2008 R2 client tools. A DAC package or export file built with one version of the DAC Framework can be processed by any later version of the DAC Framework. For example, a DAC package extracted using the SQL Server 2008 R2 client tools can be deployed using either the SQL Server 2008 R2 SP1 or higher client tools. Data Deployment Limitations Note these fidelity limitations in the DAC Framework data deployment engine in SQL Server 2012 SP1. The limitations apply to the following DAC Framework actions: deploy or publish a .dacpac file, and import a .bacpac file. 1. Loss of metadata for certain conditions and base types within sql_variant columns. In the affected cases, you will see a warning with the following message: Certain properties on certain data types used within a sql_variant column are not preserved when deployed by the DAC Framework. MONEY, SMALLMONEY, NUMERIC, DECIMAL base types: Precision is not preserved. DECIMAL/NUMERIC base types with precision 38: the “TotalBytes” sql_variant metadata is always set to 21. All text base types: The database default collation is applied for all text. BINARY base types: Max length property is not preserved. TIME, DATETIMEOFFSET base types: Precision is always set to 7. 2. Loss of data within sql_variant columns. In the affected case, you will see a warning with the following message: There will be data loss when a value in a sql_variant DATETIME2 column with scale greater than 3 is deployed by the DAC Framework. The DATETIME2 value is limited to a scale equal to 3 during deployment. DATETIME2 base type with scale greater than 3: scale is limited to equal 3. 3. Deployment operation fails for the following conditions within sql_variant columns. In the affected cases, you will see a dialog with the following message: Operation failed due to data limitations in the DAC Framework. DATETIME2, SMALLDATETIME and DATE base types: If the value is outside of DATETIME range – for example, the year is less than 1753. DECIMAL, NUMERIC base type: when precision of the value is greater than 28. Additional Considerations for Deployment Actions Note the following considerations for DAC Framework data deployment actions: Extract/Export - On actions that use the DAC Framework to create a package from a database – for example, extract a .dacpac file, export a .bacpac file - these limitations do not apply. The data in the package is a full-fidelity representation of the data in the source database. If any of these conditions are present in the package, the extract/export log will contain a summary of the issues via the messages noted above. This is to warn the user of potential data deployment issues with the package they created. The user will also see the following summary message in the log: These limitations do not affect the fidelity of the data types and values stored in the DAC package created by the DAC Framework; they only apply to the data types and values resulting from deploying a DAC package to a database. For more information about the data that is affected and how to work around this limitation, seethis topic. Deploy/Publish/Import - On actions that use the DAC Framework to deploy a package to a database, like to deploy or publish a .dacpac file, and import a .bacpac file, these limitations do apply. The data that results in the target database may not contain a full-fidelity representation of the data in the package. The Deploy/Import log will contain a message, noted above, for every instance the issue is encountered. The operation will be blocked by errors – see category 3 above - but will proceed with the other warnings. For more information about the data that is affected in this scenario and how to work around this limitation for deploy/publish/import actions, see this topic. Workarounds – Extract and export operations will write full-fidelity BCP data files into the .dacpac or .bacpac files. To avoid limitations, use the SQL Server BCP.exe command line utility to deploy full-fidelity data to a target database from a DAC package. See Also Data-tier Applications Delete a Data-tier Application 4/6/2017 • 6 min to read • Edit Online You can delete a data-tier application by using either the Delete Data-tier Application wizard or a Windows PowerShell script. You can specify whether the associated database is retained, detached, or dropped. Before you begin: Limitations and Restrictions, Permissions To upgrade a DAC, using: The Register Data-tier Application Wizard, PowerShell Before You Begin When you delete a data-tier application (DAC) instance, you choose one of three options specifying what is to be done with the database associated with the data-tier application. All three options delete the DAC definition metadata. The options differ in what they do with the database associated with the data-tier application. The wizard does not delete any of the instance-level objects associated with the DAC or database, such as logins. OPTION DATABASE ACTIONS Delete registration The associated database remains intact. Detach database The associated database is detached. The instance of the Database Engine cannot reference the database, but the data and log files are intact. Delete database The associated database is dropped. The data and log files are deleted. Limitations and Restrictions There is no automatic mechanism to restore the DAC definition metadata or the database after you delete a DAC. How you can manually rebuild the DAC instance depends on the delete option. OPTION HOW TO REBUILD THE DAC INSTANCE Delete registration Register a DAC from the database left in place. Detach database Re-attach the database by using sp_attachdb or SQL Server Management Studio, and then register a new DAC instance from the database. Delete database Restore the database from a full backup made before the DAC was deleted, and then register a new DAC instance from the database. WARNING Rebuilding a DAC instance by registering a DAC from a restored or re-attached database will not recreate some parts of the original DAC, such as the server selection policy. Permissions A DAC can only be deleted by members of the sysadmin or serveradmin fixed server roles, or by the database owner. The built-in SQL Server system administrator account named sa can also launch the wizard. Using the Delete Data-tier Application Wizard To Delete a DAC Using a Wizard 1. In Object Explorer, expand the node for the instance containing the DAC to be deleted. 2. Expand the Management node. 3. Expand the Data-tier Applications node. 4. Right-click the DAC to be deleted, and then select Delete Data-tier Application… 5. Complete the wizard dialogs: a. Introduction b. Choose Method c. Summary d. Delete Data-tier Application Introduction Page This page describes the steps for deleting a data-tier application. Do not show this page again. - Click the check box to stop the page from being displayed in the future. Next > - Proceeds to the Choose Method page. Cancel - Ends the wizard without deleting a data-tier application or database. Using the Delete Data-tier Application Wizard Choose Method Page Use this page to specify the option for handling the database associated with the DAC to be deleted. Delete registration - Removes the metadata defining the data-tier application, but leaves the associated database intact. Detach database - Removes the metadata defining the data-tier application and detaches the associated database. The database can no longer be referenced by that instance of the Database Engine, but the data and log files remain intact. Delete database - Removes the metadata defining the DAC and drops the associated database. The data and log files for the database are permanently deleted. < Previous - Returns to the Introduction page. Next > - Proceeds to the Summary page. Cancel - Ends the wizard without deleting the DAC or database. Using the Delete Data-tier Application Wizard Summary Page Use this page to review the actions the wizard will take when deleting the DAC instance. Review your selection summary - Review the DAC, database, and deletion method displayed in the box. If the information is correct, select either Next or Finish to delete the DAC. If the DAC and database information is not correct, select Cancel and select the correct DAC. If the deletion method is not correct, select Previous to return to the Choose Method page and select a different method. < Previous - Returns to the Choose Method page to choose a different delete method. Next > - Deletes the DAC instance using the method you chose on the previous page, and proceeds to the Delete Data-tier Application page. Cancel - Ends the wizard without deleting the DAC instance. Using the Delete Data-tier Application Wizard Delete Data-tier Application Page This page reports the success or failure of the delete operation. Deleting the DAC - Reports the success or failure of each action taken to delete the DAC instance. Review the information to determine the success or failure of each action. Any action that encountered an error will have a link in the Result column. Select the link to view a report of the error for that action. Save Report - Select this button to save the deletion report to an HTML file. The file reports the status of each action, including all errors generated by any of the actions. The default folder is a SQL Server Management Studio\DAC Packages folder in the Documents folder of your Windows account.. Finish - Ends the wizard. Using the Delete Data-tier Application Wizard Delete a DAC Using PowerShell To delete a DAC using a PowerShell script 1. Create a SMO Server object and set it to the instance that contains the DAC to be deleted. 2. Open a ServerConnection object and connect to the same instance. 3. Use add_DacActionStarted and add_DacActionFinished to subscribe to the DAC upgrade events. 4. Specify the DAC to delete. 5. Use one of these three sets of code, depending on which delete option is appropriate: To delete the DAC registration but leave the database intact, use the Unmanage() method. To delete the DAC registration and detach the database, use the Uninstall() method and specify DetachDatabase. To delete the DAC registration and drop the database, use the Uninstall() method and specify DropDatabase. Example Deleting the DAC but Leaving the Database (PowerShell) The following example deletes a DAC named MyApplication using the Unmanage() method to delete the DAC but leave the database intact. ## Set a SMO Server object to the default instance on the local computer. CD SQLSERVER:\SQL\localhost\DEFAULT $srv = get-item . ## Open a Common.ServerConnection to the same instance. $serverconnection = New-Object Microsoft.SqlServer.Management.Common.ServerConnection($srv.ConnectionContext.SqlConnectionObject) $serverconnection.Connect() $dacstore = New-Object Microsoft.SqlServer.Management.Dac.DacStore($serverconnection) ## Subscribe to the DAC delete events. $dacstore.add_DacActionStarted({Write-Host `n`nStarting at $(get-date) :: $_.Description}) $dacstore.add_DacActionFinished({Write-Host Completed at $(get-date) :: $_.Description}) ## Specify the DAC to delete. $dacName = "MyApplication" ## Only delete the DAC definition from msdb, the associated database remains active. $dacstore.Unmanage($dacName) Delete a DAC Using PowerShell Example Deleting the DAC and Detaching the Database (PowerShell) The following example deletes a DAC named MyApplication using the Uninstall() method to delete the DAC and detach the database. ## Set a SMO Server object to the default instance on the local computer. CD SQLSERVER:\SQL\localhost\DEFAULT $srv = get-item . ## Open a Common.ServerConnection to the same instance. $serverconnection = New-Object Microsoft.SqlServer.Management.Common.ServerConnection($srv.ConnectionContext.SqlConnectionObject) $serverconnection.Connect() $dacstore = New-Object Microsoft.SqlServer.Management.Dac.DacStore($serverconnection) ## Subscribe to the DAC delete events. $dacstore.add_DacActionStarted({Write-Host `n`nStarting at $(get-date) :: $_.Description}) $dacstore.add_DacActionFinished({Write-Host Completed at $(get-date) :: $_.Description}) ## Specify the DAC to delete. $dacName = "MyApplication" ## Delete the DAC definition from msdb and detach the associated database. $dacstore.Uninstall($dacName, [Microsoft.SqlServer.Management.Dac.DacUninstallMode]::DetachDatabase) Delete a DAC Using PowerShell Example Deleting the DAC and Dropping the Database (PowerShell) The following example deletes a DAC named MyApplication using the Uninstall() method to delete the DAC and drop the database. ## Set a SMO Server object to the default instance on the local computer. CD SQLSERVER:\SQL\localhost\DEFAULT $srv = get-item . ## Open a Common.ServerConnection to the same instance. $serverconnection = New-Object Microsoft.SqlServer.Management.Common.ServerConnection($srv.ConnectionContext.SqlConnectionObject) $serverconnection.Connect() $dacstore = New-Object Microsoft.SqlServer.Management.Dac.DacStore($serverconnection) ## Subscribe to the DAC delete events. $dacstore.add_DacActionStarted({Write-Host `n`nStarting at $(get-date) :: $_.Description}) $dacstore.add_DacActionFinished({Write-Host Completed at $(get-date) :: $_.Description}) ## Specify the DAC to delete. $dacName = "MyApplication" ## Delete the DAC definition from msdb and drop the associated database. ## $dacstore.Uninstall($dacName, [Microsoft.SqlServer.Management.Dac.DacUninstallMode]::DropDatabase) Delete a DAC Using PowerShell See Also Data-tier Applications Data-tier Applications Deploy a Data-tier Application Register a Database As a DAC Back Up and Restore of SQL Server Databases Database Detach and Attach (SQL Server) Deploy a Data-tier Application 3/24/2017 • 8 min to read • Edit Online Deploy a data-tier application (DAC) from a DAC package to an existing instance of the database engine or Azure SQL Database using a wizard or a PowerShell script. The deployment process registers a DAC instance by storing the DAC definition in the msdb system database (master in SQL Database); creates a database, then populates that database with all the database objects defined in the DAC. Deploy the same DAC package multiple times You can deploy the same DAC package to a single instance of the Database Engine multiple times, but you must run the deployments one at a time. The DAC instance name specified for each deployment must be unique within the instance of the Database Engine. Managed instances If you deploy a DAC to a managed instance of the Database Engine, the deployed DAC is incorporated into the SQL Server Utility the next time the utility collection set is sent from the instance to the utility control point. The DAC will then be present in the Deployed Data-tier Applications node of the Management Studio Utility Explorer and reported in the Deployed Data-tier Applications details page. Database Options and Settings By default, the database created during the deployment will have all of the default settings from the CREATE DATABASE statement, except: The database collation and compatibility level are set to the values defined in the DAC package. A DAC package built from a database project in the SQL Server Developer Tools uses the values set in the database project. A package extracted from an existing database uses the values from the original database. You can adjust some of the database settings, such as database name and file paths, in the Update Configuration page. You cannot set the file paths when deploying to SQL Database. Some database options, such as TRUSTWORTHY, DB_CHAINING, and HONOR_BROKER_PRIORITY, cannot be adjusted as part of the deployment process. Physical properties, such as the number of filegroups, or the numbers and sizes of files cannot be altered as part of the deployment process. After the deployment completes, you can use the ALTER DATABASE statement, SQL Server Management Studio, or SQL Server PowerShell to tailor the database. Limitations and restrictions A DAC can be deployed to SQL Database, or an instance of the Database Engine running SQL Server 2005 Service Pack 4 (SP4) or later. If you create a DAC using a later version, the DAC may contain objects not supported by SQL Server 2005. You cannot deploy those DACs to instances of SQL Server 2005. Security and permissions Authentication logins are stored in a DAC package without a password. When the package is deployed or upgraded, the login is created as a disabled login with a generated password. To enable the logins, log in using a login with the ALTER ANY LOGIN permission and use ALTER LOGIN to enable the login and assign a new password that can be communicated to the user. This is not required for Windows Authentication logins because their passwords are not managed by SQL Server. A DAC can only be deployed by members of the sysadmin or serveradmin fixed server roles, or by logins in the dbcreator fixed server role with ALTER ANY LOGIN permissions. The built-in SQL Server system administrator account named sa can also deploy a DAC. Deploying a DAC with logins to SQL Database requires membership in the loginmanager or serveradmin roles. Deploying a DAC without logins to SQL Database requires membership in the dbmanager or serveradmin roles. Deploy a DAC using the wizard 1. In Object Explorer, expand the node for the instance to which you want to deploy the DAC. 2. Right-click the Databases node, then select Deploy Data-tier Application… 3. Complete the wizard dialogs and click finish. More about some of the wizard pages below: Select DAC Package Page Specify the DAC package that contains the data-tier application to be deployed. The page transitions through three states. Select the DAC Package Choose the DAC package to deploy. The DAC package must be a valid DAC package file and must have a .dacpac extension. DAC Package - Specify the path and file name of the DAC package that contains the data-tier application to be deployed. You can select the Browse button at the right of the box to browse to the location of the DAC package. Application Name - A read-only box that displays the DAC name assigned when the DAC was authored or extracted from a database. Version - A read-only box that displays the version assigned when the DAC was authored or extracted from a database. Description - A read-only box that displays the description written when the DAC was authored or extracted from a database. Validating the DAC Package Displays a progress bar as the wizard confirms that the selected file is a valid DAC package. If the DAC package is validated, the wizard proceeds to the final version of the Select Package page where you can review the results of the validation. If the file is not a valid DAC package, the wizard remains on the Select DAC Package. Either select another valid DAC package or cancel the wizard and generate a new DAC package. Review Policy Page Review the results of evaluating the DAC server selection policy (if used). The DAC server selection policy is optional, and is assigned to the DAC when it is created in Visual Studio. The policy uses the server selection policy facets to specify conditions an instance of the Database Engine should meet to host the DAC. Evaluation results of policy conditions - Shows whether the DAC deployment policy conditions succeeded. The results of evaluating each condition are reported on a separate line. The following server selection policies always evaluate to false when deploying a DAC to SQL Database: operating system version, language, named pipes enabled, platform, and tcp enabled. Ignore policy violations - Use this check box to proceed with the deployment if one or more of the policy conditions failed. Only select this option if you are sure that all of the conditions which failed will not prevent the successful operation of the DAC. Update Configuration Page Specify the names of the deployed DAC instance and the database created by the deployment, and to set database options. Database Name: - Specify the name of the database to be created by the deployment. The default is the name of the source database the DAC was extracted from. The name must be unique within the instance of the Database Engine and comply with the rules for Database Engine identifiers. If you change the database name, the names of the data file and log files will change to match the new value. The database name is also used as the name of the DAC instance. The instance name is displayed on the node for the DAC under the Data-tier Applications node in Object Explorer, or the Deployed Data-tier Applications node in the Utility Explorer. The following options do not apply to SQL Database, and are not displayed when deploying to SQL Database. Use the default database location - Select this option to create the database data and log files in the default location for the instance of the Database Engine. The file names will be built using the database name. Specify database files - Select this option to specify a different location or name for the data and log files. Data file path and name: - Specify the full path and file name for the data file. The box is populated with the default path and file name. Edit the string in the box to change the default, or use the Browse button to navigate to the folder where the data file is to be placed. Log file path and name: - Specify the full path and file name for the log file. The box is populated with the default path and file name. Edit the string in the box to change the default, or use the Browse button to navigate to the folder where the log file is to be placed. Summary Page Use this page to review the actions the wizard will take when deploying the DAC. The following settings will be used to deploy your DAC. - Review the information displayed to ensure the actions taken will be correct. The window displays the DAC package you selected, and the name you selected for the deployed DAC instance. The window also displays the settings that will be used when creating the database associated with the DAC. Deploy Page This page reports the success or failure of the deploy operation. Deploying the DAC - Reports the success or failure of each action taken to deploy the DAC. Review the information to determine the success or failure of each action. Any action that encountered an error will have a link in the Result column. Select the link to view a report of the error for that action. Save Report - Select this button to save the deployment report to an HTML file. The file reports the status of each action, including all errors generated by any of the actions. The default folder is the SQL Server Management Studio\DAC Packages folder in the Documents folder of your Windows account. Deploy a DAC using PowerShell 1. Create a SMO Server object and set it to the instance to which you want to deploy the DAC. 2. Open a ServerConnection object and connect to the same instance. 3. Use System.IO.File to load the DAC package file. 4. Use add_DacActionStarted and add_DacActionFinished to subscribe to the DAC deployment events. 5. Set the DatabaseDeploymentProperties. 6. Use the DacStore.Install method to deploy the DAC. 7. Close the file stream used to read the DAC package file. PowerShell examples The following example deploys a DAC named MyApplication on a default instance of the Database Engine, using a DAC definition from a MyApplication.dacpac package. ## Set a SMO Server object to the default instance on the local computer. CD SQLSERVER:\SQL\localhost\DEFAULT $srv = get-item . ## Open a Common.ServerConnection to the same instance. $serverconnection = New-Object Microsoft.SqlServer.Management.Common.ServerConnection($srv.ConnectionContext.SqlConnectionObject) $serverconnection.Connect() $dacstore = New-Object Microsoft.SqlServer.Management.Dac.DacStore($serverconnection) ## Load the DAC package file. $dacpacPath = "C:\MyDACs\MyApplication.dacpac" $fileStream = [System.IO.File]::Open($dacpacPath,[System.IO.FileMode]::OpenOrCreate) $dacType = [Microsoft.SqlServer.Management.Dac.DacType]::Load($fileStream) ## Subscribe to the DAC deployment events. $dacstore.add_DacActionStarted({Write-Host `n`nStarting at $(get-date) :: $_.Description}) $dacstore.add_DacActionFinished({Write-Host Completed at $(get-date) :: $_.Description}) ## Deploy the DAC and create the database. $dacName = "MyApplication" $evaluateTSPolicy = $true $deployProperties = New-Object Microsoft.SqlServer.Management.Dac.DatabaseDeploymentProperties($serverconnection,$dacName) $dacstore.Install($dacType, $deployProperties, $evaluateTSPolicy) $fileStream.Close() More information Data-tier Applications Extract a DAC From a Database Database Identifiers Export a Data-tier Application 3/24/2017 • 4 min to read • Edit Online Exporting a deployed data-tier application (DAC) or database creates an export file that includes both the definitions of the objects in the database and all of the data contained in the tables. The export file can then be imported to another instance of the Database Engine, or to Azure SQL Database. The export-import operations can be combined to migrate a DAC between instances, to create an archive, or to create an on-premise copy of a database deployed in SQL Database. Before You Begin The export process builds a DAC export file in two stages. 1. The export builds a DAC definition in the export file – BACPAC file - in the same way a DAC extract builds a DAC definition in a DAC package file. The exported DAC definition includes all of the objects in the current database. If the export process is run against a database that was originally deployed from a DAC, and changes were made directly to the database after deployment, the exported definition matches the object set in the database, not what was defined in the original DAC. 2. The export bulk copies out the data from all of the tables in the database and incorporates the data into the export file. The export process sets the DAC version to 1.0.0.0 and the DAC description in the export file to an empty string. If the database was deployed from a DAC, the DAC definition in the export file contains the name given to the original DAC, otherwise the DAC name is set to the database name. Limitations and Restrictions A DAC or database can only be exported from a database in SQL Database, or SQL Server 2005 Service Pack 4 (SP4) or later. You cannot export a database that has objects that are not supported in a DAC, or contained users. For more information about the types of objects supported in a DAC, see DAC Support For SQL Server Objects and Versions. Permissions Exporting a DAC requires at least ALTER ANY LOGIN and database scope VIEW DEFINITION permissions, as well as SELECT permissions on sys.sql_expression_dependencies. Exporting a DAC can be done by members of the securityadmin fixed server role who are also members of the database_owner fixed database role in the database from which the DAC is exported. Members of the sysadmin fixed server role or the built-in SQL Server system administrator account named sa can also export a DAC. Using the Export Data-tier Application Wizard To Export a DAC Using a Wizard 1. Connect to the instance of SQL Server, whether on-premise or in SQL Database. 2. In Object Explorer, expand the node for the instance from which you want to export the DAC. 3. Right-click the database name. 4. Click Tasks and then select Export Data-tier Application… 5. Complete the wizard dialogs: Introduction Page Export Settings Page Validation Page Summary Page Progress Page Results Page Introduction Page This page describes the steps for the Export Data-tier Application Wizard. Options Do not show this page again. - Click the check box to stop the Introduction page from being displayed in the future. Next - Proceeds to the Select DAC Package page. Cancel – Cancels the operation and closes the Wizard. Export Settings Page Use this page to specify the location where you want the BACPAC file to be created. Save to local disk - Creates a BACPAC file in a directory on the local computer. Click Browse… to navigate the local computer, or specify the path in the space provided. The path name must include a file name and the .bacpac extension. Save to Windows Azure - Creates a BACPAC file in a Windows Azure container. You must connect to a Windows Azure container in order to validate this option. Note that this option also requires that you specify a local directory for the temporary file. Note that the temporary file will be created at the specified location and will remain there after the operation completes. To specify a subset of tables to export, use the Advanced option. Validation Page Use the validation page to review any issues that block the operation. To continue, resolve blocking issues and then click Re-run Validation to ensure that validation is successful. To continue, click Next. Summary Page Use this page to review the specified source and target settings for the operation. To complete the export operation using the specified settings, click Finish. To cancel the export operation and exit the Wizard, click Cancel. Progress Page This page displays a progress bar that indicates the status of the operation. To view detailed status, click the View details option. Results Page This page reports the success or failure of the export operation, showing the results of each action. Any action that encountered an error will have a link in the Result column. Click the link to view a report of the error for that action. Click Finish to close the Wizard. Using a .Net Framework Application To export a DAC using the Export() method in a .Net Framework application. To view a code example, download the DAC sample application on Codeplex 1. Create a SMO Server object and set it to the instance that contains the DAC to be exported. 2. Open a ServerConnection object and connect to the same instance. 3. Use the Export method of the Microsoft.SqlServer.Management.Dac.DacStore type to export the DAC. Specify the name of the DAC to be exported, and the path to the folder where the export file is to be placed. See Also Data-tier Applications Extract a DAC From a Database Extract a DAC From a Database 3/24/2017 • 7 min to read • Edit Online Use either the Extract Data-tier Application Wizard or a Windows PowerShell script to extract a data-tier application (DAC) package from an existing SQL Server database. The extraction process creates a DAC package file that contains definitions of the database objects and their related instance-level elements. For example, a DAC package file contains the database tables, stored procedures, views, and users, along with the logins that map to the database users. Before you begin You can extract a DAC from databases residing on instances of SQL Database, or SQL Server 2000 Service Pack 4 or later. If the extraction process is run against a database that was deployed from a DAC, only the definitions of the objects in the database are extracted. The process does not reference the DAC registered in msdb (master in SQL Database). The extraction process does not register the DAC definition in the current instance of the Database Engine. For more information about registering a DAC, see Register a Database As a DAC. Limitations and restrictions A DAC can only be extracted from a database in SQL Database, or SQL Server 2005 Service Pack 4 (SP4) or later. You cannot extract a DAC if the database has objects that are not supported in a DAC, or contained users. For more information about the types of objects supported in a DAC, see DAC Support For SQL Server Objects and Versions. Permissions Extracting a DAC requires at least ALTER ANY LOGIN and database scope VIEW DEFINITION permissions, as well as SELECT permissions on sys.sql_expression_dependencies. Extracting a DAC can be done by members of the securityadmin fixed server role who are also members of the database_owner fixed database role in the database from which the DAC is extracted. Members of the sysadmin fixed server role or the built-in SQL Server system administrator account named sa can also extract a DAC. Using the Extract Data-tier Application Wizard To Extract a DAC Using a Wizard 1. In Object Explorer, expand the node for the instance containing the database from which the DAC is to be extracted. 2. Expand the Databases node. 3. Right-click the node for the database from which the DAC is to be extracted, point to Tasks, and then select Extract Data-tier Application… 4. Complete the wizard dialogs: a. Introduction Page b. Select Data Page c. Set Properties Page d. Validation and Summary Page e. Build Package Page Wizard introduction page This page describes the steps for extracting a data-tier application. Do not show this page again. - Click the check box to stop the page from being displayed in the future. Next > - Proceeds to the Choose Method page. Cancel - Ends the wizard without extracting a data-tier application from the database. [Extract Wizard] Select data page Select the reference data that you want to include in your data-tier application (DAC) package file. Including data in your DAC package is optional. The DAC package will already include the schema of all supported database objects and instance objects related to your database. You can include up to 10 MB of reference data in your DAC package file. However, for tables to be included in the DAC, they may not contain binary large object (BLOB) data types such as image or varchar(max). To extract larger amounts of data for transferring to another database, use SQL Server Integration Services, the bulk copy utility, or one of many other data migration techniques. Database table - Select the check box next to the database tables which contain the data that you want to include in your DAC package. You can select up to ten tables that have 10,000 rows or less. [Extract Wizard] Set properties page Use this page of the wizard to describe the data-tier application (DAC). These properties are used to identify the DAC and help distinguish it from others. Name - This name identifies the DAC. It can be different than the name of the DAC package file and should describe your application. For example, if the database is used for a finance application, you may wish to name the DAC Finance. Version (use xx.xx.xx.xx, where x is a number) - A numeric value that identifies the version of the DAC. The DAC version is used in Visual Studio to identify the version of the DAC that developers are working on. When deploying a DAC, the version is stored in the msdb database and can later be viewed under the Data-tier Applications node in SQL Server Management Studio. Description: - Optional. Describes the DAC. When deploying a DAC, the description is stored in the msdb database and can later be viewed under the Data-tier Applications node in Management Studio. Save to DAC package file (include .dacpac extension with file name): - Saves the DAC to a DAC package file, with a .dacpac extension. Click the Browse button to specify a name and location for the file. Overwrite existing file - Select this check box to replace the DAC package file if one already exists with the same name. Validation and summary page On this page, the wizard validates that all database objects are supported by a data-tier application (DAC). It also checks dependencies across database objects to determine the set of objects that can be successfully included in the DAC. After that, it displays the validation report and summarizes the options that you have selected in this wizard. To change an option, click Previous. To begin extracting a DAC, click Next. NOTE!If one or more objects are not supported by a DAC, then the Next button is disabled and the extraction process may not continue. In such cases, it is recommended to remove the non-supported objects and then run this wizard again. Summary - A summary of the options you have selected are listed under DAC properties. The results of the validation are listed under DAC objects. There are three types of results from the validation: Objects included in DAC successfully: these objects and their dependencies are supported, and can be included in the DAC successfully. Objects included in DAC with warnings: these objects are supported, but depend on other objects that are not supported in a DAC. Objects not included in DAC: these objects are not supported and must be removed from the database before successfully extracting a DAC. The validation process checks multiple levels of dependencies. For example, if a stored procedure depends on a table that uses the unsupported CLR data type, the stored procedure will be listed under Objects included in DAC with warnings. If one or more objects are not supported by a DAC, then the Next button is disabled and the extraction process will not continue. In such cases, it is recommended to remove the objects that are not supported and then run this wizard again. Save Report - Enables you to save an HTML-based file that lists all of the objects under the DAC Objects node in the summary. This report can be useful when some of your database objects are not supported in a DAC. Use the report to change or remove objects that are not supported, before trying to extract the DAC again. Build package page Use this page to monitor the progress of the wizard as it extracts the data-tier application (DAC). Action - During the Create and save DAC package file action, the wizard extracts a DAC from your SQL Server database. Then, a DAC package is created in memory and saved to the location you specified. Click on the links in the Result column to see the outcome of the corresponding step. Save Report - Click to save the results of the wizard's progress to a file. Finish - Click to close the wizard after processing has completed, or if an error occurs. Extract a DAC using PowerShell To extract a DAC from a database using the Extract() method in a PowerShell script 1. Create a SMO Server object and set it to the instance that contains the database from which the DAC is to be extracted. 2. Add a variable that specifies the name of the database. 3. Specify the metadata for the DAC, such as the DAC name, version, and description. 4. Specify the path and file name for the extracted DAC package file. 5. Run the Extract method with the information specified above. Example (PowerShell) The following example extracts a DAC named MyApplication from a database named MyDB. ## Set a SMO Server object to the default instance on the local computer. CD SQLSERVER:\SQL\localhost\DEFAULT $srv = get-item . ## Specify the database to extract to a DAC. $dbname = "MyDB" ## Specify the DAC metadata. $applicationname = "MyApplication" $version = "1.0.0.0" $description = "This DAC defines the database used by my application." ## Specify the location and name for the extracted DAC package. $dacpacPath = "C:\MyDACs\MyApplication.dacpac" ## Extract the DAC. $extractionunit = New-Object Microsoft.SqlServer.Management.Dac.DacExtractionUnit($srv, $dbname, $applicationname, $version) $extractionunit.Description = $description $extractionunit.Extract($dacpacPath) See also Data-tier Applications Import a BACPAC File to Create a New User Database 3/24/2017 • 6 min to read • Edit Online Import a data-tier application (DAC) file – a .bacpac file – to create a copy of the original database, with the data, on a new instance of the Database Engine, or to Azure SQL Database. Export-import operations can be combined to migrate a DAC or database between instances, or to create a logical backup, such as creating an on-premise copy of a database deployed in SQL Database. Before You Begin The import process builds a new DAC in two stages. 1. The import creates a new DAC and associated database using the DAC definition stored in the export file, the same way a DAC deploy creates a new DAC from the definition in a DAC package file. 2. The import bulk copies in the data from the export file. SQL Server Utility If you import a DAC to a managed instance of the Database Engine, the imported DAC is incorporated into the SQL Server Utility the next time the utility collection set is sent from the instance to the utility control point. The DAC will then be present in the Deployed Data-tier Applications node of the Management Studio Utility Explorer and reported in the Deployed Data-tier Applications details page. Database Options and Settings By default, the database created during the import will have all of the default settings from the CREATE DATABASE statement, except that the database collation and compatibility level are set to the values defined in the DAC export file. A DAC export file uses the values from the original database. Some database options, such as TRUSTWORTHY, DB_CHAINING, and HONOR_BROKER_PRIORITY, cannot be adjusted as part of the import process. Physical properties, such as the number of filegroups, or the numbers and sizes of files cannot be altered as part of the import process. After the import completes, you can use the ALTER DATABASE statement, SQL Server Management Studio, or SQL Server PowerShell to tailor the database. For more information, see Databases. Limitations and restrictions A DAC can be imported to SQL Database, or an instance of the Database Engine running SQL Server 2005 Service Pack 4 (SP4) or later. If you export a DAC from a higher version, the DAC may contain objects not supported by SQL Server 2005. You cannot deploy those DACs to instances of SQL Server 2005. Prerequisites We recommend that you do not import a DAC export file from unknown or untrusted sources. Such files could contain malicious code that might execute unintended Transact-SQL code or cause errors by modifying the schema. Before you use an export file from an unknown or untrusted source, unpack the DAC and examine the code, like stored procedures and other user-defined code. For more information about how to perform these checks, see Validate a DAC Package. Security To improve security, SQL Server Authentication logins are stored in a DAC export file without a password. When the file is imported, the login is created as a disabled login with a generated password. To enable the logins, log in using a login that has ALTER ANY LOGIN permission and use ALTER LOGIN to enable the login and assign a new password that can be communicated to the user. This is not needed for Windows Authentication logins because their passwords are not managed by SQL Server. Permissions A DAC can only be imported by members of the sysadmin or serveradmin fixed server roles, or by logins that are in the dbcreator fixed server role and have ALTER ANY LOGIN permissions. The built-in SQL Server system administrator account named sa can also import a DAC. Importing a DAC with logins to SQL Database requires membership in the loginmanager or serveradmin roles. Importing a DAC without logins to SQL Database requires membership in the dbmanager or serveradmin roles. Using the Import Data-tier Application Wizard To launch the wizard, use the following steps: 1. Connect to the instance of SQL Server, whether on-premise or in SQL Database. 2. In Object Explorer, right-click on Databases, and then select the Import Data-tier Application menu item to launch the wizard. 3. Complete the wizard dialogs: Introduction Page Import Settings Page Database Settings Page Summary Page Progress Page Results Page Introduction Page This page describes the steps for the Data-tier Application Import Wizard. Options Do not show this page again. – Click the check box to stop the Introduction page from being displayed in the future. Next – Proceeds to the Import Settings page. Cancel – Cancels the operation and closes the wizard. Import Settings Page Use this page to specify the location of the .bacpac file to import. Import from local disk – Click Browse… to navigate the local computer, or specify the path in the space provided. The path name must include a file name and the .bacpac extension. Import from Azure – Imports a BACPAC file from a Microsoft Azure container. You must connect to an Microsoft Azure container to validate this option. Note that this option also requires that you specify a local directory for the temporary file. The temporary file will be created at the specified location and will remain there after the operation completes. When browsing Azure, you will be able to switch between containers within a single account. You must specify a single .bacpac file to continue the import operation. Note that you can sort columns by Name, Size, or Date Modified. To continue, specify the .bacpac file to import, and then click Open. Database Settings Page Use this page to specify details for the database that will be created. For a local instance of SQL Server: New database name – Provide a name for the imported database. Data file path – Provide a local directory for data files. Click Browse… to navigate the local computer, or specify the path in the space provided. Log file path – Provide a local directory for log files. Click Browse… to navigate the local computer, or specify the path in the space provided. To continue, click Next. For an Azure SQL Database: Import a BACPAC file to create a new Azure SQL database provides step by step instructions using the Azure portal, PowerShell, SSMS or SqlPackage. Consult SQL Database options and performance: Understand what's available in each service tier for a detailed look at the different service tiers. Validation Page Use this page to review any issues that block the operation. To continue, resolve blocking issues and then click Rerun Validation to ensure that validation is successful. To continue, click Next. Summary Page Use this page to review the specified source and target settings for the operation. To complete the import operation using the specified settings, click Finish. To cancel the import operation and exit the wizard, click Cancel. Progress Page This page displays a progress bar that indicates the status of the operation. To view detailed status, click the View details option. To continue, click Next. Results Page This page reports the success or failure of the import and create database operations, showing the success or failure of each action. Any action that encountered an error will have a link in the Result column. Click the link to view a report of the error for that action. Click Close to close the wizard. See Also Import a BACPAC file to create a new Azure SQL database Data-tier Applications Export a Data-tier Application Monitor Data-tier Applications 3/24/2017 • 3 min to read • Edit Online A data-tier application (DAC) can be monitored from the Utility Explorer and Object Explorer in SQL Server Management Studio (SSMS), along with system views and tables. In addition, all objects in the database contained in the DAC can be monitored using standard database and Database Engine monitoring techniques. Before You Begin If you deploy a DAC to a managed instance of the Database Engine, information about the deployed DAC is incorporated into the SQL Server Utility the next time the utility collection set is sent from the instance to the utility control point. You can then view basic health information about the DAC by using the Management Studio Utility Explorer. The SSMS Object Explorer displays basic configuration information about each DAC deployed to an instance of the Database Engine, regardless of whether the instance is managed in the SQL Server Utility. Also, the database associated with a deployed DAC can be monitored using the same procedures for monitoring any database. Using the SQL Server Utility The Deployed Data-tier Applications detail page in the Management Studio Utility Explorer displays a dashboard that reports the resource utilization of all DACs that have been deployed to managed instances of the Database Engine. The top pane of the details page lists each deployed DAC with visual indicators showing whether their utilization of CPU and file resources are outside the policies defined for the SQL Server Utility. If you select any DAC in the list view, further details are displayed in tabs in the bottom pane of the page. For more information about the information presented on the details page, see Deployed Data-tier Application Details (SQL Server Utility). After using the Deployed Data-tier Applications detail page to quickly identify any DACs that are either underutilizing or stressing their hardware resource, you can make plans to address any problems. Multiple DACs that are not fully utilizing their current hardware resources could be consolidated to a single server, freeing some of the servers for other uses. If a DAC is stressing the resources on its current server, the DAC can be moved to a larger server, or additional resources can be added to the current server. The minimum and maximum limits for resource usage are defined by application monitoring policies defined in the Utility Administration details page. Database administrators can tailor the policies to match the limits established by their organizations. For example, one company might set 75% as the maximum CPU utilization for a DAC, while another company might set the maximum at 80%. For more information about setting application monitoring policies, see Utility Administration (SQL Server Utility). To view the Deployed Data-tier Applications detail page: 1. Select the View/Utility Explorer menu. 2. Connect the Utility Explorer to the utility control point (UCP). 3. Select the View/Utility Explorer Details menu. 4. Select the Deployed Data-tier Applications node in the Utility Explorer. The information in the Deployed Data-tier Applications detail page comes from the data in the utility management data warehouse, which defaults to collecting the data every 15 minutes. The interval can also be tailored using the Utility Administration details page. Using Object Explorer The SSMS Object Explorer displays basic configuration information about each DAC deployed to an instance of the Database Engine. This includes both managed instances that have been enrolled in the SQL Server Utility, and stand-alone instances that cannot be viewed in the Utility Explorer. To view the details of a DAC deployed to an instance of the Database Engine: 1. Select the View/Object Explorer menu. 2. Connect to the instance of the Database Enginefrom the Object Explorer pane. 3. Select the View/Object Explorer Details menu. 4. Select the server node in Object Explorer that maps to the instance, and then navigate to the Management\Data-tier Applications node. 5. The list view in the top pane of the details page lists each DAC deployed to the instance of the Database Engine. Select a DAC to display the information in the detail pane at the bottom of the page. The right-click menu of the Data-tier Applications node is also used to deploy a new DAC or delete an existing DAC. Using the DAC System Views and Tables The msdb.dbo.sysdac_history_internal system table records the success or failure of all DAC management actions performed on an instance of the Database Engine. The table records the time each action occurred, and which login initiated the action. For more information, see sysdac_history_internal (Transact-SQL). The DAC system views report basic catalog information. For more information, see Data-tier Application Views (Transact-SQL). Monitoring DAC Databases After a DAC has been successfully deployed, the database contained in the DAC operates the same as any other database. Use standard Database Engine techniques and tools for monitoring the performance, log, events, and resource utilization of the database. See Also Data-tier Applications Deploy a Data-tier Application Register a Database As a DAC 4/6/2017 • 6 min to read • Edit Online Use either the Register Data-tier Application Wizard or a Windows PowerShell script to build a data-tier application (DAC) definition that describes the objects in an existing database, and register the DAC definition in the msdb system database (master in Azure SQL Database). Before you begin: Limitations and Restrictions, Permissions To upgrade a DAC, using: The Register Data-tier Application Wizard, PowerShell Before You Begin The registration process creates a DAC definition that defines the objects in the database. The combination of the DAC definition and the database form a DAC instance. If you register a database as a DAC on a managed instance of the Database Engine, the registered DAC will be incorporated into the SQL Server Utility the next time the utility collection set is sent from the instance to the Utility Control Point. The DAC will then be present in the Deployed Data-tier Applications node of the Management Studio Utility Explorer and reported in the Deployed Datatier Applications details page. Limitations and Restrictions DAC registration can only be performed on a database in SQL Database, or SQL Server 2005 Service Pack 4 (SP4) or later. DAC registration cannot be performed if a DAC is already registered for the database. For example, if the database was created by deploying a DAC, you cannot run the Register Data-tier Application Wizard. You cannot register a DAC if the database has objects that are not supported in a DAC, or contained users. For more information about the types of objects supported in a DAC, see DAC Support For SQL Server Objects and Versions. Permissions Registering a DAC in an instance of Database Engine requires at least ALTER ANY LOGIN and database scope VIEW DEFINITION permissions, SELECT permissions on sys.sql_expression_dependencies, and membership in the dbcreator fixed server role. Members of the sysadmin fixed server role or the built-in SQL Server system administrator account named sa can also register a DAC. Registering a DAC that does not contain logins in SQL Database requires membership in the dbmanager or serveradmin roles. Registering a DAC that contains logins in SQL Database requires membership in the loginmanager or serveradmin roles. Using the Register Data-tier Application Wizard To Register a DAC Using a Wizard 1. In Object Explorer, expand the node for the instance containing the database to be registered as a DAC. 2. Expand the Databases node. 3. Right-click the database to be registered, point to Tasks, and then select Register As Data-tier Application… 4. Complete the wizard dialogs: a. Introduction Page b. Set Properties Page c. Validation and Summary Page d. Register DAC Page Introduction Page This page describes the steps for registering a data-tier application. Do not show this page again. - Click the check box to stop the page from being displayed in the future. Next > - Proceeds to the Set Properties page. Cancel - Terminates the wizard without registering a DAC. Using the Register Data-tier Application Wizard Set Properties Page Use this page to specify DAC-level properties such as the application name and version. Application name. - A string that specifies the name used to identify the DAC defintion, the field is been populated with the database name. Version. - A numeric value that identifies the version of the DAC. The DAC version is used in Visual Studio to identify the version of the DAC that developers are working on. When deploying a DAC, the version is stored in the msdb database and can later be viewed under the Data-tier Applications node in SQL Server Management Studio. Description. - Optional. Text that explains the purpose of the DAC. When deploying a DAC, the description is stored in the msdb database and can later be viewed under the Data-tier Applications node in Management Studio. < Previous - Returns you to the Introduction page. Next > - Verifies that a DAC can be built from the objects in the database, and displays the results in the Validation and Summary page. Cancel - Terminates the wizard without registering the DAC. Using the Register Data-tier Application Wizard Validation and Summary Page Use this page to review the actions the wizard will take when registering the DAC. The page transitions through three states as it verifies that a DAC can be built from the objects in the database. Using the Register Data-tier Application Wizard Retrieving Objects Retrieving database and server objects. - Displays a progress bar as the wizard retrieves all of the required objects from the database and the instance of the Database Engine. < Previous - Returns you to the Set Properties page to change your entries. Next > - Registers the DAC and displays the results in the Register DAC page. Cancel - Terminates the wizard without registering the DAC. Using the Register Data-tier Application Wizard Validating Objects Checking SchemaName . ObjectName . - Displays a progress bar as the wizard verifies the dependencies of the retrieved objects, and verifies that they are all valid objects for a DAC. SchemaName.ObjectName identify which object is currently being verified. < Previous - Returns you to the Set Properties page to change your entries. Next > - Registers the DAC and displays the results in the Register DAC page. Cancel - Terminates the wizard without registering the DAC. Using the Register Data-tier Application Wizard Summary The following setting will be used to register your DAC. - Displays a report of the properties and objects that will be included in the DAC. Save Report - Select this button to save a copy of the validation report to an HTML file. The default folder is a SQL Server Management Studio\DAC Packages folder in the Documents folder of your Windows account. < Previous - Returns you to the Set Properties page to change your entries. Next > - Registers the DAC and displays the results in the Register DAC page. Cancel - Terminates the wizard without registering the DAC. Using the Register Data-tier Application Wizard Register DAC Page This page reports the success or failure of the registration. Registering the DAC - Reports the success or failure of each action taken to register the DAC. Review the information to determine the success or failure of each action. Any action that encountered an error will have a link in the Result column. Select the link to view a report of the error for that action. Save Report - Select this button to save the registration report to an HTML file. The file reports the status of each action, including all errors generated by any of the actions. The default folder is a SQL Server Management Studio\DAC Packages folder in the Documents folder of your Windows account. The file name is in the format <DACPackageName>_RegisterDACReport_yyyymmdd.html, where <DACPackageName> is the name of the package being deployed, yyyy = the current year, mm = the current month, and dd = the current day. Finish - Terminates the wizard. Using the Register Data-tier Application Wizard Register a DAC Using PowerShell To register a database as a DAC using the Register() method in a PowerShell script 1. Create a SMO Server object and set it to the instance that contains the database to be registered as a DAC. 2. Add a variable that specifies the name of the database. 3. Specify the metadata for the DAC, such as the DAC name, version, and description. 4. Run the Register method with the information specified above. Example (PowerShell) The following example registers a database named MyDB as a DAC. ## Set a SMO Server object to the default instance on the local computer. CD SQLSERVER:\SQL\localhost\DEFAULT $srv = get-item . ## Specify the database to register as a DAC. $dbname = "MyDB" ## Specify the DAC metadata. $applicationname = "MyApplication" $version = "1.0.0.0" $description = "This DAC defines the database used by my application." ## Register the DAC. $registerunit = New-Object Microsoft.SqlServer.Management.Dac.DacExtractionUnit($srv, $dbname, $applicationname, $version) $registerunit.Description = $description $registerunit.Register() See Also Data-tier Applications Unpack a DAC Package 3/24/2017 • 2 min to read • Edit Online Use the Unpack Data-tier Application dialog box to unzip the scripts and files from a data-tier application (DAC) package. The scripts and files are placed in a folder where they can be reviewed before the package is used to deploy the DAC into a production system. The contents of one DAC can also be compared with the contents of another package unpacked to another folder. 1. Before you begin: Security 2. To unpack a DAC, using: Unpack Data-tier Application Dialog, Examine the Contents of a DAC Package Security We recommend that you do not deploy a DAC package from unknown or untrusted sources. Such DACs could contain malicious code that might execute unintended Transact-SQL code or cause errors by modifying the schema. Before you use a DAC from an unknown or untrusted source, deploy it on an isolated test instance of the Database Engine, unpack the DAC and examine the code, such as stored procedures or other user-defined code. Unpack Data-tier Application Dialog To Unpack a DAC Package File In Windows Explorer, navigate to the location of a DAC package (.dacpac) file. Use one of these two methods to open the Unpack Data-tier Application dialog: 1. Right-click the DAC package (.dacpac) file and select Unpack. 2. Double-click the DAC package file. Complete the dialogs: Unpack Microsoft SQL Server DAC Package File Browse for Folder Unpack Microsoft SQL Server DAC Package File Use this page to specify the destination folder in which to place the unpacked files, and then run the unpack operation. Files will be unpacked to this folder: - Specify the full path to the folder for the unpacked files. If the folder exists and you know the full path, type the path in the box. If not, click the Browse button to navigate to a folder or create a new folder. Browse - Opens the Browse for Folder page where you can choose a folder by navigating the file hierarchy, or create a new folder. Unpack - Starts the unpack operation. Cancel - Terminates the dialog box without unpacking the DAC package. Browse for Folder Use this page to choose the destination folder for the unpack operation. Optionally, you can also create a new folder. Folder list - Displays the file hierarchy for your computer. Expand the nodes to navigate to the folder in which to unpack the DAC package. Click on the folder and then click OK. Make New Folder - Opens a dialog in which you can specify the name for a new folder to be created in the folder you have currently selected in the folder hierarchy. OK - Places the path to the folder you selected in the Files will be unpacked to this folder box of the Unpack DAC Package File page and returns you to that page. Cancel - Terminates the dialog box without selecting a folder. Examine the Contents of a DAC Package After unpacking the package, you can examine the files produced by the Unpack Data-tier Application dialog. The dialog box builds the following files in the selected destination folder: 1. A Transact-SQL script that contains the statements for creating the objects defined in the DAC. The file name is DACName.sql, where DACName is the name of the DAC. 2. All XML files from the package. 3. All files from the Extra Files section of the DAC, such as the DAC pre-deployment or post-deployment files. For more information, see Validate a DAC Package. See Also Data-tier Applications Deploy a Data-tier Application Upgrade a Data-tier Application Upgrade a Data-tier Application 4/29/2017 • 13 min to read • Edit Online Use either the Upgrade Data-tier Application Wizard or a Windows PowerShell script to change the schema and properties of a currently deployed data-tier application (DAC) to match the schema and properties defined in a new version of the DAC. Before you begin: Choosing DAC Upgrade Options, Limitations and Restrictions, Prerequisites, Security, Permissions To upgrade a DAC, using: The Upgrade Data-tier Application Wizard, PowerShell Before You Begin A DAC upgrade is an in-place process that alters the schema of the existing database to match the schema defined in a new version of the DAC. The new version of the DAC is supplied in a DAC package file. For more information about creating a DAC package, see Data-tier Applications. Choosing DAC Upgrade Options There are four upgrade options for an in-place upgrade: Ignore Data Loss – If True, the upgrade will proceed even if some of the operations result in the loss of data. If False, these operations will terminate the upgrade. For example, if a table in the current database is not present in the schema of the new DAC, the table will be dropped if True is specified. The default setting is True. Block on Changes – If True, the upgrade is terminated if the database schema is different than that defined in the previous DAC. If False, the upgrade continues even if changes are detected. The default setting is False. Rollback on Failure – If True, the upgrade is enclosed in a transaction, and if errors are encountered a rollback will be attempted. If False, all changes are committed as they are made and if errors occur you may have to restore a previous backup of the database. The default setting is False. Skip Policy Validation – If True, the DAC server selection policy is not evaluated. If False, the policy is evaluated and the upgrade terminates if there is a validation error. The default setting is False. Limitations and Restrictions DAC uprades can only be performed in SQL Database, or SQL Server 2005 Service Pack 4 (SP4) or later. Prerequisites It is prudent to take a full database backup before starting the upgrade. If an upgrade encounters an error and cannot roll back all of its changes, you may need to restore the backup. Before starting the upgrade, there are several actions that you should take to validate the DAC package and the upgrade actions. For more information about how to perform these checks, see Validate a DAC Package. We recommend that you do not upgrade by using a DAC package from unknown or untrusted sources. Such packages could contain malicious code that might execute unintended Transact-SQL code or cause errors by modifying the schema. Before you use a package from an unknown or untrusted source, unpack the DAC and examine the code, such as stored procedures or other user-defined code. If changes have been made to the current database after the last version of the DAC was deployed, some of the changes may prevent the successful completion of the upgrade, or be removed by the upgrade. You should first generate and review a report of any such changes made in the database. It is prudent to generate a list of the schema changes the upgrade will perform, and review the list for any problems. The application name in the DAC package must match the application name of the currently deployed DAC. For example, if the current DAC has an application name of GeneralLedger, you can only upgrade by using a DAC package that also has an application name of GeneralLedger. Ensure there is enough transaction log space available to log all of the modifications. Security To improve security, SQL Server Authentication logins are stored in a DAC package without a password. When the package is deployed or upgraded, the login is created as a disabled login with a generated password. To enable the logins, log in using a login that has ALTER ANY LOGIN permission and use ALTER LOGIN to enable the login and assign a new password that can be communicated to the user. This is not needed for Windows Authentication logins because their passwords are not managed by SQL Server. Permissions A DAC can only be upgraded by members of the sysadmin or serveradmin fixed server roles, or by logins that are in the dbcreator fixed server role and have ALTER ANY LOGIN permissions. The login must be the owner of the existing database. The built-in SQL Server system administrator account named sa can also upgrade a DAC. Using the Upgrade Data-tier Application Wizard To Upgrade a DAC Using a Wizard 1. In Object Explorer, expand the node for the instance containing the DAC to be upgraded. 2. Expand the Management node, and then expand the Data-tier Applications node. 3. Right-click the node for the DAC to be upgraded, and then select Upgrade Data-tier Application… 4. Complete the wizard dialogs: a. Introduction Page b. Select Package Page c. Review Policy Page d. Detect Change Page e. Review the Upgrade Plan f. Summary Page g. Upgrade DAC Page Introduction Page This page describes the steps for upgrading a data-tier application. Do not show this page again. - Click the check box to stop the page from being displayed in the future. Next > - Proceeds to the Select Package page. Cancel - Terminates the wizard without upgrading the DAC. Select Package Page Use this page to specify the DAC package that contains the new version of the data-tier application. The page transitions through two states. Select the DAC Package Use the initial state of the page to choose the DAC package to deploy. The DAC package must be a valid DAC package file and must have a .dacpac extension. The DAC application name in the DAC package must be the same as the application name of the current DAC. DAC Package - Specify the path and file name of the DAC package that contains the new version of the data-tier application. You can select the Browse button at the right of the box to browse to the location of the DAC package. Application Name - A read-only box that displays the DAC application name assigned when the DAC was authored or extracted from a database. Version - A read-only box that displays the version assigned when the DAC was authored or extracted from a database. Description - A read-only box that displays the description written when the DAC was authored or extracted from a database. < Previous - Returns to the Introduction page. Next > - Displays a progress bar as the wizard confirms that the selected file is a valid DAC package. Cancel - Terminates the wizard without upgrading the DAC. Validating the DAC Package Displays a progress bar as the wizard confirms that the selected file is a valid DAC package. If the DAC package is validated, the wizard proceeds to the Review Policy page. If the file is not a valid DAC package, the wizard remains on the Select DAC Package page. Either select another valid DAC package or cancel the wizard and generate a new DAC package. Validating the contents of the DAC - The progress bar that reports the current status of the validation process. < Previous - Returns to the initial state of the Select Package page. Next > - Proceeds to the final version of the Select Package page. Cancel - Terminates the wizard without deploying the DAC. Review Policy Page Use this page to review the results of evaluating the DAC server selection policy, if the DAC has a policy. The DAC server selection policy is optional, and is assigned to a DAC authored in Microsoft Visual Studio. The policy uses the server selection policy facets to specify conditions an instance of the Database Engine should meet to host the DAC. Evaluation results of policy conditions - A read-only report showing whether the evaluations of the conditions in the DAC server selection policy succeeded. The results of evaluating each condition are reported on a separate line. Ignore policy violations - Use this check box to proceed with the upgrade if one or more of the policy conditions failed. Only select this option if you are sure that all of the conditions which failed will not prevent the successful operation of the DAC. < Previous - Returns to the Select Package page. Next > - Proceeds to the Detect Change page. Cancel - Terminates the wizard without upgrading the DAC. Detect Change Page Use this page reports the results of the wizards check for changes made to the database that make it's schema different than the schema definition stored in the DAC metadata in msdb. For example, if CREATE, ALTER, or DROP statements have been used to add, change, or remove objects from the database after the DAC was originally deployed. The page first displays a progress bar, and then reports the results of the analysis. Detecting change, this may take a few minutes - Displays a progress bar as the wizard checks for differences between the current schema of the database and the objects in the DAC definition. Change detection results: - Indicates that the analysis has completed and the results are reported below. The database DatabaseName has not changed - The wizard detected no differences in the objects defined in the database and their counterparts in the DAC definition. The database DatabaseName has changed - The wizard detected changes between the objects in the database and their counterparts in the DAC definition. Proceed despite possible loss of changes - Specifies that you understand some of the objects or data in the current database will not be present in the new database, and that you are willing to proceed with the upgrade. You should select this button only if you have analyzed the change report and understand the steps you must perform to manually transfer any objects or data required in the new database. If you are not sure, click the Save Report button to save the change report, then click Cancel. Analyze the report, plan how to transfer any required objects and data after the upgrade completes, then restart the wizard. Save Report - Click the button to save a report of the changes the wizard detected between the objects in the database and their counterparts in the DAC definition. You can then review the report to determine if you need to take actions after the upgrade completes to incorporate some or all of the objects listed in the report into the new database. < Previous - Returns to the Select DAC Package page. Next > - Proceeds to the Options page. Cancel - Terminates the wizard without deploying the DAC. Options Page Use this page to select the rollback on failure option for the upgrade. Rollback on failure – Select this option to enclose the upgrade in a transaction which the wizard can attempt to roll back if errors occur. For more information about the option, see Choosing DAC Upgrade Options. Restore Defaults - Returns the option to its default setting of false. < Previous - Returns to the Detect Change page. Next > - Proceeds to the Review the Upgrade Plan page. Cancel - Terminates the wizard without deploying the DAC. Review the Upgrade Plan Page Use this page to do review the actions that will be taken by the upgrade process. Only proceed when you are confident the upgrade will not create problems. The following actions will be used to upgrade the DAC. - Review the information displayed to ensure the actions taken will be correct. The Action column displays the actions, such as Transact-SQL statements, that will be run to perform the upgrade. The Data Loss column will contain a warning if the associated action could delete data. Refresh – refreshes the action list. Save Action Report – saves the contents of the action window to an HTML file. Proceed despite possible loss of changes - Specifies that you understand some of the objects or data in the current database will not be present in the new database, and that you are willing to proceed with the upgrade. You should select this button only if you have analyzed the change report and understand the steps you must perform to manually transfer any objects or data required in the new database. If you are not sure, click the Save Action Report button to save the change report and the Save Scripts button to save the Transact-SQL script, then click Cancel. Analyze the report and script, and then plan how to transfer any required objects and data after the upgrade completes, then restart the wizard. Save Scripts – saves the Transact-SQL statements that will be used to perform the upgrade to a text file. Restore Defaults - Returns the option to its default setting of false. < Previous - Returns to the Detect Change page. Next > - Proceeds to the Summary page. Cancel - Terminates the wizard without deploying the DAC. Summary Page Use this page to do a final review of the actions the wizard will take when upgrading the DAC. The following settings will be used to upgrade your DAC. - Review the information displayed to ensure the actions taken will be correct. The window displays the DAC you selected to be upgraded, and the DAC package containing the new version of the DAC. The window also displays whether the current version of the database is the same as the current DAC definition, or if the database has changed. < Previous - Returns you to the Review the Upgrade Plan page. Next > - Deploys the DAC and displays the results in the Upgrade DAC page. Cancel - Terminates the wizard without deploying the DAC. Upgrade DAC Page This page reports the success or failure of the upgrade operation. Upgrading the DAC - Reports the success or failure of each action taken to upgrade the DAC. Review the information to determine the success or failure of each action. Any action that encountered an error will have a link in the Result column. Select the link to view a report of the error for that action. Save Report - Select this button to save the upgrade report to an HTML file. The file reports the status of each action, including all errors generated by any of the actions. The default folder is a SQL Server Management Studio\DAC Packages folder in the Documents folder of your Windows account. Finish - Terminates the wizard. Using PowerShell To upgrade a DAC using the IncrementalUpgrade() method in a PowerShell script 1. Create a SMO Server object and set it to the instance that contains the DAC to be upgraded. 2. Open a ServerConnection object and connect to the same instance. 3. Use System.IO.File to load the DAC package file. 4. Use add_DacActionStarted and add_DacActionFinished to subscribe to the DAC upgrade events. 5. Set the DacUpgradeOptions. 6. Use the IncrementalUpgrade method to upgrade the DAC. 7. Close the file stream used to read the DAC package file. Example (PowerShell) The following example upgrades a DAC named MyApplication on a default instance of the Database Engine, using a new DAC version in a MyApplication2017.dacpac package. ## Set a SMO Server object to the default instance on the local computer. CD SQLSERVER:\SQL\localhost\DEFAULT $srv = get-item . ## Open a Common.ServerConnection to the same instance. $serverconnection = New-Object Microsoft.SqlServer.Management.Common.ServerConnection($srv.ConnectionContext.SqlConnectionObject) $serverconnection.Connect() $dacstore = New-Object Microsoft.SqlServer.Management.Dac.DacStore($serverconnection) ## Load the DAC package file. $dacpacPath = "C:\MyDACs\MyApplication2017.dacpac" $fileStream = [System.IO.File]::Open($dacpacPath,[System.IO.FileMode]::OpenOrCreate) $dacType = [Microsoft.SqlServer.Management.Dac.DacType]::Load($fileStream) ## Subscribe to the DAC upgrade events. $dacstore.add_DacActionStarted({Write-Host `n`nStarting at $(get-date) :: $_.Description}) $dacstore.add_DacActionFinished({Write-Host Completed at $(get-date) :: $_.Description}) ## Upgrade the DAC and close the package. $dacName = "MyApplication" ## Set the upgrade options. $upgradeProperties = New-Object Microsoft.SqlServer.Management.Dac.DacUpgradeOptions $upgradeProperties.blockonchanges = $true $upgradeProperties.ignoredataloss = $false $upgradeProperties.rollbackonfailure = $true $ upgradeProperties.skippolicyvalidation = $false ## Upgrade the DAC $dacstore.IncrementalUpgrade($dacName, $dacType, $upgradeProperties) ## Close the package file. $fileStream.Close() See Also Data-tier Applications SQL Server PowerShell Validate a DAC Package 4/29/2017 • 5 min to read • Edit Online It is a good practice to review the contents of a DAC package before deploying it in production, and to validate the upgrade actions before upgrading an existing DAC. This is especially true when deploying packages that were not developed in your organization. 1. Before you begin: Prerequisites 2. To upgrade a DAC, using: View the Contents of a DAC, View Database Changes, View Upgrade Actions, Compare DACs Prerequisites We recommend that you do not deploy a DAC package from unknown or untrusted sources. Such DACs could contain malicious code that might execute unintended Transact-SQL code or cause errors by modifying the schema. Before you use a DAC from an unknown or untrusted source, deploy it on an isolated test instance of the Database Engine, run DBCC CHECKDB (Transact-SQL) on the database, and also examine the code, such as stored procedures or other user-defined code, in the database. View the Contents of a DAC There are two mechanisms for viewing the contents of a data-tier application (DAC) package. You can import the DAC package to a DAC project in SQL Server Developer Tools. You can unpack the contents of the package to a folder. View a DAC in SQL Server Developer Tools 1. Open the File menu, select New, and then select Project…. 2. Select the SQL Server project template, and specify a Name, Location, and Solution name. 3. In Solution Explorer, right click the project node and select Properties…. 4. On the Project Settings tab, in the Output Types section, select the Data-tier Application (.dacpac File) check box, and then close the properties dialog. 5. In Solution Explorer, right click the project node and select Import Data-tier Application…. 6. Use Solution Explorer to open all of the files in the DAC, such as the server selection policy and the preand post-deployment scripts. 7. Use the Schema View to review all of the objects in the schema, particularly reviewing the code in objects such as functions or stored procedures. View a DAC in a Folder Unpack the DAC package into a folder by following the instructions in Unpack a DAC Package. View the contents of the Transact-SQL scripts by opening them in the Database Engine Query Editor in Management Studio. View the contents of the text files in tools such as notepad. View Database Changes After the current version of a DAC was deployed to production, changes may have been made directly to the associated database that might conflict with the schema defined in a new version of the DAC. Before upgrading to a new version of the DAC, check to see if such changes have been made to the database. View Database Changes by Using a Wizard 1. Run the Upgrade Data-tier Application wizard, specifying the currently deployed DAC and the DAC package containing the new version of the DAC. 2. On the Detect Change page, review the report of the changes that have been made to the database. 3. Select Cancel if you do not want to continue with the upgrade. 4. For more information on using the wizard, see Upgrade a Data-tier Application. View Database Changes by Using PowerShell 5. Create a SMO Server object and set it to the instance that contains the DAC to be viewed. 6. Open a ServerConnection object and connect to the same instance. 7. Specify the DAC name in a variable. 8. Use the GetDatabaseChanges() method to retrieve a ChangeResults object, and pipe the object to a text file to generate a simple report of new, deleted, and changed objects. View Database Changes Example (PowerShell) View Database Changes Example (PowerShell) The following example reports any database changes that have been made in a deployed DAC named MyApplicaiton. ## Set a SMO Server object to the default instance on the local computer. CD SQLSERVER:\SQL\localhost\DEFAULT $srv = get-item . ## Open a Common.ServerConnection to the same instance. $serverconnection = New-Object Microsoft.SqlServer.Management.Common.ServerConnection($srv.ConnectionContext.SqlConnectionObject) $serverconnection.Connect() $dacstore = New-Object Microsoft.SqlServer.Management.Dac.DacStore($serverconnection) ## Specify the DAC instance name. $dacName = "MyApplication" ## Generate the change list and save to file. $dacChanges = $dacstore.GetDatabaseChanges($dacName) | Out-File -Filepath C:\DACScripts\MyApplicationChanges.txt View Upgrade Actions Before using a new version of a DAC package to upgrade a DAC that was deployed from an earlier DAC package, you can generate a report that contains the Transact-SQL statements that will be run during the upgrade, and then review the statements. Report Upgrade Actions by Using a Wizard 1. Run the Upgrade Data-tier Application wizard, specifying the currently deployed DAC and the DAC package containing the new version of the DAC. 2. On the Summary page, review the report of the upgrade actions. 3. Select Cancel if you do not want to continue with the upgrade. 4. For more information on using the wizard, see Upgrade a Data-tier Application. Report Upgrade Actions by Using PowerShell 5. Create a SMO Server object and set it to the instance that contains the deployed DAC. 6. Open a ServerConnection object and connect to the same instance. 7. Use System.IO.File to load the DAC package file. 8. Specify the DAC name in a variable. 9. Use the GetIncrementalUpgradeScript() method to get a list of the Transact-SQL statements an upgrade would run, and pipe the list to a text file. 10. Close the file stream used to read the DAC package file. View Upgrade Actions Example (PowerShell) View Upgrade Actions Example (PowerShell) The following example reports the Transact-SQL statements that would be run to upgrading a DAC named MyApplicaiton to the schema defined in a MyApplication2017.dacpac file. ## Set a SMO Server object to the default instance on the local computer. CD SQLSERVER:\SQL\localhost\DEFAULT $srv = get-item . ## Open a Common.ServerConnection to the same instance. $serverconnection = New-Object Microsoft.SqlServer.Management.Common.ServerConnection($srv.ConnectionContext.SqlConnectionObject) $serverconnection.Connect() $dacstore = New-Object Microsoft.SqlServer.Management.Dac.DacStore($serverconnection) ## Load the DAC package file. $dacpacPath = "C:\MyDACs\MyApplication2017.dacpac" $fileStream = [System.IO.File]::Open($dacpacPath,[System.IO.FileMode]::OpenOrCreate) $dacType = [Microsoft.SqlServer.Management.Dac.DacType]::Load($fileStream) ## Specify the DAC instance name. $dacName = "MyApplication" ## Generate the upgrade script and save to file. $dacstore.GetIncrementalUpgradeScript($dacName, $dacType) | Out-File -Filepath C:\DACScripts\MyApplicationUpgrade.sql ## Close the filestream to the new DAC package. $fileStream.Close() Compare DACs Before upgrading a DAC, it is a good practice to review the differences in the database and instance-level objects between the current and new DACs. If you do not have a copy of the package for the current DAC, you can extract a package from the current database. If you import both DAC packages into DAC projects in SQL Server Developer Tools, you can use the Schema Compare tool to analyze the differences between the two DACs. Alternatively, unpack the DACs into separate folders. You can then use a difference tool, such as the WinDiff utility, to analyze the differences. See Also Data-tier Applications Deploy a Data-tier Application Upgrade a Data-tier Application Deploy a Database By Using a DAC 3/24/2017 • 5 min to read • Edit Online Use the Deploy a Database to SQL Azure Wizard to deploy a database between an instance of the Database Engine and a Azure SQL Database server, or between two Azure SQL Databaseservers. Before You Begin The wizard uses a Data-tier Application (DAC) BACPAC archive file to deploy both the data and the definitions of database objects. It performs a DAC export operation from the source database, and a DAC import to the destination. Database Options and Settings By default, the database created during the deployment will have the default settings from the CREATE DATABASE statement. The exception is that the database collation and compatibility level are set to the values from the source database. Database options, such as TRUSTWORTHY, DB_CHAINING and HONOR_BROKER_PRIORITY, cannot be adjusted as part of the deployment process. Physical properties, such as the number of filegroups, or the numbers and sizes of files cannot be altered as part of the deployment process. After the deployment completes, you can use the ALTER DATABASE statement, SQL Server Management Studio, or SQL Server PowerShell to tailor the database. Limitations and Restrictions The Deploy Database wizard supports deploying a database: From an instance of the Database Engine to Azure SQL Database. From Azure SQL Database to an instance of the Database Engine. Between two Azure SQL Database servers. The wizard does not support deploying databases between two instances of the Database Engine. An instance of the Database Engine must be running SQL Server 2005 Service Pack 4 (SP4) or later to work with the wizard. If a database on an instance of the Database Engine contains objects not supported on Azure SQL Database, you cannot use the wizard to deploy the database to Azure SQL Database. If a database on Azure SQL Database contains objects not supported by SQL Server, you cannot use the wizard to deploy the database to instances of SQL Server. Security To improve security, SQL Server Authentication logins are stored in a DAC BACPAC file without a password. When the BACPAC is imported, the login is created as a disabled login with a generated password. To enable the logins, log in using a login that has ALTER ANY LOGIN permission and use ALTER LOGIN to enable the login and assign a new password that can be communicated to the user. This is not needed for Windows Authentication logins because their passwords are not managed by SQL Server. Permissions The wizard requires DAC export permissions on the source database. The login requires at least ALTER ANY LOGIN and database scope VIEW DEFINITION permissions, as well as SELECT permissions on sys.sql_expression_dependencies. Exporting a DAC can be done by members of the securityadmin fixed server role who are also members of the database_owner fixed database role in the database from which the DAC is exported. Members of the sysadmin fixed server role or the built-in SQL Server system administrator account named sa can also export a DAC. The wizard requires DAC import permissions on the destination instance or server. The login must be a member of the sysadmin or serveradmin fixed server roles, or in the dbcreator fixed server role and have ALTER ANY LOGIN permissions. The built-in SQL Server system administrator account named sa can also import a DAC. Importing a DAC with logins to SQL Database requires membership in the loginmanager or serveradmin roles. Importing a DAC without logins to SQL Database requires membership in the dbmanager or serveradmin roles. Using the Deploy Database Wizard To migrate a database using the Deploy Database Wizard 1. Connect to the location of the database you want to deploy. You can specify either an instance of Database Engine or a Azure SQL Database server. 2. In Object Explorer, expand the node for the instance that has the database. 3. Expand the Databases node. 4. Right click the database you want to deploy, select Tasks, and then select Deploy Database to SQL Azure… 5. Complete the Wizard dialogs: Introduction Page Deployment Settings Summary Page Progress Results Introduction Page This page describes the steps for the Deploy Database Wizard. Options Do not show this page again. - Click the check box to stop the Introduction page from being displayed in the future. Next - Proceeds to the Deployment Settings page. Cancel – Cancels the operation and closes the Wizard. Deployment Settings Page Use this page to specify the destination server and to provide details about your new database. Local host: Server connection – Specify server connection details and then click Connect to verify the connection. New database name – Specify a name for the new database. SQL Database database settings: SQL Database edition – Select the edition of SQL Database from the drop-down menu. Maximum database size – Select the maximum database size from the drop-down menu. Other settings: Specify a local directory for the temporary file, which is the BACPAC archive file. Note that the file will be created at the specified location and will remain there after the operation completes. Summary Page Use this page to review the specified source and target settings for the operation. To complete the deploy operation using the specified settings, click Finish. To cancel the deploy operation and exit the Wizard, click Cancel. Progress Page This page displays a progress bar that indicates the status of the operation. To view detailed status, click the View details option. Results Page This page reports the success or failure of the deploy operation, showing the results of each action. Any action that encountered an error will have a link in the Result column. Click the link to view a report of the error for that action. Click Finish to close the Wizard. Using a .Net Framework Application To deploy a database using the DacStoreExport() and Import() methods in a .Net Framework application. To view a code example, download the DAC sample application on Codeplex 1. Create a SMO Server object and set it to the instance or server that contains the database to be deployed. 2. Open a ServerConnection object and connect to the same instance. 3. Use the Export method of the Microsoft.SqlServer.Management.Dac.DacStore type to export the database to a BACPAC file. Specify the name of the database to be exported, and the path to the folder where the BACPAC file is to be placed. 4. Create a SMO Server object and set it to the destination instance or server. 5. Open a ServerConnection object and connect to the same instance. 6. Use the Import method of the Microsoft.SqlServer.Management.Dac.DacStore type to import the BACPAC. Specify the BACPAC file created by the export. See Also Data-tier Applications Export a Data-tier Application Import a BACPAC File to Create a New User Database