Tivoli Storage Productivity Center 4.2Repository Whitepaper

October 2012Version 1.2

Kai Boerner,Andrei Bulie,Cezar Constantinescu,Martin Eggers,Dragos Haiduc,Werner Link,Maggie Phung,Oliver Roehrsheim,Patrick Schaefer,Marcus Siegmund,Helene Wassmann

1

Legal Notice

© Copyright IBM Corporation 2011,2012

IBM Research & Development GermanyLocation MainzHechtsheimer Strasse 255131 MainzGermany

Octorber 2012

All Rights Reserved

IBM, the IBM logo, ibm.com, Tivoli, IBM DB2 and Tivoli Storage Productivity Center are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.

If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or TM), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries.

A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at

ibm.com/legal/copytrade.shtml

Other product, company or service names may be trademarks or service marks of others.

2

Table of Content

1 Introduction ................................................................................................................................... 4 1.1 Tivoli Storage Productivity Center ......................................................................................... 4 1.2 Who should read this Document ............................................................................................. 5

2 Estimating and controlling the size of TPC database .................................................................... 6 2.1 Guide through the calculation ................................................................................................. 6

2.1.1 Identifying key calculation factors .................................................................................. 6 2.1.2 Identifying keepalive time of historical data ................................................................... 7 2.1.3 Estimate database space consumption ............................................................................. 7 2.1.4 Setting up database space on various filesystems and disks ............................................ 7

2.2 Controlling through Resource Retention ................................................................................ 8 2.2.1 Resource History Retention ............................................................................................. 8 2.2.2 Removed Resource Retention ........................................................................................ 11 2.2.3 History Aggregator ........................................................................................................ 13

2.3 Estimate and control size of Historical Performance Management data .............................. 14 2.3.1 Understanding Performance Data size dependencies .................................................... 15 2.3.2 Performance Data History Retention ............................................................................. 16 2.3.3 Storage Subsystem Performance Data Sizing ................................................................ 17 2.3.4 Fabric Performance Management Data Sizing .............................................................. 24 2.3.5 Snapshot Performance Management Data Sizing .......................................................... 26

2.4 Estimate sizing of TPC for Data ........................................................................................... 30 2.4.1 Sizing the repository for TPC for Data requirements .................................................... 30 2.4.2 Sizing the repository for DB Scan requirements ........................................................... 34

2.5 Estimate sizing of TPC Alerts .............................................................................................. 36 2.5.1 Alerts ............................................................................................................................. 36 2.5.2 Database space used by Alerts ....................................................................................... 37

3 Database configuration ................................................................................................................ 39 3.1 Database configuration through TPC installer ..................................................................... 39 3.2 Tuning-Parameters for fresh database installations .............................................................. 43

3.2.1 Database instance parameters ........................................................................................ 44 3.2.2 Database parameters ...................................................................................................... 44 3.2.3 References to DB2 configuration parameters ................................................................ 47

4 Optimizing use of physical storage for DB2 databases ............................................................... 48 4.1 Placing the DB2 transaction logs onto a separate disk ......................................................... 48 4.2 Setting the DB2 database on separate disk ........................................................................... 49

4.2.1 Moving an “Automatic Storage” database to one or more different disks .................... 54 4.2.2 Expanding an “Automatic Storage” database with an additional disk .......................... 54 4.2.3 Expanding “Database managed (DMS) tablespaces” with an additional disk .............. 55

3

1 Introduction

In a world with networked and highly virtualized storage, database storage design can appear as a daunting complex task for a database administrator (DBA) or system architect to get right.

Poor database storage design can have a significant negative impact on a database server. CPUs are so much faster than physical disks that it is not uncommon to find poorly performing database servers that are significantly I/O bound and underperforming by many times their true potential.

The good news is that it is more important to not get database storage design wrong than it is to get it perfectly right. Trying to understand the innards of the storage stack and hand tuning which database tables and indexes should be stored on which part of what physical disk is an exercise that is neither generally achievable nor maintainable (by the average DBA) in today’s virtualized storage world.

Simplicity is the key to ensuring good database storage design. The basics involve ensuring an adequate number of physical disks to keep the system from becoming I/O bound.

This document provides some guidelines and best practices regarding IBM DB2 repository tuning for IBM Tivoli Productivity Center.

1.1 Tivoli Storage Productivity Center

IBM® Tivoli® Storage Productivity Center (TPC) is a storage infrastructure management software product that can centralize, automate, and simplify the management of complex and heterogeneous storage environments. The generic term TPC is used further in this document, and is intended to specifically refer to TPC Edition of release 4.2.x. TPC uses the IBM DB2 Database Management System (DBMS) as persistence layer to store the various objects and corresponding object attributes. Since IBM DB2 was developed to be used for various different applications, having a variety of different requirements towards a DBMS, IBM DB2 offers a rich set of parameters to explicitly tune the database to fullfill application specific requirements.

4

1.2 Who should read this Document

This document enables the TPC administrator to control and estimate the IBM Tivoli Storage Productivity Center version 4.2.x. It is also for those who are responsible for administrating and tuning the underlying IBM DB2 for best performance.

This document will assume that TPC is used as application layer software, leveraging IBM DB2 as DBMS. General approaches for DB2 repository performance improvement will be described. How to enable DB2 parameters for optimizing DB2 for your storage environment will be covered.One major topic of this document is to enable the administrator of TPC to control and estimate the need of physical disk space for all historical data TPC collects.

Chapter 2 enables the TPC Administrator to estimate how much space its TPC database need for historical data, performance data and filesystem data.

Chapter 3 and 4 enabled the TPC Administrator to move the TPC database to the specified disk drives and configure DB2 to improve performance and space usage.

Readers should be familiar with the following topics:• Microsoft® Windows® , Linux and UNIX® operating systems• Database architecture and concepts• Security management aspects• User authentication and authorization

If you are enabling Secure Sockets Layer (SSL) communication, you also should be familiar with SSL protocol, key exchange (public and private), digital signatures, and certificate authorities.

5

2 Estimating and controlling the size of TPC database

This chapter describes some topics you should know and understand regarding how TPC stores and maintains data collected by various monitoring jobs in the database (such as Performance Monitors or Filesystem Scans). Some components within TPC 4.2 are known to produce large amounts of data – especially for the purpose of visualizing historical data. In the following sections you will find samples and some information that will help you to estimate the space requirements in your specific environment for these components.

The chapter 'Controlling through Resource Retention' explains all the details required to understand how the required TPC 4.2 repository database space will grow over time for these tasks and how you can effectively limit the growing space requirements to your needs.

2.1 Guide through the calculation

2.1.1 Identifying key calculation factors

Before you can start the entire calculation, check your existing and planned environment for a set of factors needed for the space calculation. Please identify volumes, pools, disks for each subsystem of specific type, amount of switch ports, files and settings you would like to keep entity history and performance history data for.

For estimating the database space used by subsystems, you have to gather the information from your SAN environment:

Amount of LUNs: ◦ IBM ESS◦ IBM DS8000◦ IBM XIV◦ SMI-S based subsystems (IBM DS4000, EMC, HDS, HP, Netapp,...).

Amount of vdisks, mdisks and nodes: ◦ IBM SVC◦ IBM Storwize

Amount of fibre channel ports:◦ SMI-S based SAN Switches

Amount of Filesystems, Users and different file types:◦ Computers, which will be scanned by Storage Resource Agent for Filesystem data.

Amount of Tablespaces:◦ Computers, which will be scanned by Storage Resource Agent for database data

6

2.1.2 Identifying keepalive time of historical data

Before you proceed, please make yourself aware of which and how long you would like to keep the historical data of capacity information, entity data and especially performance metrics. This information is stored by TPC in different level of detail (per scan/sample, per hour, per day, per week and per month). More details on how to set this in TPC is documented in chapter 2.2.

Keep in mind that storing all information consume database space which will grow over time when history gets filled and have influence on database and TPC performance. So clarify for your purposes the questions:

◦ For how long you need to know capacity, entity and performance data?◦ Do you really need sample or other fine granularity data for a long amount of days, or is

maybe daily, weekly or monthly data enough?◦ Keep in mind that these settings are for data collections of all subsystems, computers and

switches, including the devices which you will add in future!

2.1.3 Estimate database space consumption

With the information of the key factors of your SAN environment and the knowledge of how long you need to keep the data, you can now move on and calculate the estimated database space consumption. Chapter 2.3 covers details and example calculations for various subsystems, virtualizers and switches. Walk through each of these chapters to estimate for each SAN entity the amount of database space used for storing performance metric data and their related history snapshot data.

Use the detailed calculations documented in chapter 2.4 to identify the amount if space needed for storing computer filesystem and database data.

Chapter 2.5 describes the space typically needed for the alerting functionality of TPC. One million alerts could use up to 1 GB of space. To be safe, you should always add a large amount of contingency space (in GB) for general usage, alerts and devices not yet managed by TPC.

2.1.4 Setting up database space on various filesystems and disks

At this point you should know how much database space is estimated for performance data, historical capacity and entity data and how often and fast you would like to access each of them. So it is time to think about how to place the database data on the storage with the disk performance and ability to increase disk space. Chapter 3 and 4 provide more details about how you can use TPC installation to deploy several tablespaces and their containers on different drives and how to move between them later after installation is done.

7

2.2 Controlling through Resource Retention

2.2.1 Resource History Retention

History data is the largest and most varied amount of data in the TPC repository, and therefore has the most significant influence on the size and performance of the repository database.

The resource history retention that you can see in Illustration 1 controls how long to keep the historical information. By specifying a number for the days, the weeks, or the months for each element on this window, you can control the amount of data that is retained and available for historical analysis and charting. The longer you keep the data, the more informative your analysis is over time.

When these settings are too high, they can have a negative effect on the amount of time that it takes to generate reports. If report generation starts to slow down to an unacceptable level, this might be due to high resource history retention settings.

Note: If you do not select a Performance Monitor check box, the data is never discarded and generates a great amount of data in the database. If you don't want to have any history or retained Data, press “No History” button or select individual check boxes and insert 0 days to keep.

Illustration 1 shows the default configuration. Adjust those values according to your specific environment.

Sample data is the data that is collected at the specified interval length of the monitor, for example, you can collect performance data every five minutes. The default retention period for sample data is 14 days, which means that by default, TPC keeps the individual five minute samples for 14 days before TPC purges the samples. TPC summarizes the Individual samples into hourly and daily data. For example, TPC saves the sum of 12 of the five minute samples as an hourly performance data record, and TPC saves the sum of 288 of these samples as a daily performance data record. The default retention periods for hourly and daily data are 30 days and 90 days, respectively.

8

Illustration 1: Resource History Retention

TPC for Databases has its own resource history retention configuration. You can see the configuration pane at Administrative Services - Configuration - Resource History Retention for Databases. Illustration 2 shows the default settings.

9

Illustration 2: Resource History Retention for Databases

TPC for Data has an additional resource history retention configuration. You can see this setting in each profile (Data Manager - Monitoring - Profiles). Profiles are assigned to scans. Illustration3 shows an example. You can set the retention period per sample, week, and month.

10

Illustration 3: Profile defined for Statistical Data History

2.2.2 Removed Resource Retention

Removed Resource Retention controls how long an entity resides in the TPC repository after it has been removed from the environment. Such entities are displayed with a status of 'missing' in the user interface. This affects entities like subsystems, computers, fabrics, switches etc, because when these are removed, all related data to that system is removed, too.

For example, if a volume has been deleted, after the next probe, the storage subsystem health indicates a warning, because a volume is missing. This health status remains until you remove the missing entity manually or the Remove Resource Retention time has passed. You can only remove missing entities from the TPC repository, except that you can also remove the storage subsystem from the TPC repository. Select Disk Manager – Storage Subsystems, click the subsystem that you want to remove, and select Remove.

11

Select Administrative Services - Configuration - Removed Resource Retention to reach the control panel. Illustration 4 displays the default settings.

Illustration 4: Removed Resource Retention

TPC for Databases has its own resource history retention configuration. Select Administrative Services - Configuration - Removed Resource Retention for Databases to access the configuration panel. Illustration 5 shows the default settings.

12

Illustration 5: Removed Resource Retention for Databases

2.2.3 History Aggregator

The History Aggregator enables jobs to sum data in an enterprise environment for historical reporting purposes, such as summary statistics and user space usage statistics, and is extremely important. Check the state of the History Aggregator regularly. Improper maintenance in this area can negatively impact historical data trending. Run the History Aggregator daily, which is the default. Configure the History Aggregator at Administrative Services - Configuration - History Aggregator. Illustration 6 shows the configuration panel. The History Aggregator is used within TPC for Data but also removes old Alert log records. You do not use the History Aggregator to create hourly and daily performance samples.

13

Illustration 6: History Aggregator

2.3 Estimate and control size of Historical Performance Management data

IBM Tivoli Storage Productivity Center Performance Manager produces a lot of historical data by collecting this from the managed subsystems and switches, and stores this in the TPC database. The size of such data grows over time until it reaches the age you defined previously in Resource Retention. Estimating how much disk space is needed for this data in the database allows you to avoid running out of disk space, which would severly impact the operation of TPC. So if your space is limited and cannot be increased easily, take some time and calculate your estimated database size requirements.

Performance data is historical in nature. It means, it is collected periodically and stored in the TPC repository database. The sample performance data is obtained directly from the individual devices, and the delta between two subsequent samples are saved into TPC repository tables. Each row saved in these

14

sample performance data tables is associated with a particular resource of the storage subsystem at a particular date and time.Over time, TPC creates hourly and daily averages of this data. The averaged data requires less storage space in the repository over a longer period of time. It also makes reporting over a longer time period more meaningful and easier to display.

2.3.1 Understanding Performance Data size dependencies

There are a number of performance counters that each device type keeps track of. Since counters are kept for diverse devices and device components, usually including individual volumes, the database size can grow dramatically in short periods of time. The main factor in database size is the number of volumes configured on the particular storage subsystem devices, and the frequency with which historical performance data is collected and saved.

The sample data, based on user settings for each particular device, could be collected in 5, 10, 15, 20, 30 or 60 minutes time intervals. For devices, with the collection frequency at 5-minutes interval, TPC would collect and store in the repository 60/5 x 24 = 288 samples per day. This consumes much more repository storage than if the user chose to sample the same devices at 30-minute interval. The last requires from TPC to collect and store 60/30 x 24 = 48 samples per day and per device.

In order to avoid filling up the available disk space, or overwhelming the database management system with too much data, it is necessary to purge or consolidate the existing data periodically. Data consolidation is handled via the summarization performance data in hourly and daily, but the sample data tables should be subject to strict size control. It is important to recognize that database performance will be impacted by database size, and especially database query and delete operations will show linear degradation with increased table size. The best answer to this issue is for the user to adopt a rigid database purge policy to ensure that older less important performance data is periodically deleted from the database. TPC has a configuration panel that controls how much history you keep over time.

15

2.3.2 Performance Data History Retention

Illustration 7 shows the TPC panel for setting the history retention for performance monitors as well as other types of collected statistics.

Important: The history aggregation process is a global setting, which means that the values set for history retention are applied to all performance data from all devices. You cannot set history retention on an individual device basis.

• Per performance monitoring taskThis value defines the number of days that TPC keeps individual data samples for all of the devices that send performance data. The example shows 14 days. When per sample data reaches this age, TPC permanently deletes it from the database. Increasing this value allows the user to look back at device performance at the most granular level at the expense of consuming more storage space in the TPC repository database. Data held at this level is good for plotting performance over a small time period but not for plotting data over many days or weeks because of the number of data points. Consider keeping more data in the hourly and daily sections for longer time period reports.

• Hourly

Illustration 7: Performance Data History Retention

16

This value defines the number of days that TPC holds performance data that has beengrouped into hourly averages. Hourly average data potentially consumes less space in the database.

• DailyThis value defines the number of days that TPC holds performance data that has been grouped into daily averages. After the defined number of days, TPC permanently deletes records of the daily history from the repository.Daily averaged data requires 24 times less space in the data for storage compared to hourly data. This is at the expense of granularity; however, plotting performance over a longer period (perhaps weeks or months) becomes more meaningful.

2.3.3 Storage Subsystem Performance Data Sizing

There is a significant difference in the sizing calculation between the following 3 device type groups:

• IBM and Non-IBM storage subsystems (ESS, DS8000, DS4000, DS5000, EMC, HP, HDS, ...)• IBM storage virtualizers (SVC, Storwize)• IBM XIV storage subsystem

For this reason, the sizing tables are separated.

Note: Notice that the final illustration is pure performance data sizing and doesn't include any additions used by DB2 for index spaces and other database overhead.The DB2 index spaces may vary significantly based on the current DB2 version and its setup.

Sizing the repository for IBM and non-IBM storage subsystems

For these subsystem families and most of non-IBM subsystems, the biggest component is the volume, and the biggest performance sample data will be that of volumes.

Table 1 shows working examples for four storage subsystems in an environment and the amount of storage space that performance collection uses for each example. The total illustration represents the amount of storage needed for the “per sample” data. Continue through this section to calculate the complete amount of storage needed for hourly and daily history types.

Calculation method example for ESS:60/5 x 24 = 288 samples per day x 1,500 volumes x 349 bytes per sample = 150,768,000 bytes

17

(a) Subsystem type

(b) Number of volumes (LUNs) sampled

(c) Performance collection interval (minutes)

(d) Performance data record size

(e) Daily amount of samples data collected 60 / (c) x 24 x (b) x (d)

= (e)

ESS 1,500 5 349 bytes 143 MB

DS8000 1,500 5 605 bytes 235 MB

DS4000 500 5 349 bytes 50 MB

Non-IBM 1,000 5 349 bytes 95 MB

Daily totals (f) 523 MB

Sample History Retentionper performance monitor task =14 days

Total MB = (f) x 14 days 7322 MB

Table 1: Per sample repository database sizing for ESS, DSxxxx, and non-IBM subsystems

You can see that the amount of space that is required increases dramatically as the sample rate increases. Remember this when you plan the appropriate sample rate for your environment.

Next, use Table 2 to calculate the amount of storage that is needed to hold the performance data for the hourly and daily history averages. When complete, add together the totals from Table 1 and Table 2 to give you the total repository requirement for these types of storage subsystems as seen in Table 3.

Calculation method example for ESS:1,500 volumes x 349 bytes per sample x 60/interval length = 6,282,000 bytes for hourly

history average

18

(a) Subsystem name

(b) Number of volumes (LUNs) sampled

(c)Performance data record size

(d) Hourly requirement (b) x (c) x 24

(e) Daily requiremt (b) x (c)

ESS 1,500 349 bytes 12 MB 0,5 MB

DS8000 1,500 605 bytes 20 MB 0,82 MB

DS4000 500 349 bytes 4 MB 0,17 MB

non-IBM 1,000 349 bytes 8 MB 0,33 MB

Daily totals 44 MB 1,82 MB

History Retentionhourly =30 days

(f) 1320 MB

History Retentiondaily =90 days

(g) 164 MB

Total MB( (f) + (g) )

1484 MB

Table 2: Hourly and daily repository database sizing for ESS, DSxxxx, and non-IBM storage

Table 3 shows the total TPC repository space required for ESS, DSxxxx, and non-IBMstorage subsystems. The total TPC repository space is the sum of the totals of both Table 1 and Table 2.

Total space required 7,322 MB

1,484 MB

8,806 MB

Table 3: Total TPC repository space required for ESS, DSxxxx, and non-IBM subsystems

Sizing the repository for SVC and Storwize V7000

There are a few topology basics, which differentiate the SVC/Storwize V7000 from any other storage device and affect the entire performance management view of that device.

The SAN Volume Controller is a single point of control for disparate, heterogenous storage resources. It can be expanded up to eight nodes in one cluster. Highly available I/O Groups are the basic configuration element of an SVC cluster. An I/O Group is formed by combining a redundant pair of SVC nodes. SVC submits I/O to the back-end (MDisk) storage, which could

19

be an ESS or DS volume, a FAStT volume, or some other generic volume allocated from some other storage subsystem. The SVC nodes interact with the storage subsystems in the same way as any direct-attached host. SVC references to MDisks are analogous with host-attached LUNs in a non-SVC environment.

TPC collects and stores the MDisk level performance statistics for SVC devices. Each MDisk corresponds to the performance data associated with a single managed disk configured for the SVC machine, measured from a single SVC node, for a single data collection interval. It means, there is a row in TPC repository database per collection interval, per node, per MDisk. Therefore the number of Mdisks performance data rows could be counted as follows:

Mdisks + Mdisks * nodes = Mdisk * (nodes +1)

TPC collects the VDisk level performance statistics for SVC devices as well. The Vdisk entity corresponds to the performance data associated with a single virtual disk configured for the SVC machine, measured from a single SVC node, in the responsible I/O Group, for a single data collection interval. For each Vdisk there will be a row in the repository per collection interval, per I/O Group node. Therefore the counter for Vdisk rows:

Vdisks + Vdisks *2 (nodes in I/O Group) = Vdisks *3

Table 4 shows working examples for 2 SVCs with different configurations (number of volumes, performance data sample interval, etc..). The total illustration represents the amount of storage needed for the “per sample” data. Continue through this section to calculate the complete amount of storage needed for hourly and daily history types.

Calculation method example for SVC named SVC_Test:60/5 x 24 = 288 samples per day x 3,045 data records(*) x 250 bytes per sample = 219,240,000

bytes

for data records(*) use the following formula: (a)Number of Vdisks *3 + (b)Number of Mdisks *((c)Number of nodes +1)

20

SVC (a)Number of Vdisks (LUNs)

(b)Number of MDisks

(c)Number of nodes

(d)Performance collection interval (min)

(e)Performance data record size

Daily amount of data collected 60 / (d) x 24 x (e) x data records(*)

SVC_Test 1,000 15 2 5 250 bytes 219,240,000

SVC_Prod 3,000 15 6 15 250 bytes 218,520,000

Daily totals (f)437,760,000

History Retention per performance monitor task =14 days

(g)6,128,640,000

Total MB( (f) + (g) ) /1,000,000

6,567 MB

Table 4: Per sample Repository sizing for SVC

Next, use Table 4 to calculate the amount of storage that is needed to hold the performancedata for the hourly and daily history averages.

Calculation method example for SVC named SVC_Test:3,045 data records (*) x 250 bytes per sample x 24 = 18,270,000 bytes for hourly history average

for data records(*) use the following formula: Number of Vdisks *3 + Number of Mdisks *(Number of nodes +1)

(a)SVC (b)data records* (c)Performance data record size

(d) Hourly requirement (b) x (c) x 24

(e) Daily requiremt (b) x (c)

SVC_Test 3,045 250 bytes 18,270,000 86,250

SVC_Prod 9,105 250 bytes 54,630,000 2,276,250

Daily totals 72,900,000 2,362,500

History Retentionhourly =30 days

(f) 2,187,000,000

History Retentiondaily =90 days

(g) 212,625,000

Total MB( (f) + (g) ) /1,000,000

2,400 MB

Table 5: Hourly and daily repository database sizing for SVC

21

Table 6 shows the total TPC repository space required for SVC subsystems. The total TPC repository space is the sum of the totals of both Table 4 and Table 5.

Total space required 6,567 MB

2,400 MB

8,967 MB

Table 6: Total TPC repository space required for SVC subsystems

Sizing the repository for XIV

For each single XIV volume there will be a row stored in the TPC repository DB measured for a single data collection interval. Since XIV storage is relatively dynamic storage to TPC, it is not easy to provide the user the exact performance data row sizing. In our labs we measured between 80 and 200 bytes per row for XIV devices. This depends on how many interface modules are used for each individual volume. We are using 200 bytes in our calculation. To keep it simple enough we provide you a safe value for your capacity planning.

The table below shows examples for a storage subsystem in a production environment and the amount of storage space that performance collection is using for each example. The total illustration represents the amount of storage needed for the “per sample” data. Continue through this section to calculate the complete amount of storage needed for hourly and daily history types.

Calculation method example for XIV_Production:60/5 x 24 = 288 samples per day x 500 volumes x 200 bytes per sample = 28,800,000bytes

Per sample repository database sizing for XIV,(a)Subsystemname

(b) Number ofvolumes (LUNs)sampled

(c) Performancecollectioninterval(minutes)

(d) Performancedata record size (bytes)

(e) Daily amountof data collected(60/(c) x 24) x (b)

x (d) = (e)

XIV_production 500 5 200 28,800,000

XIV_Test 320 5 200 14,400,000

(f) Total required per day 43,200,000

(g) Number of days to retain persample = 14 days(f) x (g)/1,024,000 + 50%

907 MB

Table 7: Per sample Repository sizing for XIV

22

Note: Table 7 includes an additional 50%. This amount provides for DB2 table indexes and other database overhead.

You can see that the amount of space that is required increases dramatically as the samplerate increases. Remember this when you plan the appropriate sample rate for yourenvironment.

The next table shows how to calculate the amount of storage that is needed to hold the performance data for the hourly and daily history averages. When complete, add the totals from both tables in this section to give you the total repository requirement for this type of storage subsystem, as shown in the last table from this section.

Calculation method example for XIV_production:500 volumes x 200 bytes per sample x 24 = 2,400,000 bytes for hourly history average

Hourly and daily repository database sizing(a)Subsystemname

(b) Number ofvolumessampled (LUNs)

(c) Performancedata record size(bytes)

(d) Hourlyrequirement

(b) x (c) x 24

(e) Daily amountof data collected(60/(c) x 24) x (b)

x (d) = (e)

XIV_production 500 200 2,400,000 100,000

XIV_Test 320 200 1,536,000 64,000

Daily totals 3,936,000 100,000

Hourly retentiondays = 30 (f) 118,080,000

Daily retentiondays = 90

(g) 14,760,000

Total MB(f) + (g)/

1,024,000 + 50%190 MB

Table 8: Hourly and daily repository database sizing for XIVThe last table shows the total Tivoli Storage Productivity Center repository space required for XIV storage subsystems. The total Tivoli Storage Productivity Centerrepository space is the sum of the totals from the per sample and hourly/daily repository database sizing tables.

23

Total space required 907 MB

190 MB

1,097 MB

Table 9: Total TPC repository space required for XIV subsystems

2.3.4 Fabric Performance Management Data Sizing

For switches, the performance data is proportional to the number of ports in a switch. The necessary disk space is determined by the sum of the switch performance sample size and the aggregated sample size.

The disk space be calculated approximately according to the following formula:

Assuming:

NumPt = total number of ports to monitor CR = number of sample data collected per hour

(for a sample interval of 5 minutes, this should be 60/5 = 12 samples ) Rs = retention for sample data in days Rh = retention for hourly summarized data in days Rd = retention for daily summarized data in days

Switch performance sample size[byte] = NumPt * CR * 24 * Rs * 400 byte

Switch performance aggregated data size[byte] = NumPt * (24 * Rh + Rd) * 420 byte

Total Switch performance size = Switch performance sample size + Switch performance aggregated data size

Example: For an environment with the following configuration:

• 3 Switches:Switch A with 8 portsSwitch B with 16 portsSwitch C with 24 ports

• The Fabric performance monitor is configured to run indefinitely.

24

• The sample interval is set to 5 minutes.• Retention for sample data is 14 days.• Retention for hourly summarized data is 30 days• Retention for daily summarized data is 30 days

The necessary disk space can be calculated with:

NumPt = 8 + 16 + 24 = 48 CR = 60 / 5 = 12 Rs = 14Rh = 30Rd = 30

Switch (a)Number of Ports (b)Performance collection interval (min)

(c)Performance data record size

Daily amount of data collected (a) x 60 / (b) x 24 x (c)

Switch A 8 5 400 bytes 921,600

Switch B 16 5 400 bytes 1,843,200

Switch C 24 5 400 bytes 2,764,800

Daily totals (f)5,529,600

History Retention per performance monitor task =14 days

(g)77,414,400

Total MB( (f) + (g) ) /1,000,000

82,944 MB

Table 10: Per sample Repository sizing for Switches

25

Switch (a)Number of Ports (b)Performance data record size

Daily amount of hourly data collected (a) x (b) x 24

Daily amount of daily data collected (a) x (b)

Switch A 8 420 bytes 80,640 3,360

Switch B 16 420 bytes 161,280 6,720

Switch C 24 420 bytes 241,920 10,080

History Retention per hourly performance monitor data =30 days

(f)14,515,200

History Retention per daily performance monitor data =30 days

(g) 604,800

Total MB( (f) + (g) ) /1,000,000

15,120 MB

Table 11: Per hourly and daily Repository sizing for Switches

Total Switch performance size = 82.94 MB + 15.12 MB

= 98.06 MB

2.3.5 Snapshot Performance Management Data Sizing

Snapshots are copies of the current configuration tables at a given point in time. The configuration data from the snapshot tables at a certain time will associate with the statistical data collected from that instance onwards. A snapshot copy will be used as reference until there is a new copy created. For most devices, these snapshot copies are created when • The performance data collection is started• A change in configuration occurs, for example, a new volume is created.• A snapshot has reached its expiration date for the duration of data collection.

For SVC and Storwize, due to the underlying structure, there is an additional case when a snapshot is taken. When the SVC is scheduled to collect performance data at a definite duration, a set of snapshot will be created when the task has reached half of its duration. For example, if the duration is set to 2 hours, the snapshot will be taken when the data collection starts and an hour after it has started.

26

The data from these snapshot tables are kept as long as the duration of the statistical data persist in the tables base on the retention setting.

The calculation for the size of snapshots can be very different. This can be affected by a number of facts from device type to configuration of each device. In order to simplify the calculation, each device type will have its own formula. The components that are mostly influencing the size of the database for that individual device type will contribute as the factors in the formulars.

1. Calculation method for ESS snapshot: For every volume, there will be approximately two rows persisted into the database.Formula for data records(*) :

Number of Volumes * 2

With an average of 250 bytes per record and the number of data records calculated above, the total space needed for this ESS can be calculated as following: 1 snapshot per day x 2000 data records(*) x 250 bytes per record = 500,000 bytes

2. Calculation method for DS8000/DS6000 snapshot:The data records are mainly based on the number of volumes and how they span over multi-rank extent pools. The data records calculation uses a constant of 5 as an average number of ranks that a volume spreads over.

Formula for data records(*) : Number of Volumes + Number of Volumes * 5 = Number of Volumes * 6

With an average of 200 bytes per record and the number of data records calculated above, the total space needed for this DS8000 can be calculated as following:

1 snapshot per day x 18,000 data records(*) x 200 bytes per record = 3,600,000 bytes

3. Calculation method for DS4000/DS5000 snapshot:The data records are mainly based on the number of volumes and how they spread across the number of physical disks. The following formula uses 5 as an average number of disks that a volume spreads over.

Formula for data records(*) :Number of Volumes + Number of Volumes * 5 = Number of Volumes * 6

With an average of 200 bytes per record and the number of data records calculated above, the total space needed for this DS4000 can be calculated as following:

1 snapshot per day x 2000 data records(*) x 200 bytes per record = 400,000 bytes 4. Calculation method for non-IBM snapshot

27

The data records are mainly based on the number of volumes and how they spread across the number of physical disks. The following formula uses 5 as an average number of disks that a volume spreads over.

Formula for data records(*) :Number of Volumes + Number of Volumes * 5 = Number of Volumes * 6

With an average of 200 bytes per record and the number of data records calculated above, the total space needed for this HDS can be calculated as following:

1 snapshot per day x 6,000 data records(*) x 200 bytes per record = 1,200,000 bytes

5. Calculation method for SVC/Storwize snapshotThe data records for SVC are mainly based on the number of volumes and how they span across the number of Mdisks. A Vdisks can reside on as little as 1 Mdisk to the maximum number of available Mdisks. However, a Vdisk is unlikely to spread over all Mdisks. For most cases, each will span over a range of 1 to 10 Mdisks. In the following formular, using 5 as an average number of Mdisks.

Formula for data records(*) :Number of Vdisks + Number of Vdisks* 5 = = Number of Vdisks * 6

With an average of 488 bytes per record and the number of data records calculated above, the total space needed for this SVC can be calculated as following:

1 snapshot per day x 3,732 data records(*) x 248 bytes per record = 925,536 bytes

6. Calculation method for XIV snapshotFor every volume, there will be approximately three rows persisted into the database.

Formula for data records(*) : Number of Volumes * 3

With an average of 438 bytes per record and the number of data records calculated above, the total space needed for this XIV can be calculated as following:

1 snapshot per day x 3,000 data records(*) x 438 bytes per record = 1,344,000 bytes

7. Calculation method for Switch snapshotFor every port, there will be approximately two rows persisted into the database.

Formula for data records(*) : Number of Ports * 2

With an average of 150 bytes per record and the number of data records calculated above, the total space needed for this Switch can be calculated as following:

28

1 snapshot per day x 80 data records(*) x 150 bytes per record = 12,000 bytes

Table 12 shows the examples for all device types with different hardware configurations and the assumption that one snapshot is taken daily . The total represents the amount of storage needed for all devices in one day.

Storage Devices or Switches

Number of Ports

Number of Nodes

Number of Mdisks

Number of Rank

Number of Disks

Number of Volumes

Record Size

Required space per snapshot

ESS 1000 250 bytes 600,000 bytes

DS8000 8 3000 200 bytes 3,600,000 bytes

DS4000 14 400 200 bytes 400,000 bytes

SVC/Storwize 2 66 622 250 bytes 925,536 bytesNon-IBM 12 1000 200 bytes 1,200,000 bytes

XIV 180 300 348 bytes 1,344,000 bytes

Switch 40 150 bytes 12,000 bytes

Total MB 7.7 MB

Table 12: Snapshot repository database sizing

29

2.4 Estimate sizing of TPC for Data

2.4.1 Sizing the repository for TPC for Data requirements

Repository sizing for TPC for Data is more difficult to accurately model due to the dynamic nature of the collected data. Performance data collection sizing is simple in that it collects a set amount of data at regular intervals.

However with TPC for Data, a policy or profile collects a variable amount of data from each monitored server based on what and how much data of a matching type is found on each machine.

Key factors in sizing TPC for Data (with focus on Filesystem Scan):

• Total number of operating system registered users storing files• Total number of filesystems monitored• Total number of different file types (that is, *.txt, *.exe, *.doc, *.mp3, and so forth)• Number of machines with Storage Resource Agents or Data Agents deployed and

collecting data• Total number of file names collected and stored for reporting• The settings for 'Resource History Retention' as outlined in the previous chapter.

With respect to Filesystem Scan, the following database tables are known to typically accumulate the most information over time. Therefore this chapter explains how to calculate the space requirements for these table.

Table Name Describtion Average size in bytes per entryT_STAT_FTYPE_HIST File type history 55T_STAT_FILE Stored file names 155T_STAT_USER_HIST User history file 55Table 13 Key largest repository tables

Table 14, Table 15 and Table 16 help to estimate the worst case sizing for these key tables.

The following table helps to estimate the requirements for maintaining the file/folder ownership history on user basis (T_STAT_USER_HIST).

30

Statistic name

(a) Number of

filesystems covered

(b) Number of users covered

(c) Days to keep scan history

(d) Number of weeks of

scan history

(e) Number of months of scan history

Records maintained

= a x b x (c + d + e)

Custom_stat 300 800 30 52 24 25,440,000UNIX_stat 250 1,500 30 52 24 39,750,000Windows_stat 500 2,000 30 52 24 106,000,000

Total number of records (worst case) 171,190,000

Total requirement (bytes) = Total number of records x 55 bytes 9,415,450,000

Realistic expectation :reduce to 50% of worst 4,707,725,000

4,708 MB

Table 14 Estimating the user history repository requirement (T_STAT_USER_HIST)

Note: Unlike the performance tables, we must estimate much more here. For example, there might be 500 filesystems covered by the Windows_stat and 2,000 users with data across the 500 filesystems, but not all of the 500 filesystems have files owned by the 2,000 users. There is likely only a subset of filesystems with data for all 2,000 users. This is why the realistic illustration is reduced to only 50% of the worst case illustraton. You might want to change the 50% factor to your specific requirements.

Use Table 15 to calculate the repository space required to store file type history information.

Estimating the required space for maintaining a file type history is more accurate than estimating the user table history, because the data entering this table is more constant for a given profile.

31

Statistic profile name

(a) Number of file types

(b) Number of TPC agents

covered

(c) Days to keep scan

history

(d) Number of weeks of

scan history

(e) Number of months of scan history

Records maintained

= a x b x (c + d + e)

Win_types 50 200 30 52 24 1,060,000UNIX_servers 50 150 60 52 24 1,020,000

Media files 30 50 60 52 24 204,000

Total number of records 2,284,000

Total (bytes) = Total number of records x 55 bytes 125,620,000

Total MB 126 MB

Table 15 Estimating the file type repository requirement (T_STAT_FTYPE_HIST)

The third TPC for Data repository table of significant size is the T_STAT_FILE table. This table holds a record of the file names, which have been collected by profiles for largest, most obsolete, orphan files, and so forth.

Note: If you plan to use TPC for Data for duplicate file spotting or to archive specific files for you, it is likely that you will need to increase the number of file names that each agent will collect. Be aware that TPC for Data can assist such tasks only by analyzing the file names collected into the database. Therefore the number of file names to be maintained is essential. On the other hand, increasing these numbers increases the requirements on the repository at the same time.Tip: Using filters on file types and folders would be helpful in order to limit the file names to those candidates that are of interest.

For more information on this topic refer to Redbook 'IBM TotalStorage Productivity Center Advanced Topics '.

With the following values applied to a specific profile, the "Total file names per agent" would accumulate to 1,800 file names to be collected per agent.

32

Illustration 8: Adding up all filenames

Statistic profile name

(a) Total file names collected per agent

(b) Number of agents to which this profile applies

Total files per statistic = a x b

Duplicate file spot 2,000 500 1,000,000

Control audio files 200 150 30,000

Archive old data 200 50 10,000

Total files in table 1,040,000

Size (bytes) = Total files x 155 bytes 161,200,000

Size 162 MB

Table 16 Estimating the file name repository requirement (T_STAT_FILE)

The final step for sizing the TPC for Data repository is to total the three tables and add an overhead for the default statistics. The average overhead for the default statistic types is provided at 1.5 MB per TPC agent. Therefore:

Default statistics overhead = Total number of agents x 1.5 MB

33

Example with 400 agents :

Default statistics overhead = 400 x 1.5 MB = 600 MB

Add this value in Table 17

Source Amount in MB User history 4,708File type history 126File names 162Default statistics overhead 600Total requirement (MB) 5,596

Table 17 TPC for Data repository total

2.4.2 Sizing the repository for DB Scan requirements

Since TPC maintains historical data on tablespace level as lowest entity, the total number of tablespaces monitored by TPC is the driving factor for calculating the space requirements for DBMS Scans.

Depending on the vendor of the DBMS and the actual setup of the databases monitored, the number of tablespaces will vary. In case you are monitoring these databases with TPC already, you may facilitate TPC's reporting functionality to determine the actual numbers. Otherwise you might want to use the toolset provided by your DBMS vendor.

Note that the key table in this calculation is also used by filesystem scan. Therefore the required space for DBMS Scan adds on top of existing space requirements and does not provide the upper limit size for this table.

Table Name Describtion Average size in bytes per entryT_STAT_FS_HIST Tablespace history 71Table 18 Key largest repository tables

34

Statistic profile name

(a) Number of databases

(b) Average number of

tablespaces

(c) Days to keep scan history

(d) Number of weeks of

scan history

(e) Number of months of scan history

Records maintained

= a x b x (c + d + e)

Warehouse (DB2) 200 50 60 52 24 1,360,000

Test (other) 1,000 25 7 52 12 1,775,000

Total number of records 3,135,000

Total (bytes) = Total number of records x 71 bytes 222,585,000

Total MB : Total (bytes) / 1,000,000 223 MB

Table 19 Estimating the tablespace history repository requirement (T_STAT_FS_HIST)

35

2.5 Estimate sizing of TPC Alerts

2.5.1 Alerts

You can set up Tivoli® Storage Productivity Center so that it examines the data that it collects about your storage infrastructure and writes an alert to a log when an event occurs. You also can specify that an action is initiated, such as sending an SMNP trap, sending an e-mail, or running a script when the event occurs.

Alerts are triggered based on the data collected by monitoring jobs (pings, scans, and probes), so the alerts must be defined before the monitoring jobs are run. For each alert, you select a condition that triggers the alert and (optionally) an action to be performed when that condition occurs. You can define an alert in the following ways:

• As part of a data collection schedule• As part of an alert definition

When an event occurs and triggers an alert. The alert is stored in the database, so that you can view them through TPC GUI. You can also select one or more other ways to be notified of the event. These alert notifications include SNMP traps, IBM® Tivoli Enterprise Console® events, IBM Tivoli® Netcool®/OMNIbus, Tivoli Storage Productivity Center login notifications, operating-system event logs, or email.

Note: Alerts are not generated in a Tivoli Storage Productivity Center instance for actions that you perform from that instance. For example, if you start Tivoli Storage Productivity Center and use Disk Manager to assign or unassign volumes for a subsystem, you do not receive alerts for those volume changes in that instance. However, if you assign and unassign volumes outside of that Tivoli Storage Productivity Center instance, an alert is generated.

In general, the following types of conditions can trigger alerts:

• A data collection schedule failed to complete.• A change occurred in the storage infrastructure.• A performance threshold was violated.

The specific conditions that can trigger events vary, depending on the type of storage resource that is being monitored.

Notification methods, or triggered actions, define the method by which you are notified of an alert: SNMP Trap, Tivoli Enterprise Console Event, IBM Tivoli® Netcool®/OMNIbus, Login Notification, Windows Event Log, UNIX Syslog, and email. Alerts are always written to the error log. Additionally, if a Data agent or Storage Resource Agent is deployed on a monitored

36

computer, you can run a script or start an IBM Tivoli Storage Manager job in response to the alert.

The following conditions must be met in order to successfully use alerts:

• Data collection schedules are configured and scheduled to run on a regular basis.• If you want to be notified about an alert in some way other than an entry in the log file, such

as using SNMP traps, Tivoli Enterprise Console events, or email, alert notification instructions must be configured before using the alert.

The following types of alerts are set for your system by default:

• New entity found• Job failed

2.5.2 Database space used by Alerts

All the alerts are always stored in the Alert Log, even if you have not set up notification.This log can be found in TPC GUI in the navigation tree at IBM Tivoli Storage Productivity Center → Alerting → Alert Log → All

The alerts use 3 tables in the DB2 database : T_ALERT_DEFINITION , T_ALERT_EMAIL , T_ALERT_LOG

T_ALERT_DEFINITION – table where all alerts definition are stored T_ALERT_EMAIL - table where email definition alerts are stored T_ALERT_LOG – table where all triggered alerts are stored

Many database activities to form SNMP and Tivoli Enterprise Console® events might affect overall performance if too many alerts get created.

1. Alerts can be suppressed to avoid generating too many alert log entries or too many actions when the triggering condition occurs often. If you selected a threshold as a triggering condition for alerts, you can specify the conditions under which alerts are triggered and choose whether you want to suppress repeating alerts. You can view suppressed alerts in the constraint violation reports.

2. Change the triggered actionsYou can edit an alert if you want to change the triggering condition, triggered action, or the storage resources against which it is deployed.

3. Enable / disable the alertsYou can disable an alert. This retains the alert definition but prevents the alert from being

37

run.

4. Delete the alerts ( not the default ones )

To ensure that the list of alerts in the navigation tree is up-to-date, you can delete alerts that you no longer want to implement.

If you decide that the alerts tables are occupying too much space you can always set the Alert Disposition → Alert Log Disposition, which represents the length of time to keep entries in the alert logs. The default is 90 days.

To make an idea of how much space the alerts occupy , in a complex environment the number of rows in T_ALERT_LOG can reach in 90 days 3 million entries and occupy approximative 1.12 GB.

38

3 Database configuration

3.1 Database configuration through TPC installerThrough the typical installation mode the TPC installer is installing the TPC database with the default settings in the default location set by the DB2. The other way to install TPC is the custom installation mode. Through this mode the installer lets you to configure the database as well. Illustration 9 shows the panel for choosing the installation mode.

Illustration 9: Initial installation panel Once you have selected the custom installation mode, you have to select what TPC components you want to install (you must select at least to create the database schema). Once you have selected the components you want to install and entered the credentials for the DB2. This DB2 user and password is used to create the TPC database schema. Once you have done that, you reach the Illustration 10 which gives you the options to create a new customized database or select an existing database.

39

Illustration 10: Database schema installation panelIf you have already used the installer to create a database schema only, the installer sees it and displays the information about it in this panel. In this case you have the option to use that database schema by selecting “Use local database” or you have the option to “Create local database”.

Note: If you have already installed a DB2 server and TPC database schema on a local system, you cannot use a remote DB2 server for the TPC database schema installation. The TPC installer selects the local DB2 server by default.

If you choose to create a new database schema, you must provide the database name. Usually it is TPCDB and the field is completed automatically, but it can have different names as well and them must be completed in the database name field. In this step once again you have the option to leave the default values for the database schema or to customize it by clicking the “Database creation details...” button.

If you choose to customize the creation of the database, a new panel will open with the database schema information. Illustration 11 shows the details panel for database schema creation.

40

Illustration 11: Database schema detailed installation panelIn this panel you can customize the database schema creation by setting the schema name ( the schema name cannot be longer than eight characters ) , by selecting on which drive the database schema is created ( i.e.: C: , D: ), by changing the size and location of the tablespace, by changing the management of the tablespace, and by changing the location and the size of the log that is created during the installation and which contains information about the install operations performed. The disk space needed for the TPC database schema varies significantly with the storage network configuration, data collection, data retention period and other factors. Unless you are an experienced administrator, you should use the default values for tablespace allocation, that the TPC installer provides.

Below I will provide a space estimation for each tablespace required by the TPC( Normal, Key, Big, Temp, Temporary user tablespace ), based on a configuration containing 5000 volumes with some general assumption:

The Normal tablespace is used for snapshots and miscellaneous data, and for a 5000 volumes configuration it should have around 500 MB. A table that uses significant space is T_RES_STORAGE_VOLUME_SNAPSHOT. This table uses about 2500 bytes for each record. The number of snapshots depends on the data collection activities.

41

The Key tablespace is used for configuration data which is constantly used. For example, the key entity and the relationships data , and for a 5000 volumes configuration it should have 500 MB. A table that uses significant space is T_RES_DATA_PATH. This table uses about 300 bytes for each record for the relationship between the storage volumes and host ports. There could be dozens to hundreds of data path for a volume.

The Big tablespace is used for performance statics, and for a 5000 volumes configuration it should have around 400 MB per day of performance data. The data collected for performance data for storage volumes can use a significant amount of space. For 5000 volumes, if performance data is collected every 5 minutes, the data for one day would be around 400 MB. If the data is kept 7 days, the data collected would take about 3 GB. If the data is kept longer, the storage must be scaled up accordingly. The Temp tablespace is used for temporary data for query processing and for other temporary tables. For a 5000 volumes configuration this tablespace should have 1 GB. This value applies as well for the Temporary user tablespace (for the same configuration).You can choose to manage the above tablespaces in 3 ways: System managed (SMS), Database managed (DMS) or Automatic Storage.

Through SMS the operating system manages the tablespaces. Containers are defined as regular operating system files, and they are accessed using operating system calls. Through SMS management containers cannot be dropped from SMS tablespaces, and adding new ones is restricted to partitioned databases. The SMS is used by default by the TPC installer.Through DMS DB2 manages the tablespaces. Containers can be defined either as files, which will be fully allocated with the size given when the tablespace is created, or as devices. Extending the containers is possible using the ALTER TABLESPACE command. Unused portions of DMS containers can be also released.Automatic storage database is the one in which tablespaces can be created and whose container and space management characteristics are completely determined by the DB2 database manager. At the most basic level, databases that are enabled for automatic storage have a set of one or more storage paths associated with them.

Note: Unless you are an experienced administrator, you should use the default values for tablespace allocation.

42

3.2 Tuning-Parameters for fresh database installations

The TPC installer sets important DB2 tuning parameters to auto-tuning.

One important change to the earlier TPC releases is that TPC configures self tuning bufferpools. With self tuning bufferpools the database manager adjusts the size of the buffer pools in response to workload requirements. Having self tuning bufferpools removes the need to measure bufferpool hit ratios and to manually adjust bufferpool sizes in order to utilize them best.

Self tuning buffer pools reside in shared memory regions that the database manager can balance with other database memory pools. The TPC installer configures no upper limit for the shared memory regions. If upper limits for overall memory usage of DB2 are needed, this can be configured either on the database instance level or on the database level. The parameter for the database instance is “Size of instance shared memory” (INSTANCE_MEMORY). The parameter for the database is “Size of database shared memory” (DATABASE_MEMORY).

For reference, the parameters that the TPC installer configures to auto-tuning are listed in the tables below. These are the most important parameters and are not a complete listing.

A hints and tips chapter “5.5.2 DB2 Performance Tuning” mentions different tuning recommendations (http://www-01.ibm.com/support/docview.wss?uid=swg27008254). Those are outdated and will be removed from the TPC hints and tips.

43

3.2.1 Database instance parameters

Parameter Value ExplanationMON_HEAP_SZ DB2 9.1 – 512

DB2 9.5 or higher – AutomaticThis parameter determines the amount of the memory, in pages, to allocate for database system monitor data.

INSTANCE_MEMORY Automatic This parameter specifies the maximum amount of memory that can be allocated for a database partition. To limit the total memory usage you set it to a specific value.

3.2.2 Database parameters

Parameter Value ExplanationDATABASE_MEMORY Automatic This parameter specifies the

maximum amount of memory that can be allocated for the database shared memory region. To limit the total memory usage you set it to a specific value.

44

Parameter Value ExplanationSELF_TUNING_MEM On This parameter determines

whether the memory tuner will dynamically distribute available memory resources as required between memory consumers that are enabled for self-tuning.

DBHEAP DB2 9.1 – 3000DB2 9.5 – 3000DB2 9.7 – Automatic

This parameter determines the maximum memory used by the database heap. It contains control block information for tables, indexes, tablespaces, and buffer pools. It also contains space for the log buffer and temporary memory used by utilities.

SORTHEAP Automatic This parameter defines the maximum number of private memory pages to be used for private sorts, or the maximum number of shared memory pages to be used for shared sorts. The memory tuner dynamically adjust the size of the memory area controlled by this parameter as the workload requirements change.

SHEAPTHRES_SHR Automatic This parameter represents a soft limit on the total amount of database shared memory that can be used by sort memory consumers at any one time. The memory tuner dynamically adjust the size of the memory area controlled by this parameter as the workload requirements change.

45

Parameter Value ExplanationLOCKLIST Automatic This parameter indicates the

amount of storage that is allocated to the lock list. There is one lock list per database and it contains the locks held by all applications concurrently connected to the database. The memory tuner dynamically adjust the size of the memory area controlled by this parameter as the workload requirements change.

MAXLOCKS Automatic This parameter defines a percentage of the lock list held by an application that must be filled before the database manager performs lock escalation. The memory tuner dynamically adjust the size of the memory area controlled by this parameter as the workload requirements change.

NUM_IOCLEANERS Automatic This parameter allows you to specify the number of asynchronous page cleaners for a database.

NUM_IOSERVERS Automatic This parameter specifies the number of I/O servers for a database.

PCKCACHESZ Automatic This parameter is allocated out of the database shared memory, and is used for caching of sections for static and dynamic SQL and XQuery statements on a database. The memory tuner dynamically adjust the size of the memory area controlled by this parameter as the workload requirements change.

46

Parameter Value ExplanationAUTO_MAINT On This parameter is the parent of

all the other automatic maintenance database configuration parameters.

AUTO_TBL_MAINT On This parameter is the parent of all table maintenance parameters.

AUTO_RUNSTATS On This automated table maintenance parameter enables or disables automatic table runstats operations for the database. Statistics collected by the runstats utility are used by the optimizer to determine the most efficient plan for accessing the physical data.

The hints and tips for TPC mention that running runstats manually is recommended. With AUTO_RUNSTATS on this is no longer recommended.

3.2.3 References to DB2 configuration parameters

For reference see the configuration parameters summaries for DB2 9.7, 9.5, and 9.1.

DB2 9.7 configuration parameters summary http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.admin.config.doc/doc/r0005181.html

DB2 9.5 configuration parameters summaryhttp://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.admin.config.doc/doc/r0005181.html

DB2 9.1 configuration parameters summary http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r0005181.htm

47

4 Optimizing use of physical storage for DB2 databases

The most recent TPC version 4.2 only uses one database as repository: TPCDB.

By default, the TPC 4.2 database and its DB2 transaction log files are stored on the same filesystem. You can achieve performance improvements by placing the transaction log files onto a separate disk.

While the ratio of log physical disks to data physical disks is heavily dependent onworkload, a good rule of thumb is to use 15% to 25% of the physical disks for logs, and 75% to85% of the physical disks for data.

4.1 Placing the DB2 transaction logs onto a separate disk

On a Windows system chose as target directory a directory on a separate disk. On Linux/Unix choose as target directory a directory under a mount point of the separate disk.

Example: To move the logs for the TPCDB database to a new location, use the following steps:

1. Shutdown the TPC services: TPC data server service, TPC device server service

2. Choose a new log path location, for example, E:\DB2_logs\TPCDB(make sure that the target directoiry exists).

3. Start a DB2 command line processor(see illustrations below)

Illustration 12: DB2 Command line processor window

4. Issue the following commands in the window:

48

connect to database_name

update db cfg for database_name using NEWLOGPATH target_directory_of_new_disk

Where database_name is the name of the database ( e.g. TPCDB) and target_directory_of_new_disk is the path to which you want to relocate the logs.

Restart DB2 in order to activate the change. You can use db2stop and db2start, or the DB2 control center in order to restart the database instance. A reboot does the trick as well.

5. Start the TPC services again: TPC data server service, TPC device server service

The DB2 logs for the TPC database repository are now stored on a different physical disk than the corresponding tablespaces. This will lead to performance improvements during TPC DB operation.

4.2 Setting the DB2 database on separate disk

With a high workload on TPC ( possibly due to many performance jobs or probes ) and improper settings of resource history retention that keep too much data, you may find yourself with a very large database. Sometimes the database is so large that it fills the entire free space of a filesystem (partition). In this case the user must clean up the repository or move it to a new filesystem. The next steps will show how the TPC repository can be moved to another partition ( for this example, move TPCDB from C: partition to D: partition ):

1. Verify that the partition you want to move the repository to has enough free space for the database and for the database backup.

2. Stop the TPC services (TPC data server service, TPC device server service). Wait for them to completely stop.

3. Create a snapshot of the current configuration: (This step is optional.)

1. Create a file called summary.cmd with the following lines.database_name is the repository name ( e.g. TPCDB ):

LIST DB DIRECTORYconnect to database_name

49

get snapshot for tablespaces on database_name LIST TABLESPACES SHOW DETAILget db cfg for database_name

2. Start DB2 Command Window by using Start Menu or use simply the command “db2cmd”:

Illustration 13: Start Menu Path to DB2 Command Window

3. From the DB2 Command Window navigate to where summary.cmd was created.4. Run the command: db2 -f summary.cmd -vz summary-log-old.txt

4. Backup the current TPC database (This step is mandatory, so that in case something goes wrong the repository can be restored easily from the backup):1. Create the folder where you will backup the database. For example D:\db2backup2. From the DB2 Command Window navigate to D:\db2backup and run the following

commands:

db2connect to database_namedb2move database_name export(This may take a while depending on the size of the database.)

5. Stop the DB2From the DB2 Command Window previously opened run: db2stop force

6. Copy specific directories from C: to D:1. Navigate to C:\DB2\NODE0000\ and Copy SQL00001 directory with all its content to

D:\DB2\NODE0000\ . The new location will look like D:\DB2\NODE0000\SQL000012. Navigate back to C:\DB2\NODE0000\ and Copy TPCDB directory with all its content

to D:\DB2\NODE0000\ . The new location will look like D:\DB2\NODE0000\TPCDB3. Navigate back to C:\DB2\NODE0000\ and Copy SQLDBDIR directory with all its

content to D:\DB2\NODE0000\ . The new location will look like D:\DB2\NODE0000\SQLDBDIR

4. Copy directory C:\DB2\TPCDB to D:\DB2\ .

Note: There might be more than one SQL0000x folders ( e.g.. SQL00001, SQL00002, and so on ). To find out in which one reside TPCDB (the one that needs to be moved), run the following command from DB2 Command Window:

list db directory on C:

50

7. Create a file called TPCDB.cfg with the following content:

DB_NAME=TPCDBDB_PATH=C:\,D:\INSTANCE=DB2STORAGE_PATH=C:\,D:\

Note: This configuration file is used by the db2relocatedb command. The configuration parameters listed above are required for the command to work, but the configuration file can have the following additional parameters:

DB_NAME=oldName,newNameDB_PATH=oldPath,newPathINSTANCE=oldInst,newInstNODENUM=nodeNumberLOG_DIR=oldDirPath,newDirPathCONT_PATH=oldContPath1,newContPath1CONT_PATH=oldContPath2,newContPath2…STORAGE_PATH=oldStoragePath1,newStoragePath2STORAGE_PATH=oldStoragePath2,newStoragePath2…FAILARCHIVE_PATH=newDirPathLOGARCHMETH1=newDirPathLOGARCHMETH2=newDirPathMIRRORLOG_PATH=newDirPathOVERFLOWLOG_PATH=newDirPath…

This is the description of the parameters:

DB_NAMESpecifies the name of the database being relocated. If the database name is being changed, both the old name and the new name must be specified. This is a required field.

DB_PATHSpecifies the original path of the database being relocated. If the database path is changing, both the old path and new path must be specified. This is a required field.

INSTANCESpecifies the instance where the database exists. If the database is being moved to a new instance, both the old instance and new instance must be specified. This is a required field.

NODENUMSpecifies the node number for the database node being changed. The default is 0.

51

LOG_DIRSpecifies a change in the location of the log path. If the log path is being changed, both the old path and new path must be specified. This specification is optional if the log path resides under the database path, in which case the path is updated automatically.

CONT_PATHSpecifies a change in the location of tablespace containers of type Database Managed Space or System Managed Space. Both the old and new container path must be specified. Multiple CONT_PATH lines can be provided if there are multiple container path changes to be made. This specification is optional if the container paths reside under the database path, in which case the paths are updated automatically. If you are making changes to more than one container where the same old path is being replaced by a common new path, a single CONT_PATH entry can be used. In such a case, an asterisk (*) could be used both in the old and new paths as a wildcard.

STORAGE_PATHThis is only applicable to databases with automatic storage enabled. It specifies a change in the location of one of the storage paths for the database. Both the old storage path and the new storage path must be specified. Multiple STORAGE_PATH lines can be given if there are several storage path changes to be made. You can verify if automatic storage is enabled by launching DB2 Control Center and navigate to the details of the tablespace containers.

FAILARCHIVE_PATHSpecifies a new location to archive log files if the database manager fails to archive the log files to either the primary or the secondary archive locations. You should only specify this field if the database being relocated has the failarchpath configuration parameter set.

LOGARCHMETH1Specifies a new primary archive location. You should only specify this field if the database being relocated has the logarchmeth1 configuration parameter set.

LOGARCHMETH2Specifies a new secondary archive location. You should only specify this field if the database being relocated has the logarchmeth2 configuration parameter set.

MIRRORLOG_PATHSpecifies a new location for the mirror log path. The string must point to a path name, and it must be a fully qualified path name, not a relative path name. You should only specify this field if the database being relocated has the mirrorlogpath configuration parameter set.

OVERFLOWLOG_PATHSpecifies a new location to find log files required for a rollforward operation, to store active log files retrieved from the archive, and to find and store log files required by the db2ReadLog API. You should only specify this field if the database being relocated has the overflowlogpath configuration parameter set.

52

Blank lines or lines beginning with a comment character (#) are ignored.

8. From the DB2 Command Window previously opened navigate to the TPCDB.cfg file and run the following command:

db2relocatedb -f TPCDB.cfg

This command will relocate the TPC repository from and to the drives specified in the TPCDB.cfg file.After the command completes you should see the following output:

Files and control structures were changed successfully.Database was catalogued successfully.DBT1000I The tool completed successfully

9. From the DB2 Command Window run db2start command to start the DB2.

10. Verify current configuration. This step is optional:1. From the DB2 Command Window navigate to the summary.cmd file created in step 3

and run the following command:db2 -f summary.cmd -vz summary-logs-new.txt

2. Compare summary-logs-new.txt with summary-logs-old.txt. The DB2 configuration parameters should be the same other than the differences related to the DB2 path.

11. Delete the folders copied in step 6 from the original partition( C:). This will release the disk space occupied with the original location of the repository.

12. Start the TPC Services.

Notes:

The db2relocatedb command cannot be used to move a TPC database that has been created with the option “Automatic Storage” under the database creation details in the custom installation path of the TPC installer. For “Automatic Storage” a simpler solution exist to move the database to a different disk.

Note that it's possible to expand a “autonomic storage” database with an additional disk.

Also traditional tablespaces managed by database can be expanded with an additional disk by placing additional tablespace containers onto the additional disk.

The administrative view sysibmadm.dbpath shows which type of storage an existing database uses. E.g. type “DB_STORAGE_PATH” is “Automatic Storage”. Refer also to the DB2 information center.http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.sql.rtn.doc/doc/r0022037.html

53

4.2.1 Moving an “Automatic Storage” database to one or more different disks

This can be done with fewer steps then in section 4.2 as a backup/restore operation. Still an offline maintenance window is required. The database backup should be kept in a safe location to be able to restore the database.

Steps are the following.

1. Make sure the database uses “Automatic Storage” by looking at the administrative view sysibmadm.dbpath.

2. Stop the TPC services (TPC data server service, TPC device server service). Wait for them to completely stop.

3. Backup the database.

4. Drop the database.

5. Restore the backup image to new storage paths. Use the “ON” parameter to specify the refined storage paths. Use the “NEWLOGPATH” parameter to specify the refined location for the active log files.

6. Start the TPC services.

Example: In order to move an “Automatic Storage” database tpcdb from a Windows C: drive to drives F: and G: for the tablepaces and to L:\db2_log for the active log files the DB2 related commands are the following if the folder D:\db_backup has enough space for the database backup.

1. db2 backup db tpcdb to D:\db_backup2. db2 drop db tpcdb3. db2 restore db tpcdb from D:\db_backup on F:,G: newlogpath L:\db2_log

4.2.2 Expanding an “Automatic Storage” database with an additional disk

This can be done online while TPC operates. One or more additional storage paths are added to the database. Automatic storage tablespaces use the new storage path(s).

Steps are the following.

1. Make sure the database uses “Automatic Storage” by looking at the administrative view sysibmadm.dbpath.

54

2. While connected to the database issuedb2 alter database add storage on storagePathListwhere storagePathList is a comma separated list of storage paths.

Example: In order to expand the database tpcdb on a Windows C: drive to the drive D: the DB2 commands are the following.

1. db2 connect to tpcdb2. db2 “select * from sysibmadm.dbpath” and make sure the type “DB_STORAGE_PATH” is

listed but not types “TBSP_DEVICE”, “TBSP_CONTAINER” or “TBSP_DIRECTORY”.3. db2 alter database add storage on D:

4.2.3 Expanding “Database managed (DMS) tablespaces” with an additional disk

This can be done online while TPC operates. New tablespace containers are added to a tablespace. The new containers reside on the additional disk.

Steps are the following.

1. Make sure the tablespace uses traditional DMS file base tablespace containers by listing the tablepace containers and looking them up in the administrative view sysibmadm.dbpath. They have type “TBSP_CONTAINER”.

2. While connected to the database issuedb2 “alter tablespace tablespaceName add (file 'filePath' size)”where tablespaceName is name of the tablespace to be extended, filePath the name of the file to be added, size the size of the file to be used.

Example: In order to expand the DMS tablespace tpctbsppm in database tpcdb by 250 MB onto a Windows drive D: with the new tableapace container file D:\tpcdb\tpctbsppm.2 the DB2 commands are the following.

1. db2 connect to tpcdb2. db2 list tablapaces (record the “Tablespace ID” for the tablespace tpctbsppm, it's 4 for the

example)3. db2 list tablespace containers for 44. db2 “select * from sysibmadm.dbpath” and make sure the listed containers have type

“TBSP_CONTAINER”5. db2 “alter tablespace tpctbsppm add (file 'D:\tpcdb\tpctbsppm.2' 250M)”

55