MicroStrategy Types of Caches
Joaquin Attanasio

Joaquin Attanasio

Business Intelligence Consultant | Microstrategy Expert | Data Specialist

Other Articles:

MicroStrategy Types of Caches

Share on linkedin
Share on facebook
Share on twitter
Share on whatsapp

Good morning everyone! Another week in our favourite space, the corner of the curious and discoverers known as #BestInMicro.

Types of Caches

Today, we will continue to delve a little deeper into optimisation techniques and take a look at the different types of caches available in MicroStrategy.

As you may have noticed, in the previous article we talked about the report cache specifically, but there are other types of cache that play a part in the optimisation of the tool. Let’s analyse them.

9 Types of Caches in MicroStrategy

Let’s start with the basic and familiar ones, which can be managed from the MicroStrategy menu:

Report Caching

Report Caches: There is not much to add to this explanation, they are the results that are calculated and processed for the first time and then presented with the previously obtained result. They can be stored in the memory of the Intelligence Server or on disk (as a file). As we discussed in the difference between history list and report caching, history is also a way of “caching” the report results per user.

Element Caches: For those who have not yet registered, the elements are the objects represented by the red cube. The item cache is a cache that is stored in the memory of the Intelligence server. This stores the values of the lookup tables of the attributes, and allows to optimise the navigation, mainly when we want to select the values for some filter or when navigating through the hierarchy.

Types of Caches Element

This type of caches must always be taken into account, I have lost count of the number of times users have complained because they could not see a value in a filter and it was because I had updated the values in the database and they were still cached in MicroStrategy.

Object Caches: This cache is similar to the previous one, except that, instead of storing values, we are storing objects. Obviously with this definition I am not explaining the plutonium formula, but there is not much more to explain. As in the previous example these were caches that were affected by updating information, this type of cache can be useful to clear when doing some package import with the object manager, or some schema-level modification that may affect objects indirectly, such as a parent-child relationship.

Now I bring you some that not everyone knows about. Let’s move on topage caches. When a user views a published dossier, the Intelligence Server generates one cache object per page, so that the cache can be reused when the user switches from one page to another. This is one of the new features that have been added in recent versions.

Something similar can be found when we talk about Cachés en Mobile. When defining the home screen of the application configuration, we can select different documents and pages that will be pre-loaded when the application is run. It is possible to define a list in order to be loaded at the start of the app to optimise the user experience.

Types of Caches Object

Continuing with the list, and I don’t want to be repetitive, if it all seems the same (and it’s not that the speech is cached… heh, I know, very bad joke) we move on to talk about the Result caches.

These are results that are stored in memory on information sets. A great example of such caches are intelligent Cubes. Those who have played a little with import data will have seen that these generate cubes, escaping a little from the historical concept of cubes that those of us who are more experienced with the tool have. It is this type of stored information that corresponds to this type of caches.

Then, there are the Server Caches, which can be differentiated or divided into two types:

The configuration that controls the server-side object cache for schema and application objects. A capacity is assigned to it. Very similar to those mentioned above, but instead of objects belonging to users, it refers to objects more related to the internal use of the Intelligence server.

.The configuration governing the server-side object cache for configuration objects (users, groups, schedules, etc). This is a server level configuration that applies to configuration objects. By default, 2048 server objects are kept in cache.

Finally, there are the XML caches. These work in the same way as the report caches, and are in fact associated with them, but they are generated when the execution is done from the web server. This type of cache, although redundant, is generated in XML format, thus streamlining not only the output, but also the presentation of the information on the web. 

Otherwise, e.g. when a report is only sent to history, no XML cache is generated. This is because the Intelligence Server does not have to generate the XML because the results were never sent to the web server, i.e. they were not displayed… do you understand the difference? 

If it is still not clear, the KB8934 was useful to me to finalise the idea.  

Cache management

The settings for all cache types, except page caches and the history list, are specified in “Storage in cache” in the project configuration editor.

Page cache settings are configured through the Application properties > cache files Managementin MicroStrategy Workstation.

The history list configuration is specified in the Intelligence Server Configuration Editor.

Server caches are managed in Project Configuration > Caching > Auxiliary Caches > Objects > Maximum RAM Usage (MBytes)

Types of Caches Auxiliary

Finally, result, item and object caches are created and stored for individual projects, not shared between projects. Note that to make changes to the cache configuration, you must have the “Manage Caches” privilege. In addition, changes to the cache configuration do not take effect until you stop and restart the Intelligence Server.


And? Did you know them all? Do you use them? Thinking that optimising the tool and minimising waiting times is a key factor for users, and here we have 9 different points where you can make a difference. But be careful! Remember that caching information is like taking a snapshot at a specific time, and the consequences of displaying outdated information can be far worse than waiting a few seconds longer to execute, so, as a mother would say: whatever you do, do it judiciously!

I look forward to seeing you next time, I hope you find it useful, and don’t hesitate to ask questions or ask for more info on the topics you are interested in!


Deja un comentario

Your email address will not be published. Required fields are marked *

Business Data Master Logo

No te pierdas el


Explicaremos en detalle los contenidos y objetivos del Business Data Master


18:30 (GTM+1)



* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.