EMC ACCELERATES ORACLE

Transcription

1 White Paper EMC ACCELERATES ORACLE Increase database query performance Increase I/O bandwidth available to concurrent workloads Simple installation and transparent operation EMC Solutions Group Abstract This white paper details how EMC and GridIron Systems hardware can provide a scalable, high-performance Oracle database infrastructure in physical as well as virtualized databases. August 2012

2 Copyright 2012 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. All trademarks used herein are the property of their respective owners. Part Number H

3 Table of contents Executive summary... 4 Business case... 4 Solution overview... 5 Key results... 5 Introduction... 6 Purpose... 6 Audience... 6 Scope... 6 Not in scope... 6 Terminology... 6 Overview: Balanced systems for performance-oriented database applications... 7 Problem overview... 7 EMC and GridIron solutions... 7 Testing methodology... 8 Configurations... 9 Tested configuration... 9 EMC CLARiiON CX4-960 storage configuration Baseline configurations Oracle Bare Metal configuration Virtualized Oracle configuration Test execution results Results summary Conclusion Summary Appendices Appendix A: Detailed performance results by query Appendix B: Workload query definitions Appendix C: GridIron TurboCharger zoning Real to virtual WWPN mapping: FabricA Real to virtual WWPN mapping: FabricB TurboCharger scripts

4 Executive summary Business case Numerous surveys show that data in enterprises will continue to grow at extreme rates as organizations continue to maximize the business value of their data. Applications such as Business Intelligence (BI), Customer Resource Management (CRM) and Enterprise Resource Planning (ERP) are a few examples where constant refinement in data analytics is increasing the profitability and operational efficiencies of the business. For these reasons, the growing demand for data analytics will continue to rise exponentially as organizations learn new ways to extract increased business values from their data: In 2011, the amount of information created and replicated will surpass 1.8 zettabytes (1.8 trillion gigabytes) growing by a factor of 9 in just five years. Source: IDC, Extracting Value From Chaos June 2011 Data velocity, variety, and volume are all expanding rapidly and challenging the warehouse architecture with "extreme data." Source: Gartner, Inc. The State of Data Warehousing in 2012 February 13, 2012 The rapid growth in the ability to collect electronic business data is driving the need for high performance analytical solutions built on cost-effective business intelligence systems. This capability has become critical to the financial success of many companies. At the same time, the explosive growth of enterprise data and the rich, real-time analytics demanded by businesses are challenging the performance of many popular applications. The efficient storage and retrieval of data to meet the requirements of businesscritical applications often requires unplanned, expensive, and disruptive upgrades to current infrastructure investments. Corporate initiatives to virtualize all server infrastructure adds a new dimension to this problem, causing tension between application owners, trying to meet the performance requirements of these data analytic systems, and corporate infrastructure standards. Multiple industry initiatives are specifically targeted at providing an effective solution to this performance dilemma: Leading database vendors such as Oracle and Microsoft have been investing in new features, focused specifically at increasing the performance and manageability of data warehouse applications, but these improvements have not kept pace with the growth of data and the analytics needs of businesses. The latest servers with multicore processors have the power to satisfy the compute needs of analytics applications, especially when configured as part of a server cluster, but these servers run into I/O bottlenecks. EMC has been investing in upgrading storage processor capability with the latest multicore hardware, better storage management software, and the incorporation of solid state drive (SSD) technology to keep pace with the increased I/O demands of applications built on Oracle and Microsoft SQL Server. However, even advanced storage systems struggle to satisfy the I/O demands of clusters of the latest multicore servers. 4

5 A new, high-performance data access layer is needed to satisfy the increasingly high I/O requirements of data-intensive analytics workloads. Solution overview EMC and GridIron Systems, Inc. have jointly built solutions to help enterprises utilize scalable private cloud technologies to address their needs for storing and analyzing multiterabyte data stores, and to improve operational efficiency, and strategic decision-making. GridIron s TurboCharger nondisruptive SAN I/O acceleration appliance is designed to seamlessly integrate into existing application/server/storage environments and provide a 2x to 10x improvement in application performance. This joint solution demonstrates how EMC and GridIron Systems can provide a scalable, high-performance database infrastructure, through high-speed caching of the I/O in the SAN between server and storage via the GridIron TurboCharger appliance, accelerating application and infrastructure performance for database sizes ranging from hundreds of gigabytes to hundreds of terabytes. Advantages include: Better performance than a traditionally tuned database application Nondisruptive installation of the GridIron TurboCharger appliance in the SAN environment, requiring no application or database changes, and presenting no additional management overhead Increased concurrency in mixed workload environments Greater consolidation ratios with virtualization unhindered by I/O bottlenecks Manageability of single system versus multiple independent storage arrays Low operational costs by not having to re-layout data over time Key results The solution demonstrates significant performance benefits for customers who are seeking to improve performance of their Oracle database environment(s): When we configured GridIron TurboChargers (GTs) in the physical Oracle environment, query performance improved by an average of 3.2 times with some queries speeding up by over 10 times, when compared to a baseline (no GT) configuration. In the virtualized environment, the GTs were able to increase the query performance an average of 2.2 times, when compared to a baseline (no GT) configuration. Detailed performance improvements, including specific query performance, are documented elsewhere in this white paper. 5

6 Introduction Purpose Audience Scope This white paper describes an innovative approach to hosting high-performance Oracle databases that leverages the advantages of EMC storage arrays and the GridIron TurboCharger nondisruptive SAN I/O acceleration appliance to provide higher bandwidth, increased concurrent query performance, and cost-effective manageability of the infrastructure. The intended audience for this white paper includes chief technology officers, architects, IT planners, database administrators, partners, and BI professionals, who are involved in decision making for major IT infrastructure acquisitions and seeking ways to improve data warehouse system performance. The scope of this paper corresponds to the scope of the solution validation (build, test, and document) activities performed by EMC engineers in an EMC solutions laboratory. What was built and tested is described and, where possible, recommendations and guidelines are provided for professionals to design a similar solution. The concepts, instructions, procedures, recommendations, and guidelines presented in this document are thorough but not all-inclusive. Not in scope Terminology Installation and configuration instructions, as well as detailed application architecture guidelines, do not fall within the scope of this white paper. This white paper includes the following terminology. Table 1. Terminology Term Oracle RAC DBGEN GridIron TurboCharger appliance Definition Oracle Real Application Cluster. DBGEN enables the generation of a TPC-H like workload. The DBGEN tool allows the user to generate data with known relationships between tables and can be scaled to different sizes. The GridIron TurboCharger (GT) is a SAN-based hardware application accelerator that improves performance by identifying and serving performance-critical data from a solid state tier. 6

7 Overview: Balanced systems for performance-oriented database applications Problem overview Critical business applications typically rely on databases such as Oracle and Microsoft SQL Server to generate or report on revenue for an organization. Usually, the faster these applications can access data in the databases, the greater are the benefits for the organization s revenue and productivity. Therefore, the performance at which these databases operate, in addition to maintaining the availability and reliability of the database, is a top priority for IT managers. Organizations have moved to a shared storage model for improved data protection and storage economics in the data center. The popularity of business intelligence applications has driven an increase in the number of database instances, and the concurrent use of those instances, at a pace that is much faster than the increase in enterprise storage performance. The aggregate I/O from several applications and users accessing database instances that reside on the same storage system at the same time, with varying patterns of access, creates I/O bottlenecks. These I/O bottlenecks make it extremely challenging for the storage array to support the performance needs of such dynamic and diverse workloads. The growing trend of server virtualization deployment exacerbates this performance problem. Virtual servers and virtual desktops hosted on the same storage system multiply the concurrency of demand and create significant overall performance degradation due to the I/O bottleneck. There are different ways to alleviate the I/O bottleneck such as server-side caching, storage-side caching and tiering, network-based acceleration, and purpose-built database appliances, to name a few. For an overview of the pros and cons of these various approaches, see the Storage Switzerland article: Cost Effectively Solving Oracle Performance Problems. EMC and GridIron solutions EMC and GridIron have developed a reference architecture for high-performance databases that combines a mid-tier storage array with a Fibre Channel (FC) fabricbased application acceleration appliance, based on SSD and Flash memory-based caching. This reference architecture is introduced through soft zoning changes in the SAN fabric. It is transparent to the application servers, often without requiring a downtime of the application. Best of all, the reference architecture does not require any changes to the application, database, servers, storage, or operational processes. The LUN layout on the back-end storage remains unchanged. The remainder of this white paper describes the approach and results of a proof-ofconcept project that uses the EMC CLARiiON CX4-960 storage array technology together with GridIron TurboChargers to provide an ideal solution to SAN performance challenges. This solution provides scale-out flexibility, performance, and manageability at a favorable cost per GB. 7

8 Testing methodology This workload generated large streams of data reads to reflect a production database environment. The team wanted something that could be run in multiple parallel queries without incurring significant locking wait times. The desired database size was at a minimum of 1 TB. The DBGEN tool, produced by the Transaction Processing Council (see was used. This tool generates data with known relationships between tables and can be scaled to different sizes. A set of 21 queries was created using QGEN for Oracle s SQL programming language to produce high read demands that are typical of decision support systems. All of the queries use aggregates and grouping functions aggressively. The queries use parameters that are randomized for each successive execution so that no hot spots are created by repeatedly executing a query with a static set of parameters. Although the underlying database schema and queries are based on TPC-H specification, there are significant differences in both the implementation and the query workload so that this methodology cannot be compared to any official TPC benchmark specifications. For more information, see Appendix B: Workload query definitions. Users have the ability to control the amount of data returned to the client and the amount of data required to produce the report on the client. Since all the reports use aggregations and groupings, the workload is both I/O- and processor-intensive. Users can tune the query specifications so as to limit the amount of I/O and/or processor requirements to match the relative balance of the system being tested. The main objective is to run the same reporting workload against one or more system configurations to compare their relative performance under extreme loads. 8

9 Configurations Tested configuration To test the EMC/GridIron solution in a read-intensive workload scenario, we used a series of configurations. The test methodology defined a baseline configuration consisting of a single server accessing an FC-attached EMC storage array with a full set of dedicated spindles. Two different configurations were tested: Oracle Bare Metal configuration: Oracle running on a physical server Virtualized Oracle configuration: Oracle running in a virtual server The two configurations were designed to maximize read throughput from the appliance cache after the initial data load from the CLARiiON CX4-960 disks. The GridIron TurboCharger (GT) is a SAN-attached I/O acceleration device that uses Flash/SSD and RAM technology, which allows infrastructure to run at optimum efficiency that accelerates application performance. The TurboCharger appliance resides in the FC SAN fabric between the servers and the storage platforms containing the application data, as shown in Figure 1. The TurboCharger appliance creates a high-performance caching tier using RAM and Flash/SSD technology to create a highperformance cache in front of single or multiple storage platforms (such as the EMC VMAX series and EMC VNX series). Figure 1. GridIron installation within SAN fabric The TurboCharger s hardware-based analytic engine constantly evaluates I/O performance and application access patterns to determine the hot blocks residing on the attached storage platforms that are most important to application performance. In essence, this is a form of sub-lun tiering but with the difference that the Flash/SSD tier containing the performance-important data blocks resides in the TurboCharger appliance. The TurboCharger employs a predictive scheme using statistical analysis to establish application I/O access patterns and data relationships to determine which blocks should reside in the TurboCharger appliance to optimize application performance. The TurboCharger uses caching as an element of the acceleration 9

10 technology it is not a storage device and all of the blocks contained in the TurboCharger are copies of blocks that exist on primary storage (Gold Copy). Once installed via zoning, a GridIron TurboCharger (GT) may run in either of two modes: pass-thru or boost. In pass-thru mode, all SCSI commands and data simply flow through the GT unimpeded (although statistics may be gathered). In boost mode, the GT responds to host read requests by serving data blocks from its internal cache, if they are so resident. Additionally, in boost mode the GT analyzes patterns in the data, identifying hotspots and tracing their movement, and tiering data as appropriate to meet the applications anticipated needs. Note This configuration reflects production deployments where two GTs are configured as a high availability cluster, using active-active failover between the GTs. The baseline and boosted GT scenarios used a common SAN configuration as follows. EMC CLARiiON CX4-960 storage configuration All configurations that leverage the CLARiiON CX4-960 employed the same underlying disk configuration. This configuration was designed to represent a common customer decision point, focusing particularly on the use of RAID 10. The configuration follows best practice guidance by isolating the SQL datafiles, TEMP, and log files to separate sets of spindles. Furthermore, as shown in the SAN configuration table below, this configuration spreads the I/O workload across both storage processors to provide efficient storage processor and cache utilization. By reusing this storage configuration for all tests, testing new scenarios was accomplished by FC zoning. The GridIron SAN planner utility was used to generate FC zoning scripts and each new scenario was reconfigured by simply rezoning the GridIron into the FC configuration. For sample zoning scripts, see Appendix C: GridIron TurboCharger zoning. Table 2 represents the inventory of the SAN configuration used. Table 2. SAN configuration inventory Group RAID level Purpose LUNs Disks RAID Group 1 10 Log + TEMP LUN0, LUN2, LUN4, LUN6 (LUN size 1,000 GB) 8 x 500 GB SPA Storage processor RAID Group 2 10 Log + TEMP LUN1, LUN3, LUN5, LUN7 (LUN size 1 TB) RAID Group 3 10 Data LUN0, LUN2, LUN4 (LUN size 2 TB) RAID Group 4 10 Data LUN1, LUN3, LUN5 (LUN size 2 TB) 8 x 500 GB SPB 16 x 500 GB SPA 16 x 500 GB SPB Table 3 shows the Brocade FC switching configuration that we used. 10

11 Table 3. Brocade FC configuration Component FC switching and fabric Configuration 2 x Brocade VA-FC40 8 GB/s 32-port Table 4 shows the application server used for the baseline and the GT boost scenario for the Oracle Bare Metal configuration. Table 4. Oracle Bare Metal application server configuration Component Server Configuration 256 GB memory 4 x 10-core Intel Xeon E CPUs, hyper-threaded (looks like 80 CPUs) 4 x 2-port QLogic 8 GB/s HBA cards Application layer Red Hat Enterprise Linux 5 Oracle Enterprise Database 11 R2 ( ) TPC-H Scale 3,000; actual DB size 10.5 TB Table 5 shows the application server used for the baseline and the GT boost scenario for the virtualized Oracle configuration. Table 5. Virtualized Oracle configuration Component Server Configuration 64 GB memory 2 x 6-core Intel Xeon E CPUs, hyper-threaded (looks like 24 CPUs) 2 x QLogic 8 GB/s HBA cards VMware VMware vsphere Hypervisor (ESXi ) 5 2 x virtual machines running Red Hat Enterprise Linux 5 28 GB of RAM for each virtual machine; 24 GB of RAM for each Oracle instance Application layer Red Hat Enterprise Linux 5 Oracle Enterprise Database 11 R2 ( ) TPC-H scale 1,000; actual database size 5 TB Baseline configurations The baseline configuration was the database implemented on a CLARiiON CX4-960, using the disk configuration above and no GT boosting. The configuration of these scenarios was designed to provide enough read bandwidth to be able to satisfy the cache loading for the boost scenario in a reasonable amount of time compared to the overall workload execution time. The tests could utilize the total throughput capability of the CX

12 Oracle Bare Metal configuration This scenario is a variation of the CLARiiON CX configuration using a pair of GTs in a high-availability cluster to boost application I/O performance, thus increasing bandwidth and reducing latencies and elapsed time significantly. In order to insert the GTs into the data path, it is necessary to create new zones for each fabric. For more information, see Appendix C: GridIron TurboCharger zoning. Zones that manage traffic between the host and the TurboCharger are called front-end zones and are shown in blue. Zones that manage traffic between the TurboCharger and the storage array are called back-end zones and are shown in green. The GT was logically zoned into the SAN, between the storage and servers, as depicted in Figure 2. Figure 2. GridIron configuration for Oracle Bare Metal scenario Two host ports were mapped to each GT front-end port, and two array ports to each GT back-end port. Table 6 includes the complete configuration details. Table 6. GridIron configuration details for the Oracle Bare Metal scenario Component Server FC switching and fabric Storage Configuration 4 x QLogic 8 Gb/s dual-port HBA cards (a total of 8 x 8 Gb/s FC ports) 2 x Brocade VA-FC40 8 GB/s 32-port 2 x GridIron GT-1500 TurboCharger 8 x 4 Gb/s FC ports 12

13 Virtualized Oracle configuration This scenario is an example of how to enable virtualized Oracle using the same configuration of CLARiiON CX4-960 and a pair of GTs to boost application I/O performance, so increasing bandwidth and reducing latencies and elapsed time significantly. The intent was to increase the ratio of GTs to SAN storage processors and to better align the GridIron fibre capacity to the server fibre capacity. The GTs were logically zoned into the SAN between the storage and servers, as depicted in Figure 3. Figure 3. GridIron configuration for Virtualized Oracle Scenario Each host port was mapped one-to-one with a GT front-end port, GT back-end port, and array port. Table 7 includes the complete configuration details. Table 7. GridIron configuration details for the virtualized Oracle scenario Component Server FC switching and fabric Storage Configuration 2 x QLogic 8 Gb/s dual-port HBA cards (total of 4 8Gb/s FC ports) 2 x Brocade VA-FC40 8 GB/s 32-port 2 x GridIron GT-1500 TurboCharger 8 x 4 Gb/s FC ports Table 4 illustrates the RAID configuration and hardware components in the reference configuration. 13

14 Figure 4. Detailed hardware topology 14

15 Table 8 shows the inventory of the configuration components. Table 8. Configuration components Component Server Application layer FC switching and fabric Storage Configuration Oracle Bare Metal server 256 GB memory 4 x 10-core Intel 4 x QLogic 8 Gb/s dual-port HBA cards Red Hat Enterpise Linux v5 Oracle Enterprise Database 11g R2 2 x QLogic SANbox GB FC switch 1 x CLARiiON CX x 15k rpm 500 GB disk drives 12 x SSD drives for caching/tiering on the CX4 2 x storage processors (SPA, SPB) 8 x 4 Gb/s FC ports 15

16 Test execution results Results summary In order to test the performance characteristics of each configuration, we executed the same data set and same queries. To avoid the performance benefit of cached query result sets, the queries executed included logic to randomize the query predicate used. Since a random query predicate can cause some unpredictability in the results, each query was executed four times and the results were averaged. The charts in this section illustrate the average execution time of each query. Figure 5 shows the execution times of the individual queries using GridIron boost compared to the baseline without boost, in the Bare Metal configuration. 4,000 Bare Metal Query Execution Time (seconds) 3,500 3,000 2,500 2,000 1,500 1, Query 1 Query 2 Query 3 Query 4 Query 5 Query 6 Query 7 Query 8 Query 9 Query 10 Query 11 Without GridIron Boost Query 12 Query 13 Query 14 Query 15 Query 16 With GridIron Boost Query 17 Query 18 Query 19 Query 20 Query 21 Figure 5. Oracle Bare Metal configuration: query execution times The second chart (Figure 6) shows the execution times of the individual queries running with and without GridIron boost in a virtualized environment. All subsequent charts (in the Appendices section) illustrate more detailed comparison of the query results versus the baseline execution. For details of the configuration used for each execution, see the Configurations section. Each of these queries is defined in the Appendices section. 16

17 Virtualized Query Execution Time (seconds) 1,800 1,600 1,400 1,200 1, Query 1 Query 2 Query 3 Query 4 Query 5 Query 6 Query 7 Query 8 Query 9 Query 10 Query 11 Query 12 Query 13 Query 14 Query 15 Query 16 Query 17 Query 18 Query 19 Query 20 Query 21 Without GridIron Boost With GridIron Boost Figure 6. Virtualized Oracle configuration: Query execution times Figure 5 and Figure 6 show the results of the overall execution times on a per-query basis. In nearly all cases the boosted queries ran significantly faster (2 to 11 times faster) compared to their respective baseline runs. For additional query analysis, see Appendix A: Detailed performance results by query. Note The servers used for the Bare Metal configuration and the virtualized Oracle configuration were not identical in their capability. Variability in performance between the two sets of tests is to be expected. Note Benchmark results are highly dependent upon workload, specific application requirements, and system design and implementation. Relative system performance will vary as a result of these and other factors. Therefore, this workload should not be used as a substitute for a specific customer application benchmark when critical capacity planning and/or product evaluation decisions are contemplated. All performance data contained in this report was obtained in a rigorously controlled environment. Results obtained in other operating environments may vary significantly. 17

18 Conclusion Summary The solutions described in this white paper provide significant performance gains, achieved by combining the GridIron TurboChargers with the EMC CLARiiON CX In both the Bare Metal and virtualized Oracle scenarios, the performance of the data warehouse query workload increased by at least 2x, while in the Bare Metal configuration, some queries ran up to 11x faster. The GridIron TurboChargers improved query performance, as shown in the previous charts (Figure 5 and Figure 6). In the Bare Metal configuration, except for Query18 whose performance stayed about the same, the performance of the rest of the queries improved from 2 to 11 times, while the queries in the virtualized configuration ran up to 3 times faster. Note Since the CPU capability varies between the Bare Metal and virtual hosts, the performance boost results varied accordingly. In the Bare Metal configuration, a query could use all of the resources (such as CPU and I/O bandwidth) available. The GridIron TurboChargers offer better IOPS, response times, bandwidth, and therefore higher concurrency for the database. Higher concurrency means a query can spin up a lot more threads at once. The available thread count is much lower for the host in the virtual environment. The Bare Metal configuration delivered an average (across all queries) of 3.2 times the baseline (no GT) performance. This is consistent with the 3.2x reduction in the overall elapsed time that was measured between the baseline and boosted scenarios. The virtualized configuration delivered an average (across all queries) of 2.2 times the baseline (no GT) performance. This is consistent with the 2.2x reduction in overall elapsed time that was measured between the baseline and boosted scenarios. The GridIron TurboChargers provided these performance increases without the disruption and cost of infrastructure replacement or application changes. The bandwidth boost provided by the GridIron TurboChargers can be seen in Figure 7. Bandwidth delivered to the server more than tripled to over 5 GB/s when the TurboChargers were put into boost mode. (Throughput on the left side of the chart is with TurboChargers in pass-through mode and on the right in boost mode.) 18

19 Figure 7. GridIron measured throughput 19

20 Appendices The following appendices provide supporting information about the architecture and test configurations. Appendix A: Detailed performance results by query Figure 8 and Figure 9 show the runtime as it is divisible into the baseline time using the formula: ([baseline time]/ [run time]) or [run time]/ [baseline time] This analysis shows how many times faster the execution is. It is important to note that this chart can be misleading as 1x really means that the execution time is the same. Therefore, to be accurate, the scale should start at 1 and not 0. This chart is included as it better illustrates which queries had the most dramatic performance gain (particularly queries 6, 11, 20, and 21 in the Bare Metal configuration). These queries were the most heavily I/O-bound queries and therefore benefited the most from storage acceleration Performance Multiplier vs. Baseline Query 1 Query 2 Query 3 Query 4 Query 5 Query 6 Query 7 Query 8 Query 9 Query 10 Query 11 Query 12 Query 13 Query 14 Query 15 Query 16 Query 17 Query 18 Query 19 Query 20 Query 21 Bare Metal GridIron Boost % Figure 8. Bare Metal configuration: Performance multiplier versus baseline 20

21 3.0 Performance Multiplier vs. Baseline Query 1 Query 2 Query 3 Query 4 Query 5 Query 6 Query 7 Query 8 Query 9 Query 10 Query 11 Query 12 Query 13 Query 14 Query 15 Query 16 Query 17 Query 18 Query 19 Query 20 Query 21 Virtualized GridIron Boost % Figure 9. Virtualized Oracle configuration: Performance multiplier versus baseline 21

22 Appendix B: Workload query definitions Table 9 is an inventory of the queries executed in the test and a description of the business question they are designed to answer. Table 9. Executed test queries Query Query01 Query02 Query03 Query04 Query05 Query06 Description The Pricing Summary Report Query provides a summary pricing report for all line items shipped as of a given date. The date is within days of the greatest ship date contained in the database. The query lists totals for extended price, discounted extended price, discounted extended price plus tax, average quantity, average extended price, and average discount. These aggregates are grouped by RETURNFLAG and LINESTATUS, and listed in ascending order of RETURNFLAG and LINESTATUS. A count of the number of line items in each group is included. The Minimum Cost Supplier Query finds, in a given region, for each part of a certain type and size, the supplier who can supply it at minimum cost. If several suppliers in that region offer the desired part type and size at the same (minimum) cost, the query lists the parts from suppliers with the highest account balances. For each supplier, the query lists the supplier's account balance, name and nation; the part's number and manufacturer; the supplier's address, phone number and comment information. The Shipping Priority Query retrieves the shipping priority and potential revenue, defined as the sum of l_extendedprice * (1-l_discount), of the orders having the largest revenue among those that had not been shipped as of a given date. Orders are listed in decreasing order of revenue. If more than 10 unshipped orders exist, only the 10 orders with the largest revenue are listed. The Order Priority Checking Query counts the number of orders ordered in a given quarter of a given year in which at least one line item was received by the customer later than its committed date. The query lists the count of such orders for each order priority sorted in ascending priority order. The Local Supplier Volume Query lists for each nation in a region the revenue volume that resulted from line item transactions in which the customer ordering parts and the supplier filling them were both within that nation. The query is run in order to determine whether to institute local distribution centers in a given region. The query considers only parts ordered in a given year. The query displays the nations and revenue volume in descending order by revenue. Revenue volume for all qualifying line items in a particular nation is defined as sum (l_extendedprice * (1 - l_discount)). The Forecasting Revenue Change Query considers all the line items shipped in a given year with discounts between DISCOUNT-0.01 and DISCOUNT The query lists the amount by which the total revenue would have increased if these discounts had been eliminated for line items with l_quantity less than quantity. Note that the potential revenue increase is equal to the sum of [l_extendedprice * l_discount] for all line items with discounts and quantities in the qualifying range. 22

23 Query Query07 Query08 Query09 Query10 Query11 Query12 Query13 Description The Volume Shipping Query finds, for two given nations, the gross discounted revenues derived from line items in which parts were shipped from a supplier in either nation to a customer in the other nation during 1995 and The query lists the supplier nation, the customer nation, the year, and the revenue from shipments that took place in that year. The query orders the answer by Supplier nation, Customer nation, and year (all ascending). The market share for a given nation within a given region is defined as the fraction of the revenue, the sum of [l_extendedprice * (1-l_discount)], from the products of a specified type in that region that was supplied by suppliers from the given nation. The query determines this for the years 1995 and 1996 presented in this order. The Product Type Profit Measure Query finds, for each nation and each year, the profit for all parts ordered in that year that contain a specified substring in their names and that were filled by a supplier in that nation. The profit is defined as the sum of [(l_extendedprice*(1-l_discount)) - (ps_supplycost * l_quantity)] for all line items describing parts in the specified line. The query lists the nations in ascending alphabetical order and, for each nation, the year and profit in descending order by year (most recent first). The Returned Item Reporting Query finds the top 20 customers, in terms of their effect on lost revenue for a given quarter, who have returned parts. The query considers only parts that were ordered in the specified quarter. The query lists the customer's name, address, nation, phone number, account balance, comment information and revenue lost. The customers are listed in descending order of lost revenue. Revenue lost is defined as sum (l_extendedprice*(1-l_discount)) for all qualifying line items. The Important Stock Identification Query finds, from scanning the available stock of suppliers in a given nation, all the parts that represent a significant percentage of the total value of all available parts. The query displays the part number and the value of those parts in descending order of value. The Shipping Modes and Order Priority Query counts, by ship mode, for line items actually received by customers in a given year, the number of line items belonging to orders for which the l_receiptdate exceeds the l_commitdate for two different specified ship modes. Only line items that were actually shipped before the l_commitdate are considered. The late line items are partitioned into two groups, those with priority URGENT or HIGH, and those with a priority other than URGENT or HIGH. This query determines the distribution of customers by the number of orders they have made, including customers who have no record of orders, past or present. It counts and reports how many customers have no orders, how many have 1, 2, 3, etc. A check is made to ensure that the orders counted do not fall into one of several special categories of orders. Special categories are identified in the order comment column by looking for a particular pattern. 23

24 Query Query14 Query15 Query16 Query17 Query18 Query19 Query20 Query21 Description The Promotion Effect Query determines what percentage of the revenue in a given year and month was derived from promotional parts. The query considers only parts actually shipped in that month and gives the percentage. Revenue is defined as (l_extendedprice * (1-l_discount)). The Top Supplier Query finds the supplier who contributed the most to the overall revenue for parts shipped during a given three month interval. In case of a tie, the query lists all suppliers whose contribution was equal to the maximum, presented in supplier number order. The Parts/Supplier Relationship Query counts the number of suppliers who can supply parts that satisfy a particular customer's requirements. The customer is interested in parts of eight different sizes as long as they are not of a given type, not of a given brand, and not from a supplier who has had complaints registered at the Better Business Bureau. Results must be presented in descending count and ascending brand, type, and size. The Small-Quantity-Order Revenue Query considers parts of a given brand and with a given container type and determines the average line item quantity of such parts ordered for all orders (past and pending) in the 7-year data-base. What would be the average yearly gross (undiscounted) loss in revenue if orders for these parts with a quantity of less than 20% of this average were no longer taken? The Large Volume Customer Query finds a list of the top 100 customers who have ever placed large quantity orders. The query lists the customer name, customer key, the order key, date and total price and the quantity for the order. The Discounted Revenue query finds the gross discounted revenue for all orders for three different types of parts that were shipped by air or delivered in person. Parts are selected based on the combination of specific brands, a list of containers, and a range of sizes. The Potential Part Promotion Query identifies suppliers in a particular nation having selected parts that may be candidates for a promotional offer. The query identifies suppliers who have an excess of a given part available; an excess is defined to be more than 50% of the parts like the given part that the supplier shipped in a given year for a given nation. Only parts whose names share a certain naming convention are considered. The Suppliers Who Kept Orders Waiting query identifies suppliers, for a given nation, whose product was part of a multisupplier order (with current status of 'F') where they were the only supplier who failed to meet the committed delivery date. 24

25 Appendix C: GridIron TurboCharger zoning The GridIron TurboChargers (GT) are logically inserted between the server(s) and storage array(s) by zoning. Instead of a single direct zone, a front-end zone (between the server and front-end ports of the GT) and a back-end zone (between the array and the back-end ports of the GT) is established. The GT uses a FC proxy to create a set of virtual initiators and virtual targets. The frontend zone includes: Host HBA port GT real front-end port GT virtual target In this way, the host believes it is connected directly to the array. The back-end zone includes: Server SP port GT real back-end port GT virtual initiator Likewise, the array believes it is connected directly to the host. The GT proxies the communication between the virtual initiator and the virtual target. The only requirement for this configuration is that the switch used support node-port ID virtualization (NPIV). GT zoning is easily accomplished by way of a GridIron tool, GT Planner, which, given some basic information, including host and target World Wide Port Names (WWPNs), generates a topology graph and scripts. Real to virtual WWPN mapping: FabricA Fabric: FabricA Table 10. Aliases and real to virtual WWPN mapping in FabricA Device Real WWPN TurboCharger Port Virtual WWPN z_bubba_15k_h0p0_be 21:00:00:24:ff:3a:fb:02 gi_itchy_b1 B1 21:b1:00:23:73:00:94:00 z_bubba_15k_h0p0_fe 21:00:00:24:ff:3b:01:e2 gi_itchy_f1 B1 21:f1:00:23:73:00:94:00 z_bubba_15k_h1p0_be 21:00:00:24:ff:3a:fe:ba gi_itchy_b1 B1 21:b1:00:23:73:00:94:00 z_bubba_15k_h1p0_fe 21:00:00:24:ff:3b:01:e2 gi_itchy_f3 f3 21:f3:00:23:73:00:94:00 z_bubba_15k_h2p0_be 21:00:00:24:ff:3a:fe:ba gi_scratchy_b1 b1 21:b1:00:23:73:00:95:00 z_bubba_15k_h2p0_fe 50:02:37:30:09:50:00:05 gi_scratchy_f1 f1 "21:f1:00:23:73:00:95:00 z_bubba_15k_h3p0_be 21:00:00:24:ff:3a:fe:b8 gi_scratchy_b1 b1 21:b1:00:23:73:00:94:00 z_bubba_15k_h3p0_fe 50:02:37:30:09:50:00:07 gi_scratchy_f3 F3 21:f3:00:23:73:00:94:00 25

26 Zones: FabricA zone: z_bubba_15k_h0p0_be gi_itchy_b1; t_cx4960_cas0p2; vi_itchy_bubba_h0p0 zone: z_bubba_15k_h0p0_fe gi_itchy_f1; h_bubba_h0p0; vt_itchy_cx4_cas0p2 zone: z_bubba_15k_h1p0_be gi_itchy_b1; t_cx4960_cas1p2; vi_itchy_bubba_h1p0 zone: z_bubba_15k_h1p0_fe h_bubba_h1p0; vt_itchy_cx4_cas1p2; gi_itchy_f3 zone: z_bubba_15k_h2p0_be gi_scratchy_b1; t_cx4960_cbs0p2; vi_scrch_bubba_h2p0 zone: z_bubba_15k_h2p0_fe gi_scratchy_f1; h_bubba_h2p0; vt_scrch_cx4_cbs0p2 zone: z_bubba_15k_h3p0_be gi_scratchy_b1; t_cx4960_cbs1p2; vi_scrch_bubba_h3p0 zone: z_bubba_15k_h3p0_fe h_bubba_h3p0; vt_scrch_cx4_cbs1p2; gi_scratchy_f3 26

27 Scripts: FabricA alicreate "gi_itchy_b1", "21:b1:00:23:73:00:94:00" alicreate "gi_itchy_f1", "21:f1:00:23:73:00:94:00" alicreate "gi_itchy_f3", "21:f3:00:23:73:00:94:00" alicreate "gi_scratchy_b1", "21:b1:00:23:73:00:95:00" alicreate "gi_scratchy_f1", "21:f1:00:23:73:00:95:00" alicreate "gi_scratchy_f3", "21:f3:00:23:73:00:95:00" alicreate "h_bubba_h0p0", "21:00:00:24:ff:3a:fb:02" alicreate "h_bubba_h1p0", "21:00:00:24:ff:3b:01:e2" alicreate "h_bubba_h2p0", "21:00:00:24:ff:3a:fe:ba" alicreate "h_bubba_h3p0", "21:00:00:24:ff:3a:fe:b8" alicreate "t_cx4960_cas0p2", "50:06:01:60:3b:20:6f:a5" alicreate "t_cx4960_cas1p2", "50:06:01:62:3b:20:6f:a5" alicreate "t_cx4960_cbs0p2", "50:06:01:68:3b:20:6f:a5" alicreate "t_cx4960_cbs1p2", "50:06:01:6a:3b:20:6f:a5" alicreate "vi_itchy_bubba_h0p0", "50:02:37:30:09:40:00:01" alicreate "vi_itchy_bubba_h1p0", "50:02:37:30:09:40:00:03" alicreate "vi_scrch_bubba_h2p0", "50:02:37:30:09:50:00:05" alicreate "vi_scrch_bubba_h3p0", "50:02:37:30:09:50:00:07" alicreate "vt_itchy_cx4_cas0p2", "50:02:37:30:09:40:00:11" alicreate "vt_itchy_cx4_cas1p2", "50:02:37:30:09:40:00:13" alicreate "vt_scrch_cx4_cbs0p2", "50:02:37:30:09:50:00:15" alicreate "vt_scrch_cx4_cbs1p2", "50:02:37:30:09:50:00:17" 27

28 Real to virtual WWPN mapping: FabricB Fabric: Fabric Table 11. Aliases and real to virtual WWPN mapping in FabricB Device Real WWPN TurboCharger Port Virtual WWPN z_bubba_15k_h0p1_be 21:00:00:24:ff:3a:fb:03 gi_itchy_b2 B2 21:b2:00:23:73:00:95:00 z_bubba_15k_h0p1_fe 50:02:37:30:09:40:00:02 gi_itchy_f2 F2 21:f2:00:23:73:00:94:00 z_bubba_15k_h1p1_be 21:00:00:24:ff:3b:01:e3 gi_itchy_b2 B2 21:b2:00:23:73:00:95:00 z_bubba_15k_h1p1_fe 50:02:37:30:09:40:00:04 gi_itchy_f4 F4 21:f4:00:23:73:00:94:00 z_bubba_15k_h2p1_be 21:00:00:24:ff:3a:fe:bb gi_scratchy_b2 B2 21:b2:00:23:73:00:95:00 z_bubba_15k_h2p1_fe 50:02:37:30:09:50:00:06 gi_scratchy_f2 F2 21:f2:00:23:73:00:95:00 z_bubba_15k_h3p1_be 21:00:00:24:ff:3a:fe:b9 gi_scratchy_b2 B2 21:b2:00:23:73:00:94:00 z_bubba_15k_h3p1_fe 50:02:37:30:09:50:00:08 gi_scratchy_f4 F4 21:f4:00:23:73:00:95:00 Zones: FabricB zone: z_bubba_15k_h0p1_be gi_itchy_b2; t_cx4960_cas0p3; vi_itchy_bubba_h0p1 zone: z_bubba_15k_h0p1_fe gi_itchy_f2; h_bubba_h0p1; vt_itchy_cx4_cas0p3 zone: z_bubba_15k_h1p1_be gi_itchy_b2; t_cx4960_cas1p3; vi_itchy_bubba_h1p1 zone: z_bubba_15k_h1p1_fe h_bubba_h1p1; vt_itchy_cx4_cas1p3; gi_itchy_f4 zone: z_bubba_15k_h2p1_be gi_scratchy_b2; t_cx4960_cbs0p3; vi_scrch_bubba_h2p1 zone: z_bubba_15k_h2p1_fe gi_scratchy_f2; h_bubba_h2p1; vt_scrch_cx4_cbs0p3 zone: z_bubba_15k_h3p1_be gi_scratchy_b2; t_cx4960_cbs1p3; vi_scrch_bubba_h3p1 zone: z_bubba_15k_h3p1_fe h_bubba_h3p1; vt_scrch_cx4_cbs1p3; gi_scratchy_f4 28

29 Scripts: FabricB alicreate "gi_itchy_b2", "21:b2:00:23:73:00:94:00" alicreate "gi_itchy_f2", "21:f2:00:23:73:00:94:00" alicreate "gi_itchy_f4", "21:f4:00:23:73:00:94:00" alicreate "gi_scratchy_b2", "21:b2:00:23:73:00:95:00" alicreate "gi_scratchy_f2", "21:f2:00:23:73:00:95:00" alicreate "gi_scratchy_f4", "21:f4:00:23:73:00:95:00" alicreate "h_bubba_h0p1", "21:00:00:24:ff:3a:fb:03" alicreate "h_bubba_h1p1", "21:00:00:24:ff:3b:01:e3" alicreate "h_bubba_h2p1", "21:00:00:24:ff:3a:fe:bb" alicreate "h_bubba_h3p1", "21:00:00:24:ff:3a:fe:b9" alicreate "t_cx4960_cas0p3", "50:06:01:61:3b:20:6f:a5" alicreate "t_cx4960_cas1p3", "50:06:01:63:3b:20:6f:a5" alicreate "t_cx4960_cbs0p3", "50:06:01:69:3b:20:6f:a5" alicreate "t_cx4960_cbs1p3", "50:06:01:6b:3b:20:6f:a5" alicreate "vi_itchy_bubba_h0p1", "50:02:37:30:09:40:00:02" alicreate "vi_itchy_bubba_h1p1", "50:02:37:30:09:40:00:04" alicreate "vi_scrch_bubba_h2p1", "50:02:37:30:09:50:00:06" alicreate "vi_scrch_bubba_h3p1", "50:02:37:30:09:50:00:08" alicreate "vt_itchy_cx4_cas0p3", "50:02:37:30:09:40:00:12" alicreate "vt_itchy_cx4_cas1p3", "50:02:37:30:09:40:00:14" alicreate "vt_scrch_cx4_cbs0p3", "50:02:37:30:09:50:00:16" alicreate "vt_scrch_cx4_cbs1p3", "50:02:37:30:09:50:00:18" 29

30 TurboCharger scripts TurboCharger: Itchy ==== BEGIN TurboCharger: Itchy ==== wwn-map port real h_bubba_h0p0 virtual gi_itchy_vi_bubba_h0p0 interface b1 wwn-map port real h_bubba_h1p0 virtual gi_itchy_vi_bubba_h1p0 interface b1 wwn-map port real h_bubba_h0p1 virtual gi_itchy_vi_bubba_h0p1 interface b2 wwn-map port real h_bubba_h1p1 virtual gi_itchy_vi_bubba_h1p1 interface b2 wwn-map port real t_cx4960_cas0p2 virtual gi_itchy_vt_cx4_cas0p2 interface f1 wwn-map port real t_cx4960_cas1p2 virtual gi_itchy_vt_cx4_cas1p2 interface f3 wwn-map port real t_cx4960_cas0p3 virtual gi_itchy_vt_cx4_cas0p3 interface f2 wwn-map port real t_cx4960_cas1p3 virtual gi_itchy_vt_cx4_cas1p3 interface f4 it-nexus initiator h_bubba_h0p0 interface f1 target t_cx4960_cas0p2 it-nexus initiator h_bubba_h1p0 interface f3 target t_cx4960_cas1p2 it-nexus initiator h_bubba_h0p1 interface f2 target t_cx4960_cas0p3 it-nexus initiator h_bubba_h1p1 interface f4 target t_cx4960_cas1p3 ==== END TurboCharger: Itchy ==== TurboCharger: Scratchy ==== BEGIN TurboCharger: Scratchy ==== wwn-map port real h_bubba_h2p0 virtual gi_scrh_vi_bubba_h2p0 interface b1 wwn-map port real h_bubba_h3p0 virtual gi_scrh_vi_bubba_h3p0 interface b1 wwn-map port real h_bubba_h2p1 virtual gi_scrh_vi_bubba_h2p1 interface b2 wwn-map port real h_bubba_h3p1 virtual gi_scrh_vi_bubba_h3p1 interface b2 wwn-map port real t_cx4960_cbs0p2 virtual gi_scrh_vt_cx4_cbs0p2 interface f1 wwn-map port real t_cx4960_cbs1p2 virtual gi_scrh_vt_cx4_cbs1p2 interface f3 wwn-map port real t_cx4960_cbs0p3 virtual gi_scrh_vt_cx4_cbs0p3 interface f2 wwn-map port real t_cx4960_cbs1p3 virtual gi_scrh_vt_cx4_cbs1p3 interface f4 30

31 it-nexus initiator h_bubba_h2p0 interface f1 target t_cx4960_cbs0p2 it-nexus initiator h_bubba_h3p0 interface f3 target t_cx4960_cbs1p2 it-nexus initiator h_bubba_h2p1 interface f2 target t_cx4960_cbs0p3 it-nexus initiator h_bubba_h3p1 interface f4 target t_cx4960_cbs1p3 ==== END TurboCharger: Scratchy ==== 31