[MSTG] Various Caches Available

Various Caches Available in MicroStrategy

 

What is Caching:

Caching is the retention of a recently used elements, objects, or report results for the purpose of improving the query response time in the further requests. Caching enables user to retrieve results from stored files rather that executing queries against a database.

There are four types of caches in MicroStrategy.

1.     Element Caches : Elements of frequently browsed
attributes are stored in the memory on the Intelligent Server and the MicroStrategy
Desktop machine for faster retrievals.

2.     Object Caches : Definition of the frequently
viewed metadata objects are stored on the I-Server and the MicroStrategy
Desktop machines for faster retrieval.

3.     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.

4.     Document Caches : Results of the report services
Document are stored in the memory or disk on the I-Server machine for faster retrieval.

Where do Caches Reside :

The table summarizes them

Caches Types and Location

Cache Type	Client Memory	Server Memory	Server Disk
Element	Yes	Yes
Object	Yes	Yes
Report		Yes	Yes
Document		Yes	Yes

In Two Tier mode, Object and Element caches exist on the Client Machine for
each Project that the Client accesses.

In three tier mode, Object, Element, Report and Document caches exists for each
Project on the I-Server machine and Object and Element Caches exists on the
Client Machines too.

Note :  Caches are Created and stored at the Project Level, Therefore they are not shared across Projects.

Element Caches :

An Element Caches is a recently used attribute element list stored in the memory of MicroStrategy Desktop and I-Server machines.

The example below illustrated is how element caches work.

·         A MicroStrategy Desktop User double-Clicks the
Customer Attribute in the data Explorer in order to display a list of Customers.

·         If no element caches exist n the MS-Desktop or the I
sever memory, the element request is send to the ware house for processing.

·         The list of Customers retrieved from the warehouse is
then stored as an Element Cache in the memory of the  I-Server machine, and the MS-Desktop machine of the user who submitted the request.

·         If the same user requests the same  attribute elements, the element cache
on the local MS-Desktop machine is used to satisfy that request.

·         If a different user requests the attribute elements,
the Element Cache on the I-Server Memory is used to satisfy that request.

Note:  When a user requests elements, Element cache ID’s are matched to the 

element requests in order to determine if a cache can be used to satisfy the request.

Object Caches :

Object Caches is a recently used objects definition stored in the memory of the MS-Desktop and I-Server. We can create object caches for both application and schema objects.

The example below illustrates how object caches work:

·         A user opens the report editor.

·         The collection of attributes, metrics and other user objects are displayed in the report editor that makeup the report definition.
If no object cache for the report exists in the memory of the MS-Desktop or I
Serer machine, the object request is sent to the metadata for processing.

·         The report object definition is retrieved from
metadata and displayed to the user in the report editor.

·         An object cache is created in the memory of the I-Server
and MS-Desktop machines.

·         If the same user requests the same object, the object
cache on the local MS-Desktop machine satisfies the request.

·         If a different user requests the same report the
object cache in the I-Server memory satisfies that request.

Report Caches:

The I-Server provides report caching functionality that
reduce the number of user requests that query the data warehouse. When an user initially runs the report the I-Server caches the result set. Subsequently, when a different user runs the same report again the I-Server can retrieve the result set from the cache rather than having to query the data warehouse again.

The example below illustrates how report caches work.

·         A user runs
a report.

·         The report
runs against the data warehouse.

·         The I-Server
caches the result set and returns the result to the user.

·         A second
user subsequently runs the same report.

·         The I-Server
searches the report Caches.

·         The I-Server
checks the following variables.

 

     I.        Are the
report and any objects it contain unchanged since the cache is created.

   II.        For the
prompted reports did the second user choose the same prompt answers as the first user.

  III.        Based on
the cache property and security settings, is the second user allowed to access the first user’s cache.

 IV.        Is the
cache still active ie. Is it not expired

·         If the answer to any of the variables is no, the cache
is not valid, and the I-Server queries the data warehouse. If the answer to all
the variables is Yes the cache is valid and the I-Server retrieves the result
set from cache.

Document Caching :

Report service document can be cached to improve the system
performance and maintain a low memory footprint of the I-Server.

Document caches are created on the runtime or on schedule and
behave in a similar to the report caches. At runtime the document caches are
created only in MS-Web.

 

For example when you execute a prompted document in MS-Web,
an XML document cache is generated. When you reprompt the document, a new XML cache is generated with the data reflecting the new prompt answers.

You can configure the Document Caching properties at two different levels.

1.     Project Level

2.     Document Level.

[OBIEE 10g] What To Do When OBIEE Fact Tables Do Not Join To All Dimension Tables ?

 

What to do when OBIEE fact tables do not join to all dimension tables?

Here using the Sh Schema to Explain the above Scenario

 

The Step By Step Process:

Import Products,costs,sales,customers Tables From SH Schema….

Physical Diagram Joins between Facts and Dimensions

In The Above We don’t have join between customers and costs….when we try to get the data,

From this in Answers it will be like this

In one way this result is correct, because there is no join between customer and costs…

So the BI server has fired the Database with the following Query 

select distinct D1.c1 as c1,

     D1.c2 as c2,

     cast(NULL as  DOUBLE PRECISION  ) as c3

from

     (select distinct T78.CUST_FIRST_NAME as c1,

               T102.PROD_CATEGORY as c2

          from

               CUSTOMERS T78,

               PRODUCTS T102,

               SALES T125

          where  ( T78.CUST_ID = T125.CUST_ID and T102.PROD_ID = T125.PROD_ID )

     ) D1

order by c1, c2

Though we Have not selected any column from sales the bi server has

Directed to aggregate based on sales….

In order to Fetch the Data using customers and costs we need to set Physically complex join or we can set content level to Total

In physical layer, by making the condition always true…

Physical Diagram Will be Like this

In Bmm Layer Make Sure to Create Hierarchies for the dimensions,Don’t set any Level Based Measures

 Drag and drop in Presentation Layer

Check for global consistency and save it.  Run the Bi Server and Presentation services And check the result..

Now, This works….Here The Important Point to remember is the output that has got is an Cartesian product….Generally Don’t go for this because it will cause some performance issues…..