Skip to main content

MSTR VLDB SQL optimization tips

https://www2.microstrategy.com/producthelp/10.6/SupplementalAdmin/WebHelp/Lang_1033/Content/AdminSupplemental/Optimizing_queries.htm

https://www2.microstrategy.com/producthelp/10.6/SupplementalAdmin/WebHelp/Lang_1033/Content/AdminSupplemental

https://www2.microstrategy.com/producthelp/10.6/SupplementalAdmin/WebHelp/Lang_1033/Content
/attr_selection_form_selection_option_interm_passes.htm

SQL Generation and Data Processing: VLDB Properties » Details for all VLDB properties » Selecting and inserting data with SQL: Select/Insert » Attribute Selection and Form Selection Option for Intermediate Passes
Attribute Selection and Form Selection Option for Intermediate Passes

Normally, the MicroStrategy SQL Engine selects the minimum number of columns that are needed in each pass. For an intermediate pass, the SQL Engine usually only selects attribute ID forms. The SQL Engine also selects the attributes necessary to make the join, usually key attributes. Then in the final pass, additional attributes or attribute forms that are necessary for report display can be joined.

This algorithm is optimal in most cases, as it minimizes the size of intermediate tables. However, in certain schemas, especially denormalized ones, and schemas that use fact tables as both lookup tables and relationship tables, such an algorithm may cause additional joins in the final pass.

Example

A report template contains the attributes Region and Store, and metrics M1 and M2. M1 uses the fact table FT1, which contains Store_ID, Store_Desc, Region_ID, Region_Desc, and f1. M2 uses the fact table FT2, which contains Store_ID, Store_Desc, Region_ID, Region_Desc, and F2. With the normal SQL Engine algorithm, the intermediate pass that calculates M1 selects Store_ID and F1, the intermediate pass that calculates M2 selects Store_ID and F2. Then the final pass joins these two intermediate tables together. But that is not enough. Since Region is on the template, it should join upward to the region level and find the Region_Desc form. This can be done by joining either FT1 or FT2 in the final pass. So with the original algorithm, either FT1 or FT2 is being accessed twice. If these tables are big, and they usually are, the performance can be very slow. On the other hand, if Store_ID, Store_Desc, Region_ID, and Region_Desc are picked up in the intermediate passes, there is no need to join FT1 or FT2 does not need to be joined in the final pass, thus boosting performance.

For this reason, the following two properties are available in MicroStrategy:

• Attribute Form Selection Option for Intermediate Pass
• Attribute Selection Option for Intermediate Pass
• These properties intend to use bigger (wider) intermediate tables to save additional joins in the final pass and exchange space for time.
• These two properties work independently. One does not influence the other.
• Each property has two values. The default behavior is the original algorithm.
• When the property is enabled:
— The SQL Engine selects additional attributes or attribute forms in the intermediate pass, when they are directly available.
— The SQL Engine does not join additional tables to select more attributes or forms. So for intermediate passes, the number of tables to be joined is the same as when the property is disabled.

Comments

Post a Comment

Popular posts from this blog

Slowly Changing Dimension Types 0, 4, 5, 6 and 7

Slowly Changing Dimension Types 0, 4, 5, 6 and 7 Ralph introduced the concept of slowly changing dimension (SCD) attributes in 1996. Dimensional modelers, in conjunction with the business’s data governance representatives, must specify the data warehouse’s response to operational attribute value changes.  Core SCD approaches:  Type 1 (overwrite),  Type 2 (add a row), and  Type 3 (add a column).  Since legibility is a key component of the Kimball mantra, we sometimes wish Ralph had given these techniques more descriptive names, such as “overwrite” instead of “type 1.” But at this point, the SCD type numbers are part of our industry’s vernacular. We have written about more advanced SCD patterns, such as the 2005 article entitled “ Slowly Changing Dimensions are Not Always as Easy as 1, 2, 3. ” However, we’ve not consistently named the more advanced and hybrid techniques. With the third edition of  The Data Warehouse Toolkit  (Wiley, 201...

MicroStrategy URL API Parameters

MicroStrategy URL Structure The following table summarizes the root URL structure used for every request to MicroStrategy Web. Environment Main Application URL Administration URL J2EE http://webserver/MicroStrategy/servlet/mstrWeb http://webserver/MicroStrategy/servlet/mstrWebAdmin .NET http://webserver/MicroStrategy/asp/Main.aspx http://webserver/MicroStrategy/asp/Admin.aspx Every request sent to MicroStrategy Web calls a central controller. Parameters are appended to  Main.aspx  or  mstrWeb  (in a .NET and J2EE environment, respectively) to indicate to the controller how the request should be internally forwarded and handled. The following examples show a URL for accessing a MicroStrategy folder when the user does not have an existing session. The URL contains not only the parameters needed to connect to MicroStrategy Web, but also the parameters needed to log on and create a session. J2EE environment: <a href="http:...

Internationalization Design Technics

Microstrategy Internationalization Design Technics MicroStrategy supports data internationalization through two different techniques. You can either provide translated data through the use of extra tables and columns, or you can provide separate databases to store your translated data. These techniques are described below: You can support data internationalization in your database by using separate tables and columns to store your translated data. You can use various combinations of tables and columns to support and identify the translated data in your database. To support displaying the name of each month in multiple languages, you can include the translated names in a separate column, one for each required language, within the same table. Each column can use a suffix to identify that the column contains translated data for a certain language. The same LU_MONTH_OF_YEAR table with translated data for the Spanish and German langua...

Case functions Microstrategy

Ca se functions Microstrategy Case functions return specified data in a SQL query based on the evaluation of user-defined conditions. In general, a user specifies a list of conditions and corresponding return values. Case This function evaluates multiple expressions until a condition is determined to be true, then returns a corresponding value. If all conditions are false, a default value is returned.  Case  can be used for categorizing data based on multiple conditions. This is a single-value function. Syntax Case ( Condition1 ,  ReturnValue1 ,  Condition2 , ReturnValue2 ,...,  DefaultValue ) Example Case(([Total Revenue] < 300000), 0, ([Total Revenue] < 600000), 1, 2) sum(Case (Day@DESC in (“Sat”,”Sun”), Sales, 0) {~+} Sum(Case(Category@DESC In("Books","Electronics"),Revenue,0)){~+} CaseV (case vector) CaseV  evaluates a single metric and returns different values according to the results. It can be used to perfo...

Uniquely identifying data using Compound Key in Microstrategy

Uniquely identifying data in tables with Compound Key attribute: The types of keys that can be assigned to a table include: • Simple key requires only one column to identify a record uniquely within a table. • Compound key requires multiple columns to identify a unique record. . The following diagram shows how the different key structures can be used to identify a cal...

Custom Subtotal Displays in MicroStrategy

Defining custom subtotal displays in MicroStrategy By default, when users apply subtotals in a report, the name of the subtotal is displayed in the subtotal line items that appear in the report. Users can use custom subtotals to give more control over the characteristics of a subtotal. Custom subtotals allow users to define custom subtotal line items that appear on the reports  U sers can make the subtotal name dynamic by typing special characters in the subtotal name field as listed in the following table. Character Description #A The name of the attribute under which the subtotal appears. #P The name of the attribute to the left of, or above the attribute under which the subtotal appears. #0 All the forms of the parent element. #1 The first form of the parent element reading from left to right or from top to bottom. #2 The second form of the parent element reading from left to right or from top to bottom. #3 The third form of th...

Configure Connection Mapping in Microstrategy

Configure Connection Mapping in Microstrategy The following steps demonstrate the second scenario where two different data warehouses are used within the same project: Create two different database connections -                                                                                        One that points to the data warehouse for the European users                                                                 and the other that points to the data warehouse for USA users as shown below: Select Europe as the default database connection for the database Instance as seen below: Go to P...
Star schemas and aggregate (or summary) fact tables Aggregate tables can further improve query performance by reducing the number of rows over which higher-level metrics must be aggregated.  However, the use of aggregate tables with dimension tables is not a valid physical modeling strategy. Whenever aggregation is performed over fact data, it is a general requirement that tables joined to the fact table must be at the same attribute level or at a higher level. If the auxiliary table is at a lower level, fact rows will be replicated prior to aggregation and this will result in inflated metric values (also known as "multiple counting"). With the above Time dimension table, a fact table at the level of Day functions correctly because there is exactly one row in DIM_TIME for each day. To aggregate the facts to the level of Quarter, it is valid to join the fact table to the dimension table and group by the quarter ID from the dimension table. Sql select DT...

OLAP features in Microstrategy

OLAP features in Microstrategy MSTR  OLAP Services uses Intelligent Cube Technology—an in-memory version of report data that can 1 About MicroStrategy OLAP Services  can be manipulated by the MicroStrategy Analytical Engine. MicroStrategy Desktop, Web, and Office users can slice and dice data in reports within Intelligent Cubes without having to re-execute SQL against the data warehouse.  Many of the standard OLAP features that MicroStrategy provides out of the box, such as: Page-by Pivoting Sorting Subtotals Banding Aliasing Outline mode Thresholds etc.. With an OLAP Services license, user can perform additional OLAP analysis, using the following features:  Displaying data on the fly: dynamic aggregation, page  Creating metrics on-the-fly: derived metrics, Defining attribute elements on-the-fly: derived elements,  Filtering data on the fly: view filters and metric filters,  Importing data as an Intelligent Cube

Data Mart Reports in Microstrategy

Creating Data Mart Reports in Microstrategy   When there is requirement to store all the report results to a database table you can use the interesting feature in Microstratgey called Data Mart Reports. To create a data mart table, you first create a data mart report that defines the columns of the data mart table. You then create the data mart table and populate it with data. The steps below walk you through the process of creating a data mart report and then executing the report to create a data mart table. The steps also include an example for most steps, based on Tutorial sample data in the MicroStrategy Tutorial project.                Follow the simple steps below to create a datamart report: 1 In MicroStrategy Developer, create a new report or select an existing report to use as the data mart table. The report should contain the attributes...