In our snowflake, we have multiple users accessing the database. And sometimes when query takes long time people are cancelling the query from UI.
I was wondering if there is a way to get information about who has cancelled the query.
Like we have table QUERY_HISTORY to get information about the query.
Do we have a similar table to get information of query cancelled?
Only the user who executed the query can cancel it via the Abort button in the UI. Other ways to cancel a query would be to issue one of the following functions:
SYSTEM$CANCEL_QUERY
SYSTEM$CANCEL_ALL_QUERIES
SYSTEM$ABORT_SESSION
SYSTEM$ABORT_TRANSACTION
ALTER WAREHOUSE ... ABORT ALL QUERIES
ALTER USER ... ABORT ALL QUERIES
Any one of the above functions that are issued would be a query in the QUERY_HISTORY as well.
A cancelled query will have an error of 604, and I expect that the error code is different if the query has timed out (which by default is set to 2 days).
The question is whether there is a table that stores cancelled queries like QUERY_HISTORY, I think. The answer is that even a cancelled query will be in QUERY_HISTORY.
Related
I am executing an asynchronous query against Snowflake and getting back a query_id. I want to query Snowflake to determine the execution status of the query, so I will know when it is safe to retrieve the results. What is the best way to do this? I am ruling out the below methods, as they each have limitations.
QUERY_HISTORY Function - I only want the status for 1 query. This function returns multiple queries, which is inefficient. Additionally, it has a row limit, so if my query was more than 10,000 queries ago, it will not be returned. Also, the bigger value I set for result_limit, the longer the function takes to run. A call with the value of 100 took 5 seconds to complete, while a value of 10,000 took multiple minutes, before I gave up and aborted the query.
QUERY_HISTORY View - The documentation states that this view has up to a 45 minute latency in data. I need to know the status in real time.
You should just be able to run
select *
from table(information_schema.query_history())
where query_id = ?
I have an NHibernate Query (which is populating an EXTJS grid)
It's firing 2 queries off to the database, one to get the record count (for paging purposes) and the other to get the top N rows to fill the grid with.
From code, I'm consistently getting an exception on the Select count(*) statement.
NHibernate.Exceptions.GenericADOException:
Failed to execute multi criteria[SQL:
SELECT count(*) as y0_ FROM RecordView this_ inner join ProcessesView
process1_ on this_.ProcessId=process1_.Id inner join BusinessModelsView
businessmo3_ on process1_.BusinessModelId=businessmo3_.Id inner join BatchesView
batch2_ on this_.BatchId=batch2_.Id WHERE this_.ProcessId = ?;
] ---> System.Data.SqlClient.SqlException: Timeout expired.
The timeout period elapsed prior to completion of the operation or the server
is not responding.
However if I take that exact query and drop it into an SSMS window, and run it, it executes in a <1 second.
Is NHibernate doing anything "funny" under the hood here. Are there execution plan/cache issues. I'm at a complete loss as to why this is occurring.
Whenever I encountered this error, the reason was locking (never performance). There was two sessions opened (accidently). Both started transaction and one of them locked the table.
The problem could be some not disposed session, or "unintended" singleton... holding opened session.
This answer is not as straigth forward as I wish, but I am sure about the direction. Because I experienced the same (and was guilty)
BTW: as Oskar Berggren found out from you, 30 secods timeout would be related to the <property name="command_timeout">30</property>. I am sure, if you will provide 60, 120 ... it will be not enough because of lock
Your two queries are not handled in the same way by SQL SERVER
your NH query has been compiled on its first execution, based on table statistics and on the first value of the parameter. The generated query plan will then be used for all subsequent calls, witout considering the parameter value
your SQL query (where, I guess, you replace the ? with an actual value) gets a different compilation for each value, based on statistics, and on the value.
Your first NH compilation might have produced a query plan, effective for the first value, but not in the general case.
First, I would suggest that :
you count on a projection (say on the main table id), as it is slightly more effective than count(*), allowing the DB to work only on indexes when possible
you check that you don't miss any index necessary to your query
you check that all your table statistics are up to date
If this does not improve execution time, this post offers some options (recompile might be the good one) :
Query executed from Nhibernate is slow, but from ADO.NET is fast
I'm new to triggers and I need to fire a trigger when selecting values from a database table in sql server. I have tried firing triggers on insert/update and delete. is there any way to fire trigger when selecting values?
There are only two ways I know that you can do this and neither are trigger.
You can use a stored procedure to run the query and log the query to a table and other information you'd like to know.
You can use the audit feature of SQL Server.
I've never used the latter, so I can't speak of the ease of use.
No there is no provision of having trigger on SELECT operation. As suggested in earlier answer, write a stored procedure which takes parameters that are fetched from SEECT query and call this procedure after desired SELECT query.
SpectralGhost's answer assumes you are trying to do something like a security audit of who or what has looked at which data.
But it strikes me if you are new enough to sql not to know that a SELECT trigger is conceptually daft, you may be trying to do something else, in which case you're really talking about locking rather than auditing - i.e. once one process has read a particular record you want to prevent other processes accessing it (or possibly some other related records in a different table) until the transaction is either committed or rolled back. In that case, triggers are definitely not your solution (they rarely are). See BOL on transaction control and locking
I am trying to resolve deadlocks. My Application gets deadlocks all the time when there is more then 10 users at the same time.
I have tried with SQL profiler and can't figure it out.
The thing is, in SQL Profiler I have checked to use the Deadlock Graph Event. But when I run the trace the event never got logged. I can see there are many Deadlocks and Deadlock Chains, but none Deadlock Graph. Please advice.
Thanks for help
You need to have only Locks->Deadlock graph selected if you want to see Deadlock graph event only.
When you run set up a filter for database name or database id, the DeadlockGraph event is not captured, even if you don't check "Exclude rows that don't check values".
If you filter for, say, Duration or NTUserName, which neither are populated by DeadlockGraph, the event is included (as long as you don't filter for the database, that is.)
Likewise, if you add LockAcquired and filter for DatabaseName (not populated by LockAcquired), the event is included.
So the problem is with this precise combination.
Refer:
https://connect.microsoft.com/SQLServer/feedback/details/240737/filtering-for-database-name-id-filters-out-deadlock-graph-when-it-shouldnt
I'm trying to analyze a deadlock in SQL Server 2008 profiler. I know how to find the offending sql queries, but the collected queries do not include parameter values.
I other words I can see something like this:
DELETE FROM users WHERE id = #id
But what I would like to see is this:
DELETE FROM users WHERE id = 12345
I guess there are some additional events or Columns I need to collect in the profiler, but I don't know which. I am currently using the "TSQL_LOCKS" template.
Any hints would be greatly appreciated.
Thanks,
Adrian
Disclaimer: I've asked a similar question before, but I guess it was too specific, which is why I got no replies. I'm starting another attempt with this one.
I think you need the RPC:Completed event:
http://msdn.microsoft.com/en-us/library/ms175543.aspx
The Profiler will contain the parameter values in the RPC:Completed/RPC:Starting events. But you already got replies telling you this.
What I want to add is that is very little need to know the parameter run-time values in order to analyze a deadlock graph. First, because if 'users' is involved in the deadlock, the deadlock graph itself will give away what #id is the conflict, if the conflict is on a key. Second, more importantly, for a deadlock scenario is irrelevant the exact keys that are involved. Is not like a deadlock happens because one deletes user with id 123 but will not happen when it deletes user 321.
If you decided to ask on SO in the first place, I think the best would be to post the actual deadlock graph and let the community have a look at it. There are many here that can answer quite a few questions just from the deadlock graph XML.
Start a trace with the following events having all checkboxes checked:
SQL: BatchCompleted
SQL: BatchStarting
Deadlock graph
Lock:Deadlock
Lock:Deadlock chain
After the deadlock occurs, stop the trace, then click on the deadlock graph event class.
This should give you a good idea of what's going wrong.
If you're using a stored procedure (which it looks like you are) or Hibernate/NHibernate you might need to turn on the Stored Procedures starting event (SP:StmtStarting) and RPC:Starting event. This will show the parameters in it's own line after the query.
Something like:
SP:StmtStarting DELETE FROM users WHERE id = #id
RPC:Starting exec sp_execute 12345