问题
I'm in the process of creating a new database onto SQL Server 2012 for our production environment. When I use the "New Database..." option from SQL Server Management Studio and generate the output I get:
CREATE DATABASE [AAA]
CONTAINMENT = NONE
ON PRIMARY
( NAME = N'AAA', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQL2014\MSSQL\DATA\AAA.mdf' , SIZE = 5120KB , FILEGROWTH = 1024KB )
LOG ON
( NAME = N'AAA_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQL2014\MSSQL\DATA\AAA_log.ldf' , SIZE = 1024KB , FILEGROWTH = 10%)
GO
ALTER DATABASE [AAA] SET COMPATIBILITY_LEVEL = 120
GO
ALTER DATABASE [AAA] SET ANSI_NULL_DEFAULT OFF
GO
ALTER DATABASE [AAA] SET ANSI_NULLS OFF
GO
ALTER DATABASE [AAA] SET ANSI_PADDING OFF
GO
ALTER DATABASE [AAA] SET ANSI_WARNINGS OFF
GO
ALTER DATABASE [AAA] SET ARITHABORT OFF
GO
ALTER DATABASE [AAA] SET AUTO_CLOSE OFF
GO
ALTER DATABASE [AAA] SET AUTO_SHRINK OFF
GO
ALTER DATABASE [AAA] SET AUTO_CREATE_STATISTICS ON(INCREMENTAL = OFF)
GO
ALTER DATABASE [AAA] SET AUTO_UPDATE_STATISTICS ON
GO
ALTER DATABASE [AAA] SET CURSOR_CLOSE_ON_COMMIT OFF
GO
ALTER DATABASE [AAA] SET CURSOR_DEFAULT GLOBAL
GO
ALTER DATABASE [AAA] SET CONCAT_NULL_YIELDS_NULL OFF
GO
ALTER DATABASE [AAA] SET NUMERIC_ROUNDABORT OFF
GO
ALTER DATABASE [AAA] SET QUOTED_IDENTIFIER OFF
GO
ALTER DATABASE [AAA] SET RECURSIVE_TRIGGERS OFF
GO
ALTER DATABASE [AAA] SET DISABLE_BROKER
GO
ALTER DATABASE [AAA] SET AUTO_UPDATE_STATISTICS_ASYNC OFF
GO
ALTER DATABASE [AAA] SET DATE_CORRELATION_OPTIMIZATION OFF
GO
ALTER DATABASE [AAA] SET PARAMETERIZATION SIMPLE
GO
ALTER DATABASE [AAA] SET READ_COMMITTED_SNAPSHOT OFF
GO
ALTER DATABASE [AAA] SET READ_WRITE
GO
ALTER DATABASE [AAA] SET RECOVERY SIMPLE
GO
ALTER DATABASE [AAA] SET MULTI_USER
GO
ALTER DATABASE [AAA] SET PAGE_VERIFY CHECKSUM
GO
ALTER DATABASE [AAA] SET TARGET_RECOVERY_TIME = 0 SECONDS
GO
ALTER DATABASE [AAA] SET DELAYED_DURABILITY = DISABLED
GO
USE [AAA]
GO
IF NOT EXISTS (SELECT name FROM sys.filegroups WHERE is_default=1 AND name = N'PRIMARY') ALTER DATABASE [AAA] MODIFY FILEGROUP [PRIMARY] DEFAULT
GO
Why are so many ANSI options defaulting to OFF? The server instance was set up by RackSpace on our behalf. Could it be because of some defaults they set up in the instance?
Thanks, Chris
回答1:
The options are defaulting to OFF
because, in all likelihood, this database was created and scripted without touching any of the defaults. When a database is created, it is essentially cloned from the model
system database, and on a brand new install of SQL Server the ANSI settings on the database will be OFF
, even though some of these settings (like ANSI_NULLS
) are options you would really never want to be OFF
for any modern database application. In fact, in the case of ANSI_NULLS
in particular, the documentation specifies that the ability to turn it off at all is deprecated, although it will likely still be a few years before that's really the case.
And therein lies the rub: these settings are still kept OFF
for the benefit of old applications, who had to turn these options ON
way back when to benefit from their goodness (and breaking changes). If the session specifies no values for them, the database settings are applied.
But most applications do specify these settings in a session, if not explicitly, then implicitly through their data access library. Per the documentation on SET ANSI_DEFAULTS, which toggles a bunch of settings at once:
The SQL Server Native Client ODBC driver and SQL Server Native Client OLE DB Provider for SQL Server automatically set
ANSI_DEFAULTS
toON
when connecting. The driver and Provider then setCURSOR_CLOSE_ON_COMMIT
andIMPLICIT_TRANSACTIONS
toOFF
. TheOFF
settings forSET CURSOR_CLOSE_ON_COMMIT
andSET IMPLICIT_TRANSACTIONS
can be configured in ODBC data sources, in ODBC connection attributes, or in OLE DB connection properties that are set in the application before connecting to SQL Server. The default forSET ANSI_DEFAULTS
isOFF
for connections from DB-Library applications.
DB-Library is an old access library that is nevertheless still used by some ancient applications and optionally as a backing source for things like FreeTDS, so every so often you can still run into an application that deliberately or accidentally uses the database settings, but this is increasingly rare.
As to the best value for these options, that depends entirely on your use case. If you must support old applications that expect old behavior, you may have no choice in having to leave the database settings on OFF
. If you have an application that connects through an old library but really expects modern SQL semantics, you may want to turn them ON
. For all other applications, these options are likely already set on a per-session basis to their (in)correct values by the application itself and what you configure won't matter anyway.
A discussion on each individual option and when you'd want to turn it ON
or OFF
would exceed the limits of a reasonable answer. Consult the documentation on each of them and formulate your own best practices. You can let things like the SET option requirements for indexes on computed columns guide you, which require a bunch of options to be ON
before you can even create them (and they're generally considered a nice thing to have).
来源:https://stackoverflow.com/questions/40892178/best-ansi-options-when-creating-a-new-database