Integrating MicroStrategy Analytics Platform with Microsoft SQL Server

MicroStrategy, Inc. Integrating MicroStrategy Analytics Platform with Microsoft SQL Server This document explains how MicroStrategy integrates with Microsoft SQL Server and lists best practices MicroStrategy Incorporated, 2014 Page 1 of 49

Contents Introduction... 4 About MicroStrategy... 4 About Microsoft SQL Server... 4 Overview of MicroStrategy Architecture... 5 MicroStrategy Technology Philosophy: Leverage the Power of the RDBMS... 5 Model-based Dynamic SQL Generation... 5 Schema Abstraction... 5 Aggregate Awareness... 5 Multi-pass SQL... 6 Optimal Query Generation... 6 Intermediate Tables... 6 Table Creation Type... 10 Index Creation on Intermediate Tables... 11 Sub Query Type... 11 SQL Global Optimization... 13 Set Operator Optimization... 14 Parallel SQL Execution... 14 Database Write-Back... 15 Integration with SQL Server Linked Servers... 16 Querying XML Data in SQL Server... 16 Integration with Indexed Views... 32 Integration with Table-Valued User-Defined functions... 33 Integration with In-Memory OLTP... 36 Integration with Clustered Columnstore Indexes... 37 Additional VLDB Settings... 38 Extended Analytics Using SQL Server Functions... 40 Analytic Functions: Functions for OLAP... 40 Custom Group Banding via the CASE statement... 43 MicroStrategy Certification of SQL Server Status... 43 SQL Server 2014... 43 SQL Server 2012... 44 MicroStrategy Incorporated, 2014 Page 2 of 49

SQL Server 2008 R2... 44 SQL Server 2008... 44 SQL Server 2005... 44 Appendix... 45 Default VLDB Settings for SQL Server for Linux, UNIX and Windows... 45 Data type Mapping... 45 SQL Server Database Functions Used by MicroStrategy... 46 MicroStrategy Incorporated, 2014 Page 3 of 49

Introduction This paper provides a brief overview of the MicroStrategy architecture and explains how this architecture takes advantage of the features and functionality of the Microsoft s SQL Server database. MicroStrategy offers an unsurpassed range of analytical functionality, which is further optimized when integrated with Microsoft s SQL Server broad list of database features that improve data warehousing performance. The intent of this document is to provide clarification on how the two products work together and the necessary steps to ensure they are optimized. This document focuses mostly on configuration rather than installation steps. The goal is to highlight concepts that refer to detailed how-to steps in the relevant parts of the respective product documentation. About MicroStrategy Founded in 1989, MicroStrategy (NASDAQ: MSTR) is a leading worldwide provider of enterprise software platforms. The Company's mission is to provide the most flexible, powerful, scalable and user-friendly platforms for analytics, mobile, identity and loyalty, offered either on premises or in the cloud. The MicroStrategy Analytics Platform enables leading organizations to analyze vast amounts of data and distribute actionable business insight throughout the enterprise. Our analytics platform delivers reports and dashboards, and enables users to conduct ad hoc analysis and share their insights anywhere, anytime. The MicroStrategy Mobile App Platform lets organizations rapidly build information-rich applications that combine multimedia, transactions, analytics, and custom workflows. To learn more about MicroStrategy, visit www.microstrategy.com and follow us on Facebook (http://www.facebook.com/microstrategy) and Twitter (http://www.twitter.com/microstrategy). About Microsoft SQL Server Microsoft SQL Server (hereafter referred to as SQL Server) Database is an object relational database management system produced and marketed by Microsoft Corporation, it provides a comprehensive feature set to easily manage the most demanding transaction processing, business intelligence, and content management applications. The SQL Server database is packaged in various editions. http://www.microsoft.com/en-us/server-cloud/products/sql-server-editions Please refer to this link to verify which SQL Server features are supported by edition. http://msdn.microsoft.com/en-us/library/cc645993.aspx MicroStrategy Incorporated, 2014 Page 4 of 49

Overview of MicroStrategy Architecture MicroStrategy Technology Philosophy: Leverage the Power of the RDBMS The MicroStrategy architecture has its roots in the principles of Relational OLAP (ROLAP). A ROLAP architecture provides OLAP functionality to the end user (e.g. multidimensional framework, slice-anddice interaction, drilling, etc.), but uses a relational database to resolve queries and perform calculations, rather than using a specialized proprietary multidimensional database. While the virtues of ROLAP are fully extolled elsewhere, this is an important distinction for this article for two reasons. First, MicroStrategy applications have been able to achieve industry-leading data scale because of the reliance on the processing power and data management capabilities of the underlying RDBMS. The system design principle of partnering with the RDBMS, through features discussed in this document, is the cornerstone of achieving such scalability. Second, this focus on integration with the RDBMS allows a business intelligence system to tap into a powerful dynamic over time: technical advances in RDBMS technology are seamlessly accessible to a MicroStrategy-based BI system. The net benefit to the customer is a BI system that increases in value when either MicroStrategy or the RDBMS adds features to their products. Model-based Dynamic SQL Generation When a user runs a MicroStrategy report or dashboard, MicroStrategy will push down the analytics to the RBDMS in the form of optimized SQL queries and visualize the data of the result sets according to the report and dashboard specifications. Hence, to the RDBMS, a MicroStrategy application is an SQLbased application, in many ways like any other SQL application accessing the SQL Server Database. Schema Abstraction The SQL Engine component of MicroStrategy will generate the queries dynamically at runtime. The SQL Engine performs its work based on a metadata model defined to the system. Note, that the MicroStrategy metadata is not used to store joins or schema-type information, such as star or snowflake. Instead, the metadata model stores content information for each table indicating that it contains a set of particular facts and a set of particular attributes. When a report request is submitted, the Engine breaks the report down into the individual components (i.e. attributes and facts), then begins searching the model to determine which combination of tables will be necessary and efficient in resolving the request. Schema abstraction of the database columns (into MicroStrategy attributes and facts) provides the flexibility necessary to allow applications to be created quickly without having to change the structure of the data model. MicroStrategy is able to support virtually any type of star, snowflake, or hybrid physical design, including transactional schemas. The business model defined in MicroStrategy is easily able to span multiple stars/snowflakes in a single application and even a single query. MicroStrategy supports dimensional models well, but does not require a dimensional model. Aggregate Awareness Query performance in many data warehouses is enhanced through the use of aggregate tables. Aggregate tables, also called summary tables, store pre-computed results of data allowing users to MicroStrategy Incorporated, 2014 Page 5 of 49

query from a summarized set of data rather than the detail level data that would be stored in the fact table. In many cases, use of aggregate tables will improve query performance by orders of magnitude. MicroStrategy s SQL Engine is aggregate-aware and determines the use of aggregate tables transparently at query time. MicroStrategy provides transparent navigation of aggregate tables, directing queries to summary tables when they exist without user involvement. Multi-pass SQL One of the key elements to providing analytical sophistication in analytical applications is MicroStrategy s ability to generate multi-pass SQL. Multi-pass SQL is required to answer analytical questions that cannot be answered with a single SQL query block. Examples of questions/scenarios that require multi-pass SQL include: Set qualification: Show me sales by region over the last six months, but only for customers who purchased one of the 5 most popular products. Split metrics: query returns sales data from a sales star schema and inventory data from an inventory star schema Metrics calculated at different levels of aggregation Metrics calculated with different filtering criteria Simulating outer joins on RDBMS platforms that do not support them natively Querying multiple tables due to application-level partitioning Support for these scenarios, especially when combined together, provide a framework for significant analytic questions and value to the users of the system. One of the main optimizations the MicroStrategy SQL Engine makes is to generate SQL that performs these multi-pass queries as efficiently as possible. Optimal Query Generation MicroStrategy differentiates two kinds of tables accessed as part of its analytical workload. The first consists of a set of base tables. These generally contain the fact and attribute data as required to implement the desired logical data model for the analytical application. These tables are created, populated, and maintained outside of MicroStrategy. The second is a set of intermediate tables that are required to implement multi-pass SQL. They are temporary in nature and hold intermediate results. They are created, populated and dropped by MicroStrategy. MicroStrategy implements a list of strategies to generate intermediate tables the choice of which can have a significant impact on query performance. MicroStrategy s SQL Engine is capable of generating different SQL syntax in order to provide optimal support for any given RBDMS. The following sections discuss the default choices for SQL Server and potential alternatives. Intermediate Tables By default any RBDMS contains a lot of functionality that ensure ACID compliance when creating tables. In the context of creating temporary result sets for an analytical query, a lot of this functionality can be MicroStrategy Incorporated, 2014 Page 6 of 49

considered overhead as the goal is primarily a read-only operation against base tables. The SQL Server database implements a range of features that help reduce the overhead involved when processing intermediate results for multi-pass queries. Temporary table One way to implement multi-pass SQL is to execute each pass in a separate table. SQL Server global temporary tables are a good choice because there is low overhead cost for creating and inserting into them. Global temporary tables, indicated with the ## prefix, are created in the tempdb and last for only one session: they are dropped implicitly when the application disconnects from the database or dropped explicitly using the DROP TABLE command. MicroStrategy, by default, uses global temporary tables when generating intermediate tables in SQL Server. VLDB Category VLDB Property Setting Value Tables Intermediate Table Type True temporary table Tables Table Creation Type Implicit Table In the example below, notice how each SQL pass is specified as a SELECT INTO statement that populates a global temporary table. select a13.year_id YEAR_ID, a12.subcat_id SUBCAT_ID, sum(a11.tot_unit_sales) WJXBFS1 into ##ZZSP00 from ITEM_MNTH_SLS a11 join LU_ITEM a12 on (a11.item_id = a12.item_id) join LU_MONTH a13 on (a11.month_id = a13.month_id) group by a13.year_id, a12.subcat_id select a13.year_id YEAR_ID, a12.subcat_id SUBCAT_ID, sum(a11.units_received) WJXBFS1 into ##ZZSP01 from INVENTORY_ORDERS a11 join LU_ITEM a12 on (a11.item_id = a12.item_id) join LU_MONTH a13 on (a11.month_id = a13.month_id) group by a13.year_id, a12.subcat_id select pa11.year_id YEAR_ID, pa11.subcat_id SUBCAT_ID, a13.subcat_desc SUBCAT_DESC, pa11.wjxbfs1 WJXBFS1, pa12.wjxbfs1 WJXBFS2 from ##ZZSP00 pa11 join ##ZZSP01 pa12 on (pa11.subcat_id = pa12.subcat_id and pa11.year_id = pa12.year_id) MicroStrategy Incorporated, 2014 Page 7 of 49

join LU_SUBCATEG a13 on (pa11.subcat_id = a13.subcat_id) drop table ##ZZSP00 drop table ##ZZSP01 Derived Tables Derived table syntax is another option for intermediate table type with SQL Server. Rather than implement each SQL pass in a separate table, the derived table syntax allows the SQL Engine to issue additional passes as query blocks in the FROM clause. Instead of issuing multiple SQL passes that create intermediate tables, the SQL engine generates a single large pass of SQL. This can allow queries to run faster since there are no CREATE TABLE or DROP TABLE statements to catalog, no corresponding locks on the system tables, and no logging of records inserted into a physical table. Customers may want to experiment with this option to determine if it is beneficial in their specific environment. VLDB Category VLDB Property Setting Value Tables Intermediate Table Type Derived table select pa11.year_id YEAR_ID, pa11.subcat_id SUBCAT_ID, a13.subcat_desc SUBCAT_DESC, pa11.wjxbfs1 WJXBFS1, pa12.wjxbfs1 WJXBFS2 from (select a13.year_id YEAR_ID, a12.subcat_id SUBCAT_ID, sum(a11.tot_unit_sales) WJXBFS1 from ITEM_MNTH_SLS a11 join LU_ITEM a12 on (a11.item_id = a12.item_id) join LU_MONTH a13 on (a11.month_id = a13.month_id) group by a13.year_id, a12.subcat_id ) pa11 join (select a13.year_id YEAR_ID, a12.subcat_id SUBCAT_ID, sum(a11.units_received) WJXBFS1 from INVENTORY_ORDERS a11 join LU_ITEM a12 on (a11.item_id = a12.item_id) join LU_MONTH a13 on (a11.month_id = a13.month_id) group by a13.year_id, a12.subcat_id ) pa12 on (pa11.subcat_id = pa12.subcat_id and pa11.year_id = pa12.year_id) join LU_SUBCATEG a13 on (pa11.subcat_id = a13.subcat_id) MicroStrategy Incorporated, 2014 Page 8 of 49

Note that not all reports can take advantage of derived tables. There are two primary scenarios in which temporary tables must be used instead of derived tables: When a report uses a function supported in the MicroStrategy Analytical Engine that is not supported in SQL Server (e.g. many of the functions in the financial and statistical functions packages). If these functions are used for intermediate calculations, the MicroStrategy Analytical Engine will perform the calculations and then insert records back into the RDBMS for further processing. Inserting these records back into SQL Server requires a temporary table. When a report uses the MicroStrategy partitioning feature. (Do not confuse this with SQL Server partitioning, which is transparent to MicroStrategy.) When using partitioning, the MicroStrategy SQL Engine executes a portion of the query in order to determine which partitions to use. The results are then used to construct the rest of the query. Because the full structure of the query is not known prior to execution, the SQL engine must use temporary tables to execute the query in multiple steps. These situations do not cover 100% of the cases in which temporary tables must be used. The rest of the cases are relatively obscure combinations of VLDB settings, such as certain combinations of Sub Query Type plus outer join settings on metrics plus non-aggregatable metrics. If the Intermediate Table Type is set to Derived Tables then either True temporary table or Permanent table should be specified as the Fallback table type in case the specific report requirements not support the use of common table expressions. For each report, the SQL Engine will follow an all or nothing policy in determining whether to use common table expression syntax. If the entire report cannot be resolved in a single statement with common table expressions, the SQL Engine will automatically revert to the Fallback Table Type syntax and not use common table expression syntax at all for the report. MicroStrategy, by default, uses a permanent table when a fallback table type is required. VLDB Category VLDB Property Setting Value Tables Fallback table type Permanent Table Common Table Expressions Common table expressions (CTE) provide a way to perform many operations within a single SQL statement. Rather than implement each pass in a separate statement, CTE syntax allows the SQL Engine to issue additional SELECT statements in the WITH clause. The WITH clause defines a name for a single SELECT statement that can be referenced as a table name in any FROM clause of the full SELECT statement that follows. Using CTE can allow queries to run faster since there is no CREATE TABLE or DROP TABLE statement to catalog, no corresponding locks on the system tables, and no logging of records inserted into a physical table if needed. Customers may want to experiment with this option to determine if it is beneficial in their specific environment. MicroStrategy Incorporated, 2014 Page 9 of 49

VLDB Category VLDB Property Setting Value Tables Intermediate Table Type Common Table Expressions with pa1 as (select a12.subcat_id SUBCAT_ID, a13.year_id YEAR_ID, sum(a11.tot_unit_sales) WJXBFS1 from ITEM_MNTH_SLS a11 join LU_ITEM a12 on (a11.item_id = a12.item_id) join LU_MONTH a13 on (a11.month_id = a13.month_id) group by a12.subcat_id, a13.year_id ), pa2 as (select a12.subcat_id SUBCAT_ID, a13.year_id YEAR_ID, sum(a11.units_received) WJXBFS1 from INVENTORY_ORDERS a11 join LU_ITEM a12 on (a11.item_id = a12.item_id) join LU_MONTH a13 on (a11.month_id = a13.month_id) group by a12.subcat_id, a13.year_id )select pa1.subcat_id SUBCAT_ID, a11.subcat_desc SUBCAT_DESC, pa1.year_id YEAR_ID, pa1.wjxbfs1 WJXBFS1, pa2.wjxbfs1 WJXBFS2 from pa1 join pa2 on (pa1.subcat_id = pa2.subcat_id and pa1.year_id = pa2.year_id) join LU_SUBCATEG a11 on (pa1.subcat_id = a11.subcat_id) Note that not all reports are able to use common table expressions; the same restrictions/considerations apply as they do with derived tables. In the event that the MicroStrategy SQL engine cannot construct the query using common table expressions, it will fall back to either True temporary tables (the default) or to Permanent tables as indicated in the Fallback Table Type setting. Table Creation Type When creating intermediate tables in SQL Server, the SQL Engine will use implicit table creation rather than explicit table creation. The examples below illustrate the difference. Implicit table syntax select into ##ZZSP00 Explicit table syntax create table ##ZZSP00( MicroStrategy Incorporated, 2014 Page 10 of 49

) insert into ##ZZSP00 Index Creation on Intermediate Tables Most intermediate tables will either be joined on the attribute columns back to fact tables (e.g. metric qualification) or serve as temporary storage for metrics that will be joined with other intermediate tables to produce a final result. MicroStrategy doesn t create primary or secondary indexes on intermediate tables by default; however creating an index on the attribute columns may improve performance, since those columns will usually be involved in a join later in the report SQL. If you are using temporary tables as the intermediate table type and have large intermediate tables, consider setting the Intermediate Table Index VLDB setting to create an index on the attribute columns of each intermediate table. This setting can also be used to create indexes on the temporary or permanent tables created as part of the fallback table types for derived table syntax reports and common table expression. VLDB Category VLDB Property Setting Alternative Non-default Value Indexing Intermediate Table Index Create only secondary index on intermediate table select a11.customer_id CUSTOMER_ID into ##ZZMQ00 from CUSTOMER_SLS a11 where (a11.tot_unit_sales > 10.0) create index ##ZZMQ00_i on ##ZZMQ00 (CUSTOMER_ID) select a14.category_id CATEGORY_ID, max(a15.category_desc) CATEGORY_DESC, sum((a11.qty_sold * (a11.unit_price - a11.discount))) WJXBFS1 from ORDER_DETAIL a11 join LU_ORDER a12 on (a11.order_id = a12.order_id) join session.zzmq00 pa1 on (a12.customer_id = pa1.customer_id) join LU_ITEM a13 on (a11.item_id = a13.item_id) join LU_SUBCATEG a14 on (a13.subcat_id = a14.subcat_id) join LU_CATEGORY a15 on (a14.category_id = a15.category_id) group by a14.category_id Sub Query Type There are many cases in which the SQL Engine will generate subqueries (i.e. SELECT statements in the WHERE clause): MicroStrategy Incorporated, 2014 Page 11 of 49

Reports that use Relationship Filters Reports that use NOT IN set qualification, e.g. AND NOT <metric_qualification> or AND NOT <relationship_filter> Reports that use Attribute qualification with M-M relationships, e.g. show Revenue by Category, filter on Catalog Reports that raise the level of a filter, e.g. dimensional metric at Region level, but qualify on Store Reports that use non-aggregatable metrics, e.g. inventory metrics Reports that use Dimensional extensions Reports that use Attribute to attribute comparison in the filter The default setting for SQL Server and Sub Query Type is Option 2 Where col1 in (select s1.col1...) falling back to EXISTS (select * ) for multiple columns IN.. In most cases, the subquery expression will be generated by the SQL Engine using the IN syntax. select a11.item_id ITEM_ID, max(a12.item_name) ITEM_NAME, sum(a11.tot_dollar_sales) WJXBFS1 from ITEM_MNTH_SLS a11 join LU_ITEM a12 on (a11.item_id = a12.item_id) where (((a11.item_id) in (select r11.item_id from ITEM_MNTH_SLS r11 where r11.month_id in (200307))) group by a11.item_id If the subquery logically requires more than one column, the SQL Engine will generate an expression using EXISTS syntax. select a11.item_id ITEM_ID, max(a13.item_name) ITEM_NAME, sum(a11.tot_dollar_sales) WJXBFS1 from ITEM_MNTH_SLS a11 join LU_MONTH a12 on (a11.month_id = a12.month_id) join LU_ITEM a13 on (a11.item_id = a13.item_id) where ((exists (select * from ITEM_MNTH_SLS r11 join LU_MONTH r12 on (r11.month_id = r12.month_id) where r12.quarter_id in (20034) and r11.month_id = a11.month_id and r11.item_id = a11.item_id)) group by a11.item_id Customers may want to experiment with this setting to determine if a non-default setting is beneficial in their specific environment. Some reports may perform better with Option 6 Use temporary table, falling back to IN for correlated subquery. Reports that include a filter with an AND NOT set qualification (e.g. AND NOT relationship MicroStrategy Incorporated, 2014 Page 12 of 49

filter) could benefit from using temp tables to resolve the subquery. However, such reports will probably benefit more from using the Set Operator Optimization discussed later in this document. VLDB Category VLDB Property Setting Alternative Non-default Value Query Optimizations Sub Query Type Use Temporary Table falling back to IN (SELECT COL) for correlated subquery The other non-default options for this setting are unlikely to be advantageous with SQL Server. Option 0 WHERE EXISTS (select * ) IN performs better than EXISTS. This setting is useful for RDBMS platforms that do not support any of the other syntax. Option 1 WHERE EXISTS (select col1, col2 ) IN performs better than EXISTS. This setting is useful for RDBMS platforms that do not support other syntax and for which selecting column names performs better than select *. Option 3 Where (col1, col2) in (Select s1.col1, s1.col2 ) SQL Server does not support multiple columns in an IN subquery, so this setting cannot be used. Option 4 Use temporary table falling back to [Option 0] for correlated subqueries IN performs better than EXISTS for. Option 6 is better than Option 4 for SQL Server. Option 5 WHERE col1 IN (select s1.col1), falling back to [Option 1] for multiple columns EXISTS (select * ) performs better than EXISTS (select col1, col2), so Option 2 is a better choice than Option 5. SQL Global Optimization This setting can substantially reduce the number of SQL passes generated by MicroStrategy. In MicroStrategy, SQL Global Optimization reduces the total number of SQL passes with the following optimizations: o o o o Eliminates unused SQL passes, e.g. an intermediate table is created but not referenced in a later pass Reuses redundant SQL passes o E.g. exact same intermediate table is created multiple times single intermediate table is created Combines SQL passes where the SELECT list is different o E.g. two intermediate tables have the same FROM clause, same JOINs, same WHERE clause, same GROUP BY SELECT lists are combined into single SELECT statement Combines SQL passes where the WHERE clause is different o E.g. two intermediate tables have the same SELECT list, same FROM clause, same JOINs, same GROUP BY predicates from the WHERE clause are moved into CASE statements in the SELECT list. See the System Administration Guide for a complete description of the cases covered by this setting. The default setting for SQL Server is to enable SQL Global Optimization at its highest level. MicroStrategy Incorporated, 2014 Page 13 of 49

Set Operator Optimization This setting is used to combine multiple subqueries into a single subquery using set operators (i.e. UNION, INTERSECT, EXCEPT). The default setting for SQL Server is to enable Set Operator Optimization. select a13.category_id CATEGORY_ID, max(a14.category_desc) CATEGORY_DESC, sum(a11.tot_unit_sales) WJXBFS1 from ITEM_EMP_SLS a11 join LU_ITEM a12 on (a11.item_id = a12.item_id) join LU_SUBCATEG a13 on (a12.subcat_id = a13.subcat_id) join LU_CATEGORY a14 on (a13.category_id = a14.category_id) where (a11.emp_id) in (((select r11.emp_id from ITEM_EMP_SLS r11 where r11.item_id = 37) except (select r11.emp_id from ITEM_EMP_SLS r11 where r11.item_id = 217))) group by a13.category_id Parallel SQL Execution Parallel SQL Execution (PSE) is the ability to run some passes of a multi-pass SQL in parallel with the idea of improving the overall report execution time. Starting with MicroStrategy version 9.3.0, each report that is executed in sequential mode may record projected improvement in execution time if this report were to run in parallel mode. This information can be used to turn on PSE Mode. PSE is typically useful for reports that source from multiple databases as the report SQL passes tend to be distributed across sources and there isn t an increased query load on a single database due to passes being run in parallel. In addition to multisource reports, PSE can be considered for any critical or high visibility reports or for scheduled reports/cubes that are executed during off-peak hours when there load on the database tends to be low. It is important to consider the load on the database system, before turning on PSE for a large number of reports. PSE VLDB Settings: Level VLDB Category VLDB Property Setting Project, Query Optimizations Parallel Query Report Execution Value - Disable (default) - Enable Project, Report Query Optimizations Parallel Query Execution Improvement Estimate in SQL View - Disable (default) - Enable for multiple data source reports only - Enable for all reports that support it MicroStrategy Incorporated, 2014 Page 14 of 49

Project Query Optimizations Maximum Parallel Queries Per Report - 2 (default) Database Write-Back MicroStrategy provides the ability to write back data into the SQL Server database from MicroStrategy documents and dashboard. This functionality is implemented using the optional MicroStrategy Transaction Services. Transaction Services allows concurrent write-back of data from mobile devices or over the web using database transactions. The syntax used to implement write-back is defined using a Transaction Report. To embed this write-back functionality, you must create a Transaction Services report that defines what data can be updated and then can be placed in a Report Services Document. Transaction Services reports are created using the Freeform SQL Editor and inserting a transaction to the SQL definition for the report. This will add Begin Transaction and End Transaction to the report SQL definition. Begin Transaction <update statement...> End Transaction Example: Transaction Services FFSQL example Even though each DBMS has different methods to start and end transactions, MicroStrategy Transaction Services will start and end the transactions via ODBC calls made through the drivers. The workflow is outlined below and is identical to manually starting and ending transactions on the DBMS. Start: SQLSetConnectAttr SQL_AUTOCOMMIT_OFF=0 Execute Statements End: SQLEndTran SQL_COMMIT=0 SQL_ROLLBACK=1 MicroStrategy Transaction Services workflow Generally, the execution of a Transaction Services report does not automatically trigger the invalidation of MicroStrategy Caches or In-Memory Cubes. Therefore, any changes introduced by the Transaction Services report in the database might not automatically be reflected in a report or document even when re-executed. To achieve the desired application behavior it might be required to invalidate caches and/or cubes or to refrain from implementing these technologies altogether. On the other hand, a DBMS executing SQL against Transaction Services report objects on more relaxed isolation levels than Serializable might cause unintended and unwanted effects on concurrently executing reports or documents. MicroStrategy Incorporated, 2014 Page 15 of 49

Integration with SQL Server Linked Servers SQL Server supports the concept of Linked Servers, which allow you to access data not stored on the local SQL Server. The remote linked servers can be other SQL Server databases or non-sql Server databases such as Oracle. The SQL Server syntax for referencing a table in a linked server is: LinkedServerName..TableOwnerName.TableName If your linked server name is ORACLE and you have a table named LU_PROD owned by SCOTT, a view in the SQL Server database can be created as follows: CREATE VIEW LU_PROD AS SELECT * FROM ORACLE..SCOTT.LU_PROD If you have tables in the Oracle database that are owned by the Oracle ID System, you need to enclose the word System in brackets, as SQL Server uses System as a reserved word and does not accept its use in the table reference without the brackets: CREATE VIEW LU_PROD AS SELECT * FROM ORACLE..[SYSTEM].LU_PROD There are no VLDB settings associated with the use of SQL Server linked views in MicroStrategy. The linked server views appear as tables in the warehouse catalog and are accessible as if they were regular SQL Server tables. Querying XML Data in SQL Server SQL Server supports storing, managing, and querying XML data. SQL Server has a built-in XML data type so that users can store XML documents in columns in relational tables. SQL Server also provides methods on the XML data type that allow users to manipulate and query XML data from within SQL statements. MicroStrategy can take advantage of these methods to access XML data stored in SQL Server. Example Data The following examples use XML documents like the one below to represent information about Books. Instead of storing Title, Author, etc. in separate relational columns, the Book information is stored in an XML column. <book pages="110"> MicroStrategy Incorporated, 2014 Page 16 of 49

<title>history of Cats</title> <author> <fn>john</fn> <ln>doe</ln> </author> <author> <fn>jane</fn> <mi>e.</mi> <ln>doe</ln> </author> <chapter pages="10">beginning</chapter> <chapter pages="80">middle</chapter> <chapter pages="20">end</chapter> </book> The examples that follow are built on a simple MicroStrategy project using the sample tables below. LU_BOOK LU_MONTH LU_STORE BOOK_SALES BOOK_ID integer MONTH_ID integer STORE_ID integer BOOK_ID integer BOOK_XML xml YEAR_ID integer STORE_NAME varchar(50) STORE_ID integer REGION_ID integer MONTH_ID integer REGION_NAME varchar(50) DOLLARS integer UNITS integer The following MicroStrategy objects are defined: Attributes o Book: @ID = BOOK_ID, @XML = BOOK_XML o Year: @ID = YEAR_ID o Month: @ID = MONTH_ID; Parent = Year o Region: @ID = REGION_ID, @DESC = REGION_NAME o Store: @ID = STORE_ID, @DESC = STORE_NAME; Parent = Region Facts o Dollars = DOLLARS o Units = UNITS Metrics o SumDollars=Sum(Dollars) o SumUnits=Sum(Units) Note that the Book attribute does not have a DESC form, but rather has a form called XML that maps to the XML column in the LU_BOOK table. The XML form should not be used as a default display form. In fact, the XML form should not be displayed in the grid at all. MicroStrategy Incorporated, 2014 Page 17 of 49

MicroStrategy Incorporated, 2014 Page 18 of 49

When importing XML columns via the Warehouse Catalog Editor, the Table Structure dialog will show the XML data type will be shown as Unknown. This is not a problem in of itself, but there are a few implications: Garbage is likely to be displayed if an XML column is displayed in a grid. Attribute forms or facts mapped to XML columns should be wrapped in appropriate functions (e.g. CAST) that return strings or other standard data types. The XML data type will not be created by Engine-generated SQL when creating a data mart table or temp table that requires the XML column. However, as long as an XML column is not used as the ID form of an attribute or directly as a metric column, there should be no need to create a temp table using the XML data type. Filtering on XML data using EXIST MicroStrategy SQL can generate the EXIST syntax via a Filter using ApplyComparison. ApplyComparison("#0.exist( /book/author[ln=""doe""] ) = 1", Book@XML) MicroStrategy Incorporated, 2014 Page 19 of 49

MicroStrategy Incorporated, 2014 Page 20 of 49

select a11.book_id BOOK_ID, sum(a11.dollars) WJXBFS1 from BOOK_SALES a11 join LU_BOOK a12 on (a11.book_id = a12.book_id) where a12.book_xml.exist('/book/author[ln="doe"]') = 1 group by a11.book_id MicroStrategy Incorporated, 2014 Page 21 of 49

Displaying elements from XML data using QUERY and VALUE The QUERY method can be called in Attribute Forms or Metric expressions using ApplySimple. Users may need to introduce CAST into expression to avoid string data, right truncation error message during report execution. Attribute Form example: ApplySimple( cast(#0.query( /book/title ) as nvarchar(250)), Book@XML) Metric expression example: Max(ApplySimple("cast(#0.query('/book/title') as nvarchar(250))", Book@XML)) {~} QUERY returns XML, while VALUE returns a specified SQL data type. The following example illustrates how to call QUERY in an attribute form using ApplySimple. MicroStrategy Incorporated, 2014 Page 22 of 49

Sample attribute form using ApplySimple and QUERY Sample SQL: select a11.book_id BOOK_ID, cast(a11.book_xml.query('/book/title') as nvarchar(250)) CustCol_1 from LU_BOOK a11 MicroStrategy Incorporated, 2014 Page 23 of 49

Sample result from report using attribute form using QUERY The VALUE method can also be called in Attribute Forms or Metric expressions using ApplySimple. Attribute form example: ApplySimple("#0.value('/book[1]/title[1]', 'varchar(100)')", [BOOK_XML]) Metric expression example: Max(ApplySimple("#0.value('/book[1]/title[1]', 'varchar(100)')", Book@XML)) {~} The first argument to VALUE must be a single element; if the XQuery expression results in multiple elements, an error will result. The following example illustrates how to call VALUE in a metric definition using ApplySimple. MicroStrategy Incorporated, 2014 Page 24 of 49

Sample metric definition using ApplySimple and VALUE Sample SQL select a11.book_id BOOK_ID, a11.book_xml.value('/book[1]/title[1]', 'varchar(100)') WJXBFS1 from LU_BOOK a11 MicroStrategy Incorporated, 2014 Page 25 of 49

Sample result from report using metric using VALUE Modeling XML data as a Logical Table using VALUE and NODES The NODES and VALUE methods can be used to return a result table from the evaluation of XQuery expressions against data in an XML column. We can use MicroStrategy logical views to make a column of XML look like a table to the SQL Engine. The data can then be accessed like any other table modeled in the MicroStrategy schema. For example, define a new Logical Table called LV_CHAPTER using the SQL statement below. select B.book_id, C.value('../title[1]', 'varchar(50)') as Title, C.value('../author[1]/fn[1]', 'varchar(50)') as AuthorFN, C.value('../author[1]/mi[1]', 'varchar(50)') as AuthorMI, C.value('../author[1]/ln[1]', 'varchar(50)') as AuthorLN, C.value('.', 'varchar(50)') as Chapter, C.value('@pages', 'varchar(50)') as ChapterLength from LU_BOOK B cross apply book_xml.nodes('/book/chapter') as resulttable(c) MicroStrategy Incorporated, 2014 Page 26 of 49

Logical Table Editor The NODES method takes the XML column LU_BOOK.BOOK_XML and returns a row for every element matching /book/chapter (i.e. one row for every chapter). Each call to the VALUE method maps the result of an XQuery expression to a column in the resulting table. The user must be aware of a few rules for these mappings: If the path expression returns no elements, then the column value is NULL for the current row. If the path expression returns exactly one element, then that element will be mapped to the data type specified. If the path expression returns more than one element, the function will return an error. The SELECT statement above returns results like the following. MicroStrategy Incorporated, 2014 Page 27 of 49

BOOK_ID TITLE AUTHORFN AUTHORMI AUTHORLN CHAPTER CHAPTER LENGTH 1 History of Dogs John NULL Doe Introduction NULL 1 History of Dogs John NULL Doe Body NULL 1 History of Dogs John NULL Doe Conclusion NULL 2 History of Cats John NULL Doe Beginning 10 2 History of Cats John NULL Doe Middle 80 2 History of Cats John NULL Doe End 20 3 Counting to Three John Q Public One 10 3 Counting to Three John Q Public Two 175 3 Counting to Three John Q Public Three 15 Using the new Logical Table as a source table, define a new attribute and a new fact: Attribute Chapter: @ID = Chapter, Parent = Book Fact ChapterLength: ChapterLength Ensure that LV_CHAPTER is a source table for Book@ID. You may need to edit the Book attribute in order for this change to be recognized by the product. During report execution the logical view syntax will be included in SQL generated by the Engine. MicroStrategy Incorporated, 2014 Page 28 of 49

Attribute using Logical Table Attribute Editor and Parent Mapping MicroStrategy Incorporated, 2014 Page 29 of 49

Fact using Logical Table Report example using Logical Table and NODES and VALUE syntax: Attributes: Chapter Metrics o Book Units Sold: sum(units) {Book*, ~+} o Number of Pages: sum(chapterlength) {~+} MicroStrategy Incorporated, 2014 Page 30 of 49

select a11.book_id BOOK_ID, sum(a11.units) WJXBFS1 into ##ZZMD00 from BOOK_SALES a11 group by a11.book_id select a11.chapter CHAPTER, a11.chapterlength WJXBFS1 into ##ZZMD01 from (select B.book_id, C.value('../title[1]', 'varchar(50)') as Title, C.value('../author[1]/fn[1]', 'varchar(50)') as AuthorFN, C.value('../author[1]/mi[1]', 'varchar(50)') as AuthorMI, C.value('../author[1]/ln[1]', 'varchar(50)') as AuthorLN, C.value('.', 'varchar(50)') as Chapter, C.value('@pages', 'varchar(50)') as ChapterLength from LU_BOOK B cross apply book_xml.nodes('/book/chapter') as resulttable(c) ) a11 select pa11.chapter CHAPTER, pa13.wjxbfs1 WJXBFS1, pa11.wjxbfs1 WJXBFS2 from ##ZZMD01 pa11 join (select B.book_id, C.value('../title[1]', 'varchar(50)') as Title, C.value('../author[1]/fn[1]', 'varchar(50)') as AuthorFN, C.value('../author[1]/mi[1]', 'varchar(50)') as AuthorMI, C.value('../author[1]/ln[1]', 'varchar(50)') as AuthorLN, C.value('.', 'varchar(50)') as Chapter, C.value('@pages', 'varchar(50)') as ChapterLength MicroStrategy Incorporated, 2014 Page 31 of 49

from LU_BOOK B cross apply book_xml.nodes('/book/chapter') as resulttable(c) ) a12 on (pa11.chapter = a12.chapter) join ##ZZMD00 pa13 on (a12.book_id = pa13.book_id) drop table ##ZZMD00 drop table ##ZZMD01 Integration with Indexed Views Pre-aggregating data is a common and powerful way to improve end user query response times. Rather than aggregating many, many rows at query execution time, pre-summarization allows the database to perform row access and aggregation ahead of time, satisfying the query request time much faster. Data warehouse practitioners have long used physical summary tables to pre-aggregate data in a ROLAP environment. MicroStrategy is an aggregate aware application that allows end users to query physical summary tables without needing to specify which table to use to satisfy the query. SQL Server provides Indexed Views as a means of materializing pre-aggregated data. Indexed views are a SQL Server feature that provides for the creation, maintenance, and automatic navigation of aggregated data. When a unique clustered index is created for a view, the view definition is computed and stored in the database like a regular table to create an Indexed View. A user can reference the view directly in SQL or the SQL Server optimizer may choose to rewrite a query that references a base table to use the indexed view instead (provided that it determines its cost to be less than the original query). In the latter case, the use of Indexed Views is entirely transparent to the end user and to the MicroStrategy developer. Indexed Views can provide dramatic query execution improvements when the SQL submitted by the application attempts to aggregate many rows. Based on the Relational OLAP architecture used by MicroStrategy, any SQL generated by an end user request will be submitted to SQL Server where the optimizer may choose to substitute the Indexed View for the base table. Provided that the proper conditions are set up in the view definition, MicroStrategy will transparently take advantage of Indexed Views via the logic implemented by the SQL Server query optimizer. If desired, a MicroStrategy Developer can also use the Indexed View to model MicroStrategy Attributes and Facts directly against the view. Best Practices for Indexed Views Below are some general guidelines for creating and managing materialized query tables: If the underlying data in the base table are frequently updated then the use of Indexed Views on that data may not be beneficial. Not recommended for OLTP Keep the index key compact There is an increased maintenance cost in using Indexed Views as they require more disk space as they are updated automatically to reflect changes in the base tables. MicroStrategy Incorporated, 2014 Page 32 of 49

Use the SQL Server Database Engine Tuning Advisor for guidance on creating indexed views optimized for the expected SQL loads. Note: MicroStrategy does not support the use of Indexed Views on MicroStrategy Intermediate tables because the SQL Engine does not support the use of the WITH SCHEMABINDING clause in the view creation DDL. There is no VLDB setting associated with this option. Integration with Table-Valued User-Defined functions SQL Server supports table-valued user-defined functions in which users can provide input parameters to answer analytical questions of the data warehouse. Table-valued functions are similar to stored procedures but unlike stored procedures can be referenced in a FROM clause much like a table. When a table-valued function is referenced in the select statement the results are stored in the tempdb prior to being returned to the application. Table-valued user-defined function example The following example illustrates how a table-valued user-defined function can be used in MicroStrategy with a Free Form SQL report. In the SQL Server database a table exists with employee information (LU_EMPLOYEE). A table-valued user-defined function is created to pull the employee ID, employee first and last name, and employee hire date from the existing table while generating the years of experience on the fly. The input parameter for the function requires the user to specify an integer value for the number of years of experience. The table output of the SELECT statement will display the employees who meet that criterion. CREATE FUNCTION EmployeesWithYearsExperience(@years int) RETURNS @YearsExperience TABLE ( EmpId int primary key NOT NULL, EmpName nvarchar(100) NOT NULL, HireDate date NOT NULL, YearsExperience int NULL ) AS BEGIN INSERT INTO @YearsExperience (EmpId, EmpName, HireDate, YearsExperience) SELECT [EMP_ID], [EMP_FIRST_NAME] + ' ' + [EMP_LAST_NAME], [HIRE_DATE], DATEDIFF (year, [HIRE_DATE], GETDATE()) FROM LU_EMPLOYEE WHERE DATEDIFF (year, [HIRE_DATE], GETDATE()) >= @years; RETURN; END; In MicroStrategy, a Free Form SQL report is created from a SELECT statement and the columns and attributes and metrics are mapped accordingly. Instead of hard coding a numeric value for the number MicroStrategy Incorporated, 2014 Page 33 of 49

of years a value prompt is added so that the user can input any value for the number of years experience. When the report is executed the user is prompted for a numeric value and the end result set displays those values that meet the criterion. MicroStrategy Incorporated, 2014 Page 34 of 49

MicroStrategy Incorporated, 2014 Page 35 of 49

Integration with In-Memory OLTP Introduced in SQL Server 2014 and available in 64-bit Enterprise, Developer, and Evaluation editions, the In-Memory OLTP database engine is optimized for OLTP operations. This new engine component integrates with the SQL Server engine and allows for the creation of tables that reside in the SQL Server host memory and are fully transactional, durable, and accessible via SQL like traditional disk-based tables. Designed to handle heavy insertion rates from concurrent connections, the new engine can dramatically improve the performance of OLTP operations. In order to create in-memory optimized tables the SQL Server database administrator must first create a memory optimized file group for the database and associate a database file with this file group. MicroStrategy developers can add SQL Server memory-optimized base tables to a MicroStrategy project without the need for any changes on the MicroStrategy side. The default warehouse catalog SQL will return the base tables that reside on disk or in-memory. There is no VLDB setting associated with this option. Intermediate tables and In-Memory OLTP: MicroStrategy does not support the use of in-memory OLTP tables for MicroStrategy intermediate tables. Comment [MW1]: I don t think we need to update our object to support this feature. The current SQL Engine does not generate a nonclustered primary key (or even an ordinary primary key) which is required in the DDL. Also, in my testing I did not see any performance gains over global temporary tables. MicroStrategy Incorporated, 2014 Page 36 of 49

MicroStrategy Transaction services and In-Memory OLTP MicroStrategy developers can also take advantage of the In-Memory OLTP feature via the MicroStrategy Transaction Services product. See Database Write-Back for more details on this feature. Integration with Clustered Columnstore Indexes Introduced in SQL Server 2014 and available in the Enterprise, Developer, and Evaluation editions, a clustered columnstore index provides an in-memory columnar storage option for SQL Server. This index type is best suited for data warehousing workloads where bulk loads and read-only queries are prevalent. Consequently, this feature is targeted primarily for analytics rather than OLTP operations. A clustered columnstore index is the only index on the base table and determines the physical storage (column-oriented) for the entire table. The data in a clustered columnstore index is compressed up to 7 times more than its equivalent storage in a row-oriented table. MicroStrategy developers may find this feature useful for MicroStrategy Data Mart reports where inserts are one-time or infrequent. In order to use a Clustered Columnstore Index with a Data Mart Report, the Report Data Mart should be edited to include the following SQL to be executed after the table creation but before data insertion. CREATE CLUSTERED COLUMNSTORE INDEX cci_??? ON?? Note: The??? is a MicroStrategy wildcard that will be replaced with the name of the MicroStrategy data mart table. MicroStrategy Incorporated, 2014 Page 37 of 49

If the MicroStrategy Data Mart report is writing to an existing table the SQL to create the clustered columnstore index should include the DROP_EXISTING = ON so that the index statement will not fail. CREATE CLUSTERED COLUMNSTORE INDEX cci_??? ON?? WITH (DROP_EXISTING = ON) Additional VLDB Settings Many of the VLDB properties control string syntax used in SQL queries generated by the MicroStrategy SQL engine. MicroStrategy application developers can further optimize SQL for their specific SQL Server environment using these string insertion settings. Possible locations for VLDB optimizations in the query structure are listed below. VLDB String Insertion Settings when using temporary tables [Report Pre Statements] [Table Pre Statements] select [SQL Hint] <column_expressions> into <table_name> from <tables_and_joins> where <filter_expressions> MicroStrategy Incorporated, 2014 Page 38 of 49

group by having <column_expressions> <column_expressions> [Insert Post String] create [Index Qualifier] index [Index Prefix]<index_name> on <column_expression> [Index Post String] create [Index Qualifier] index [Index Prefix]<index_name> on <column_expression> [Index Post String] [Table Post Statements] select [SQL Hint] <column_expressions> from <tables_and_joins> where <filter_expressions> group by <column_expressions>[select Post String][Select Statement Post String] [Report Post Statements] drop table <table_name> [Cleanup Post Statements] VLDB String Insertion Settings when using Permanent Tables and Explicit Table Creation When Intermediate Table Type is set to Permanent Tables, some additional string-valued settings are enabled so that the user can customize the syntax of CREATE TABLE statement. Also, when Table Creation Type is set to Explicit, temporary tables are created with separate CREATE TABLE and INSERT statements; Implicit table creation does not generate INSERT statements. When using Explicit table creation, some additional string-valued settings are enabled so that the user can customize the syntax of the INSERT statements. The SQL below shows the position of these VLDB settings. [Report Pre Statements] [Table Pre Statements] create [Table Qualifier] table [Table Descriptor][Table Prefix] <table_name> [Table Option] ( <column_specifications>) [Table Space] [Create Post String] [Insert Pre Statements] [Bulk Insert String]insert into [Table Prefix]<table_name> [Insert Table Option] select [SQL Hint] <column_expressions> from <tables_and_joins> where <filter_expressions> group by <column_expressions> having <column_expressions> [Insert Post String] MicroStrategy Incorporated, 2014 Page 39 of 49

[Insert Post Statements] create [Index Qualifier] index [Index Prefix]<index_name> on <column_expression> [Index Post String] create [Index Qualifier] index [Index Prefix]<index_name> on <column_expression> [Index Post String] [Table Post Statements] select [SQL Hint] <column_expressions> from <tables_and_joins> where <filter_expressions> group by <column_expressions>[select Post String][Select Statement Post String] [Report Post Statements] drop table <table_name> [Cleanup Post Statements] Extended Analytics Using SQL Server Functions The MicroStrategy platform includes libraries of mathematical, statistical, and financial functions that can be applied to any report or customized application. More than 250 analytical functions are available out-of-the-box, and additional libraries can be added by plugging in custom functions or proprietary algorithms. The MicroStrategy platform provides the advantage of determining whether a given function can be performed in SQL Server or whether it should be performed in the MicroStrategy engine. This collaboration between MicroStrategy and SQL Server allows calculations to be performed in the most appropriate location. In general, the MicroStrategy engine will push as much processing as possible to SQL Server, in order to take advantage of the processing power of the database server and database parallelism. Additionally, using RDBMS functions avoids transport of data between the database server and the MicroStrategy Intelligence Server, further improving scalability and system performance. Analytic Functions: Functions for OLAP OLAP functions are a powerful family of functions for business intelligence and data warehousing applications. These functions can provide significant analytical capabilities for many business analysis queries. SQL Syntax for OLAP Functions <analytic function> ::= <function_name> OVER ([<partition clause>] [<order by clause> [<windowing clause>]]) MicroStrategy Incorporated, 2014 Page 40 of 49

SQL Server 2012 added push-down support for OLAP functions that were not supported in prior releases of SQL Server. With SQL Server 2012 and higher, MicroStrategy s OLAP functions will be calculated via SQL in SQL Server rather than in the MicroStrategy analytical engine. Below is the list of MicroStrategy supported OLAP functions that are pushed-down to the database server. There is no VLDB setting associated with this option. OLAP functions supported for push down with SQL Server 2012 and higher FirstInRange MovingStdev OLAPSum Lag MovingStdevP RunningAvg LastInRange MovingSum RunningCount Lead OLAPAvg RunningMax MovingAvg OLAPCount RunningMin MovingCount OLAPMax RunningStdev MovingMax OLAPMin RunningStdevP MovingMin OLAPRank RunningSum Moving average example select a11.day_date DAY_DATE, a12.region_id REGION_ID, max(a13.region_name) REGION_NAME, sum(a11.tot_dollar_sales) WJXBFS1, avg(sum(a11.tot_dollar_sales)) over(order by a12.region_id asc rows 2 preceding) WJXBFS1 from DAY_CTR_SLS a11 join LU_CALL_CTR a12 on (a11.call_ctr_id = a12.call_ctr_id) join LU_REGION a13 on (a12.region_id = a13.region_id) group by a11.day_date, a12.region_id On Windows users should also choose the Microsoft SQL Server 2012 database connection type but something else needs to be considered. MicroStrategy supports two different ODBC drivers for Microsoft SQL Server 2012. One is the default Windows ODBC driver that comes with the OS installation and is called the SQL Server driver. The other ODBC Driver does not come installed by default and is called the SQL Server Native Client. This must be downloaded from Microsoft or copied from the SQL Server 2012 installation media. MicroStrategy Incorporated, 2014 Page 41 of 49

The SQL Server driver does not support the new OLAP functions so if a user attempts to execute a report that takes advantage of the OLAP functions the following message appears: [Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near rows. To work around this error, users should modify the Database Connection so that the DSN used for the Warehouse connection is one configured to use the SQL Server Native Client ODBC Driver. This driver has full support for the new OLAP functions. Ranking The RANK function is closely related to other OLAP functions. Key distinctions of the RANK function are that it requires an order by clause and does not support a window clause. The MicroStrategy Engine is aware that SQL Server supports the Rank function, so the ranking will be done by the database rather than the MicroStrategy Analytical Engine. Rank example select a13.region_id REGION_ID, max(a14.region_name) REGION_NAME, a11.emp_id EMP_ID, max(a12.emp_last_name) EMP_LAST_NAME, max(a12.emp_first_name) EMP_FIRST_NAME, sum(a11.tot_dollar_sales) WJXBFS1, rank () over (partition by a13.region_id order by sum(a11.tot_dollar_sales) asc) WJXBFS2 from ITEM_EMP_SLS a11 MicroStrategy Incorporated, 2014 Page 42 of 49

join LU_EMPLOYEE a12 on (a11.emp_id = a12.emp_id) join LU_CALL_CTR a13 on (a12.call_ctr_id = a13.call_ctr_id) join LU_REGION a14 on (a13.region_id = a14.region_id) group by a13.region_id, a11.emp_id Custom Group Banding via the CASE statement Custom Group Banding is a powerful technique for generating histograms and other complex analyses. The Engine uses SQL Server s CASE statement to implement custom group banding reports. select a11.customer_id CUSTOMER_ID, Case when (a11.tot_dollar_sales=10000.0 and 10000.0=1.0+100.0*floor((10000.0-1.0)/100.0) ) then floor(1.0*(a11.tot_dollar_sales- 1.0)/100.0) when (a11.tot_dollar_sales between 1.0 and 10000.0) then floor(1.0*(a11.tot_dollar_sales- 1.0)/100.0) +1 else 0 end DA62 into #ZZMQ00 from CUSTOMER_SLS a11 where (a11.tot_dollar_sales between 1.0 and 10000.0) select a12.da62 DA62, sum(a11.tot_unit_sales) WJXBFS1 from CUSTOMER_SLS a11 join #ZZMQ00 a12 on (a11.customer_id = a12.customer_id) join LU_CUSTOMER a13 on (a11.customer_id = a13.customer_id) join LU_CUST_CITY a14 on (a13.cust_city_id = a14.cust_city_id) where a14.cust_state_id in (5) group by a12.da62 drop table #ZZMQ00 MicroStrategy Certification of SQL Server Status Listed below is the current status of certification of SQL Server by MicroStrategy. SQL Server 2014 OS platform Recommended ODBC Driver Status Windows 32-bit and 64-bit AIX 64-bit Solaris 64-bit RedHat and SUSE 64-bit 32-bit SQL Server Native Client ODBC Driver or 32-bit SQL Server ODBC Driver 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol Certified: MD, WH, ST, NCS Certified: MD, WH, ST Certified: MD, WH, ST Certified: MD, WH, ST MicroStrategy Incorporated, 2014 Page 43 of 49

HP-UX 64 bit Itanium 64-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol Certified: MD, WH, ST SQL Server 2012 OS platform Recommended ODBC Driver Status Windows 32-bit and 64-bit AIX 64-bit Solaris 64-bit RedHat and SUSE 64-bit HP-UX 64 bit Itanium SQL Server 2008 R2 32-bit SQL Server Native Client ODBC Driver or 32-bit SQL Server ODBC Driver 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 64-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol OS platform Recommended ODBC Driver Status Windows 32-bit and 64-bit AIX 64-bit Solaris 64-bit RedHat and SUSE 64-bit HP-UX 64 bit Itanium SQL Server 2008 32-bit SQL Server Native Client ODBC Driver or 32-bit SQL Server ODBC Driver 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 64-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol OS platform Recommended ODBC Driver Status Windows 32-bit and 64-bit AIX 64-bit Solaris 64-bit RedHat and SUSE 64-bit HP-UX 64 bit Itanium SQL Server 2005 32-bit SQL Server Native Client ODBC Driver or 32-bit SQL Server ODBC Driver 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 64-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol OS platform Recommended ODBC Driver Status Windows 32-bit and 64-bit AIX 64-bit Solaris 64-bit 32-bit SQL Server Native Client ODBC Driver or 32-bit SQL Server ODBC Driver 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol Certified: MD, WH, ST, NCS Certified: MD, WH, ST Certified: MD, WH, ST Certified: MD, WH, ST Certified: MD, WH, ST Certified: MD, WH, ST, NCS Certified: MD, WH, ST Certified: MD, WH, ST Certified: MD, WH, ST Certified: MD, WH, ST Certified: MD, WH, ST, NCS Certified: MD, WH, ST Certified: MD, WH, ST Certified: MD, WH, ST Certified: MD, WH, ST Certified: MD, WH, ST, NCS Certified: MD, WH, ST Certified: MD, WH, ST MicroStrategy Incorporated, 2014 Page 44 of 49

RedHat and SUSE 64-bit HP-UX 64 bit Itanium 32-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol 64-bit MicroStrategy ODBC Driver for SQL Server Wire Protocol Certified: MD, WH, ST Certified: MD, WH, ST Appendix Default VLDB Settings for SQL Server for Linux, UNIX and Windows VLDB Category VLDB Property Setting Value Tables Intermediate Table Type True temporary table Tables Table Creation Type Implicit Table Tables Fallback Table Type Permanent table Indexing Intermediate Table Index Don t create an index Query Optimizations Query Optimizations Sub Query Type SQL Global Optimization WHERE COL1 IN (SELECT s1.col1 ), falling back to EXISTS (SELECT * ) for multiple columns IN Level 4: Level 2 + Merge All Passes with Different Where Query Optimizations Set Operator Optimization Enable set operator optimization Joins Max Tables In Join 255 Joins Full Outer Join Support Supported Select/Insert UNION Multiple INSERT Use UNION Data type Mapping MicroStrategy supports the following SQL Server data types: Exact numerics: BIGINT, BIT, DECIMAL, INT, MONEY, NUMERIC, SMALLINT, SMALLMONEY, TINYINT Approximate numeric: FLOAT, REAL Date and Time: DATE, DATETIME, DATETIME2, SMALLDATETIME, TIME Character strings: CHAR, TEXT, VARCHAR Unicode character strings: NCHAR, NTEXT, NVARCHAR Binary strings: BINARY, IMAGE, VARBINARY MicroStrategy Incorporated, 2014 Page 45 of 49

Other data types:, TIMESTAMP, XML (see previous section for details) MicroStrategy does not support the following data types: CURSOR, DATETIMEOFFSET, HIERARCHYID, SQL_VARIANT, TABLE, UNIQUEIDENTIFIER, and SPATIAL TYPES. SQL Server Database Functions Used by MicroStrategy MicroStrategy makes use of built-in SQL Server functions when possible. Listed below are the MicroStrategy supported functions and the equivalent IBM SQL pattern as it applies to the MicroStrategy SQL Engine. Those designated as Analtyical Engine do not have a native built-in function equivalent on SQL Server. MSTR Function Category MSTR Function SQL Pattern Basic CoalesceFunction Analytical Engine Basic ExceptFunction #<(#>#1#<#0 except #*#>#<)#> Basic FirstFunction Analytical Engine Basic GeoMeanFunction EXP(AVG(LOG(#0))) Basic GreatestFunction Analytical Engine Basic IFOperator (Case when #0 then #1 else #2 end) Basic IsNotNullFunction Analytical Engine Basic IsNullFunction Analytical Engine Basic LastFunction Analytical Engine Basic LeastFunction Analytical Engine Basic MedianFunction Analytical Engine Basic MovingDifferenceFuncti on Analytical Engine Basic NotInOperator Analytical Engine Basic NotLikeOperator Analytical Engine Basic ProductFunction Analytical Engine Basic StdevFunction STDEV(#0#< #*#>) Basic StdevPFunction STDEVP(#0#< #*#>) Basic UnionFunction #<(#>#1#<#0 union #*#>#<)#> Basic VarFunction VAR(#0#< #*#>) Basic VarPFunction VARP(#0#< #*#>) Date & Time AddDaysFunction DATEADD(DD, #1, #0) Date & Time AddMonthsFunction DATEADD(MM, #1, #0) Date & Time CurrentDateFunction CONVERT (date, GETDATE()) Date & Time CurrentDateTimeFuncti on GETDATE() Date & Time CurrentTimeFunction CONVERT (time, GETDATE()) Date & Time DateFunction CONVERT(DATETIME, CONVERT(VARCHAR(10), #0, 101)) Date & Time DayOfMonthFunction DATEPART(DAY, #0) Date & Time DayOfWeekFunction DATEPART(WEEKDAY, #0) MicroStrategy Incorporated, 2014 Page 46 of 49

Date & Time DayOfYearFunction DATEPART(DAYOFYEAR, #0) Date & Time DaysBetweenFunction DATEDIFF(DD, #0, #1) Date & Time HourFunction DATEPART(Hour, #0) Date & Time MilliSecondFunction DATEPART(Millisecond, #0) Date & Time MinuteFunction DATEPART(Minute, #0) Date & Time MonthEndDateFunction CONVERT(DATE, DATEADD(mm, 1 + DATEDIFF(mm, 0, #0), -1)) Date & Time MonthFunction DATEPART(MONTH, #0) Date & Time MonthsBetweenFunctio n (DATEDIFF(MM, #0, #1) - CASE WHEN DAY(#0) > DAY(#1) THEN 1 ELSE 0 END) Date & Time MonthStartDateFunctio n CONVERT(DATE, DATEADD(mm, DATEDIFF(mm, 0, #0), 0)) Date & Time QuarterFunction DATEPART(QUARTER, #0) Date & Time SecondFunction DATEPART(Second, #0) Date & Time WeekFunction DATEPART(WEEK, #0) Date & Time YearEndDateFunction CONVERT(DATE, DATEADD(yy, 1 + DATEDIFF(yy, 0, #0), -1)) Date & Time YearFunction DATEPART(YEAR, #0) Date & Time YearStartDateFunction CONVERT(DATE, DATEADD(yy, DATEDIFF(yy, 0, #0), 0)) Internal BandingCFunction Case when (#1=#2 and #0=#1) then #3 when (#0=#2) then #3 when (#0 between #1 and #2) then floor(1.0*#3*(#0- #1)/(#2- #1)+1) else 0 end Internal BandingFunction Case when (#0=#2 and #2=#1+#3*floor((#2- #1)/#3) ) then floor(1.0*(#0- #1)/#3) when (#0 between #1 and #2) then floor(1.0*(#0- #1)/#3) +1 else 0 end Mathematical AbsFunction ABS(#0) Mathematical AcosFunction ACOS(#0) Mathematical AcoshFunction LOG(#0+SQRT(#0-1)*SQRT(#0+1)) Mathematical AsinFunction ASIN(#0) Mathematical AsinhFunction LOG(#0+SQRT(POWER(#0,2)+1)) Mathematical Atan2Function ATN2(#1, #0) Mathematical AtanFunction ATAN(#0) Mathematical AtanhFunction ((LOG(1+#0)-LOG(1- #0))/2) Mathematical CeilingFunction CEILING(#0) Mathematical CosFunction COS(#0) Mathematical CoshFunction Analytical Engine Mathematical DegreesFunction DEGREES(#0) Mathematical ExpFunction EXP(#0) Mathematical FloorFunction FLOOR(#0) Mathematical Int2Function FLOOR(#0) Mathematical IntersectFunction #<(#>#1#<#0 intersect #*#>#<)#> Mathematical IntFunction FLOOR(#0) Mathematical LnFunction LOG(#0) Mathematical Log10Function LOG10(#0) MicroStrategy Incorporated, 2014 Page 47 of 49

Mathematical LogFunction LOG(#0)/LOG(#1) Mathematical ModFunction (#0-FLOOR((#0)/NULLIF(#1, 0))*(#1)) Mathematical PowerFunction POWER(#0, #1) Mathematical QuotientFunction CAST((#0)/NULLIF(#1, 0) AS INTEGER) Mathematical RadiansFunction RADIANS(#0) Mathematical RandbetweenFunction ((#1- #0)*RAND()+#0) Mathematical RankFunction #0#,#<partition by#>#<#, #*#># rank () over (#1#2#<,#*#> order by #0) Mathematical Round2Function ROUND(#0, #1) Mathematical RoundFunction ROUND(#0, 0) Mathematical SinFunction SIN(#0) Mathematical SinhFunction Analytical Engine Mathematical SqrtFunction SQRT(#0) Mathematical TanFunction TAN(#0) Mathematical TanhFunction Analytical Engine Mathematical TruncFunction CAST(#0 AS INTEGER) Null & Zero NullToZeroFunction ISNULL(#0, 0) Null & Zero ZeroToNullFunction NULLIF(#0, 0) OLAP FirstInRangeFunction first_value(#0) over(#1) OLAP LagFunction lag(#0#<, #*#>) over ([#P] [#O]) OLAP LastInRangeFunction last_value(#0) over(#1) OLAP LeadFunction lead(#0#<, #*#>) over ([#P] [#O]) OLAP MovingAvgFunction avg(#0) over(#1) OLAP MovingCountFunction count(#0) over(#1) OLAP MovingMaxFunction max(#0) over(#1) OLAP MovingMinFunction min(#0) over(#1) OLAP MovingStdevFunction stdev(#0) over(#1) OLAP MovingStdevPFunction stdevp(#0) over(#1) OLAP MovingSumFunction sum(#0) over(#1) OLAP OLAPAvgFunction avg(#0#< #*#>) over ([#P] [#O] [#W]) OLAP OLAPCountFunction count(#0#< #*#>) over ([#P] [#O] [#W]) OLAP OLAPMaxFunction max(#0#< #*#>) over ([#P] [#O] [#W]) OLAP OLAPMinFunction min(#0#< #*#>) over ([#P] [#O] [#W]) OLAP OLAPRankFunction rank() over ([#P] [#O]) OLAP OLAPSumFunction sum(#0#< #*#>) over ([#P] [#O] [#W]) OLAP RunningAvgFunction avg(#0) over(#1) OLAP RunningCountFunction count(#0) over(#1) OLAP RunningMaxFunction max(#0) over(#1) OLAP RunningMinFunction min(#0) over(#1) OLAP RunningStdevFunction stdev(#0) over(#1) OLAP RunningStdevPFunction stdevp(#0) over(#1) OLAP RunningSumFunction sum(#0) over(#1) MicroStrategy Incorporated, 2014 Page 48 of 49

Statistical CorrelationFunction Analytical Engine Statistical CovarianceFunction Analytical Engine Statistical FisherFunction Analytical Engine Statistical InterceptFunction Analytical Engine Statistical PearsonFunction Analytical Engine Statistical RSquareFunction Analytical Engine Statistical SlopeFunction Analytical Engine Statistical StandardizeFunction Analytical Engine Statistical SteYXFunction Analytical Engine String ConcatBlankFunction (#0#< + ' ' + #*#>) String ConcatFunction CONCAT(#0#<, #*#>) String InitCapFunction (UPPER(SUBSTRING(#0, 1, 1)) + LOWER(SUBSTRING(#0, 2, Len(#0) - 1))) String LeftStrFunction LEFT(#0, #1) String LengthFunction LEN(#0) String LowerFunction LOWER(#0) String LTrimFunction LTRIM(#0) String PositionFunction CHARINDEX(#0, #1) String RightStrFunction RIGHT(#0, #1) String RTrimFunction RTRIM(#0) String SubStrFunction SUBSTRING(#0, #1, #2) String TrimFunction LTRIM(RTRIM(#0)) String UpperFunction Analytical Engine MicroStrategy Incorporated, 2014 Page 49 of 49