Microsoft SQL Server Development Customer Advisory Team : Resource Utilization

How to warm up the Analysis Services data cache using Create Cache statement?

Nicholas Dritsas — Thu, 26 Apr 2007 12:55:00 GMT

Goal

This document describes how to build Create Cache commands. Create Cache for Analysis Services (AS) was introduced in SP2 of SQL Server 2005. It can be used to make one or more queries run faster by populating the OLAP storage engine cache first.

Some customers have found certain queries benefit other later queries. For example, ascmd.exe could be used every hour to execute all queries in a directory keeping the cache ready for subsequent user queries. The other approach, which has been used, is to create a cache query for each user query. This is feasible if the MDX query is part of a report, then one simply adds another query that has the side effect of populating the cache, thereby speeding up the next query.

The root of the problem is that during a query, the AS Server does only local optimizations. Calculations, mixed granularities, and other more complex MDX statements can result in a chatty communication between the FE (Formula Engine) and the SE (Storage engine). In AS2000 and earlier, this was also a network round trip.

By issuing a cache statement, we can populate the cache with one or more subcubes that cover the regions of cube space that the query will actually need. We often find approximately the same time taken for each subcube query, so the effect can be dramatic overall.

With this methodology, the collection of MDX queries will appear as first executing inside the storage engine, and second inside the formula engine. In addition to reducing overall time, this can make it easier to predict the effect of multi-user load testing, because the first part uses 100% of all CPUs, and the second part uses 100% of one CPU.

Summary Steps

It is an iterative process. I would describe the identification of potential scenarios where create cache would help:

Run profiler
Run the query looking for Non-cache SE queries (query subcube filtered by subevent = 2)
Look at the total time of the query vis-à-vis of the sum of the times of the non-cache SE queries.
If:

They are pretty close and
There are many non-cache SE queries within the same range of time (not just 1 or 2 time consuming)

then create cache might help.

There could be variations, but here are one set of steps that have been used successfully:

1. Extract all MDX queries as separate files.

2. Add a Create Cache statement to correspond for every MDX query file.

3. Run Clear Cache, Create Cache, then the user query.

4. Verify that the Create Cache is effective and improve, if necessary.

5. Work on next query

6. When done with all queries, combine the Create Cache into 1 or more Create Cache queries.

7. Verify the combined Create Cache.

Detailed Description

Below are details about each of the steps.

1. Extract MDX queries as separate files

Placing the queries in separate MDX files, it can be faster to work one by one and verify if each query is handled correctly by Create Cache before moving on.

1. Start a trace.

2. Run the report.

3. Stop the trace.

4. Extract the queries. One way is with SQLProfiler, /File /Export /Extract SQLServer Analysis Serverices Events / Extract All Queries. This creates a text file, with each query on a separate line. When queries have multiple lines this might be confusing, but is easy to add an extra line or otherwise edit. Either copy each query to a separate file, or, for every query that is being worked on, comment out the other queries.

2. Add Create Cache for every MDX query

Below is an example of a Create Cache statement.

create cache

for [MyCube]

as (

{ [USA].[Oregon], [USA].[Colorado], [USA].[Florida], [USA].[Washington] }

* { [Measures].[mybasemeasure] }

* { [2006].children, parallelperiod( [Time].[Year], 1, [2006].[Q1].[Jan] ), YTD( parallelperiod( [Time].[Year], 1, [2006].[Q1].[Jan] ) ) }

* { [Products].[Shoes].children }

)

It should be apparent that it is basically a crossjoin of each dimension member that is specified in the query. Note that set expressions are allowed.

2.a. Add Specified Members

First add all members specified in the query. NOTE: Create Cache covers static analysis rather than dynamic. MDX with dynamic members will not benefit from this approach.

2.b. Add Calculated Members and Definitions

During execution, the Formula Engine can issue a subcube query which includes calculated members.

For example, if the cube has a calculated member:

[MyDim].[Calc123] as [MyDim].[A] + [MyDim].[B]

one should include the following members in Create Cache:

[MyDim].[A], [MyDim].[B] }

2.c. Account for Custom Rollups

During execution, there may be custom rollups that affect the calculation. For example, a custom rollup may involve QTD() or YTD(). This might be hard to detect since the actual calculations are stored in the relational database. Custom rollups can be viewed from BI Development Studio. The dimension must be processed (otherwise the calculations still only exist on the relational database).

1. Go to Solution Explorer, double-click on the dimension you want to examine.

2. Click on the Browser tab.

3. Find the icon for Member Properties, click on it. Select "Custom Rollup", "Custom Rollup Properties".

4. It will display the Custom Rollup (formula) and other properties (such as solve order) for each member.

For example, if calculations include YTD or PeriodsToDate, the member list should account for that. So, if the query includes:

[Date].[2006].[June],

ParallelPeriod( [Date].[2006].[June], [Date].[Year], -1 )

YTD( [Date].[2006].[June] )

the only calculations resulting in output are [Date].[2005].[June], [Date].[2006].[Jan] ..[Date].[2006].[June]. However, because of indirect relationships, you should also add the member set:

YTD( ParallelPeriod( [Date].[2006].[June], [Date].[Year], -1 )

3. Run Clear Cache, Create Cache, User Query

Now, it is time to run the Clear Cache statement and examine its effect. Note that the Cube ID can be specified or left blank to clear the entire database cache entries.

<DatabaseID>FoodCmp</DatabaseID>

<CubeID>SalesCube</CubeID>

</Object>

</ClearCache>

</Batch>

3.a. Connection string parameters

We recommend these parameters to be added at the connection string.

Provider=msolap.3;Datasource=MyServer;Initial Catalog=MyDatabase;Timeout=300;Disable Prefetch Facts=true;Cache Ratio=1

Provider: The name of the OLE DB provider, msolap.

Datasource: The name of the server. Might be named instance like MyServer\MyInstance.

Initial Catalog: The name of the database to use.

Timeout: Optional number of seconds for command timeout. This can help to avoid very long runs until the queries are optimized to run faster.

Disable Prefetch Facts: Optional new parameter to disable the Formula Engine heuristic that sends queries for possibly more data than it is requested.

Cache Ratio: Optional parameter to control the conversion from a specified set of members to the subcube query sent to the SE Storage Engine. Use 1 to send only the specified list.

3.b. Ways to Execute Queries

Because the connection string needs to be modified, SQL Server Management Studio cannot be used. There are several alternatives:

1. One could write a small program in C#.

2. ascmd.exe can execute queries and output time. The ascmd utility is part of the Yukon Samples kit – located here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=e719ecf7-9f46-4312-af89-6ad8702e4e6e&DisplayLang=en

Then look in the C:\Program Files\Microsoft SQL Server\90\Samples\Analysis Services\Administrator\ascmd folder.

3. Use the mdx sample app from AS2000.

4. Verify Create Cache is Effective

The goal of using Create Cache is to isolate the storage engine and formula engine work and prevent the user query from executing subcube commands. The SE is multi threaded when the FE is single threaded. Therefore, one can just use Task Manager to verify if the SE is running.

During a good run, initially all the CPUs are at 100% since the SE is busy with the Create Cache command. Then, only one CPU reaches 100% because the FE is busy with the formulas and preparing the result set.

Task Manager is the general way to verify, but to be sure, create a trace and look for event Query Subcube, subevent 2 Non Cache. The cache subcube queries are fast and generally not an issue for AS. (In fact it shows how effective it is to create a cache first.)

4.a. Improve, if necessary

If the user query results in Task Manager CPU spikes (caused by subcube queries), one only needs to determine which members from the main query are not present in the Create Cache statement.

It might be helpful to look at trace information for Query Subcube Verbose. It might be that by comparing the ones for the Create Cache with the ones for the user query, some differences can be seen, and that could help discover which members should be added to the Create Cache query.

Another approach is to simplify the query until the problem does not happen. Try to use binary search to find the critical part of the user query that causes the extra subcubes.

4.b. Eliminate All Subcubes

This general technique works well when one can eliminate all subcubes. However, it might not be possible to know the set of members in advance (static analysis). If this is not true, for instance for complex calculations, then the Create Cache technique might not be as beneficial. Adding members that are not used can be cheap in some cases, for example to add one more product in an already large specified set. Or it might be expensive, for example to include another large set of data that otherwise would avoid entire partitions. One will need to experiment and measure the result, and because sometimes it will be a win and sometimes a loss, we recommend considering several user parameters.

5. Work on Next Query

6. After working with all the main queries, combine the Create Cache into 1 or More Create Cache statements

The best number of Create Cache queries depends on their structure (which dimension members involved, which measure group) and member sets.

1. Different measure groups should be separated unless the dimension members are consistent. Then, it is just a matter of convenience to combine, since under the covers the measure groups are physically separate.

2. If one query is covered or almost covered by another one, they should be combined.

3. If queries are disjoint or mostly disjoint, keep separate.

We have not experimented greatly, but here is one suggestion. Execute both scenarios, as separate and combined. Measure execution time and size of resulting DataCache (from perfmon counter). Use single combined Create Cache if the combination reduces time to 67% of separate commands and consumes space less than 3 times as much as separate.

7. Verify the combined Create Cache

Execute all queries, in this pattern:

1. Clear Cache

2. Create Cache (possibly many queries)

3. User queries

Verify the set of queries in the same way as each single query.

Contributors:

Eric Jacobsen

Cristian Petculescu

SSAS Partition Slicing

Eric Jacobsen — Tue, 06 Mar 2007 01:10:00 GMT

Summary:
SSAS uses partitions to contain cube data. Small cubes might use only one, but for non trivial cubes, cube designers will create partitions based on ease of managing data and to split groups of data. This document discusses how the server uses "slices" to examine partitions at query time. The slices are stored as a range of internal surrogate keys, and can be thought of as a very high level index.

Using more attributes in the partition definition can potentially improve performance by the ability to exclude partitions. To benefit user queries successfully requires some consideration of the internal way partition slices are used. Note that even though slices might not exclude partitons, we still expect the map indexes to be efficient at retrieving only neccessary data.

Slice description:
By "slice" we mean one or more members that limit the multidimensional space. Queries may have a "slice" as a result of including a set of members on an axis, or by placing members or a set in the where clause. Query slices are always a finite set of members. The formula engine may decompose MDX queries into many storage engine queries, which have a simple specification of granularity of each attribute, and a set of slices that limit the contents.

Cube partitions each have a slice for each attribute. This slice is either set by the administrator as part of the partition definition, or for MOLAP partitions is created during creation of the bitmap index for the partition. There is one slice per attribute in the partition. (Similarly there is one bitmap index per attribute in the partition.) Because the server automatically discovers the slice it is sometimes referred to as the "auto slice".

The partition slice value is stored in a file in the partition directory, with the name "Info.*.xml". The information stored is the minimum and maxiumum member IDs that are present in the partition, for each attribute. The member IDs are internal to the olap server, and are basically surrogate keys, created as a contiguous set of 32-bit integers starting with 1. This can have an impact when considering the min/max range way that partitions are created. It might be beneficial to change the SQL query for the dimension attributes so that the order in which attributes are returned matches the partitioning slicing scheme. Then the alignment of the internal surrogate keys helps the server at query time eliminate some partitions from being considered. See below the section Design Example.

The slice is created during index creation. Index creation is controlled by the number of rows, specified in the config file as <IndexBuildThreshold>, with a default of 4096. Partitions with fewer rows will not have indexes built -- and therefore will not have an "auto slice".

Optimal Number and Size of Partitions

There is not necessarily an optimal number or size of partitions, but some general guidelines exist. In Analysis Services 2005 Performance Guide (see link below), we suggest at most about 2000 partitions, and maximum of about 2 GB or 10-15 million rows in size. Some sites successfully use much larger partitions. For number of partitions, too few can miss opportunities to use slicing or can cause larger time windows for processing. Too many partitions might take more work to manage, cause some slowdowns of operations during processing (improved after SP2 was released), and can slow service startup time due to many more files on disk. Too small partitions might not offer any benefit. Too large partitions might increase the time window for processing past what is available.

Query Time Behavior

During query time all partitions are scanned for possible inclusion, by checking the query slices and partition slices for intersection. This is sequential, but is fast because it involves only integer range comparisons. Partitions that are included will be queried in parallel, and partitions that are excluded are not touched further.

There are SQLProfiler trace events for each partition that is used. Which trace event depends on whether the fact table or an aggregation, and each partition could have a separate aggregation definition.

Troubleshooting Information

It is important for very large cubes that a partition is not touched unless the query depends upon it. The information generally used to troubleshoot is:

Trace event Query Subcube Verbose. Check to see which attributes have slices.
Info.*.xml file, located in the partition. Make sure slices are defined for the attributes used in the query.
Trace events, can be used to check which partitions are being used. See below.

In SSAS2005 SP2 and earlier, the following behaviors may have a negative impact on the number of partitions touched.

Aggregations having fewer than <IndexBuildThreshold> rows are not excluded based on slice, even if a slice range exists for the fact table data. One possible work around is to lower the value of the <IndexBuildThreshold> configuration parameter in the server configuration file. However, this is not recommended as it may result in a large number of additional indexes, slowing processing performance.
Queries using "OR" slices do not use partition slices. The OR slice can be identified by a "+" in the trace event Query Subcube Verbose.

Both of these issues are expected to be addressed in a future Analysis Services release.

Trace Events

These are the relevant trace events to examine.

Query Subcube Verbose. This trace event is emitted after the internal storage engine subcube query has completed. The duration shows the total time for creating the datacache. Note that a query will only have one occurring at a time, and many partitions can be read from concurrently. So the start and end times will not overlap other Query Subcube Verbose events. Here is an example part of the output.

D:3 (Time) [1 8 52 * 0 0 0 0 0] => ((All)):[All] (Season):[Winter 2007] (Period):[JANUARY_2007] (Week):* (Day):0 (Dimdate):0 (Year):0 (Half):0 (Qtr):0

The numbers in square brackets [1 8 52 * 0 ...] have these meanings:

Single number - The internal surrogate key ID for the member participating in the slice. Note that the first element is often the All level, which by definition only has 1 member, and therefore its ID will always be 1. The member name is displayed.

'*' - The answer must have granularity for this attribute, and all members are used. There is no slice on this member.

0 - The answer should not include granularity for this attribute.

'+' - A slice is defined with more than 1 member. This is sometimes called an "OR" slice, because the equivalent SQL query would be of the form: where city = 'Seattle' or city = 'Redmond'. The list of members is not displayed. For simple MDX queries it is sometimes possible to infer the list.

Query Subcube. This trace event is not as readable for a human as Query Subcube Verbose. The format is a bitmap of attribute granularities, with dimensions delimited by a comma (",").

The same format of information is emitted by the Get Data From Aggregation trace event, and is also inserted into the QueryLog relational database table, if enabled in the configuration file. You can cut and paste this string directly into the AggManager sample to help create aggregations that match your queries, without or in addition to using the QueryLog relational table. (We wish to point out the format can be transferred -- not to suggest creating aggregations by just cutting and pasting. Designing the set of of aggregations is beyond the scope of this document.)

TextData from Query Subcube event : 00000000,000000000000000000000000,01110000

In this example, there are 3 dimensions, and the query only has granularity on attributes in the 3rd dimension. (Which for this example happened to be the Time dimension.)

Get Data From Aggregation. This trace event is emitted when reading from a partition, in an aggregation (not from the lowest level fact data). It is not emitted if the partition can be excluded based on the partition's "auto slice".

Note that the start and end time will typically overlap the start end end time of other events, because storage engine reads partition data in parallel, and the time will be contained within the time range for Query Subcube and Query Subcube Verbose.

The ObjectPath trace column tells what partition is being read. Note that Query Subcube and Query Subcube Verbose also have ObjectPath, but are missing the partition information since the query represents the union of all its partitions. The format is as follows. Note that for named instances the server name might be of the form MachineName\ServerInstanceName.

ServerName . DatabaseID . CubeID . MeasureGroupID . PartitionName

The TextData column contains the name of the aggregation used and the list of attribute granularity for the aggregation used. It will always "cover" (be larger than) the granularity of the Query Subcube. Here is an example:

TextData from Query Subcube event : 00000000,000000000000000000000000,01110000

TextData from Get Data From Aggregation event: Aggregation 1 00000000,000000000000000000000000,01110111

Progress Report Begin, Progress Report End These trace events are emitted when reading from a partition, in the fact data (not from an aggregation). It is not emitted if the partition can be excluded based on the partition's "auto slice".

The ObjectName trace column tells what partition is being read. The TextData column also tells the same information. Here is an example:

TextData from Progress Report Begin event : Started reading data from the 'MyPartitionName' partition.

Example of Partition Slice Information

The exact MDX query is unimportant, so we will just look at the Query Subcube Verbose and some partition information.

Query Subcube Verbose, from SQLProfiler trace:

Dimension 0 [Location] (0 0 0 0 0 0 0 0) [Dimlocation]:0 [Chain]:0 [Division]:0 [Region]:0 [Area]:0 [Store]:0 [Location Type]:0 [Grouped Stores Ind]:0
Dimension 1 [Product] (0 2 2 14 137 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0) [Dimproduct]:0 [Company]:[C SAMPLE] [Brand]:[B 1 SAMPLE] [Group]:[G 105 SAMPLE] [Dept]:[D 1125 SAMPLE] [Category]:0 [Range]:0 [Style]:0 [Colour]:0 [Size 1]:0 [Size 2]:0 [Size]:0 [Season Ind]:0 [Replenishment]:0 [Clearance]:0 [RSP]:0 [Primary Supplier]:0 [Supplier Color]:0 [SKU]:0 [Size Indicator1]:0 [VPN]:0 [Sku Description]:0 [Latest Cost]:0 [Original RSP]:0
Dimension 2 [Time] (0 * * * + 0 0 0) [Dimdate]:0 [Week]:* [Period]:* [Season]:* [Day]:+ [Year]:0 [Qtr]:0 [Half]:0

The "0" means no granularity for that attribute.

The "*" means include granularity for that attribute, with all members.

The "+" means include granularity for that attribute, with a set of members.

A number means include granularity for that attribute, with one specific member. The number is the internal surrogate key.

This subcube query included a slice on a set of days. Though the set members are not included in the trace event, for the actual query the set of [Time].[Day] for this example was { 1465, 1466, ... 1492 }.

So we can expect for this query, that partitions slicing by [Product] or [Time] would be effective at reducing query time by using slice information as a high-level index and reducing the work for the query.

SQLProfiler Trace information:

For this example, aggregations were able to answer the subcube query. So the relevant trace events are Progress Report Begin, and Progress Report End. Here are the relevant columns for one trace event. (Note that in SQLProfiler, this is displayed horizontally as one row.)

EventClass: Progress Report Begin

EventSubclass: 14 - Query

TextData: Started reading data from the 'Aggregation 9' aggregation.

DatabaseName: Sample

ObjectName: Aggregation 9

ObjectID: Aggregation 9

ObjectPath: MyMachine.Sample.Sample SMDB.Fact Sales SKU Store Day 0.Sales_W200639.Aggregation 9

Note that the partition name is part of the ObjectPath, a trace column that is disabled by default.

Here is a subset of info.*.xml for a customer partition year 2005 week 36. We can see that if the query slice contains any of the Product or Time properties, partitions should be excluded. Note that some ranges are narrow (few members), and some ranges are broad. For example, the range for [Product].[Colour] is 2...736, which is not surprising since the product sold in this week probably contains every color. If there was a goal of partitioning also by color or some other product attribute, that would help queries that sliced by that attribute.

For the example query subcube, we expect it to be excluded based on [Time].[Day]. For this example, it actually was excluded due to the set of days not in the inclusive range 1101...1107 for the property Day.

      <MapDataIndex>
        <DimensionID>Product</DimensionID>
        <PropertyID>ID Company</PropertyID>
        <m_MinIndex>2</m_MinIndex>
        <m_MaxIndex>2</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Product</DimensionID>
        <PropertyID>ID Brand</PropertyID>
        <m_MinIndex>2</m_MinIndex>
        <m_MaxIndex>2</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Product</DimensionID>
        <PropertyID>ID Group</PropertyID>
        <m_MinIndex>2</m_MinIndex>
        <m_MaxIndex>21</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Product</DimensionID>
        <PropertyID>ID Style</PropertyID>
        <m_MinIndex>22</m_MinIndex>
        <m_MaxIndex>325486</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Product</DimensionID>
        <PropertyID>ID SKU</PropertyID>
        <m_MinIndex>122</m_MinIndex>
        <m_MaxIndex>1307861</m_MaxIndex>
      </MapDataIndex>
        <DimensionID>Product</DimensionID>
        <PropertyID>Colour</PropertyID>
        <m_MinIndex>2</m_MinIndex>
        <m_MaxIndex>736</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Product</DimensionID>
        <PropertyID>Size Description1</PropertyID>
        <m_MinIndex>2</m_MinIndex>
        <m_MaxIndex>2205</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Time</DimensionID>
        <PropertyID>(All)</PropertyID>
        <m_MinIndex>1</m_MinIndex>
        <m_MaxIndex>1</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Time</DimensionID>
        <PropertyID>ID Season</PropertyID>
        <m_MinIndex>11</m_MinIndex>
        <m_MaxIndex>11</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Time</DimensionID>
        <PropertyID>ID Period</PropertyID>
        <m_MinIndex>39</m_MinIndex>
        <m_MaxIndex>39</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Time</DimensionID>
        <PropertyID>ID Week</PropertyID>
        <m_MinIndex>159</m_MinIndex>
        <m_MaxIndex>159</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Time</DimensionID>
        <PropertyID>ID Day</PropertyID>
        <m_MinIndex>1101</m_MinIndex>
        <m_MaxIndex>1107</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Time</DimensionID>
        <PropertyID>Dimdate</PropertyID>
        <m_MinIndex>1101</m_MinIndex>
        <m_MaxIndex>1107</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Time</DimensionID>
        <PropertyID>ID Year</PropertyID>
        <m_MinIndex>6</m_MinIndex>
        <m_MaxIndex>6</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Time</DimensionID>
        <PropertyID>Id Trdhalf</PropertyID>
        <m_MinIndex>8</m_MinIndex>
        <m_MaxIndex>8</m_MaxIndex>
      </MapDataIndex>
      <MapDataIndex>
        <DimensionID>Time</DimensionID>
        <PropertyID>ID Qtr</PropertyID>
        <m_MinIndex>14</m_MinIndex>
        <m_MaxIndex>14</m_MaxIndex>
      </MapDataIndex>

Design Example

In this example, it is known that for a cube, users often want to query for a particular city and time range. It is common to partition by time, and to improve query time, we can also partition by geographical region. For the real customer cube, there is one city that represents more than 50% of the records. So we want to create a partition that looks graphically something like this:

2001, BigCity	2002, BigCity	2003, BigCity	2004, BigCity	2005, BigCity
2001, OtherCities	2002, OtherCities	2003, OtherCities	2004, OtherCities	2005, OtherCities

Remember that improving query time is by excluding partitions, and that is done by ensuring discontiguous ID ranges. The IDs are surrogate keys created during dimension processing. So for this example, it is required that during dimension processing, the query for Country, Province, and City, will result in BigCity being either before or after the other cities (and provinces and countries). For example, if it is in the middle, we will get these ranges:

BigCity partition: MinIndex = 500, MaxIndex = 500

OtherCites partition: MinIndex = 1, MaxIndex = 1000

Therefore a query with slice on SmallCity with ID = 123 would exclude the BigCity partitions, but a query with slice on BigCity would not be able to exclude OtherCities partitons, and would take longer.

The preferred result is a set of exclusive ranges (without overlap). Thus a query with slice on BigCity will exclude 50% of the partitions, and a query with slice on SmallCity will exclude 50% of the partitions. This is optimal.

BigCity partition: MinIndex = 1, MaxIndex = 1

OtherCites partition: MinIndex = 2, MaxIndex = 1000

So we know the goal, and should check the info.*.xml files after processing, to ensure they form exclusive ranges, and check representative MDX queries, and check the Query Subcube Verbose trace events.

Ordering the rows during dimension processing can be done using a named query as the source of the dimension in the DSV. One could define a different named query for each attribute. There is a chance this could hurt performance of dimension processing if any operation needed a join. Another approach is to substitute a view for the dimension table, to perform the appropriate sorting. Note that at present we have not actually done this, but we believe this approach will work.

Further Reading

Analysis Services 2005 Performance Guide

http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SSAS2005PerfGuide.doc

AggManager, part of the SP2 samples.

http://www.microsoft.com/downloads/details.aspx?FamilyID=e719ecf7-9f46-4312-af89-6ad8702e4e6e&DisplayLang=en

[end]

Check out the exciting new SQL Server Best Practices website.....

thomasda — Sat, 09 Dec 2006 01:31:00 GMT

http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/default.mspx

Get the real-world guidelines, expert tips, and rock-solid guidance to take your SQL Server implementation to the next level. Drawing on the extensive experience and expertise from respected developers and engineers at Microsoft as they walk you through the specifics on solving particularly difficult issues.

Best SQL Server 2005 MDX Tips and Tricks - Part 1

Nicholas Dritsas — Thu, 12 Oct 2006 14:42:00 GMT

Overview

SQL Server’s 2005 Analysis Services has introduced several changes to the MDX queries syntax that can lead to better performance than the equivalent AS 2000 queries.

Here is a list of tips and tricks as well as best practices on how to get better performance from your MDX queries in AS2005.

Details

For filtering a set, use Filter inside Crossjoin vs the other way around

Filter a set and then use it in the Crossjoin. Filter function materializes the set and iterates through the set to check condition to build new set.

Avoid:

filter(NECJ({set1},{set2}),..)

Use:

NECJ(filter({set1},...),{set2})"

Use Rank() over Intersect() function to check if a member exists in a set

The disadvantage of using Intersect() to determine if a member exists in a set is because it treats the member as a set and can not use a better plan in the evaluator.

Avoid:

iif(intersect({ACTUALS_DAYS_SET},{[TIME DIM].[Time Main].currentmember}).count)>0

Use:

iif(rank([TIME DIM].[Time Main].currentmember, {ACTUALS_DAYS_SET})>0

Use Curly Braces in crossjoin with single member

When doing Crossjoins always use sets (add curly braces around single member if used in crossjoin).

Avoid:

Sum( [FINANCIAL VERSION DIM].[Financial Version].[Financial Version Type].&[WSLT]

*{[GROUP STATUS DIM].[Group Status].[Group Status Name].[cancel]

,[GROUP STATUS DIM].[Group Status].[Group Status Name].[turn down]},measure)

Use:

Sum(

{[FINANCIAL VERSION DIM].[Financial Version].[Financial Version Type].&[WSLT]}

*{[GROUP STATUS DIM].[Group Status].[Group Status Name].[cancel]

,[GROUP STATUS DIM].[Group Status].[Group Status Name].[turn down]},Measure)

Avoid unnecessary .CurrentMember in calculations.

It is not a good practice to use .CurrentMember when it is not required in the calculations. The formula engine can generate a better query plan if MDX does not use “.CurrentMember” to select the current member of a dimension. CurrentMember is implied and does not need to be explicitly included in the syntax.

No Need to use [TIME DIM].[Time Main].[Year].currentmember in the following MDX.

WITH

MEMBER [Measures].[M] as

'([TIME DIM].[Time Main].[Year].currentmember

,[FINANCIAL VERSION DIM].[Financial Version].[Financial Category].&[ACTL])'

select

{[TIME DIM].[Time Main].[Year].&[2005].members}

descendants([GROUP EVENT DIM].[Group Event].[Hotel].&[12]

,[GROUP EVENT DIM].[Group Event].[Group Event])}

Use Exists Function

Exists function should be used where ever possible instead of filter on member properties.

Avoid Lookup

Avoid using lookup function. Try to find out if the cube structure can be modified to have the measure available in the same cube.

Use Minus over Filter for a single member

When filtering out a single member from the set use minus over filter function

Avoid:

filter({set},.Currentmember <> "UNKN")

Use :

( {set} minus {&[UNKN] member})

Do not use calculated members that are constants

Although there may not be any difference for a simple example, when combined with other calculations, it can cause a more complicated execution plan inside the server. Note that when using parallelperiod function, often the function evaluates to a constant, so if it is known in advance that is preferred because the engine does not check for certain patterns that are known to be constant. It can be faster for a UI tool to send a first query to resolve parallelperiod (without other calculations), then substitute into the original query, rather than sending one more complicated query.

Avoid:

with

member [a].[NiceName] as '[a].[123]'

member [Time].[YearBefore] as 'parallelperiod( [Time].[year], 1, [Time].[2006].[jan] )'

select { [a].[NiceName] } on 0,

{ [Time].[2006].[jan], [Time].[YearBefore] } on 1

from [MyCube]

Use:

select { [a].[123] } on 0,
{ [Time].[2006].[jan], [Time].[2005].[jan] } on 1
from [MyCube]

How to check if the cell is empty?

Usually empty cell is checked for avoiding division by zero or for checking if value is missing (NON EMPTY analysis).

Check for non empty to avoid division by zero

For a/b calculations

IIF(b=0,NULL,a/b)

Empty cells are treated as zero in arithmetic operations.

For checking empty cells (Non Empty Analysis)

Filter([dimension].[hierarchy].member.members, isEmpty(dim.member))

This invokes MDX function IsEmpty, which, as the name suggests, checks whether cell value (in this case at coordinate b) is empty or not. Note, that if the cell value is empty, it is treated as number zero in arithmetic operations, however, it is possible, that b had value zero, which is not empty! Therefore check for IsEmpty is appropriate when the user wants to differentiate empty or missing values from the existing values (for example in NON EMPTY like analysis), but is not appropriate for checks in division by zero.

Note: Dot not ever use IS operator (ie: IIF(b IS NULL, NULL, a/b)) to check if the cell value is empty. The IS operator checks if the member b exists or not.

Miscellaneous design tips

Avoid assigning values like 0, Null, “N/A”, “-“ to cells that would remain empty otherwise. Use Format_String instead, for custom UI formatting of values.
Avoid redundant Sum/Aggregate calculations in situations where default/normal cell value aggregation would do.
Try to avoid IIF. If have to use IIF, see if it’s possible to write it in such a way that one of the branches (then/else) is written “null”.
Prefer using static literal hierarchy and member references (e.g. Measures.Sales instead of Dimensions(0).Sales, Product.[All] instead of Product.Members.Item(0) etc.).
Avoid using LinkMember, StrToSet, StrToMember, StrToValue.
Prefer using the new calculation Non_Empty_Behavior optimization hint instead of writing calculation expressions of the form Aggregate(NonEmptyCrossjoin(Descendants(…, Leaves) …).
If wanting to get the value of the current cell, consider using an explicit measure name instead of Measures.CurrentMember.
When writing calculation expressions like “expr1 * expr2”, make sure the expression sweeping the largest area/volume in the cube space is on the left side. For instance, write “Sales * ExchangeRate” instead of “ExchangeRate * Sales”, and “Sales * 1.15” instead of “1.15 * Sales”.
Consider replacing simple “Measure1 + Measure2” calculations with computed columns (additional measures) in the DSV or in the SQL data source.
Instead of writing expressions like Sum(Customer.City.Members, Customer.Population.MemberValue), consider defining a separate measure group on the City table, with a Sum measure on the Population column.

Author: Nicholas Dritsas

OLTP Blueprint - A Performance Profile of OLTP applications

thomasda — Fri, 23 Jun 2006 21:34:00 GMT

Performance and Tuning Blue Prints

We will look at different types of applications, how they use resources, and how one would approach performance tuning each. The performance profile of OLTP differs significantly from a Relational Data Warehouse or Reporting application. It is helpful to understand these differences and the objectives for high performance.

OLTP blueprint

For example, OLTP applications are characterized by high volumes of small identical transactions. These can include SELECT, INSERT, UPDATE and DELETE operations. The implications are significant in terms of database design, resource utilization and system performance.

OLTP Performance blue print objectives. There are performance problems if any of the following are true. Note: Actual value used in Value column can be debated.

Resource issue	Rule	Description	Value	Source	Problem Description
Database Design	Rule 1	High Frequency queries having # table joins	>4	Sys.dm_exec_sql_text, Sys.dm_exec_cached_plans	High Frequency queries with lots of joins may be too normalized for high OLTP scalability
	Rule 2	Frequently updated tables having # indexes	>3	Sys.indexes, sys.dm_db_operational_index_stats	Excessive index maintenance for OLTP
	Rule 3	Big IOs Table Scans Range Scans	>1	Perfmon object SQL Server Access Methods Sys.dm_exec_query_stats	Missing index, flushes cache
	Rule 4	Unused Indexes	index not in*	* Sys.dm_db_index_usage_stats	Index maintenance for unused indexes
CPU	Rule 1	Signal Waits	> 25%	Sys.dm_os_wait_stats	Time in runnable queue is pure CPU wait.
	Rule 2	Plan re-use	< 90%	Perfmon object SQL Server Statistics	OLTP identical transactions should ideally have >95% plan re-use
	Rule 3	Parallelism: Cxpacket waits	>5%	Sys.dm_os_wait_stats	Parallelism reduces OLTP throughput
Memory	Rule 1	Avg page life expectancy	< 300 (seconds)	Perfmon object SQL Server Buffer Manager SQL Server Buffer Nodes	Cache flush, due to big read Possible missing index
	Rule 2	Avg page life expectancy	Drops by 50%	Perfmon object SQL Server Buffer Manager	Cache flush, due to big read Possible missing index
	Rule 3	Memory Grants Pending	>1	Perfmon object SQL Server Memory Manager	Current number of processes waiting for a workspace memory grant
IO	Rule 1	Avg Disk seconds / read	> 20 ms	Perfmon object Physical Disk	Reads should take 4-8ms with NO IO pressure
	Rule 2	Avg Disk seconds / write	> 20 ms	Perfmon object Physical Disk	Writes (sequential) can be as fast as 1ms for transaction log.
	Rule 3	Big IOs Table Scans Range Scans	>1	Perfmon object SQL Server Access Methods	Missing index, flushes cache
	Rule 4	If Top 2 values for wait stats are any of the following: 1. ASYNCH_IO_COMPLETION 2. IO_COMPLETION 3. LOGMGR 4. WRITELOG 5. PAGEIOLATCH_x	Top 2	Sys.dm_os_wait_stats	If top 2 wait_stats values include IO, there is an IO bottleneck
Blocking	Rule 1	Block percentage	> 2%	Sys.dm_db_index_operational_stats	Frequency of blocks
	Rule 2	Block process report	30 sec	Sp_configure, profiler	Report of statements
	Rule 3	Avg Row Lock Waits	> 100ms	Sys.dm_db_index_operational_stats	Duration of blocks
	Rule 4	If Top 2 values for wait stats are any of the following: 1. LCK_x	Top 2	Sys.dm_os_wait_stats	If top 2 wait_stats values include locking, there is a blocking bottleneck

In summary, OLTP applications are comprised of high volumes of identical small transactions. They differ significantly in terms of resource usage as compared with other types of applications such as reporting or data warehousing. The blueprint above considers resources usage as a means of formulating a “performance profile” of a typical OLTP application.

For example, the high volumes of OLTP identical transactions mean plan re-use is desirable. CPU utilization can thusly be reduced with plan re-use and join reduction. IO performance can be improved with good indexing, join reduction, and high page life expectancy. Sorts can be limited with index usage. Blocking can be reduced with index design and short transactions.

The unique performance profile of OLTP provides guidance in terms of resource utilization, expressed in the blueprint above. While the specific values can be debated, the general concepts applicable to OLTP applications in terms of resource utilization and performance characteristics are valid.

enjoy,

Tom Davidson

How can SQL Server 2005 help me evaluate and manage indexes?

thomasda — Mon, 12 Dec 2005 18:43:00 GMT

SQLCAT Blog:

Question: How can SQL Server 2005 help me evaluate and manage indexes?

(1) How can I find out whether my indexes are useful? How are they used?

(2) Do I have any tables or indexes that are not used (or rarely)

(3) What is the cost of index maintenance vs. its benefit?

(4) Do I have hot spots & index contention?

(5) Could I benefit from more (or less) indexes?

Answer:

SQL Server 2005 Dynamic Management Views (DMVs) are important insofar as they expose changing server state information that typically spans many sessions, many transactions, and many requests. DMVs provide a level of transparency that was not available in SQL Server 2000 and can be used for diagnostics, memory and process tuning, and monitoring. The SQL Server engine tracks detailed resource history in DMVs that can be queriable with SELECT statements but are not persisted to disk. Thus DMVs reflect activity since the last SQL Server recycle.

Since indexes provide an alternative to a table scan, and because DMVs expose index usage counters, we can compare the cost vs. the benefit of indexes. This comparison will include the maintenance cost of keeping the index up to date, versus the benefit of reads e.g. when an index can be used in lieu of a table scan. Keep in mind that an update or delete operation involves both a read which is first required to determine whether a row qualifies for the update operation, and a write if a row is found to qualify. In an insert operation, only writes will be performed on all indexes. Consequently, in an insert-intensive workload, writes will exceed reads. In an update-intensive (updates and deletes) workload, read and write counts are generally close assuming there are not a lot of ‘records not found’. In read-intensive workloads, read counts will exceed write counts. Referential constraints such as foreign keys require other read activity (for inserts, updates, and deletes) to ensure referential integrity is maintained.

(1) How can I find out whether my indexes are useful? How are they used?

First, we will determine whether indexes are ‘useful’. DDL is used to create objects (such as indexes) and update the catalog. Creating the index does not constitute ‘use’ of the index, and thus the index will not be reflected in the index DMVs until the index is actually used. When an index is used by a Select, Insert, Update, or Delete, its use is captured by sys.dm_db_index_usage_stats. If you have run a representative workload, all useful indexes will have been recorded in sys.dm_db_index_usage_stats. Thus, any index not found in sys.dm_db_index_usage_stats is unused by the workload (since the last re-cycle of SQL Server). Unused indexes can be found as follows:

(2) Do I have any tables or indexes that are not used (or rarely used)?

------ unused tables & indexes. Tables have index_id’s of either 0 = Heap table or 1 = Clustered Index

Declare @dbid int

Select @dbid = db_id('Northwind')

Select objectname=object_name(i.object_id)

, indexname=i.name, i.index_id

from sys.indexes i, sys.objects o

where objectproperty(o.object_id,'IsUserTable') = 1

and i.index_id NOT IN (select s.index_id

from sys.dm_db_index_usage_stats s

where s.object_id=i.object_id and

i.index_id=s.index_id and

database_id = @dbid )

and o.object_id = i.object_id

order by objectname,i.index_id,indexname asc

Rarely used indexes will appear in sys.dm_db_index_usage_stats just like heavily used indexes. To find rarely used indexes, you look at columns such as user_seeks, user_scans, user_lookups, and user_updates.

--- rarely used indexes appear first

declare @dbid int

select @dbid = db_id()

select objectname=object_name(s.object_id), s.object_id, indexname=i.name, i.index_id

, user_seeks, user_scans, user_lookups, user_updates

from sys.dm_db_index_usage_stats s,

sys.indexes i

where database_id = @dbid and objectproperty(s.object_id,'IsUserTable') = 1

and i.object_id = s.object_id

and i.index_id = s.index_id

order by (user_seeks + user_scans + user_lookups + user_updates) asc

(3) What is the cost of index maintenance vs. its benefit?

If a table is heavily updated and also has indexes that are rarely used, the cost of maintaining the indexes could exceed the benefits. To compare the cost and benefit, you can use the table valued function sys.dm_db_index_operational_stats as follows:

--- sys.dm_db_index_operational_stats

declare @dbid int

select @dbid = db_id()

select objectname=object_name(s.object_id), indexname=i.name, i.index_id

, reads=range_scan_count + singleton_lookup_count

, 'leaf_writes'=leaf_insert_count+leaf_update_count+ leaf_delete_count

, 'leaf_page_splits' = leaf_allocation_count

, 'nonleaf_writes'=nonleaf_insert_count + nonleaf_update_count + nonleaf_delete_count

, 'nonleaf_page_splits' = nonleaf_allocation_count

from sys.dm_db_index_operational_stats (@dbid,NULL,NULL,NULL) s,

sys.indexes i

where objectproperty(s.object_id,'IsUserTable') = 1

and i.object_id = s.object_id

and i.index_id = s.index_id

order by reads desc, leaf_writes, nonleaf_writes

--- sys.dm_db_index_usage_stats

select objectname=object_name(s.object_id), indexname=i.name, i.index_id

,reads=user_seeks + user_scans + user_lookups

,writes = user_updates

from sys.dm_db_index_usage_stats s,

sys.indexes i

where objectproperty(s.object_id,'IsUserTable') = 1

and s.object_id = i.object_id

and i.index_id = s.index_id

and s.database_id = @dbid

order by reads desc

The difference between sys.dm_db_index_usage_stats and sys.dm_db_index_operational_stats is as follows. Sys.dm_db_index_usage_stats counts each access as 1, whereas sys.dm_db_index_operational_stats counts depending on the operation, pages or rows.

(4) Do I have hot spots & index contention?

Index contention (e.g. waits for locks) can be seen in sys.dm_db_index_operational_stats. Columns such as row_lock_count, row_lock_wait_count, row_lock_wait_in_ms, page_lock_count, page_lock_wait_count, page_lock_wait_in_ms, page_latch_wait_count, page_latch_wait_in_ms, pageio_latch_wait_count, pageio_latch_wait_in_ms detail lock and latch contention in terms of waits. You can determine the average blocking and lock waits by comparing waits to counts as follows:

declare @dbid int

select @dbid = db_id()

Select dbid=database_id, objectname=object_name(s.object_id)

, indexname=i.name, i.index_id --, partition_number

, row_lock_count, row_lock_wait_count

, [block %]=cast (100.0 * row_lock_wait_count / (1 + row_lock_count) as numeric(15,2))

, row_lock_wait_in_ms

, [avg row lock waits in ms]=cast (1.0 * row_lock_wait_in_ms / (1 + row_lock_wait_count) as numeric(15,2))

from sys.dm_db_index_operational_stats (@dbid, NULL, NULL, NULL) s, sys.indexes i

where objectproperty(s.object_id,'IsUserTable') = 1

and i.object_id = s.object_id

and i.index_id = s.index_id

order by row_lock_wait_count desc

The following report shows blocks in the [Order Details] table, index OrdersOrder_Details. While blocks occur less than 2 percent of the time, when they do occur, the average block time is 15.7 seconds.

It would be important to track this down using the SQL Profiler Blocked Process Report. You can set the Blocked Process Threshold to 15 using sp_configure ‘Blocked Process Threshold’,15. Afterwards, you can run a trace to capture blocks over 15 seconds.

The Profiler trace will include the blocked and blocking process. The advantage of tracing for long blocks is the blocked and blocking details can be saved in the trace file and can be analyzed long after the block disappears. Historically, you can see the common causes of blocks. In this case the blocked process is the stored procedure NewCustOrder. The blocking process is the stored procedure UpdCustOrderShippedDate.

The caveat with Profiler Trace of Blocked Process Report is that in the case of stored procedures, you cannot see the actual statement within the stored procedure that is blocked. You can capture the actual blocked statement of a stored procedure in realtime (as it is occuring) using the following:

create proc sp_block_info

select t1.resource_type as [lock type]

,db_name(resource_database_id) as [database]

,t1.resource_associated_entity_id as [blk object]

,t1.request_mode as [lock req] --- lock requested

,t1.request_session_id as [waiter sid] --- spid of waiter

,t2.wait_duration_ms as [wait time]

,(select text from sys.dm_exec_requests as r --- get sql for waiter

cross apply sys.dm_exec_sql_text(r.sql_handle)

where r.session_id = t1.request_session_id) as waiter_batch

,(select substring(qt.text,r.statement_start_offset/2,

(case when r.statement_end_offset = -1

then len(convert(nvarchar(max), qt.text)) * 2

else r.statement_end_offset end - r.statement_start_offset)/2)

from sys.dm_exec_requests as r

cross apply sys.dm_exec_sql_text(r.sql_handle) as qt

where r.session_id = t1.request_session_id) as waiter_stmt --- statement blocked

,t2.blocking_session_id as [blocker sid] -- spid of blocker

,(select text from sys.sysprocesses as p --- get sql for blocker

cross apply sys.dm_exec_sql_text(p.sql_handle)

where p.spid = t2.blocking_session_id) as blocker_stmt

from

sys.dm_tran_locks as t1,

sys.dm_os_waiting_tasks as t2

where

t1.lock_owner_address = t2.resource_address

exec sp_block_info

(5) Could I benefit from more (or less) indexes?

Remembering that indexes involve both a maintenance cost and a read benefit, the overall index cost benefit can be determined by comparing reads and writes. Reading an index allows us to avoid table scans however they do require maintenance to be kept up-to-date. While it is easy to identify the fringe cases where indexes are not used, and the rarely used cases, in the final analysis, index cost benefit is somewhat subjective. The reason is the number of reads and writes are highly dependent on the workload and frequency. In addition, qualitative factors beyond the number of reads and writes can include a highly important monthly management report or quarterly VP report in which the maintenance cost is of secondary concern.

Writes of all indexes are performed for inserts, but there are no associated reads (unless there are referential constraints). Besides select statements, reads are performed for updates and deletes, writes are performed if rows qualify. OLTP workloads have lots of small transactions, frequently combining select, insert, update and delete operations. Data Warehouse activity is typically separated into batch windows having a high concentation of write activity, followed by an on-line window of read activity.

SQL Statement	Read	Write
Select	Yes	No
Insert	No	Yes, all indexes
Update	Yes	Yes, if row qualifies
Delete	Yes	Yes, if row qualifies

In general, you want to keep indexes to a funtional minimum in a high transaction OLTP environment due to high transaction throughput combined with the cost of index maintenance and potential for blocking. In contrast, you pay for index maintenance once during the batch window when updates occur for a data warehouse. Thus, data warehouses tend to have more indexes to benefit its read-intensive on-line users.

In conclusion, an important new feature of SQL Server 2005 includes Dynamic Management Views (DMVs). DMVs provide a level of transparency that was not available in SQL Server 2000 and can be used for diagnostics, memory and process tuning, and monitoring. DMVs can be useful in answering practical questions such as index usage, cost benefit of indexes, and index hot spots. Finally, DMVs are queriable with SELECT statements but are not persisted to disk. Thus they reflect changing server state information since the last SQL Server recycle.

Partitioned Tables, Parallelism & Performance considerations

thomasda — Wed, 30 Nov 2005 19:17:00 GMT

Q: When querying SS2005 Partitioned Tables, what kind of parallelism should I expect to see and how will that affect performance?

A: First, a brief background on partitioning. SQL Server 2005 table partitioning provides many improvements in terms of manageability and availability. The manageability improvements allow metadata only switch-in and switch-out of a partition of data (supporting sliding window requirements). Availability improvements include online index rebuilds, parallel operations, and piecemeal restores of filegroups (see blog SQL Server 2005 OnLine Piecemeal Restore at http://blogs.msdn.com/sqlcat/archive/2005/10/27/485580.aspx).

Now let’s look at how performance is impacted by partitioned tables. Regardless of whether you are using partitioning, the selection of a parallel plan is determined by the number of CPUs, query cost, available memory and current workload. The remaining considerations outlined here are valid only if all of these allow using parallel plan.

When a query uses a single partition e.g. all but a single partition is eliminated, SQL Server 2005 Intra-Partition parallelism can parallelize row retrieval using multiple threads up to the sp_configure’d value of Maximum Degree of Parallelism (MAXDOP). Frequently, MAXDOP is set to the default of 0 which means MAXDOP is equal to the total number of CPUs. When a query spans two or more partitions, only a single thread per partition will be used to retrieve rows.

If your number of partitions is equal to MAXDOP or less, data skewing may cause some parallel threads to complete before others resulting in CXPACKET waits. In cases where the number of partitions exceeds MAXDOP, SQL Server 2005 on-demand parallelism means that when a thread completes its work on a partition, it will automatically start processing the next partition in line. Say you have 16 partitions and a MAXDOP of 8. The first 8 threads work on partitions 1-8. The first thread completed will start processing partition 9, the next, partition 10 and so on.

If you have big multi-proc box of 8 or more CPUs, the worst case query performance would be a single SELECT statement that spans two partitions (see Table 1). One thread per partition would be used to retrieve the rows (See Table 2 yellow highlight for partitions 80 and 81 & number of threads in Executes column) although MAXDOP can still be applied after row retrieval in subsequent steps (See Table 2 green highlights).

Table 1: Retrieve 2 weeks of data

SELECT

SUM(Sales_Qty) as Sales_Qty,

SUM(Sale_Amt) as Sales_Amount

FROM SalesDB.dbo.Tbl_Fact_ Sales – Partitioned by week

WHERE date_id between '20050703' and '20050716'

Table 2: Set Statistics Profile: MAXDOP = 12

Rows	Executes	StmtText
1	1	SELECT SUM([Sales_Qty]) [Sales_Qty],SUM([Sale_Amt]) [Sales_Amount] FROM [SalesDB].[dbo].[Tbl_Fact_Sales] WHERE [date_id]>=@1 AND [date_id]<=@2
0	0	\|--Compute Scalar(DEFINE:([Expr1002]=CASE WHEN [globalagg1008]=(0) THEN NULL ELSE [globalagg1010] END, [Expr1003]=CASE WHEN [globalagg1012]=(0) THEN NULL ELSE [globalagg1014] END))
1	1	\|--Stream Aggregate(DEFINE:([globalagg1008]=SUM([partialagg1007]), [globalagg1010]=SUM([partialagg1009]), [globalagg1012]=SUM([partialagg1011]), [globalagg1014]=SUM([partialagg1013])))
2	1	\|--Parallelism(Gather Streams)
2	12	\|--Stream Aggregate(DEFINE:([partialagg1007]=COUNT_BIG([SalesDB].[dbo].[Tbl_Fact_Sales].[Sales_Qty] as [ss].[Sales_Qty]), [partialagg1009]=SUM([SalesDB].[dbo].[Tbl_Fact_Sales].[Sales_Qty] as [ss].[Sales_Qty]), [partialagg1011]=COUNT_BIG([SalesDB].[dbo].[Tbl_Fact_Sales].[Sale_Amt] as [ss].[Sale_Amt]), [partialagg1013]=SUM([SalesDB].[dbo].[Tbl_Fact_Sales].[Sale_Amt] as [ss].[Sale_Amt])))
20577235	12	\|--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1006]) PARTITION ID:([PtnIds1006]))
2	12	\|--Parallelism(Distribute Streams, Demand Partitioning)
2	1	\| \|--Constant Scan(VALUES:(((80)),((81))))
20577235	2	\|--Index Seek(OBJECT:([SalesDB].[dbo].[Tbl_Fact_Sales].[IX_Tbl_Fact_Sales_SKDteItmStrIDSalQtySalAmtDiscMkd] AS [ss]), SEEK:([ss].[SK_Date_ID] >= (20050703) AND [ss].[SK_Date_ID] <= (20050716)) ORDERED FORWARD PARTITION ID:([PtnIds1006]))

For instance, suppose you have a TB-sized Sales table that is partitioned by month. A common query pattern may be to compare this month to last month, or perhaps this month to a year ago.

Table 3: MONTHLY Partitions

WHERE clause

Partitions

Retrieval Parallelism

Single SELECT statement

SELECT …. WHERE DateCol BETWEEN ’10/1/2005’ and ‘11/30/2005’

1 thread per partition *

SELECT

UNION SELECT

[UNION SELECT]

Select …. Where DateCol between ’10/1/2005’ and ‘10/31/2005

UNION

Select …. Where DateCol between ’11/1/2005’ and ‘11/30/2005

1 per select

MAXDOP per partition

Table 4: WEEKLY Partitions: Sales for November 1-15

WHERE clause

Partitions

Retrieval Parallelism

Single SELECT statement

SELECT SUM(Sales) from WKSales

WHERE DateCol BETWEEN ’11/1/2005’ and ‘11/15/2005’

1 thread per partition *

SELECT

UNION SELECT

[UNION SELECT]

SELECT SUM(Sales) from WKSales

WHERE DateCol BETWEEN ’11/1/2005’ and ‘11/5/2005’

UNION

SELECT SUM(Sales) from WKSales

WHERE DateCol BETWEEN ’11/6/2005’ and ‘11/12/2005’

UNION

SELECT SUM(Sales) from WKSales

WHERE DateCol BETWEEN ’11/13/2005’ and ‘11/15/2005’

1 per select

MAXDOP per partition

There are cases where big monolithic tables can provide better performance although manageability and availability can be challenging. For example, if you have a query that spans 2 partitions of a 1TB partitioned table, SQL Server 2005 can only apply 1 thread per partition while retrieving rows from each partition. In contrast, SQL Server 2005 can apply MAXDOP to retrieve rows from the monolithic version of the 1TB table (see Table 5).

Table 5: Monolithic BigSalesTable

	WHERE clause	Partitions	Retrieval Parallelism
Single SELECT statement	SELECT …. WHERE DateCol BETWEEN ’10/1/2005’ and ‘11/30/2005’	N/A	MAXDOP

Best Practices:

The above comments on partitions and parallel performance are most applicable to Data Warehouses, batch processing, and reporting. Not all data warehouse environments will want to enable parallelism for all queries. Specifically, parallelism is most effective if the system is running only a few queries at a time and you want as many resources possible made available to those queries to minimize execution time. If the data warehouse is already a high concurrency environment, parallelism will not improve throughput or response time since the collection of single-threaded queries are likely already consuming the available resources. Likewise, for peak performance, you do not want parallelism in a high concurrency OLTP workload.

When deciding upon a partitioning granularity (e.g. daily, weekly, monthly), consider your users’ common query patterns. Remember that for best parallel performance of a big multi-proc box of 8 CPU or more, you want your queries to maximize parallelism e.g. at least MAXDOP partitions. As illustrated in tables 3 & 4, performance boosts can be achieved if you have the luxury of rewriting SQL statement as a union of multiple single-partition queries.

In conclusion, for best parallel query performance with partitioned tables in SQL Server 2005, aim for either a single partition per SELECT statement (to get Intra-Partition parallelism), or MANY partitions (at 1 thread per partition) per SELECT statement.

Tom Davidson

SQL Server Customer Advisory Team

How do you measure CPU pressure?

thomasda — Tue, 06 Sep 2005 06:39:00 GMT

It is important to understand whether CPU pressure is affecting SQL Server performance. This is true even in the case where SQL Server is the only application running on a particular box. The System object Perfmon counter Processor Queue length is not necessarily an effective way of measuring CPU pressure in SQL Server. To see why this is the case, we first must take a brief (and simplified) look at the SQL Server Execution Model.

SQL Server uses a User Mode Scheduler (UMS) to control the execution of SQL Server user requests (SPIDs or session_ids). The UMS does not replace the Windows scheduler but rather, manages the execution of SQL Server requests (without returning control to Windows). So when SQL Server gets its time slice from the Windows scheduler, the SQL Server UMS manages what user requests are run during this time. In a 4-proc scenario, there will be 4 User Mode Schedulers, one for each CPU. Each UMS uses a number of constructs (queues, lists and worker threads) to govern execution. At any given time, each UMS will have at most a single running user, a runnable queue of requests that are waiting for CPU, a waiter list (for resources such as IO, locks, memory), and a work queue (user requests that are waiting for worker threads).

The runnable queue can be likened to a grocery analogy where there are multiple check out lines. The register clerk is the CPU. There is just one customer checking out e.g. “running” at any given register. The time spent in the checkout line represents CPU pressure. The longer the line, the longer the waits, hence more CPU pressure.

OK, back to SQL Server. Assume the following for a single UMS: SPID 51 is currently running. The Runnable Queue consists of SPIDs 60, 55, 87 & 79. The Waiter list includes SPIDS 55, 84 & 72. The Work queue is empty. Now, assume the running SPID 51 needs physical IO. Two things will happen. SPID 51 is moved to the wait list until the IO is completed and the next session_id in the runnable queue, SPID 60, begins to run. When the IO is complete, SPID 51 is moved to the bottom of the runnable queue which now consists of SPIDS 55, 87, 79 & 51.

Given this scenario, the total amount of time waiting consists of resource and signal waits. The time waiting for a resource is shown as Resource Waits. The time waiting in the runnable queue for CPU is called Signal Waits. In SQL Server 2005, waits are shown in the Dynamic Management View (DMV) sys.dm_os_wait_stats. The query to measure cpu pressure is as follows:

---- Total waits are wait_time_ms

Select signal_wait_time_ms=sum(signal_wait_time_ms)

,'%signal (cpu) waits' = cast(100.0 * sum(signal_wait_time_ms) / sum (wait_time_ms) as numeric(20,2))

,resource_wait_time_ms=sum(wait_time_ms - signal_wait_time_ms)

,'%resource waits'= cast(100.0 * sum(wait_time_ms - signal_wait_time_ms) / sum (wait_time_ms) as numeric(20,2))

From sys.dm_os_wait_stats

You can initialize or clear out SQL Server 2005 waitstats with the statement dbcc sqlperf ([sys.dm_os_wait_stats],clear) with no_infomsgs. In SQL Server 2000, waits can be seen by looking at DBCC SQLPERF (WAITSTATS).

If you have SQL–dedicated box it is conceivable that you could have high signal waits indicating CPU pressure and still have a low processor queue length. In such cases, a faster CPU could reduce signal waits but just focusing on the low processor queue length as a measure of CPU contention may lead to the erroneous conclusion that CPU is fine.

In conclusion, if Signal Waits are a significant percentage of total waits, you have CPU pressure which may be alleviated by faster or more CPUs. Alternately, CPU pressure can be reduced by eliminating unnecessary sorts (indexes can avoid sorts in order & group by’s) and joins, and compilations (and re-compilations). If Signal Waits are not significant, a faster CPU will not appreciably improve performance.

Tom Davidson