This article discusses the new feature named Policy Based Management in SQL Server 2008. Policy Based Management is an extensive management configuration that can be used to manage servers, databases and objects. Policy Based framework provides a way to define policies that apply to servers, databases and objects. With Policy based Management framework, you can enforce consistent policies across all servers.
Terms used in Policy Based Framework:
Facet: Is a management area within policy based environment.
Condition: Defines the permitted state of one or more properties in a defined facet.
Policy: Contains a single condition that is to be enforced.
Category: Contains one or more policies that you want to enforce.
Target: Defines the servers, databases or other database objects for which the polices are to be enforced.
Listed below is the evaluation modes that are available in Policy Based Management in SQL Server 2008.
On Demand: – Evaluates the policy only when you directly execute the policy.(Manual)
On Change: Prevent – When nested triggers are enabled, uses data definition language (DDL) triggers to prevent policy violations by detecting changes that violate policy and rolling them back.(Automatic)
On Change: Log Only – Evaluates a policy when a relevant change is made and logs policy violations in the event logs.(Automatic)
On Schedule – Uses SQL Server Agent jobs to periodically evaluate policies. Logs policy violations in the event logs and generates a report.(Automatic)
Policies that are executed automatically are executed under the member of a sysadmin role and hence are written to the event logs. Policies that are executed manually are executed under the context of the current user. This user needs permission of ALTER TRACE to write to event logs.
Permission Needed to Configure Policy Based Management: You need PolicyAdministratorRole role in msdb database to configure Policy Based Management Settings.
SQL Server stores policy related data in msdb database. You must backup this database after changes to conditions, policies and categories.
SQL Server 2008 has predefined policies and they are listed below.
Asymmetric Key Encryption Algorithm :
Checks whether asymmetric keys were created by using 1024-bit or stronger encryption. As a best practice, you should use RSA 1024-bit or stronger encryption to create asymmetric keys for data encryption.
Backup And Data File Location:
Checks whether database files are on devices separate from the backup files. As a best practice, you should put the database and backups on separate backup devices.
CmdExec Rights Secured
Checks an instance of SQL Server 2000 to determine whether only members of the sysadmin server role can run CmdExec and ActiveX Script job steps, which is a recommended best practice.
Data And Log File Location
Checks whether data and log files are placed on separate logical drives. As a best practice, placing the files on separate drives allows the I/O activity to occur at the same time for both the data and log files.
Database Auto Close
Checks whether the AUTO_CLOSE option is set to OFF. When AUTO_CLOSE is set to ON, this option can cause performance degradation on frequently accessed databases because of the increased overhead of opening and closing the database after each connection. AUTO_CLOSE also flushes the procedure cache after each connection.
Database Auto Shrink
Checks whether the AUTO_SHRINK database option is set to OFF. Because frequently shrinking and expanding a database can lead to fragmentation on the storage device.
Database Collation
Checks whether user-defined databases are defined by using a database collation that is the same as the collation for the master and model databases, which is a recommended best practice. Otherwise, collation conflicts can occur that might prevent code from executing.
Database Page Status
Checks for user databases that have the database status set to Suspect. The Database Engine marks a database as Suspect when it reads a database page that contains an 824 error. Error 824 indicates that a logical consistency error was detected during a read operation, and it frequently indicates data corruption caused by a faulty I/O subsystem component.
Database Page Verification
Checks whether the PAGE_VERIFY database option is set to CHECKSUM. This recommended best practice helps provide a high level of data-file integrity by forcing the Database Engine to calculate a checksum over the contents of the whole page and store the value in the page header when a page is written to disk. When the page is read from disk, the checksum is recomputed and compared to the checksum value that is stored in the page header.
File Growth For SQL Server 2000
Checks an instance of SQL Server 2000 for data files that are 1 gigabyte or larger and are set to autogrow by a percentage instead of a fixed size. As a recommended best practice, large databases should class=SpellE>autogrow by a fixed size. Otherwise, growing a data file by a percentage can cause performance problems with SQL Server because of progressively larger growth increments.
Guest Permissions
Checks whether the guest user has permission to access a user database. As a best practice, you should revoke the guest user permission to access a database if it is not required.
Last Successful Backup Date
Checks to ensure that a database has recent backups. Scheduling regular backups protects a database against data loss.
Public Not Granted Server Permissions
Checks whether the public server role has server permissions. Every login that is created on the server is a member of the public server role and will have server permissions.
Read-Only Database Recovery Model
Checks for read-only user databases that have recovery set to Full. As a best practice, these databases should use the Simple recovery model because they arent frequently updated.
SQL Server 32-Bit Affinity Mask Overlap
Checks whether the 32-bit instance of SQL Server has one or more processors that are assigned to be used with both the Affinity Mask and Affinity I/O Mask options. Enabling a CPU with both the affinity mask and the affinity I/O mask can slow performance by forcing the processor to be overused.
SQL Server 64-Bit Affinity Mask Overlap
Checks whether the 64-bit instance of SQL Server has one or more processors that are assigned to be used with both the Affinity Mask and Affinity I/O Mask options. Enabling a CPU with both the affinity mask and the affinity I/O mask can slow performance by forcing the processor to be overused.
SQL Server Affinity Mask
Checks whether the Affinity Mask option is set to 0. This is the default value, which dynamically controls CPU affinity. Using the default value is a recommended best practice.
SQL Server Blocked Process Threshold
Checks the Blocked Process Threshold option, and ensures it is set to 0 (disabled) or to a value higher than or equal to 5 (seconds). Setting the Blocked Process Threshold option to a value from 1 through 4 can cause the deadlock monitor to run constantly, and this state is desirable only when you are troubleshooting.
SQL Server Default Trace
Determine whether the Default Trace option is disabled. When this option is enabled, default tracing provides information about configuration and DDL changes to the SQL Server Database Engine.
SQL Server Dynamic Locks
Checks whether the Locks option is set to 0. This is the default value, which dynamically controls locks. Using the default value is a recommended best practice.
SQL Server Lightweight Pooling
Checks whether the Lightweight Pooling option is set to 0. This is the default value, which prevents SQL Server from using lightweight pooling. Using the default value is a recommended best practice.
SQL Server Login Mode
Checks the login security configuration to ensure Windows authentication is being used. Using Windows authentication is a recommended best practice because this mode uses the Kerberos security protocol, provides support for account lockout, and supports password expiration. For Windows Server 2003 and Windows Server 2008, Windows authentication also provides password policy enforcement in terms of complexity validation for strong passwords.
SQL Server Max Degree Of Parallelism
Checks whether the Max Degree Of Parallelism (MAXDOP) option is set to a value greater than 8. Because setting this option to a value larger than 8 often causes unwanted resource consumption and performance degradation, youll usually want to reduce the value to 8 or less.
SQL Server Max Worker Threads For SQL Server 2005 And Above
Checks the Max Worker Threads Server option for potentially incorrect settings. Setting the Max Worker Threads option to a small value might prevent enough threads from servicing incoming client requests in a timely manner. Setting the option to a large value can waste address space, because each active thread consumes 512 KB on 32-bit servers and up to 4 MB on 64-bit servers. For instances of SQL Server 2005 and SQL Server 2008, you should set this option to 0, which allows SQL Server to automatically determine the correct number of active worker threads based on user requests.
SQL Server Network Packet Size
Determines whether the network packet size of any logged-in user is more than 8060 bytes. As a best practice, the network packet size should not exceed 8060 bytes. Otherwise, SQL Server performs different memory allocation operations, and this can cause an increase in the virtual address space that is not reserved for the buffer pool.
SQL Server Password Expiration
Checks whether password expiration is enabled for each SQL Server login. As a best practice, you should enable password expiration for all SQL Server logins using ALTER LOGIN. Additionally, if SQL Server authentication is not required in your environment, you should enable only Windows authentication.
SQL Server Password Policy
Checks whether the Enforce Password policy is enabled for each SQL Server login. As a best practice, you should enable the Enforce Password policy for all the SQL Server logins by using ALTER LOGIN.
SQL Server System Tables Updatable
Checks whether system tables for SQL Server 2000 can be updated. As a best practice, you shouldnt allow updates to system tables.
Symmetric Key Encryption For User Databases
Checks whether encryption keys that have a length of less than 128 bytes do not use the RC2 or RC4 encryption algorithm. As a best practice, you should use AES 128 bit or larger to create symmetric keys for data encryption. If AES is not supported by your operating system, you should use 3DES encryption.
Symmetric Key For master Database
Checks for user-created symmetric keys in the master database.
Symmetric Key For System Databases
Checks for user-created symmetric keys in the msdb, model, and tempdb databases. As a best practice, you should not create symmetric keys in the system databases.
Trustworthy Database
Checks whether the dbo role for a database is assigned to the sysadmin fixed server role and the database has its trustworthy bit set to ON. As a best practice, you should turn off the trustworthy bit or revoke sysadmin permissions from the dbo database role. Otherwise, a privileged database user can elevate privileges to the sysadmin role and then create and run unsafe assemblies that could compromise the system.
Windows Event Log Cluster Disk Resource Corruption Error
Checks the system event log for EventId 1066. This error can occur when a device is malfunctioning and also as a result of SCSI host adapter configuration issues.
Windows Event Log Device Driver Control Error
Checks the system event log for EventId 11. This error can be caused by a corrupt device driver, a hardware problem, faulty cabling, or connectivity issues.
Windows Event Log Device Not Ready Error
Checks the system event log for EventId 15. This error can be caused by SCSI host adapter configuration issues or related problems.
Windows Event Log Disk Defragmentation
Checks the system event log for EventId 55. This error occurs when the Disk Defragmenter tool cannot move a particular data element and as a result Chkdsk.exe is scheduled to run.
Windows Event Log Failed I_O Request Error
Checks the system event log for EventId 50. This error is caused by a failed I/O request.
Windows Event Log I_O Delay Warning
Checks the event log for error message 833. This message indicates that SQL Server has issued a read or write request from disk, and that the request has taken longer than 15 seconds to return. You can troubleshoot this error by examining the system event log for hardware-related error messages. Look also for hardware-specific logs.
Windows Event Log I_O Error During Hard Page Fault Error
Checks the system event log for EventId 51. This error is caused by an error during a hard page fault.
Windows Event Log Read Retry Error
Checks the event log for SQL Server error message 825. This message indicates that SQL Server was unable to read data from the disk on the first try. Youll need to check the disks, disk controllers, array cards, and disk drivers.
Windows Event Log Storage System I_O Timeout Error
Checks the system event log for EventId 9. This message indicates that an I/O time-out has occurred in the storage system.
Windows Event Log System Failure Error
Checks for the system event log for EventId 6008. This event indicates an unexpected system shutdown.
Next topic will be How to configure Policay Based management in SQL Server 2008 with illustration.
Leave a Reply