Microsoft SQL Server 2008 R2 Unleashed- P233 pdf

access check cache bucket count Type: Advanced Option Default Value: 0 When any database object is accessed by SQL Server, the access check is cached in an internal structure named acces

Trang 1

set working set size(remains listed but has no effect)

Open Objects(remains listed but has no effect)

From a historical perspective, one of the all-time favorite options in SQL Server 7.0 was

max async IO The reason that option became obsolete is that it is completely automated

with SQL Server 2000, SQL Server 2005, and SQL Server 2008 Previously, max async IO

was used to specify the number of simultaneous disk I/O requests that SQL Server 7.0 (and

earlier versions) could submit to the Windows OS during a checkpoint operation It

invari-ably helped overall throughput on systems that used RAID devices that had extensive disk

cache mechanisms SQL Server 2008 adjusts these options automatically

Configuration Options and Performance

The following sections explain essential information about many of the most significant

SQL Server configuration options and their impact on SQL Server performance Some of

the options don’t have performance implications and therefore may not be addressed in

much detail—or at all As part of each option’s explanation, an indication of whether the

option is advanced or basic is given, along with the option’s default value and whether

the option is self-configuring Recommended values are usually indicated for the different

types of generalized application processing that the SQL Server is used for (that is, OLTP,

OLAP, data warehouse, and mixed) For some configuration options, there may not be

recommended values, but perhaps there may be notes that further explain how they can

be used Remember that there are 70 configuration options; this chapter focuses on the

essential ones in alphabetical order (how they are listed in SQL Server)

access check cache bucket count

Type: Advanced Option

Default Value: 0

When any database object is accessed by SQL Server, the access check is cached in an

internal structure named access check result cache The access check cache bucket

countoption controls the number of entries and number of hash buckets used for access

check result cache

Possible performance gains can be made by changing these options (in rare

circum-stances) In general, you should leave this one alone

The following is an example of this option:

exec sp_configure ‘access check cache bucket count’, 0

go

RECONFIGURE

Go

Trang 2

access check cache quota

In conjunction with access check cache bucket countoption, when SQL server accesses

any database object, the access check is cached in an internal structure named access

check result cache The access check cache bucket countoption, along with the

access check cache quotaoption, controls the number of entries and number of hash

buckets used for access check result cache

Possible performance gains can be made by changing these options (in rare

circum-stances) But, in general, you should leave this one alone also

exec sp_configure ‘access check cache quota’, 0

go

RECONFIGURE

Go

ad hoc distributed queries

SQL Server does not allow ad hoc distributed queries using OPENROWSETand

OPENDATASOURCEagainst providers other than the SQL Native Client OLE DB provider

When the ad hoc distributed queriesoption is set to 0, SQL Server allows ad hoc

access against other providers When it is set to 1, SQL Server does not allow any ad hoc

access

Ad hoc distributed queries use the OPENROWSETandOPENDATASOURCEfunctions to connect

to remote data sources using OLE DB OPENROWSETandOPENDATASOURCEshould be used

only to reference OLE DB data sources that are accessed infrequently For any data sources

that will be accessed more than a few times, you should define a linked server Enabling

the use of ad hoc queries means that any authenticated login to SQL Server can access the

provider SQL Server administrators should enable this feature only for highly trusted

providers that are safe to be accessed by any local login

exec sp_configure ‘Ad Hoc Distributed Queries’, 1

go

RECONFIGURE

Go

Trang 3

affinity I/O mask

Type: Advanced option; requires a reboot of SQL Server to take effect

Default value: 0

In Windows Servers, multitasking sometimes requires that process threads move among

different processors This type of movement of processing threads can reduce Microsoft

SQL Server performance under heavy system loads because each processor cache is

repeat-edly reloaded with data Assigning processors to specific threads can improve performance

by eliminating processor reloads; such an association between a thread and a processor is

called processor affinity SQL Server 2008 supports processor affinity by means of two

affin-ity mask options: affinity mask(to deal with the processor affinity needs) and affinity

I/O mask(to address I/O-related affinity) Affinity support for servers with 33 to 64

proces-sors is available only on 64-bit operating systems

Theaffinity I/O maskoption binds SQL Server disk I/O to a specified subset of CPUs In

high-end SQL Server OLTP environments, this extension can enhance the performance of

SQL Server threads issuing I/Os This enhancement does not support hardware affinity for

individual disks or disk controllers

The value for affinity I/O maskspecifies which CPUs in a multiprocessor computer are

eligible to process SQL Server disk I/O operations The mask is a bitmap in which the

rightmost bit specifies the lowest-order CPU (0), the bit to its immediate left specifies the

next-lowest-order CPU (1), and so on To configure more than 32 processors, you set both

affinity I/O maskandaffinity64 I/O mask When all bits are set to 0(oraffinity I/O

maskis not specified), SQL Server disk I/O is scheduled to any of the CPUs eligible to

process SQL Server threads

The values for affinity I/O maskare as follows:

A 1-byteaffinity I/O maskvalue covers up to 8 CPUs in a multiprocessor computer

To cover more than 32 CPUs, you configure a 4-byte affinity I/O maskvalue for the first

32 CPUs and up to a value-byte affinity64 I/O maskvalue for the remaining CPUs

A1bit in the affinity I/O pattern specifies that the corresponding CPU is eligible to

perform SQL Server disk I/O operations; a 0bit specifies that no SQL Server disk I/O

opera-tions should be scheduled for the corresponding CPU

An example of the bitmask values for the first seven processors of an eight-processor

system follows (with decimal values shown in parentheses):

Trang 4

00000001 (1) 0

00000011 (3) 0, 1

00000111 (7) 0, 1, 2

00001111 (15) 0, 1, 2, 3

00011111 (31) 0, 1, 2, 3, 4

00111111 (63) 0, 1, 2, 3, 4, 5

01111111 (127) 0, 1, 2, 3, 4, 5, 6

Because setting the SQL Server affinity I/O maskoption is a specialized operation, it

should be used only when necessary When specifying the affinity I/O maskoption,

you must use it with the affinity maskconfiguration option You should not enable the

same CPU in both the affinity I/O maskswitch and the affinity maskoption The bits

corresponding to each CPU should be in one of the following three states:

0in both the affinity I/O maskoption and the affinity maskoption

1in the affinity I/O maskoption and 0in the affinity maskoption

0in the affinity I/O maskoption and 1in the affinity maskoption

In SQL Server 2008, reconfiguring the affinity I/O maskoption requires a restart of the

SQL Server instance

exec sp_configure ‘affinity I/O mask’, 1

go

RECONFIGURE

Go

Affinity64 I/O maskis available only in the 64-bit version of SQL Server

affinity mask

Type: Advanced option

When a server is experiencing a heavy load because other applications are running on the

same server, it might be desirable to bind thread affinity to a processor

affinity maskis a bitmapped field that provides SQL Server threads an affinity to

proces-sors This is typically used in conjunction with the affinity I/O maskoption just

described Starting from the least-significant digit, each bit that is set to 1represents the

processor on which SQL Server will spawn its threads Processors are numbered from 0to

7 An example of the bitmask values for the first seven processors of an eight-processor

system follows (with decimal values shown in parentheses):

Trang 5

00000001 (1) 0

00000011 (3) 0, 1

00000111 (7) 0, 1, 2

00001111 (15) 0, 1, 2, 3

00011111 (31) 0, 1, 2, 3, 4

00111111 (63) 0, 1, 2, 3, 4, 5

01111111 (127) 0, 1, 2, 3, 4, 5, 6

You usually leave the eighth processor alone because many system processes—such as

domain controllers—default to that processor

For example, if you want to create the affinity for one SQL Server instance’s threads to use

four processors of an eight-processor system, you would set this bitmask to be 15

(00001111) As a result, SQL Server would spawn its threads only on those processors, thus

reducing overall reloading of the processor cache This can be especially evident during

heavy system loads

exec sp_configure ‘affinity mask’, 15

go

RECONFIGURE

Go

In general, the default affinity value is able to provide ample load balancing across

proces-sors You should allocate CPUs based on your particular processing load and application

types.affinity64 maskis available only on the 64-bit version of SQL Server

Following is a general recommendation of what to specify based on the different

applica-tion types you are running:

OLTP—Use the default value, 0

Data warehouse—Potentially use 75% of available processors to maximize the huge

data loads, large reporting, and number of users

OLAP—Use the default value, 0

Mixed—Use the default value, 0

From SSMS, you select SQL Server Properties, open the Processor tab, and select the

targeted processors in the Enable Processors section, as shown in Figure 55.3

Trang 6

Agent XP

Type: Advanced

TheAgent XPoption enables SQL Server 2008 Agent extended stored procedures for this

server If enabled, the SQL Server Agent is available in SSMS If not enabled, the SQL Server

Agent is not available in SSMS and cannot be used to start or stop the service This option

also supports direct execution of CLR assemblies It is not optimized to do so; it just

supports this

A0value indicates that SQL Server Agent extended stored procedures are not available

(the default) A value of 1indicates that the SQL Server Agent extended stored procedures

are available.

awe enabled

Type: Advanced; requires a reboot of SQL Server to take effect

SQL Server can use the Advanced Windowing Extensions (AWE) API to support large

amounts of physical memory In fact, the specific amount of memory you can use

Trang 7

depends on your hardware configuration and operating system support The amount of

physical memory supported has increased with the introduction of Microsoft Windows

Server operating systems:

Windows Server Standard Edition supports physical memory up to 4GB

Windows Server Enterprise Edition supports physical memory up to 32GB

Windows Server Datacenter Edition supports physical memory up to 64GB

The default of 0for the awe enabledoption tells SQL Server to use dynamic memory in

standard 32-bit virtual address spaces When you enable AWE, the SQL Server instance

does not dynamically manage the size of the address space The instance holds all

memory acquired at startup until it is shut down, and memory pages come from the

Windows nonpageable pool This means that none of the memory of the instance can be

swapped out You end up with a great deal of activity occurring in memory only This is

potentially a fast Database Engine

NOTE

Releases of SQL Server before SQL Server 2005 supported dynamic memory, which

allowed SQL Server to automatically adjust memory usage when there was spare

memory on the system However, SQL Server was limited by the amount of memory

available at startup Starting with SQL Server 2005, this limit on startup memory

availability is removed SQL Server 2005 and 2008 supportHot Add Memoryin

Microsoft Windows Servers, which allows users to add physical memory without

restarting the server

Hot Add Memoryrequires SQL Server 2008 Enterprise Edition and is available only for

64-bit SQL Server and for 32-bit SQL Server when AWE is enabled Hot Add Memoryis

not available for 32-bit SQL Server when AWE is not enabled Hot Add Memoryis

avail-able only for Windows Servers Enterprise and Datacenter Editions It also requires

spe-cial hardware supported by the hardware vendor

awe enabledis usually used in conjunction with the max server memoryoption to control

how much memory each SQL Server instance uses

sp_configure ‘awe enabled’, 1

go

RECONFIGURE

Go

Following is a general recommendation of what to specify based on the different

applica-tion types you are running:

OLTP—If memory is available, set it to 1

Data warehouse—Not appropriate for this type.

Trang 8

OLAP—If memory is available and you are not using OLAP file options, set it to 1

Mixed—If memory is available, set it to 1

backup compression default

Type: Basic

Starting with SQL Server 2008 Enterprise, you can use the BACKUPTransact-SQL statement

to select the backup compression setting to use WITH COMPRESSIONorWITH

NO_COMPRES-SION However, when you install SQL Server 2008, the backup compression default is set

to0, which makes backup compression off by default To change the default to

COMPRESSION, you set the backup compression default to 1 To revert the default to

NO_COMPRESSION, set the backup compression default back to 0

From a performance point of view, compression can significantly increase CPU usage, and

the additional CPU consumed by the compression process might impact concurrent

oper-ations Therefore, you might want to create low-priority compressed backups in a session

whose CPU usage is limited by the Resource Governor

blocked process threshold

Type: Advanced

Theblocked process thresholdoption allows you to specify the threshold, in seconds,

at which blocked process reports are generated By default, no blocked process reports are

produced.blocked process thresholduses the deadlock monitor background thread to

walk through the list of tasks waiting for a time greater than or multiples of the

config-ured threshold This option is useful when debugging systems with many deadlock

situa-tions However, there is a cost of overhead involved, so it should be used for only short

periods of time

c2 audit mode

C2 audit mode can be configured through SSMS or with the c2 audit modeoption in

sp_configure This feature is still available Selecting this option configures the server to

record both failed and successful attempts to access statements and objects This

informa-tion can help you profile system activity and track possible security policy violainforma-tions The

C2 security standard has been superseded by common criteria compliance features Much

of the detail-level auditing is now done with SQL Auditing (covered in the SQL Server

Security chapters) and is far more robust than this feature C2 audit mode data is saved in

a file in the default data directory of the instance If the audit log file reaches its size limit

of 200MB, SQL Server creates a new file, closes the old file, and writes all new audit

Trang 9

records to the new file This process continues until the audit data directory fills up or

auditing is turned off To determine the status of a C2 trace, you query the sys.traces

catalog view Be aware that C2 audit mode saves a large amount of event information to

the log file, which can grow quickly If the data directory in which logs are being saved

runs out of space, SQL Server shuts itself down! If auditing is set to start automatically,

you must either restart the instance with the -fflag (which bypasses auditing) or free up

additional disk space for the audit log

clr enabled

Type: Basic

SQL Server 2008 supports direct execution of CLR assemblies It is not optimized to do so;

it just supports this capability

A0value for clr enabledindicates that these CLR assemblies are not allowed to run on

this SQL Server instance A value of 1allows this type of execution The setting takes effect

immediately after sp_configureis run, with no restart of the SQL Server instance

required When RECONFIGUREis run and the run value of the clr enabledoption is

changed from 1to0, all application domains containing user CLR assemblies are

immedi-atelyunloaded CLR assembly execution is not supported under lightweight pooling, so

you must disable one of two options: clr enabledorlightweight pooling

common criteria compliance enabled

Thecommon criteria compliance enabledoption enables three areas (or elements) of

what is termed common criteria The first is Residual Information Protection (RIP), which

overwrites memory with a known pattern of bits before memory is reallocated to a new

resource This meets the RIP standard and contributes to improved security The downside

of this improvement is a slowing in performance The second enables login auditing to

occur Each time a user successfully logs in to SQL Server, information about the last

successful login time, the last unsuccessful login time, and the number of attempts

between the last successful and current login times is made available These login statistics

can be viewed by querying the sys.dm_exec_sessionsdynamic management view And

lastly, this option enables the behavior that a column-level GRANTshould not override a

table-levelDENY In other words, when enabled, a table-level DENYtakes precedence over a

column-levelGRANT

Trang 10

cost threshold for parallelism

Type: Advanced

SQL Server 2008 supports parallel query execution Before a query is executed, SQL Server’s

cost-based optimizer estimates the cost of execution for a serial plan (that is, a plan that

uses a single thread) The option to set the cost threshold for parallelism allows you to

specify a threshold in seconds; if the cost of the serial execution plan (in seconds) is

greater than the value specified by this parameter, SQL Server considers a parallel query

execution plan A query does not become a candidate for parallel query execution simply

based on this fact Because parallel query execution is supported only on multiprocessor

servers, the cost threshold for parallelismvalue is ignored for single-processor

hard-ware For an application that uses many complex queries, you should set this value to a

lower number so that you can take advantage of the parallel query execution capabilities

of SQL Server

exec sp_configure ‘cost threshold for parallelism’, 2

go

RECONFIGURE

Go

The following is a general recommendation of what to specify based on the different

application types you are running:

OLTP—Use the default value, 5

Data warehouse—Many complex queries are candidates for parallelism Set to a

low value, such as 2(seconds)

OLAP—Use the default value, 5

Mixed—Use the default value, 5

cross db ownership chaining

Type: basic

You use the cross db ownership chainingoption to configure cross-database ownership

chaining for an instance of Microsoft SQL Server This server option allows you to control

cross-database ownership chaining at the database level or to allow cross-database

owner-ship chaining for all databases In other words, when this option is off for the instance, it

is disabled for all databases This server-wide option can be more selectively set at the

indi-vidual database level Our recommendation is to turn it off at the server instance level and

Định dạng
Số trang	10
Dung lượng	239,37 KB