I have a .NET Windows application that runs large number of inserts in a SQL SERVER 2008 R2 database .
When I run the application on my laptop(also the database is on my laptop) it works fine.
But when I run it on a sever that is absolutely better than my loptop in any cases, it works at least 5 times slower.
In both case , databases are the same, applications are the same and data are the same .
what are the things that could effect on SQL Server performance (except for T-SQL )?
Uhhhhhhhh, a few things come to mind:
How do you know it's not a network issue?
What happens when you run some queries directly on an SSMS window in the server?
Are there other apps collocated on that server? Are they healthy?
Are you running out of disk space on the server? Are transaction logs filling up?
Have you run PerfMon stats against SQLServer to see if there are resource pressures from I/O, CPU, RAM?
Are you sure the databases are identical? Does the server have triggers that are not on your local database?
Are other users accessing the database simultaneously? Are they running queries that may be blocking your query?
Have you updated statistics on your server recently?
Are you running the exact same queries in both database? Different where clauses could be using indices completely differently.
Have you run an execution plan for a sample query in both databases and compared the results?
Are there errors in the SQLServer logs or event logs on the server?
Related
I tried to use Azure SQL Database with Tableau for visualizing data. First issue was that Tableau takes a huge time on connecting to db on start (about 10-30 minutes). After connecting it works fast. I provided some investigations and determined that the same situation happens when I try to expand tables list of database in Sql Server Management studio and then I run SELECT * FROM INFORMATION_SCHEMA.TABLES and have execution time ~10 min. Count of tables in db = 63. Tests was performed at single connection to db, so there was'nt any processes that can lock server and all another queries works fine.
Any ideas what exactly can affect so bad to performance?
There could be many reasons for slowness:
Your Azure SQL Database could be in lower performance tier
You might be located very far from your Azure SQL data center. Try to move the Azure SQL to a data center closer to your location
Please refer to link for any issues related to network latency: https://blogs.msdn.microsoft.com/azuresqldbsupport/2017/10/02/how-to-troubleshoot-slow-performance-after-moving-to-azure-due-to-network-latency/
My application has some queries (complex ones with fulltext-search). The queries usually run fast and often (let's say 30x/h). But periodically (lets say every two or three weeks) it looks like Sql Server drops the execution plan and the queries are extremely slow.
After running "EXEC sp_updatestats" the queries are fast again.
Anyone has an idea of what I can do to find the reason for this problem?
Installed SQL Server version is 13.0.4224.16, running on Windows Server 2016. The application doesn't make use of stored procedures.
I want to run sql profiler to see the performance of my database Sql Server 2008, but I'm afraid that running the profiler in the same machine it will affect the performance of the server, and I don't want to slow down ther server.
A long time ago I heard from a DBA than he run the profiler from his laptop connected to the sql server, in a way that it does not affect the performance of the server.
Si bassically my question is How to run Sql profiler from an external computer without causing slow performance of the sql server?
Any database being profiled has to do work in order for profiling to be possible - there is no way around it. Generally speaking, observation of a system always induces a load to that system. However, SQL Server Profiler and other similar tools also do ADDITIONAL work outside of the target db, and this additional work can be offloaded to another computer.
To offload what you can, you just run SQL Server Profile from ANY machine that is not the database server. When you start a New Trace, you tell it to connect to the database on whatever server the database is running on. That's all there is to it. Your target db will incur some additional load (unavoidable), but you will be offloading as much work as you can to whatever machine you run Profiler on.
If you are able to connect to the computer from external computer,then there would be no issues running profiler remotely as well..
So basically my question is How to run Sql profiler from an external computer without causing slow performance of the sql server?
When you run profiler for long periods of time ,it affects performance,since it has to keep track of all events in memory and log it before discarding ..So running profiler for long periods of time is not recommended..
You also can use extended events starting from SQL2008(very light weight relative to profiler) to track events similar to Profiler ..
http://www.sqlteam.com/article/introduction-to-sql-server-2008-extended-events
Profiler can be initiated from any computer with appropriate permissions and access, but it ALWAYS runs on the actual SQL Server instance. There is no way around this. You can minimize the operations that are logged and filter by a specific user to mitigate performance issues, but that's about it.
The DBA in question may have run a server side trace, which can be less impactful, but it's still inititated ON the appicable instance.
I am a DBA and I am not aware of any performance issues by running SQL Server Profiler on the server itself. That said when you run SQL Server Profiler It loads just like SSMS where you can select which server to use.
If you have a query that is running so long that its killing SQL resources yes running it at all will still use up resources but regardless of where the source of the profiler is.
See screenshot of SS Profiler
If you are concerned about performance on the SQL Server instance don't run Profiler in production during peak hours.
If you want to minimize the impact of SQL Trace then it is the best to use the server-side tracing:
https://msdn.microsoft.com/en-us/library/cc293613.aspx
Like that you can record the SQL commands into a trace file and SQL Profiler is closed. When you are done with the SQL command collection, you can copy the trace file and open it using SQL Profiler in some other computer. It is much better than runing SQL Trace directly through SQL Profiler (which is called the client-side tracing).
Running SQL Server 2014 Express on our domain. We use Windows Authentication to log on. All queries are performed in stored procedures.
Now, the system runs fine for all our users - except one. When he logs on (using our software), all queries take around 10 times longer (e.g. 30 ms instead of 2 ms). The queries are identical, the database is the same, the network speed is the same, the operative system is the same, the SQL Server drivers are the same, connection pooling is the same, DNS is the same. Changing computer does not help. The problem seems to be linked to the account being used.
What on Earth may be the cause for this huge performance hit?
Please advise!
I would try rebuilding the SP (by running an ALTER statement that duplicates its existing structure) to force SQL Server to recompile. I don't know every way SQL Server caches things but it can definitely create distinct execution plans for different types of connections so I wouldn't be surprised if your slow user is running a version with an inefficient execution plan.
http://www.sommarskog.se/query-plan-mysteries.html
When running a very simple query in SQL Server 2000.
SELECT getDate()
Most queries are sub second, but one query randomally in 10 takes about five seconds.
I am running these queries from SQL Server 2008 Management studio, but it occurs in other clients and on other machines as well, so it is not client specific.
The query is running to a server which is on the same network and there is no significant load on the server.
Can anyone tell me why this might be happening?
Sounds like network issues. We had the same thing happen when I worked for a large bank. Due to politics, it was out of our control.
You can do a few things to confirm this, like try running the queries from the server, etc.
The two things I would suspect without more information right off the bat are network latency and server load. Do you get this behavior when running the query from the database server machine itself? Do you get this behavior when running in single-user mode?