Hướng dẫn học Microsoft SQL Server 2008 part 148 potx

Nielsen c68.tex V4 - 07/21/2009 4:18pm Page 1432 Part IX Performance Tuning and Optimization ALTER TABLE dbo.OrderDetailCH ADD CONSTRAINT FK_OrderDetailCH_Order FOREIGN KEY (LocationCode,OrderID) REFERENCES dbo.OrderCH(LocationCode,OrderID) ALTER TABLE dbo.OrderDetailCH ADD CONSTRAINT PK_OrderDetailCH PRIMARY KEY NONCLUSTERED (LocationCode, OrderDetailID) ALTER TABLE dbo.OrderDetailCH ADD CONSTRAINT OrderDetailCH_PartitionCheck CHECK (LocationCode = ‘CH’) go move the data INSERT dbo.OrderCH (LocationCode, OrderID, OrderNumber, ContactID, OrderPriorityID, EmployeeID, LocationID, OrderDate, Closed) SELECT ‘CH’, OrderID, OrderNumber, ContactID, OrderPriorityID, EmployeeID, [Order].LocationID, OrderDate, Closed FROM [Order] JOIN Location ON [Order].LocationID = Location.LocationID WHERE LocationCode = ‘CH’ INSERT dbo.OrderDetailCH ( LocationCode, OrderDetailID, OrderID, ProductID, NonStockProduct, Quantity, UnitPrice, ShipRequestDate, ShipDate, ShipComment) SELECT ‘CH’, OrderDetailID, OrderDetail.OrderID, ProductID, NonStockProduct, Quantity, UnitPrice, ShipRequestDate, ShipDate, ShipComment FROM OrderDetail JOIN OrderCH ON OrderDetail.OrderID = OrderCH.OrderID Creating the partition view With the data split into valid partition tables that include the correct primary keys and constraints, SQL Server can access the correct partition table through a partition view. The OrderAll view uses a UNION ALL to vertically merge data from all three partition tables: CREATE VIEW OrderAll AS 1432 www.getcoolebook.com Nielsen c68.tex V4 - 07/21/2009 4:18pm Page 1433 Partitioning 68 SELECT LocationCode, OrderID, OrderNumber, ContactID, OrderPriorityID, EmployeeID, LocationID, OrderDate, Closed FROM OrderCH UNION ALL SELECT LocationCode, OrderID, OrderNumber, ContactID, OrderPriorityID, EmployeeID, LocationID, OrderDate, Closed FROM OrderJR UNION ALL SELECT LocationCode, OrderID, OrderNumber, ContactID, OrderPriorityID, EmployeeID, LocationID, OrderDate, Closed FROM OrderKDH Selecting through the partition view When all the data is selected from the OrderAll partition view, the query plan, shown in Figure 68-1, includes all three partition tables as expected: SELECT LocationCode, OrderNumber FROM OrderAll Result (abridged): LocationCode OrderNumber CH 1 JR 4 JR 7 KDH 9 KDH 10 What makes partition views useful for advanced scalability is that the SQL Server query processor will use the partition tables’ check constraints to access only the required tables if the partition key is included in the WHERE clause of the query calling the partition view. The following query selects on the Kill Devil Hills orders from the partition view. The LocationCode column is the partition key, so this query will be optimized for scalability. Even though the view’s union includes all three partition tables, the query execution plan, shown in Figure 68-2, reveals that the query processor accesses only the OrderCH partition table: SELECT OrderNumber FROM OrderAll WHERE LocationCode = ‘KDH’ 1433 www.getcoolebook.com Nielsen c68.tex V4 - 07/21/2009 4:18pm Page 1434 Part IX Performance Tuning and Optimization Result: OrderNumber 9 10 FIGURE 68-1 The partition table’s query plan, when run without a where clause restriction, includes all the partition tables as a standard union query. Updating through the partition view Union queries are typically not updateable. Yet, the partition tables’ check constraints enable a partition view based on a union query to be updated, as long as a few conditions a re met: ■ The partition view must include all the columns from the partition tables. ■ The primary key must include the partition key. 1434 www.getcoolebook.com Nielsen c68.tex V4 - 07/21/2009 4:18pm Page 1435 Partitioning 68 ■ Partition table columns, including the primary key, must be identical. ■ Columns and tables must not be duplicated within the partition view. FIGURE 68-2 When a query with a where clause restriction that includes the partition key retrieves data through the partition view, SQL Server’s query processor accesses only the required tables. The following UPDATE query demonstrates updating through the OrderAll view: UPDATE OrderAll SET Closed = 0 WHERE LocationCode = ‘KDH’ 1435 www.getcoolebook.com Nielsen c68.tex V4 - 07/21/2009 4:18pm Page 1436 Part IX Performance Tuning and Optimization Unfortunately, an UPDATE does not benefit from query optimization to the extent that a SELECT does. For heavy transactional processing at the stored-procedure level, the code should access the correct partition table. Moving data An issue with local-partition views is that data is not easily moved from one partition table to another partition table. An UPDATE query that attempts to update the partition key violates the check constraint: UPDATE OrderAll SET Locationcode = ‘JR’ WHERE OrderNumber = 9 Result: Server: Msg 547, Level 16, State 1, Line 1 UPDATE statement conflicted with TABLE REFERENCE constraint ‘FK_OrderDetailKDH_Order’. The conflict occurred in database ‘OBXKites’, table ‘OrderDetailKDH’. The statement has been terminated. For implementations that partition by region or department, moving data may not be an issue, but for partition schemes that divide the data into current and archive partitions, it is. The only possible workaround is to write a stored procedure that inserts the rows to be moved into the new partition and then deletes them from the old partition. To complicate matters further, a query that inserts into the partition view cannot reference a partition table in the query, so an INSERT SELECT query won’t work. A temporary table is required to facilitate the move: CREATE PROCEDURE OrderMovePartition ( @OrderNumber INT, @NewLocationCode CHAR(5) ) AS SET NoCount ON DECLARE @OldLocationCode CHAR(5) SELECT @OldLocationCode = LocationCode FROM OrderAll WHERE OrderNumber = @OrderNumber Insert New Order SELECT DISTINCT OrderID, OrderNumber, ContactID, OrderPriorityID, EmployeeID, LocationID, OrderDate, Closed INTO #OrderTemp FROM OrderAll WHERE OrderNumber = @OrderNumber AND LocationCode = @OldLocationCode INSERT dbo.OrderAll (LocationCode, OrderID, OrderNumber, ContactID, OrderPriorityID, 1436 www.getcoolebook.com Nielsen c68.tex V4 - 07/21/2009 4:18pm Page 1437 Partitioning 68 EmployeeID, LocationID, OrderDate, Closed) SELECT @NewLocationCode, OrderID, OrderNumber, ContactID, OrderPriorityID, EmployeeID, LocationID, OrderDate, Closed FROM #OrderTemp Insert the New OrderDetail SELECT DISTINCT OrderDetailID, OrderDetailAll.OrderID, ProductID, NonStockProduct, Quantity, UnitPrice, ShipRequestDate, ShipDate, ShipComment INTO #TempOrderDetail FROM OrderDetailALL JOIN OrderALL ON OrderDetailALL.OrderID = OrderALL.OrderID WHERE OrderNumber = @OrderNumber Select * from #TempOrderDetail INSERT dbo.OrderDetailAll ( LocationCode, OrderDetailID, OrderID, ProductID, NonStockProduct, Quantity, UnitPrice, ShipRequestDate, ShipDate, ShipComment) SELECT @NewLocationCode, OrderDetailID, OrderID, ProductID, NonStockProduct, Quantity, UnitPrice, ShipRequestDate, ShipDate, ShipComment FROM #TempOrderDetail Delete the Old OrderDetail DELETE FROM OrderDetailAll FROM OrderDetailAll JOIN OrderALL ON OrderAll.OrderID = OrderDetailAll.OrderID WHERE OrderNumber = @OrderNumber AND OrderDetailAll.LocationCode = @OldLocationCode Delete the Old Order DELETE FROM OrderALL WHERE OrderNumber = @OrderNumber AND LocationCode = @OldLocationCode To test the stored procedure, the following batch moves order number 9 from the Kill Devils Hill store to the Jockey’s Ridge location: EXEC OrderMovePartition 9, ‘JR’ To see the move, the following query reports the LocationCode from both the OrderAll and the OrderDetailAll tables: 1437 www.getcoolebook.com Nielsen c68.tex V4 - 07/21/2009 4:18pm Page 1438 Part IX Performance Tuning and Optimization Select OrderAll.OrderNumber, OrderALL.LocationCode as OrderL, OrderDetailALL.LocationCode AS DetailL FROM OrderDetailAll JOIN OrderAll ON OrderAll.OrderID = OrderDetailAll.OrderID WHERE OrderNumber = 9 Result: OrderNumber OrderL DetailL 9JRJR 9JRJR 9JRJR Distributed-partition views Because partition views often segment data along natural geographic lines, it logically follows that a partition view that spans multiple servers is very useful. Distributed-partition views build upon local-partition views to unite data from segmented tables located on different servers. This technique is also referred to as a federated-database configuration because multiple individual components cooperate to complete the whole. This is how Microsoft gains those incredible performance benchmarks. The basic concept is the same as that of a local-partition view, with a few differences: ■ The participating servers must be configured as linked servers with each other. ■ The distributed-partition view on each server is a little different from those of the other servers, because it must use distributed queries to access the other servers. ■ Each server must be configured for lazy schema validation to prevent repeated requests for metadata information about the databases. Turning on lazy schema validation means that SQL Server will not check remote tables for the proper schema until it has executed a script. This means that if a remote table has changed, then scripts that depend on that table will error out. Turning this feature on can result in certain bad effects on scripts but does help increase performance. The following script configures a quick distributed-partition view between Maui and Maui\ Copenhagen (my two development instances). To save space, I list o nly the Maui half of the script. Similar code is also run on the second server to establish the distributed view. The script creates a database with a single table and inserts a single row. Once a link is established, and lazy schema validation is enabled, the distributed-partition view is created. This partition view is created with a four-part name to access the remote server. Selecting through the distributed-partition view retrieves data from both servers: CREATE DATABASE DistView go USE DistView 1438 www.getcoolebook.com Nielsen c68.tex V4 - 07/21/2009 4:18pm Page 1439 Partitioning 68 CREATE TABLE dbo.Inventory( LocationCode CHAR(10) NOT NULL, ItemCode INT NOT NULL, Quantity INT ) ALTER TABLE dbo.Inventory ADD CONSTRAINT PK_Inventory PRIMARY KEY NONCLUSTERED(LocationCode, ItemCode) ALTER TABLE dbo.Inventory ADD CONSTRAINT Inventory_PartitionCheck CHECK (LocationCode = ‘MAUI’) INSERT dbo.Inventory (LocationCode, ItemCode, Quantity) VALUES (’MAUI’, 12, 1) Link to the Second Server EXEC sp_addlinkedserver @server = ‘MAUI\COPENHAGEN’, @srvproduct = ‘SQL Server’ EXEC sp_addlinkedsrvlogin @rmtsrvname = ‘MAUI\COPENHAGEN’ Lazy Schema Validation EXEC sp_serveroption ‘MAUI\COPENHAGEN’, ‘lazy schema validation’, true Create the Distributed Partition View CREATE VIEW InventoryAll AS SELECT * FROM dbo.Inventory UNION ALL SELECT * FROM [MAUI\COPENHAGEN].DistView.dbo.Inventory SELECT * FROM InventoryAll Result: LocationCode ItemCode Quantity MAUI 12 1 MAUI\COPENHAGEN 14 2 Updating and moving data with distributed-partition views One fact that makes distributed-partition views an improvement over local-partition views is that a distributed-partition view can move data without complication. MS Distributed Transaction Coordinator must be running and xact_abort enabled because the transaction is a distributed transaction. The following update query changes the LocationCode of the first server’s row to Maui\Copenhagen, and effectively moves the row from Maui to Maui\Copenhagen: 1439 www.getcoolebook.com Nielsen c68.tex V4 - 07/21/2009 4:18pm Page 1440 Part IX Performance Tuning and Optimization SET XACT_ABORT ON UPDATE InventoryAll SET LocationCode = ‘MAUI\COPENHAGEN’ WHERE Item = 12 To show you the effect of the update query, the next query selects from the distributed-partition view and demonstrates that item 14 is now located on Maui: SELECT * FROM InventoryAll Result: LocationCode ItemCode Quantity MAUI 12 1 MAUI 14 2 Highly scalable distributed-partition views SQL Server’s query processor handles distributed-partition views much like it handles local-partition views. Where the local-partition view accesses only the required tables, a distributed-partition view performs distributed queries and r equests the required data from the remote servers. Each server executes a portion of the query. In the following example, the query is being executed on Maui. A remote query request is sent to Maui\Copenhagen, and the results are passed back to Maui. The query processor knows not to bother looking at the table on Maui. Even better, the query passes the row restriction to the remote server as well. Maui\Copenhagen has two rows, but only one is returned: SELECT * FROM InventoryAll WHERE LocationCode = ‘MAUI\COPENHAGEN’ AND Item = 14 Result: LocationCode ItemCode Quantity MAUI\COPENHAGEN 14 2 Partitioned Tables and Indexes Partitioned tables are similar to partitioned views — both involve segmenting the data. However, whereas partitioned views store the data in separate tables and use a view to access the tables, partitioned tables store the data in a segmented clustered index and use the table to access the data. Partitioning tables reduces the sheer size of the clustered and non-clustered b-tree indexes, which provides these scalability benefits: 1440 www.getcoolebook.com Nielsen c68.tex V4 - 07/21/2009 4:18pm Page 1441 Partitioning 68 ■ Inserts and update operations must also insert and update index pages. When a table i s partitioned, only the affected partition’s indexes are updated. ■ Index maintenance can be a costly operation. A partition’s index is significantly smaller and reduces the performance cost of reindexing or defragmenting the index. However, the partitions can’t be indexed off-line, which is still a major drawback. ■ Backing up part of a table using Backup Filegroups eases backups. ■ The index b-tree is slightly smaller — perhaps an intermediate level or two smaller — but the performance gain is probably not going to be noticeable. ■ A partitioned table can segment the data by one WHERE clause filter and perhaps improve the selectiveness of another filtering predicate so that the index is used when perhaps it wasn’t without partitioning. ■ With partitioned data, a scan might only need to retrieve a partition, rather than the entire table, which can result in a huge performance difference and avoid memory bloat. Best Practice The performance benefit of partitioned tables doesn’t kick in until the table is extremely large — billion-row tables in terabyte-size databases. In fact, in some testing, partitioned tables actually hurt performance on smaller tables with less than a million rows, so reserve this technology for the big problems. Maybe that’s why table partitioning isn’t included in Standard Edition. On the other hand, even for tables with fewer than one million rows, partitioning can be an effective part of archiving old data into one partition while keeping current data in another partition. Creating SQL Server 2008 table partitions is a straightforward four-step process: 1. Create the partition function that will determine how the data is partitioned. 2. Create the partition scheme that assigns partitions to filegroups. 3. Create the table with a non-clustered primary key. 4. Create a clustered index for the table using the partition scheme and partition function. Partition functions and partition schemes work together to segment the data as illustrated in Figure 68-3. Creating the partition function A partition function is simply a means to define the range of values that each partition will contain. A table partition can segment the data based on a single column. Even though the table isn’t yet defined, the function must know the segmenting column’s data type, so the partition function’s parameter is the data type that will be used to segment the data. In the following example, the function fnYears takes a datetime value. The function defines the boundary values for the ranges of each partition. An important aspect of boundary values is that you 1441 www.getcoolebook.com . another partition. Creating SQL Server 2008 table partitions is a straightforward four-step process: 1. Create the partition function that will determine how the data is partitioned. 2. Create the partition. distributed-partition view is created. This partition view is created with a four -part name to access the remote server. Selecting through the distributed-partition view retrieves data from both servers: CREATE. views SQL Server s query processor handles distributed-partition views much like it handles local-partition views. Where the local-partition view accesses only the required tables, a distributed-partition