MAXIMIZING AVAILABILITY OF MICROSOFT SQL SERVER 2012 ON VBLOCK SYSTEMS

Transcription

1 Maximizing Availability of Microsoft SQL Server 2012 on Vblock Systems Table of Contents MAXIMIZING AVAILABILITY OF MICROSOFT SQL SERVER 2012 ON VBLOCK SYSTEMS January

2 Contents Introduction...4 Business case...4 Solution overview...4 Key results...5 Objectives...5 Scope...5 Audience...6 Feedback...6 Technology overview...7 Vblock Systems...7 Compute components...7 Network components...7 Storage components...8 Virtualization components...8 EMC PowerPath/VE...8 Microsoft Windows Server 2008 R2 with Service Pack Microsoft SQL Server Architecture overview...10 Physical architecture...10 Logical architecture...11 Hardware resources...11 Software resources...12 Design considerations...13 Determining high-availability and disaster recovery needs...13 Choosing a SQL Server 2012 AlwaysOn design...14 Designing the overall solution architecture...14 Sizing and configuring infrastructure components...16 Compute configuration...16 Network configuration...16 Storage configuration...16 Virtualization configuration...19 Solution validation...20 Test environment design

3 Workload generation...21 Distance emulation...22 Test methodology...23 Test scenarios...23 Creating and configuring the Availability Group...23 Test results...25 Site failure...25 Network failure...27 Storage array failure...28 Server/node failure...30 Conclusion...31 Next steps...31 References

4 Introduction In today s dynamic business environment, continuous uptime and fast recovery from adverse conditions are vital to meeting service-level agreements (SLAs) for high availability of business critical applications and application data. Planning for business disruptions and minimizing their impact is critical for enterprises, government agencies, and service providers to reduce revenue losses and compliance risks, including potential lawsuits. Designing and deploying a database like Microsoft SQL Server 2012, in conjunction with a highly available converged infrastructure helps organizations to avert these risks and control deployment and maintenance costs. This solution architecture paper describes the VCE solution for supporting a geographically dispersed SQL Server 2012 environment protected by AlwaysOn technology with multi-subnet support at synchronous distances of 0, 100, and 300 kilometers. Business case Because of the demand for increasingly higher availability service levels, many organizations are upgrading or migrating to SQL Server 2012 to leverage its AlwaysOn features for high availability and disaster recovery. SQL Server 2012 AlwaysOn is an integrated, flexible, and cost-efficient solution that provides redundancy within and across data centers, fast application failover for maximum availability, and data protection of critical applications. These migrations can replace older infrastructures, which are difficult to manage and expensive to support. Building an infrastructure by separately deploying and managing compute, storage, and virtualization resources for databases and other business systems has been complex, time-consuming, and costly until now. Converged infrastructures that take advantage of virtualized databases like SQL Server are rapidly transforming the way organizations deploy and manage their IT assets and resources. With a converged infrastructure, IT has a single flexible, scalable platform to manage, which reduces system complexity and IT operational overhead. With fewer servers consuming less space, power, and cooling, IT organizations also see significant capital and operational expense savings. For this reason, deploying SQL Server 2012 and taking advantage of its AlwaysOn functionality on a leading converged infrastructure helps organizations achieve business continuity objectives at a lower risk and cost. Solution overview The VCE solution is built on geographically dispersed SQL Server 2012 environments deployed on Vblock Systems protected by AlwaysOn technology in a primary and disaster recovery configuration across two data centers. Deploying SQL Server 2012 on Vblock Systems enhances the benefits of the AlwaysOn high-availability and disaster recovery features. Vblock Systems immediately deliver a pre-engineered, tested, and validated converged infrastructure that supports your high-availability requirements while reducing the total cost of ownership (TCO) and improving time to market. Vblock Systems require fewer servers and network switches, less data center space, and much lower power and cooling costs when compared to traditional data center architectures. Virtualizing SQL Server 2012 on Vblock Systems for maximum availability further reduces operational costs and frees IT resources for more strategic tasks. 4

5 By combining the power of the Vblock converged infrastructure and a virtualized SQL Server 2012, your organization can: Demonstrate business-critical levels of high performance and availability between data centers Ensure site resiliency and meet recovery objectives when faced with application, storage, network, and node failures Achieve business-continuity SLAs end-to-end at a lower risk and cost Key results Testing and validation of the VCE solution demonstrated the following: Using SQL Server 2012 AlwaysOn Availability Groups, the Recovery Time Objective (RTO) of less than one hour, and the Recovery Point Objective (RPO) of zero data loss were met in all failure scenarios at distances of 0, 50,100, and 300 kilometers. The Vblock System 300 can easily service SQL Server 2012 mission-critical online transaction processing (OLTP) production workloads while providing high availability through a combination of the Availability Groups feature and the storage capabilities of the Vblock converged infrastructure. Deploying SQL Server 2012 on a pair of Vblock Systems is simple and efficient, and provides improved data protection under typical transaction loads. Objectives The primary objective of this solution architecture paper is to demonstrate how to reduce the impact of hardware and software failures by using virtualized SQL Server 2012 for high availability and disaster recovery. This document includes best practice for facilitating SQL Server 2012 deployments on Vblock Systems to maximize continuous availability of the application and ensure business continuity during disasters. Scope The scope of this solution architecture is to: Validate the Vblock System for critical, enterprise-level, SQL Server 2012 deployments in a disaster recovery configuration featuring AlwaysOn Availability Groups. Demonstrate the high availability of SQL Server 2012 on Vblock Systems during disaster recovery. Provide best practices for a SQL Server 2012 deployment on the Vblock System. Low-level configuration, performance tuning, and maintenance issues are not addressed in this document. 5

6 Audience The primary audience of this solution architecture paper is technical practitioners, such as data center managers, database architects, and database administrators (DBAs). In addition, IT management teams would also be interested in reviewing this document as part of a product evaluation. Feedback To suggest documentation changes and provide feedback on this paper, contact docfeedback@vce.com. Include the title of this paper, the name of the topic to which your comment applies, and your feedback. 6

7 Technology overview The following sections summarize the technologies used in the VCE solution: Vblock Systems EMC PowerPath/VE Microsoft Windows Server 2008 R2 with Service Pack 2 Microsoft SQL Server 2012 For more information about the overall test environment including the distance emulator, load generation tools, and test measurement tools, refer to the Test environment design section. Vblock Systems Growing business challenges demand an IT infrastructure that is swift, agile, and economical enabling organizations to adapt to change quickly and cost-effectively. VCE designs and delivers Vblock Systems, which seamlessly integrate leading compute, network, and storage technologies. Through intelligent discovery, awareness, and automation, Vblock Systems provide the highest levels of virtualization and application performance. The Vblock System 300 is an agile and efficient data center-class system, providing modular and scalable performance. It features a high-density, compact fabric switch; tightly-integrated, fabric-based blade servers; and best-in-class, unified storage. Organizations look to the platform for unified storage, to support high-bandwidth applications, and for ease of use. Available in several models, this solution uses the Vblock 300EX. Each Vblock model has a base configuration, which is a minimum set of compute and storage components as well as fixed network resources. Within the base configuration, certain hardware aspects can be customized. Together, the components offer balanced CPU, I/O bandwidth, and storage capacity relative to the compute and storage arrays in the system. For more information, go to Compute components The compute components in Vblock Systems are built on the Cisco Unified Computing System (UCS) line of products. Components include one or more blade server chassis, compute blades, I/O modules, and the fabric interconnects that connect the unified fabric to the rest of the environment. Network components The network components in Vblock Systems consist of various models of Cisco Nexus and MDS storage switches. This includes the Cisco Nexus 7000 Series, Cisco Nexus 5000 Series, Cisco Nexus 1000V, Cisco Catalyst 3000 Series, and the Cisco MDS 9000 Series switches. 7

8 Storage components The Vblock Systems used in this solution contain VNX5300 storage arrays. The VNX5300 is a high-end, enterprise storage array that supports multiple drive technologies, including Flash, serialattached SCSI, SAS, and nearline SAS (NL-SAS) drives, and a full range of RAID types. Intel Xeon processors power the VNX series for intelligent storage that automatically and efficiently scales in performance, while ensuring data integrity, security, and high availability for mission-critical SQL Server environments. Virtualization components Virtualization components include VMware ESXi, VMware vcenter Server, and VMware vsphere. VMware vcenter Server provides a scalable and extensible platform that forms the foundation for virtualization management. It centrally manages VMware vsphere environments, allowing IT administrators control over the virtual environment. For more information on VMware vcenter Server, go to EMC PowerPath/VE EMC PowerPath/VE performs multipathing for the storage arrays on the Vblock System. PowerPath/VE works in combination with SAN storage to intelligently manage Fibre Channel (FC), iscsi, and Fibre Channel over Ethernet (FCoE) I/O paths. Installed on the vsphere host, PowerPath/VE scales to the maximum number of virtual machines on the host. The virtual machines do not have PowerPath/VE installed nor are they aware that PowerPath VE is managing them. PowerPath/VE dynamically load balances I/O requests and automatically detects, and recovers from, path failures. PowerPath/VE standardizes path management across heterogeneous physical and virtual environments and ensures application uptime. Microsoft Windows Server 2008 R2 with Service Pack 2 For this solution, the cluster feature available with Windows Server 2008 R2 with Service Pack (SP) 2 was used. A failover cluster is a group of independent computers that work together to increase the availability of applications and services. The clustered servers, called nodes, are connected by physical cables and software. If one of the cluster nodes fails, another node begins to provide service (a process known as failover). Users experience a minimum of disruptions in service. Microsoft cluster technologies guard against three specific types of failure: Application and service failures, which affect application software and essential services. System and hardware failures, which affect hardware components such as CPUs, drives, memory, network adapters, and power supplies. Site failures in multisite organizations, which can be caused by natural disasters, power outages, or connectivity outages. 8

9 Microsoft SQL Server 2012 Microsoft SQL Server is a database management and analysis system for e-commerce, line-of-business, and data warehousing solutions. The latest version, SQL Server 2012, adds new high availability and disaster recovery solutions through AlwaysOn Availability Groups. The new SQL Server 2012 AlwaysOn feature provides flexible design choices for selecting an appropriate high-availability and disaster recovery solution for applications. SQL Server AlwaysOn was developed for applications that require high uptime, need protection against failures within a data center and adequate redundancy against failures across data centers. SQL Server 2012 AlwaysOn provides availability at either the application database or instance level: Availability Groups is a new feature that helps protect application databases from planned and unplanned downtime. The Availability Groups feature provides an enterprise-level alternative to database mirroring. An availability group supports a failover environment for a set of read-write primary databases and one to four sets of corresponding secondary databases. Optionally, secondary databases can be made available for read-only access and/or some backup operations. Failover Cluster Instance provides availability for the entire SQL Server instance by enabling failover of the instance rather than individual database(s). The Failover Cluster Instance feature enhances existing SQL Server Failover Clustering with support for multisite clustering across subnets for improved site protection, a flexible failover policy for better control over instance failover, and improved diagnostics for faster troubleshooting. 9

10 Architecture overview VCE solutions are designed to reflect and validate real-world deployments. This paper describes a disaster recovery solution for SQL Server 2012 on the Vblock System using AlwaysOn Availability Groups. The following sections describe the physical and logical architecture of the solution. Physical architecture The solution uses Windows Server in a Windows Server Failover Cluster (WSFC) on two Vblock 300EX Systems. One Vblock 300EX System serves as the primary data center site and the other Vblock System as the disaster recovery data center site The Vblock 300EX System is optimal for the storage, compute, hypervisor, and network requirements of this solution. Each of the ESX hosts resides on a VNX5300 storage array connected through MDS 9148 and Nexus Figure 1 shows the physical architecture of the solution. Figure 1. Physical architecture 10

11 Logical architecture Figure 2 shows the logical architecture of the solution. Figure 2. Logical architecture Hardware resources Table 1 shows the hardware resources used in this solution. Table 1. Solution hardware resources Equipment Quantity Configuration Compute 6 Cisco UCS B200 M2 blade server packs (12-core, 96 GB memory) Network switches 4 Cisco Nexus 5548 Storage platform 2 EMC VNX5300 Aggregation SAN switch 4 Cisco MDS 9148 Virtualization 2 VMware vsphere 5.0 VMware vcenter Server 5.0 Management 2 Cisco UCS C200 servers 11

12 Software resources Table 2 lists the software used in this solution. Table 2. Solution software resources Description Quantity Version Purpose Windows Server 2008 R R2 x64 SP1 Server operating system Microsoft SQL Server 2012 Enterprise Edition Database server EMC PowerPath/VE Advanced multipathing for SQL Server production host HBAs 12

13 Design considerations To meet high-availability and disaster recovery requirements using SQL Server 2012 AlwaysOn Availability Groups, it is important for an organization to: Determine high-availability and disaster recovery needs. Choose a SQL Server 2012 AlwaysOn design. Design an overall solution architecture. Size and configure infrastructure components. Follow best practices for SQL Server 2012 from VMware, Cisco, and EMC The following sections discuss some of the design considerations for the implementation of Availability Groups. For more information about prerequisites, restrictions, and other recommendations, refer to and Determining high-availability and disaster recovery needs Disaster recovery is the ability to recover data in case the production system is damaged, destroyed or becomes unavailable for an undeterminable period. One of the first things to do when creating a disaster recovery plan is to determine how much data and time you can afford to lose. The primary measures to use to determine high availability and disaster recovery needs including data recovery metrics, are: High availability Refers to a system or component that is continuously operational for a desirable length of time. Availability can be measured relative to "100% operational" or "never failing." Disaster recovery is a subset of business continuity. High availability can be a concept within a data center or across data centers. Disaster recovery Refers to a strategy preparing for recovery and continuation of the technology infrastructure vital to an organization after a natural or human-induced disaster. Disaster recovery is also a subset of business continuity. Recovery Point Objective and Recovery Time Objective are the key metrics to measure disaster recovery readiness. Recovery Point Objective (RPO) Describes a point in time from which data can be restored. For instance, if there is data corruption, loss, or unavailability, what point in time can a valid copy of the data be restored from? Example The database is corrupted. Can we restore from 15 minutes ago?" This would be an RPO of 15 minutes. Recovery Time Objective (RTO) The amount of time in which you want data or hardware restored after a data corruption or hardware failure. Example The production financial processing system just crashed. How long will it be until it is back online and available for our banking customers?" If the answer is one hour then the RTO is one hour. 13

14 Figure 3. Using RPO and RTO to determine data recovery needs The disaster recovery goal of the VCE solution is recovery in less than one hour with zero data loss. Choosing a SQL Server 2012 AlwaysOn design SQL Server 2012 AlwaysOn provides flexible design choices for selecting an appropriate solution for your application that provides protection against failures within a data center and adequate redundancy across data centers. Microsoft has identified the following design patterns as the most commonly used by their customers for high availability and disaster recovery: Multi-site Failover Cluster Instance for a local high-availability and disaster recovery solution Availability Groups for a local high-availability and disaster recovery solution Failover Cluster Instance for local high availability, and Availability Groups for a disaster recovery solution For an overview of these design patterns for high availability and disaster recovery, refer to Designing the overall solution architecture Setting up Availability Groups requires: At least two servers (one primary replica and one secondary replica) running Microsoft Windows Server 2008 R2 Enterprise Edition Microsoft SQL Server 2012 Enterprise Edition Windows Server Failover Clustering (WSFC) configured between the hosts Table 3 lists important Microsoft prerequisites and requirements to consider when designing a high-availability and disaster recovery solution. For more information, refer to 14

15 Table 3. Prerequisites and Requirements Component Prerequisites and requirements Windows Server 2008 R2 Availability Groups are not supported on domain controllers. Each host computer must be a node in a WSFC cluster. A WSFC node can host only one availability replica for a given Availability Group. On a given WSFC node, one or more instances of SQL Server can host availability replicas for many Availability Groups. Ask your database administrators how many WSFC nodes are required to support the availability replicas of the planned Availability Groups. Every computer on which a server instance hosts an availability replica must possess sufficient disk space for all the databases in the Availability Group. SQL Server 2012 The instances of SQL Server that host availability replicas for a given Availability Group must reside on separate nodes of a single WSFC cluster. Each server instance must be running the Enterprise Edition of SQL Server Enable the AlwaysOn Availability Groups feature on each server instance that will host an availability replica for any availability group. Availability Groups For a given Availability Group, availability replicas must be hosted by server instances running on different nodes of the same WSFC cluster. However, virtual machines on the same physical computer can each host an availability replica for the same Availability Group because each virtual machine acts as a separate computer. Each Availability Group supports one primary replica and up to four secondary replicas. The number of databases and Availability Groups you can put on a computer (virtual or physical) depends on the hardware and workload, but there is no enforced limit. Thoroughly test your environment with a production-like workload to ensure it can handle peak workload capacity within your application service level agreements (SLAs). Consider load under failure conditions as well as expected response times. Availability Database Must be a read-write database. Read-only databases cannot be added to Availability Groups. Must be a multi-user database. Must not belong to any existing Availability Group. Must not be configured for database mirroring. The infrastructure used for testing and validation was built on a Windows Server 2008 R2 Enterprise Edition operating system platform with a four-node WSFC consisting of a two-node cluster on the primary data center site and a two-node cluster on the secondary data center site using a stretched, active-active failover cluster configuration. After validation of the infrastructure, four SQL Server 2012 instances were installed with a single AlwaysOn Availability Group. The AlwaysOn Availability group was created with one primary replica and three secondary replicas. For more information about creating Availability Groups, refer to 15

16 Sizing and configuring infrastructure components The following sections describe how the components of the converged infrastructure on the Vblock 300EX were configured for validation of the solution. Before you begin, check the latest software and hardware requirement for SQL Server Current requirements are listed at Compute configuration For the Vblock solution, two Vblock 300EX Systems were used to represent the primary and secondary (disaster recovery) data center sites. Each Vblock contained four Cisco UCS B200 M2 blade server packs. Each blade server had a 12-core CPU and 96 GB of memory. Network configuration Microsoft strongly recommends that you use the same network links for communications between Windows Server Failover Cluster (WSFC) cluster members and communications between availability replicas. Using separate network links can cause unexpected behaviors if some of the links fail (even intermittently). To improve throughput, manageability, application separation, high availability, and security, virtual local area networks (VLANs) were used to segregate the network traffic of various types. Storage configuration SQL AlwaysOn Availability Groups require separate, non-shared storage between data centers. The following sections describe the storage configuration for the solution. RAID groups In accordance with best practices from Microsoft, EMC, and VMware, the SQL Server database configuration was split into two RAID groups for data and transaction log data. For application data, RAID 5 disks were used. RAID 5 was chosen for two main reasons: Lower cost of data protection compared to RAID 10, with RAID 5 requiring only 20 percent of the total usable capacity for storing parity data High-read performance because all drives contribute to the delivery of data To ensure availability of transaction log data in disaster recovery situations, RAID 10 disk groups were used for transaction log data. Table 4 shows the RAID group configurations in the VNX5300 storage arrays. Table 4. RAID groups 16

17 RAID Group No. No. of Disks Disk Type Disk Size (GB) RPM RAID Type 10 5 SAS K RAID (4+1) 239, SAS K Hot Spare Purpose ESXi boot LUNs, VM Boot and Swap Hot Spare Storage pools To optimize read performance, a RAID 5 storage pool was used for Microsoft SQL Server application data. A separate RAID 10 storage pool was used for the SQL Server transaction logs. Table 5 shows the storage pool configurations, which are identical in both Vblock Systems. Table 5. Storage pools Pool Name No. of Disks Disk Type Disk Size (GB) RPM RAID Type Purpose MSSQL_R5 10 SAS K RAID 5 For SQL Server DB MSSQL_R10 8 SAS K RAID 10 For SQL Server Transaction Log Disk storage To maximize performance and availability, best practices from Microsoft, EMC, Cisco, and VMware were used to configure the virtualized storage to the physical infrastructure. On the primary data center site, the storage on the VNX5300 was mapped to the volumes on the Windows Server 2008 virtualized environment hosted on the Vblock System. As shown in Table 6, separate disk volumes were created and mapped between the Windows Server guest operating system and the virtual machines. 17

18 Table 6. Disk storage layout Vblock 300EX 1 Drive Letter Storage (GB) Hard Disk No. Purpose C: 100 Hard Disk 1 Boot and Swap ESXi Disk Type VMware Datastore VNX Array LUN Size (GB) VNX Storage Pool vmdk vm_boot_swap 600 RG #10 D: 1024 Hard Disk 2 DB vmdk sql_db 2500 MSSQL_DB L: 700 Hard Disk 3 Log vmdk sql_log 1700 MSSQL_LOG C: 100 Hard Disk 1 Boot and Swap vmdk vm_boot_swap 600 RG #10 D: 1024 Hard Disk 2 DB vmdk sql_db 2500 MSSQL_DB L: 700 Hard Disk 3 Log vmdk sql_log 1700 MSSQL_LOG C: 100 Hard Disk 1 Boot and Swap C: 100 Hard Disk 1 Boot and Swap C: 100 Hard Disk 1 Boot and Swap C: 100 Hard Disk 1 Boot and Swap C: 1100 Hard Disk 1 Boot and Swap vmdk vm_boot_swap 600 RG #10 vmdk vm_boot_swap 600 RG #10 vmdk vm_boot_swap 600 RG #10 vmdk vm_boot_swap 600 RG #10 vmdk vm_boot_swap 600 RG #10 The same disk storage layout was configured on the VNX5300 storage array at the secondary data center site (Table 7). 18

19 Table 7. Disk storage layout Vblock 300EX 2 Drive Letter Storage (GB) Hard Disk # Purpose ESXi Disk Type C: 100 Hard Disk 1 Boot and Swap VMware Datastore VNX Array LUN Size (GB) VNX Storage Pool vmdk vm_boot_swap 600 RG #10 D: 1024 Hard Disk 2 DB vmdk sql_db 2500 MSSQL_DB L: 700 Hard Disk 3 Log vmdk sql_log 1700 MSSQL_LOG C: 100 Hard Disk 1 Boot and Swap vmdk vm_boot_swap 600 RG #10 D: 1024 Hard Disk 2 DB vmdk sql_db 2500 MSSQL_DB L: 700 Hard Disk 3 Log vmdk sql_log 1700 MSSQL_LOG Virtualization configuration The following table describes the virtual machines created to validate the solution. Data Center Site Virtual Machine Role Primary Windows Server 2008 R2 SP2 domain controller (ms-dc1) SQL Server 2012 (ms-sql-db1) SQL Server 2012 (ms-sql-db2) Cluster File Share Witness (ms-sql-wns) SQL Server 2012 Native Client (ms-sql-client1) TPC-E (MSTPCE1) TPC-E (MSTPCE2) Provides DNS, Active Directory, and DHCP services Provides database services Provides database services Provides cluster FSW services Provides access to data in the SQL Server 2012 database Provides test workload data Provides test workload data Secondary SQL Server 2012 (ms-sql-db3) Provides database services SQL Server 2012 (ms-sql-db4) Provides database services 19

20 Solution validation The testing of this solution validated the use of the high-availability and disaster recovery capabilities of SQL 2012 AlwaysOn Availability Groups with the Vblock System to enable business continuity of Microsoft operations. Test environment design The solution infrastructure was deployed on Windows Server 2008 R2 in a four-node Windows Server Failover Cluster (WSFC) over two Vblock 300EX Systems. One Vblock 300EX System served as the primary data center site and the other Vblock System served as the secondary data center site. The data center sites were connected by a simulated WAN. A SQL Server 2012 instance was deployed on each node in the WSFC configuration. The SQL Server instances share an AlwaysOn Availability Group for high-availability and disaster recovery purposes. With this configuration, the primary data center site can fail over to the secondary data center site easily while maintaining availability and minimizing costly downtime. Two additional virtual machines were created on the primary data center site for TPC-E, which was used to generate the application test workload. A distance emulator between the two Vblock Systems emulated a WAN for testing over distance. Figure 4 shows the test environment. Figure 4. Test environment 20

21 Workload generation To test high availability and disaster recovery, VCE ran OLTP-like workloads against the SQL Server 2012 database environment in parallel with a simulated real world failure event and verified that the application and database were online and available during the failure. Workloads were generated using TPC Benchmark E (TPC-E). TPC-E consists of a set of transactional operations designed to exercise system functionalities in a manner representative of complex OLTP application environments. To help users relate to the components of the benchmark, these transactional operations have been given a real-world context, depicting the activity of a brokerage firm. The workload is centered on the activity of processing brokerage trades and uses a schema that is divided in four sets of tables. TPC-E models the activity of brokerage firm that must manage customer accounts, execute customer trade orders, and be responsible for the interactions of customers with financial markets. The brokerage firm interacts with financial markets to execute orders on behalf of the customers and updates relevant account information. The number of customers defined for the brokerage firm can be varied to represent the workloads of different size businesses. This benchmark is composed of a set of transactions that are executed against three sets of database tables that represent market data, customer data, and broker data. A fourth set of tables contains generic dimension data such as zip codes. Figure 5 shows the key components of the environment: Figure 5. TPC-E Benchmark Transactions 21