DB2 Warehousing Design Best Practices

Transcription

1 Platform: DB2 UDB for Linux, UNIX, Windows DB2 Warehousing Design Best Practices Bill O Connell, Ph.D., IBM Toronto Lab DB2 Chief BI Architect Session: E13 Wednesday, Oct / 4:15 5:15pm 1

2 Agenda Balanced Configuration Unit (BCU) Overview; purpose, Terminology, and definition Mapping to AIX and Linux Configurations Virtual Mart and ODS consolidation into an EDW Layered Warehouse design Continuous and Trickle feed (in presence of MQTs) Balancing Warehouses designs for Scalability General Do s and Don ts 2 2

3 What is a Balanced Configuration Unit (BCU)? Minimum replicable HW/SW stack necessary to start or expand the infrastructure of a Business Intelligence (BI) system. Provides a scalable performance ratio of disk I/O to memory to CPU to network A prescriptive approach for building data warehouse infrastructure Data Warehouse pseries Server pseries Server pseries Server cpu 1 cpu n-1 cpu 1 cpu n-1 cpu 1 cpu n-1 memory memory memory cpu 2 cpu n cpu 2 cpu n cpu 2 cpu n I/O Channels I/O Channels I/O Channels BCU 1 BCU 2 BCU N 3 3

4 Guiding Design Principles The BCU has been guided by these key design principles which were validated with the field and our largest BI customers: Price to performance ratio Stability Fault tolerance High availability Ease of installation and implementation Packaging density Balanced performance Scalability Industry-standard components Minimize solution permutations 4 Balanced performance. The components that make up the Linux BCU have been chosen for their performance characteristics, and balanced with the other components in the design. Stability. Components have been chosen that are either successfully in use in production environments today, or have undergone rigorous lab testing and been judged stable enough for customer use. Fault tolerance. Where possible, components have been chosen to provide fault tolerance, recognizing that the xseries product line does not have all of the fault tolerant features available in pseries. However the small granularity and cost associated with the xseries solution lends itself to fault tolerance through complete server replacement or hot standby. Network, SAN, and storage components have been selected with fault tolerance in mind. High availability. If required, high availability is provided at the server level through the hot-standby implementation. The low granular cost of the xseries solution makes this a viable solution for the Linux BCU. Ease of installation and implementation. The Linux BCU design has been chosen to facilitate ease of installation, implementation, and manageability. Because of this principle, certain cluster management and monitoring tools over others are recommended over others. Scalability. The scalability of the Linux BCU solution is addressed via scale-out of the server and storage rather than scaling up using the spare capacity within each BCU. In addition, scalability has been made as simple as possible. Price to performance ratio. The price to performance ratio has been considered a primary design principle rather than a secondary consideration (as in the case of the pseries BCU). Customers considering a Linux BCU will be doing so predominantly because of the attractive price-to-performance characteristics of this solution. Packaging density. Components have been chosen with the objective of minimizing the footprint via packaging density of the Linux BCU. Industry-standard components. Components have been chosen that are considered industry standard. This decision will enable customers to use the Linux BCU as a blueprint for developing Linux BCU data warehouses from non-ibm hardware, if required. Minimize solution permutations. To minimize the support and testing impact of the Linux BCU, the hardware and software permutations and options will be kept to a minimum. Only a small subset of the DB2 ICE components will be used. 4

5 Why do we need a Balanced Configuration Unit? Move towards more Black Box (yet using open components) Implementation Standards and Consistency Reduce Complexity GOAL: Reduce time to deploy (get to ROI sooner), lower total cost of ownership (TCO), and improve overall customer satisfaction for IBM Data Warehouse infrastructures. 5 5

6 DB2 Shared Nothing Architecture Partitioned Database Model Database is divided into multiple partitions Database Partitions can run on different nodes Each Database Partition has dedicated resources (Engine, Log Manager, Lock Manager, Caches, etc.) Parallel Processing occurs on all partitions and is coordinated by the DBMS Single system view to user and application Fast Communication Manager Database Partition data log data log data log data log Data Log 6 6

7 DB2 Database Topology CPU MEM high-speed network CPU MEM CPU MEM CPU MEM MPP many servers, each with a single cpu and operating system table CPU CPU MEM CPU CPU CPU CPU CPU high-speed network CPU CPU CPU CPU CPU MEM MEM table SMP - many cpus in a single server with one operating system table Cluster - many servers where each server is an SMP server 7 7

8 BCU Flavors ETL End Users DS4500 DS4500 DS4500 DS4500 SAN pseries pseries pseries pseries Scalable Interconnect pseries pseries pseries pseries SAN DS4500 DS4500 DS4500 DS4500 DB2 DB2 8 In a total data warehouse design, there are applications other than just the database that need to be accounted for in terms of processing and IO power. Those usually involved getting data into the database (e.g. ETL) or getting data out of the database (end user applications such as Microstrategy, Business Objects, Brio, etc.) as well as facilities to to do backup/recovery. Due to platform selections for those applications, they may or may not require additional BCUs to be added to the data warehouse design. If they are to be included, a BCU approach should be taken as well for these applications. 8

9 BCU Terminology Layer Term Definition HA-BCU 1 2:n BCU 1 1:n BPU High Availability Balanced Configuration Unit Provides a complete high availability solution by adding automated server fail-over (HACMP) to the BCU layer Requires defining a fail-over configuration relationship between BCUs. Balanced Configuration Unit A single operating system image, either provided via an LPAR or individual server. A number of BCU types exist to deliver different distinct functions to the overall architecture e.g. Data, Admin, etc. This will be the top layer of an implementation where only a single BCU is required, or HACMP is not a requirement Details the individual hardware components that are required to deliver balanced performance. Balanced Partition Unit The BPU is used to refer to the resources required or used by a single DB2 Partition, and for this reason is useful to use as a basis for estimating overall system size. This is the lowest level of detail for BCU architecture and only exists for BCU types that are dedicated to DB2 9 9

10 Balanced Partition Unit (BPU) The Balanced Partition Unit is a DB2 with DPF concept and primarily refers to the resources that are required to service a DB2 Partition Data BPU A DB2 data partition dedicated to storing database data. Coordinator BPU The DB2 coordinator partition that manages connections and coordinates a query. Catalog BPU The partition of the database under which the DB2 Catalog primarily resides. This will also be a coordinator BPU too Although a single DB2 partition can service all these types/usages it is good practice in database design to use separate database partitions for each of these 10 10

11 Balanced Configuration Unit (BCU) The Balanced Configuration Unit can be one of a number of types, each fulfilling a different function within the Data warehouse environment Data BCU a collection of DB2 database partitions that is dedicated to managing and processing a part of the data within the Database. Admin BCU a collection of DB2 database partitions encompassing the DB2 Catalog and Coordinator partitions. ETL BCU BCU that is responsible for processing all (or an element) of the extract, transformation and load work for the Data Warehouse. This typically infers use of a third-party ETL tool or customers bespoken ETL programs. Each of these different BCUs supports different workloads and therefore can be expected to be configured differently

12 ETL BCU Dedicated ETL server scenarios: Scenario one Standalone ETL server without local coordinator partition, and without data presplitting Scenario two Standalone ETL server without local coordinator partition, and with data pre-splitting Scenario three Distributed ETL processing; ETL server plus ETL processes local to the database partitions, and with data pre-splitting T R A N S F DB2 ETL Best Practice To ease the burden of workload management for ETL, use a separate server or LPAR exclusively for ETL. For the BCU, it is recommended that this separate set of resources be the ETL BCU. Note: For ETL sizing, the tool vendor should be involved to provide specific guidelines and references

13 Administration BCU Configuration The Administration BCU would have the following DB2 functions: Administration BPU Catalog function Coordinator function Single partition data (small tables) When Query Patroller (QP) is implemented, the QP control tables would reside on this partition Administration BCU 1 Administration BPU Catalog Coordinator Single Partition Data Query Patroller 13 13

14 In Building System, We Start with a Balanced Partition Unit (BPU) A BPU is defined as 1 DB2 Partition and the resources associated with it. DB2 Data Partition DB2 Agents CPUs for DB2 Agents Memory for DB2 Agents Storage for Partition Data Sizing a system starts at the BPU level!!! Rules of thumb exist for each BPU type BPU Configuration specific to each BCU Type Admin Data ETL Data BPU 1 DB2 Data Partition DB2 Agents CPU Memory - Bufferpool Communication I/O Channels Storage Capacity BPU 14 14

15 Build up multiple BPU s to define the Balanced Configuration Unit A single operating system image, either provided via an LPAR or individual server and the resources associated with it. AIX, p5-575 Data BCU: 8 BPUs 32GB memory 8 Power5 processors Single AIX OS image Dedicated Modular Storage Data BCU 8 BPUs AIX OS image 8 CPUs 32GB of memory Communication I/O Channels Storage Capacity Power5 BCU 15 15

16 BPU Mapping to Physical Computing Resources The mapping of DB2 partitions on a physical machine with a defined balance of compute resources for each partition leads us to the defining the Balanced Configuration Units (BCUs) Preferred BCU Solution for a Data Warehouse using DB2 with DPF Partitions Administration BCU DB2 Data BCU DB2 Data BCU Multi-partition Data Multi-partition Data Multi-partition BPU 1 Data Multi-partition Catalog BPU BPU 1 Data Multi-partition BPU 1 Data Multi-partition BPU 1 Data 1 Administration BPU Multi-partition BPU 1 Data Multi-partition BPU 1 Data Multi-partition BPU 1 Data Multi-partition BPU 1 Data Multi-partition BPU 1 Data Multi-partition BPU 1 Data Catalog Multi-partition Coordinator BPU 1 BPU 1 Data Multi-partition BPU 1 Data Multi-partition Coordinator BPU 1 Data Multi-partition BPU 1 Data BPU 8 BPU 8 Single-Partition Data Single-partition Data DB2 Data BCU DB2 Data BCU BPU 1 Multi-partition Data Multi-partition Data Multi-partition BPU 1 Data Multi-partition BPU 1 Data Multi-partition Non- DB2 ETL BPU 1 Data Multi-partition BPU 1 Data Multi-partition BPU 1 Data Multi-partition Multi-partition BPU 1 Data BPU 1 Data Multi-partition BPU 1 Data Multi-partition Coordinator BPU for BPU 1 Data Multi-partition BPU 1 Data Multi-partition Non-DB2 ETL BPU 1 Data Multi-partition Multi-partition BPU 1 Data BPU 1 Data Multi-partition BPU 1 Data BPU 8 BPU

17 I1 AIX Data BCU Building Block Approach 8-way p GHz Total RBI estimation is 10.0 At least 32 GB Memory (DDR1) Expect concurrency limited to medium to complex jobs 2 Internal 73 GB drives for paging space and rootvg volume group 2 drives for mirroring paging space and performance 8 DB2 Partitions 2 GB Ethernet Adapters for DB2 FCM 2 Integrated Ethernet ports for Corporate Network 2 Integrated HMC ports for Administration HMC is required with the p Fibre Channel Adapters for Backup / Restore 8-port async adapter for HACMP heartbeat (if HACMP implemented) ½ Bonnie & Clyde XG I/O Drawer (Feature Code #5794) 10 slots for adapter cards 17 Includes cpu, memory, network, partition setup, backup restore, etc. - What is missing? Storage Configurations Why? Different workloads can require a different balance of cpu to storage performance. The way to address a range of performance balance is to fix the cpu performance and vary the ranges of storage performance. 17

18 Slide 17 I1 Don't review the details of the bullets. Emmphasize that each BCU has the same configuration for: cpu performance memory communications backup/restore What's missing? Storage. Why? different workloads will have different performance balance. This is way to address. IBM_USER, 1/9/2005

19 I2 Balancing the Touch Points AIX Storage Variations Touch points are Memory, CPU, I/O, Disk, et al Also balance between Price and Price / Performance BCU Configuration BCU #1 Std Workloads BCU #2 Heavy Workloads Workload Type Typical, ~20 mixed and complex queries Heavily mixed workload w/ Random I/O or ODS IO thruput (MB/sec) < 600 < 1200 IOPS (IOs/sec) 12,000 24,000 # DS4500 Storage Servers 1 2 # EXP710 Storage Enclosures 6 12 # FC Adapters for Storage 4 8 # Useable Disks (@ 73GB) Useable Storage (RAID-5 in GB)

20 Slide 18 I2 Emphasize: - BCU #1 and #2 have same MB/sec - BCU #3 and #4 have 2x MB/sec MB/sec is increased by increasing DS4500 and FC adapters BCU #1 and #2 have different IO/sec because different number of disks IBM_USER, 12/22/2004

21 NEW TPCH RESULT!! DB2 outperforms Oracle in 10TB TPC-H DB2 leads Oracle by 16% with ¼ the CPUs (DB2 on 4 8ways vs Oracle on 2 64ways) DB2 leads Oracle by 2x with ½ the CPUs (DB2 on 4 8ways vs Oracle on 64way) DB2 leads in Price/Performance over 10g and RAC by a wide margin DB2 Leads 10TB TPC-H Performance with fewer CPUs DB2 Leads 10TB TPC-H price/performance QphH@10000GB $/QphH@10000GB Higher is Better DB2 v8.2 (4 8w ays) Oracle 10g RAC (2 64w ays) Oracle 10g (1 64w ay) Results current as of May 18, 2005, See Appendix for details. Check for latest results 19 Lower is Better DB2 v8.2 (4 8w ays) Oracle 10g RAC (2 64w ays) Oracle 10g (1 64w ay) 19

22 System Overview Balanced Configuration Unit (AIX) DB2 Data HA-BCU DB2 Data HA-BCU Hardware Management Console (HMC) EXP700 EXP710 Disk Drives DS4500 -Storage Controller EXP700 EXP710 Disk Drives DS Controller Storage EXP700 EXP710 Disk Drives DS Controller Storage Storage Area Network Switch Fabric EXP700 EXP710 Disk Drives DS Controller Storage IBM IBM p5-p575 p570 8 x 1.9GHz CPUs 32GB memory DB2 V8 64 bit AIX V5.3 HACMP IBM p5-p575 p570 8 x 1.9GHz CPUs 32GB memory DB2 V8 64 bit AIX V5.3 HACMP IBM IBM p5-p575 p570 8 x 1.9GHz CPUs 32GB memory DB2 V8 64 bit AIX V5.3 HACMP IBM p5-p575 p570 8 x 1.9GHz CPUs 32GB memory DB2 V8 64 bit AIX V5.3 HACMP Corporate Network Cisco Cisco Gb Ethernet Gb Ethernet Non-blocking Non-blocking Switch Switch CommonSAN Switch Fabric IBM IBM p5-p575 p570 LPAR 2 x 1.9GHz CPUs 16GB memory DB2 V8 64 bit AIX V5.2 HACMP IBM IBM p5-p575 p570 LPAR 2 x 1.9GHz CPUs 16GB memory DB2 V8 64 bit AIX V5.2 HACMP IBM p5-p575 p570 8 x 1.9GHz CPUs 32GB memory DB2 V8 64 bit AIX V5.3 HACMP IBM IBM p5-p575 p570 8 x 1.9GHz CPUs 32GB memory DB2 V8 64 bit AIX V5.3 HACMP Storage Area Network Switch Fabric DS Controller Storage DS Controller Storage DS Controller Storage DS4500 -Storage Controller EXP700 EXP710 EXP700 EXP710 Disk Drives Disk Drives AdministrationHA-BCU EXP700 EXP710 EXP700 EXP710 Disk Drives Disk Drives DB2 Data HA-BCU 20 20

23 Linux BCU Configuration #1 Tin IBM xseries 346 Intel CPU 3.2 Ghz 8x 512 MB RAM DDR1 6 disks 146GB SCSI disks RAID (ServeRAID 7K 256 MB DIMM option) GB RAW data Connectivity with onboard GB Ethernet Adapters Or Infiniband for large clusters > 32 nodes Excellent scalability for ultra low price point No high availability or redundancy besides redundant power and RAID disks Optional IO Upgrade to add additional IO capability 14 additional 146GB SCSI disks to improve concurrency 21 21

24 NEW TPCH RESULT!! 1 TB Linux BCU #1 TPC-H on DB2 ICE cluster Compared to Oracle RAC QppH, QthH, QphH QppH QthH QphH $/Qp $/QphH DB2 ICE on x346 cluster Oracle RAC on HP cluster 52% better performance than Oracle RAC solution 45% cheaper from price/perf perspective We loaded the 1TB database in under an hour, compared to >4 hours for Oracle RAC

25 Linux BCU #2 Gold X346 (Intel) or e326 (AMD) 2 GB Fibre Channel Cards DS4300 Storage 2U 3U x346 DS4300 1U 3U e326 DS4300 3U EXP700 3U EXP700 Considerations The enterprise configuration High Availability FC based with HA SAN deployment capable, tape backup integration through FC, Interconnect is either 1GB Ethernet for or InfiniBand for large scale clusters (> 32 nodes ) 23 23

26 System Overview Linux Balanced Configuration Unit Architecture DB2 Data HA-BCU DB2 Data HA-BCU Administration Console EXP700 Disk Drives DS4500 DS4300 -Storage Controller EXP700 Disk Drives DS4500 DS Controller Storage EXP700 Disk Drives DS4500 DS Controller Storage EXP700 Disk Drives DS4500 DS Controller Storage Storage Area Network Switch Fabric IBM p570 x x x 1.9GHz 3.6GHz CPUs 32GB 8GB memory DB2 V8 64 bit Linux AIX 2.4 V5.3 kernel HACMP TSA IBM p570 x x 1.9GHz 3.6GHz CPUs 32GB 8GB memory DB2 V8 64 bit Linux AIX 2.4 V5.3 kernel HACMP TSA IBM p570 x x 1.9GHz 3.6GHz CPUs 32GB 8GB memory DB2 V8 64 bit Linux AIX 2.4 V5.3 kernel HACMP TSA IBM p570 x x x 1.9GHz 3.6GHz CPUs 32GB 8GB memory DB2 V8 64 bit Linux AIX 2.4 V5.3 kernel HACMP TSA Corporate Network Cisco Cisco Gb Ethernet Gb Ethernet Non-blocking Non-blocking Switch Switch CommonSAN Switch Fabric IBM p570 x x x 1.9GHz 3.6GHz CPUs 32GB 8GB memory DB2 V8 64 bit Linux AIX 2.4 V5.3 kernel HACMP TSA IBM p570 x x 1.9GHz 3.6GHz CPUs 32GB 8GB memory DB2 V8 64 bit Linux AIX 2.4 V5.3 kernel HACMP TSA IBM p570 x x 1.9GHz 3.6GHz CPUs 32GB 8GB memory DB2 V8 64 bit Linux AIX 2.4 V5.3 kernel HACMP TSA IBM p570 x x x 1.9GHz 3.6GHz CPUs 32GB 8GB memory DB2 V8 64 bit Linux AIX 2.4 V5.3 kernel HACMP TSA Storage Area Network Switch Fabric DS4500 DS Controller Storage DS4500 DS Controller Storage DS4500 DS Controller Storage DS4500 DS Storage Controller EXP700 EXP700 Disk Drives Disk Drives AdministrationHA-BCU EXP700 EXP700 Disk Drives Disk Drives DB2 Data HA-BCU 24 24

27 System Growth and Server Failover Admin BCU 1 Admin BCU 2 Admin BCU 2 Data BCU 1 Data BCU 2 Data BCU 3 Data BCU 4 Data BCU 5 Data BCU N-1 Data BCU N Legend Combined Coordinator, Catalog and Single Partition Data BPU Coordinator BPU Multi Partition Data BPU 25 25

28 Building for Agility Application Neutral Design Marts via Logical Views (Logical Data Marts) MQTs supports Marts Floor 4 Floor 1 Floor 2 Floor 3 Floor 5 Dashboard Static reports, Fixed Periods Dimensional, Data Mart, Cubes, Duration: Years Summarized Data Performance and rolled up Data Duration: Years EDW Physically built on lower floors Near 3 rd Normal Form, Subject Area, code and Reference tables. Duration: Years Staging, detail, denormalized, Raw Source Duration: 60, 120, 180, etc days Floor 0 Operational Systems Duration: 60, 120, 180, etc days 26 26

29 Interaction Application Data Marts (LOB Apps) Atomic Data (normalized) EDW Logical and or Physical Mart layer (a.k.a., upper floors) ODS / Staging Layer ETL Operational systems 27 27

30 Workload Management and Priority Scheduling Complex Strategic Queries Short Tactical Queries Trickle Updates Query Manager EDW DB2 Query Patroller DB2 Governor I/O Prioritization 28 28

31 Sample MQT Cube Hierarchy on Floor 4 Dealing with Data Rollin in and Roll out Product Period Class Period Dept Period Product Weekly Class Weekly Dept Weekly Rollin / Rollout Periods Product Daily lvl Class Daily Lookup Base table Dept Daily 29 29

32 Balancing DB2 Configurations DB2 Distribute all partitioned database objects uniformly over all disks Assign equal number of physical disks to each data partition Use a one-to-one mapping of physical disks to partitions A physical disk belongs to only one partition Ensures maximum workload balancing For tables & indexes use DMS File with JFS2 by default for Perm Use CIO with DMS File Temp space, use SMS Start with one buffer pool DB2 delineates between prefetched pages & single pages 16KB page sizes is a good for many DB2 uses 30 Evenly spread data, indexes, temp, database path, logs across all disks. - Isolate physical disks to partitions, reduces disk head contention - if there is unbalanced performance - very easy to isolate data skew, hardware, etc. - we frequently find h/w problems (io adapters, disks, etc) before the h/w support does because we can see an imbalance. - Use large LUNs. Do not use O/S to mask the underlying luns - use multiple containers - one container per LUN for DMS raw. - Each LUN has data, indexes, temp, database path, and logs on the disks. 4. Tablespaces for data and indexes are DMS raw only. - There is a problem with AIX 5, JFS, JFS2, DB2 interaction. Until this is fully understood and resolved - use DMS raw containers - period. Avoid all complications of JFS, DB2 interaction, VMM file system caching, inode locks, etc., etc Use SMS for temporary space - but this needs continued evaluation. - Would not be surprised to find DMS raw best for temp also. Issue is OLTP sorts - DMS temp can be terrible for short sorts. But large sorts are fine. Large reorgs are much better (Sprint as example). - Use JFS - Use multiple containers on a LUN - at least one container per 2 physical disks - one container per 1 physical disk is probably better. Addresses inode lock contention and 64 GB file size limit in JFS. 6. Minimize page sizes. - 8K page size is a good compromise for everything. Larger page sizes are ok, but have to use a smaller temp page size. 7. Extent size is always 16 - there are no I/O concurrency advantages of a larger size (at least today because of the readv of 16 pages max) 8. Prefetch is always a multiple of underlying number of physical disks and extent sizes 30

33 BCU Flavors ETL, OLAP, BI users, etc. Use the DB2 BCU configuration for BCU flavors Recruit the ISV providing software to configure ETL BCU - Ascential, Informatica, Business Objects, Cognos, etc. End User BCUs BI Tools & Applications Application focus (Cognos, SAS, Java, etc.) Concurrency = large memories, large CPU burn rate Spin off marts BCU MOLAP engines, dependent data marts Separate Database (unless building layered architecture) 31 For the DB2 database BCUs, one field-proven design approach is to have data BCUs which are in essence the BCUs/nodes where the data and data partitions reside and have separate BCUs for a load/control function. The Load/Control BCU would contain the DB2 catalog and potentially be the query coordinators for the query workload as well as the DB2 load splitters for ETL work. The purpose of separating these functions is that the processing, IO and networking requirements are different for each of these functions (Data versus Load/Control). Usually the Data BCU design will be the most powerful in terms of processing, memory, IO and networking requirements. A safe approach would be to use this BCU design for all BCU types, if there is uncertainty about specific application requirements. This would also add costs to the design, but the customer would not necessarily have to later identify and upgrade hardware components in the middle of their data build out, adding to the delay and visibility of the project at a critical time 31

34 Do s Best Practices Build balanced symmetrical DB configurations Keep it simple Identify & maintain correct ratio of disks to I/O to Server to CPU to Memory Once the BCU ratios are defined, stick with it Always design for HA in cluster configurations Be ready to add HA fail over if not deployed initially Set AIX & DB2 configuration parameters right DB2 configuration advisor will help a lot 32 This slide is self-explanatory. Please see slide 34 for contacts. 32

35 DB2 Partition Rules of Thumb for AIX Per DB2 Partition Typically 200+ GB Active Raw Data GB Raw Data 1 DB2 partition per CPU (Power 5 processor) 4 GB Memory Server 1 GB Ethernet Adapter per 4 CPUs One 2 Gb Fibre Channel Adapter per 2 CPUs Storage 1 Storage Server (DS4500) per 8 CPUs Minimum 8 disks at RPM; > 12 is more balanced Total Storage Capacity = 3 to 4 x Raw Data Balance storage & IO requirements Mainstream disk choice - 73Gb 146Gb only where large amount of the data is inactive TIP: Please refer to the rules of thumb for BCUs and BPUs for additional detailed information related to IBMs latest hardware offerings. 33 Balance Originates from Average Workloads The ROT above our oriented towards a Power 5 pseries processor serving as the processor for the Data Partition. These RoT are intended to represent an average at this point in time. We intend through performance testing work we do with BPU/BCU to improve the definition of these RoT and adjust as appropriate. 150Gb of active raw data per BPU. Raw data is the base/atomic level data to be held in the DW, defined by sizing each entity average row length * no. rows. Strongly recommend 4Gb memory per CPU. This provides a sensible about of memory for DB2 and tuning most BI workloads. Additional memory benefits can be assessed over time as a system matures. Between 8-16 disks to feed a CPU. In OLTP you get better use of a cache, which is the reason that they can support larger disks. DW does a lot of sequential read mixed with random I/O which typically eradicates benefit of read cache. 150GB x 4 (raw data to disk). 500GB of active raw data has to sit on 8 disks = 83Gb data per drive drives!! More on this later. 1 Fibre channel adaptor for every 4 CPUs. No more than 1 partition per CPU. Max table size per partition < 100Gb Minimum 8 disks at RPM; > 12 is more balanced 1200 IOs/sec 150 IOs/disk maximum) 33

36 Do s Best Practices Fit the technology to the business requirements When technology & people clash, people win Get database partitioning done right first Select good partitioning keys Ensure partitions map to disks for full parallelism & workload balancing Build a solid development & test environment Ensure symmetry between queries, data, and operations 34 This slide is self explanatory. 34

37 Don ts: the Road to Troubles Don t assume OLTP & BI workloads are similar Caching & I/O throughput are different causing differing cost emphasis Be careful consolidating SAN or disk subsystems for cost reasons alone Clients typically make storage decisions on cost per GB. For BI, focus on cost per I/O to disk Sorting, scan rates, aggregation, etc more critical in BI 35 Making assumptions anywhere along in the data warehouse design process and implementation process opens the window for trouble later on in the form of CRITSITs, customer satisfaction problems, etc.. Avoid those by not making assumptions and keeping your finger on the pulse of the customer throughout the entire sales and implementation timeframe. 35

38 Don ts: the Road to Troubles Don t use too few storage controllers vs. # of disks BI is often constricted on I/O throughput Don t use large disk capacities to save cost 72GB disks ideal for many BI workloads Don t assign > 1 DB2 partition to 1 disk grouping Use partition independence with spindles as you do for data partitions Setup spindles such that they serve requests from 1 partition 36 With an optimum design, a 15Krpm drive can read sequentially data at roughly 13MB/sec. A 10Krpm drive will be 25% less (10 MB/sec). With data scatter and other degradations such as varying block sizes of reads, a realistic sequential read rate to assume is 6-8 MB/sec per drive IF THE DESIGN GUIDELINES SPECIFIED IN THIS PRESENTATION ARE FOLLOWED. The key to achieving this throughput rate is to let only one DB2 partition request data from the individual drive (or LUN). 36

39 Database Cluster Symmetry Easier to configure Easier to manage Easier to operate Easier to troubleshoot Easier to upgrade Easier to predict capacity costs Easier to discuss with Line of Business execs Symmetrical configurations let DB2 hash partition evenly with less DBA effort minimize data skew, eliminate hot spots 37 These are the keys to having a good DB2 data warehouse design. Symmetry should exist at all levels of the architecture. 37

40 Minimum Recommended Maintenance Levels for DB2/AIX Known issues to prevent instability of warehouse Current external DB2/AIX issues are at this site : 1=IY49385&uid=swg &loc=en_US&cs=utf-8&lang=en+en One can subscribe to updates on this document and other flashes at Select "Database & Data Management" for the Product family, then select "DB2 Universal Database for Linux, UNIX and Windows" topic under the "Databases" category 38 38

41 DB2 Warehouse Design Best Practices Session: E15 Bill O Connell IBM Toronto Lab boconnel@ca.ibm.com 39 39