To put theAdventureWorks2008sample database inEMERGENCYmode in code, do the following: ALTER DATABASE AdventureWorks2008 SET EMERGENCY; TheREAD_ONLYdatabase-state settings are used to al
Trang 1To revert this change and make theAdventureWorks2008database online and available, do the
fol-lowing:
ALTER DATABASE AdventureWorks2008 SET ONLINE;
You may encounter a situation in which the database is inaccessible and you do not have a backup
To access the database regardless of online/offline state, members of the sysadmin role can put the
database inEMERGENCYmode Once inEMERGENCYmode, the database is in read-only mode and is
accessible only by members of the sysadmin role To put theAdventureWorks2008sample database
inEMERGENCYmode in code, do the following:
ALTER DATABASE AdventureWorks2008 SET EMERGENCY;
TheREAD_ONLYdatabase-state settings are used to allow only selects from the database.READ_ONLY
cannot take effect if any users are in the database To reset the database to a normal read-and-write
state, theREAD_WRITEdatabase setting is used
To set theAdventureWorks2008sample database to aREAD_ONLYstate in code, do the following:
ALTER DATABASE AdventureWorks2008 SET READ_ONLY;
The restricted access database-state settings are also available The three restricted access levels are
single_user,restricted_user, andmulti_userstates These settings control which users are
allowed to access the database TheSINGLE_USERsetting is appropriate when you are doing database
maintenance TheRESTRICTED_USERsetting allows database access only to users in thedb_owner,
dbcreator, andsysadminroles TheMULTI_USERsetting is used to set the database in the normal
operating state
The following sets theAdventureWorks2008sample database toSINGLE_USERaccess:
ALTER DATABASE AdventureWorks2008 SET SINGLE_USER;
To revert the preceding setting and set theAdventureWorks2008database access toMULTI_USER
access, do the following:
ALTER DATABASE AdventureWorks2008 SET MULTI_USER;
Compatibility level
In SQL Server, the database-compatibility level can be set to80(SQL Server 2000),90(SQL Server
2005), or100(SQL Server 2008) When a database is upgraded to SQL Server 2008 from any
earlier version of SQL Server, the database retains its existing compatibility level Setting the
database-compatibility level to a level lower than100may be necessary if you are upgrading the Database Engine
and still need to maintain the behavior of an earlier version of SQL Server
The compatibility level option does not provide full backward compatibility It is mainly intended to enable new reserved words to be used in tables, and to retain some (very lim-ited) changed behavior Refer to SQL Server Books Online for a full overview.
To set the compatibility level of theAdventureWorks2008sample database to100(SQL Server 2008)
in code, do the following:
ALTER DATABASE AdventureWorks2008 SET COMPATIBILITY_LEVEL = 100;
Trang 2TABLE 39-13
Recovery-Configuration Properties
Property Level* Graphic Control Code Option
Recovery Model D Management Studio ALTER DATABASE <DB Name> SET
RECOVERY Page Verify D Management Studio ALTER DATABASE <DB Name> SET
PAGE_VERIFY Media Retention S Management Studio EXEC sp_configure ‘media
retention’
Backup Compression S Management Studio EXEC sp_configure ‘backup
compression default’
Recovery Interval S Management Studio EXEC sp_configure ‘recovery
interval’
* The configuration level refers to Server, Database, or Connection.
New in 2008
In SQL Server 2008, the ALTER DATABASE syntax shown in the sample code replaces the
sp_dbcmptlevelstored procedure for setting the database compatibility level
To view the compatibility level of SQL Server, query the compatibility_level column in the
sys.databases catalog view.
Recovery-configuration properties
The recovery-configuration properties, shown in Table 39-13, are used to set recovery options in SQL
Server
The recovery options determine how SQL Server handles transactions and the transaction log, and how
the transaction log is backed up
Recovery model
SQL Server 2008 uses a recovery model to configure several settings that work together to control how
the transaction log behaves regarding file growth and recovery possibilities The three recovery model
options are as follows:
■ Simple: The transaction log contains only transactions that are not yet written to the data file
This option does not provide up-to-the-minute recovery
Trang 3■ Bulk-Logged: The transaction log contains all DML operations, but bulk insert operations are only marked, not logged
■ Full: The transaction log contains all changes to the data file This option provides the greatest recovery potential
Chapter 41, ‘‘Recovery Planning,’’ focuses on recovery planning and operations in detail.
In code, set the recovery option with theALTER DATABASE SET RECOVERYcommand
In Management Studio, the recovery model can be changed by selecting Simple, Bulk-logged, or Full in
the Recovery Model drop-down list in the Database Properties Options tab (refer to Figure 39-2)
To set the recovery mode in theAdventureWorks2008sample database to Bulk-Logged in code, do
the following:
ALTER DATABASE AdventureWorks2008 SET RECOVERY BULK_LOGGED;
Page Verify
Even though SQL Server works with 8KB data pages, the operating system I/O writes in 512-byte
sec-tors Therefore, it’s possible that a failure might occur in the middle of a data-page write, resulting in
only some of the 512-byte sectors to be written to disk This is known as a torn page You can have SQL
Server tell you if a torn page occurs by using thePAGE_VERIFYdatabase option
ThePAGE_VERIFYdatabase option can be set to one of the following values:
■ CHECKSUM: This is the default level forPAGE_VERIFY With this option, SQL Server calcu-lates a checksum over the contents of each page and stores the value in the page header when
a page is written to disk When the page is read from disk, the checksum is recalculated and compared to the original checksum value
■ TORN_PAGE_DETECTION: This option instructs SQL Server to toggle a bit on each 512-byte sector with each write operation If all the sectors were written to disk, then all the detection bits should be identical If, on recovery, any of the bits are different, then SQL Server can detect the torn-page condition and mark the database as suspect
■ NONE: With this option, database page writes will not generate aCHECKSUMor TORN_PAGE_DETECTIONvalue
To change thePAGE_VERIFYoption, you can either use Management Studio or T-SQL code In
Man-agement Studio,PAGE_VERIFYcan be changed by selectingCHECKSUM,TORN_PAGE_DETECTION, or
NULLin the Page Verify box in the Database Properties Options tab (refer to Figure 39-2)
Using T-SQL code, the following command can be used to set thePAGE_VERIFYoption for
AdventureWorks2008sample database toTORN_PAGE_DETECTION:
ALTER DATABASE AdventureWorks2008 SET PAGE_VERIFY TORN_PAGE_DETECTION;
To view the PAGE_VERIFY option for the database, query the page_verify_option_desc
column in the sys.databases catalog view.
Trang 4Media retention
Themedia retentionoption is used to set the number of days to retain each backup set The default
value formedia retentionis 0 days This option helps protect backups from being overwritten until
the specified number of days has elapsed
In Management Studio, themedia retentionserver configuration option can be set by entering the
number of days to retain each backup media in the ‘‘Default backup media retention (in days)’’ box in
the Server Properties Database Settings tab (see Figure 39-11)
FIGURE 39-11
The Database Settings tab of Management Studio’s Server Properties
To setmedia retentionto 10 days in code, do the following:
EXEC sp_configure ‘show advanced options’, 1;
RECONFIGURE;
EXEC sp_configure ‘media retention’, 10;
RECONFIGURE;
Trang 5Backup compression
Backup compression is a new feature introduced in SQL Server 2008 Enterprise Edition Although this
feature is supported only in Enterprise Edition, every SQL Server 2008 edition can restore a compressed
backup
In Management Studio, to compress new backups by default, setbackup compression default
by checking the Compress Backup check box in the Server Properties Database Settings tab (refer to
Figure 39-11)
To setbackup compression defaultin code, do the following:
EXEC sp_configure ‘backup compression default’, 1 RECONFIGURE
After installation, new backups are uncompressed by default Backup compression can greatly reduce backup size and backup restore time This improvement is not free, however Backup compression significantly increases CPU usage, which may impact other operations on
the server Hence, I recommend testing this feature thoroughly to understand the pros and cons before
implementing it in your production SQL Server.
For more information about backup compression, refer to Chapter 41, ‘‘Recovery Planning.’’
Recovery interval
Therecovery intervalserver configuration option controls when SQL Server issues checkpoints for
each database A checkpoint flushes dirty pages from the buffer cache of the database to disk
Check-points are performed when SQL Server estimates that the recovery time will be longer than the
speci-fiedrecovery interval The estimated duration applies only to theREDO(roll forward) phase of the
recovery, not theUNDO(roll backward) phase The default value for this option is0, which implies that
this option is automatically configured by SQL Server
Best Practice
Leave the recovery interval option at the default value of 0 If you do change the recovery
interval, then be sure to test it thoroughly and evaluate all other performance-tuning opportunities
first
If you insist on changing therecovery intervaloption, you can use either Management Studio or
T-SQL code In Management Studio, therecovery intervalserver configuration option can be set
by entering the maximum number of minutes per database to recover databases in the ‘‘Recovery interval
(minutes)’’ box in the Server Properties Database Settings tab (refer to Figure 39-11)
Trang 6Using T-SQL code, the following command sets therecovery intervalserver configuration option
to five minutes:
EXEC sp_configure ‘show advanced options’, ‘1’;
RECONFIGURE;
EXEC sp_configure ‘recovery interval’, 5;
RECONFIGURE;
Summary
Configuration options are important for compatibility, performance tuning, and controlling the
connec-tion The configuration options are set at the server, database, and connection level Most of the options
can be set from Management Studio, and all of them can be configured with code
Continuing with SQL Server administration tasks, the next chapter focuses on managing policies
Trang 8Policy-Based Management
IN THIS CHAPTER
Declarative management Exploring facet properties Defining policies Enforcing policies
Recently I was on a virtual panel with SQL Server MVPs Steve Wynkop
and Chris Shaw (of SSWUG.org fame) discussing what’s new with SQL
Server 2008 I said the top new developer feature is table-valued
param-eters, and the top DBA feature is Policy-Based Management (affectionately called
PBM) This surprised Chris because he expected me to focus on only developer
features, and he wanted to say that PBM was the top new feature Sorry to steal
your thunder, Chris
But it’s true For SQL Server operations, PBM has the potential to radically alter
how DBAs do their job, advance the consistency and quality of the operations up
a few levels, and significantly ease managing hundreds of servers
I’ll put it in print here: If you’re an operational DBA and you don’t get excited about
PBM, then you should consider flipping burgers instead (And as a DB dev type, I
don’t usually get very excited about an admin feature.)
So, with that introduction, what is PBM?
Traditionally, applying and enforcing server and database settings and
configura-tions across multiple SQL Servers has been a mash-up of log books, checklists,
jobs, DDL triggers, scripts, and good ideas on the whiteboard that were never
actually implemented
PBM changes all that by making policies declarative — in fact, during its early
life, PBM was called Declarative Management Framework
SQL is a declarative language, meaning that SQL commands don’t state how the
query should be solved SQL describes the question, and the Query Optimizer
figures out how to solve the query
Trang 9Similarly, PBM abstracts the management intent, meaning the policies, from the procedural
implemen-tation As the DBA, you define what the system should be and then let SQL Server figure out how to
achieve it Policy checking can be automated, and the results logged
SQL Server 2008 focuses on automating policy checking for a single SQL Server instance But users can
build multi-server solutions quite easily using PowerShell scripts and agent jobs
What’s New with Policy-Based Management?
Of course, everything is new with PBM — it’s a new feature — but there’s more to the story In SQL
Server 2008, PBM replaces the Surface Area Configuration (SAC) tool that SQL Server 2005 introduced
With SQL Server 2005, Microsoft installed SQL Server in a locked-down state — with a minimum exposed
surface area configuration Any setting that could be turned off was turned off The SAC tool was a pretty
slick and easy way to check the server settings and enable features
PBM is considerably more complicated than the old SAC tool One of SQL Server’s strengths has always
been the scalability of the experience — it’s usable by the occasional, accidental DBA as well as by the
professional, experienced DBA I contend that SAC was very useful for the web developers who also serve
as the DBA 30 minutes a month They’re never going to learn PBM, and probably never going to read this
chapter, but the SAC tool was easy to find and easy to use PBM is far superior to SAC in every way; SAC
was just really easy to use
The demise of SAC aside, Policy-Based Management is brilliant Without a doubt, PBM is the right direction
for SQL Server management and it’s the right tool for the professional DBA today
It’s worth mentioning that there is more to PBM than meets the eye PBM is actually a down-payment
technology that Microsoft can build on I expect to see great things being done in SQL 11 to
leverage PBM
Defining Policies
Policies may be defined interactively in Management Studio, loaded in from XML, or defined with either
T-SQL code or APIs There are three types of PBM objects In a sense they function as three levels, with
one policy built from conditions, which are built out of facets:
■ 74 Management facets, defined only by Microsoft, are collections of properties that represent
a management dimension For example, the table facet has 34 specific properties that can be checked about a table Examples of common facets include logins, a server, a linked server, or
an index Inside each facet are anywhere from a handful to dozens of properties, which can be referred to by a condition
■ Health conditions, defined by the DBA, based on one facet, are the desired states, or values,
in terms of facet properties
Trang 10■ Policies, defined by the DBA, based on one health condition, declare how and upon what
object (server, database, etc.) the health condition should be enforced
The UI for Policy-Based Management is in Management Studio’s Object Explorer under the Management
node, as shown in Figure 40-1 Most of the PBM tasks are found in the PBM node context menus
Management facets
A brilliant-cut diamond has 58 facets Policy-Based Management has 74 management facets; fortunately,
a condition can be built with only one facet The easiest way to see all the facets is to open the Facets
node under Management➪ Policy Management, as shown in Figure 40-1
FIGURE 40-1
Policy-Based Management’s policies, conditions, and facets are found in Object Explorer under the
Management node
In database design terminology, there’s a many-to-many relationship between SQL Server object types
and properties For example, database facet properties apply only to databases, but the name facet
property (there’s only one property) can apply to 19 different types of SQL Server objects, ranging from
ApplicationRoles to XmlSchemaCollections, including databases