Tips, Tricks, and General Info on the Msft BI Platform : Analysis Services

Getting Excel Web Access Errors with SSAS 2008?

jbasilico — Tue, 15 Dec 2009 19:21:00 GMT

If you are having issues getting Analysis Services 2008 data being refreshed through Excel Services, take a look at the trusted providers within MOSS. By default, MOSS only trusts up to SQL Server 2005, simply because SQL Server 2008 wasn't out when MOSS 2007 was released.

To correct, you'll need to add a Trusted Data Provider as follows:

Provider ID = MSOLAP.4
Data Provider Type = OLE DB
Description = Microsoft OLE DB Provider for OLAP Services 10.0.

For full explanation/steps that walk through the "fix", follow this link.

Constrained Delegation with Kerberos and SSAS Named Instance

jbasilico — Sat, 04 Apr 2009 00:26:00 GMT

If you building an environment with Kerberos Constrained Delegation, and have a named instance of Analysis Services, where your DC is running Windows Server 2003, take note. Having learned the hard way this week, there is a hot fix for Windows Server 2003 you'll need to apply before Kerberos will work with the named instance of SSAS.

Here's the link to the hotfix KB article: http://support.microsoft.com/kb/959202

Teradata/SSAS 2005 - Functionality and Performance Testing White Paper Now Available

jbasilico — Wed, 16 Jul 2008 22:43:00 GMT

Expanding upon the previous posts regarding SSAS 2005 functionality and performance testing with TD v12.0, a white paper I co-wrote on the topic has recently been made available up on Microsoft's Global ISV "Connector" site for Teradata (http://www.microsoft.com/isv/teradata/default.aspx). Here's the link to download the thirty page paper: http://download.microsoft.com/download/e/7/7/e77e1cc3-8922-4942-8f6b-1f35e2382a02/Functionality%20and%20Performance%20Testing%20SSAS%202005%20with%20Teradata%20v12.pdf. Enjoy!

Using SAP Data with Microsoft's BI Tools

jbasilico — Tue, 08 Jul 2008 20:31:00 GMT

I often get asked by organizations how they can leverage their SAP "data" investment against the Microsoft Business Intelligence suite of tools. The set of questions usually falls into one of these four categories:

Ability to extract data directly from SAP R/3 modules for later reporting and analysis.
Ability to extract data directly from SAP NetWeaver® BI (SAP BW) for later reporting and analysis.
Ability to report directly off SAP NetWeaver® BI (SAP BW) data with Microsoft BI tools.
Ability to leverage Excel directly against SAP NetWeaver® BI 7.0 without BEx.

Well, the stock answer usually goes something like this:

Microsoft Business Intelligence (BI) provides easy-to-use, certified access to SAP data to help you make better, more informed decisions. With Microsoft BI, you can use the familiar tools in Microsoft SQL Server 2005 and the 2007 Microsoft Office system environment to create, analyze, and share your own reports and BI dashboards from all sources.

Using Microsoft SQL Server and Office SharePoint Server 2007, teams across your organization can collaborate on information coming from both the SAP and Microsoft environments to ensure everyone is on the same page when it comes to analyzing results and making critical business decisions.

Finally, our strategic relationship with SAP has gone commercial with the launch of Duet, our jointly developed product that allows you to easily and quickly interact with your SAP and Microsoft Office environments. For more information on Duet, visit the Duet for Microsoft Office and SAP page (http://www.microsoft.com/isv/sap/technology/duet.aspx).

Ok...but what does that translate into in terms of architecture and implementation choices? Glad you asked. :-)

Here's the high level architecture on how Microsoft interacts with SAP data (at least as of today, July 8th 2008).

Implementation of data extracts from SAP R/3
SQL Server 2005 includes support for accessing SAP data by using the Microsoft .NET Data Provider for mySAP Business Suite (see this link for more details: http://msdn.microsoft.com/en-us/library/cc185434.aspx). This provider lets you create a package that can connect to a mySAP Business Suite solution and then execute commands on the server. You can also create Reporting Services reports against a SAP server. The Microsoft .NET Data Provider for mySAP Business Suite is tested on SAP R/3 versions 4.6C and higher. Earlier versions of SAP R/3 are not supported.

You can use the Microsoft .NET Data Provider for mySAP Business Suite in the SQL Server Import and Export Wizard, the Script task, the DataReader source, and the Script transformation that Integration Services provides, as well as the data processing extensions in Reporting Services.

You must provide a select query to specify data to be imported. The query must confirm to the semantics supported by the Data Provider for SAP. For more information about the grammar for a SELECT query for the Data Provider for SAP, see Syntax for a SELECT Statement.

Once data is extracted out of SAP R/3, the destination of that data could be any relational database (such as SQL Server), and then reports (from SSRS) and multi-dimensional cubes (from SSAS) can be created from that database data. The resulting SQL Server reports/cubes could then be used within the Microsoft Business Intelligence delivery mechanisms, such as through Excel, SharePoint, PerformancePoint, etc.

Implementation of data extracts from SAP NetWeaver® BI (SAP BW) using Open Hub and SQL Server 2005 Integration Services
The SAP Open Hub service enables you to distribute data from an SAP BI/BW system into external data marts, analytical applications, and other applications. With this, you can ensure controlled distribution using several systems. The central object for the export of data is the InfoSpoke. Using this, you can define the object from which the data comes and into which target it is transferred, leveraging SQL Server Integration Services (SSIS) as the transfer/transform mechanism.

SAP BI objects such as InfoCubes, ODS objects, or InfoObjects can act as open hub data sources. You can select database tables or flat files as open hub destinations, and then use those destinations as actual sources within SSIS. To automate the extraction using SAP’s Open Hub Service, you’ll need to setup a process chain. Note that both a full and delta modes are also available as the extraction mode.

As stated already with direct extraction from SAP R/3, once data is extracted out of SAP NetWeaver® BI (SAP BW), the destination of that data could be any relational database (such as SQL Server), and then reports (from SSRS) and multi-dimensional cubes (from SSAS) can be created from that database data. The resulting SQL Server reports/cubes could then be used within the Microsoft Business Intelligence delivery mechanisms, such as through Excel, SharePoint, PerformancePoint, etc.

Note that SQL Server 2008 Integration Services will include direct support for the NW BI 7.0 OHS - http://download.microsoft.com/download/1/7/5/175af735-edab-41db-b762-1b259ec5b362/Microsoft%20BI%20and%20SAP%20NetWeaver%20-%20SSIS.pdf.

Implementation for reporting against SAP NetWeaver® BI (SAP BW) data
Through a rich extensibility model, the report authoring and report deployment features of Microsoft® SQL Server™ Reporting Services 2005 can integrate with any number of business intelligence data sources. To answer the strong need for a rich reporting tool for SAP NetWeaver® Business Intelligence (SAP BW) and to bridge the gap between these two powerful business intelligence platforms, Microsoft has developed a new .NET Framework data provider and query designer for SAP NetWeaver® Business Intelligence.

With the release of SQL Server 2005 Service Pack 1 organizations can now take advantage of SQL Server’s Business Intelligence (BI) capabilities such as Reporting Services on SAP BW Data without purchasing independent and expensive reporting solutions. SQL Server 2005 Reporting Services is now certified to run reports on SAP BW. Customers that already own or plan to purchase SQL Server 2005 SP1, will get two new components that provide support for reporting on SAP BW in the SP1 release:

• The 'Microsoft .NET Data Provider 1.0 for SAP NetWeaver® Business Intelligence’

• A new query designer to enable the creation of SAP-compatible queries for SAP BW

The new Microsoft .NET Data Provider 1.0 for SAP NetWeaver® BI is a standards based provider that uses standard internet protocols and XML for Analysis (XML/A) (an XML standard for Online Analytical Processing - OLAP) to communicate with the SAP server. The .NET provider enables users to directly access QueryCubes as well as InfoCubes and MultiProviders. Since XML/A support is built into SAP BW, SAP BW reports can be authored and developed using SQL Server 2005 Reporting Services regardless of which relational database SAP BW data is stored in. To significantly reduce bandwidth requirements and improve network performance, the Microsoft .NET Data Provider 1.0 for SAP NetWeaver® BI uses GZIP compression when communicating with the SAP BW server, enabling organizations to efficiently work with large XML documents. Security is essential for data integrity; and the Microsoft .NET Data Provider 1.0 for SAP NetWeaver® BI supports and leverages internet standards such as SSL. This enables the system to safely transmit data between your SAP BW server and SQL Server 2005, providing added protection to your essential business information.

The new custom built Query Designer enables you to rapidly build reports for SAP BW. The query designer builds SAP-compatible MDX queries to base your reports on and provides insight into cubes, cube meta-data, calculated members, functions and variables.

By connecting SQL Server 2005 SP1 Reporting Services to SAP BW data, SAP BW users can quickly and easily take advantage of the flexible, yet easy-to-use reporting capabilities of SQL Reporting Services without migrating their data to another platform. This new integrated solution makes it easy to create and manage reports on information inside any SAP BW Data Warehouse, empowering organizations to easily get important SAP business intelligence information to the people who need it. SAP BW report authoring now becomes easy-to-do, consistent and familiar using SQL Server 2005 Reporting Services. Plus, deploying and distributing reports becomes a simple one-step process that targets the Web as the reporting platform – viewing reports becomes as simple as clicking a hyperlink.

In order to use the provider, the following components must be installed:

· Microsoft SQL Server 2005 Reporting Services Service Pack 1 or later

· Microsoft .NET Framework 2.0

The provider has been developed for and tested against SAP BW 3.5. However, the provider should also be compatible with BW 3.1 and BW 3.0B servers that have been patched to a sufficient service pack level, described below.

· Support Package 30 for SAP BW 3.0B

· Support Package 24 for SAP BW 3.1

· Support Package 16 for SAP BW 3.5

· Support Package 10 for SAP NetWeaver® 2004s (BW 7.0)

For more information on using Reporting Services directly against SAP BW, follow this link: http://download.microsoft.com/download/4/7/a/47a548b9-249e-484c-abd7-29f31282b04d/UsingRSwithSAPNetWeaver.doc.

Implementation for reporting against SAP NetWeaver® BI 7.0 Using Excel (without BEx)
Users familiar with SAP’s BW or NetWeaver BI often are interested in native Excel integration with SAP’s business intelligence data. SAP only offered BEx Analyzer in the past…however some casual users weren’t interested in learning this Excel Add-on tool. Now with SAP NetWeaver® BI 7.0, Excel 2007 users can tap into the full power of SAP BI data from within the comforts of the native Excel 2007 environment.

More potential for SAP NetWeaver® BI

· SAP customers can deploy SAP NetWeaver®BI beyond the realm of classical BEx users

· Microsoft customers can continue working with Excel to leverage data from SAP NetWeaver®BI Warehouses

SAP supports the standard

· Microsoft Excel is a long established standard for reporting

· The Pivot Table is a fast and intuitive way to analyze data

· Microsoft Excel 2007 provides enhanced reporting and formatting features like “top n” analysis

Very simple prerequisites, full support

· SAP NetWeaver®BI 7.0 natively and fully supports Microsoft Excel 2007

· The prerequisites are described in Note 1134226

· No BExAnalyzer or SAP NetWeaver®BI training necessary

Trusted integration

· Microsoft Excel has been supported in the past with some known some limitations in areas like hierarchy handling or filtering

· The new native Microsoft Excel 2007 integration provides access to SAP NetWeaver®BI data in a reliable and trusted way

To learn more about this native Excel 2007 interaction with SAP NW BI, go here: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/8483.

Optimizing File Locations for Analysis Services 2005

jbasilico — Fri, 09 May 2008 16:37:00 GMT

The following techniques can help you to optimize the data files and temporary files used during processing:

· Place the Analysis Services data files on a fast disk subsystem.

The location of the data files is determined by the DataDir server property. To optimize disk access for querying and processing, place the Analysis Services Data folder on a dedicated disk subsystem (RAID 5, RAID 1+0, or RAID 0+1).

· If temporary files are used during processing, optimize temporary file disk I/O.

The default location of the temporary files created during aggregation processing is controlled by the TempDir property. If a temporary file is used, you can increase processing performance by placing this temporary folder on a fast disk subsystem (such as RAID 0 or RAID 1+0) that is separate from the data disk.

Object Promotion Process for Microsoft BI Objects

jbasilico — Tue, 15 Apr 2008 04:59:00 GMT

With Integration Services, Reporting Services, and Analysis Services, their respective business intelligence objects (packages, reports, and cubes) are designed through the Business Intelligence Design Studio (BIDS), which is really the Visual Studio shell incorporated with special SQL Server 2005 business intelligence project templates installed. Using BIDS, or Visual Studio 2005 with the BI templates installed, allows the developer to deploy the projects directly to a server environment. This works fine for a development environment where the developer most likely has access and permissions to deploy objects to the server, but what about Q/A, Beta (Test), and Production environments? Most likely, organizations do not want their developers impacting installed objects on their test and production environments…for obvious reasons. Therefore, a change management/object promotion process must be utilized against the business intelligence environment, allowing non-developer resources to quickly and easily deploy new object types.

Also of consideration is object versioning. When working with Visual Studio, there are multiple product options that allow versioning and check-in-check-out of project objects. From Microsoft, two products exists that enable versioning/checking object code, those being Visual Source Safe, and Team Foundation Server.

The process for deployment "object promotion" to non personal-development environments is accomplished through three different options:

1) Use BIDS/Visual Studio 2005 to open the project/solution, and then deploy the data sources and reports to the appropriate server. The project object allows for multiple configuration settings, and is an exposed set of properties that can identify development, QA, test, and product environment settings.

2) Use a scripting engine (for Reporting Services that scripting engine is RS.EXE, for Analysis Services it’s ASCMD, and for Integration Services it's DTUTIL) to develop a script that deploys, installs, and secures objects to a particular target server. (Note – There are several sample scripts that come with SQL Server 2005 for reference).

3) Use application interfaces to create a custom deployment tool. For example, the Reporting Services management web service endpoint (http://<Server Name>/ReportServer/ReportService2005.asmx?wsdl) could be used to accomplish the same deploy, install, and securing of Reporting Services objects that the RS.EXE scripting command implements.

Analysis Services 2005 Design Best Practices - Cubes & MDX

jbasilico — Wed, 02 Apr 2008 03:45:00 GMT

Once you have identified potential Analysis Services bottlenecks, and have made the proper adjustments to Analysis Services server properties and perhaps added more memory/CPU power to the server, the next phase is to look into tuning the OLAP cube design and the related MDX queries used against the cube.

The sections outlined below will give you best practice insight (that I've used during customer proof of concepts) for fine-tuning your cube and query design, thus making your OLAP cube as efficient as possible for queries being sent to it for results.

Cube Design Best Practices - Dimensions

· Consolidate multiple hierarchies into single dimension (unless they are related via fact table)

· Avoid ROLAP storage mode

· Use role playing dimensions (e.g. OrderDate, BillDate, ShipDate) - avoids multiple physical copies

· Use parent-child dimensions prudently

o No aggregation support

· Set Materialized = true on reference dimensions

· Use many-to-many dimensions prudently

o Slower than regular dimensions, but faster than calculations

o Intermediate measure group must be “small” relative to primary measure group

Cube Design Best Practices – Attributes/Hierarchies

· Define all possible attribute relationships!

· Remove redundant attribute relationships

· Mark attribute relationships as rigid where appropriate

· Use integer (or numeric) key columns

· Set AttributeHierarchyEnabled to false for attributes not used for navigation (e.g. Phone#, Address)

· Set AttributeHierarchyOptimizedState to NotOptimized for infrequently used attributes

· Set AttributeHierarchyOrdered to false if the order of members returned by queries is not important

· Use natural hierarchies where possible

Cube Design Best Practices – Measures

· Use smallest numeric data type possible

· Use semi-additive aggregate functions instead of MDX calculations to achieve same behavior

· Put distinct count measures into separate measure group (BIDS does this automatically)

· Avoid string source column for distinct count measures

Cube Design Best Practices – OLAP Partitions

· No more than 20M rows per partition

· Specify partition slice

o Optional for MOLAP – server auto-detects the slice and validates against user specified slice (if any)

o Must be specified for ROLAP

· Manage storage settings by usage patterns

o Frequently queried à MOLAP with lots of aggregations

o Periodically queried à MOLAP with less or no aggregations

o Historical à ROLAP with no aggregations

· Alternate disk drive - use multiple controllers to avoid I/O contention

· Remote partitions for scale out – VLDB

Cube Design Best Practices – Aggregations

· Define all possible attribute relationships

· Set accurate attribute member counts and fact table counts

· Set AggregationUsage to guide aggregation designer

o Set rarely queried attributes to None

o Set commonly queried attributes to Unrestricted

· Do not build too many aggregations

o In the 100s, not 1000s

· Do not build aggregations larger than 30% of fact table size (agg design algorithm doesn’t)

MDX Query Design Best Practices

· Use calculated members instead of calc cells where possible

· Use .MemberValue for calculations on numeric attributes

o Filter(Customer.members, Salary.MemberValue > 100000)

· Avoid using CalculationPassValue

o Rely on auto recursion resolution using scopes and assignments

· Avoid redundant use of .CurrentMember and .Value

o (Time.CurrentMember.PrevMember, Measures.CurrentMember ).Value can be replaced with Time.PrevMember

· Avoid LinkMember, StrToSet, StrToMember, StrToValue

· Replace simple calculations with computed columns in DSV

o Calculation done at processing time is always better

· Many more at:

o http://sqljunkies.com/weblog/mosha

o http://sqlserveranalysisservices.com

Performance Testing of Teradata v12 with SQL Server 2005 Analysis Services

jbasilico — Sat, 29 Mar 2008 05:56:00 GMT

Ok...here's part two of the Teradata v12 series.

The first blog entry was focused on highlighting a sequence of functionality tests that were recently concluded back in February 2008 against Teradata version 12 using SQL Server 2005's Analysis Services (and the latest beta v12 .NET Provider from Teradata.)

This follow-up blog entry will focus on the benchmarking result efforts (up to 1000 simulated users) of queries against Analysis Services. What was recorded was average response time per SSAS query using a Teradata backend source, comparing response times when Teradata v2R6.2.1.3 is used and v12 is used (both using the v12 .NET Provider).

Background

The testing focused on optimizing the Project REAL Toolkit data warehouse with a goal of identifying the optimal concurrent workload for sub-second response time and indentifying best practices for a ROLAP environment.

Database preparation was the first step, and scope of that effort was as follows:

Migration of the Project REAL sample data kit to a Teradata system provided by Teradata.
Identify an appropriate database schema for Project REAL analytics based on the POC objectives.
Redesign the Project REAL solution into a Snow-Flake schema to more effectively take advantages of Teradata optimization capabilities.
Grow the data to 100GB.
Tune the Teradata system for the user load.

For conducting the testing effort, we focused on the following:

Functionality testing of Analysis Services running against Teradata v12 .NET Provider and v12 Database Engine (aka, the first blog entry in this series).
Test script preparation leveraging Visual Studio Test Suite for Testers.
Benchmark and optimize the Project REAL solution for user load against TeraData v2R6.2.1.3 using the new Teradata v12 .NET Provider.
Database migration from Teradata v2R6.2.1.3 to Teradata v12
Benchmark and optimize the Project REAL solution for user load against TeraData v12 using the new Teradata v12 .NET Provider.

Test Results

The successful execution of the engagement resulted in the following benchmark results (which was based on SQL Server 2005 Analysis Services SP2, Update 3175 applied):

Ran various user loads up to 1000 users with response times less than 1.2 second for tests against the Teradata v2R6.2.1.3 engine using the v12 .NET Provider.
Ran various user loads up to 1000 users with response times less than 0.93 second for tests against the Teradata v12 engine using the v12 .NET Provider.

Test Environment

The hardware configuration used for the testing was as follows:

Analysis Services System:

DELL two socket, quad-core system (eight total processor cores) with 1.86 GHz Intel Xeon and 4GB RAM
1 TB drive - The Analysis Services System does not require disk storage space for a ROLAP storage deployment. In a Teradata scenario, a best practice is to store the dimensions as MOLAP as a result an insignificant amount of disk space was used.
Windows 2003 Server X64
SQL Server 2005 x64 SP2 (patch level 3175)

Note that besides Analysis Services, SQL Server's RDBMS and the Visual Studio Team Suite Testing tool also ran on this server. On average, only 25% of server resources were available to SQL Server Analysis Services for the tests - which certainly reduced the overall performance of Analysis Services capabilities. However, this benchmarking test was a comparison of TD v2R6.2.1.3 to TD v12...so it didn't matter that resources were consumed by other services...since the benchmarking tests were resource and query "apples to apples" similar.

Teradata System:

4-Node Teradata 5500 system running database v2R6.2.1.3, which was also then upgraded to v12.

Disks: RAID1 with 96 x 73GB disks

Each node has:

12 AMPs and 2 PE's
4 CPU's @ 2.66Ghz

Functionality Testing of Teradata v12 with SQL Server 2005 Analysis Services

jbasilico — Wed, 27 Feb 2008 05:52:00 GMT

This blog will be a two part series…culminating from my recent internal testing of Analysis Services with Teradata v12.

The first blog entry in this series will be focused on highlighting a sequence of functionality tests that were recently concluded against Teradata version 12 using SQL Server 2005’s Analysis Services (and the latest beta v12 .NET Provider from Teradata.)

The second entry in this series will focus on the benchmarking result efforts (up to 1000 simulated users) of queries against Analysis Services. What was recorded was average response time per SSAS query using a Teradata backend source, comparing response times when Teradata v2R6.2.1.3 is used and v12 is used.

The successfully completed series of functionality tests used an Analysis Services 2005 “Post-SP2” (build 3175) instance connected to Teradata v12 for functionality testing. Using this Post-SP2 build is critical, since this SSAS SP2 doesn’t contain Teradata support. You can find information for this Post-SP2 build here: http://support.microsoft.com/kb/936305/.

The functionality tests included the following areas:

· Ability to create an Analysis Services Data Source View (DSV) against Teradata v12 using the .NET Provider for Teradata v12.

· Ability to process Analysis Services dimensions and cubes which were sourced from Teradata v12 using the .NET Provider for Teradata v12.

· Ability to query Analysis Services ROLAP cubes that are created against Teradata v12 using the .NET Provider for Teradata v12.

· Ability to execute reports from Reporting Services 2005 which have their data source defined against Analysis Services cubes that have Teradata v12 data using the .NET Provider for Teradata v12.

· Ability to execute reports from Reporting Services Report Builder 2005, whereby the Report Model was generated from an Analysis Services 2005 ROLAP cube that has its data source connected to a Teradata v12 database using the .NET Provider for Teradata v12.

I’ll be posting benchmark results during mid-March for those that are interested in seeing comparative Analysis Services query response time numbers between Teradata v2R6.2.1.3 versus Teradata v12 backend data sources.