Acceleration of UNIX Database Migration to Dell Servers with Sybase Replication Server

Transcription

1 Acceleration of UNIX Database Migration to Dell Servers with Sybase Replication Server Enterprise Product Group (EPG) Dell White Paper By Jack Farley and Mike Wallace, Sybase Inc., and Dave Jaffe and Todd Muirhead, Dell Inc. June 2005

2 Contents Executive Summary... 4 Introduction... 5 Migrating Sybase Databases... 5 The Systems... 7 Sybase... 9 The Application The Database Schema The Stored Procedures The Online Transaction Processing Driver Application Results Data Migration...15 Replication Performance Benefits of Replication Technology for Migrations Conclusions Appendix A. disk_init.sql Appendix B. create_db.sql Appendix C. create_tables.sql Appendix D. create_ind.sql June 2005 Page 2 Dell Enterprise Product Group

3 Tables Table 1: Comparison of Sun Fire V440 vs the Dell PowerEdge Table 2: Dell/EMC Storage... 8 Table 3: Database Configuration Parameters... 9 Table 4: DVD Store Database Schema Table 5: Migration Timings Table 6: Replication Synchronization Timings Table 7: Results Figures Figure 1 - Cross Platform Dump and Load Configuration Figure 2 - Initial Replication Server Architecture Figure 3 - Replication Server Architecture after migration (Failback enabled) June 2005 Page 3 Dell Enterprise Product Group

4 Section 1 Executive Summary Sybase Adapter Server Enterprise (ASE) database software is available for a wide range of operating systems and hardware platforms. Tools are included with the Sybase ASE database that make it easy to move or migrate databases from one operating system or platform to another. In the newest version of Sybase ASE, version , enhancements were made to provide additional features and methods to perform data migrations while helping to ensure business continuity. In order to document and test these processes, a team of Dell and Sybase engineers migrated a 100 GB Sybase ASE database from a Unix server from Sun Microsystems Inc. (a Sun Fire V440 with four 1.28 GHz UltraSPARC IIIi processors running the Sun Solaris operating system) to a Dell PowerEdge 2850 with dual 3.4 GHz Xeon processors installed with the Red Hat Enterprise Linux 3.0 operating system. Details of the database migration are presented in this paper. The data migration from a Sun FireV440 running Solaris 9 to a Dell PowerEdge 2850 running Red Hat Enterprise Linux 3 AS was implemented using Sybase ASE with the newly introduced Cross Platform Dump and Load feature as well as Sybase Replication Server. This software: minimizes system unavailability during the initial data conversions keeps the migration source and target systems in sync which facilitates the parallel testing of systems provides a fallback system to help keep the business running in case of a migration failure The results of the migration tests showed that an online transaction processing database could be migrated from a Unix server to a Dell/Linux server with only 40 minutes of downtime and with full protection against either system having failures. Additionally, Sybase transaction processing rates increased 50% at the same CPU utilization rate after migration from the Sun Fire V440 server to the Dell PowerEdge See Section 6 for discussion of this performance comparison. June 2005 Page 4 Dell Enterprise Product Group

5 Section 2 Introduction Sybase Inc. began in 1984 with the development of Sybase SQL Server (today called Adaptive Server Enterprise (ASE)). During the past 20 years, Sybase has evolved from strictly a Database company, to a broader Information Management Company. Today, Sybase enables the Unwired Enterprise by delivering enterprise and mobile infrastructure, development and integration software solutions. Organizations can attain maximum value from their data assets by getting the right information to the right people at the right time and place. Some of the world s most critical data in commerce, finance, vernment, healthcare, and defense runs on Sybase. In today s world of the Internet, businesses cannot afford to take their systems down for lengthy database migrations. Sybase Replication Server provides near real-time movement of data between heterogeneous database sources. With this ability, customers can set up and maintain a warm standby database to provide availability during a failure, or just to provide maintenance windows for a 24x7 application. It is this technology that allows Sybase to migrate across platforms with almost no downtime. Historically, platform changes have been difficult from a database perspective because they generally required a large amount of down time in order to move the data from the old server to the new server. Sybase s Bulk Copy (BCP) tool has been used to migrate databases from one platform to another for many years. With the addition of the Cross Platform Dump and Load (XPDL) tool in Sybase Adaptive Server Enterprise (ASE) , that process is made a little easier. These migration tools allow customers to decide what platform to run Sybase on based on their current set of requirements and budgets and not based on what platform Sybase has been run on in the past. Migrating Sybase Databases Sybase ASE Backup Server was enhanced in version to support a cross platform database load. With this enhancement, customers can load any ASE database (version 12.0 and newer with the same server page size) into a new ASE server regardless of the platform of the original database. This is significant as the byte ordering (endian structure) is different on some platforms. During the test described in this paper, the XPDL feature was used to load an ASE database running on a Sun Fire V440 into an ASE database on a Dell PowerEdge XPDL is the tool that dumps and loads an entire database and Bulk Copy (BCP) is the tool used to import and export data from a Sybase database at the table level. XPDL and BCP can be used to move data in conjunction with Sybase June 2005 Page 5 Dell Enterprise Product Group

6 Replication Server to provide a method for migrating a database with almost no down time. The following steps accomplish this: Set up Replication Server with production databases Migrate data to new platform (old system operational during migration) Drain replicated transactions from the queues Shutdown application to old operational system Allow remaining transactions to be replicated Restart application on new operational system Transactions are replicated to old system to provide a failback scenario. Sybase Replication Server was used during the test described in this paper. June 2005 Page 6 Dell Enterprise Product Group

7 Section 3 The Systems This study involved migrating a large (100 GB) database from a 4-processor system, the Sun Fire V440, to a Dell 2-processor system, the PowerEdge 2850, with as little downtime as possible. The processors used for both systems were not the fastest speed offered by each vendor at the time of the tests (Feb. 2005) four 1.28 GHz/1 MB L2 cache Ultra SPARC IIIi processors in the Sun Fire V440 and two 3.4 GHz / 1 MB L2 cache Xeon processors in the Dell PowerEdge 2850, both servers with 8 GB of memory. 1 Details are shown in Table 1. Operating System CPU Sun Fire V440 Dell PowerEdge 2850 Solaris 9 12/03 RedHat Enterprise Linux 3 4x 1.28 GHz UltraSPARC IIIi w/ 1MB L2 cache Memory 8 GB 8 GB Internal Disks NICs 4x 73 GB 10K RPM Ultra320 SCSI 2x 10/100/ Mb/s (Internal) Disk Controller On-board SCSI PERC 4ei Fiber Channel HBA Remote Management Service Hardware Price (without HBAs) Price of Database Licenses ($34,995/CPU for Sun Solaris and $24,995/CPU for Linux) 2x 3.4 GHz/1 MB L2 Cache Xeon 2x 73 GB 10K RPM Ultra320 SCSI 2x 10/100/ Mb/s (Internal) 2x QLA x QLA 2340 Serial Management Card 3-Year Gold Support w/ 7x24 Onsite $27,339 $12,070 $139,980 $49,990 Total Price $167,319 $62,060 Dell Remote Access Card, Version IV, without Modem 3-Year Gold Support w/ 7x24 Onsite 3 Source 11/29/ /9/05 Table 1: Comparison of Sun Fire V440 vs the Dell PowerEdge 2850 June 2005 Page 7 Dell Enterprise Product Group

8 List prices of the two systems are shown in Table 1. The list price of the Sun system is from November 2004 because Sun stopped offering the 1.28GHz Ultra SPARC IIIi processors after the testing for this paper was completed. The list price of the database manager license, based on processor count, is included in the calculation of the total price and is shown in the table. Sybase pricing is based in part on the platform and Sun Solaris licenses are priced higher per CPU than Linux x86 licenses. The operating system cost is included in the server hardware price. Pricing of the configurations did not include the SAN hardware or software. RedHat Enterprise Linux 3 was installed on the Dell PowerEdge 2850 and Solaris 9 12/03 was installed on the Sun Fire V440. The Sun Fire V440 uses a 64-bit architecture that allows a flat addressing model to address the entire 8 GB of memory installed in the server directly. The 32-bit architecture of the Dell 2850 requires some additional configuration to enable access to the full 8 GB. The shmmax kernel parameter was increased to and an in memory file system of 4g was mounted. This was accomplished by adding the following to the /etc/rc.local file: sysctl -w kernel.shmmax= mount -t shm shmfs -o size=4g /dev/shm Storage for both the Dell and Sun servers was provided by a Storage Area Network (SAN)-attached Dell/EMC CX700 fibre channel storage array. Each server was attached to the SAN via two QLogic Host Bus Adapters. Each server was assigned to a set of storage logical units (LUNs) that used the same number and type of disk drives. The EMC compatibility matrix (available at which includes both the Dell PowerEdge 2850 and Sun Fire V440, was consulted to ensure that the proper versions of drivers and firmware were utilized on both the Dell and Sun servers. EMC PowerPath software provides load balancing and failover for the dual HBAs that were present in both systems. The storage components used for both servers in the test are shown in Table 2. Controller Disk Enclosures Disks LUNs Software Table 2: Dell/EMC Storage 1 Dell/EMC CX700 3 Dell/EMC DAE2 40 x 73 GB/ 10K RPM 3 10-Disk RAID 1/0 LUNs for Data 2 2-Disk RAID 1 LUN for Logs 1 5-Disk RAID 0 for Temporary Data Staging for Loading 1 HotSpare Disk Navisphere Manager Access Logix PowerPath June 2005 Page 8 Dell Enterprise Product Group

9 Section 4 Sybase Sybase Adaptive Server Enterprise (ASE) is a powerful data management platform for high performance business applications. The latest version of Sybase ASE makes it even easier to deploy and maintain, with enhanced operational scalability to support tougher workloads with fewer resources. The non-default database initialization parameters that were used are listed in Table 3. Parameter Sun Fire V440 Dell PowerEdge 2850 Extended Cache Size Named Cache: Log Cache 300M 300M Named Cache: Default Data Cache 2.2GB 1.7GB 16K Buffer Pool 300M 300M Local Cache Partition Num 4 2 Named Cache: Product Cache 200M 200M Local Cache Partition Num 4 2 Procedure Cache Size Max Network Packet Size 8192 Max Memory Additional Network Memory Number of Engines (Max/Start/Run) 4 / 2 / 3 2 / 2 / 2 Number of Sort Buffers Disk I/O Structures Max Async I/Os per Engine Max Async I/Os per Server Heap Memory per User Table 3: Database Configuration Parameters The configuration of the ASE server utilized a few ASE features in order to improve performance of the application. The performance features used in this test were: June 2005 Page 9 Dell Enterprise Product Group

10 Named caches with partitioning Row level locking on the Orders and OrderLines tables Larger network packet sizes were used for the initial loading of tables into the primary server. If BCP s are used to migrate the data, the Linux server should also be configured for larger packet sizes during the BCP process The ASE features used to aid in the migration of the data from the Sun platform to the Linux platform were: The Cross Platform Dump and Load (XPDL) feature of ASE was used on the Linux platform to allow us to migrate the database (see figure 1). Unix Configuration Linux Configuration Sun Fire V440 Solaris 9 Dell PowerEdge 2850 RedHat Enterprise Linux 3.0 Sybase ASE Cross Platform Dump and Load (XPDL) Sybase ASE SAN SAN Source DB Target DB Figure 1 - Cross Platform Dump and Load Configuration Sybase Replication Server helps simplify data movement and synchronization across the enterprise. It allows DBA s to quickly set up redundant disaster recovery sites and synchronize data across heterogeneous database platforms -- Sybase ASE, Oracle, IBM DB2 and Microsoft SQL Server. By moving and synchronizing data easily, companies gain economic value by sharing data located in application silos with other applications when and where needed. Replication Server provides the following capabilities: Provides transaction replication maintaining the transactional integrity of all replication information June 2005 Page 10 Dell Enterprise Product Group

11 Helps ensure delivery of data with fault tolerant store and forward queues Non-intrusive to native database applications Bi-directional replication with Sybase and heterogeneous databases Supports system migration to the web and deployment of new applications on Linux Works on Linux platforms, as specified in the Sybase Product Certification for Linux OS In the test, Sybase Replication Server maintained the transactional integrity between the Linux Server ASE and the Sun Server ASE by moving the transactions using the Warm Standby feature as illustrated in figure 2. This capability allowed for the migration to be scheduled without requiring a prolonged downtime for the migration of the data. Unix Configuration Linux Configuration Dell PowerEdge 2850 RedHat Linux 3.0 Sun V440 Solaris 9 Sybase ASE Sybase Replication Server 12.6 Sybase ASE SAN SAN Source DB Replication Storage Target DB Figure 2 - Initial Replication Server Architecture For this test, the Cross Platform Dump and Load was used to migrate the data from the Sun server to the Linux server. This process required an outage time in order to take a dump of the primary database in single user mode. Once the dump was completed, transactions were resumed on the primary database, capturing the results in the Replication Server stable queues. After the load was completed, indexes were rebuilt on the Linux server and the stored messages were played into the Linux server. Once the migration was completed, the replication environment was reversed so that transactions on the Linux server were captured and moved over to the Sun server (see figure 3), providing a fallback scenario in the event of problems. This June 2005 Page 11 Dell Enterprise Product Group

12 is a capability of the Warm Standby feature of ASE that allows the switch of the active database. Unix Configuration Linux Configuration Dell PowerEdge 2850 RedHat Linux 3.0 Sun V440 Solaris 9 Sybase ASE Sybase Replication Server 12.6 Sybase ASE SAN SAN Source DB Replication Storage Target DB Figure 3 - Replication Server Architecture after migration (Failback enabled) Because Replication Server provides heterogeneous database access, a similar architecture can be used in migrating other databases such as Oracle, IBM UDB, and MS SQL. June 2005 Page 12 Dell Enterprise Product Group

13 Section 5 The Application The application used in this migration models the database back end of an online transaction-processing (OLTP) environment. The database (100 GB total size), representing an online DVD store with 1 million DVD titles, was driven by a C# language program simulating users logging in to the online store, browsing for DVDs by title, author or catery, and then finally submitting an order. The driver program measures the number of orders per minute that the database can handle as well as the total response time as seen by the simulated end users. The Database Schema The DVD store was comprised of five main tables and one other (see Table 4). Table Columns Number of Rows Customers Orders CUSTOMERID, FIRSTNAME, LASTNAME, ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY, REGION, , PHONE, CREDITCARD, CREDITCARDEXPIRATION, USERNAME, PASSWORD, AGE, INCOME, GENDER, PROD_ID_IDX, PROD_ID1, PROD_ID2 PROD_ID10 ORDERID, ORDERDATE, CUSTOMERID, NETAMOUNT, TAX, TOTALAMOUNT 200 million 120 million Orderlines ORDERLINEID, ORDERID, PROD_ID, QUANTITY, ORDERDATE 600 million Products Reorder PROD_ID, CATERY, TITLE, ACTOR, PRICE, QUAN_IN_STOCK, SPECIAL, COMMON_PROD_ID1, COMMON_RATING1, COMMON_PROD_ID2, COMMON_RATING2, COMMON_PROD_ID3, COMMON_RATING3, SALES PROD_ID, DATE_LOW, QUAN_LOW, DATE_REORDERED, QUAN_REORDERED, DATE_EXPECTED Cateries CATERY, CATERYNAME 16 Table 4: DVD Store Database Schema The Customers table was pre-populated with two hundred million customers, one hundred million US customers and one hundred million customers from the rest of the world. The Orders table was pre-populated with ten million orders per month for a full year. The Orderlines table was pre-populated with an average of 5 items per order. The Products table contained one million DVD titles. Finally, the Cateries table listed the 16 DVD cateries. The scripts used to create the database are shown in Appendix A through Appendix D. 1 million Variable June 2005 Page 13 Dell Enterprise Product Group

14 The Stored Procedures The DVD Store database was managed through six stored procedures. The first two were used during the login phase. If the customer was a returning customer, Login was used to retrieve the customer s information, in particular the CUSTOMERID. If the customer was a new customer, New_customer was used to create a new row in the Customers table with the user s data. Following the login phase the customer might search for a DVD by catery, actor or title. Browse_by_catery, Browse_by_actor and Browse_by_title implemented these, respectively. Finally, after the user had made his or her selections, the Purchase stored procedure was called to complete the transaction. The Online Transaction Processing Driver Application A multi-threaded driver program was written to model an order entry or online transaction processing (OLTP) workload. Each thread of the OLTP driver application connected to the database and made a series of stored procedure calls that simulated users logging in, browsing and purchasing. Since there were no simulated user think times or key times, the database connections were kept full, simulating what happens in a real multi-tiered application where some small number of connections are pooled and shared among the web servers that may be handling thousands of simultaneous customers. Thus a realistic simulation of database activity was achieved without needing to model thousands of users. Each thread of the OLTP driver modeled a series of customers ing through the entire sequence of logging in, browsing the catalog several ways and finally purchasing the selected items. Each completed sequence by a customer counted as a single order. The driver measured order rates and the average response time to complete each order. June 2005 Page 14 Dell Enterprise Product Group

15 Section 6 Results The study had three separate components. The first piece focused on the actual data migration. The second piece examined in detail the use of Sybase Replication Server to keep the source and target servers in synch during the migration. And the third piece looked at the database performance before and after the migration Data Migration After all software was installed and the Sun Fire V440 database was populated, the migration process was initiated. The migration consisted of (1) taking a backup of the Sun Fire V440 database, (2) data replication that was automatically triggered upon the completion of the backup, (3) loading the backed-up database to the Dell PE2850, (4) converting the data due to the endian change, and (5) switching the users over to the Dell PE2850. The initial Sun Fire V440 database backup took 40 minutes. This was the ONLY time that the production database was unavailable to end users. While normally database backups do not require any system unavailability, in order to use the cross platform dump and load capability (XPDL) for a system where an endian change is required, an outage must be taken. Following the Sun Fire V440 database backup and re-enabling end-user access, the database was loaded to the Dell PE2850. Due to the endian change and the necessity to convert data and drop and rebuild indexes in order to ensure accuracy, the complete XPDL process took 14 hours. This consisted of 32 minutes to load the database, 2 hours 28 minutes to convert the data tables and 11 hours 5 minutes to completely drop and recreate all indexes. It was noted by the authors after the index rebuilds were completed that the with sorted data option had not been used, and therefore the time to rebuild the indexes was larger than should be required. Following the completion of the XPDL process the Replication Server connection to the Dell PE2850 was enabled and the two systems brought in to synchronization. Timings are shown in Table 5. June 2005 Page 15 Dell Enterprise Product Group

16 Conversion step Timing Notes Database Backup 40 Min This was the only time that the system was unavailable to end-users Database load Data Endian Conversion 32 Min 2 hr 28 min Index Re-create 11 hr 5 min This will vary based upon the number of indexes involved End-User Switch Table 5: Migration Timings 1 Min Replication Several tests were run to specifically test the ability of Sybase s Replication Server to completely catch up after waiting for the XPDL process to complete. The primary test for Replication Server synchronization timing consisted of running the DVD Store order workload described in Section 5 against the Sun Fire V440 system while the Replication Server connection to the Dell PE2850 was disabled. This would cause the completed transactions to queue in Replication Server queues, which would occur during the conversion process. After a significant number of transactions were queued in Replication Server, the connection to the Dell PE2850 was enabled while keeping a high transaction rate on the Sun Fire V440. The initial transaction rate at the Sun Fire V440, while the Replication Server connection to the Dell PE2850 was disabled, was 4924 transactions per minute for one hour. All of these transactions were queued in Replication Server. After the initial batch of transactions were run and queued in Replication Server, additional transactions were applied to the Sun Fire V440 system while the Replication Server connection to the Dell PE2850 was enabled and the previously queued transactions began to be applied. This would be the same situation as getting the systems in sync while maintaining end user data access to the original system. The transaction rate on the Sun Fire V440 system for this portion of the test was also 4924 transactions per minute for one hour. During this test, the initial batch of queued transactions was completely applied to the Dell PE2850 in 21 minutes. This shows that Replication Server was applying transactions to the Dell Linux system almost 3 times faster than they were initially run against the Sun Fire V440 system, thus providing a smooth catch-up. Once the Dell PE2850 was completely in sync with the Sun Fire V440 and it was determined that it was time to switch production over to the Dell PE2850 environment, it took less than one minute to stop accessing the Sun Fire V440, begin accessing the Dell PE2850 AND switch Replication Server so that all June 2005 Page 16 Dell Enterprise Product Group

17 transactions occurring on the Dell PE2850 production system were then being replicated back to the Sun Fire V440 system, providing a fallback environment. Timings for Replication Server are shown in Table 6. Replication Sync Test Replication Queue Buildup Replication Queue catchup 4924 transactions per minute Initial 1 st hour s queued transactions 2 nd hour s transactions caught up to near real-time replication Table 6: Replication Synchronization Timings 1 hr 21 min 10 min Time Performance The performance of Sybase ASE on both the Sun Fire V440 system and the Dell PE2850 system was measured before and after the migration using the tests described in Section 5 herein. The Online Transaction Processing Driver Application was used to send orders to the Sybase database, first while it was located on the Sun server, and then after the database had been migrated to the Dell server. In each case enough database connections were opened to drive the database server to the same CPU utilization (76%, a typical loading level used by database administrators to allow headroom for order spikes). The driver application measured the orders per minute handled by each database server as well as the average transaction time. Results of these tests are listed in Table 7. The Dell PowerEdge 2850 with two 3.4 GHz processors was 50% faster than the Sun Fire V440 with four 1.28 GHz processors running Sybase ASE. 1 System Sun Fire V440 4x1.28 GHz/1 MB L2 Cache Dell PowerEdge x 3.4 GHz/1 MB L3 Cache Table 7: Results Simultaneous Database Connections Orders Per Minute (larger is better) Average Transaction Time (s) CPU Utilization % Dell PE2850 Performance Advantage Over Sun Fire V440 Total Hardware + Software Price 24 14, $167, , x $62,060 June 2005 Page 17 Dell Enterprise Product Group

18 Section 7 Benefits of Replication Technology for Migrations Replication Server provides a safe method for upgrading existing systems or migrating to new platforms. Replicating data changes allows customers to migrate existing database data without interrupting critical business applications. While the preparation work is being completed on the new database, changes to the old database are: captured, stored, and forwarded when the database is ready. The applications can then be switched to the new platform at an off-peak time, with very little downtime. Replication Server can provide: Reduced overall downtime for migration - Using Replication Server during the migration can reduce the overall downtime for the critical business applications to minutes instead of the hours normally taken to migrate data using traditional migration methods. Failback scenario Customers have the ability with Replication Server to fail back to the old platform without the loss of data or requiring transaction replay. This can be a critical component in risk aversion during a migration. Disaster Recovery System The system utilized can easily be modified to provide for a warm standby disaster recovery system. In the event of a primary system failure, users can be switched over to a DR site in a matter of seconds. Support for heterogeneous platforms Replication Server can replicate data bi-directionally with a number of RDBMS platforms (MSSQL, Oracle, Sybase, IBM DB2, others). June 2005 Page 18 Dell Enterprise Product Group

19 Section 8 Conclusions Sybase ASE and Sybase Replication Server are enterprise class software products that are very effective in supporting a UNIX platform migration to Linux on the Dell PE2850. With this combination the following als were achieved: Minimized the unavailability of end user access to only 40 minutes for the entire migration of a 100 GB online transaction processing database. Kept the new target ASE database running on the Dell Linux PE2850 completely in sync with the original system. This allowed the complete testing of the new system prior to the conversion date, helping to ensure programs and processes could be completely checked out prior to final switchover. Provided a complete fall back / disaster recovery environment so that in the event of an issue, users could be switched back to the original system in a matter of seconds without any data loss. Provided a 50% gain in transaction processing rates over the original system, the Sun Fire V440, with no additional CPU utilization. Sybase ASE and Sybase Replication Server are very mature, stable products that can provide a significant advantage to the continual accessibility of your businesses data during a migration to a high performance platform, the Dell Linux PE2850. THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND. 1 The Sun Fire V440 was tested using the fastest processor speed offered by Sun at the time of testing: 1.28 GHz. After the testing was done for this paper, but before the paper was completed, Sun introduced a faster CPU, at GHz. The list price of the Sun Fire V440 with GHz CPUs was $31, as of June 9, The PowerEdge 2850 offered 5 processor speeds, with the fastest being 3.6 GHz and the slowest, 2.8 GHz, and was tested with two 3.4GHz processors. Dell expects server testing performance to vary with processor speed. June 2005 Page 19 Dell Enterprise Product Group

20 2 This term does not connote an actual operating speed of 1 Gb/sec. For high speed transmission, connection to a Gigabit Ethernet server and network infrastructure is required. 3 Service may be provided by third-party. Technician will be dispatched if necessary following phone-based troubleshooting. Subject to parts availability, geographical restrictions and terms of service contract. Service timing dependent upon time of day call placed to Dell. U.S. only. Dell and PowerEdge are trademarks of Dell Inc. Sybase, Adaptive Server Enterprise and Replication Server are registered trademarks of Sybase, Inc. EMC, Navisphere and PowerPath are registered trademarks and Access Logix is a trademark of EMC Corp. Intel and Xeon are registered trademark of Intel Corp. Red Hat is a registered trademark of Red Hat Inc. Linux is a registered trademark of Linus Torvalds. Microsoft and Windows are registered trademarks of Microsoft Corporation. Sun and Solaris are registered trademarks of Sun Microsystems, Inc. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell disclaims proprietary interest in the marks and names of others. Copyright 2005 Dell Inc. All rights reserved. Reproduction in any manner whatsoever without the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell. Information in this document is subject to change without notice. June 2005 Page 20 Dell Enterprise Product Group

21 Appendix A. --Disk Init disk_init.sql USE MASTER sp_configure "number of devices",20 --Initialize five 32 GB Raw data devices + two 20 GB Log devices + temp device IF EXISTS (SELECT * FROM sysdevices WHERE name="ds2datadev1") execute sp_dropdevice DS2DataDev1 IF EXISTS (SELECT * FROM sysdevices WHERE name="ds2datadev2") execute sp_dropdevice DS2DataDev2 IF EXISTS (SELECT * FROM sysdevices WHERE name="ds2datadev3") execute sp_dropdevice DS2DataDev3 IF EXISTS (SELECT * FROM sysdevices WHERE name="ds2datadev4") execute sp_dropdevice DS2DataDev4 IF EXISTS (SELECT * FROM sysdevices WHERE name="ds2datadev5") execute sp_dropdevice DS2DataDev5 IF EXISTS (SELECT * FROM sysdevices WHERE name="tempdbdev") execute sp_dropdevice tempdbdev IF EXISTS (SELECT * FROM sysdevices WHERE name="ds2logdev1") execute sp_dropdevice DS2LogDev1 IF EXISTS (SELECT * FROM sysdevices WHERE name="ds2logdev2") execute sp_dropdevice DS2LogDev2 disk init name = "DS2DataDev1", physname = "/dev/raw/datadev1", vdevno = 3, size = "32G" disk init name = "DS2DataDev2", physname = "/dev/raw/datadev2", vdevno = 4, size = "32G" disk init name = "DS2DataDev3", physname = "/dev/raw/datadev3", vdevno = 5, size = "32G" disk init name = "DS2DataDev4", physname = "/dev/raw/datadev4", vdevno = 6, size = "32G" disk init name = "DS2DataDev5", physname = "/dev/raw/datadev5", vdevno = 7, size = "32G" disk init name = "tempdbdev", June 2005 Page 21 Dell Enterprise Product Group

22 physname = "/dev/raw/datadev6", vdevno = 10, size = "5G" disk init name = "DS2LogDev1", physname = "/dev/raw/logdev1", vdevno = 8, size = "19G" disk init name = "DS2LogDev2", physname = "/dev/raw/logdev2", vdevno = 9, size = "19G" create_tables.sql use DS2 June 2005 Page 22 Dell Enterprise Product Group

23 Appendix B. -- Database create_db.sql IF EXISTS (SELECT * FROM sysdatabases WHERE name='ds2') DROP DATABASE DS2 CREATE DATABASE DS2 ON DS2DataDev1="32G", DS2DataDev2="32G", DS2DataDev3="32G", DS2DataDev4="32G", DS2DataDev5="32G" LOG ON DS2LogDev1="19G", DS2LogDev2="19G" June 2005 Page 23 Dell Enterprise Product Group

24 Appendix C. -- Create Tables create_tables.sql CREATE TABLE CUSTOMERS ( CUSTOMERID NUMERIC IDENTITY NOT NULL, FIRSTNAME VARCHAR(50) NOT NULL, LASTNAME VARCHAR(50) NOT NULL, ADDRESS1 VARCHAR(50) NOT NULL, ADDRESS2 VARCHAR(50), CITY VARCHAR(50) NOT NULL, STATE VARCHAR(50), ZIP INT, COUNTRY VARCHAR(50) NOT NULL, REGION TINYINT NOT NULL, VARCHAR(50), PHONE VARCHAR(50), CREDITCARDTYPE INT NOT NULL, CREDITCARD VARCHAR(50) NOT NULL, CREDITCARDEXPIRATION VARCHAR(50) NOT NULL, USERNAME VARCHAR(50) NOT NULL, PASSWORD VARCHAR(50) NOT NULL, AGE TINYINT, INCOME INT, GENDER VARCHAR(1), PROD_ID_IDX INT NOT NULL, PROD_ID1 INT NOT NULL, PROD_ID2 INT NOT NULL, PROD_ID3 INT NOT NULL, PROD_ID4 INT NOT NULL, PROD_ID5 INT NOT NULL, PROD_ID6 INT NOT NULL, PROD_ID7 INT NOT NULL, PROD_ID8 INT NOT NULL, PROD_ID9 INT NOT NULL, PROD_ID10 INT NOT NULL ) CREATE TABLE ORDERS ( ORDERID NUMERIC IDENTITY NOT NULL, ORDERDATE DATETIME NOT NULL, CUSTOMERID NUMERIC, NETAMOUNT MONEY NOT NULL, TAX MONEY NOT NULL, TOTALAMOUNT MONEY NOT NULL ) lock datarows CREATE TABLE ORDERLINES ( ORDERLINEID SMALLINT NOT NULL, ORDERID NUMERIC NOT NULL, PROD_ID NUMERIC NOT NULL, QUANTITY SMALLINT NOT NULL, ORDERDATE DATETIME NOT NULL ) lock datarows CREATE TABLE PRODUCTS ( PROD_ID NUMERIC IDENTITY NOT NULL, CATERY NUMERIC NOT NULL, TITLE VARCHAR(50) NOT NULL, June 2005 Page 24 Dell Enterprise Product Group

25 ACTOR VARCHAR(50) NOT NULL, PRICE MONEY NOT NULL, QUAN_IN_STOCK INT NOT NULL, SPECIAL TINYINT, COMMON_PROD_ID1 INT NOT NULL, COMMON_RATING1 INT NOT NULL, COMMON_PROD_ID2 INT NOT NULL, COMMON_RATING2 INT NOT NULL, COMMON_PROD_ID3 INT NOT NULL, COMMON_RATING3 INT NOT NULL, SALES INT NOT NULL ) CREATE TABLE CATERIES ( CATERY NUMERIC IDENTITY NOT NULL, CATERYNAME VARCHAR(50) NOT NULL ) SET IDENTITY_INSERT CATERIES ON INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (1,'Action') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (2,'Animation') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (3,'Children') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (4,'Classics') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (5,'Comedy') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (6,'Documentary') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (7,'Drama') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (8,'Family') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (9,'Foreign') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (10,'Games') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (11,'Horror') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (12,'Music') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (13,'New') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (14,'Sci-Fi') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (15,'Sports') INSERT INTO CATERIES (CATERY, CATERYNAME) VALUES (16,'Travel') June 2005 Page 25 Dell Enterprise Product Group

26 Appendix D. create_ind.sql -- create_ind.sql USE DS2 ALTER TABLE CUSTOMERS ADD CONSTRAINT PK_CUSTOMERS PRIMARY KEY CLUSTERED (CUSTOMERID) CREATE UNIQUE INDEX IX_CUST_USERNAME ON CUSTOMERS (USERNAME) ALTER TABLE ORDERS ADD CONSTRAINT PK_ORDERS PRIMARY KEY CLUSTERED (ORDERID) ALTER TABLE ORDERLINES ADD CONSTRAINT PK_ORDERLINES PRIMARY KEY CLUSTERED (ORDERID, ORDERLINEID) ALTER TABLE CATERIES ADD CONSTRAINT PK_CATERIES PRIMARY KEY CLUSTERED (CATERY) ALTER TABLE PRODUCTS ADD CONSTRAINT PK_PRODUCTS PRIMARY KEY CLUSTERED (PROD_ID) CREATE INDEX IX_PROD_ACTOR ON PRODUCTS (ACTOR) CREATE INDEX IX_PROD_CATERY ON PRODUCTS (CATERY) CREATE INDEX IX_PROD_TITLE ON PRODUCTS (TITLE) CREATE INDEX IX_PROD_SPECIAL ON PRODUCTS (SPECIAL) ALTER TABLE ORDERS ADD CONSTRAINT FK_CUSTOMERID FOREIGN KEY (CUSTOMERID) REFERENCES CUSTOMERS (CUSTOMERID) ALTER TABLE ORDERLINES ADD CONSTRAINT FK_ORDERID FOREIGN KEY (ORDERID) REFERENCES ORDERS (ORDERID) June 2005 Page 26 Dell Enterprise Product Group