Acceleration of UNIX Database Migration to Dell Servers ... · June 2005 Acceleration of UNIX...

June 2005

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 Page 2 Dell Enterprise Product Group

Contents Executive Summary.................................................................................................................... 4

Introduction................................................................................................................................. 5

Migrating Sybase Databases.............................................................................................. 5

The Systems................................................................................................................................. 7

Sybase ........................................................................................................................................... 9

The Application ........................................................................................................................ 13

The Database Schema ....................................................................................................... 13

The Stored Procedures ...................................................................................................... 14

The Online Transaction Processing Driver Application............................................ 14

Results ........................................................................................................................................ 15

Data Migration ................................................................................................................... 15

Replication .......................................................................................................................... 16

Performance ........................................................................................................................ 17

Benefits of Replication Technology for Migrations .......................................................... 18

Conclusions ............................................................................................................................... 19

Appendix A. disk_init.sql .................................................................................................. 21

Appendix B. create_db.sql................................................................................................. 23

Appendix C. create_tables.sql ........................................................................................... 24

Appendix D. create_ind.sql................................................................................................ 26


Tables

Table 1: Comparison of Sun Fire V440 vs the Dell PowerEdge 2850.................................................... 7 Table 2: Dell/EMC Storage ......................................................................................................................... 8 Table 3: Database Configuration Parameters .......................................................................................... 9 Table 4: DVD Store Database Schema..................................................................................................... 13 Table 5: Migration Timings ...................................................................................................................... 16 Table 6: Replication Synchronization Timings ...................................................................................... 17 Table 7: Results .......................................................................................................................................... 17

Figures

Figure 1 - Cross Platform Dump and Load Configuration.................................................................. 10 Figure 2 - Initial Replication Server Architecture.................................................................................. 11 Figure 3 - Replication Server Architecture after migration (Failback enabled) ................................ 12


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 12.5.3, 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 12.5.3 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 2850. See Section 6 for discussion of this performance comparison.


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, government, 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) 12.5.3, 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 12.5.3 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 12.5.3 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 12.5.2 database running on a Sun Fire V440 into an ASE 12.5.3 database on a Dell PowerEdge 2850.

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


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.


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.

Sun Fire V440 Dell PowerEdge 2850 Operating System

Solaris 9 12/03 RedHat Enterprise Linux 3

CPU 4x 1.28 GHz UltraSPARC IIIi w/ 1MB L2 cache

2x 3.4 GHz/1 MB L2 Cache Xeon

Memory 8 GB 8 GB

Internal Disks 4x 73 GB 10K RPM Ultra320 SCSI

2x 73 GB 10K RPM Ultra320 SCSI

NICs 2x 10/100/10002 Mb/s (Internal)

2x 10/100/10002 Mb/s (Internal)

Disk Controller On-board SCSI PERC 4ei Fiber Channel HBA

2x QLA 2340 2x QLA 2340

Remote Management

Serial Management Card

Dell Remote Access Card, Version IV, without Modem

Service 3-Year Gold Support w/ 7x24 Onsite

3-Year Gold Support w/ 7x24 Onsite3

Hardware Price (without HBAs)

$27,339 $12,070

Price of Database Licenses ($34,995/CPU for Sun Solaris and $24,995/CPU for Linux)

$139,980 $49,990

Total Price $167,319 $62,060 Source http://www.sun.com

11/29/041 http://www.dell.com 6/9/05

Table 1: Comparison of Sun Fire V440 vs the Dell PowerEdge 2850


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 2899100000 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=2899100000 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 http://www.emc.com/interoperability/index.jsp), 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 1 Dell/EMC CX700

Disk Enclosures 3 Dell/EMC DAE2

Disks 40 x 73 GB/ 10K RPM

LUNs 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

Software Navisphere® Manager

Access Logix™

PowerPath

Table 2: Dell/EMC Storage


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 2094000

Named Cache: Log Cache 300M 300M

2.2GB 1.7GB

300M 300M

Named Cache: Default Data Cache

16K Buffer Pool

Local Cache Partition Num 4 2

200M 200M Named Cache: Product Cache

Local Cache Partition Num 4 2

Procedure Cache Size 32768 32768

Max Network Packet Size 8192

Max Memory 2048000 2048000

Additional Network Memory 131072

Number of Engines (Max/Start/Run) 4 / 2 / 3 2 / 2 / 2

Number of Sort Buffers 2048 2048

Disk I/O Structures 65536 65536

Max Async I/Os per Engine 65536 65536

Max Async I/Os per Server 65536 65536

Heap Memory per User 8192 8192

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:


• 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 12.5.3 was used on the Linux platform to allow us to migrate the database (see figure 1).

Source DB Target DB

Sybase ASE 11.9.2 - 12.5.3

Cross Platform Dump and Load (XPDL)

Unix Configuration

SAN

Sun Fire V440Solaris 9

Sybase ASE 12.5.3

Linux Configuration

SAN

Dell PowerEdge 2850RedHat Enterprise

Linux 3.0

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


• 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.

Dell PowerEdge 2850RedHat Linux 3.0

Source DB Target DB

Sybase ASE 12.5.2

Sybase Replication Server 12.6

Unix Configuration

SAN

Sun V440Solaris 9

Sybase ASE 12.5.3

Linux Configuration

Replication Storage

SAN

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


is a capability of the Warm Standby feature of ASE that allows the switch of the active database.

Source DB Target DB

Sybase ASE 12.5.2

Sybase Replication Server 12.6

Unix Configuration

SAN

Sun V440Solaris 9

Sybase ASE 12.5.3

Dell PowerEdge 2850RedHat Linux 3.0

Linux Configuration

Replication Storage

SAN

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.


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 category, 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 CUSTOMERID, FIRSTNAME, LASTNAME, ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY, REGION, EMAIL, PHONE, CREDITCARD, CREDITCARDEXPIRATION, USERNAME, PASSWORD, AGE, INCOME, GENDER, PROD_ID_IDX, PROD_ID1, PROD_ID2 … PROD_ID10

200 million

Orders ORDERID, ORDERDATE, CUSTOMERID, NETAMOUNT, TAX, TOTALAMOUNT

120 million

Orderlines ORDERLINEID, ORDERID, PROD_ID, QUANTITY, ORDERDATE 600 million

Products PROD_ID, CATEGORY, TITLE, ACTOR, PRICE, QUAN_IN_STOCK, SPECIAL, COMMON_PROD_ID1, COMMON_RATING1, COMMON_PROD_ID2, COMMON_RATING2, COMMON_PROD_ID3, COMMON_RATING3, SALES

1 million

Reorder PROD_ID, DATE_LOW, QUAN_LOW, DATE_REORDERED, QUAN_REORDERED, DATE_EXPECTED

Variable

Categories CATEGORY, CATEGORYNAME 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 Categories table listed the 16 DVD categories. The scripts used to create the database are shown in Appendix A through Appendix D.


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 category, actor or title. Browse_by_category, 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 going 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.


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.


Conversion step Timing Notes

Database Backup 40 Min This was the only time that the system was unavailable to end-users

Database load 32 Min

Data Endian Conversion 2 hr 28 min

Index Re-create 11 hr 5 min This will vary based upon the number of indexes involved

End-User Switch 1 Min

Table 5: Migration Timings

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


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 Time

Replication Queue Build-up

4924 transactions per minute

1 hr

Replication Queue catch-up

Initial 1st hour’s queued transactions

21 min

2nd hour’s transactions caught up to ‘near real-time’ replication

10 min

Table 6: Replication Synchronization Timings

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 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

Sun Fire V440 4x1.28 GHz/1 MB L2 Cache

24 14,070 0.1 76 - $167,319

Dell PowerEdge 2850 2x 3.4 GHz/1 MB L3 Cache

48 21,041 0.14 76 1.50x $62,060

Table 7: Results


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).


Section 8 Conclusions

Sybase ASE 12.5.3 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 goals 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 12.5.3 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 1.593 GHz. The list price of the Sun Fire V440 with 4 1.593 GHz CPUs was $31,339.00 as of June 9, 2005. 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.


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.


Appendix A. disk_init.sql --Disk Init USE MASTER go sp_configure "number of devices",20 go --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 go IF EXISTS (SELECT * FROM sysdevices WHERE name="DS2DataDev2") execute sp_dropdevice DS2DataDev2 go IF EXISTS (SELECT * FROM sysdevices WHERE name="DS2DataDev3") execute sp_dropdevice DS2DataDev3 go IF EXISTS (SELECT * FROM sysdevices WHERE name="DS2DataDev4") execute sp_dropdevice DS2DataDev4 go IF EXISTS (SELECT * FROM sysdevices WHERE name="DS2DataDev5") execute sp_dropdevice DS2DataDev5 go IF EXISTS (SELECT * FROM sysdevices WHERE name="tempdbdev") execute sp_dropdevice tempdbdev go IF EXISTS (SELECT * FROM sysdevices WHERE name="DS2LogDev1") execute sp_dropdevice DS2LogDev1 go IF EXISTS (SELECT * FROM sysdevices WHERE name="DS2LogDev2") execute sp_dropdevice DS2LogDev2 go disk init name = "DS2DataDev1", physname = "/dev/raw/datadev1", vdevno = 3, size = "32G" go disk init name = "DS2DataDev2", physname = "/dev/raw/datadev2", vdevno = 4, size = "32G" go disk init name = "DS2DataDev3", physname = "/dev/raw/datadev3", vdevno = 5, size = "32G" go disk init name = "DS2DataDev4", physname = "/dev/raw/datadev4", vdevno = 6, size = "32G" go disk init name = "DS2DataDev5", physname = "/dev/raw/datadev5", vdevno = 7, size = "32G" go disk init name = "tempdbdev",


physname = "/dev/raw/datadev6", vdevno = 10, size = "5G" go disk init name = "DS2LogDev1", physname = "/dev/raw/logdev1", vdevno = 8, size = "19G" go disk init name = "DS2LogDev2", physname = "/dev/raw/logdev2", vdevno = 9, size = "19G" go create_tables.sql use DS2 go


Appendix B. create_db.sql -- Database IF EXISTS (SELECT * FROM sysdatabases WHERE name='DS2') DROP DATABASE DS2 go CREATE DATABASE DS2 ON DS2DataDev1="32G", DS2DataDev2="32G", DS2DataDev3="32G", DS2DataDev4="32G", DS2DataDev5="32G" LOG ON DS2LogDev1="19G", DS2LogDev2="19G" go


Appendix C. create_tables.sql -- Create Tables 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, EMAIL 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 ) go 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 go 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 go CREATE TABLE PRODUCTS ( PROD_ID NUMERIC IDENTITY NOT NULL, CATEGORY NUMERIC NOT NULL, TITLE VARCHAR(50) NOT NULL,


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 ) go CREATE TABLE CATEGORIES ( CATEGORY NUMERIC IDENTITY NOT NULL, CATEGORYNAME VARCHAR(50) NOT NULL ) go SET IDENTITY_INSERT CATEGORIES ON INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (1,'Action') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (2,'Animation') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (3,'Children') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (4,'Classics') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (5,'Comedy') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (6,'Documentary') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (7,'Drama') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (8,'Family') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (9,'Foreign') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (10,'Games') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (11,'Horror') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (12,'Music') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (13,'New') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (14,'Sci-Fi') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (15,'Sports') INSERT INTO CATEGORIES (CATEGORY, CATEGORYNAME) VALUES (16,'Travel') GO


Appendix D. create_ind.sql -- create_ind.sql USE DS2 GO ALTER TABLE CUSTOMERS ADD CONSTRAINT PK_CUSTOMERS PRIMARY KEY CLUSTERED (CUSTOMERID) GO CREATE UNIQUE INDEX IX_CUST_USERNAME ON CUSTOMERS (USERNAME) GO ALTER TABLE ORDERS ADD CONSTRAINT PK_ORDERS PRIMARY KEY CLUSTERED (ORDERID) GO ALTER TABLE ORDERLINES ADD CONSTRAINT PK_ORDERLINES PRIMARY KEY CLUSTERED (ORDERID, ORDERLINEID) GO ALTER TABLE CATEGORIES ADD CONSTRAINT PK_CATEGORIES PRIMARY KEY CLUSTERED (CATEGORY) GO ALTER TABLE PRODUCTS ADD CONSTRAINT PK_PRODUCTS PRIMARY KEY CLUSTERED (PROD_ID) GO CREATE INDEX IX_PROD_ACTOR ON PRODUCTS (ACTOR) GO CREATE INDEX IX_PROD_CATEGORY ON PRODUCTS (CATEGORY) GO CREATE INDEX IX_PROD_TITLE ON PRODUCTS (TITLE) GO CREATE INDEX IX_PROD_SPECIAL ON PRODUCTS (SPECIAL) GO ALTER TABLE ORDERS ADD CONSTRAINT FK_CUSTOMERID FOREIGN KEY (CUSTOMERID) REFERENCES CUSTOMERS (CUSTOMERID) GO ALTER TABLE ORDERLINES ADD CONSTRAINT FK_ORDERID FOREIGN KEY (ORDERID) REFERENCES ORDERS (ORDERID) GO

Date post:	21-Apr-2018
Category:	Documents
Upload:	ledat
View:	224 times
Download:	1 times

Acceleration of UNIX Database Migration to Dell Servers ... · June 2005 Acceleration of UNIX...

Documents