I have a problem in my application while executing a SQL query. I attached SQL Profiler to see the problem.
A query like
SELECT abc_id
FROM abc_Master
WHERE abc_name = #abcName COLLATE SQL_Latin1_General_CP1_CS_AS
AND (status=''active'' OR status=''live'')
is taking 60.102 seconds to execute.
I have noticed an audit login log record above this query log in server profiler trace list.
-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
Is this causing the delay? why is the query taking 60 secs to execute?
Related
I have two connections to the same db on the same server, with the same user,
as open windows in Sequel Server Management studio.
On the first I run:
BEGIN TRANSACTION T1
SET ANSI_PADDING ON
SET CONCAT_NULL_YIELDS_NULL ON
SET QUOTED_IDENTIFIER ON;
SET NUMERIC_ROUNDABORT OFF
SET ARITHABORT OFF
SET ANSI_WARNINGS ON
SET ANSI_NULLS ON
DELETE from GPSData where GPSDateTime BETWEEN '2014-06-09' AND '2014-06-11'
COMMIT TRANSACTION T1
and the error is:
Msg 1934, Level 16, State 1, Line 8
DELETE failed because the following SET options have incorrect settings: 'ANSI_NULLS, CONCAT_NULL_YIELDS_NULL, ANSI_WARNINGS, ANSI_PADDING'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations.
When I run the same transaction on the other connection, the error is:
The DELETE statement conflicted with the REFERENCE constraint "FK_GPSUnit_GPSData". The conflict occurred in database "PLATO_PEP", table "dbo.GPSUnit", column 'GPSDataID'.
The statement has been terminated.
The second error I expect to see. How can the first connection give an ANSI_PADDING... error, when the same settings work on the second connection?
Per the Microsoft Documentation for MS SQL 2008R2,
1)If SET CONCAT_NULL_YIELDS is not specified, the setting of the CONCAT_NULL_YIELDS_NULL database option applies
2)The setting of SET CONCAT_NULL_YIELDS_NULL is set at execute or run time and not at parse time
I interpret this as
As soon as you connect to the database without providing a SET CONCAT_NULL_YIELDS_NULL command , it will set it by default from the database option
To verify this, I created a database called Test with option CONCATENATE NULL YIELDS NULL=FALSE and a login which defaults to this database and execute the following SQL statements using SQLCMD.
set nocount on
declare #dbName sysname
select #dbName = DB_NAME()
select 'I am in database =',#dbName
select 'The CONCAT_NULL_YIELDS_NULL setting is =', is_concat_null_yields_null_on
from sys.databases
where name = #dbName
IF ( (4096 & ##options) = 4096 )
begin
select 'CONCAT_NULL_YIELDS_NULL is ON'
end
else
begin
select 'CONCAT_NULL_YIELDS_NULL is OFF'
end
go
The output of the above SQL is
I am in database = Test
is_concat_null_yields_null_on
The CONCAT_NULL_YIELDS_NULL setting is = 0
CONCAT_NULL_YIELDS_NULL is ON
Why is the CONCAT_NULL_YIELDS_NULL ON when it should have been OFF as the database Test had this option set to OFF ?
Is my interpretation of the M.S document incorrect OR is the documentation itself wrong ?
I know that this feature is marked for deprecation but my understanding is that it is still active for MS SQL2008R2.
The database options aren't very relevant because the various client libraries and tools all have their own defaults anyway which they set on your behalf at connection time.
Erland Sommarskog lists them here
We're trying to diagnose some performance issues on both SQL Server 2008 and SQL Server 2008 R2 arising from bad query plans that get cached on behalf of users but are unable to exactly reproduce them in SSMS as we cannot convince SQL Server to match the application's set_options value of 255 that gets returned from sys.dm_exec_plan_attributes, aka. ##OPTIONS.
The ##OPTIONS bit mask is documented at the following MSDN page:
Configure the user options Server Configuration Option
According to the above page the following combination of SET statements should yield an ##OPTIONS value of 255:
SET DISABLE_DEF_CNST_CHK ON
SET IMPLICIT_TRANSACTIONS ON
SET CURSOR_CLOSE_ON_COMMIT ON
SET ANSI_WARNINGS ON
SET ANSI_PADDING ON
SET ANSI_NULLS ON
SET ARITHABORT ON
SET ARITHIGNORE ON
SET QUOTED_IDENTIFIER OFF
SET NOCOUNT OFF
SET ANSI_NULL_DFLT_ON OFF
SET ANSI_NULL_DFLT_OFF OFF
SET CONCAT_NULL_YIELDS_NULL OFF
SET NUMERIC_ROUNDABORT OFF
SET XACT_ABORT OFF
But when you exec that you get the warning:
Line 1: The option 'DISABLE_DEF_CNST_CHK' is obsolete and has no effect.
And PRINT ##OPTIONS returns 254 instead of 255.
Clearly Connection Pooling is able to sort this out when you see EXEC sp_reset_connection in SQL Profiler, as none of our application code actually changes any SET options. But of course we can't call sp_reset_connection from SSMS:
Msg 208, Level 16, State 9, Procedure sp_reset_connection, Line 1
Invalid object name 'sp_reset_connection'.
Is there a trick to get that last DISABLE_DEF_CNST_CHK bit into play? An alternative option name or a system table to tweak?
Well I've found one way to SET DISABLE_DEF_CNST_CHK ON but I DO NOT recommend doing this on a production server...
When new connections are established SQL Server sets ##OPTIONS to the value stored against the 'user options' row in the sys.configurations view. This value defaults to 0. You can check the configured and running value with:
select * from sys.configurations where name = 'user options'
-- or:
EXEC sp_configure 'user options'
As a user with the sysadmin or serveradmin role you can change the value for future connections with:
EXEC sp_configure 'user options', 1
GO
RECONFIGURE
GO
Note that changing this setting affects all future connections to the server which is why I DO NOT recommend doing this on a production server.
After changing this configuration value, then opening a new connection in SSMS, using the other SET options as described in the original question finally got us to ##OPTIONS 255.
We are using MS SQL server 10.0, and running the DBCC options in two different user accounts, we get two different results. One has language us_english other as british. Where is the information stored on the server, is it possible to change it?
textsize 2147483647
language us_english
dateformat mdy
datefirst 7
lock_timeout -1
quoted_identifier SET
arithabort SET
ansi_null_dflt_on SET
ansi_warnings SET
ansi_padding SET
ansi_nulls SET
concat_null_yields_null SET
isolation level read committed snapshot
In a word, yes. This setting is set on the login that the connection is using and changes all sorts of subtle behavior. Dates are especially affected (first day of the week etc).
To view the default language settings for all logins run the following:
SELECT name, sp.default_language_name FROM master.sys.server_principals AS sp
That will show you the differences.
If you want to change the default language of a login use the following syntax:
ALTER LOGIN LoginName WITH DEFAULT_LANGUAGE = us_english
It looks like the default language for some users is different. You can change the default language for a user with the following syntax:
ALTER USER UserName WITH DEFAULT_LANGUAGE = us_english;
For more info see here.
What are the best SET Options to issue before stored procedure creation?
for example
SET QUOTED_IDENTIFIER OFF
SET ANSI_NULLS ON
CREATE PROCEDURE HelloWorld
AS
--also, should any be issued within the procedure body?
PRINT 'hello world!'
RETURN 0
GO
By best, I mean the most preferred settings.
For stored procedure creation specifically, then only two are important at parse time
SET ANSI_NULLS
SET QUOTED_IDENTIFIER
And they should be ON to work with newer SQL Server functionality that only works these being ON
Stored procedures execute with the SET settings specified at execute time except for SET ANSI_NULLS and SET QUOTED_IDENTIFIER. Stored procedures specifying SET ANSI_NULLS or SET QUOTED_IDENTIFIER use the setting specified at stored procedure creation time. If used inside a stored procedure, any SET setting is ignored.
Ref: http://msdn.microsoft.com/en-us/library/ms190356.aspx
To set both at the same time and others as well, use
SET ANSI_DEFAULTS ON
When enabled (ON), this option enables the following ISO settings:
SET ANSI_NULLS
SET CURSOR_CLOSE_ON_COMMIT
SET ANSI_NULL_DFLT_ON
SET IMPLICIT_TRANSACTIONS
SET ANSI_PADDING
SET QUOTED_IDENTIFIER
SET ANSI_WARNINGS
For completeness, set these other three at the connection level which allows things like INDEXED VIEWs to work correctly
SET ARITHABORT ON
SET CONCAT_NULL_YIELDS_NULL ON
SET NUMERIC_ROUNDABORT OFF
Transaction Isolation Level (often Read committed - to ensure no dirty reads). And unless you're interested in the number of rows affected; set nocount on
I typically don't bother setting any before the proc. In the proc Itypically use SET NOCOUNT ON and if it is just a select SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED