Context: SSAS 2005. I run a MDX query in SSMS, the query will throw error 'The operation has been cancelled.' whenever the execution time reaches 50 seconds (or 49 seconds, 48 seconds some times). I have already set ServerTimeOut to 0 and restarted the SSAS server. Any idea? I googled a bit and I am sure there is no processing when the query is running. In SQL Profiler I can only see an error event with the same information as in the SSMS. The log file has nothing recorded regarding this. But I do see the memory going up all the way until the query fails. Any idea?
Update
Ok it turns out I didn't set a relationship between a dimension and a measure group. I am not 100% clear about the issue but not it's sure it's not related to server properties nor processing while executing the query.
Related
we have jobs in sql agent runnig schedually. We know at least about one job (scheduled every day at three different times - morning, afternoon, night) which rarely (apx one per several months) fires/runs twice in same time (like a parallel). But it is scheduled only one time in same moment. Job runs CLR stored procedure which launch console application which process some getting data and recalculating
This behaviour causes problems for us.
Why?
How could it happend?
Where is problem?
But where is reason?
Thank you for all ideas.
(Of course, we should handle it and prevent this behaviour.)
I found error in job history according to time of job execution - error 6535.
This error appears twice for this job iteration. Firstly without addtional message, secondly with additional message "The step suceeded". When I looking for information about his error 6535 - i found that this error occurs on sql server 2005, but due to select ##version, the customer use sql server 2008 R2
OLE DB or ODBC error.
An error occurred while processing table 'Query 1'.
The current operation was cancelled because another operation in the transaction failed.
Out of line object 'DataSourceView', referring to ID(s) 'Temp_DSV', has been specified but has not been used.
I got the above error when i ran a query in Power Pivot for excel. Can somebody tell me , what might be the reason?
i got this message error too in mylast 7 days.
My solution is running first in example select top 10 * in sql server management studio, then go to excel, running query in power pivot again.
I dont know why this is solve, but it save me, in many times.
Maybe your query exceeds the memory limitations of 32bit Excel. Try to limit your query with a WHERE clause.
Also see this related question:
How to debug OLE DB or ODBC error (import data from MySql to Excel)
I have a bit a funny situation. Our Azure SQL instance maxes out at 100 DTU for a certain query and the query returns a timeout:
SqlException (0x80131904): Timeout expired. The timeout period
elapsed prior to completion of the operation or the server is not
responding. This failure occurred while attempting to connect to the
routing destination.
If I run exactly the same query (with the parameters hardcoded) in SQL Server Management Studio it still takes the DTU up to 25%, but that's still far away from 100%. Nothing else runs on that server. There are a few other queries that run before/after. But if we just run them, nothing spikes out.
Any ideas?
My analysis of the issue goes like this..
First when DTU's are maxed out and if a query fails due to that,you will not get time out..Below is the error message you will get..
Resource ID: %d. The %s limit for the database is %d and has been reached. For more information
You can try testing that by opening multiple resource intensive queries
Secondly when you get time out's as indicated in your question,this is mostly due to query waiting for resources like say some database IO,memory..
we faced similar time out's ,but most of them are fixed by updating stats and rebuilding indexes,rest of them we optimized
What would cause a query being done in Management Studio to get suspended?
I perform a simple select top 60000 from a table (which has 11 million rows) and the results come back within a sec or two.
I change the query to top 70000 and the results take up to 40 min.
From doing a bit of searching on another but related issue I came across someone using DBCC FREEPROCCACHE to fix it.
I run DBCC FREEPROCCACHE and then redo the query for 70000 and it seemmed to work.
However, the issue still occurs with a different query.
I increase to say 90000 or if I try to open the table using [Right->Open Table], it pulls about 8000 records and stops.
Checking the activity log for when I do the Open Table shows the session has been suspended with a wait type of "Async_Network_IO". For the session running the select of 90000 the status is "Sleeping", this is the same status for the above select 70000 query which did return but in 45min. It is strange to me that the status shows "Sleeping" and it does not appear to be changing to "Runable" (I have the activiy monitor refreshing ever 30sec).
Additional notes:
I am not running both the Open Table and select 90000 at the same time. All queries are done one at a time.
I am running 32bit SQL Server 2005 SP2 CU9. I tried upgrading to SP3 but ran into install failurs. The issues was occuring prior to me trying this upgrade.
Server setup is an Active/Active cluster the issue occurs on either node, and the other instance does not have this issue.
I have ~20 other database on this same server instance but only this one DB is seeing the issue.
This database gets fairly large. It is currently at 76756.19MB. Data file is 11,513MB.
I am logged in locally on the Server box using Remote Desktop.
The wait type "Async_Network_IO" means that its waiting for the client to retrieve the result set as SQL Server's network buffer is full. Why your client isn't picking up the data in a timely manner I can't say.
The other case it can happen is with linked servers when SQL Server is querying a remote table, in this case SQL Server is waiting for the remote server to respond.
Something worth looking at is virus scanners, if they are monitoring network connections sometimes they can get lagged, its often apparent by them hogging all the CPU.
Suspended means it is waiting on a resource and will resume when it gets its resource. Judging from the sizes you are pulling back, it seems you are in an OLAP type of query.
Try the following things:
Use NOLOCK or set the TRANSACTION ISOLATION LEVEL at the top of the query
Check your execution plan and tune the query to be more efficient
The query has been canceled because the estimated cost of this query (1660) exceeds the configured threshold of 1500. Contact the system administrator.
I am getting error as above on live while running one of the stored procedure threads where parameter contain XML variable.
I have checked the configuration value of QUERY_GOVERNOR_COST_LIMIT is set to 1500.
To get resolve this problem I have added SET QUERY_GOVERNOR_COST_LIMIT 0 in stored procedures. And it is working fine.
When I run stored procedures in back end with and without SET QUERY_GOVERNOR_COST_LIMIT 0 statement, it is running fine, and run within 0 seconds.
But it is creating problem with .Net application and getting error.
So, why it is giving error with application and not with SQL Query analyzer?
Even query is run within 0 seconds as it can give error when execution time will exceed more then 15 seconds (as configured QUERY_GOVERNOR_COST_LIMIT 1500 )?
Please share your idea for the analysis and solution.
Could be because SET ARITHABORT is OFF from .NET
could also be a conversion problem, look at your execution plan do you see any conversions. How are you executing this from .NET and are you using the correct data types?
usually this happens because of different default ANSI setting for SSMS and .net
they could create different execution plans.
the first you need to check is the execution plans from both sources.
you can do this with sql profiler's Showplan XML event
QUERY_GOVERNOR_COST_LIMIT is a connection level Runtime setting. So while making connection this needs to be set. When you test in SSMS Query window you need to set this setting in QueryOption property window (right click inside query window, QueryOptions, Advance,...)
You also mentioned that query executes in 0 seconds so why even from .NET it errors out with setting of 15sec? Because the setting works on Estimated Query execution Cost, not the Actual one. So right question is why sql server has estimated the execution cost more than 15sec.? And there is no single answer for this one.
Though I would like to know what is the user workflow/situation where you actually need to use this setting. Many times estimated cost is lot different than actual so unless dev/dba know exactly what they are doing and what will be execution... looks like I don't understand the practical usage of this setting.