Dell Compellent Storage Center DB2 UDB. Best Practices

Transcription

1 Dell Compellent Storage Center DB2 UDB Best Practices

2 Page 2

3 Document revision Date Revision Description 4/15/2010 A Preliminary THIS BEST PRACTICES GUIDE IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND Dell Inc. All rights reserved. Reproduction of this material in any manner whatsoever without the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell. Dell, the DELL logo, the DELL badge, and Compellent are trademarks of Dell Inc. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell Inc. disclaims any proprietary interest in trademarks and trade names other than its own. Page 3

4 Contents Document revision... 3 Contents... 4 General syntax... 6 Conventions... 6 Preface... 7 Introduction... 7 Audience... 7 Customer support... 7 Overview of CML Storage Center... 8 Dell Compellent Storage Virtualization... 8 Data Instant Replay... 8 Data Progression... 8 Thin Provisioning... 8 Fast Track... 8 Consistency Groups... 8 Overview of DB2 UDB concepts... 9 DB2 instances... 9 Databases Buffer pools Table spaces Catalog table space Regular table spaces Long table spaces System temporary table spaces User temporary table spaces Table space management Containers Table space settings Page size Extent size Prefetch size Overhead and transfer rate Performance tuning guidelines Tuning DB2 UDB configuration parameters Page 4

5 Buffer pools Asynchronous I/O servers and I/O cleaners No file system caching Dell Compellent Volumes (LUNs) Layout DB2 best practices Conclusion Tables Table 1. Document syntax... 6 Table 2. Implications of page size Table 3. Supported configuration for table spaces without file system caching Page 5

6 General syntax Table 1. Document syntax Item Menu items, dialog box titles, field names, keys Mouse click required User Input User typing required Website addresses addresses Convention Bold Click: Monospace Font Type: Conventions Notes are used to convey special information or instructions. Timesavers are tips specifically designed to save time or reduce the number of steps. Caution indicates the potential for risk including system or data damage. Warning indicates that failure to follow directions could result in bodily harm. Page 6

7 Preface Introduction This white paper describes the best practices for running IBM DB2 UDB on a Dell Compellent Storage Center SAN. It discusses performance related DB2 parameters to help you fine tune your databases. Audience The primary target audience for this white paper is DB2 database administrators, system administrators, storage administrators, and architects who analyze, design, and maintain robust database and storage systems. Readers should be familiar with IBM DB2 Universal Database and Dell Compellent Storage Center and its features. Customer support Dell Compellent provides live support EZSTORE ( ), 24 hours a day, 7 days a week, 365 days a year. For additional support, Dell Compellent at support@compellent.com. Dell Compellent responds to s during normal business hours. Page 7

8 Overview of CML Storage Center Dell Compellent Storage Virtualization Dell Compellent virtualizes enterprise storage at the disk level, creating a dynamic pool of storage resources shared by all servers. Because read/write operations are spread across all available drives, multiple requests are processed in parallel, boosting system performance. With Dell Compellent storage virtualization, users can create hundreds of volumes in seconds to support any server platform and optimize the placement of applications. Data Instant Replay Dell Compellent storage delivers continuous data protection using space-efficient snapshots called Replays. With Data Instant Replay, once an initial snapshot of a volume is taken, only incremental changes in data need to be captured. This not only saves disk space, but speeds local recovery of lost or deleted files. An unlimited number of Replays can be scheduled for near-instant recovery to virtually any point in time. Data Progression Only Dell Compellent dynamically migrates data at the block level to the optimal storage tier based on frequency of access. The most active blocks of data reside on high-performance SSD or Fibre Channel drives, while less active blocks of data automatically move to lower-cost, high-capacity SAS or SATA drives. The result is storage that is always in tune with application needs and overall storage cost slashed by up to 80%. Thin Provisioning Dell Compellent Thin Provisioning, called Dynamic Capacity, delivers the highest storage utilization possible by eliminating allocated but unused capacity. Dynamic Capacity completely separates storage allocation from utilization, enabling users to allocate any size virtual volume upfront, yet only consume physical disk space when data is written. Thin Write technology assesses the incoming payload against the current state of the storage pool, then allocates space accordingly. Fast Track Dell Compellent Fast Track technology enhances Automated Tiered Storage by dynamically placing the most frequently accessed data on the fastest, or outer, tracks of each disk drive. Meanwhile, the least active blocks of data remain on the inner tracks of all the drives in each storage tier. The result is ready access to frequently used data with fewer drives than conventional storage systems. Consistency Groups Dell Compellent Consistency Group allows storage administrators to take a snapshot of a database automatically. When creating a snapshot of a running database using Dell Compellent Data Instant Replay feature, you must ensure that all storage volumes (LUNs) that make up your database be automatically snapped. Page 8

9 Overview of DB2 UDB concepts Before you can tune the database level of a DB2 UDB system to achieve optimum performance, you must understand how DB2 UDB is structured and you must know how DB2 UDB stores and manages data. DB2 instances An instance in DB2 for LUW is like a copy of RDBMS including all the processes that run DB2 and memory associated with that instance and some configuration parameters to control that instance. Anytime a new instance is created, that instance references the DB2 Database Manager program files that were stored on that server during the installation process; thus, each instance behaves like a separate installation of DB2 UDB. Every instance controls access to one or more databases. Every database within an instance is assigned a unique name, has its own set of system catalog tables, and has its own configuration file. Below is an example of an instance named db2inst1. Page 9

10 Databases A DB2 UDB database is a set of related objects. When you create a DB2 UDB database, you are establishing an administrative relational database entity that provides an underlying structure for an eventual collection of related objects such as tables, views, indexes, table spaces, etc. Below is an example of a database named TESTDB. Buffer pools A buffer pool is associated with a single database and can be used by more than one table space. When considering a buffer pool for one or more table spaces, you must ensure that the table space page size and the buffer pool page size are the same for all table spaces that the buffer pool services. A table space can only use one buffer pool. When the database is created, a default buffer pool named IBMDEFAULTBP is created which is shared by all table spaces. More buffer pools can be added by using the CREATE BUFFERPOOL statement. The buffer pool size defaults to the size specified by the BUFFPAGE database configuration parameter but can be overridden by specifying the SIZE keyword in the CREATE BUFFERPOOL command. Adequate buffer pool size is essential to good database performance since it will reduce disk I/O. Large buffer pools will also have an effect on query optimization, since more of the work can be done in memory. Page 10

11 Below is an example of the default buffer pool. Table spaces All data for a database is stored in a number of table spaces. You can think of a table space as being a child and a database as its parent, where the table space (child) cannot have more than one database (parent). Because there are different uses for table spaces, they are classified according to their usage and how they will be managed. There are five different table spaces by usage: Catalog table space There is only one catalog table space per database, and it is created when the CREATE DATABASE command is issued. Named SYSCATSPACE by DB2, the catalog table space holds the system catalog tables. This table space is always created when the database is created. Regular table spaces Regular table spaces hold table data and indexes. It can also hold long data such as Large Objects (LOBs) unless they are explicitly stored in long table spaces. A table and its indexes can be segregated into separate regular table spaces, if the table spaces are database managed space (DMS). We will define the differences between DMS and system managed space (SMS) later in this white paper. At least one regular table space must exist for each database. The default is named USERSPACE1 when the database is created. Long table spaces Long table spaces are used to store long or LOB table columns and must reside in DMS table spaces. They can also store structured type columns or index data. If no long table space is defined, then LOBs will be stored in regular table spaces. Long table spaces are optional and none will be created by default. Page 11

12 System temporary table spaces System temporary table spaces are used to store internal temporary data required during SQL operations such as sorting, reorganizing tables, creating indexes, and joining tables. At least one must exist per database. The default created with the database is named TEMPSPACE1. User temporary table spaces User temporary table spaces store declared global temporary tables. No user temporary table spaces exist when a database is created. At least one user temporary table space should be created to allow definition of declared temporary tables. User temporary table spaces are optional and none will be created by default. Table space management System Managed Space (SMS) SMS table spaces are managed by the operating system. Containers are defined as regular operating system files and they are accessed via operating system calls. This means that all the regular operating system functions will handle the following: I/O will be buffered by the operating system, space will be allocated according to the operating system conventions, and the table space is automatically extended when it is necessary. However, containers cannot be dropped from SMS table spaces, and adding new ones is restricted to partitioned databases. The three default table spaces explained in the previous section are SMS. Database Managed Space (DMS) DMS table spaces are managed by DB2. Containers can be defined either as files (which will be fully allocated with the size given when the table space is created) or devices. DB2 will manage as much of the I/O as the allocation method and the operating system will allow. Extending the containers is possible by using the ALTER TABLESPACE command. Unused portions of DMS containers can be also released (starting with version 8). Below is an example of the table spaces. Page 12

13 Containers Every table space has one or more containers. Again, you might think of a container as being a child and a table space as its parent. Each container can only belong to a single table space but a table space can have many containers. Containers can be added to or dropped from a DMS table space, and their sizes can be modified. Containers can only be added to SMS table spaces on partitioned databases in a partition, which does not yet have a container allocated for the table space. When new containers are added, an automatic rebalancing will start to distribute the data across all containers. Rebalancing will not prevent concurrent access to the database. Below is an example of Containers. Table space settings There are a number of settings that can be specified for table spaces, either when they are created, or later with an ALTER TABLESPACE statement. Page size Data is transferred between table space containers and buffer pools in discrete blocks called pages. Sizes supported are 4K, 8K, 16K and 32K. The page size limits the row length and column count of tables that can be placed in the table space according to the following table: Table 2. Implications of page size Page Size Row Size Limit Column Count Limit Maximum capacity 4 KB GB 8 KB GB 16 KB GB 32 KB GB Page 13

14 Table spaces are limited to pages, so choosing a larger page size will increase the capacity of the table space. Extent size Extent size specifies the number of pages that will be written to a container before skipping to the next container. The database manager cycles repeatedly through the containers as data is stored. This parameter has effect only when there are multiple containers for the table space. Prefetch size Prefetch size specifies the number of pages that will be read from the table space when data prefetching is being performed. Prefetching reads in data needed by a query prior to its being referenced by the query so that the query need not wait for I/O to be performed. Prefetching is selected by the database manager when it determines that sequential I/O is appropriate and that prefetching may help to improve performance. Overhead and transfer rate These values are used to determine the cost of I/O during query optimization. Both values are measured in milliseconds and they should be the average for all containers. The overhead is the time associated with I/O controller activity, disk seek time and rotational latency. The transfer rate is the amount of time necessary to read one page into memory. The default values are 24.1 and 0.9, respectively. These values can be calculated based on hardware specifications. Below is an example of Table Space Setting. Page 14

15 Performance tuning guidelines Tuning DB2 UDB configuration parameters DB2 UDB "out of the box" parameter values are based on a system that uses 256 MB of RAM and a single disk. If you have a larger system, you need to modify these parameters to best take advantage of your system resources. You can determine a good starting point for tuning your configuration by using the Configuration Advisor, which recommends database parameter values based on your system resources. To run the configuration advisor, use the autoconfigure command, or invoke it through the Control Center, by right clicking on the desired database to configure, and choosing Configuration Advisor. Buffer pools As explained in previous section about buffer pools, they act as the "in memory" work area for the database to perform most data manipulation (except large objects and long field data) during all transactional activities such as reads, writes, updates, and deletes. Each database requires at least one buffer pool. For a database that has table spaces of more than one page size, additional buffer pools with matching page sizes need to be created. Buffer pool contention can be a significant factor in database performance. If the buffer pool is large enough to keep the required data in memory, less disk activity will occur. Conversely, if the buffer pool is not large enough, the overall performance of the database can be severely curtailed, and the database manager can become I/O bound as a result of the high amount of disk activity required by the applications. Asynchronous I/O servers and I/O cleaners DB2 UDB encourages the asynchronous I/O access of a page read and written between the buffer pool and the disk for optimal performance. I/O servers asynchronously read data pages from the disk into the buffer pool anticipating their need by an application: this is called "prefetching." Prefetching can improve the database performance because the pages will be found in the buffer pool when the agent accesses them, reducing the time the application waits for the page to be read from the disk into the buffer pool. Page cleaners, on the other hand, write changed pages from the buffer pool to disk before the space in the buffer pool is required by a database agent. As a result, database agents should not have to wait for changed pages to be written out so that they might use the space in the buffer pool. This improves overall database performance. Page cleaners can be triggered by several reasons, for example, when a changed pages threshold is reached. The number of I/O servers (prefetchers) for a database can be configured using the NUM_IOSERVERS database configuration parameter. In order to fully exploit all the I/O devices in the system, a good value to use is generally one or two more than the number of physical devices on which the database resides. It is better to configure additional I/O servers, since there is minimal overhead associated with each I/O server and any unused I/O servers will remain idle. Page 15

16 The NUM_IOCLEANERS database configuration parameter allows you to specify the number of asynchronous page cleaners for a database. Consider the following factors when setting the value for this parameter: Application type If it is a query-only database that will not have updates, set this parameter to be zero (0). The exception would be if the query work load results in many TEMP tables being created (you can determine this by using the explain utility). If transactions are run against the database, set this parameter to be between one and the number of physical storage devices used for the database. Workload Environments with high update transaction rates might require more page cleaners to be configured. Buffer pool sizes Environments with large buffer pools might also require more page cleaners to be configured. Also keep in mind that having too many page cleaners may overwhelm the run queue on the database server and cause the significant performance degradation. Hence, as a rule of thumb, you may consider setting the number of page cleaners equal to the number of CPUs on the database server. No file system caching The operating system, by default, caches file data that is read from and written to disk. A typical read operation involves physical disk access to read the data from disk into the file system cache, and then to copy the data from the cache to the application buffer. Similarly, a write operation involves physical disk access to copy the data from the application buffer into the file system cache, and then to copy it from the cache to the physical disk. This default behavior of caching data at the file system level is reflected in the DB2 table space clause: FILE SYSTEM CACHING with the default value of "Yes". Since the DB2 database manager manages its own data caching using buffer pools, the caching at the file system level is not needed if the size of the buffer pool is tuned appropriately. In some cases, caching at the file system level and in the DB2 buffer pools causes performance degradation because of the extra CPU cycles required to do the double caching. To avoid this double caching, most file systems have a feature that disables caching at the file system level. This is generically referred to as non-buffered I/O. On UNIX, this feature is commonly known as Direct I/O (or DIO). On Windows, this is equivalent to opening the file with the FILE_FLAG_NO_BUFFERING flag. In addition, some file systems such as IBM JFS2 or VERITAS VxFS also support enhanced Direct I/O, that is, the higher-performing Concurrent I/O (CIO) feature. The DB2 database manager automatically takes advantage of CIO on file systems where this feature exists. These features might help to reduce the memory requirements of the file system cache, thus making more memory available for other uses. As stated above, the DB2 database manager automatically enables file system caching when performing I/O. To disable it, you can use the CREATE TABLESPACE or ALTER TABLESPACE statements. Use the NO FILE SYSTEM CACHING clause to enable non-buffered I/O, thus disabling file caching for a particular table space. Once non-buffered I/O is enabled, the DB2 database manager automatically determines which of the DIO or CIO is to be used on all platforms. Given the performance improvement in CIO, the DB2 database manager uses it whenever it is supported; there is no user-interface to specify which one is to be used. Page 16

17 In order to obtain the maximum benefits of non-buffered I/O, it might be necessary to increase the size of DB2 buffer pools to mitigate any loss of benefit from file caching. The recommended method of enabling non-buffered I/O is at the table space level, using the DB2 implementation method. This method allows you to apply non-buffered I/O on specific table spaces while avoiding any dependency on the physical layout of the database. It also allows the DB2 database manager to determine which I/O is best used for each file, buffered or non-buffered. Table 3 shows the supported configuration for using table spaces without file system caching. It also indicates whether DIO or enhance DIO will be used in each case. The link to this table can found here: doc/t htm Table 3. Supported configuration for table spaces without file system caching. Platforms File system type and minimum level required DIO or CIO requests submitted by the DB2 database manager AIX 5.2+ Journal File System (JFS) DIO AIX 5.2+ AIX 5.2+ HP-UX 11i (PA-RISC) HP-UX 11i (Itanium ) Concurrent Journal File System (JFS2) VERITAS Storage Foundation for DB2 4.0 (VxFS) VERITAS Storage Foundation for DB2 3.5 (VxFS) VERITAS Storage Foundation for DB2 3.5 (VxFS) CIO CIO DIO DIO Solaris 9 UNIX File System (UFS) DIO Solaris 10 UNIX File System (UFS) CIO Solaris 9, 10 Linux distributions SLES 9 and RHEL 4 (on these architectures: x86, x86_64, IA64, POWER ) Linux distributions SLES 9 and RHEL 4 (on these architectures: x86, x86_64, IA64, POWER) Linux distributions SLES 9 and RHEL 4 (on this architecture: zseries ) Windows VERITAS Storage Foundation for DB2 4.1 (VxFS) ext2, ext3, reiserfs VERITAS Storage Foundation 4.1 (VxFS) ext2, ext3 or reiserfs on a Small Computer System Interface (SCSI) disks using Fibre Channel Protocol (FCP) No specific requirement, works on all DB2 supported file systems CIO DIO CIO DIO DIO Page 17

18 Note: The VERITAS Storage Foundation for the DB2 database manager might have different operating system prerequisites. The platforms listed above are the prerequisite for the current DB2 release. Consult the VERITAS Storage Foundation for DB2 support information for the prerequisite information. Page 18

19 Dell Compellent Volumes (LUNs) Layout When creating volumes for your databases, you need to consider following the below recommendations: Separate volumes (LUNs) for DB2 data, active transaction logs, and archived logs. Create multiple volumes (LUNs) for table spaces (minimum 4) depending on the size of your table space and the work load. Each volume (LUN) should contain one table space container. For example: if you create a data table space across 4 volumes, each of these volumes will have one container; totaling 4 containers for this table space. Use RAID10 for data volumes, transaction logs volumes, and archived logs volumes. Configure multipath for your volumes (LUNs). Refer to the table below for proper RAID configuration for your active data and Replay data. Tier 1 15K FC Writeable Data R10 Data Table Space / Active Transaction Logs / Archived Logs Replay Data R5/5 Data Table Space R5/9 Tier 2 10K FC R10 R5/5 Data Table Space R5/9 Tier 3 SATA R10 R5/5 Archived logs R5/9 Page 19

20 DB2 best practices In order to have a performing DB2 UDB database system, the following should be considered: As a rule of thumb, allocate physical disks per CPU core. In the case of Dell Compellent Storage Center, you should have 1 disk enclosure (15 active drives) per CPU core. Separate data table space, transaction logs, and archived logs into their own LUNs. Configure at least 4 containers for data table space. If your table space is heavily accessed, use 8 containers (8 LUNs) or more. Use file systems instead of raw devices. Use the NO FILE SYSTEM CACHING keyword when creating your table space. Use RAID10 for all writable data. Configure your buffer pools large enough to handle the I/O. Set your table space EXTENTSIZE to RAID stripe size. In the case of Dell Compellent Storage Center, if you use the default data page size on the Dell Compellent, then you need to create the EXTENTSIZE for your table space of 2MB. Set NUM_IOSERVERS to a value that is one or two more than the number of physical disks. Make sure not to set the NUM_IOCLEANERS too high as this may degrade database performance. Page 20

21 Conclusion Having good knowledge of how IBM DB2 UDB and Dell Compellent Storage Center work, you can achieve an optimal design for your databases. Once a design is set, you need to run some regression tests to make sure that it fits your business needs. Above all, a DBA s time and effort is best spent optimizing the database schema, rather than physical database storage. Optimizing the schema involves using functionality like MDCs, MQTs, creating appropriate indexes, and dropping inappropriate ones. After all, there is no higher throughput or lower latency I/O than one that does not need to be performed at all. Page 21