3.3 Using Conditions as Server Restrictions
This section focuses on adding more
logic to a policy by using the server restrictions options. To enhance
the intelligence of the Auto Close policy described in the previous
example, it may be useful to target this policy only at SQL Servers
running the Standard or Enterprise Edition. This will avoid the
possibility of spurious alerts for instances of SQL Server Express.
The following steps will create a condition and assign it as a restriction to the policy created earlier:
1. Right-click on Conditions and choose New Condition.
2. Enter the name SQL Server Standard or Enterprise Edition.
3. Using the Facet drop-down box, choose Server.
4. In the
Expression pane, choose the field named @EngineEdition, choose the
equals operator, and select Standard from the Value drop-down box.
5. Click to add a new clause to the Expression using the OR operator.
6. Choose again the field @EngineEdition, use the equals operator, and select EnterpriseOrDeveloper from the Value drop-down box.
7. Click OK.
8. Locate the policy for Database – Auto Close and choose Properties.
9. Using the Server Restriction drop-down box, select the Condition named SQL Server Standard or Enterprise Edition.
The next time this policy is evaluated it will
detect the SQL Server edition, and this policy will be evaluated only
against servers running Standard or Enterprise Editions. In order to
leverage the value of these policies, it’s necessary to define a
Central Management Server, import the policies, and evaluate against
the environment. The next section describes the process and steps
required to successfully configure the environment and evaluate the
policies.
3.4 Enterprise Policy Evaluation
The architecture for the Policy-Based
Management framework consists of a Central Management Server where
policies are stored; server groups, which are logical containers for
servers; and server registrations, which are connections to the target
database servers. Once the Central Management Server is defined and
each instance registered, policies can be evaluated against entire
groups of servers with ease, and reports can be generated showing
compliance status.
The first step is to configure a Central
Management Server. This server is typically used as a repository for
policies and to host the schedules for policy evaluation.
To configure a Central Management Server:
1. Launch SQL Server Management Studio and choose View ? Registered Servers.
2. Expand
Database Engine and in the expanded view that appears, right-click on
Central Management Servers and select Register Central Management
Server. The New Server Registration dialog, shown in Figure 2, will appear.
3. Type the
name of the instance that will host your Central Management Server in
the “Server name:” field of the New Server Registration dialog. You can
optionally give this Registered server a friendly name in the
registered server name and registered server description text fields in
this dialog. Click Save after you have select the hosting instance.
Now that your Central Management Server is
created, you’ll want to add servers to it. It is a best practice to
create various server groups for the different groupings of servers in
your environment (e.g. Production, Test, Development). To create a
Server Group right-click on the Central Management Server you just
created and choose New Server Group, enter the name Production, and click OK.
Register each production instance within the
group named Production by right clicking on the server group and
choosing New Server Registration. The instances must be able to
communicate directly with the Central Management Server, so you will
want to point specify connection details to connect to the instance in
the New Server Registration dialog.
If policies were created on an instance other
than the Central Management Server, you need to transfer them, which
you can do using a simple export/import process. To export the policies
from the source instance, right-click and choose Export, and specify a
name and location on disk. One XML file is created for each policy
exported.
To import policies to the Central Management
Server, right-click on the server name and choose Central Management
Server Actions, and then select Import Policies from the submenu.
Navigate to the folder location and select the policy files to import.
To evaluate the policies, right-click on the
Central Management Server to evaluate for all registered servers, or
right-click on the group name to evaluate for servers within the group,
and choose Evaluate Policies from the menu. Choose the source (specify
the Central Management Server) and check the policies to evaluate using
the left-hand checkboxes. Click Evaluate in the bottom-right corner and
verify the output.
NAMING CONVENTIONS FOR POLICIES
Consider defining a naming convention
standard for conditions and policies. It helps to organize policies by
using the target in the name; for example, any policies for databases
can include the prefix “Database” in the policy name, and server-wide
policies can be prefixed with “Server.”
3.5 Automating Best Practice Checks with PBM
Microsoft and the SQL Server community
have established many best practices concerning SQL Server and database
design, configuration, and deployment. Typically, a best practice is a
deviation from a standard or default configuration to improve some
aspect of the solution — performance, reliability, maintainability, and
so on. Because SQL Server is an application platform and can be
deployed and used in many different ways, use of these best practices
is often hotly debated. As such, there are may be exceptions to these
best practices, whereby a given recommendation may apply only in some
situations, or some additional qualifications or conditions are
required to determine whether the best practice is applicable.
ORGANIZING POLICIES USING CATEGORIES
The PBM feature has an option to
populate metadata for each policy. This includes a category, a
description, and a hyperlink to further information. One particularly
useful field is Category, which can be used to separate policies based
on their purpose, e.g., best practices, organization standards, or bad
configurations. The categories can be used to sort policies during
evaluation and improve manageability.
This section provides guidance on implementing
policies to automate checks for best practices. It is not intended to
define a best practice, or to provide a full set of health-check
policies.
There are several benefits to defining and
automating health-check policies — in particular scalability and reuse
of the solution. You can execute the checks on a schedule, and any
deviation or omission will be highlighted immediately. Additionally,
these checks can be scaled across an entire estate to which new servers
or additional environments are added with relatively little effort.
3.6 Database — Check Last Backup
This check ensures that a successful
full backup occurred in the past 24 hours. The approach used in this
condition could easily be adapted for use with transaction log backups.
First, create a new condition using the name Last Good Backup.
In the Facet field, select Database maintenance. Choose the field
@LastBackupDate and use the operator >=. Next, in the Value field,
click the ellipses (. . .) to launch the Advanced Edit dialog. This
dialog permits entry of a T-SQL statement. Enter the following, click
OK, and save the condition:
DateAdd('day', -1, GetDate())
Next, create a new policy named Database — Recent Backup,
and select the check condition Last Good Backup that you created
earlier. Initially, set the Evaluation Mode to On demand. All other
settings should remain at their default. Click OK to complete creation
of the policy.
