I just found this on a hosted SQL server I use. The query was trying to enable service broker and was just waiting for an exclusive database lock which it wasn’t getting.
So it was sitting there for 58 days.
Do you have a query thats been running for longer ?
This is what I like to see. I hope that means no problems with internet today.
if you are looking to work with Analysis Services then you need to learn MDX and there is no better person to learn it from than Chris Webb
Chris is a Microsoft MVP and a leading expert on MDX. He is the co-author of two books, "MDX Solutions" (second edition) and "Expert Cube Development with SQL Server Analysis Services 2008", and blogs about Microsoft BI topics at http://cwebbbi.wordpress.com/
Chris is doing an introduction to MDX course Wednesday, 26 October 2011 to Friday, 28 October 2011
To register for the Introduction to MDX course or get more details click here
- What is MDX and why should I use it?
- Understanding the structure of a cube: recognizing cubes, measure groups, dimensions and hierarchies
- Understanding the concepts of members, tuples and sets
- Writing simple queries: using SQL Management studio to write SELECT statements
- Creating simple calculated members: when to use query, session and cube-scoped calculations, using simple MDX expressions and functions
- Standard Calculations: looking at the best ways to implement common calculations, such as time series, market shares and rankings
- Using set functions: using common MDX functions such as Crossjoin, Filter, Order, Generate to create more complex queries
- Advanced concepts: autoexists, solve order and subselects
- MDX Script Assignments: making scoped assignments, understanding how assignments affect aggregation, using assignments with calculated members
- MDX for Reporting Services
- Performance Tuning and Troubleshooting: using Profiler, building aggregations, functions to avoid
Cost £749 + VAT
I was reading the news today about the Kercher murder trial and the acquittal of Amanda Knox. The reason for the acquittal was the DNA evidence that was collected, and was the foundation of the prosecution in the original trial, could not be relied upon. Over years the forensic community have defined how data should be collected and processed. In this case it doesn’t matter if the DNA evidence was correct or not, the way means by which it was collected and processed could not be relied upon and thus the information is discarded.
How does this relate to BI?
You are producing data which is going to be the foundation of decisions in your business. If your data can not be relied upon then the business wont trust that data and so the data becomes useless. I’ve seen far too many BI systems where there is no trust of the data. This results in the data being questioned at the slightest hiccup of the data. Rather than looking at what caused the hiccup in the business, the business turn back on the data and say the data is wrong. This means all the time that has been spent building the BI system has been for nothing.
What does this mean for your projects?
Some of the aspects of BI projects that I feel undermine any trust in data are,
1. Not delivering data on time
If data is not delivered on time then questions are raised as to what is wrong with the system. If you can’t deliver data on time then the key thing to do is to inform the business of the situation. Its always better to be upfront about these problems than try and hide the fact. Whats more the problems might be due to a source system, if thats the case then your BI system shouldn’t take the hit for a problem in a source system. Why not have a dashboard informing the users of the status of your BI system and its processing.
2. Changing results
Once a result is delivered to the business it shouldn’t change. Ok its a little more complex than that but in principle you shouldn’t changed something thats already been calculated. If results have to change then you and your users need to be aware of what and why. Do you have a latency problem in collecting information and so it takes 7 days to get to a final figure. If so your daily figures may change for 7 days, but after that they shouldn’t. You should have exception reporting so that if you get late facts after the 7 days you can manage the system by informing the users that a problem with another system and not the BI system, will mean the figures will change.
3. Not informing the business of a problem
If someone makes a decision based on the information in your BI system and 2 days later they are told the system hasn’t been working properly for 2 days they aren’t going to be happy. Its going to make them think twice about using your system as the foundation of their decision in the future. If you had informed them at the time then they would likely understand and whilst the system has had a problem it won’t undermine the trust in the system.
4. Providing two different values at the same time
Many BI systems have evolved over time, usually in a Lego fashion. A bit stuck on hear, a bit stuck on there. This almost always leads to information being consumed by the business from systems with different latencies and potentially different calculations. This is the worst case as the business won’t know which figure to look at and so won’t trust any of them. The single version of the truth is a core concept that I always try to adhere to. If you have to have multiple versions then the end users have to be aware of what the differences are so they can trust the data and your systems.
Information is King, if you have the information then you can do anything you want. However if its wrong then thats the worst situation to be in.
Make sure you do what you need to to make sure that your business trusts your data and doesn’t have reasons not to trust your data.