Exam 70-450: PRO: Designing, Optimizing and Maintaining a Database Administrative Solution Using Microsoft SQL Server 2008 Defining high-availability solutions Data distribution Automating administrative tasks (for example, checking db stats, backups) Maintaining administrative tasks (for example, determining index rebuild time, file groups for backup) Defining security solutions Monitoring and troubleshooting the database server Performance optimization (for example, physical tuning, including hardware, operating system, instance-level tuning), PerfMon Designing and executing deployments Deployments and migration Defining the infrastructure (for example, storage, hardware, and number of servers or instances)

Skills Being MeasuredThis exam measures your ability to accomplish the technical tasks listed below.The percentages indicate the relative weight of each major topic area on the exam.

Designing a SQL Server Instance and a Database Solution (14 percent) Design for CPU, memory, and storage capacity requirements. This objective may include but is not limited to: RAID, calculating table size, IO throughput, transaction per second, data compression, non-uniform memory access (NUMA), tempdb capacity Design SQL Server instances. This objective may include but is not limited to: instance configuration, surface area configuration, CPU affinity, memory allocation, max degree of parallelism (MAXDOP), collation Design physical database and object placement. This objective may include but is not limited to: heap and index placement, filestream, data and log files, filegroups, partition placement, large object placement, full text catalog Design a migration, consolidation, and upgrade strategy. This objective may include but is not limited to: multi-instance considerations, SQL Server version upgrade, instance and database collation, server-level and instance-level objects, service pack applicationDesigning a Database Server Security Solution (15 percent) Design instance authentication This objective may include but is not limited to: choosing authentication type, logon triggers, regulatory requirements Design instance-level security configurations This objective may include but is not limited to: Windowsservice accounts, filestream, proxy, credentials, instance-level permissions, certificate and key management, endpoint security, using SSL certificates, TCP ports Design database, schema, and object security paramaters This objective may include but is not limited to: users, roles, certificate and key management, Service broker, Common Language Runtime (CLR), ownership chains Design a security policy and an audit plan This objective may include but is not limited to: Policy-Based Management Framework, security functions, sp_helprotect, catalog views, extended events, notifications Design an encryption strategy This objective may include but is not limited to: Transparent Data Encryption, encrypting protected data, certificate and key management, filestreamDesigning a Database Solution for High Availability (15 percent) Design a failover clustering solution This objective may include but is not limited to: cluster resource group, cluster setup considerations, number of nodes, service accounts Design database mirroring This objective may include but is not limited to: whether to use a witness server, Windows Server considerations, suspend vs. stop, automatic or manual failover, automatic page repair, database snapshots for reporting, managing instance-level objects Design a high-availability solution that is based on replication This objective may include but is not limited to: different replication types, topologies, recover from replication failure, synchronization, health monitoring Design a high-availability solution that is based on log shipping This objective may include but is not limited to: manage instance-level objects, changing roles, reporting secondary instance for reporting, monitor server, reinitializing, consistency check on secondary instance Select high-availability technologies based on business requirements This objective may include but is not limited to: failover clustering, database mirroring, log shipping, replicationDesigning a Backup and Recovery Solution (20 percent) Design a backup strategy This objective may include but is not limited to: recovery model, compression, choosing backup types, scheduling, backup media, file and filegroups backup, verifying backups, key management, mirrored backups, cluster considerations Design a recovery strategy This objective may include but is not limited to: page, file, filegroup, partial and online restores, orphan users, instance rebuild, encryption considerations, handling media failures, transaction logs, point in time and mark recovery, filestreams Design a recovery test plan This objective may include but is not limited to: log shipping, replication, hardware considerations, scheduling a database restore test, handling high availability failuresDesigning a Monitoring Strategy (13 percent) Design a monitoring solution at the operating system level This objective may include but is not limited to: system monitor counters, event logs, dynamic management views and functions, Windows Management Instrumentation (WMI), remote monitoring, analyze results Design a monitoring solution at the instance level This objective may include but is not limited to: instance, database and object monitoring, data collection, event notifications, dynamic management objects, analyze results Design a solution to monitor performance and concurrency This objective may include but is not limited to: Dedicated Administrator Connection (DAC), locking, blocking, deadlocks, dynamic management objects, index utilization, tracing, analyzeDesigning a Strategy to Maintain and Manage Databases (14 percent) Design a maintenance strategy for database servers This objective may include but is not limited to: rebuild for page-level compression, index and heap maintenance, partition management, statistics Design a solution to govern resources This objective may include but is not limited to: Resource Governor (CPU, memory, number of requests per second; resource pools, resource groups), query governor Design policies by using Policy-Based Management This objective may include but is not limited to: designing policies and conditions Design a data compression strategy This objective may include but is not limited to: row vs. page level, update frequency, compression ratio, compressing partitions, specific indexes Design a management automation strategy This objective may include but is not limited to: SQL Server PowerShell, Windows Management Instrumentation (WMI), SQL Server Agent, event notifications, DDL triggersDesigning a Strategy for Data Distribution (9 percent) Administer SQL Server Integration Services (SSIS) packages This objective may include but is not limited to: design security for accessing packages, troubleshoot and restart package, schedule package execution, deploy packages to same or different instances Design a strategy to use linked servers This objective may include but is not limited to: security, providers, distributed transactions Design a replication strategy for data distribution This objective may include but is not limited to: selecting replication types, conflict resolution, health monitoring, horizontal and vertical partitioning

Understanding Surface Area ConfigurationIn the default configuration of new installations of SQL Server, many features are not enabled. SQL Server selectively installs and starts only key services and features, to minimize the number of features that can be attacked by a malicious user. A system administrator can change these defaults at installation time and also selectively enable or disable features of a running instance of SQL Server.Additionally, some components may not be available when connecting from other computers until protocols are configured.Note

Unlike new installations, no existing services or features are turned off during an upgrade, but additional surface area configuration options can be applied after the upgrade is completed.

Protocols, Connection, and Startup Options Use SQL Server Configuration Manager to start and stop services, configure the startup options, and enableprotocolsand other connection options.To start SQL Server Configuration Manager On the Start menu, point to All Programs, point to Microsoft SQL Server 2008 R2, point to Configuration Tools, and then click SQL Server Configuration Manager. Use the SQL Server Services area to start components and configure the automatic starting options. Use the SQL Server Network Configuration area to enable connection protocols, and connection options such as fixed TCP/IP ports, or forcing encryption.For more information, see SQL Server Configuration Manager. Remote connectivity can also depend upon the correct configuration of a firewall. For more information, see Configuring the Windows Firewall to Allow SQL Server Access.Enabling and Disabling Features Enabling and disabling SQL Serverfeatures can be configured using facets in SQL Server Management Studio.To configure surface area using facets1. In Management Studio connect to a component of SQL Server.2. In Object Explorer, right-click the server, and then click Facets.3. In the View Facets dialog box, expand the Facet list, and select the appropriate Surface Area Configuration facet (Surface Area Configuration, Surface Area Configuration for Analysis Services, or Surface Area Configuration for Reporting Services).4. In the Facet properties area, select the values that you want for each property.5. Click OK.

Understanding How to Set the SQL Server I/O Affinity OptionThe affinity mask configuration option defined in the sp_configure stored procedure allows you to specify which CPUs on a multiprocessor computer are to be used to run threads from an instance of SQL Server. You can use the affinity mask configuration option to exclude SQL Server threads from processors that you want to reserve for operating system processes. For more information about the affinity mask option, see SQL Server 2000 Books Online. Similarly, IO_affinity_mask allows you to specify which CPUs are configured to run SQL Server threads related to I/O operations.

When you are running an instance of SQL Server on large, enterprise-level multiprocessor computers with more than 16 CPUs, you may attain additional performance benefits by using the IO_affinity_mask switch in conjunction with the affinity mask option. This provides the capability to specify which CPUs are affinitized for SQL Server disk operations and which CPUs service the remaining processing associated with SQL Server.

In almost all cases, leaving IO_affinity_mask at its default setting results in the best performance. Some sites may see an improvement in performance by setting the IO_affinity_mask option.

You may create a performance bottleneck for non-disk related CPU requirements if the number of CPUs allocated to SQL Server disk IO processing is more than what the system needs for disk IO processing. Conversely, a performance bottleneck for disk IO may be created if you enable less CPUs to SQL Server disk IO processing than what the system needs for disk IO processing.

Configure Parallel Processing in SQL Server 2008A lot of calculations are required to determine whether parallel processing should be used. Generally, SQL Server processes queries in parallel in the following cases:When the number of CPUs is greater than the number of active connections.When the estimated cost for the serial execution of a query is higher than the query plan threshold (The estimated cost refers to the elapsed time in seconds required to execute the query serially.)Certain types of statements cannot be processed in parallel unless they contain clauses, however. For example, UPDATE, INSERT, and DELETE are not normally processed in parallel even if the related query meets the criteria. But if the UPDATE or DELETE statements contain a WHERE clause, or an INSERT statement contains a SELECT clause, WHERE and SELECT can be executed in parallel. Changes are applied serially to the database in these cases.To configure parallel processing, simply do the following:1. In the Server Properties dialog box, go to the Advanced page. 2. By default, the Max Degree Of Parallelism setting has a value of 0, which means that the maximum number of processors used for parallel processing is controlled automatically. Essentially, SQL Server uses the actual number of available processors, depending on the workload. To limit the number of processors used for parallel processing to a set amount (up to the maximum supported by SQL Server), change the Max Degree Of Parallelism setting to a value greater than 1. A value of 1 tells SQL Server not to use parallel processing. 3. Large, complex queries usually can benefit from parallel execution. However, SQL Server performs parallel processing only when the estimated number of seconds required to run a serial plan for the same query is higher than the value set in the cost threshold for parallelism. Set the cost estimate threshold using the Cost Threshold for Parallelism box on the advanced page of the Server Properties dialog box. You can use any value from 0 through 32,767. On a single CPU, the cost threshold is ignored. 4. Click OK. These changes are applied immediately. You do not need to restart the server

Logon TriggersLogon triggers fire stored procedures in response to a LOGON event. This event is raised when a user session is established with an instance of SQL Server. Logon triggers fire after the authentication phase of logging in finishes, but before the user session is actually established. Therefore, all messages originating inside the trigger that would typically reach the user, such as error messages and messages from the PRINT statement, are diverted to the SQL Server error log. Logon triggers do not fire if authentication fails. You can use logon triggers to audit and control server sessions, such as by tracking login activity, restricting logins to SQL Server, or limiting the number of sessions for a specific login. For example, in the following code, the logon trigger denies log in attempts to SQL Server initiated by login login_test if there are already three user sessions created by that login.CopyUSE master;GOCREATE LOGIN login_test WITH PASSWORD = '3KHJ6dhx(0xVYsdf' MUST_CHANGE, CHECK_EXPIRATION = ON;GOGRANT VIEW SERVER STATE TO login_test;GOCREATE TRIGGER connection_limit_triggerON ALL SERVER WITH EXECUTE AS 'login_test'FOR LOGONASBEGINIF ORIGINAL_LOGIN()= 'login_test' AND (SELECT COUNT(*) FROM sys.dm_exec_sessions WHERE is_user_process = 1 AND original_login_name = 'login_test') > 3 ROLLBACK;END;

Note that the LOGON event corresponds to the AUDIT_LOGIN SQL Trace event, which can be used in event notifications. The primary difference between triggers and event notifications is that triggers are raised synchronously with events, whereas event notifications are asynchronous. This means, for example, that if you want to stop a session from being established, you must use a logon trigger. An event notification on an AUDIT_LOGIN event cannot be used for this purpose.

Compression A. Creating a table that uses row compressionThe following example creates a table and sets the compression to ROW.CREATE TABLE T1 (c1 int, c2 nvarchar(50) )WITH (DATA_COMPRESSION = ROW);GO

B. Creating a table that uses page compressionThe following example create a table and sets the compression to PAGE.CREATE TABLE T2 (c1 int, c2 nvarchar(50) )WITH (DATA_COMPRESSION = PAGE);GO

C. Setting the DATA_COMPRESSION option on a partitioned tableThe following example uses the TestDatabase table that is created by using the code provided earlier in this section. The example creates a partition function and scheme, and then creates a partitioned table and specifies the compression options for the partitions of the table. In this example, partition 1 is configured for ROW compression, and the remaining partitions are configured for PAGE compression.To create a partition function:CREATE PARTITION FUNCTION myRangePF1 (int)AS RANGE LEFT FOR VALUES (1, 100, 1000) ;GO

To create a partition scheme:CREATE PARTITION SCHEME myRangePS1AS PARTITION myRangePF1TO (test1fg, test2fg, test3fg, test4fg) ;GO

To create a partitioned table that has compressed partitions:CREATE TABLE PartitionTable1 (col1 int, col2 varchar(max))ON myRangePS1 (col1) WITH ( DATA_COMPRESSION = ROW ON PARTITIONS (1), DATA_COMPRESSION = PAGE ON PARTITIONS (2 TO 4));GO

D. Setting the DATA_COMPRESSION option on a partitioned tableThe following example uses the database that is used in example C. The example creates a table by using the syntax for noncontiguous partitions.CREATE TABLE PartitionTable2 (col1 int, col2 varchar(max))ON myRangePS1 (col1) WITH ( DATA_COMPRESSION = ROW ON PARTITIONS (1,3), DATA_COMPRESSION = NONE ON PARTITIONS (2,4));GO

E. Modifying a table to change the compressionThe following example changes the compression of the nonpartitioned table that is created in example A.ALTER TABLE T1 REBUILD WITH (DATA_COMPRESSION = PAGE);GO

F. Modifying the compression of one partition in a partitioned tableThe following example changes the compression of the partitioned table that is created in example C. The REBUILD PARTITION = 1 syntax causes only partition number 1 to be rebuilt.ALTER TABLE PartitionTable1 REBUILD PARTITION = 1 WITH (DATA_COMPRESSION = NONE) ;GO

The same operation that uses the following alternate syntax causes all partitions in the table to be rebuilt.ALTER TABLE PartitionTable1 REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE ON PARTITIONS(1) ) ;GO

G. Modifying the compression of a several partitions in a partitioned tableThe REBUILD PARTITION = ... syntax can rebuild only one partition. To rebuild more than one partition, you must execute multiple statements, or execute the following example to rebuild all partitions, using the current compression settings for unspecified partitions.ALTER TABLE PartitionTable1 REBUILD PARTITION = ALL WITH(DATA_COMPRESSION = PAGE ON PARTITIONS(1), DATA_COMPRESSION = ROW ON PARTITIONS(2 TO 4) ) ;GO

H. Modifying the compression on an indexThe following example uses the table that is created in example A and creates an index on the column C2.CREATE NONCLUSTERED INDEX IX_INDEX_1 ON T1 (C2) WITH ( DATA_COMPRESSION = ROW ) ; GO

Execute the following code to change the index to page compression:ALTER INDEX IX_INDEX_1 ON T1REBUILD WITH ( DATA_COMPRESSION = PAGE ) ;GO

I. Modifying the compression of a single partition in a partitioned indexThe following example creates an index on a partitioned table that uses row compression on all partitions of the index.CREATE CLUSTERED INDEX IX_PartTab2Col1ON PartitionTable1 (Col1)WITH ( DATA_COMPRESSION = ROW ) ;GO

To create the index so that is uses different compression settings for different partitions, use the ON PARTITIONS syntax. The following example creates an index on a partitioned table that uses row compression on partition 1 of the index and page compression on partitions 2 through 4 of the index.CREATE CLUSTERED INDEX IX_PartTab2Col1ON PartitionTable1 (Col1)WITH (DATA_COMPRESSION = ROW ON PARTITIONS(1), DATA_COMPRESSION = PAGE ON PARTITIONS (2 TO 4 ) ) ;GO

The following example changes the compression of the partitioned index.ALTER INDEX IX_PartTab2Col1 ON PartitionTable1REBUILD PARTITION = ALL WITH ( DATA_COMPRESSION = PAGE ON PARTITIONS(1) ) ;GO

J. Modifying the compression of a several partitions in a partitioned indexThe REBUILD PARTITION = ... syntax can rebuild only one partition. To rebuild more than one partition, you must execute multiple statements, or execute the following example to rebuild all partitions, using the current compression settings for unspecified partitions.ALTER INDEX IX_PartTab2Col1 ON PartitionTable1REBUILD PARTITION = ALL WITH(DATA_COMPRESSION = PAGE ON PARTITIONS(1), DATA_COMPRESSION = ROW ON PARTITIONS(2 TO 4) ) ;GO