* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download SEAS VLDB - Microsoft
Survey
Document related concepts
Entity–attribute–value model wikipedia , lookup
Oracle Database wikipedia , lookup
Microsoft Access wikipedia , lookup
Concurrency control wikipedia , lookup
Tandem Computers wikipedia , lookup
Functional Database Model wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Team Foundation Server wikipedia , lookup
Relational model wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Clusterpoint wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Transcript
SEAS – 2006 SQL Server 2005 VLDB Management & Operation Agenda The challenge of Very Large Databases Take the VLDB challenge and break into smaller manageable designs SQL Server 2005 VLDB technologies Table partitioning Online operations Improved performance Improved concurrency Piecemeal management Capacity Planning Storage Disks Tempdb Transaction Logs Memory CPU VLDB Lessons Learned SEAS06 - VLDB Management & Operation 2 Very Large Databases Trends Drive capacity doubles every 12-18 months 10 TB Drive cost drops Data retention driven by • Regulatory requirements • Business analysis 5 TB 2 TB 1 TB Database size doubles every year for the same cost SEAS06 - VLDB Management & Operation 3 WinterCorp Study - SQL Server/Windows Growth projections 2001 2003 2005 2007 2009 2011 Minimum entry criteria for Windows 100 GB 500 GB 1 TB 2TB 4TB 8TB Total number of total entries for all databases 168 141 175 ??? ??? ??? Number of entries, Windows only 20 36 60 95 150 250 Number of entries, SQL Server 10 24 43 80 140 240 Number of entries, SQL Server, > 1 TB 0 15 43 80 140 240 800 GB 5TB 20TB 100TB + 500TB + 2000TB + Largest SQL Server Instance Projections SEAS06 - VLDB Management & Operation 4 Challenge of Very Large Databases Large scale operations including… Index creation and maintenance Bulk insertion of new data Bulk deletion of old data Concurrent reporting and updates Backup and restore Disaster recovery Detecting and recovering from media errors Tuning and Performance …while maintaining availability as dictated by business requirements. SEAS06 - VLDB Management & Operation 5 Agenda The challenge of Very Large Databases Take the VLDB challenge and break into smaller manageable designs SQL Server 2005 VLDB technologies Table partitioning Online operations Improved performance Improved concurrency Piecemeal management Capacity Planning Storage Disks Tempdb Transaction Logs Memory CPU VLDB Lessons Learned SEAS06 - VLDB Management & Operation 6 Design Philosophy VLDB Don’t think of it as Large complex database, think of it as smaller manageable components Partitioning data into smaller manageable sizes is your best friend Data Partitioning vs Function Partitioning Methods for data partitioning Database Partitioning Instance Partitioning SQL Server Partitioning SEAS06 - VLDB Management & Operation 7 Data separation: Data Partitioning vs Function Partitioning Examples of data partitioning by data Data broken up by States in the US: Alabama, Arkansas, Alaska….. Data broken up by months in a year: Jan, Feb, Mar…… Examples of data partitioning by function Data separated by business users: sales data, consulting data, competitive data…. Data separated by business function: manufacturing data, design data, inventory data……. SEAS06 - VLDB Management & Operation 8 Example #1: VLDB Case Study Function Partitioning Manage 13TBs of data Manage large files from several external customers / day Load millions of rows from multiple files and run batch reporting at the same time How do I manage different SLAs from different customers with same system. SEAS06 - VLDB Management & Operation 9 Example #1: VLDB case study – Function Partitioning Daily Customer Source files Account Function Tracking DB Individual Account Databases Function X Tables Common Database Function Y Tables Common Function Procedures - Data SEAS06 - VLDB Management & Operation Function Z Tables 10 Function Partitioning is scale out Partitioning is a VERY good idea Partitioning by business function is very logical Application must developed to partitioned data versus using database technology to access partitioned data. NOT DIFFICULT Putting all the data in one single database doesn’t make you a hero. No matter how you look at it 13TB of data is 13TB of data used to solve a business problem. SEAS06 - VLDB Management & Operation 11 Example #2: VLDB Case Study data partitioning Loads into SQL Server 350 million call detail records / day. Bulk loaded Must keep a history Reporting done all day long based off daily, weekly, monthly quarterly and yearly intervals Very partitionable by period of time 5-7 TB database This was based off a prototype, project being developed. SEAS06 - VLDB Management & Operation 12 Example #2: VLDB case study data partitioining 3 types of databases Type 1 contains 24 - 1 hour tables Type 2 contains 7 - 1 day tables Type 3 contains 7 – 1 week tables Online consolidation was much more difficult, so all 3 are built in parallel. This is good design if Hardware has head room Data is loaded without indexes and then indexed Data made available to users once indexed Yesterday, Last Week and Last 7 weeks are available while Today and This week are being loaded. SEAS06 - VLDB Management & Operation 13 Example #2: VLDB Design if using Single server SQL Server View PView Last week Week n-7 Last week This week This week Yesterday Today SEAS06 - VLDB Management & Operation Yesterday Today 14 Example #2: VLDB Design if changed from 1 Server to 4 Servers Last week Week n-7 Last week This week This week Yesterday Today SEAS06 - VLDB Management & Operation Yesterday Today 15 Example: #2: Design is use 7 server partitioning Last week Last week This week This week Yesterday Yesterday Today Today SEAS06 - VLDB Management & Operation Yesterday Today 16 Scalable Shared Database Read-only copy of a Data Warehouse database on a SAN can be shared by up to eight SQL query servers Network Load Balancing is possible Inexpensive scale-out solution as alternative to scaled-up server Easily support a large or growing group of query users SANs can create a shared read-only copy of the database instantly using SAN Snapshot technology Copy on write technology Refresh the snapshot after new data is loaded SEAS06 - VLDB Management & Operation 17 Example #3: VLDB Scale out partitioning SEAS06 - VLDB Management & Operation 18 Agenda The challenge of Very Large Databases Take the VLDB challenge and break into smaller manageable designs SQL Server 2005 VLDB technologies Table partitioning Online operations Improved performance Improved concurrency Piecemeal management Capacity Planning Storage Disks Tempdb Transaction Logs Memory CPU VLDB Lessons Learned SEAS06 - VLDB Management & Operation 19 VLDB SQL Server Technologies: Table Partitioning Designed for: Easy management of very large tables and indexes Maintain high availability Make effective use of large machines (16, 32, and more CPUs) for any type of workload Provide performance options for maintenance SEAS06 - VLDB Management & Operation 20 Table Partitioning: Common Scenario “Sliding Window” New data is added continually to a very large database (Daily, Weekly, Monthly) Data must be scrubbed, indexed, etc. As data ages, it is modified less frequently Eventually, it may be discarded Sliding Window Time Obsolete Read-Only Read-Mostly SEAS06 - VLDB Management & Operation Hot 21 Locating A Row Key (partitioning column) Partition Scheme Partition Function FileGroup 1 FileGroup 2 SEAS06 - VLDB Management & Operation FileGroup 1 22 Aligned Index One-to-one partition correspondence Index Partition Table Partition SEAS06 - VLDB Management & Operation 23 VLDB SQL Server Technologies: Online Operations Index creation Index maintenance Online restore Availability during rollback recovery SEAS06 - VLDB Management & Operation 24 Online Index Operations SQL Server 2005 Introduced as WITH (ONLINE=ON) CREATE INDEX DROP INDEX ALTER INDEX REBUILD (was DBCC DBREINDEX) ALTER INDEX add or drop constraint (primary key, unique) ONLINE is supported on partitioned tables but it is not supported for ALTER INDEX REBUILD on single partition SEAS06 - VLDB Management & Operation 25 VLDB SQL Server Technologies: Online Restore Microsoft® SQL Server™ 2000 Database is not available during restore SQL Server 2005 Database remains online Only data being restored is unavailable Works on Enterprise Edition “by default”, on nonenterprise the whole database is always offline Options File / filegroup restore Damaged page tracking and restore SEAS06 - VLDB Management & Operation 26 VLDB SQL Server Technologies: Improved Performance Bulk insertion and deletion of data File initialization Most improvement through partitioning (ALTER TABLE SWITCH mentioned before) Skip zeroing out the file(s) Permission grantable only by Windows® administrator SE_MANAGE_VOLUME_NAME special privilege Tuning ITW renamed to DTA (Database Tuning Advisor) Time-bound tuning SEAS06 - VLDB Management & Operation 27 VLDB SQL Server Technologies: Improved Concurrency Transaction isolation levels Database Snapshot SEAS06 - VLDB Management & Operation 28 Data Access Concurrency Transaction isolation levels Serializable Repeatable Read Read Committed Read Committed Snapshot Read Uncommitted Snapshot SEAS06 - VLDB Management & Operation 29 VLDB SQL Server Technologies: Snapshot Isolation Increased data availability for read applications Permits writes, which can cause conflicts Allows non-blocking consistent reads in an OLTP environment Writers do not block readers Readers do not block writers BUT… includes mandatory conflict detection, therefore… Consider Snapshot Isolation when the cost of locking data outweighs the cost of occasionally rolling back a transaction Whitepaper “SQL Server 2005 Beta 2 Snapshot Isolation” on http://www.microsoft.com/technet/prodtechnol/sql/2005/SQL05B.mspx SEAS06 - VLDB Management & Operation 30 VLDB SQL Server Technologies: Database Snapshot Snapshot of a database at a point in time Base database continues to change Created instantly Read only Transactionally consistent, time-consistent Database Snapshot does not restrict access to the base database Multiple Snapshots are allowed Database Snapshots can exist forever Constrained by resources SEAS06 - VLDB Management & Operation 31 Database Snapshot Database snapshots do consume resources on the server. Example: Buffer Pool Tested – TPC-C run lost less than 15% perf with single Database snapshot taken CREATE DATABASE dbSnap AS SNAPSHOT OF mydb USE mydb mydb – Database UPDATE (pages 4, 9, 10) Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 dbSnap – Read-Only Database Snapshot USE mydbSnap SELECT (pages 4, 6, 9, 10, 14) SEAS06 - VLDB Management & Operation 32 VLDB SQL Server technologies: Backup & Restore Common Challenge vs. Time SQL Server Solutions Backup large data volume Restore/recover large data volume SQL Server backup/restore improvements Online piecemeal restore Database Snapshots 3rd party solutions SAN based solutions Software based solutions SEAS06 - VLDB Management & Operation 33 Filegroups Basic unit of availability Earlier Versions of SQL Server Entire database SQL Server 2005 Database can be online, yet not all filegroups are available SEAS06 - VLDB Management & Operation 34 Example Server startup Database Primary Filegroup Filegroup A Database is available Filegroup A is unavailable due to missing file Filegroup is now available Filegroup B DBA locates file and recovers the filegroup SEAS06 - VLDB Management & Operation 35 Piecemeal Backup-Restore Partial database availability during restore Based on file / filegroup backup Works with all recovery models Full, Simple, Bulk-Logged Supported only for databases with multiple filegroups Filegroups must be recovered to consistent point SEAS06 - VLDB Management & Operation 36 Example Piecemeal restore for disaster recovery Online restore of filegroups in priority order Backups Database Available Primary Filegroup Primary Filegroup A Log Filegroup A Filegroup B Filegroup B SEAS06 - VLDB Management & Operation 37 Online Piecemeal Restore Principle Benefit Filegroups can be restored in stages Single object restoration (through filegroup) into temporary database Logical correction possible to corect error Granular and quick restoration of table and partition at filegroup level Steps Backup tail of active transaction log Using piecemeal restore to create temporary work database Restore primary db/log to temporary work db with “norecovery”, “partial” Restore filegroup Restore from backup of current log Logically recovers data See SQLCAT blog by Tom Davidson – http://blogs.msdn.com/sqlcat/archive/2005/10/27/485580.aspx SEAS06 - VLDB Management & Operation 38 Short Restore Sequence For Read-Only Data Log backups need not be restored when: File / filegroup is unchanged since backup File has been rolled forward to where it is read-only Useful for read-only tables or partitions Set filegroup to read-only Recommended for FULL and BULK-LOGGED databases Prevents inadvertent change Prevents changes by background tasks Required for SIMPLE model databases Log backup for roll forward not available SEAS06 - VLDB Management & Operation 39 VLDB SQL Server technologies: Statistics Management Upgrade from SQL Server 2000 SS2K statistics are rendered invalid SS2K5 will automatically build statistics after upgrade upon query execution If you don’t run it manually initial performance may/will suffer SS2K5 statistics has changed Now use formula O(sqrt(tablecard)) For very large tables this most likely will be less than 1% Recommendation: For large tables use 10% sampling, but you must test and try different values. The right answer could be 5% or 50%. SEAS06 - VLDB Management & Operation 40 Agenda The challenge of Very Large Databases Take the VLDB challenge and break into smaller manageable designs SQL Server 2005 VLDB technologies Table partitioning Online operations Improved performance Improved concurrency Piecemeal management Capacity Planning Storage and object management Disks TempDB Index Management Transaction Logs Memory CPU VLDB Lessons Learned SEAS06 - VLDB Management & Operation 41 Storage Planning… Planning for SAN Most VLDB uses SAN storage Standard disk/controller number may not apply due to large cache and pre-fetch algorithm Recommendation Using SQLIO or IOMETER to test/benchmark the SAN prior to implementing SQL Server Define storage throughput requirement for the application – e.g. my data warehouse need to push through 500mb/sec SEAS06 - VLDB Management & Operation 42 Understanding your SAN IO Subsystem Server SAN CPU Client Mirrore d Cache SQL Server memory CPU CPU …… SAN Cache SQL Server Disks Controllers SEAS06 - VLDB Management & Operation 43 Example – insert stmt / commit to log Server SAN CPU Client Mirrore d Cache SQL Server memory CPU CPU …… SAN Cache Data Page Log Record Only SQL Server Disks Controllers SEAS06 - VLDB Management & Operation 44 Example: write completed note: Data not on disk Server SAN CPU Client Mirrore d Cache SQL Server memory CPU CPU …… SAN Cache Data page IO COMPLETE SQL Server Disks Controllers SEAS06 - VLDB Management & Operation 45 Next System Checkpoint – data page(s) get written to SAN – note: again not on disk Server SAN CPU Client Mirrore d Cache SQL Server memory CPU CPU …… SAN Cache Data Page SQL Server Disks Controllers SEAS06 - VLDB Management & Operation 46 Periodically the SAN will flush its data to disk (de-staging) Server SAN CPU Client Mirrore d Cache SQL Server memory CPU CPU …… SAN Cache SQL Server Disks Controllers SEAS06 - VLDB Management & Operation 47 Storage Planning SQL Server guidelines – IO throughput Capacity planning considerations: # of spindles to handle mb/sec read requirements of the application # of spindles to handle de-staging of the SAN cache Device Speed Comments Disk Speed 200-250 IO(s)/sec - 13-16mb/sec(64K) - 2mb/sec (8K) Note: HW vendors will tell you disk are 500+ IOs/sec and 125+mb/sec. These numbers are raw file speeds with very large block sizes of 256K or greater. SQL Server reads at 8K, 64K or larger and writes at 8K or 64K Controller 125-150 mb/sec Note: based on per channel / per controller basis SQL Server random read 4-5 ms Note: This is just the IO completion, not the complete transaction SQL Server write 1 ms Notes: Assuming write through cache on controller and SAN. This is cost of Windows write in perfmon – AVG DISK SEC / WRITE counter. Log only as data pages are lazy written Numbers do not include de-staging of SAN Cache SEAS06 - VLDB Management & Operation 48 Transaction Log Planning… Database scalability is limited by the maximum throughput of the transaction log (Disk I/O) Plan on 1 ms / log write (utilizing write through cache) – Avg Disk Sec/Write counter in perfmon (using SAN) Note: SQL Server will combine multiple write requests into a single log write (See diagram next page) but keep order Fastest configuration is multiple files and multiple disks striped to handle de-staging of cache and multiple log operations (Replication, Triggers, etc.) Ballpark – (Depends on many variables): plan on 40-60K database transactions / single log SEAS06 - VLDB Management & Operation 49 Database Log Thoughput SQL Server Update, insert, delete requests SS Memory Data pages . . . 2. Data page written to SS Memory 3. Write request issued to write out log to IO Subsystem Log Buffer 1. Insert happens 4. By the time Log write IO is issued Several other log writes piggyback SEAS06 - VLDB Management & Operation 50 TEMPDB Planning… SQL Server 2005 tempdb requires more space Some new features in SQL Server 2005 Some features that use tempdb in earlier versions of SQL Server may require more tempdb disk space in SQL Server 2005. Some features that do not use tempdb in earlier versions of SQL Server use tempdb in SQL Server 2005 Good MSDN article: Capacity Planning for tempdb: http://msdn2.microsoft.com/enus/library/ms345368.aspx SEAS06 - VLDB Management & Operation 51 TempDB capacity planning On line index: 2x-3x size of index – Sort size, temp index and rollback Versioning: [Size of Version Store] = 2 * [Version store data generated per minute] * [Longest running time (minutes) of your transaction] * number of concurrent transactions/users Note: Version store data generated per minute and version store size are now a perfmon parameters Recommendation repeated: Be sure to tune TempDB for proper sizing as well as performance SEAS06 - VLDB Management & Operation 52 TEMPDB capacity Planning… a more reliable method Determine tempdb space used select sum(user_object_reserved_page_count)*8 as user_objects_kb, sum(internal_object_reserved_page_count)*8 as internal_objects_kb, sum(version_store_reserved_page_count)*8 as version_store_kb, sum(unallocated_extent_page_count)*8 as freespace_kb from sys.dm_db_file_space_usage where database_id = 2 SEAS06 - VLDB Management & Operation 53 TEMPDB capacity planing..... What tasks are using tempdb? Determine tempdb space used by Task SELECT t1.session_id, (t1.internal_objects_alloc_page_count + task_alloc) as allocated, (t1.internal_objects_dealloc_page_count + task_dealloc) as deallocated from sys.dm_db_session_space_usage as t1, (select session_id, sum(internal_objects_alloc_page_count) as task_alloc, sum (internal_objects_dealloc_page_count) as task_dealloc from sys.dm_db_task_space_usage group by session_id) as t2 where t1.session_id = t2.session_id and t2.session_id >50 order by allocated DESC SEAS06 - VLDB Management & Operation 54 Index Operations Lessons Learned Online index build logs the entire contents of the target index pages. Hence log space requirements increase significantly. You can specify to use TempDB to avoid log sizing and contention. Recommendation: specify sort_in_tempdb option for online index build and tune temp_db to avoid excessive log activity Online index not available on a per-partition basis for partitioned tables. ALTER INDEX … REBUILD of a corrupted non-clustered index may use another index (and that may be theoretically corrupted as well). Recommendation: Therefore use DBCC repair rather than alter index…rebuild SEAS06 - VLDB Management & Operation 55 TempDB for Index Operation… TEMPDB space used / Size of the index Single column index 8% of row size (4 bytes out of 46 bytes) Mappin g Index Operation Sort runs Total 3 columns index 25% of row size (10 bytes out of 42 bytes) All columns index 100% of row size (42 bytes out of 42 bytes) Mappin g Index Mappin g Index Sort runs Total Sort runs Total Online clustered index create 0.33 1.1 1.43 0.52 1.12 1.64 1.21 1.11 2.32 Online clustered index rebuild 0.17 0 0.17 0.31 0 0.31 1.01 0 1.01 Online non-clustered Index create n/a n/a n/a n/a n/a n/a n/a n/a n/a Online non-clustered index rebuild 0 0 0 0 0 0 0 0 0 Offline clustered index create 0 1.02 1.02 0 1.02 1.02 0 1.01 1.01 Offline clustered index rebuild 0 0 0 0 0 0 0 0 0 Offline non-clustered index create/rebuild 0 1.07 1.07 0 1.05 1.05 0 1.02 1.02 * Above table illustrates the amount of TEMPDB space used with respect to the size of the index Online clustered index creation can take up to 2.5x size of heap! SEAS06 - VLDB Management & Operation 56 Index Management Defrag only necessary Online Index maintenance in VLDB Fragmentation has little performance impact on index-seek Offline operation still much faster than online On average, Insert/Delete operation slower during online index – up to 30% Non-clustered index with included columns to replace covering index Operation Duration SQL Server 2000 Offline index rebuild 3:34 SQL Server 2005 offline index rebuild 2:36 SQL Server 2005 online index rebuild 10:52 SQL Server 2005 online index rebuild with normal workload 11:30 SEAS06 - VLDB Management & Operation Notes 27% faster than SQL Server 2000 57 Unused Index Unused index cause unnecessary index maintenance overhead during insert operation Determine unused index select object_name(i.object_id), i.name from sys.indexes i, sys.objects o Where objectproperty(o.object_id,'IsUserTable') = 1 And i.index_id NOT IN (select s.index_id from sys.dm_db_index_usage_stats s where s.object_id=i.object_id and i.index_id=s.index_id and database_id = <dbid> ) and o.type = 'U' and o.object_id = i.object_id order by object_name(i.object_id) asc SEAS06 - VLDB Management & Operation 58 Memory Planning Avoid paging Use “Lock Pages in Memory” option Proper sizing SQL Server Max Memory = Total system memory – OS/Application – <Max worker thread> x <Thread stack size> Thread size: x86 – 512K; X64 – 2MB; IA64 – 4MB Monitor Buffer/Plan cache System with poor plan reuse may starve buffer Use dbcc freeproccache Use dbcc freesystemcache SEAS06 - VLDB Management & Operation 59 CPU Planning Degree of Parallelism Affinity Mask OLTP environment favors low MAXDOP OLAP/DW environment favors higher MAXDOP Dynamically changeable setting MAXDOP=0 for regular business hour, and change to x during index maintenance “affinity mask” controls CPU 0-31 “affinity64 mask” controls CPU 32-64 When set, SQL Server 2005 scheduler affinitize to CPU NUMA & application partitioning Associating multiple TCP/IP ports to a single node Associating a single TCP/IP port to multiple nodes SEAS06 - VLDB Management & Operation 60 Agenda The challenge of Very Large Databases Take the VLDB challenge and break into smaller manageable designs SQL Server 2005 VLDB technologies Table partitioning Online operations Improved performance Improved concurrency Piecemeal management Capacity Planning Storage Disks Tempdb Transaction Logs Memory CPU Summary SEAS06 - VLDB Management & Operation 61 Summary VLDB is just many smaller manageable problems to solve if you partition the big into smaller components SQL Server 2005 has many new features to help VLDB Partitioning, online utilities, DMV(s), high performance, etc. SEAS06 - VLDB Management & Operation 62 © 2006 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. SEAS06 - VLDB Management & Operation 63