I'm running SQL Server 2005 and using IIS for ASP scripts.
I have a problem with sql that is when I run a sql query (exp : http://[host name] with localhost as [host name]) at first time (like when I start my windows) or when the session times out due to being idle for too long, this error happens :
Login Timeout Expired
but after that when I refresh the page, everything will be OK and it works like it should be.
It looks like it takes a long time to run the sproc the "first" time, from then on it only takes less than a sec to execute the sproc.
SQL Server will generate a execution plan for the stored procedure when it runs the first time, so it will cause a long duration. Then next times SQL can reuse the exection plan so the duration becomes shorter. However a duration of 46secs is abnormal, you can try to create a clustered index on the table, in order to speed up query.
Related
We are using dbeaver quite happily with Snowflake back end but I can't execute queries that last around 5 minutes or more.
It looks like there is sometimeout somewhere and the execution seems cancelled by DBeaver.
The error message is "SQL Error [604] [57014]: SQL execution canceled"
Any idea how I could instruct DBeaver to wait for whatever it takes?
This is probably because the STATEMENT_TIMEOUT_IN_SECONDS parameter has been set to cancel all queries after they run for 5 minutes or more.
You can check what it is set to by running this in dbeaver.
show parameters like '%STATEMENT_TIMEOUT%' in session;
I run same JAVA application (spring/hibernate) on different system both use same SQL Server version.
I'm using SQL Server Profiler to trace a query which I run (exactly same) on both systems.
This is my SQL Server version on both system:
Trace System 1 : slow-system2.trc query takes randomly between 100 - 300ms
Trace System 2 : fast.trc query takes randomly between 10-20ms
It seems here on slow-screenshot a query of "use database" takes "331ms" compared to fast.trc (0ms= :
What can cause this difference just by running "use database" query ?
I tried on a 3th system running on sql express which is too slow here is trace
It seems here on "sql express" it is due to the fact I have two additional classEvent Audit Logout that takes time :
Maybe I missed out some option on SQL Server?
The long duration of the USE statement indicates the database may be set to AUTO_CLOSE ON. Overhead is incurred during database startup when it must be opened.
The setting can be changed with:
ALTER DATABASE [YourDatabase] SET AUTO_CLOSE OFF;
When I am executing a select statement with 4 'inner' joins and two 'WHERE' conditions it took 13-15 s in local SSMS (I have executed 5 times). But when I connect the same instance from another server's SSMS and execute the same query it took 5 s to execute first time and then it took 0 s! I am using the same user SA.
Is there any possible explanation for that?
Host instance is SQL 2008 and Remote instance has SQL 2008 R2.
If your query is returning data to display in your local SSMS then this data needs to be transferred from the server to your local SSMS. The time to transfer the data from the server to your local SSMS is included in the execution time. So, the execution time is a combination of executing the script and fetching the data in order to display it.
You might want to "Include Client Statistics" and then review the row "Bytes received from server" in the "Client Statistic" tab of the result window.
In order to verify my assumption you can alter your select only to execute without fetching the data.
I am using asp.net (version 4) and am trying to run a stored procedure which I have created
ALTER PROCEDURE [dbo].[some_proc]
AS
BEGIN
INSERT INTO [dbo].[some_proc](Creation_Date)
VALUES (getDate());
select SCOPE_IDENTITY();
END
The procedure runs fine when called from within server management studio (runs in less than a second) and also runs fine from my web app UNTIL the afternoon (about 3pm), at which point I get a timeout error, as below:
The request channel timed out while waiting for a reply after 00:00:29.9969982. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
Other stored procedures that I try and run and return expected results. All the stored procedures query the same database.
I have reviewed several other answers on similar questions but they haven't helped me regarding this situation.
I realise this issue may be very specific to my situation, and if it is then my question would be how do I start to debug this issue (any tools or techniques would be really helpful)
You could run a SQL Server Profiler session recording database activity between 2.30 and 3.30
also check SQL Server Agent for any jobs that start around that time
I have a stored procedure that I've tested over and over again in SQL Server Management Studio and it works fine, returning results in roughly 3 seconds; however, when I add the Stored Procedure as the Query Type for a new DataSet in Report Builder and attempt to, either run the report or execute the SP through the built-in Query Designer the execution call times-out. I haven't even used the dataset yet in any area within the report (Tablix's or Charts).
I've made sure that the Data Sources credentials are setup properly and even tested the connection to the DB and received a successful connection statement.
I have the Dataset Time out property set to 0 which should mean no timeout. Clearly, the timeout I'm receiving is being handled by the SQL Server rather than the Report Builder in this particular case.
What would make the Stored Procedure execute properly and efficiently (speed-wise) when executed from the server, but time-out when executed from Report Builder?
I'm running 2008 R2.
Please help! Thanks in advance.
Most time-out errors occur during query processing. If you are encountering time-out errors, try increasing the query time-out value. Make sure to adjust the report execution time-out value so that it is larger than the query time-out. The time period should be sufficient to complete both query and report processing.
Thanks
Venky