In this 30-minute video Chris Webb discusses the operational side of cubes: deployment, processing, backup and restore, synchronization, and scripting.

Although you can deploy changes from Visual Studio to your SQL Server Analysis Services database directly by using the Deploy option, this can be dangerous: roles and partitions created outside the project could be overwritten. As a result, it is safer to use the the Deployment Wizard to handle deployments to production—it gives you a lot of control over what gets deployed from your project, and what doesn’t.

Partitioning your measure groups can improve both processing performance and query performance. Creating new partitions in a measure group is a task that is commonly automated. Probably the easiest way to do this is to create an XMLA script that creates a new partition in SQL Server Management Studio and execute this—although you can, of course, build partitions manually in Visual Studio, too. These XMLA scripts can be executed in a number of places, including from within SQL Server Integration Services.

Processing is the act of loading data from a data source, usually a relational data warehouse, into Analysis Services. Dimensions, partitions, measure groups, cubes and entire databases can be processed. A number of different types of processing are available in each case. For dimensions, you have Process Full, Process Update, Process Add, Process Clear and Process Default. For partitions, you have Process Full, Process Add, Process Data, Process Index and Process Default. Using different combinations of these types of processing can reduce your overall processing times.

Other important administrative tasks include backup and restore and synchronization, which allows you to copy data from one Analysis Services data to another. Synchronization is useful in situations where you need to process your database on a different machine to the one that your end users are querying.