I'm reviewing dozens of SQL Server 2017 stored procedure query execution plans. I just noticed that one of the stored procedures is named "getDate". The procedure "seems" to work, and according to this "getDate" isn't a reserved keyword, but I'm bothered by the potential confusion with the GETDATE() function. I don't have a lot of time right now to comb through all of the potentially impacted code modules editing calls to this stored procedure. Is this something I can ignore for now and fix later, or is it likely causing problems such that I should fix it right away? I don't see any problems, apart from (presumably unrelated) super-slow running queries--which is why I'm reviewing the execution plans.
The estimated execution plan for this "getDate" stored procedure looks OK though.
It's not recommended to keep the same name for the stored procedure. It would create so much chaos when you think long run and if you have enough time and privilege, change the name using SP_RENAME proc.
But at the same time, it would not throw error. Because GETDATE function is a database object in SQL Server and supports only SELECT or read data. What we can create is a stored procedure with the same name of database objects. So we are able to do DDL things to the user defined database objects.
Related
I'm 100% convinced this is a duplicate but after more than an hour of searching I just can't seem to find the answer.
When using special procedures (i.e. the sp_ ones like sp_executesql), is it wise to use the full 3-part identifier master.dbo (or master..) or just use them as is? I'm looking for the most performance optimized version of this:
1. sp_executesql
2. master..sp_executesql
3. master.dbo.sp_executesql
Are 2 and 3 identical in terms of performance specifically regarding the above (i.e. referencing master) and is it safe to user master.. or should you not risk it even on master since someone could still create another schema there at some point?
Much appreciated.
TL;DR;
Shouldn't be any noticeable performance difference.
The long story:
Whenever you are executing a stored procedure that starts with the sp_ prefix SQL Server will first search for it in master.dbo, so all three options should have the same performance.
From an article posted by Eric Cobb in 2015 entitled Why you should not prefix your stored procedures with “sp_”
Whenever SQL Server sees “sp_” at the beginning of a stored procedure, it first tries to find the procedure in the master database. As stated in the Microsoft documentation above, “This prefix is used by SQL Server to designate system procedures“, so when SQL Server sees “sp_” it starts looking for system procedures. Only after it has searched through all of the procedures in the master database and determined that your procedure is not there will it then come back to your database to try to locate the stored procedure.
Also, it quotes another official documentation (with a link to 2008 version, working on finding current version):
A user-defined stored procedure that has the same name as a system stored procedure and is either nonqualified or is in the dbo schema will never be executed; the system stored procedure will always execute instead.
That quote, even though I couldn't find in the documentation of current version, I can easily prove.
Consider the following script:
USE <YourDatabaseNameHere> -- change to the actual name of the db, of course
GO
CREATE PROCEDURE dbo.sp_who
AS
SELECT 'Zohar peled' as myName
GO
-- change to the actual name of the db, of course
EXEC <YourDatabaseNameHere>.dbo.sp_who
EXEC dbo.sp_who
EXEC sp_who
GO
DROP PROCEDURE dbo.sp_who -- cleanup
When tested on 2016 version (which is the server I've had available for testing),
All three exec statements executed the system procedure. I couldn't find any way to execute my procedure.
Now I can't fiddle around with the master DB on my server, so I can only show that it's true for existing system procedures, but I'm pretty sure that it's going to be the same for any procedure that starts with the sp_ prefix, even if you wrote it yourself to both the master database and your own, as Aaron Bertrand illustrated on his article under the title Another side effect : Ambiguity
However, even if that wasn't the case, unless having many procedures in the current schema, and running the stored procedure in a tight loop, I doubt you'll see any noticeable performance difference.
Later on in the same article:
As alluded to in the previous point, procedures named with “sp_” are going to perform slower. It may not always be noticeable, but it is there. Connecting to DatabaseA, jumping over to the master database and scanning every stored procedure there, then coming back to DatabaseA and executing the procedure is always going to take more time than just connecting to DatabaseA and executing the procedure.
Note that this paragraph is talking about performance issues executing a user-defined stored procedure that has the sp_ prefix - so let's reverse this process for a moment:
Suppose SQL Server would have to scan all the stored procedures in the current schema, and only then, if not found, go to Master.Dbo and start looking there.
Easy to see the more procedures you have in the schema the longer it takes. However - have you ever noticed how long it takes SQL Server to find the procedure it needs to run?
I've been working with SQL Server since it's 2000 version, and I've had my share of databases containing hundreds of procedures all cramped up in the same schema - but that was never a performance issue.
In fact, in over 15 years of experience with SQL Server, I've never encountered a performance issue caused by the time it takes SQL Server to find the stored procedure it needs to run.
A few days ago I was asked this question(tel intvw) and I was drawn blank. I said execution plan is stored in the server so its called STORED Procedure. But I am not sure I was correct.
My research after that has shown that there is plan cache or procedure cache inside of SQL Server that's dedicated to storing execution plans. In that article there is also reference to what is called compiled plan stub. So it appears that Compiled Plan Stub is first created and then execution plan is created.
So what I wanted to know is briefly
What are the steps that happen when I create a stored procedure?
Why is a Stored Procedure called stored procedure(if the question makes sense)?
If you can refer me to an existing SO question or some other article, that should also be fine.
Why is a Stored Procedure called stored procedure
Because it is a procedure that is stored in a database.
In other languages/environments, procedures that can be executed aren't usually stored. They are compiled in either bytecode or assembler. I.e. the procedure does not exist in its original textual form anymore. The original procedure cannot be retrieved as it was when it was created in those environments (although reverse engineering can retrieve the essence of that procedure).
When you create a stored procedure in SQL Server, it is completely stored in its original full-text form, same indentation, same casing, same lines, including comments and all. You can retrieve the text with which you created the stored procedure in its entirety.
Simplified explanation about executing a stored procedure
When SQL Server wants to execute a stored procedure, it will first check the cache to see if it has been compiled already. If it finds an entry in the cache (in the form of an execution plan) it will use this entry to execute. If it doesn't find an entry it will compile the procedure into an execution plan, store it in the cache for later use, then execute it using the execution plan.
There are cases that force a stored procedure to be recompiled, e.g. when the execution plan cache is cleared (schema changes, statistics updates, ...) or when supplying commands to the compiler that force recompilation (stored procedure WITH RECOMPILE, query option OPTION(RECOMPILE), ...).
I said execution plan is stored in the server so its called STORED Procedure.
Wrong. Execution plans also are stored on the server for dynamic SQL. I have no real idea why it is called as stored procedure, but the procedure as a whole is stored on the server (code etc.). I can assume this is the reason - but the execution plan (cache) is irrelevant here, because all execution plans are possibly stored there.
For 1: what do you care? Obviously a SQL Statement is executed. There is some parsing, to make sure it is valid. The rest is an implementation detail - and may vary even between versions. I would assume a SP is stored in some level of bytecode - but again, who cares? I do database level development for 25 years and that never even came into my consideration.
I have a question: let's say I have a procedure which contains dynamic SQL inside the definition of procedure, so when I execute the procedure for the first time, it's obvious that it compiles the procedure and stores the plan for first time.
What happens during the second run? Will the same plan be used or will the procedure go for a recompile as it contains dynamic SQL in it?
Dynamic SQL is always compiled. It may result in the same execution plan as the first run (totally dependent on parameters).
I would suggest reading this article from MS. Relevant quotes:
Recompilations: Definition
Before a query, batch, stored procedure, trigger, prepared statement, or dynamic SQL statement (henceforth, "batch") begins execution on a SQL Server, the batch gets compiled into a plan. The plan is then executed for its effects or to produce results.
and
Compiled plans are stored into a part of SQL Server's memory called plan cache . Plan cache is searched for possible plan reuse opportunities. If a plan reuse for a batch happens, its compilation costs are avoided.
A similar question has already been answered in Stack Exchange for Database Administrators. Please refer: https://dba.stackexchange.com/questions/47283/when-does-sp-executesql-refresh-the-query-plan
I have a stored procedure in MS SQL Server that uses a Sybase linked server. Each time the stored procedure is executed it runs for a long time and looks like it is recompiling before execution. Any idea how to stop this recompilation?
its hard to believe that recompilation taking this much time. I suspects this procedure using some old plan to execute which is not optimized.
few points to check.
excute with recompile option. which make new query plan.
check which query inside the proc taking long time. if MDA tables installed check in mosSysStatement. or check in master..sysprocesses table while running that stored proc. it would show statement number which is currently running. it would give you fair idea which statement taking.
run update statistics on tables used by stored proc.
Thanks,
Gopal
I was wondering if you guys could help me get to the bottom of a weird problem I have recently had on SQL Server.
I have a stored procedure (lets call SPold) which is reasonably large with a lot of calculations (can't possibly do this in app as info for around 6000 users needs to come back in a one-er (I reduce this to 1000 based on Surname)). The stored procedure usually executes in a couple of seconds, and is called once every couple of minutes.
Now this morning, the stored procedure was suddenly taking 4-10 times as long to execute, causing a number of timeouts. I discovered that by making a copy of the procedure with a new name (SPnew) and executing, I would get the fast execution times again. This indicated to me that the execution plan was the problem with the original, SPold, so I decided to execute it with recompile. This would return the results a quicker (although not as fast as SPnew), but subsequent calls from users to SPold were once again slow. It was like the new plan wasn't being kept.
What I have done is to fix this is put Exec SPnew into SPold, and now calls to SPold are returning fast again.
Does anyone have any idea what is going on here? The only thing that updated overnight was the statistics, although I think that this should affect both SPold and SPnew.
Sounds like you are experiencing an incorrectly cached query plan due to parameter sniffing.
Can you post the stored procedure?
Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005
I Smell a Parameter!
In SQL Server 2005, you can use the OPTIMIZE FOR query hint for preferred values of parameters to remedy some of the problems associated with parameter sniffing:
OPTIMIZE FOR Instructs the query optimizer to use a particular value for a local
variable when the query is compiled and optimized. The value is used
only during query optimization, and not during query execution.
OPTIMIZE FOR can counteract the parameter detection behavior of the
optimizer or can be used when you create plan guides. For more
information, see Recompiling Stored Procedures and Optimizing Queries
in Deployed Applications by Using Plan Guides.
Although SQL Server 2005 does not support OPTIMIZE FOR UNKNOWN (introduced in SQL Server 2008) which
will eliminate parameter sniffing for a given parameter:
OPTION (OPTIMIZE FOR (#myParam UNKNOWN))
You can achieve the same effect in SQL Server 2005 by copying the parameter into a local variable, and then use the local variable in the query.
I've also encounterred two "strange" cases with Sql Server 2005, which might relate to your problem as well.
In the first case my procedure executed prety fast, when being run as dbo, and it was slow when being run from the application, under a different user account.
In the second case the query plan of the procedure got optimized for the parameter values with which the procedure was called for the first time, and this plan was then reused later for other parameter values as well, resulting in a slow execution.
For this second case the solution was to copy the parameter values into local variables in the procedure, and then using the variables in the queries instead of the parameters.