Deploying Analysis Services Databases from BIDS

Once the developer is finished making changes to an Analysis Services project in Business Intelligence Development Studio (BIDS), he or she deploys the object definitions within the project to an Analysis Services instance. The deployment process, when performed through BIDS, takes place over four distinct steps:

1. Script building

2. Object comparison

3. Script submission

4. Process protection

Note These three steps are not what are formally described in the product documentation. Instead, Books Online refers to Build and Deploy processes with the Deploy process encompassing the Build process. To align the formal processes with these three steps, the script building step aligns to the Build process while the object comparison and script submission steps are the additional steps included in the Deploy process.

During the first step, a series of XML files are assembled in the project’s Bin subfolder. These files encapsulate the information within the project required for successfully deployment. Each is recognizable through the use of one of four file extensions:

· .asdatabase

· .configsettings

· .deploymenttargets

· .deploymentoptions

The .asdatabase file contains a ASSL script defining the database and all the objects within it. The script is assembled from the individual files of the Analysis Services project and serves as the basis for the script submitted to Analysis Services in the final step.

The .configsettings file contains a listing of objects within the Analysis Services database as defined by the project associated with data storage as well as data sources. In deployments involving the Analysis Services Deployment Wizard, this file can be used to override certain information in the .asdatabase file.

The .deploymenttargets file identifies the Analysis Services instance and database to which the script is to eventually be applied. The information in this file comes from database properties accessible within the Analysis Services project by opening the Solution Explorer window, right-clicking the database object, selecting properties, and navigating to the Deployment page.

The .deploymentoptions file contains various settings controlling the deployment process. Some of these settings are accessible through the previously mentioned database properties dialog’s Deployment page. Others are hardcoded for BIDS deployments.

To complete the script building step, a fifth file, LastBuilt.xml, is assembled. This file, located within the Obj subfolder associated with the project’s currently selected configuration. This file records a timestamp and hash value for each object within the project. There is little to no documentation on the LastBuilt.xml file but it appears this information serves as the foundation of the following object comparison step.

Note The database properties dialog provides the means to select (and define) various configurations for your project. Each configuration represents a collection of settings controlling aspects of the project environment as well as the deployment process. The default configuration for an Analysis Services project is Development so that the LastBuilt.xml file is often located in a subfolder called Development under the project’s Obj subfolder.

With the script building step completed, the deployment process moves onto the object comparison step. During this step, a connection is made to the targeted Analysis Services instance and a Discover statement submitted to retrieve the name, id, and timestamp associated with various database objects. The values returned are compared to the information in the LastBuilt.xml file to determine which changes need to be pushed to the Analysis Services instance.

Following this determination the process moves into the script submission step. An XMLA Alter statement based on information in the .asdatabase, .configsettings, and .deploymentoptions is assembled and submitted to the Analysis Services database.

Once the changes have been deployed, the Discover statement issued during the object comparison step is resubmitted. The results of that statement are combined with information from the deployment process to construct a final file, IncrementalShapshot.xml [sic] , which is stored side-by-side with the LastBuilt.xml file. The purpose of this file appears to be to assist the next deployment cycle in determining whether a database has been altered outside of the confines of the current project. (If this is the case, this file is likely employed during the object comparison step.)