I have an SSAS cube in UAT with multiple changes. I need to now deploy these changes to each cube in live (10+ cubes all with the exact same schema). Then process each cube. What is the best way of doing this?
Currently we do this manually by opening up the changed UAT cube in BIDS, changing the Deployment destination (to point to each live cube), and click Deploy.
Can an SSIS package with a for loop calling an AS Processing Task handle this, for example? Are there XMLA (I don't know much about it) scripts that may be able to?
Thanks!
From SQL Server Management you can save the process of a cube as an XMLA script. Then you can either process it by executing the script or even create a job in SSMS. msdn.microsoft SSAS Administrative Tasks
Related
I am using SSIS job to process the ssas DB(cube, dim, partition etc) in source server and XMLA script in the same SSIS package to synchronize the SSAS DB from source server to destination server. This SSIS job is deployed and get initiated daily on source server.
This was running fine since years, but recently SSAS DB Synchronization is getting hang and not stopping/completing even after 3-4 hours. Generally it takes 30 minutes to complete. then I need to kill the job and manually sync the SSAS DB using synchronization wizard at destination server.
any way to figure out the real problem? what events to setup in SQL profiler to catch this issue while ssas db sync? or any other way?Also SQL Profiler should be run against source server or destination server?
Please help/guide/suggest. Thanks
I have an analysis services database which consists of more than 8 cubes. From that, I want one single cube to be moved in to another analysis services database (this database should have only that cube). Instead of doing all the cube work from scratch, is there a easy way to achieve this ?
An easy way to achieve this would be to just copy all files of your BIDS project to a new folder. Then open the new project in BIDS, delete all dimensions and cubes not needed, change the deployment target, and redeploy.
I am new to SSAS, and exploring Partitioning. My data source is very large (web logs):a few hundred million records.
I would like to define my cube IN BIDS, and create a SSIS Package to create partitions. For now, I am Generating The MDX to Create & process the partitions, and Executing them in SSMS.
I find that this is faster and less error prone them manually creating the partitions using the BIDS UI.
I am trying to understand the expected workflow: because every time I go back to BIDS, and make changes to measures & process the cube the partitions I created in SSMS are deleted and the old partitions I created in BIDS are re-published.
What I would like to be able to do is Refresh my partitions from the server to BIDS. Is This possible? If not, what type of workflow is expected in this case?
Thanks!
Partitions are part of the cube structure, and if you change these outside of BIDS, then you change the structure of the deployed Analysis Services database. BIDS keeps the definition of the structure locally as a set of XML files, the partition definitions are contained in a file with the extension .partitions. If you deploy an Analysis Services project from BIDS, it updates the deployed Analysis Services database to match the structure of the local XML files, thus overwriting whatever you changed outside of BIDS.
You can get a deployed database back to an Analysis Services project as follows: Open BIDS, click File/New/Project, and then select "Import Analysis Services Database" from the "Business Intelligence Projects" project type, and select the directory where you want to save the project files locally in the bottom part of the dialog. As soon as you click OK, a wizard opens that allows you to select the server and Analysis Services database to get the definition from, and when you click Next, starts writing it to the directory that you selected.
Partitions are a part of your cube structure. You should create the partitions in BIDS and then process them based on your requirement using SSIS or SSMS.
I was recently tasked with partitioning a large cube and I ended up creating 15 partitions on several measure groups. It's sped up the processing time considerably. This was done in BIDS on a development copy of the cube. My question is on deploying to the production cube. Some other changes have occurred in production while I was working on this and I don't want to overwrite them so I can't just deploy the development project to production. Is there a way for me to script just the partitioning I performed on the development cube and apply that script to the production cube?
Thanks in advance
You can implement SSIS package to automate this task. A simple example could be found here http://www.ssas-info.com/analysis-services-scripts/1622-script-to-automate-ssas-partition-management-sql-ssis
You can automate the creation of partitions in your production cube using SQL Server Agent and the SSAS Partition Manager which can be downloaded from https://ssaspartitionmanager.codeplex.com/
With just a few lines of config, you can dynamically create cube and tabular partitions on your production server.
Is any thing wrong if i create alter script on the entire database in analysis service in the development server SSMS and execute that script on the production server SSMS instead of deploying through BIDS?
no, you actually should never use BIDS to deploy to prod. BIDS will always overwrites the management settings(security and partition) of the target server.
the best option is to use the Deployment Wizard. It enables you to generate an incremental deployment script that updates the cube and dimension structures. Can customize how roles and partitions are handled. It uses as input files the XML output files generated by building the SSAS in BIDS and you can run on several modes:
Silent Mode (/s): Runs the utility in silent mode and not display any dialog boxes.
Answer file mode (/a): Do not deploy. Only modify the input files.
Output mode (/o): No user interface is displayed. Generate the XMLA script that would be sent to the deployment targets. Deployment will not occur.
If you want a complete synchronization, you can use the "Synchronize Database Wizard". It pretty much clones a database. When the destination database already exists, it performs metadata synchronization and incremental data synchronization. When the destination database does not exist, a full deployment and data synchronization is done.
I think the main disadvantage of scripting the whole database is that everything may be reprocessed. Also, if another team or team member is responsible for deploying the script it may be a lot harder to review and understand if everything is rebuilt with each update.
I work for Red Gate and we recently introduced a free tool called SSAS Compare to help manage this scenario. It helps you to create a script containing just the changes you want to deploy