The site is ASP.NET 2.0, using LINQ to SQL. Database is SQL Server 2008 R2.
Been working on an issue where performance suddenly took a huge drop one day and has remained that way since. Cannot figure out why. It has been just certain functionality of the site, not necessarily a site-wide problem. Have focused on a particular stored procedure in general that is taking a good 1000ms+ showing in profiler. When copying the TextData and running right in the query analyzer, it runs much quicker.
Have tried a sp_recompile on the stored procedure as well as the table used. The db server was restarted during a maintenance period and that also did not stabilize things. Is there any possible troubleshooting steps anyone could provide to help dig deeper on this? Absolutely stumped.
It could be a parameter sniffing problem. You can see the details here - http://blogs.msdn.com/b/turgays/archive/2013/09/10/parameter-sniffing-problem-and-workarounds. As suggested in the blog, you can try the following -
OPTION (OPTIMIZE FOR (#VARIABLE=VALUE))
OPTION (OPTIMIZE FOR (#VARIABLE UNKNOWN))
Use local variables - Basically declare local variables and assign the value of the parameter to local variable and use the local variable in the query.
OPTION (RECOMPILE) - Since you have already tried that you can ignore this
Could you post the query snippet which is causing this issue?
Related
I am completely baffled by SQL Server and OPENROWSET permissions.
Our team has an AD Group. This group is included in the DEV server's Windows Administrators local group. This same AD group has SysAdmin privilege on the local installation of SQL Server 2017.
Attempting to run the command:
SELECT *
FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0','Excel 12.0;Database=C:\Work\test.xls;HDR=YES',['sheet1$'])
works for me, but for none of my teammates.
If there is a definitive document on the security requirements for using the OPENROWSET command - I have not found it (and please - don't refer me to learn.microsoft.com - that documentation is not written in any way that I understand).
There are other issues I have found including if I change the name of the sheet in the Excel workbook - the command fails (and yes - I closed the book after making the change).
Finally - some feedback on the use of OPENROWSET - is it generally a good idea? a bad idea? pretty much neutral but be prepared for these kinds of problems?
I hope this question is specific enough to be answered - I have probably spent 20+ hours trying to figure out how to understand how this works so I can make it work and use it consistently.
Thanks!
So honestly troubleshooting security/permissions and errors with SQL Server is probably the most frustrating aspects of my job.
First few questions and thoughts about your dilemma.
Do you really want to be granting your team connected to your db
sysadmin rights? I wouldn't do that period, full-stop.
Will the data be refreshed? If yes, I suggest you ingest this data
into a sql table with a process, perhaps python, ssis, dts package,
powershell, whatever you fancy.
If the data will always be static in that one excel file, I'd suggest perhaps making it act like a linked server for (hopefully) fewer permission issues? Also, it's easier to query that way, from my memory.
In any event, this article (non msdn link) may help? I've done it this way once before and had slightly less of a difficult time, but then again it involves adding a driver (usually) to the sql server. BUT, then I did not have to allow multiple users sysadmin - and I think ANYTHING is better than that.
https://www.sqlshack.com/query-excel-data-using-sql-server-linked-servers/
Sometimes the issue is not with the user running the query, but SQL Server using the account it runs as - to get permissions on the file. This article goes over that aspect as well. I'm not sure that is your issue as you say it works for me but not for thee, but maybe read that portion of the article at least?
I have a problem with a query running on Microsoft SQL Server 2012.
This query selects articles out of different stores and ran fine over months, within under one second.
Several weeks ago, this query suddenly started taking a very long time to finish - 50 seconds or more - but only for one of our stores.
If I clear the query plan cache for this one SELECT statement, then the query takes less than one second to finish again.
Unfortunately, this problem occurs only very sporadically and only on our productive server, so I have no chance to analyze the problem.
I restarted the server few weeks ago and the problem did not occur until yesterday (before every three days).
Do you have any idea or tip for me to solve this problem?
It is definitely looks like a parameter sniffing issue.
Read more about Parameter Sniffing
You can try following options.
1- Use Dummy variables on SQL Server stored procedure or function used.
2- Alter SP WITH RECOMPILE Option.
3- Use hints like OPTION(RECOMPILE) or OPTION (OPTIMIZE FOR (#VARIABLE=VALUE))
4- Disable Parameter sniffing on SQL instance.
You can read more about this on MSDN for recommendation and workarounds here
I've written my website using ASP.NET MVC and SQL Server (used a SQL Server instance which ran locally on my machine).
I'm about to upload my site to a hosting provider. However, his DB works under MySQL. I don't care about the data already in the DB itself. It's mostly mock data and a few tables which I don't mind rewriting. But how do I go about the transition from SQL Server to MySQL? How does this influence my queries inside my code? is it the same code syntax? Will I have to recreate the table definitions? In my project I used LINQ to SQL.
Am I forced to look for a host with SQL Server capabilities (i.e. licenses)? (I hope not...)
Thanks!
You may be able to transition smoothly, but I greatly doubt this will be the case.
The differences are many and whether you could depends on what features you used when developing.
If you kept to one of the standards, you may be in luck.
See a comparison sheet on wikipedia.
In regards to the Linq aspect of your question - you should be able to use a Linq provider for MySql instead of MSSql without a problem.
Here is a link to one: http://code2code.net/DB_Linq/
If you do decide to go with the MySql hosting, I suggest you test all aspects of you application to ensure they are working as expected.
LINQ to SQL works with MS SQL Server only...so if you want to keep using it, you need to find a host with a MSSQL database.
Does anyone know how to set the timeout on a stored procedure? Found some examples on the NET, e.g sp_configure 'remote Query Timeout', 5, but this did not work. Also found some commands "DBPROP_COMMANDTIMEOUT" and "DBPROP_GENERALTIMEOUT" but i don't know if they are the right ones to use and if they are, how to use them in my transact-SQL code.
As Chris Tybur said, you can not the the query timeout for a stored proc in the stored proc or on the SQL Server.
CommandTimeout is a client concept: the client will abort the query after a certain amount of time. There is no dead man's timer or mechanism for a stored proc to abort itself /or any query). SQL server will allow a query to run forever.
The "Remote Query Timeout" is exactly that: timeout when SQL Server makes a remote call, when SQL Server itself is the client of another server. It says in the description:
This value applies to an outgoing
connection initiated by the Database
Engine as a remote query. This value
has no effect on queries received by
the Database Engine.
A recent question with good info: timeout setting for SQL Server
I have never heard of setting a timeout for executing a stored procedure on the server side. Usually you would specify the timeout for the command that runs the procedure in the data provider you are using, such as ADO.NET.
Wait - the real question is, "What is happening that you want to prevent?" Everyone has focused on server-side, client-side but in truth we don't know why you are asking this question (and it's important).
And another "why": why do you want to set a timeout on a "stored procedure"? Why not a view, a function, or a query? Did you use the term "stored procedure" for a particular reason or would you just be interested in learning how to set a timeout in T-SQL?
I'm asking because I wonder if you are having locking issues and perhaps SET LOCK_TIMEOUT 1000 or WITH(NOLOCK) might be what you really need. Without more info though I can't say. If you can give us more feedback on why you are asking, what is happening, and what ultimately you want to have happen if your "timeout" is reached, maybe we can help more.
Bottom line: Yes, you can set a timeout in T-SQL and yes you can stop the execution of a stored procedure with T-SQL. But I don't know enough about what you want to offer advice on where to look or to give you more info. I'm kinda scared that I've already said too much :)
This article has a very good explanation on query timeouts and how they're a client-side concept only. You can set the query timeout in SQL Server management studio from the Tools|Options menu.
You have to set the timeout when you execute the stored procedure on the client. As far as the SQL Server goes, it'll let the stored procedure run for ever unless told to cancel it.
In a project of mine the SQL statements that are executed against a SQL Server are failing for some unknown reason. Some of the code is already used in production so debugging it is not an easy task. Therefore I need a way to see in the database itself what SQL statements are used, as the statements are generated at runtime by the project and could be flawed when certain conditions are met.
I therefore considered the possibility to monitor the incoming statements and check myself if I see any flaws.
The database is running on a SQL Server 2005, and I use SQL server management studio express as primary tool to manipulate the database. So my question is, what is the best way to do this?
Seeing how you use the Management Studio Express, I will assume you don't have access to the MSSQL 2005 client tools. If you do, install those, because it includes the SQL profiler which does exactly what you want (and more!). For more info about that one, see msdn.
I found this a while ago, because I was thinking about the exact same thing. I have access to the client tools myself, so I don't really need to yet, but that access is not unlimited (it's through my current job). If you try it out, let me know if it works ;-)
Best way is to fire up profiler, start a trace, save the trace and then rerun the statements