March 9, 2017 at 8:49 am
Five large Tabular cubes exist, there are additions needing to be made to each. Question, what’s a better industry standard practice to implement?
Bring up new cube next to existing with all new changes?
Or take down the old one and place the new one in its place and allow old packages to hook into new cube (backups, restore, rename etc into place (can’t really test the packages to the newly restores/renames cube)?
The latter creates cube down time, and risk with existing packages. The first one means new views and packages will need to be brought in, and the existing can go cold while the users switch over connections in Excel and Power BI to the new cube.
I favor bringing up a new cube with additions next to the old existing one and phase out. My systems is a single box, where prod is also dev.
Thanks, JPQ
March 10, 2017 at 4:09 am
quinn.jay - Thursday, March 9, 2017 8:49 AMFive large Tabular cubes exist, there are additions needing to be made to each. Question, what’s a better industry standard practice to implement?
Bring up new cube next to existing with all new changes?
Or take down the old one and place the new one in its place and allow old packages to hook into new cube (backups, restore, rename etc into place (can’t really test the packages to the newly restores/renames cube)?
The latter creates cube down time, and risk with existing packages. The first one means new views and packages will need to be brought in, and the existing can go cold while the users switch over connections in Excel and Power BI to the new cube.
I favor bringing up a new cube with additions next to the old existing one and phase out. My systems is a single box, where prod is also dev.
Thanks, JPQ
Industry standard would be to develop the changes and then deploy them to a test box (or instance). Once testing is passed then come up with a deployment plan for production. Every circumstance is different but generally the pattern would be:
1. Plan for both the deployment and a rollback in the case of failure, including picking a sensible window for deployment.
2. Take backups of affected objects (cubes, databases , packages etc.)
3. Deploy the changes - this can range from fairly big deployment scripts to repointing and deploying a solution from Visual Studio.
4. Functional test
5. Communication
I guess a shorter answer would be choose the option that is less impactful to the users. I don't quite understand how one of your solutions can involve changes to packages and the other just "risks". Surely if there is a change being made then it would happen in both scenarios?
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply