What’s New in SQL Server System and Database Administration
System Administrator Responsibilities
System Databases
System Tables
System Views
System Stored Procedures
Summary
8 Installing SQL Server 2008
What’s New in Installing SQL Server 2008
Installation Requirements
Installation Walkthrough
Installing SQL Server Using a Configuration File
Installing Service Packs and Cumulative Updates
Slipstream Installations
Summary
9 Upgrading to SQL Server 2008
What’s New in Upgrading SQL Server
Using the SQL Server Upgrade Advisor (UA)
Destination: SQL Server 2008 or SQL Server 2008 R2
Upgrading Using a Configuration File
Slipstreaming Upgrades
Upgrading Other SQL Server Components
Summary
10 Client Installation and Configuration
What’s New in Client Installation and Configuration
Client/Server Networking Considerations
Client Installation
Client Configuration
Client Data Access Technologies
Summary
11 Security and User Administration
What’s New in Security and User Administration
An Overview of SQL Server Security
Authentication Methods
Managing Principals
Managing Securables
Managing Permissions
Managing SQL Server Logins
Managing SQL Server Users
Managing Database Roles
Managing SQL Server Permissions
The Execution Context
Summary
12 Data Encryption
What’s New in Data Encryption
An Overview of Data Security
An Overview of Data Encryption
SQL Server Key Management
Column-Level Encryption
Transparent Data Encryption
Column-Level Encryption Versus Transparent Data Encryption
Summary
13 Security and Compliance
Exposure and Risk
Across the Life Cycle
The Security Big Picture
Identity Access Management Components
Compliance and SQL Server
SQL Server Auditing
Setting Up Auditing via T-SQL
SQL Injection Is Easy to Do
Summary
14 Database Backup and Restore
What’s New in Database Backup and Restore
Developing a Backup and Restore Plan
Types of Backups
Recovery Models
Backup Devices
Backing Up a Database
Backing Up the Transaction Log
Backup Scenarios
Restoring Databases and Transaction Logs
Restore Scenarios
Additional Backup Considerations
Summary
15 Database Mail
What’s New in Database Mail
Setting Up Database Mail
Sending and Receiving with Database Mail
Using SQL Server Agent Mail
Related Views and Procedures
Summary
16 SQL Server Scheduling and Notification
What’s New in Scheduling and Notification
Configuring the SQL Server Agent
Viewing the SQL Server Agent Error Log
SQL Server Agent Security
Managing Operators
Managing Jobs
Managing Alerts
Scripting Jobs and Alerts
Multiserver Job Management
Event Forwarding
Summary
17 Administering SQL Server 2008 with PowerShell
What’s New with PowerShell
Overview of PowerShell
PowerShell Scripting Basics
PowerShell in SQL Server 2008
Step-By-Step Examples
Summary
18 SQL Server High Availability
What’s New in High Availability
What Is High Availability?
The Fundamentals of HA
Building Solutions with One or More HA Options
Other HA Techniques That Yield Great Results
High Availability from the Windows Server Family Side
Summary
19 Replication
What’s New in Data Replication
What Is Replication?
The Publisher, Distributor, and Subscriber Magazine Metaphor
Replication Scenarios
Subscriptions
Replication Agents
Planning for SQL Server Data Replication
SQL Server Replication Types
Basing the Replication Design on User Requirements
Setting Up Replication
Scripting Replication
Monitoring Replication
Summary
20 Database Mirroring
What’s New in Database Mirroring
What Is Database Mirroring?
Roles of the Database Mirroring Configuration
Setting Up and Configuring Database Mirroring
Testing Failover from the Principal to the Mirror
Client Setup and Configuration for Database Mirroring
Migrate to Database Mirroring 2008 as Fast as You Can
Using Replication and Database Mirroring Together
Using Database Snapshots from a Mirror for Reporting
Summary
21 SQL Server Clustering
What’s New in SQL Server Clustering
How Microsoft SQL Server Clustering Works
Installing SQL Server Clustering
Summary
22 Administering Policy-Based Management
Introduction to Policy-Based Management
Policy-Based Management Concepts
Implementing Policy-Based Management
Sample Templates and Real-World Examples
Policy-Based Management Best Practices
Summary
Part IV: Database Administration
23 Creating and Managing Databases
What’s New in Creating and Managing Databases
Data Storage in SQL Server
Database Files
Creating Databases
Setting Database Options
Managing Databases
Summary
24 Creating and Managing Tables
What’s New in SQL Server 2008
Creating Tables
Defining Columns
Defining Table Location
Defining Table Constraints
Modifying Tables
Dropping Tables
Using Partitioned Tables
Creating Temporary Tables
Summary
25 Creating and Managing Indexes
What’s New in Creating and Managing Indexes
Types of Indexes
Creating Indexes
Managing Indexes
Dropping Indexes
Online Indexing Operations
Indexes on Views
Summary
26 Implementing Data Integrity
What’s New in Data Integrity
Types of Data Integrity
Enforcing Data Integrity
Using Constraints
Rules
Defaults
Summary
27 Creating and Managing Views in SQL Server
What’s New in Creating and Managing Views
Definition of Views
Using Views
Creating Views
Managing Views
Data Modifications and Views
Partitioned Views
Indexed Views
Summary
28 Creating and Managing Stored Procedures
What’s New in Creating and Managing Stored Procedures
Advantages of Stored Procedures
Creating Stored Procedures
Executing Stored Procedures
Deferred Name Resolution
Viewing Stored Procedures
Modifying Stored Procedures
Using Input Parameters
Using Output Parameters
Returning Procedure Status
Debugging Stored Procedures Using SQL Server Management Studio
Using System Stored Procedures
Startup Procedures
Summary
29 Creating and Managing User-Defined Functions
What’s New in SQL Server 2008
Why Use User-Defined Functions?
Types of User-Defined Functions
Creating and Managing User-Defined Functions
Rewriting Stored Procedures as Functions
Creating and Using CLR Functions
Summary
30 Creating and Managing Triggers
What’s New in Creating and Managing Triggers
Using DML Triggers
Using DDL Triggers
Using CLR Triggers
Using Nested Triggers
Using Recursive Triggers
Summary
31 Transaction Management and the Transaction Log
What’s New in Transaction Management
What Is a Transaction?
How SQL Server Manages Transactions
Defining Transactions
Transactions and Batches
Transactions and Stored Procedures
Transactions and Triggers
Transactions and Locking
Coding Effective Transactions
Transaction Logging and the Recovery Process
Long-Running Transactions
Bound Connections
Distributed Transactions
Summary
32 Database Snapshots
What’s New with Database Snapshots
What Are Database Snapshots?
Limitations and Restrictions of Database Snapshots
Copy-on-Write Technology
When to Use Database Snapshots
Setup and Breakdown of a Database Snapshot
Reverting to a Database Snapshot for Recovery
Setting Up Snapshots Against a Database Mirror
Database Snapshots Maintenance and Security Considerations
Summary
33 Database Maintenance
What’s New in Database Maintenance
The Maintenance Plan Wizard
Managing Maintenance Plans Without the Wizard
Executing a Maintenance Plan
Maintenance Without a Maintenance Plan
Database Maintenance Policies
Summary
Part V: SQL Server Performance and Optimization
34 Data Structures, Indexes, and Performance
What’s New for Data Structures, Indexes, and Performance
Understanding Data Structures
Database Files and Filegroups
Database Pages
Space Allocation Structures
Data Compression
Understanding Table Structures
Understanding Index Structures
Data Modification and Performance
Index Utilization
Index Selection
Evaluating Index Usefulness
Index Statistics
SQL Server Index Maintenance
Index Design Guidelines
Indexed Views
Indexes on Computed Columns
Filtered Indexes and Statistics
Choosing Indexes: Query Versus Update Performance
Identifying Missing Indexes
Identifying Unused Indexes
Summary
35 Understanding Query Optimization
What’s New in Query Optimization
What Is the Query Optimizer?
Query Compilation and Optimization
Query Analysis
Row Estimation and Index Selection
Join Selection
Execution Plan Selection
Query Plan Caching
Other Query Processing Strategies
Parallel Query Processing
Common Query Optimization Problems
Managing the Optimizer
Summary
36 Query Analysis
What’s New in Query Analysis
Query Analysis in SSMS
SSMS Client Statistics
Using the SET SHOWPLAN Options
Using sys.dm_exec_query_plan
Query Statistics
Query Analysis with SQL Server Profiler
Summary
37 Locking and Performance
What’s New in Locking and Performance
The Need for Locking
Transaction Isolation Levels in SQL Server
The Lock Manager
Monitoring Lock Activity in SQL Server
SQL Server Lock Types
SQL Server Lock Granularity
Lock Compatibility
Locking Contention and Deadlocks
Table Hints for Locking
Optimistic Locking
Summary
38 Database Design and Performance
What’s New in Database Design and Performance
Basic Tenets of Designing for Performance
Logical Database Design Issues
Denormalizing a Database
Database Filegroups and Performance
RAID Technology
SQL Server and SAN Technology
Summary
39 Monitoring SQL Server Performance
What’s New in Monitoring SQL Server Performance
Performance Monitoring Tools
A Performance Monitoring Approach
Summary
40 Managing Workloads with the Resource Governor
Overview of Resource Governor
Resource Governor Components
Configuring Resource Governor
Monitoring Resource Usage
Modifying Your Resource Governor Configuration
Summary
41 A Performance and Tuning Methodology
The Full Architectural Landscape
Primary Performance and Tuning Handles
A Performance and Tuning Methodology
Performance and Tuning Design Guidelines
Tools of the Performance and Tuning Trade
Summary
Part VI: SQL Server Application Development
42 What’s New for Transact-SQL in SQL Server 2008
MERGE Statement
Insert over DML
GROUP BY Clause Enhancements
Variable Assignment in DECLARE Statement
Compound Assignment Operators
Row Constructors
New date and time Data Types and Functions
Table-Valued Parameters
Hierarchyid Data Type
Using FILESTREAM Storage
Sparse Columns
Spatial Data Types
Change Data Capture
Change Tracking
Summary
43 Transact-SQL Programming Guidelines, Tips, and Tricks
General T-SQL Coding Recommendations
General T-SQL Performance Recommendations
T-SQL Tips and Tricks
In Case You Missed It: New Transact-SQL Features in SQL Server 2005
The xml Data Type
The max Specifier
TOP Enhancements
The OUTPUT Clause
Common Table Expressions
Ranking Functions
PIVOT and UNPIVOT
The APPLY Operator
TRY...CATCH Logic for Error Handling
The TABLESAMPLE Clause
Summary
44 Advanced Stored Procedure Programming and Optimization
T-SQL Stored Procedure Coding Guidelines
Using Cursors in Stored Procedures
Nested Stored Procedures
Using Temporary Tables in Stored Procedures
Using Remote Stored Procedures
Stored Procedure Performance
Using Dynamic SQL in Stored Procedures
Installing and Using .NET CLR Stored Procedures
Using Extended Stored Procedures
Summary
45 SQL Server and the .NET Framework
What’s New in SQL Server 2008 and the .NET Framework
Getting Comfortable with ADO.NET 3.5 and SQL Server 2008
Developing with LINQ to SQL
Using ADO.NET Data Services
Leveraging the Microsoft Sync Framework
Summary
46 SQLCLR: Developing SQL Server Objects in .NET
What’s New for SQLCLR in SQL Server 2008
Developing Custom Managed Database Objects
Summary
47 Using XML in SQL Server 2008
What’s New in Using XML in SQL Server 2008
Understanding XML
Relational Data As XML: The FOR XML Modes
XML As Relational Data: Using OPENXML
Using the xml Data Type
Indexing and Full-Text Indexing of xml Columns
Summary
48 SQL Server Web Services
What’s New in SQL Server Web Services
Web Services Migration Path
Web Services History and Overview
Building Web Services
Examples: A C# Client Application
Using Catalog Views and System Stored Procedures
Controlling Access Permissions
Summary
49 SQL Server Service Broker
What’s New in Service Broker
Understanding Distributed Messaging
Designing a Sample System
Understanding Service Broker Constructs
Service Broker Routing and Security
Troubleshooting SSB Applications with ssbdiagnose.exe
Related System Catalogs
Summary
50 SQL Server Full-Text Search
What’s New in SQL Server 2008 Full-Text Search
Upgrade Options in SQL Server 2008
How SQL Server FTS Works
Implementing SQL Server 2008 Full-Text Catalogs
Setting Up a Full-Text Index
Full-Text Searches
Full-Text Search Maintenance
Full-Text Search Performance
Full-Text Search Troubleshooting
Summary
Part VII: SQL Server Business Intelligence Features
51 SQL Server 2008 Analysis Services
What’s New in SSAS
Understanding SSAS and OLAP
Understanding the SSAS Environment Wizards
An Analytics Design Methodology
An OLAP Requirements Example: CompSales International
Summary
52 SQL Server Integration Services
What’s New with SSIS
SSIS Basics
SSIS Architecture and Concepts
SSIS Tools and Utilities
A Data Transformation Requirement
Running the SSIS Wizard
The SSIS Designer
The Package Execution Utility
Connection Projects in Visual Studio
Change Data Capture Addition with R2
Using bcp
Logged and Nonlogged Operations
Summary
53 SQL Server 2008 Reporting Services
What’s New in SSRS 2008
Reporting Services Architecture
Installing and Configuring SSRS
Developing Reports
Management and Security
Performance and Monitoring
Summary
Part VIII: Bonus Chapters
54 Managing Linked and Remote Servers
What’s New in Managing Linked and Remote Servers
Managing Remote Servers
Linked Servers
Adding, Dropping, and Configuring Linked Servers
Mapping Local Logins to Logins on Linked Servers
Obtaining General Information About Linked Servers
Executing a Stored Procedure via a Linked Server
Setting Up Linked Servers Using SQL Server Management Studio
Summary
55 Configuring, Tuning, and Optimizing SQL Server Options
What’s New in Configuring, Tuning, and Optimizing SQL Server Options
SQL Server Instance Architecture
Configuration Options
Fixing an Incorrect Option Setting
Setting Configuration Options with SSMS
Obsolete Configuration Options
Configuration Options and Performance
Database Engine Tuning Advisor
Data Collection Sets
Summary
56 SQL Server Disaster Recovery Planning
What’s New in SQL Server Disaster Recovery Planning
How to Approach Disaster Recovery
Microsoft SQL Server Options for Disaster Recovery
The Overall Disaster Recovery Process
Have You Detached a Database Recently?
Third-Party Disaster Recovery Alternatives
Summary
Index
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y-Z
Nội dung
ptg 774 CHAPTER 24 Creating and Managing Tables the foreign key constraints that reference a table. Listing 24.18 shows an execution of this stored procedure for the Sales.Store table in the AdventureWorks2008 database. The procedure results include information about all the constraints on the table. The results to focus on are those that follow the heading Table Is Referenced by Foreign Key. The partial results shown in Listing 24.18 for the Sales.Store table indicate that FK_StoreContact_Store_CustomerID must be dropped first before you can drop the Sales.Store table. LISTING 24.18 Using sp_helpconstraint to Find Foreign Key References sp_helpconstraint [Sales.Store] /*partial results of sp_helpconstraint execution Table is referenced by foreign key AdventureWorks2008.Sales.StoreContact: FK_StoreContact_Store_CustomerID */ Two other approaches are useful for identifying foreign key references prior to dropping a table. The first is using a database diagram. You can create a new database diagram and add the table that you are considering for deletion. After the table is added, you right-click the table in Object Explorer and select Add Related Tables. The related tables, including those that have foreign key references, are then added. You can then right-click the rela- tionship line connecting two tables and select Delete Relationships from Database. When you have deleted all the foreign key relationships from the diagram, you can right-click the table you want to delete and select Generate Change Script to create a script that can be used to remove the foreign key relationship(s). The other approach is to right-click the table in Object Explorer and choose View Dependencies. The dialog that appears gives you the option of viewing the objects that depend on the table or viewing the objects on which the table depends. If you choose the option to view the objects that depend on the table, all the dependent objects are displayed, but you can focus on the objects that are tables. Using Partitioned Tables In SQL Server 2008, tables are stored in one or more partitions. Partitions are organiza- tional units that allow you to divide data into logical groups. By default, a table has only a single partition that contains all the data. The power of partitions comes into play when you define multiple partitions for a table that is segmented based on a key column. This column allows the data rows to be horizontally split. For example, a date/time column can be used to divide each month’s data into a separate partition. These partitions can also be aligned to different filegroups for added flexibility, ease of maintenance, and improved performance. Download from www.wowebook.com ptg 775 Using Partitioned Tables 24 The important point to remember is that you access tables with multiple partitions (which are called partitioned tables) the same way you access tables with a single partition. Data Manipulation Language (DML) operations such as INSERT and SELECT statements reference the table the same way, regardless of partitioning. The difference between these types of tables has to do with the back-end storage and the organization of the data. Generally, partitioning is most useful for large tables. Large is a relative term, but these tables typically contain millions of rows and take up gigabytes of space. Often, the tables targeted for partitioning are large tables experiencing performance problems because of their size. Partitioning has several different applications, including the following: . Archival—Table partitions can be moved from a production table to another archive table that has the same structure. When done properly, this partition move- ment is very fast and allows you to keep a limited amount of recent data in the production table while keeping the bulk of the older data in the archive table. . Maintenance—Table partitions that have been assigned to different filegroups can be backed up and maintained independently of each other. With very large tables, maintenance activities on the entire table (such as backups) can take a prohibitively long time. With partitioned tables, these maintenance activities can be performed at the partition level. Consider, for example, a table that is partitioned by month: all the new activity (updates and insertions) occurs in the partition that contains the current month’s data. In this scenario, the current month’s partition would be the focus of the maintenance, thus limiting the amount of data you need to process. . Query performance—Partitioned tables joined on partitioned columns can experi- ence improved performance because the Query Optimizer can join to the table based on the partitioned column. The caveat is that joins across partitioned tables not joining on the partitioned column may actually experience some performance degra- dation. Queries can also be parallelized along the partitions. Now that we have discussed some of the reasons to use partitioned tables, let’s look at how to set up partitions. There are three basic steps: 1. Create a partition function that maps the rows in the table to partitions based on the value of a specified column. 2. Create a partition scheme that outlines the placement of the partitions in the parti- tion function to filegroups. 3. Create a table that utilizes the partition scheme. These steps are predicated on a good partitioning design, based on an evaluation of the data within the table and the selection of a column that will effectively split the data. If multiple filegroups are used, those filegroups must also exist before you execute the three steps in partitioning. The following sections look at the syntax related to each step, using simple examples. These examples utilize the BigPubs2008 database. Download from www.wowebook.com ptg 776 CHAPTER 24 Creating and Managing Tables Creating a Partition Function A partition function identifies values within a table that will be compared to the column on which you partition the table. As mentioned previously, it is important that you know the distribution of the data and the specific range of values in the partitioning column before you create the partition function. The following query provides an example of determining the distribution of data values in the sales_big table by year: Select the distinct yearly values SELECT year(ord_date) as ‘year’, count(*) ‘rows’ FROM sales_big GROUP BY year(ord_date) ORDER BY 1 go year rows 2005 30 2006 613560 2007 616450 2008 457210 You can see from the results of the SELECT statement that there are four years’ worth of data in the sales_big table. Because the values specified in the CREATE PARTITION FUNC- TION statement are used to establish data ranges, at a minimum, you would need to specify at least three data values when defining the partition function, as shown in the following example: Create partition function with the yearly values to partition the data CREATE PARTITION FUNCTION SalesBigPF1 (datetime) AS RANGE RIGHT FOR VALUES (‘01/01/2006’, ‘01/01/2007’, ‘01/01/2008’) GO In this example, four ranges, or partitions, would be established by the three RANGE RIGHT values specified in the statement: . values < 01/01/2006—This partition includes any rows prior to 2006. . values >= 01/01/2006 AND values < 01/01/2007—This partition includes all rows for 2006. . values >= 01/01/2007 AND values < 01/01/2008—This partition includes all rows for 2007. . values > 01/01/2008—This includes any rows for 2008 or later. This method of partitioning would be more than adequate for a static table that is not going to be receiving any additional data rows for different years than already exist in the Download from www.wowebook.com ptg 777 Using Partitioned Tables 24 table. However, if the table is going to be populated with additional data rows after it has been partitioned, it is good practice to add additional range values at the beginning and end of the ranges to allow for the insertion of data values less than or greater than the existing range values in the table. To create these additional upper and lower ranges, you would want to specify five values in the VALUES clause of the CREATE PARTITION FUNCTION, as shown in Listing 24.19. The advantages of having these additional partitions are demonstrated later in this section. LISTING 24.19 Creating a Partition Function if exists (select 1 from sys.partition_functions where name = ‘SalesBigPF1’) drop partition function SalesBigPF1 go Create partition function with the yearly values to partition the data Create PARTITION FUNCTION SalesBigPF1 (datetime) AS RANGE RIGHT FOR VALUES (‘01/01/2005’, ‘01/01/2006’, ‘01/01/2007’, ‘01/01/2008’, ‘01/01/2009’) GO In this example, six ranges, or partitions, are established by the five range values specified in the statement: . values < 01/01/2005—This partition includes any rows prior to 2005. . values >= 01/01/2005 AND values < 01/01/2006—This partition includes all rows for 2005. . values >= 01/01/2006 AND values < 01/01/2007—This partition includes all rows for 2006. . values >= 01/01/2007 AND values < 01/01/2008—This partition includes all rows for 2007. . values >= 01/01/2008 AND values < 01/01/2009—This partition includes all rows for 2008. . values >= 01/01/2009—This partition includes any rows for 2009 or later. An alternative to the RIGHT clause in the CREATE PARTITION FUNCTION statement is the LEFT clause. The LEFT clause is similar to RIGHT, but it changes the ranges such that the < operands are changed to <=, and the >= operands are changed to >. TIP Using RANGE RIGHT partitions for datetime values is usually best because this approach makes it easier to specify the limits of the ranges. The datetime data type can store values only with accuracy to 3.33 milliseconds. The largest value it can store is 0.997 milliseconds. A value of 0.998 milliseconds rounds down to 0.997, and a value of 0.999 milliseconds rounds up to the next second. Download from www.wowebook.com ptg 778 CHAPTER 24 Creating and Managing Tables If you used a RANGE LEFT partition, the maximum time value you could include with the year to get all values for that year would be 23:59:59.997. For example, if you speci- fied 12/31/2006 23:59:59.999 as the boundary for a RANGE LEFT partition, it would be rounded up so that it would also include rows with datetime values less than or equal to 01/01/2007 00:00:00.000, which is probably not what you would want. You would redefine the example shown in Listing 24.19 as a RANGE LEFT partition function as follows: CREATE PARTITION FUNCTION SalesBigPF1 (datetime) AS RANGE LEFT FOR VALUES (‘12/31/2004 23:59:59.997’, ‘12/31/2005 23:59:59.997’, ‘12/31/2006 23:59: 59.997’, ‘12/31/2007 23:59:59.997’, ‘12/31/2008 23:59:59.997’) As you can see, it’s a bit more straightforward and probably less confusing to use RANGE RIGHT partition functions when dealing with datetime values or any other con- tinuous-value data types, such as float or numeric. Creating a Partition Scheme After you create a partition function, the next step is to associate a partition scheme with the partition function. A partition scheme can be associated with only one partition func- tion, but a partition function can be shared across multiple partition schemes. The core function of a partition scheme is to map the values defined in the partition func- tion to filegroups. When creating the statement for a partition scheme, you need to keep in mind the following: . A single filegroup can be used for all partitions, or a separate filegroup can be used for each individual partition. . Any filegroup referenced in the partition scheme must exist before the partition scheme is created. . There must be enough filegroups referenced in the partition scheme to accommo- date all the partitions. The number of partitions is one more than the number of values specified in the partition function. . The number of partitions is limited to 1,000. . The filegroups listed in the partition scheme are assigned to the partitions defined in the function based on the order in which the filegroups are listed. Listing 24.20 creates a partition schema that references the partition function created in Listing 24.19. This example assumes that the referenced filegroups have been created for each of the partitions. (For more information on creating filegroups and secondary files, see Chapter 23.) Download from www.wowebook.com ptg 779 Using Partitioned Tables 24 NOTE If you would like to create the same filegroups and files used by the examples in this section, check out the script file called Create_Filegroups_and_Files_for_ Partitioning.sql on the included CD in the code listings directory for this chapter. If you run this script, it creates all the necessary file groups and files referenced in the examples. Note that you need to edit the script to change the FILENAME value if you need the files to be created in a directory other than C:\MSSQL2008\DATA. LISTING 24.20 Creating a Partition Scheme Create a partition scheme that is aligned with the partition function CREATE PARTITION SCHEME SalesBigPS1 AS PARTITION SalesBigPF1 TO ([Older_data], [2005_data], [2006_data], [2007_data], [2008_data], [2009_data]) GO Alternatively, if all partitions are going to be on the same filegroup, such as the PRIMARY filegroup, you could use the following: Create PARTITION SCHEME SalesBigPS1 as PARTITION SalesBigPF1 ALL to ([PRIMARY]) go Notice that SalesBigPF1 is referenced as the partition function in Listing 24.20. This ties together the partition scheme and partition function. Figure 24.7 shows how the parti- tions defined in the function would be mapped to the filegroup(s). At this point, you have made no changes to any table, and you have not even specified the column in the table that you will partition. The next section discusses those details. Creating a Partitioned Table Tables are partitioned only when they are created. This is an important point to keep in mind when you are considering adding partitions to a table that already exists. Sometimes, performance issues or other factors may lead you to determine that a table you have already created and populated may benefit from being partitioned. The re-creation of large tables in a production environment requires some forethought and planning. The data in the table must be retained in another location for you to re- create the table. Bulk copying the data to a flat file and renaming the table are two possi- ble solutions for retaining the data. After you determine the data retention method, you can re-create the table, with the new partition scheme. For simplicity’s sake, the example in Listing 24.21 creates a new table named sales_big_Partitioned instead of using the Download from www.wowebook.com ptg 780 CHAPTER 24 Creating and Managing Tables 1996_data Filegroup 1996_data Filegroup Older_data Filegroup 1992_data Filegroup 1993_data Filegroup 1994_data Filegroup 1995_data Filegroup Boundary 1 Boundary 2 Boundary 3 Partition Scheme Boundary 4 Boundary 5 1992-01-01 1993-01-01 1994-01-01 1995-01-01 1996-01-01 1 Partition # 2 3 4 5 6 1991 and Earlier Data 1992 Data 1993 Data 1994 Data 1995 Data 1996 Data Later Data FIGURE 24.7 Mapping of partitions to filegroups, using a RANGE RIGHT partition function. original sales_big table. The second part of Listing 24.21 copies the data from the sales_big table into the sales_big_Partitioned table. LISTING 24.21 Creating a Partitioned Table CREATE TABLE dbo.sales_big_Partitioned( sales_id int IDENTITY(1,1) NOT NULL, stor_id char(4) NOT NULL, ord_num varchar(20) NOT NULL, ord_date datetime NOT NULL, qty smallint NOT NULL, payterms varchar(12) NOT NULL, title_id dbo.tid NOT NULL ) ON SalesBigPS1 (ord_date) this statement is key to Partitioning the table GO GO Insert data from the sales_big table into the new sales_big_partitioned table SET IDENTITY_INSERT sales_big_Partitioned ON GO INSERT sales_big_Partitioned with (TABLOCKX) (sales_id, stor_id, ord_num, ord_date, qty, payterms, title_id) SELECT sales_id, stor_id, ord_num, ord_date, qty, payterms, title_id FROM sales_big Download from www.wowebook.com ptg 781 Using Partitioned Tables 24 go SET IDENTITY_INSERT sales_big_Partitioned OFF GO The key clause to take note of in this listing is ON SalesBigPS1 (ord_date). This clause identifies the partition scheme on which to create the table (SalesBigPS1) and the column within the table to use for partitioning (ord_date). After you create the table, you might wonder whether the table was partitioned correctly. Fortunately, there are some catalog views related to partitions that you can query for this kind of information. Listing 24.22 shows a sample SELECT statement that utilizes the sys.partitions view. The results of the statement execution are shown immediately after the SELECT statement. Notice that there are six numbered partitions and that the esti- mated number of rows for each partition corresponds to the number of rows you saw when you selected the data from the unpartitioned SalesBig table. LISTING 24.22 Viewing Partitioned Table Information select convert(varchar(16), ps.name) as partition_scheme, p.partition_number, convert(varchar(10), ds2.name) as filegroup, convert(varchar(19), isnull(v.value, ‘’), 120) as range_boundary, str(p.rows, 9) as rows from sys.indexes i join sys.partition_schemes ps on i.data_space_id = ps.data_space_id join sys.destination_data_spaces dds on ps.data_space_id = dds.partition_scheme_id join sys.data_spaces ds2 on dds.data_space_id = ds2.data_space_id join sys.partitions p on dds.destination_id = p.partition_number and p.object_id = i.object_id and p.index_id = i.index_id join sys.partition_functions pf on ps.function_id = pf.function_id LEFT JOIN sys.Partition_Range_values v on pf.function_id = v.function_id and v.boundary_id = p.partition_number - pf.boundary_value_on_right WHERE i.object_id = object_id(‘sales_big_partitioned’) and i.index_id in (0, 1) order by p.partition_number /* Results from the previous SELECT statement partition_scheme partition_number filegroup range_boundary rows SalesBigPS1 1 Older_Data 0 SalesBigPS1 2 2005_Data 2005-01-01 00:00:00 30 SalesBigPS1 3 2006_Data 2006-01-01 00:00:00 613560 SalesBigPS1 4 2007_Data 2007-01-01 00:00:00 616450 SalesBigPS1 5 2008_Data 2008-01-01 00:00:00 457210 SalesBigPS1 6 2009_Data 2009-01-01 00:00:00 0 */ Download from www.wowebook.com ptg 782 CHAPTER 24 Creating and Managing Tables Adding and Dropping Table Partitions One of the most useful features of partitioned tables is that you can add and drop entire partitions of table data in bulk. If the table partitions are set up properly, these commands can take place in seconds, without the expensive input/output (I/O) costs of physically copying or moving the data. You can add and drop table partitions by using the SPLIT RANGE and MERGE RANGE options of the ALTER PARTITION FUNCTION command: ALTER PARTITION FUNCTION partition_function_name() { SPLIT RANGE ( boundary_value ) | MERGE RANGE ( boundary_value ) } Adding a Table Partition The SPLIT RANGE option adds a new boundary point to an existing partition function and affects all objects that use this partition function. When this command is run, one of the function partitions is split in two. The new partition is the one that contains the new boundary point. The new partition is created to the right of the boundary value if the partition is defined as a RANGE RIGHT partition function or to the left of the boundary if it is a RANGE LEFT partition function. If the partition is empty, the split is instantaneous. If the partition being split contains data, any data on the new side of the boundary is physically deleted from the old partition and inserted into the new partition. In addition to being I/O intensive, a split is also log intensive, generating log records that are four times the size of the data being moved. In addition, an exclusive table lock is held for the duration of the split. If you want to avoid this costly overhead when adding a new parti- tion to the end of the partition range, it is recommended that you always keep an empty partition available at the end and split it before it is populated with data. If the partition is empty, SQL Server does not need to scan the partition to see whether there is any data to be moved. NOTE Avoiding the overhead associated with splitting a partition is the reason the code in Listing 24.19 defined the SalesBigPF1 partition function with a partition for 2009, even though there is no 2009 data in the sales_big_partitioned table. As long as you split the partition before any 2009 data is inserted into the table and the 2009 partition is empty, no data needs to be moved, so the split is instantaneous. Before you split a partition, a filegroup must be marked to be the NEXT USED partition by the partition scheme that uses the partition function. You initially allocate filegroups to partitions by using a CREATE PARTITION SCHEME statement. If a CREATE PARTITION SCHEME statement allocates more filegroups than there are partitions defined in the CREATE PARTI- TION FUNCTION statement, one of the unassigned filegroups is automatically marked as NEXT USED by the partition scheme, and it will hold the new partition. Download from www.wowebook.com ptg 783 Using Partitioned Tables 24 If there are no filegroups currently marked NEXT USED by the partition scheme, you must use ALTER PARTITION SCHEME to either add a filegroup or designate an existing filegroup to hold the new partition. This can be a filegroup that already holds existing partitions. Also, if a partition function is used by more than one partition scheme, all the partition schemes that use the partition function to which you are adding partitions must have a NEXT USED filegroup. If one or more do not have a NEXT USED filegroup assigned, the ALTER PARTITION FUNCTION statement fails, and the error message displays the partition scheme or schemes that lack a NEXT USED filegroup. The following SQL statement adds a NEXT USED filegroup to the SalesBigPS1 partition scheme. Note that in this example, the filegroup specified is a new filegroup, 2010_DATA: ALTER PARTITION SCHEME SalesBigPS1 NEXT USED ‘2010_Data’ Now that you have specified a NEXT USED filegroup for the partition scheme, you can go ahead and add the new range for 2010 and later data rows to the partition function, as in the following example: Alter partition function with the yearly values to partition the data ALTER PARTITION FUNCTION SalesBigPF1 () SPLIT RANGE (‘01/01/2010’) GO Figure 24.8 shows the effects of splitting the 2009 table partition. You can also see the effects of splitting the partition on the system catalogs by running the same query as shown earlier, in Listing 24.22: Boundary 6 Added 1997-01-01 Boundary 1 Boundary 2 Boundary 3 Boundary 4 Boundary 5 1992-01-01 1993-01-01 1994-01-01 1995-01-01 1996-01-01 1 2 3 4 5 76 1991 and Earlier Data 1992 Data 1993 Data 1994 Data 1995 Data 1996 Data 1997 and Later Data Any 1997 and later data will be moved FIGURE 24.8 The effects of splitting a RANGE RIGHT table partition. Download from www.wowebook.com . displayed, but you can focus on the objects that are tables. Using Partitioned Tables In SQL Server 2008, tables are stored in one or more partitions. Partitions are organiza- tional units that. values >= 01/01/2007 AND values < 01/01 /2008 This partition includes all rows for 2007. . values > 01/01 /2008 This includes any rows for 2008 or later. This method of partitioning would. 01/01/2007 AND values < 01/01 /2008 This partition includes all rows for 2007. . values >= 01/01 /2008 AND values < 01/01/2009—This partition includes all rows for 2008. . values >= 01/01/2009—This