Analysis Services

SSAS, MPP and PDW

James Rogers — Fri, 14 Oct 2011 00:01:32 GMT

I cut my DBA teeth on IBM's DB2 UDB EEE (enough acronyms) back in the 90's. I have always appreciated the scalability that is available with a MPP architecture. So a couple of years ago I was excited to hear that SQL Server was going to have a MPP architecture available. Now I am at SQLPass Summit 2011 and seeing the PDW (Parallel Data Warehouse) and the hardware offerings by Dell and HP to scale that up and out. However, I was disappointed to learn that this technology does not extend to Analysis Services.

I spend a great deal of my time tuning SSAS and can say that it scales very well as is and there is a plethora of information out there to facilitate those efforts. However, let's dream a little here. Imagine a multi-node/single-instance/shared-nothing installation of SSAS. You can distribute/partition the cubes across the nodes and then within the nodes in a manner that allows you to isolate hot-spots of data on their own hardware so that data can stay cached. Meanwhile, other queries on data that is less-often accessed or more ad-hoc in nature can process with resources allocated on separate nodes for that and the majority of queries do not suffer as much from cache turnover and the overall system load. Ahhh, it is good to dream. We could take that a step further and wish that would could mix Vertipaq storage for that more frequently used/"hot" data node and traditional Analysis Services storage for the other data where aggregations may have more value in helping the queries. Additionally, processing of mining models could be further isolated from ongoing activities and processing activities could take advantage of the MPP architecture and resulting parallelism to allow for more processing in shorter time than on a similar, single box solution. Could even go further and dedicate a node to ROLAP partitions for more real-time requirements while limiting the burden of such queries on the overall system performance.

I realize that MS probably doesn't have much of a target market for such dreams but it would be cool nonetheless and provide some real scalability options for big data analytics implementations. Like always, the devil is in the details. OK - back to reality.

Analysis Services (SSAS) - Unexpected Internal Error when processing (ProcessUpdate). Workaround/Resolution

James Rogers — Mon, 20 Dec 2010 17:51:05 GMT

/* EDIT - This problem has been fixed in the latest SQL Server 2008 R2 Cumulative Update package. It was identified that changing the aggregation design without reprocessing the aggregations prior to a ProcessUpdate on the dimensions causes this problem and it is a bug */

Many implementations require the use of ProcessUpdate to support Type 1 slowly changing dimensions. ProcessUpdate drops all of the affected indexes and aggregations in partitions affected by data that changes in the Dimension on which the ProcessUpdate is being performed. Twice now I have had situations where the processing fails with "Internal error: An unexpected exception occurred." Any subsequent ProcessUpdate processing will also fail with the same error. In talking with Microsoft the issue is corrupt indexes for the Dimension(s) being processed in the partitions of the affected measure group. I cannot guarantee that the following will correct your problem but it did in my case and saved us quite a bit of down time.

Workaround: ProcessIndexes on the entire cube that is being processed and throwing the error. This corrected the problem on both 2008 and 2008 R2.

Pros:

Does not require a complete rebuild of the data (ProcessFull) for either the Dimension or Cube.
User access can continue while this ProcessIndexes in underway.

Cons:

Can take a long time, especially on large cubes with many partitions, dimensions and/or aggregations.
Query Performance is usually severely impacted due to the memory and CPU requirements for Aggregation and Index building

<DatabaseID>MyDatabase</DatabaseID>

<CubeID>MyCube</CubeID>

</Object>

<Type>ProcessIndexes</Type>

<WriteBackTableCreation>UseExisting</WriteBackTableCreation>

</Process>

</Parallel>

</Batch>

The cube where the corruption exists can be found by having Profiler running while the ProcessUpdate is executing. The first partition that displays the "The Job has ended in failure." message in the TextData column will be part of the cube/measuregroup that has the corruption. You can try to run ProcessIndexes on just that measure group. This may correct the problem and save additional time if you have other large measure groups in the cube that are not affected by the corruption.

Remember to execute your normal ProcessUpdate batch after the successful completion of the ProcessIndexes. The ProcessIndexes does not pick up data changes.

Things that did not work:

ProcessClearIndexes - why this doesn't work and ProcessIndexes does is unclear at this point.
ProcessFull on the partition in question. In my latest case, this would clear up the problem for that partition. However, the next partition the ProcessUpdate touched that had data in it would generate and error. This leads me to believe the corruption problem will exist in all partitions in the affected measure group that have data in them.

NOTE: I experience this problem in both a SQL 2008 and SQL 2008 R2 Analysis Services environment, on separate built from the same relational database. This leads me to believe that some data condition in the tables used for the Dimension processing caused the corruption since the two environments were on physically separate hardware. I am waiting on Microsoft to analyze the dumps to give us more insight into what actually caused the corruption and will update this post accordingly.

SSAS Usage-Based Optimization, OlapQueryLog (Enabling and Disabling), Aggregations and Structure Changes.

James Rogers — Tue, 02 Nov 2010 15:31:25 GMT

Analysis Services has a useful feature called Usage-Based Optimization. This feature is used to design aggregations based on actual user queries using Business Intelligence Development Studio (BIDS). Information on how to configure (or disable) the query logging required for this is fairly hard to find.

The Analysis Services Properties identified by "Log \ QueryLog" in the Analysis Services Properties window are used to configure the query logging used by Usage-Based Optimization:

The definition of these properties can be found in Books On Line (BOL) and on MSDN.

Enabling Usage-Based Optimization:

1. Set CreateQueryLogTable to true

2. Set the value of QueryLogConnectionString appropriately (database specified in the connection string must already exist)

3. Set the value of QueryLogSampling to the appropriate value for your environment (the default value of 10 means every 10th query will be logged). The lower the value of this property, the higher the overhead of query logging will be on the system.

4. Set the value of QueryLogTableName appropriately.

5. Click "OK"

Disabling Usage-Based Optimization:

1. Set the value of QueryLogSampling to "0". This will stop query logging.

2. Click "OK"

Advantages of Usage-Based Optimization and logging:

1. If you have an environment where users are submitting repetitive queries with similar tuples/slicers - the usage based-optimization will probably do a good job of helping design useful aggregations.

2. Very little detailed knowledge of the cube structure and querying practices is needed to create aggregations.

3. Aggregations will be designed (using BIDS or BIDS Helper utilities) based on actual user queries and not just gather requirements.

Disadvantages of Usage-Based Optimization and logging:

1. Can create overhead on the system is sampling is too frequent.

2. Resulting aggregation designs may not help as much as desired or may not help the average use-case.

3. The logging table must be maintained and kept at a manageable size:

a. Any structure changes will cause analysis services to issue a delete against the logging table for any queries containing the cube being changed/affected. This can cause cube structure changes to take a long time if the logging table is extremely large.

b. Utilities from BIDS (or BIDS Helper functionality) can be mislead by older log data that may no longer apply to the current usage patterns of the database.

Tuning Analysis Services (SSAS) for better Parallel Aggregation/Index Processing

James Rogers — Tue, 02 Nov 2010 12:33:27 GMT

One of the key performance concepts in Analysis Services is the design and use of good Aggregations to support user queries. However, Analysis Services (Both 2005 and 2008) by default is not configured very well to take advantage of multi-processor environments for parallel processing of these indexes, particularly for large MOLAP partitions. Keep in mind, using a large portion of available processors for aggregation building is only desirable in environments where a processing window is allocated and user activity is minimized or prevented entirely for that window. If you have small datasets and processing time is not a problem then making changes to support better parallel processing may not be needed or recommended. Changing of these settings is best done under guidance of Microsoft.

Problem Isolation: Using a combination of SQL Server Profiler and watching the Task Manager from windows allows simple detection of the key symptom of this problem: seeing only one processor (or processor core) being utilized while processing of aggregations is taking place. To test this, issue a multi-partition ProcessIndexes XMLA statement such as the one below and watch your Profiler and Task Manager (could also use Perfmon as well).

<Batchxmlns="http://schemas.microsoft.com/analysisservices/2003/engine">

<DatabaseID>Adventure Works DW 2008</DatabaseID>

<CubeID>Adventure Works</CubeID>

<MeasureGroupID>Fact Internet Sales 1</MeasureGroupID>

<PartitionID>Internet_Sales_2001</PartitionID>

</Object>

<Type>ProcessIndexes</Type>

<WriteBackTableCreation>UseExisting</WriteBackTableCreation>

</Process>

<DatabaseID>Adventure Works DW 2008</DatabaseID>

<CubeID>Adventure Works</CubeID>

<MeasureGroupID>Fact Internet Sales 1</MeasureGroupID>

<PartitionID>Internet_Sales_2002</PartitionID>

</Object>

<Type>ProcessIndexes</Type>

<WriteBackTableCreation>UseExisting</WriteBackTableCreation>

</Process>

<DatabaseID>Adventure Works DW 2008</DatabaseID>

<CubeID>Adventure Works</CubeID>

<MeasureGroupID>Fact Internet Sales 1</MeasureGroupID>

<PartitionID>Internet_Sales_2003</PartitionID>

</Object>

<Type>ProcessIndexes</Type>

<WriteBackTableCreation>UseExisting</WriteBackTableCreation>

</Process>

<DatabaseID>Adventure Works DW 2008</DatabaseID>

<CubeID>Adventure Works</CubeID>

<MeasureGroupID>Fact Internet Sales 1</MeasureGroupID>

<PartitionID>Internet_Sales_2004</PartitionID>

</Object>

<Type>ProcessIndexes</Type>

<WriteBackTableCreation>UseExisting</WriteBackTableCreation>

</Process>

</Parallel>

</Batch>

If, during the course of processing you see only one partition processing at a time (in the Profiler window) and that also correlates to mdsmdsrv.exe only using the equivalent of one CPU (i.e. ~50% on a 2-CPU machine) then tuning the SSAS server properties to allow better parallel aggegation/index processing might be an advantage for the environment (see original statement regarding processing windows and data sets in the first paragraph).

Configuration Changes: The configuration properties of AggregationMemoryLimitMax and AggregationMemoryLimitMin (these are in the OLAP \ Process section of the Analysis Services Properties Window):

The default value of 80 for AggregationMemoryLimitMax will prevent more than one partition from being processed, especially for large cubes/partitions with large aggregations. This is because a setting of 80 means up to 80% of the available memory can be used for building aggregations on the partition. That leaves only 20% of the available memory for other partitions, which is not enough to start another partition until the partition currently being processed is completed. I use the following formula for setting AggregationMemoryLimitMax and AggregationMemoryLimitMin (this is only used for reference, the proper settings vary from environment to environment based on hardware resources, business requirements and availability requirements):

AggregationMemoryLimitMax=ceiling(100/(<number processing cores>-2))

AggregationMemoryLimitMin=ceiling(100/((<number processing cores>-2)*1.5))

Using (<number processing cores>+1) helps to leave enough memory for at least one processor core for non-SSAS activities (such as paging, SQL Server activities).

On a 16-core machine the AggregationMemoryLimitMax would come out to 7 which means up to 14 (100/7) partitions could process aggregations in parallel. The AggregationMemoryLimitMin would come to 5 which means no more than 20 (100/5) partitions could process in parallel.

Result:

Processing time for rebuilding aggregations and indexes is significantly reduced in multi-processor environments, provided the environment does not have other resource constraints. The degree of improvement will depend on the number of processing cores and amount of memory available to the system for the Aggregation processing. However, on large mult-core, multi-processor servers with large partitions and aggregations, this can make the difference between being able to process the aggregations frequent enough to help user queries or having the user queries suffer longer durations due to missing indexes and/or aggregations that are not processed.

MDX using EXISTING, AGGREGATE, CROSSJOIN and WHERE

James Rogers — Sat, 12 Jun 2010 09:43:55 GMT

It is a well-published approach to using the EXISTING function to decode AGGREGATE members and nested sub-query filters. Mosha wrote a good blog on it here and a more recent one here. The use of EXISTING in these scenarios is very useful and sometimes the only option when dealing with multi-select filters. However, there are some limitations I have run across when using the EXISTING function against an AGGREGATE member:

The AGGREGATE member must be assigned to the Dimension.Hierarchy being detected by the EXISTING function in the calculated measure.

The AGGREGATE member cannot contain a crossjoin from any other dimension or hierarchy or EXISTING will not be able to detect the members in the AGGREGATE member.

Take the following query (from Adventure Works DW 2008):

With

member [Week Count] as 'count(existing([Date].[Fiscal Weeks].[Fiscal Week].members))'

member [Date].[Fiscal Weeks].[CM] as 'AGGREGATE({[Date].[Fiscal Weeks].[Fiscal Week].&[47]&[2004],[Date].[Fiscal Weeks].[Fiscal Week].&[48]&[2004],[Date].[Fiscal Weeks].[Fiscal Week].&[49]&[2004],[Date].[Fiscal Weeks].[Fiscal Week].&[50]&[2004]})'

select

{[Week Count]} on columns

from

[Adventure Works]

where

[Date].[Fiscal Weeks].[CM]

Here we are attempting to count the existing fiscal weeks in slicer. This is useful to get a per-week average for another member. Many applications generate queries in this manner (such as Oracle OBIEE). This query returns the correct result of (4) weeks.

Now let's put a twist in it. What if the querying application submits the query in the following manner:

With

member [Week Count] as 'count(existing([Date].[Fiscal Weeks].[Fiscal Week].members))'

member [Customer].[Customer Geography].[CM] as 'AGGREGATE({[Date].[Fiscal Weeks].[Fiscal Week].&[47]&[2004],[Date].[Fiscal Weeks].[Fiscal Week].&[48]&[2004],[Date].[Fiscal Weeks].[Fiscal Week].&[49]&[2004],[Date].[Fiscal Weeks].[Fiscal Week].&[50]&[2004]})'

select

{[Week Count]} on columns

from

[Adventure Works]

where

[Customer].[Customer Geography].[CM]

Here we are attempting to count the existing fiscal weeks in slicer. However, the AGGREGATE member is built on a different dimension (in name) than the one EXISTING is trying to detect. In this case the query returns (174) which is the total number of [Date].[Fiscal Weeks].[Fiscal Week].members defined in the dimension.

Now another twist, the AGGREGATE member will be named appropriately and contain the hierarchy we are trying to detect with EXISTING but it will be cross-joined with another hierarchy:

With

member [Week Count] as 'count(existing([Date].[Fiscal Weeks].[Fiscal Week].members))'

{[Customer].[Customer Geography].[Country].&[Australia],[Customer].[Customer Geography].[Country].&[United States]})'

select

{[Week Count]} on columns

from

[Adventure Works]

where

[Date].[Fiscal Weeks].[CM]

Once again, we are attempting to count the existing fiscal weeks in slicer. Again, in this case the query returns (174) which is the total number of [Date].[Fiscal Weeks].[Fiscal Week].members defined in the dimension. However, in 2008 R2 this query returns the correct result of 4 and additionally , the following will return the count of existing countries as well (2):

With

member [Week Count] as 'count(existing([Date].[Fiscal Weeks].[Fiscal Week].members))'

member [Country Count] as 'count(existing([Customer].[Customer Geography].[Country].members))'

{[Customer].[Customer Geography].[Country].&[Australia],[Customer].[Customer Geography].[Country].&[United States]})'

select

{[Week Count]} on columns

from

[Adventure Works]

where

[Date].[Fiscal Weeks].[CM]

2008 R2 seems to work as long as the AGGREGATE member is on at least one of the hierarchies attempting to be detected (i.e. [Date].[Fiscal Weeks] or [Customer].[Customer Geography]). If not, it seems that the engine cannot find a "point of entry" into the aggregate member and ignores it for calculated members.

One way around this would be to put the sets from the AGGREGATE member explicitly in the WHERE clause (slicer). I realize this is only supported in SSAS 2005 and 2008. However, after talking with Chris Webb (his blog is here and I highly recommend following his efforts and musings) it is a far more efficient way to filter/slice a query:

With

member [Week Count] as 'count(existing([Date].[Fiscal Weeks].[Fiscal Week].members))'

select

{[Week Count]} on columns

from

[Adventure Works]

where

({[Date].[Fiscal Weeks].[Fiscal Week].&[47]&[2004],[Date].[Fiscal Weeks].[Fiscal Week].&[48]&[2004],[Date].[Fiscal Weeks].[Fiscal Week].&[49]&[2004],[Date].[Fiscal Weeks].[Fiscal Week].&[50]&[2004]}

,{[Customer].[Customer Geography].[Country].&[Australia],[Customer].[Customer Geography].[Country].&[United States]})

This query returns the correct result of (4) weeks. Additionally, we can count the cross-join members of the two hierarchies in the slicer:

With

member [Week Count] as 'count(existing([Date].[Fiscal Weeks].[Fiscal Week].members)*existing([Customer].[Customer Geography].[Country].members))'

select

{[Week Count]} on columns

from

[Adventure Works]

where

({[Date].[Fiscal Weeks].[Fiscal Week].&[47]&[2004],[Date].[Fiscal Weeks].[Fiscal Week].&[48]&[2004],[Date].[Fiscal Weeks].[Fiscal Week].&[49]&[2004],[Date].[Fiscal Weeks].[Fiscal Week].&[50]&[2004]}

,{[Customer].[Customer Geography].[Country].&[Australia],[Customer].[Customer Geography].[Country].&[United States]})

We get the correct number of (8) here.

Performance, Named Sets, Calculated Measures, PerformancePoint and ProClarity

James Rogers — Thu, 14 Feb 2008 10:15:46 GMT

Many legacy Analysis Services (or OLAP Services) implementations use ProClarity as a querying tool and publishing framework. The server infrastructure of ProClarity allows crafty implementers to push much of the customization in KPI’s and additional measures into the “Presentation” layer of the infrastructure. This is easier to manage and change in many cases than creating named sets and calculated members in the cubes as this generally takes a SSAS administrator.

With Microsoft purchasing ProClarity and its inclusion into PerformancePoint leads to a quandary for many solution designers. While ProClarity still works well as it was designed and is available as a report type in PerformancePoint, the ProClarity views have a very different look and feel than the native PerformancePoint report views. Also, due to the fact that the report views are basically ProClarity Web Standard views, the drill-from-anywhere-to-anywhere capabilities are not available directly though the PerformancePoint interface for these views. Additionally, the library of calculated measures and sets created and published in ProClarity are not available to PerformancePoint and thus cannot be used in scorecards and report views.

In many cases, the optimum solution here is to build these ProClarity sets and measures into their respective cubes as named sets and calculated members. CAVEAT – this is not a silver bullet solution. There is a cost in terms of SSAS processing and resources for named sets and calculated measures so this should not be done without ample testing prior to implementation in production environments.

Let’s first talk about calculated measures. Existing ProClarity solutions may have a laundry list of calculated measures in their libraries. Many times these may contain nested measures (i.e. a calculated measure that uses another calculated measure) and as these get more they tend to not perform as well as desired. First, it is important to identify which measures will get heavy use in other applications such as PerformancePoint (both scorecards and reports) and Excel. Those that have a wide range of applicability justify their creation and maintenance as calculations in their respective cubes. These calculation (and set) definitions can be extracted from the ProClarity repository database for those of you who are familiar with it. This is not a “recommended” approach in much the same way as using the “sys” tables in production code for SQL Server is discouraged. As a rule, I like to take these calculations and run through extensive performance analysis using Query Analyzer and Profiler. For instance, let’s convert a calculation that reflects sales growth over the prior week:

[Measures].[Sales]/paralleperiod([Date].[Week].[Week],1,[Date].[Week].currentmember)

The query would look something like:

With member [Measures].[Sales Growth] as ‘[Measures].[Sales]/paralleperiod([Date].[Week].[Week],1,[Date].[Week].currentmember)’

Select [Org].members on rows

,[Date].[Week].&[01/01/2007 – 01/07/2007] on columns

From sales

Where [Measures].[Sales Growth]

Make sure to test the query using dimension that can take advantage of your cube partitioning strategy (in this case [Date]). Test the query with the measure as a filter, on rows and on columns. Checking profiler to make sure that the query does not cause a scan of all process partitions or excessive subcubing. Once you have settled on a calculation formula that performs well in these cases it is now time to create the calculated member through Business Intelligence Studio. When you create the calculated member in the cube, make sure you define the format and especially the non-empty behavior. If the calculation involves division, I tend to use one of the measures from the denominator as the non-empty behavior measure. I realize that this may not always be feasible if the resulting non-empty behavior is not correct so do not do this thoughtlessly.

Next, let’s talk about named sets. Many times users and/or publishers have created dimensional sets in ProClarity to ease reporting and facilitate exception-based metrics (I will talk to this in a later post). Putting these into the cube involves much the same process as the calculated measures. First I test the named set through Query Analyzer watching with Profiler. Let’s consider a named set for a dimension Sales Type that identifies gift card sales:

{[Sales Type].[Sales Type].&[Gift Card], [Sales Type].[Sales Type].&[Vendor Card]}

Next we use this in the query:

With set [Gift Card] as ‘{[Sales Type].[Sales Type].&[Gift Card], [Sales Type].[Sales Type].&[Vendor Card]}’

member [Measures].[Sales Growth] as ‘[Measures].[Sales]/paralleperiod([Date].[Week].[Week],1,[Date].[Week].currentmember)’

Select [Org].members on rows

,[Date].[Week].&[01/01/2007 – 01/07/2007] on columns

From sales

Where ([Measures].[Sales Growth], [Gift Card])

Move the set around in the query to test it from all angles and try using it as part of an aggregate measure as well:

With set [Gift Card] as ‘{[Sales Type].[Sales Type].&[Gift Card], [Sales Type].[Sales Type].&[Vendor Card]}’

member [Measures].[Gift Card Sales] as ‘sum([Gift Card],[Measures].[Sales])’

Select [Org].members on rows

,[Date].[Week].&[01/01/2007 – 01/07/2007] on columns

From sales

Where ([Measures].[Gift Card Sales])

If the results are satisfactory then create the set in the cube through Business Intelligence Studio. Keep in mind that sets are cached in memory for each connection so extremely large sets are not recommended in some cases as are too many sets.

I tend to define the named sets at the top of my calculations definition so they can be used in all the subsequent calculations, if necessary. The sets and calculations created in Business Intelligence Studio are appended to the cube definition as an MDXScript so order of creation in the Studio is important as you must define parent sets and calculations before their dependent sets and calculations. Adding and modifying these generally does not require cube reprocessing but I have seen it happen in rare instances. Make sure you test the cube modifications first in a non-production environment to make sure that they do not require reprocessing. You wouldn’t want to do something that would cause reprocessing the cube partitions as the source data may have been purged and unrecoverable (hopefully you have planned for this with a good archive process). Since named sets are cached in memory and calculated members are generally resolved in memory, often the combination of these results in better query performance. Using named sets in calculated measures often requires aggregate functions (such as SUM) which have a higher CPU requirement so consider the calculation mdx definition carefully to find the correct balance of query performance and scalability considering your server resources. On last advantage of calculated measures is that the mdx definition is static so you lessen the likelihood of the same measure being calculated multiple, different ways which can not only end up with different results but vastly different queries and performance.

With these high-use sets and calculations defined in the cube(s) in an optimum way they are now available to all applications that connect to the cube such as PerformancePoint, Excel and Reporting Services as well as ProClarity and the resulting query performance should be more predictable than when they were in the ProClarity repository and assembled on the fly by ProClarity.

Finding and killing SSAS Sessions

James Rogers — Wed, 23 Jan 2008 06:47:27 GMT

If you have a reasonably large Analysis Services implementation with users running adhoc queries via multiple tools (ProClarity, Excel, etc...) then you have probably run into problems with long-running queries. While longer-running queries may be acceptable in many data warehousing implementations, there will occasionally be a query (maybe even more than one ;) ) that causes resource issues and runs beyond the established limits of reason for your environment. Analysis Services does not have a native tool in SQL Management Studio for monitoring session activity and/or killing connections (hint: please add one). There is some sample code you can get from Microsoft along these lines but I wanted something simpler. In digging around for info on how to do this I found pieces of how to do it but nothing comprehensive so this is what I have put together so that I can do this through the SQL Management Studio.

Open a XMLA query window connected to the Analysis Services server in question.

Command 1 (Session Monitoring/Find it!):

Old School

<RequestType>DISCOVER_SESSIONS</RequestType>

</Restrictions>

</Properties>

</Discover>

Using ASSP:

Call ASSP.DiscoverSessions

SQL 2008 Using DMV:

Select * from $system.DiscoverSessions

Command 2 (Kill it!):

Old School (Through XMLA Window)

</Cancel>

Using ASSP:

Call ASSP.CancelSpid(121672)

Using ASCMD:

ASCMD.exe –S localhost –Q “Call ASSP.CancelSPID(121672)”

Command 1 uses the Discover method to list the sessions. A lot of good info is in the output of this command: See the following example (from XMLA window output – using DMV or ASSP is much easier to read and is my preference):

<xsd:schematargetNamespace="urn:schemas-microsoft-com:xml-analysis:rowset"xmlns:sql="urn:schemas-microsoft-com:xml-sql"elementFormDefault="qualified">

<xsd:elementname="root">

<xsd:complexType>

<xsd:sequenceminOccurs="0"maxOccurs="unbounded">

<xsd:elementname="row"type="row" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:simpleTypename="uuid">

<xsd:restrictionbase="xsd:string">

<xsd:patternvalue="[0-9a-zA-Z]{8}-[0-9a-zA-Z]{4}-[0-9a-zA-Z]{4}-[0-9a-zA-Z]{4}-[0-9a-zA-Z]{12}" />

</xsd:restriction>

</xsd:simpleType>

<xsd:complexTypename="xmlDocument">

<xsd:sequence>

<xsd:any />

</xsd:sequence>

</xsd:complexType>

<xsd:complexTypename="row">

<xsd:sequence>

<xsd:elementsql:field="SESSION_ID"name="SESSION_ID"type="xsd:string"minOccurs="0" />

<xsd:elementsql:field="SESSION_SPID"name="SESSION_SPID"type="xsd:int"minOccurs="0" />

<xsd:elementsql:field="SESSION_CONNECTION_ID"name="SESSION_CONNECTION_ID"type="xsd:int"minOccurs="0" />

<xsd:elementsql:field="SESSION_USER_NAME"name="SESSION_USER_NAME"type="xsd:string"minOccurs="0" />

<xsd:elementsql:field="SESSION_CURRENT_DATABASE"name="SESSION_CURRENT_DATABASE"type="xsd:string"minOccurs="0" />

<xsd:elementsql:field="SESSION_USED_MEMORY"name="SESSION_USED_MEMORY"type="xsd:int"minOccurs="0" />

<xsd:elementsql:field="SESSION_PROPERTIES"name="SESSION_PROPERTIES"type="xsd:string"minOccurs="0" />

<xsd:elementsql:field="SESSION_START_TIME"name="SESSION_START_TIME"type="xsd:dateTime"minOccurs="0" />

<xsd:elementsql:field="SESSION_ELAPSED_TIME_MS"name="SESSION_ELAPSED_TIME_MS"type="xsd:unsignedLong"minOccurs="0" />

<xsd:elementsql:field="SESSION_LAST_COMMAND_START_TIME"name="SESSION_LAST_COMMAND_START_TIME"type="xsd:dateTime"minOccurs="0" />

<xsd:elementsql:field="SESSION_LAST_COMMAND_END_TIME"name="SESSION_LAST_COMMAND_END_TIME"type="xsd:dateTime"minOccurs="0" />

<xsd:elementsql:field="SESSION_LAST_COMMAND_ELAPSED_TIME_MS"name="SESSION_LAST_COMMAND_ELAPSED_TIME_MS"type="xsd:unsignedLong"minOccurs="0"/>

<xsd:elementsql:field="SESSION_IDLE_TIME_MS"name="SESSION_IDLE_TIME_MS"type="xsd:unsignedLong"minOccurs="0" />

<xsd:elementsql:field="SESSION_CPU_TIME_MS"name="SESSION_CPU_TIME_MS"type="xsd:unsignedLong"minOccurs="0" />

<xsd:elementsql:field="SESSION_LAST_COMMAND"name="SESSION_LAST_COMMAND"type="xsd:string"minOccurs="0" />

<xsd:elementsql:field="SESSION_LAST_COMMAND_CPU_TIME_MS"name="SESSION_LAST_COMMAND_CPU_TIME_MS"type="xsd:unsignedLong"minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

<row>

<SESSION_ID>9EBAB2DE-A23E-4183-8508-7A729BF41C85</SESSION_ID>

<SESSION_SPID>126449</SESSION_SPID>

<SESSION_CONNECTION_ID>233</SESSION_CONNECTION_ID>

<SESSION_USER_NAME>DOMAIN\User</SESSION_USER_NAME>

<SESSION_CURRENT_DATABASE>Cubes</SESSION_CURRENT_DATABASE>

<SESSION_START_TIME>2007-10-19T12:54:58</SESSION_START_TIME>

<SESSION_ELAPSED_TIME_MS>34141</SESSION_ELAPSED_TIME_MS>

<SESSION_LAST_COMMAND_START_TIME>2007-10-19T12:55:09</SESSION_LAST_COMMAND_START_TIME>

<SESSION_LAST_COMMAND_END_TIME>2007-10-19T12:55:07</SESSION_LAST_COMMAND_END_TIME>

<SESSION_LAST_COMMAND_ELAPSED_TIME_MS>23438</SESSION_LAST_COMMAND_ELAPSED_TIME_MS>

<SESSION_IDLE_TIME_MS>0</SESSION_IDLE_TIME_MS>

<SESSION_CPU_TIME_MS>390</SESSION_CPU_TIME_MS>

<SESSION_LAST_COMMAND>SELECT

HIERARCHIZE( { [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[00:00 (1:00 a.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[01:00 (2:00 a.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[02:00 (3:00 a.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[03:00 (4:00 a.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[04:00 (5:00 a.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[05:00 (6:00 a.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[06:00 (7:00 a.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[07:00 (8:00 a.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[08:00 (9:00 a.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[09:00 (10:00 a.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[10:00 (11:00 a.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[11:00 (12:00 a.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[12:00 (1:00 p.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[13:00 (2:00 p.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[14:00 (3:00 p.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[15:00 (4:00 p.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[16:00 (5:00 p.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[17:00 (6:00 p.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[18:00 (7:00 p.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[19:00 (8:00 p.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[20:00 (9:00 p.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[21:00 (10:00 p.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[22:00 (11:00 p.m.)], [Quarter Hour].[Time - Time-Half Hour-Hour].[Hour].&[23:00 (12:00 p.m.)] } )

ON COLUMNS,

{ [Measures].[Gross Sales], [Measures].[Gross Sales LY] }

ON ROWS

FROM [Sales]

WHERE ( [Org Hierarchy].[Hierarchy - Org Hierarchy].&[1000001], [Date].[Hierarchy - Calendar Week].[Date - Calendar - Week].&[2007 - (09/23/07 - 09/29/07)] )</SESSION_LAST_COMMAND>

<SESSION_LAST_COMMAND_CPU_TIME_MS>109</SESSION_LAST_COMMAND_CPU_TIME_MS>

</row>

</root>

</return>

Each <row></row> corresponds to a session. You can see the SPID (<SESSION_SPID>), user (<SESSION_USER_NAME>), the last command, etc. This is info can be the basis of a session monitoring/auto kill process (many of us have written similar applications in SQL Stored Procedures for SQL Server). We could even get more sophisticated and have a .NET application that runs this, applies a transform and outputs something far more readable and extend it with cancel/kill functionality, etc. Most of the information I found while researching this alludes to using the .NET application approach. However, I wanted something simpler.

We take the <SESSION_SPID> value from the output of the DISCOVER_SESSIONS command and plug it into Command 2’s <SPID> value. Notice I use the <CancelAssociated> options with a value of 1 (true). This cancels the process and any associated processes with the SPID in question. There are a host of options with the Cancel command and I am not going to cover them here. MSDN has fairly comprehensive documentation on it as well as the DISCOVER command.