Good morning everyone, and once again welcome to the #BestInMicro Curious Club! This little place where I share adventures, stories, experiences, and learnings in the world of consulting with MicroStrategy.
This week I bring an article that is always good to have on hand. Let’s be honest, who has never accidentally deleted or overwritten an object? How many Christs remembered and curses to heaven when having to remake an object again for not making an emergency copy? Haha relax, we’ve all been there at some point, and on the way to not repeat it, today I’ll tell you a little bit about the backup and restore methodology. Join me!
If there’s one thing that I’ve felt missing throughout my life as a developer while making different documents with MicroStrategy, it was some versioning system, and I don’t mean the registration of an object’s activities Many of you will have only recently started with the tool, and since I did, it has improved a lot. I even remember when the web version of 9.3 was announced that when saving a document, it had included the option to “re-run the original document or return to the one you were working on” after a “save as” as if to help generate some kind of versioning as the development evolved.
With this, one could make modifications from time to time, or save a version of the development…
Anyway, let’s get back to what we came for. Let’s say that, in the hustle and bustle of our working day, we inadvertently deleted or modified an object and hit save, it is time to analyze alternatives to avoid having to start over again.
Copies and old versions
This is the old and classic one. It is a very good practice to save versions of what is being developing, although in the long term if it is not well maintained it can generate a very large ball of garbage (especially if we are talking about schema objects, which can cause problems in some cases). That said, let’s go into the details of this form: It is not the same thing to do a copy-paste and overwrite the object that exists, and here we must be careful. All objects have a unique ID within each project.
If we make a copy of objectAand overwrite object B, the id will not be the same. This has a huge impact since objects are linked to each other through theID (a document with its report, a report with its filter, a filter with its attribute, etc., etc.). When you want to take an object and replace it with another one without affecting the entire environment around it, you need to edit your object B, click on “save as” and then overwrite object A.. In this way, it will maintain the ID original and the restored object will not affect the other objects on which it depends.
Object manager
This is the next level. In a moderately mature environment, there are different environments: a development environment and a (minimally) production environment. As development is being approved for deployment, it is good practice to create packages and store them in some directory as a “restore point”. I say it is good practice because it can be done directly, without the creation of the package, but generally using packages not only serves as a restore point but is even easier to manage.
Metadata backup
And this is the last hope for many in a critical state of despair and crying: a Metadata backup. Well, maybe I’m giving it much bigger importance than it really implies, but I needed to give a dramatic touch to the matter 😊.
Whether the metadata is stored in the cloud or on-premise, most commonly some form of backup storage is maintained, usually daily, although it can also be on a weekly or monthly basis.
The way to restore objects from a backup is similar to the previous one: using object manager. Let’s do a quick review of the MicroStrategy architecture: Without going into complexities, we can say that there can be 2 to 4 layer connections in Microstrategy:
1- Metadata. This is where the information and structure of MicroStrategy are found.
2- The terminal from which we will connect (Developer, Workstation, app mobile, browser, etc).
3- Intelligence Server. This layer allows us to use the OLAP functionalities of MicroStrategy, in addition to the tools and facilities offered by the platform.
4- Mobile/Web Server. This layer allows us to access through the network…
When we talk about a two-layer connection, it means generating a “direct” connection to the metadata. That is, from our terminal (Workstation or Developer) to the metadata database, without going through the Intelligence server, connecting with the database credentials.
What we must do is to restore the backup in a database schema, and create a direct connection to this restored schema. This will create a new project source, connecting to the backup. Then, simply create a package with what you want to restore and import it into your current environment.
Anyway, there are different ways to recover or roll back an error, but they are not foolproof techniques, and especially depend on there being some kind of restore point. Another issue to keep in mind is that we are talking about MicroStrategy objects here. In the case of application objects, the impact is more likely to be minor, but if we modify objects such as tables, or even tables in the database, then this is a more sensitive issue and perhaps more complex to solve… anyway, I hope this note has gotten you out of trouble or at least helped you to become aware of some good practices.
Let me know if you have any other tips to add! Without further ado, I look forward to seeing you in the next edition! Greetings!
* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.
