Query read mode-Cache mode

Question

Hi,
Can u explain me the functionalities of the options:
A-Query to read all data at once
X-Query to read data during navigation
H-Query to read when u navigate or expand hierarchies
I am not clear of the diff. bet. the X,H options....
<b>Cache Mode:</b>
0-Cache is Inactive
1-Main memory cache without swapping
2-Main memory cache without swapping
3-Main memory cache with swapping
4-Persistent cache for each application server
5-Persistent cache across each application server
<b>Optimization Mode:</b>
0-Query will be optimised after generation
1-Query optimization with individual periods in days
9-Query optimization inactive
Can u explain these functionalities in detail...
Max.points will be assigned

Answer 1

HI,
PLease check this..
1.      Query to be read when you navigate or expand hierarchies (H)
The amount of data transferred from the database to the OLAP processor is the smallest in this mode. However, it has the highest number of read processes.
In the following mode Query to read data during navigation, the data for the fully expanded hierarchy is requested for a hierarchy drilldown. In the Query to be read when you navigate or expand hierarchies mode, the data across the hierarchy is aggregated and transferred to the OLAP processor on the hierarchy level that is the lowest in the start list. When expanding a hierarchy node, the children of this node are then read.
You can improve the performance of queries with large presentation hierarchies by creating aggregates on a middle hierarchy level that is greater or the same as the hierarchy start level.
       2.      Query to read data during navigation (X)
The OLAP processor only requests data that is needed for each navigational status of the query in the Business Explorer. The data that is needed is read for each step in the navigation.
In contrast to the Query to be read when you navigate or expand hierarchies mode, presentation hierarchies are always imported completely on a leaf level here.
The OLAP processor can read data from the main memory when the nodes are expanded.
When accessing the database, the best aggregate table is used and, if possible, data is aggregated in the database.
       3.      Query to read all data at once (A)
There is only one read process in this mode. When you execute the query in the Business Explorer, all data in the main memory area of the OLAP processor that is needed for all possible navigational steps of this query is read. During navigation, all new navigational states are aggregated and calculated from the data from the main memory.
The read mode Query to be read when you navigate or expand hierarchies significantly improves performance in almost all cases compared to the other two modes. The reason for this is that only the data the user wants to see is requested in this mode.
Compared to the Query to be read when you navigate or expand hierarchies, the setting Query to read data during navigation only effects performance for queries with presentation hierarchies.
Unlike the other two modes, the setting Query to Read All Data At Once also has an effect on performance for queries with free characteristics. The OLAP processor aggregates on the corresponding query view. For this reason, the aggregation concept, that is, working with pre-aggregated data, is least supported in the Query to read all data at once mode.
We recommend you choose the mode Query to be read when you navigate or expand hierarchies.
Only choose a different read mode in exceptional circumstances. The read mode Query to read all data at once may be of use in the following cases:
      The InfoProvider does not support selection. The OLAP processor reads significantly more data than the query needs anyway.
         1.      Cache is Inactive (0)
The cross-transactional cache is deactivated.
The following modes are possible for the active cache: The cross-transactional cache is activated.
       2.      Main Memory Cache Without Swapping (1)
The cache data is stored in the main memory. When the cache memory has been exhausted, excess data is removed according to the LRU algorithm, i.e. deleted from the memory. When a query is subsequently requested, the result is read from the InfoProvider once again.
       3.      Main Memory Cache with Swapping (2)
The cache data is stored in the main memory. When the caching memory is used up, the excess data is written to a background and can be loaded back into the cache memory when making another request.
After query-relevant data has been loaded again, the background store can no longer be used.
       4.      Persistent Cache per Application Server (3)
The cache data is stored persistently as a database table or as a file in a directory attainable from the application server. We recommend that you choose a directory that is proximate to the application server.
When you save the cache data in a database table this puts a strain on the database. However, it is also then quicker to access uncached data in the database.  In comparison to storing data in, for example, a star schema (see InfoCube), fewer tables are read and fewer indexes are accessed.
       5.      Cross-Application Server Persistent Cache (4)
The cache data is stored persistently as a cross-application server database table or file in a file system in the network, accessed from the application server.  In this mode there is no displacement of data and no restriction on memory size. More space is required but this method also saves time.
¡        Database table: Strain is put on the database instance for the table.
¡        File: Strain is put on the network node operating system for the file.
¡        In addition, the application server that calculates the data and network communication has to be taken into account with both storage types. 
If you do not make any other settings the OLAP processor determines the optimal initial size of the table SP, that is the memory structure in which data is held and processed in the OLAP processor (see Cache Structure). This is done after the first execution and again after a period of 31 days since the last optimization. It automatically generates a report afterwards.  
In the Query Properties dialog box in the Query Monitor you can implement, modify of deactivate this function. Choose one of the following options:
·        Query is optimized after generation (0)
·        Query optimization with individual periods in days (1) Here you can determine the optimization period yourself.
·        Query optimization inactive (9)
Hope this helps..
Bye,
Shashikanth.