Refer to the Admin.pdf for additional information.
https://community.microstrategy.com/t5/Reporting-Dashboards-and/Disable-Report-Level-Caching/td-p/229314 - done reading
https://community.microstrategy.com/t5/Architect/TN16662-Recommendations-for-invalidating-report-caches-in/ta-p/177003 - done reading
https://community.microstrategy.com/t5/Architect/TN43068-The-quot-Do-not-Expire-Cache-quot-option-is-selected-for/ta-p/192903 - done reading
https://community.microstrategy.com/t5/Administration/Purging-Cache-after-ETL-Completes-Web/td-p/10886 - done reading
https://community.microstrategy.com/t5/Server/TN16079-What-is-the-difference-between-invalidating-expiring/ta-p/176446 - done reading
https://community.microstrategy.com/t5/tkb/articleprintpage/tkb-id/architect/article-id/168 - done reading
https://community.microstrategy.com/t5/Administration/Microstrategy-cache-options/td-p/44692 - done reading
https://community.microstrategy.com/t5/Architect/TN199630-Report-Cache-Expiration-Options-are-not-visible-in/ta-p/199630 - done reading
https://community.microstrategy.com/t5/tkb/articleprintpage/tkb-id/server/article-id/273 - done reading
http://microstrategy99.blogspot.com/2012/09/caching.html - done reading
http://community.microstrategy.com/t5/Object-Development/how-to-set-up-cache-retention-period-only-for-a-set-of-reports/td-p/23329 - done reading
http://microstrategytechbuzz.blogspot.com/2013/04/cache-definition-its-usage.html - done reading
https://community.microstrategy.com/t5/Server/TN17931-MicroStrategy-Cache-Administration-Utility-Readme/ta-p/178216 - done reading
http://www.tek-tips.com/viewthread.cfm?qid=473992 - done reading
What is the recommended way to PURGE and the EXPIRE cache using Command Manager command?
Use the EXPIRE command:
EXPIRES ALL REPORT CACHES IN PROJECT "MicroStrategy Tutorial";
EXPIRE ( REPORT CACHES | REPORT CACHE "<cache_name>") IN PROJECT "<project_name>";
The 'EXPIRE' command will not delete the caches that are linked to History List messages, instead all caches will have the expired flag set which will clean up all 'Matching' caches and leave 'History' caches still available.
The command:
PURGE REPORT CACHING IN ALL PROJECTS;
deletes all caches regardless of the cache type. This means that caches linked to History List messages are deleted too. The full syntax for the command is as follows:
PURGE CACHING IN ( PROJECTS | "<project_name>");
As can be seen from the syntax there is no syntax for separating Matching, History, or both types of caches. Instead of using the 'PURGE' command, use the 'EXPIRE' command in MicroStrategy Administrator - Command Manager 8.x, as shown below:
EXPIRES ALL REPORT CACHES IN PROJECT "MicroStrategy Tutorial";
EXPIRE ( REPORT CACHES | REPORT CACHE "<cache_name>") IN PROJECT "<project_name>";
The 'EXPIRE' command will not delete the caches that are linked to History List messages, instead all caches will have the expired flag set which will clean up all 'Matching' caches and leave 'History' caches still available.
What is wrong with just deleting the cache?
Deleting caches is fine if you do not have any history list messages using the caches to store data. An alternative solution is to simply invalidate caches for tables whose data has changed. Caches marked as invalidated and not hodling data for history list messages are automatically deleted by the server, while caches that hold history data cannot be hit by new report executions, but continue to be accessible until the corresponding history list message is deleted.
What are the differences between invalidating, expiring, deleting, and purging a report cache?
Caching allows for improved performance in response to report queries. Although the use of caching is an advantage, there are instances when caches may expire or become invalid. Some of these instances are:
- When there are changes made to the objects in the data warehouse, the existing caches may be configured so that they are no longer valid when hitting certain warehouse tables. Any further report execution will no longer hit the cache.
- When the definition of an application object changes (such as a report definition, report, template, metric definition, etc.), the related report cache is marked as invalid.
- When there is a need to control the growth of caches on the Microstrategy Intelligence Server, old caches may need to be expired automatically.
- Invalidating Report Caches: Invalidation is a preventive measure that renders a cache unusable by nullifying it. Cache invalidation only applies to Matching caches and Matching-History caches. It makes the cache ineligible in the matching process so it is not used to fulfill a report request.
- In the case of a Matching cache, invalidating it will automatically result in deleting it.
- In the case of a Matching-History cache, invalidation simply converts it to a History cache that is not used in the matching process any more but is still accessible through History List messages that reference it. However, if all these messages are deleted, the converted History cache that is referenced is also deleted.
- Expiring Report Caches: Cache expiration is a process that renders a cache unusable by terminating its useful life. It yields the same results as invalidating a cache and applies to Matching caches and Matching-History caches. Cache expiration occurs automatically as per the 'Report cache duration' setting which can be found under Project Configuration > Reports >Advanced > Caching. When a cache is updated, the current cache lifetime is used to determine the cache expiration date based on the last update time of the cache. This means that changing the Report cache duration setting does not affect the expiration date of the already existing caches. It only affects the new caches that are being or will be processed.
- Deleting Report Caches: Cache deletion is a process that deletes the cache from memory as well as disk. Report caches are automatically deleted by MicroStrategy Intelligence Server if cache invalidation and History Lists are performed and maintained properly.
- In the case of a History cache, deleting it does not automatically delete the associated History List messages that reference it. After deleting a History cache, when a message that references it is retrieved, the following occurs:
- MicroStrategy Web users see an error message, "Execution results not available. Would you like to re-execute?"
- MicroStrategy Desktop users do not see the above error message because MicroStrategy Desktop automatically resubmits the report for execution.
- On the other hand, a History cache is automatically deleted when all the History List messages that reference it are deleted (when its History List reference count reaches 0).
- In the case of a Matching-History cache, when all the History List messages that reference it are deleted, it is simply converted to a Matching cache, while losing its History component.
- Caches can be deleted:
- Manually - via Cache Monitor and MicroStrategy Command Manager
- Scheduled - via MicroStrategy Cache Administration Utility
- Scheduled - via MicroStrategy Desktop Scheduled Administrative Task.
- In the case of a History cache, deleting it does not automatically delete the associated History List messages that reference it. After deleting a History cache, when a message that references it is retrieved, the following occurs:
- Purging Report Caches: Cache Purging is a process whereby all report caches can be deleted in bulk, even the one references by History List messages.
- The only difference between invalidating and expiring caches is the mechanism involved. Invalidating a cache typically takes place at a set event (like on data warehouse load) while the expiring a cache is set for a period of time (like 48 hours).
- Once the cache is marked, the status of the cache is checked and all the caches which are invalid/expired are removed from the cache lookup table. This clears old caches and makes space for new ones.
- The difference between purging and deleting caches is that purging automatically eliminates all caches in a project, while deletion can be performed for individual report caches.
Should we disable report caching?
If we do not need report caching, we should disable it. If we send the cache result to the history list, and if we have code that rely on this, disabling report cache may cause it to not be inserted into the history list databse.
How does MicroStrategy recommend that we manage report cache?
- Use an administration task to invalidate caches based on an event. An important feature of invalidating cache through and administrative task is the ability to expire report caches based upon specific warehouse tables involved in the report. That is, a table name or a list of table names are entered and the caches for the reports that touch these tables during execution are invalidated. With this, when specific tables are updated, an invalidation of report caches based on that list of tables can be triggered. This functionality can be achieved by following the steps listed below:
- Launch Developer / Desktop
- Drill down on the right project source
- Click on Administration > Scheduling > Schedule administrative tasks
- Select a MicroStrategy project to have its caches invalidated.
- Select the 'Invalidate Caches' action.
- Pick a schedule on which to run this Cache Invalidation administrative task.
- Click on the Browse button to display the list of tables in the warehouse catalog.
- Select the tables that will dictate which reports' caches will be invalidated.
- Use a Command Manager script to invalidate report caches. Report caches can be invalidated based upon warehouse table names. This script is located at C:\Program Files\MicroStrategy\Administrator\Command Manager\Outlines\Cache_Outlines\Invalidate_Report_Cache_Outline.otl: INVALIDATE ( REPORT CACHES REPORT CACHE "<cache_name>") IN PROJECT "<project_name>";
The schedule that is associated to this administrative task can be an event triggered schedule. Other details on managing report caches are located in the System Administration Guide > Increasing System Efficiency: Caching > Report caches > Managing report caches > Invalidating report caches.
When should we use report caching?
Report-level caching may be helpful when the underlying data does not change frequently. NEED TO ASK MicroStrategy THIS QUESTION.
What are different types of caches?
- Result Cache: A result cache is a cache of an executed report or document that is stored on Intelligence Server. Result caches are either report caches or document caches.
- Element Caches: are the most-recently used lookup table elements that are stored in memory on the Intelligence Server or MicroStrategy Desktop machines so they can be retrieved more quickly.(For prompt answers and browsing etc). When you run an attribute prompt or hierarchy prompt element request is created. An element request is actually a SQL statement that is submitted to the data warehouse. Once the element request is completed, the prompt can be resolved and sent back to the user. Element caching, set by default, allows for this element to be stored in memory so it can be retrieved rapidly for subsequent element requests without triggering new SQL statements against the data warehouse. Elements of frequently browsed attributes are stored in the memory on the Intelligent Server and the MicroStrategy Desktop machine for faster retrievals.
- Object Cache: is a recently used object definition stored in memory on MicroStrategy Desktop and MicroStrategy Intelligence Server. You browse an object definition when you open the editor for that object. You can create object caches for applications. For example, when a user opens the Report Editor for a report, the collection of attributes, metrics, and other user objects displayed in the Report Editor compose the report’s definition. If no object cache for the report exists in memory on MicroStrategy Desktop or MicroStrategy Intelligence Server, the object request is sent to the metadata for processing. Definition of the frequently viewed metadata objects are stored on the I-Server and the MicroStrategy Desktop machines for faster retrieval.
- Report Caches: Results of previously executed reports are stored in the memory or disks on the I-Server machine, so that they can be retrieved quickly, rather than re-executing the request against the ware house database.
- Document Caches: Results of the report services Document are stored in the memory or disk on the I-Server machine for faster retrieval.
- Session Cache - Specific to a user and exists only while the user is logged in. This cache is deleted when the user logs out or if there's no activity for a specified timeout interval. The default value for a timeout is 1200 seconds or 20 minutes.
- Project Cache - Specific to a project that is registered with the MicroStrategy Intelligence Server 9.x. The default value for a timeout is 86400 seconds or 24 hours. The default value for a refresh time is 86400 seconds or 24 hours.
- Server Cache - Specific to a MicroStrategy Intelligence Server 9.x. The default value for a timeout is 86400 seconds or 24 hours. The default value for a refresh time is 86400 seconds or 24 hours.
What are different types of result caches?
- Matching caches: are the results of reports and documents that are retained for later use by the same requests later on
- History caches: are report results saved for future reference in the History List by a specific user.
- Matching-History caches: is a Matching cache that is referenced by at least one History List message.
- XML caches: is a report cache in XML format that is used for personalized drill paths. It is created when a report is executed from MicroStrategy Web, and is available for reuse in Web.
How can I determine if my settings are effective for caching?
I don't know yet. Need to find out.
How can we purge the caches?
Restarting the Web or Application Server will also purge caches. It is also possible to purge caches without restarting the server or waiting for the cache timeout settings to be reached. In MicroStrategy Web GUI Interface, it is possible for a web administrator user to purge caches immediately. Perform the following actions
For web caches, go to http://AppServerName:Port/MicroStrategy/servlet/mstrWebAdmin?pg=purgecaches
How can we disable caching at the individual report level?
- Launch Developer / Desktop
- Locate the desired report
- Right click on the report and select Edit
- Navigate to Data -> Report Caching Options
- Choose the option Disabled: This report should not be cached.
How can we use the command line utility for managing cache?
M8CAHUtl -c:cachecommand -s:servername -p:"project name" -uid:userID -pwd:password -rid:reportID
M8CAHUtl /?
This utility is only for Windows and not available on any of the UNIX platforms. The default location for the executable file for the Cache administration utility is found in the following location: Program Files > Common Files > MicroStrategy > M8CAHUtl.exe
How can we use the Cache Monitor?
- Launch Desktop / Developer
- Drill down on the appropriate project source
- Drill down on Administration
How can we get the 'Report Cache Expiration Option' to be visible?
This is really stupid. What does this option have to do with whether we are using MicroStrategy Scheduler? If you can not see the 'Report Cache Expiration Option' when designing the report, we can cause that option to be visible if we configure the Intelligence server to use MicroStrategy scheduler. See https://community.microstrategy.com/t5/Architect/TN199630-Report-Cache-Expiration-Options-are-not-visible-in/ta-p/199630
How does dynamic date affect report caching?
Dynamic dates in the report definition affect the report's cache expiration time. See https://community.microstrategy.com/t5/tkb/articleprintpage/tkb-id/server/article-id/273
How can we set up different cache retention for different set of reports?
- We can have different command manager scripts, each invalidate cache for a specific set of individual reports, and we can schedule these scripts to run using whatever scheduler that is available to us at the native operating system level.
- We can set up an administration task to invalidate cache using either a time-based or an event-based scheduler within MicroStrategy. Perhaps we can specify the specific individual reports when we set up these administration tasks.
