Does SqlServer has to start a Scan to execute a stored procedure?
In Sql Profiler I can see this:
RPC Starting ( exec sp_Edu3_SelectExamSession #ExamSessionId=N'AccessCode39361814' )
Scan:Started
Scan:Started
Scan:Started
RPC Completed ( exec sp_Edu3_SelectExamSession #ExamSessionId=N'AccessCode39361814' )
Can I somehow see what's happening in the Stored Procedure? Different queries are done in that SP, but they do not seem to appear in Sql Profiler (maybe I need to check some more events?)
The Scan:Started are probably scans by the queries in the sp? Or not?
When you launch profiler, there is a template where you can see stored proc line by line execution. It's something like "SQLProfilerTSQL_SPs" from memory.
The Scan event may be associated, it may not: it depends on the filters you have set.
Related
I've got a stored procedure with an int output parameter. If I run SQL Server Profiler, execute the stored procedure via some .Net code, and capture the RPC:Completed event, the Text Data looks like this:
declare #p1 int
set #p1=13
exec spStoredProcedure #OutParam=#p1 output
select #p1
Why does it look like it's getting the value of the output parameter before executing the stored procedure?
I found an answer that it is RPC:completed event class. so it already know the result at that time. But I cant understand why exec statement is there, after completion of RPC:completed event.
The RPC Completed TextData you see in the Profiler (or Extended Events) trace is just a rendering of the RPC request, not the actual statement that was executed by SQL Server. This facilitates copy/paste of the text into an SSMS window for ad-hoc execution as a SQL batch.
Since the actual output value is known after the RPC has completed, the trace text uses the actual value to initialize the parameter variable. It would probably be clearer it was initialized to NULL prior to execution.
I'm not sure if this is possible but if so, my scenario would be about as simple as they come. Assuming I have 6 stored procedures called:
dbo.SyncSources
dbo.SyncData
dbo.UpdateStatistics
dbo.TruncateSourceTable
dbo.ValidateData
dbo.SearchData
None of them require any variables to be input, they simply need to be executed in the order in which they appear above. Can I create one stored procedure that will run all of them, sequentially? Keep in mind that some of the middle ones in that list take several hours to run. Also, this is on an Azure Cloud database, so SQL Server Agent is unfortunately not an option.
You can try this
create procedure OneProcedureTorunThemAll
as
begin tran
exec dbo.SyncSources
exec dbo.SyncData
exec ...
commit
it could be nice to catch errors, verify return values, etc.
We have Inbuilt store procedures in SQl server, I want to know where the execution plan builds for default store procedures? for exame : Sp_who2.
The execution plans for system stored procedures are stored in the same place as normal stored procedures. You can access them using something like:
USE Master;
SELECT c.plan_handle, q.query_plan
FROM sys.dm_exec_cached_plans AS c
CROSS APPLY sys.dm_exec_query_plan(c.plan_handle) AS q
WHERE q.objectid = OBJECT_ID(N'dbo.sp_who');
I suspect that you might actually be after the definition, because needing the execution plan of these strikes me as a little odd, because the main reason for needing an execution plan is performance tuning. So assuming that you are after the procedure definition, you can get this using:
USE Master;
SELECT [definition]
FROM sys.system_sql_modules
WHERE object_id = OBJECT_ID(N'dbo.sp_who');
Or in SQL Server management studio, you can find the procedures under Databases > Programability > Stored Procedures > System Stored Procedures, then right click and choose modify:
I would like to know whether my stored procedure will get impacted without specifying Go
Here is the code flow:
Create or replace store_proc1
As
Begin
While loop
{SQL statements repeating itself until source table record count is 0}
End
"Go"
Here I have missed Go at the end of my stored procedure.. Will it impact the performance?
GO is not a SQL statement - it's a delimiter used only in SQL Server Management Studio.
So no, omitting GO will NOT in any way affect your stored procedure's ability to run, nor it performance.
What is the difference between ; and GO in stored procedure in SQL Server ?
Actually, if I have a stored procedure in SQL server and wanna to put t separate queries inside it which the first one just calculates number of records (count) and the second one selects some records based on some conditions, then what should I use between that two queries?
Go or ;
; just ends the statement.
GO is not a statement but a command to the server to commit the current batch to the Database. It creates a stop inside the transaction.
http://msdn.microsoft.com/en-us/library/ms188037.aspx
(Update, thanks for the comments):
GO is a statement intended for the Management studio as far as I know, maybe to other tools as well.
The semicolon separates queries, the GO command separates batches. (Also GO is not a T-SQL command, it's a command recognised by the sqlcmd and osql utilities and Management Studio.)
You can't use GO inside a stored procedure. If you would try, the definition of the procedure will end there, and the rest will be a separate batch.
A local variable has the scope of the batch, so after a GO command you can't use local variables declared before the GO command:
declare #test int
set #test = 42
GO
select #Test -- causes an error message as #Test is undefined
I know this thread is old but I thought these other uses/differences might be handy for other searches like myself regarding GO.
Anything after the GO will not wind up in your sproc because the GO will execute the CREATE/ALTER PROCEDURE command. For example, if you run this...
CREATE PROCEDURE X AS
SELECT 1 As X
GO
SELECT 2 As X
Then after running it you go back in to edit the procedure you will find that only the SELECT 1 As X is in there because the GO created the sproc and anything after it is assumed to be the next thing you are doing and not part of the sproc.
I'm surprised I haven't seen this mentioned much out there but the batch separator is not only specific to the program you are querying with but in the case of SSMS it is actually user editable! If I went into the settings and changed the batch separator from GO to XX then in my copy of SSMS, XX executes the batch not GO. So what would happen if I tried to execute a stored procedure that contained GO?
Think of GO as a way of telling SSMS to send whatever is above it to the server for execution. The server never receives the GO as that is just there to mark the end of a batch of command you want SSMS to send to the server.
If you have a scenario where you need to control execution flow in your stored procedure then you can use BEGIN TRANSACTION and COMMIT TRANSACTION for that and those are allowed in stored procedures.
GO is not a command to the server, it's the default batch separator for most of the client tools the MS supply. When the client tool encounters "GO" on a new line by itself, it sends whatever commands it has accumulated thus far to the server, and then starts over anew.
What this means is that any variables declared in one batch are not available in subsequent batches. And it also means that multi-line comments can't be placed around a "GO" command - because the server will see the first batch, and see an unterminated comment.
It marks the end of a batch in Query Analyzer and
therefore signals the end of a stored procedure definition in that batch.
As much as i know its not a part of sp.
GO isn't a TSQL command.
And ; just ends the statement.