I am trying to validate the performance issues in my project I found some thing tricky
DECLARE #T DATETIME2
DBCC DROPCLEANBUFFERS
SET #T =GETDATE()
SELECT SUM(cost)
from tblLog
WHERE logID <=100000
PRINT cast(DATEDIFF(ms,#T,GETDATE()) as NVARCHAR(255))+' Milli seconds'
DBCC DROPCLEANBUFFERS
SET #T =GETDATE()
SELECT SUM(cost)
from tblLog
WHERE logID <=100000
PRINT cast(DATEDIFF(ms,#T,GETDATE()) as NVARCHAR(255))+' Milli seconds'
When I am executing above code whole at once (same query twice) even though I am cleaning buffer pool memory always second execution is taking lesser time when compared with first could please explain what is missing in this case.
Sample output:
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Warning: Null value is eliminated by an aggregate or other SET operation.
(1 row(s) affected)
(1 row(s) affected)
403 Milli seconds
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Warning: Null value is eliminated by an aggregate or other SET operation.
(1 row(s) affected)
(1 row(s) affected)
103 Milli seconds
Related
I want to see how many rows are affected for each DDL statement that is run by a query, so I set SET NOCOUNT OFF at the start of each query that is run.
Sample query:
SET NOCOUNT OFF;
GO
BEGIN TRY
BEGIN TRANSACTION
UPDATE dbo.tbProvClause SET ClauseTemplate = 'Clause1' where DocumentName = '\Templates\EndorsAccessPlainLanguageQCEng.CDS';
UPDATE dbo.tbProvClause SET ClauseTemplate = 'Clause 2' where DocumentName = '\Templates\EndorsEnforcedRemovallLtdMktPublicPropertyQCEng.CDS';
UPDATE dbo.tbProvClause SET ClauseTemplateFR = 'Malgré French Clause 1' where DocumentNameFR = '\Templates\EndorsAccessHOPPQcFr.CDS';
UPDATE dbo.tbProvClause SET ClauseTemplateFR = 'Malgré les exceptions Clause 2' where DocumentNameFR = '\Templates\EndorsEnlèvementFTNdomainepublicERLMPublicPropertyQcFr.CDS';
COMMIT TRAN
PRINT 'Script Completed With Success - Changes committed on ' + CAST(current_timestamp AS varchar(25))
END TRY
BEGIN CATCH
--
END CATCH
GO
and it returns
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
Script Completed With Success - Changes committed on Nov 29 2017 12:10PM
This is good. But when I run the same in SQLCMD, I get only 1 row .i.e.
sqlcmd -S testserver -dTestDB -i StackOverflowSQL.sql
(1 rows affected)
Script Completed With Success - Changes committed on Nov 29 2017 12:24PM
How do I retain the ability of the SET NOCOUNT OFF in SQLCMD? The reason I asked this question is that I have a number of scripts that I want to batch using SQLCMD and I will be saving their logs. In this case, the SET NOCOUNT OFF is very useful in checking how many lines of 1 rows affected will give a feedback that the run was successful.
Try something like this and see if it works.
use -v (small letter v).
sqlcmd -v NOCOUNT=OFF -S testserver -dTestDB -i StackOverflowSQL.sql
Or
In the same command prompt first run SET NOCOUNT=OFF before calling sqlcmd .
Look into below documentation link and search for "Variable Precedence". You will get some idea.
https://learn.microsoft.com/en-us/sql/tools/sqlcmd-utility
It's just a hunch. Remove the Go statement after "set nocount off".
First of all "set nocount off" statement does not require a GO. Secondly, I think GO (A batch executor) may be setting the option only for that batch.
There is a rather stupid workaround if my suggestion does not work.
You can:
print ##rowcount
after every sql statement which you may be interested to monitor the row counts.
Found the problem. There were multiple versions of SQLCMD installed in the machine. To find out which version I was using:
E:\Test>where sqlcmd
C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE
C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\SQLCMD.EXE
The one that I was using was SQL Server 2008 R2 version. the I looked into the system environment variables PATH and changed the order and now it uses the SQL server 2012 version. After changing the PATH
E:\Test>where sqlcmd
C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\SQLCMD.EXE
C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE
E:\Test>sqlcmd -S testserver -dTestdb -i StackOverflowSQL.sql
(1 rows affected)
(1 rows affected)
(1 rows affected)
(1 rows affected)
Script Completed With Success - Changes committed on Nov 29 2017 3:37PM
It works!
I have multiple INSERT / SELECT statements as part of a single SQL data import script. When I run my script I get the output
(141926 row(s) affected)
(124366 row(s) affected)
(4 row(s) affected)
(1 row(s) affected)
But what I would really want is
(141926 row(s) affected) - Customers Deleted
(124366 row(s) affected) - Customers Inserted
(4 row(s) affected) - Customers missing last name etc
(1 row(s) affected)
Is there anyway to do this in SQL??
I agree with #yorick de Wid, in that I don' think you can customise the SQL output.
The closest that I can think of in SQL Server is to "roll your own", by doing something like:
declare #recordsaffected int
<execute your SQL statement here>
set #recordsaffected = ##ROWCOUNT
print convert(varchar,#recordsaffected) + ' <your message here>'
The SSMS shows an extra (1 row(s) affected) every time when I execute insert/update. For example, execute the following SQL
declare #a table (a int)
insert into #a values (1), (2)
update #a set a = 3
And the SSMS will display the following message.
(2 row(s) affected)
(1 row(s) affected)
(2 row(s) affected)
(1 row(s) affected)
I didn't find any database/server trigger. What could cause the extra (1 row(s) affected)?
That usually means you have the actual execution plan option turned on. The execution plan is sent as an extra rowset, resulting in an extra (1 row(s) affected) message.
To disable actual execution plan press Ctrl+M.
this should not happen. try to look into the actual execution plan, what is happening there.
I found this post as I was getting the same issue but with no execution plan options turned on or triggers of any kind.
I had a very simple piece of code that would not normally have any rows affected at all:
DECLARE #dbname VARCHAR(50) = 'AdventureWorks'
If was testing some other features of SQL Server with Management Studio v18.10, the code above returned a couple of output rows that were not expected.
(0 rows affected)
(1 row affected)
Completion time: 2022-01-07T12:04:36.6414442+00:00
I my case I tracked it down to the connection settings where the Enable Always Encrypted (column encryption) option was checked / selected. I had been testing Always Encrypted, which uses encryption on parameters.
It only appears if the variable is declared and set in the same statement.
Setting the option for Enable Always Encrypted (column encryption) to unselected / unchecked fixed the reporting affected rows.
Added to help others who may find this issue.
Fitz
How can I disable the verbose output that gets printed on the console every time I run large queries in SQL Server 2005 Management Studio...
It keeps saying..
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
and keeps doing that.
I have some print statement in between the SQL, they all get lost! How can I turn this thing off ?
Use this statement on start of batch:
SET NOCOUNT ON;
There is Documentation on MSDN.
You need to write one statement prior your T-SQL.
SET NOCOUNT ON
Essentially, I want to do this in T-SQL
1) Execute SPROC1
2) Upon completion of SPROC1, execute SPROC2
3) Upon completion of SPROC2, execute SPROC3
I know this is possible using SSIS. If there any way I can do this?
Thanks
try this:
Execute SPROC1
execute SPROC2
execute SPROC3
SPROC2 will not run until SPROC1 is complete, and then SPROC3 will not run until SPROC2 is complete.
You can test it out:
CREATE PROCEDURE pTest1 AS
SELECT 1,GETDATE()
WAITFOR DELAY '00:00:02'
RETURN 0
go
CREATE PROCEDURE pTest2 AS
SELECT 2,GETDATE()
WAITFOR DELAY '00:00:02'
RETURN 0
go
CREATE PROCEDURE pTest3 AS
SELECT 3,GETDATE()
WAITFOR DELAY '00:00:02'
RETURN 0
go
EXEC pTest1
EXEC pTest2
EXEC pTest3
OUTPUT:
----------- -----------------------
1 2010-06-07 08:43:08.423
(1 row(s) affected)
----------- -----------------------
2 2010-06-07 08:43:10.423
(1 row(s) affected)
----------- -----------------------
3 2010-06-07 08:43:12.423
(1 row(s) affected)
For one DB call, use a wrapper
CREATE PROC SPROCwrapper
AS
EXEC SPROC1
EXEC SPROC2
EXEC SPROC3
GO
... or send 3 lines as per KM's answer.
SQL is sequentially executed