Configuring the Oracle Database with VERITAS Software and EMC Storage for Optimal Scalability, Mangeability, and Performance

Transcription

1 Configring the Oracle Database with VERITAS Software and EMC Storage for Optimal Scalability, Mangeability, and Performance Table of Contents I. Introdction II. Storage Topics III. Configring Oracle Database with Storage Sbsystem Traditional Approach New Approach IV. Test Configrations and Analysis V. Conclsion VI. Appendix Test Configration Details EMC Disk Configrations Step-by-Step Setp EMC Symmetrix VERITAS Database Edition for Oracle 1

2 I. Introdction I. Introdction In today s increasingly data intensive, web and e-commerce enabled world, data storage reqirements and management of that storage are becoming increasingly important. Databases contine to grow at an incredible rate as bsinesses store every detail of their cstomers as they navigate their web sites. Downtime for any reason is nacceptable and mst be avoided at all cost as sers are only a cople of mose clicks away from the competition. Management of sch a dynamic environment is difficlt for all database and system administrators. The ever important priorities of mission critical systems, sch as availability, reliability, scalability, and performance, are magnified in today s e-bsiness world. Today, cstomers are looking for optimal scalability, manageability, and performance. They are looking for the flexibility to grow their bsiness and adapt to changes from the otside world, and from within. They want to maintain a competitive advantage by deploying resorces that will give them an edge over the competition, and ths seeking ways to simplify management of their crrent infrastrctre. And, they are trying to attain the highest level of performance available from the investments they have made in software, hardware, and personnel. As anyone experienced in this area will attest, performance tning is a trade-off, often pitting one goal against another. Common qestions are: How do I maximize performance while at the same time minimize management overhead? How do I maximize flexibility and minimize cost? How do I maximize throghpt and minimize Online Transaction Processing (OLTP) response time? The goal of this white paper is to provide a list of recommendations that will allow cstomers to optimize overall scalability, manageability, and performance. Oracle, EMC, and VERITAS nderstand what cstomers are asking for as well as the challenges faced in trying to meet their objectives. Moreover, the recommendations provided mst be able to handle today s ever-changing compting environment. Availability is also a cstomer priority. This paper incldes basic techniqes, bt does not go into detail abot high availability soltions, as this is a topic of other joint technical white papers. There are many options for configring a storage sbsystem for a database workload. However, it is not obvios when to se each featre and option. In this paper, we first describe the traditional approach of configring a storage sbsystem for a database workload based on the application type, data file I/O characteristics, and availability reqirements. We then describe a new approach to configring a storage sbsystem for a database workload that is simple, easy to manage, and achieves excellent performance. The idea is to Stripe And Mirror Everything (SAME), or to place Oracle files on striped and mirrored drives. In or testing, we sed EMC hardware mirroring (RAID 1) for data protection and VERITAS software striping (RAID 0) for increased performance. Or test reslts show that the SAME method is sccessfl and shold be considered in most sitations. We recommend the following: Implement hardware mirroring and software striping for availability and performance reasons. Use the SAME method with Oracle. Minimize disk contention by evenly distribting IO across the Symmetrix. Set I/O block size to 1MB. In or test, this demonstrated optimal performance. Set VERITAS stripe depth to 1MB. In or test, this demonstrated optimal performance. Use VERITAS Qick I/O. 2 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

3 I. Introdction There are sitations where manageability considerations may make the implementation of SAME difficlt; however, this approach can be sed in most cases and works well. Or tests were condcted on a single Oracle Database approximately 50GB in size, striped across 16 to 32 devices. Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 3

4 II. Storage Topics II. Storage Topics Mirroring (RAID 1) vs. RAID 5 We recommend RAID 1, or mirroring, over RAID 5 for performance reasons. Mirroring is the simplest way to achieve data redndancy. For each data drive, there is a second drive that contains exactly the same data. Data is written to both drives. Ths, if one drive fails, the other drive can provide an exact copy of the lost data immediately. RAID 5 protects data throgh se of parity information. With RAID 5, both data and parity information are striped across all the drives in the RAID grop. If a drive fails, original data can be reconstrcted from srviving drives sing parity information. EMC reqires that all data on a Symmetrix storage sbsystem be protected either throgh hardware mirroring or RAID S (EMC RAID 5). Mirroring reqires twice the sable storage capacity for protection bt offers better performance than a RAID 5 soltion, which typically reqires only 10-25% additional storage capacity for protection bt may case some performance degradation. This is especially tre in a write intensive environment. RAID 5 can be a viable soltion where storage cost may be more important than performance. Another advantage of mirroring over RAID 5 is that mirror splits can be sed to make very fast copies or backps of files. Striping (RAID 0) We recommend RAID 0+1, or mirroring with striping, for availability and performance reasons. Striping (RAID 0) balances the I/O workload across all the disk drives in the stripe set, ths redcing potential hot spots and enhancing performance by spreading data across mltiple drives so I/Os can be done in parallel. The amont of information written to each disk before moving to the next is known as the stripe depth. The grop of physical drives being striped across is known as the stripe set or striped volme set. The nmber of logical devices inclded in the stripe set is known as the stripe width. In the following figre, we have a stripe set of for physical disks and stripe width of for logical devices. The nmber of the logical devices does not have to be the same as the nmber of physical disks. Stripe Set Stripe Depth D isk 1 D isk 2 D isk 3 D isk 4 Figre 1: Striping Storage Sbsystem Cache Use of non-volatile cache in a storage sbsystem can also improve performance. When a write reqest is pt into a non-volatile cache dring a write operation, the write is instantly confirmed, thereby enabling faster write performance. In a read operation, a storage system 4 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

5 II. Storage Topics may read ahead or pre-fetch additional data into the non-volatile cache. If the read can be satisfied in the cache (cache hit), or the pre-fetch logic has anticipated the sbseqent reads, the operation will complete in a fraction of the elapsed time of an actal disk read. EMC Symmetrix spports p to 32GB of non-volatile cache. Both random and seqential writes can benefit from cache; however, seqential reads benefit more from cache than random reads. For example, EMC Symmetrix can se cache for seqential read ahead on a per device (hyper-volme) basis. In workloads that are trly random read, the Symmetrix cache hit ratio will be less efficient. Possible Bottlenecks In configring a high performance Oracle database storage soltion, there are additional areas where bottlenecks may occr: System - Does the system have enogh CPU or memory resorces? Operating System - What are the OS limitations (for example, Windows NT has only 256 I/O qee depth)? File System - How does it compare to raw partition performance? I/O Channel - Are there enogh I/O controllers? Disk - Are the disks and their interfaces fast enogh? Other Applications - What other applications are rnning on the system? Any of these areas, in addition to how Oracle files are laid ot or which striping method is sed, may impact performance significantly. Therefore, it is important to locate the bottlenecks. In or testing, we tried to minimize these bottlenecks so we cold determine the best storage configration withot regard to these complicating factors. Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 5

6 III. Configring Oracle Database with Storage Sbsystem III. Configring Oracle Database with Storage Sbsystem In this paper, we examine two methods of configring an Oracle database with the storage sbsystem. We then compare the test reslts and discss their implications. The first configration method is the traditional approach of laying ot Oracle files based on the application type, data file I/O characteristics, and availability reqirements. The second configration method is the new Stripe And Mirror Everything (SAME) approach, or striping and mirroring all Oracle files on all available disk drives. Traditional Approach The traditional method of configring the Oracle database and storage offers maximm configration flexibility and performance tning, bt reqires in-depth nderstanding of the I/O characteristics of Oracle files and applications as well as ftre growth reqirements. We briefly discss this method sing simple categorization of application by either (Online Transaction Processing (OLTP) or Decision Spport Systems (DSS). I/O Profile of Oracle Files Varios I/O operations that Oracle performs and their characteristics can be easily described by considering the logical groping of data files called tablespace. System tablespace - System tablespace contains all of the system-related tables. Most of these tables are created dring database creation. This tablespace enconters mostly random block reads with minimal writes. Redo Logs - Oracle recommends 4, 8, or 16 mtliplexed online redo log files. Online redo logs are written seqentially for every change made to an Oracle block. Online logs are written by the LGWR process. The size of the write operation varies with the transaction throghpt. Online redo logs are read seqentially dring recovery. The online redo log file is also read seqentially by the archiver process after it is completely filled. Archive Logs - The archiver copies the online redo log files into archive files after the online redo log file is filled. Archive files are created dynamically, so they cannot be placed on raw devices. The archiver reads the online redo log file synchronosly and writes the archive redo log file asynchronosly. These archive log files are read seqentially dring backps and media recovery. Rollback segments - Rollback (ndo) segments are sed for read consistency, database recovery, and to rollback ncommitted transactions. Normally, 10 to 30 extents (ser-specified) are allocated for each rollback segment when they are created. Every transaction seqentially writes to only one extent at any given time. Extents are allocated dynamically and are resed in a circlar fashion. If a rollback segment fits in the cache and is sfficiently hot, then it will only be written to disk dring a checkpoint. If an incremental checkpoint is sed, ndo blocks are continosly written to disk. Temporary tablespace - Temporary tablespace is sed mostly for on-disk sort operations. Using direct I/O, reads and writes on this tablespace are mostly seqential. Control files - Control files are relatively small files that are mostly read dring instance startp. Writes to control files happen dring log switch and checkpoints, and when any strctral change is made to the database. User tables and indexes - It is difficlt to characterize the I/O pattern of the ser tables and indexes. In general, OLTP qeries perform one or more reads on the index block followed by a read on a table block. However, things get complex when the application natre changes. What is good for normal operation may not be optimal for maintenance operations. For example, dring data load, index create, on-disk sort, create table as select, index merge, read/write of LOBS, index range scan, index fast fll scan, parallel operations, and backp and recovery operations. 6 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

7 III. Configring Oracle Database with Storage Sbsystem I/O Profile of Applications Applications have their own I/O characteristics. Depending on the type of application, there are a nmber of storage and Oracle parameters that can be tned to optimize overall performance. For example, in a prely OLTP system where large nmbers of sers make small (single block) I/O reqests, database administrators (DBAs) tend to configre stripe depth of a volme to be a mltiple of the Oracle database block size (db_block_size). This configration increases the probability that an I/O reqest for a data block will be serviced by only one drive, and can probably handle a large nmber of concrrent sers withot developing potential disk contention. Whereas in a prely DSS system, few processes make large I/O reqests. It is often efficient to make the stripe depth small, so that many disks in the array will work to retrn the data faster. Note that when sing parallel qery, the reslts are less predictable de to the large degree of parallelism. It is important to remember that even OLTP systems, which typically perform small random reads and writes, often perform a significant amont of seqential I/O dring backp and restore operations, index bilds, data loads, or batch jobs. Cstomizing the stripe depth for prely small random reads can reslt in significant delays when performing maintenance operations that perform seqential I/O. Even thogh the traditional method is complex, it is possible for an expert to configre a storage sbsystem, after continos monitoring and going throgh many iterations, to get the best possible performance. The traditional method may also work well in certain specialized sitations sch as a database environment with highly parallel, large seqential I/O operations. This approach prodces a very cstomized Oracle and storage sbsystem setp since each configration is a fnction of a specific application and its environment. If the application or environment change, major reconfigration and re-tning may be necessary to maintain overall performance. In or traditional approach testing, we separated online redo logs from the rest of the data files (tablespace). We also did some testing as part of or traditional configration by separating redo logs, tables, and indexes from system, temporary, and rollback segment tablespaces. We limited or test reslt analysis only to the redo log separation from the rest of the data files. New Approach The SAME method offers simplicity, manageability, performance, and availability. This approach is possible becase of a combination of technical advances that have occrred over the last few years. These advancements inclde: Parallel database exection. This allows scans of large amonts of data to be parallelized across many disks and many I/O reqests so that a single disk or process does not become a bottleneck. Efficient and scalable striping of files sing the VERITAS Volme Manager (VxVM). This allows files to be striped over many disks withot hrting I/O performance and with minimal overhead on the host. Efficient file system I/Os sing VERITAS Qick I/O. This eliminates the need for sing raw devices for performance prposes in a single instance database. Dynamic re-striping of data. This allows disks to be added and sbtracted from a striped volme withot having to rebild the volmes from scratch and while keeping the system available. (We tested the fnctionality of this featre; however, we did not test the performance.) Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 7

8 III. Configring Oracle Database with Storage Sbsystem Large cache on EMC Symmetrix. A large non-volatile cache redces the overhead of doing large writes and allows write I/Os to be schedled in an efficient manner. They also can entirely eliminate disk writes for freqently written database blocks that might otherwise become a hot spot (for example, if actal disk writes are deferred). The large caches also increase the availability of databases by speeding p recovery operations. Highly reliable mirrored disks with online disk replacement. This allows striping to be sed across many disks withot the fear that a disk failre will case data loss, significant downtime, or a complete database restore. Dynamic load balancing and path failover. Host-based prodcts like EMC PowerPath or VERITAS DMP (Dynamic Mltipathing) provide added flexibility, remove potential I/O channel bottlenecks, and enhance database availability. Advanced featres like Symmetrix Dynamic Mirror Service Policy. This allows seqential read operations to be accessed from the M2 or mirror as well as the M1 or standard volme. The advent of these technical advances has eliminated many of the trade-offs that previosly had to be made when configring a storage sbsystem. We can now implement a simple configration that is both efficient and easy to manage: Stripe And Mirror Everything (SAME). By mirroring all the disks, the failre of any single disk can be tolerated. By striping all the data, hot disks are avoided and disk throghpt is maximized to all tables. The greatest benefit of SAME is that it is application independent. It will work for any application and will even work in mixed environments. To configre the storage sbsystem, one only needs to know the amont of disk storage reqired and the maximm aggregate I/O bandwidth reqired by the application. Detailed knowledge of the I/O characteristics of the varios transaction types and tables is not reqired. SAME does not reqire constant adjstment as the application and workload evolve. It works well for both random and seqential access patterns. Ths OLTP, batch, data loads, import/export, backp, recovery, and reporting will all perform well. SAME is designed to take maximm advantage of the aggregate I/O bandwidth of the storage devices. Maximizing I/O bandwidth is becoming increasingly important since disk capacity is increasing at a mch higher rate than disk throghpt. Also, a parallel operation exected against any table can take advantage of all the I/O bandwidth capacity of the storage sbsystem. This allows for fast reporting, loading, reorganization, and indexing operations on any table. 8 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

9 IV. Test Configrations and Analysis IV. Test Configrations and Analysis The goal of this paper is to provide general gidelines on how to easily configre storage with an Oracle database withot sacrificing availability and performance, sing VERITAS software and EMC Symmetrix. We also want to validate or new Stripe and Mirror Everything (SAME) method with test reslts and compare the reslts with the more traditional configration method. We performed a nmber of database tests on nmeros Oracle/VERITAS/EMC configrations. All the configrations sed the same nmber of physical disks and the same size database. The only difference was how the database files were laid ot on the disks. In the VI. Appendix section, detailed test configrations and the three main disk configrations are described. We selected the following three disk configrations becase they have the best performance nmbers in their category: Disk configration 1: Oracle files striped across all 32 drives and their mirror copy on the same 32 drives (SAME with possible disk contention) Disk configration 2: Oracle files striped across 16 drives and their mirror copy on the other 16 drives (SAME with no disk contention) Disk configration 3: Oracle log and data files in separate volmes on 16 drives and their mirror copy on the other 16 drives (Traditional with no disk contention) First we compared disk configrations 1 and 2 to see how potential disk contention can affect the database test reslts. Then, we compared disk configrations 2 and 3 to see the performance difference between the SAME method and the traditional method of data layot. The database tests inclded database creation, large seqential read/write, random read/write, and mixed environment with a single ser and mlti-sers. From the test reslts, we reached the following general conclsions: The SAME method works. Minimize disk contention by evenly distribting IO across the Symmetrix. I/O block size set to 1MB demonstrated optimal performance. VERITAS stripe depth set at 1MB demonstrated optimal performance. Use VERITAS Qick I/O. SAME Method Analysis We exclded disk configration 1 (32-way stripe for both primary and mirror) as the base configration for comparison early becase disk configration 2 (16-way stripe for primary and 16 way for mirror) has better performance nmbers. See Disk Contention Analysis for details. Comparing the test reslts from disk configration 2 (SAME approach) and 3 (traditional approach), SAME approach has eqivalent or better reslts than the traditional approach. For example, the fll index scan time of disk configration 2 is 22% and 14% faster than that of disk configration 3 in a large seqential read environment and mixed environment (large seqential read and random read/write), respectively. The two disk configrations have the same amont of data and same nmber of disks, the only difference was data layot. Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 9

10 IV. Test Configrations and Analysis Fll Table Scan (Large Seqential Read) Relative Elapsed Time Disk Config 1 (SAME w/contention) Disk Config 2 (SAME) Disk Config 3 (Traditional) Fll Table Scan (Mixed I/O Load) Relative Elapsed Time Disk Config 1 (SAME w/contention) Disk Config 2 (SAME) Disk Config 3 (Traditional) Disk configration 2 (SAME) also has eqivalent or better test reslts than disk configration 3 (traditional) in the following areas: Database bild operations - database creation, tablespace creation, table loading, and index creation. Large seqential read operations - fll table and index scan in single and mlti-ser environments. Large seqential write operations - tablespace and index creation in single and mlti-ser environments. Random read write operations - OLTP test with eight clients. Or test reslts show the following benefits of the SAME method: Striping across all disks ensres high disk tilization and performance. Hotspots on individal disks are eliminated. Mirroring data ensres high availability. Overall performance is better. 10 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

11 IV. Test Configrations and Analysis Disk Contention Analysis We compared placing all the primary and mirrored data on the same disk grop (disk configration 1) and separating the primary and mirrored data into two disk grops (disk configration 2). Disk configration 1 can have disk contention de to the possibility of simltaneos access of primary data from one file or stripe set and mirrored data from another file or stripe set on the same disk. Disk configration 2 does not have this problem. According to test reslts, disk contention does impact performance. Fll table scan time of disk configration 2 (SAME) is 17% faster and 43% faster than disk configration 1 (SAME with contention) in a large seqential read environment and mixed environment (large seqential read and random read/write), respectively. We also observed that disk configration 2 index creation time is 54% faster than that of disk configration 1. Index Creation Relative Elapsed Time Disk Config 1 (SAME w/contention) Disk Config 2 (SAME) Disk Config 3 (Traditional) Striping Considerations In general data striping increases Oracle I/O performance. The reslts of or testing showed some interesting trends depending on the environment. The variables that we changed dring testing inclded: Stripe depth (VERITAS Volme Manager stripe nit size). I/O block size (size of I/O being striped across mltiple disks). Nmber of sers (single ser vs. mlti-ser environment). Type of I/O (read-intensive vs. write-intensive environment). Oracle I/O Block Size We observed that for both read and write operations, regardless of the stripe depth, the following configrations gave s the best reslts: Write: DB_FILE_DIRECT_IO_COUNT x Oracle block size shold eqal 1MB. The data showed that when performing a tablespace creation, 1MB I/O block size can be as mch as 31% faster than 64K block size. Read: DB_FILE_MULTIBLOCK_READ_COUNT x Oracle block size shold eqal 1MB. The data showed that when performing a fll table scan, 1MB I/O block size can be as mch as 62% faster than 64K block size. Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 11

12 IV. Test Configrations and Analysis General Recommendation: Or reslts indicated that in mlti-ser environments, the stripe depth shold be set to 1MB. In or case, we varied the stripe depth between 256KB and 1MB and fond that 1MB depth offered the best overall performance. Also, for maximm performance, the I/O block size shold be calclated as the stripe depth mltiplied by the stripe width. For example, we sed stripe widths of 512KB, 1MB, and 2MB with the stripe depth of 1MB across two disks and fond that the best performance occrred with the stripe width of 2MB. Fll Table Scan of 17GB Table With Parallel Degree of 4 DB_BLOCK_SIZE=8K Stripe Depth Oracle Parameter DB_FILE_MULTIBLOCK_READ_COUNT Oracle Read I/O Size Actal Read Size Elapsed Time 1MB 8 64K 64K 8 min 46 sec 1MB K 128K 7 min 47 sec 1MB K 1024K 6 min 13 sec 1MB K 1024K 6 min 13 sec Note Oracle Read I/O Size is eqal to DB_BLOCK_SIZE x DB_FILE_MULTIBLOCK_READ_COUNT. VERITAS Qick I/O Reslts VERITAS Qick I/O technology showed dramatic performance improvements in or test configrations, especially in large seqential write environments. This increase is expected as VERITAS Qick I/O was designed to provide performance improvements in write-intensive OLTP (Online Transaction Processing) environments. VERITAS Qick I/O implements a direct I/O write capability that enables large I/Os to bypass typical file system bffering as well as eliminating potential redndant locking between the file system and Oracle databases. The test reslts demonstrated the benefits of VERITAS Qick I/O. From the varios tests, the most dramatic performance boost was for tablespace creation time. Tablespace creation can be p to 325% faster than a comparable Oracle configration rnning on a file system withot Qick I/O. Althogh it is not reflected in this paper, this likely resembled the eqivalent performance we wold expect if we ran the test sing raw I/O. In essence, VERITAS Qick I/O provides the ability to have file system manageability with raw device performance. 12 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

13 IV. Test Configrations and Analysis The reslts listed below show the performance increase of rnning an Oracle database with VERITAS Qick I/O vs. rnning the same Oracle database on a file system withot Qick I/O: VERITAS Qick I/O Comparisons 3.5 Relative Elapsed Time Database Creation Tablespace Creation Index Creation Qick I/O No Qick I/O Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 13

14 V. Conclsion V. Conclsion Simplicity is good. Or test reslts demonstrated that when configring an Oracle database with a storage sbsystem, the Stripe And Mirror Everything (SAME) method is effective. We were able to show that the SAME method works as well as, or better than, the traditional method. We also determined specific Oracle, VERITAS, and EMC Symmetrix configration recommendations, as well as demonstrated improved database performance when sing VERITAS Qick I/O. Or general concltions are: The SAME method works. Minimize disk contention by evenly distribting IO across the Symmetrix. I/O block size set to 1MB demonstrated optimal performance. VERITAS stripe depth set to 1MB demonstrated optimal performance. Use VERITAS Qick I/O. Hardware and software technology advances have overcome some past limitations. Oracle, VERITAS, and EMC prodcts inclde many advanced capabilities, sch as parallel database exection, efficient and scalable striping sing VERITAS Volme Manager, and large Symmetrix cache, that make the SAME approach possible. For example, the large EMC non-volatile cache eliminates the need for striping Oracle log files sing fine grain striping to achieve very fast seqential I/O. The cache will bffer the write operation and de-stage it to disks at a later time. The SAME method offers a simple, easy way to configre an Oracle database and storage while providing high data availability and performance. Pls the SAME approach is application and work load independent, so it can be implemented easily in a fast changing compting environment. A new idea. Today, most Oracle DBAs do not configre an Oracle database and storage based on the SAME method becase that is not how they were trained to implement Oracle and storage. Then, there is the isse of losing control and flexibility of a manally tned storage configration. However, database and storage soltions are getting bigger and more complex, jst as the storage environment is changing at ever faster Internet speed. The SAME method offers a new and innovative way of correcting this problem. In this paper, we described how we implemented the SAME configration with the Oracle/VERITAS/EMC Symmetrix combination and obtained very good database performance reslts. Therefore, with the right storage software and hardware soltion, we recommend that Oracle DBAs consider the new SAME approach. 14 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

15 VI. Appendix VI. Appendix Test Configration Details Hardware Details SUN E3000 (Sn4 SPARC, Ultra-Enterprise) 4 x 248Mhz CPUs 2GB RAM 2026MB Swap FC EMC-S 64 bit FDDI controller EMC Symmetrix (5265 Microcode) 2GB cache 32 x 36GB physical disks 32 disks were divided into 4 eqal sections called hyper-volmes, with each hyper-volme of size 8.2GB. Only the first hyper-volme from each disk is sed for testing eliminating the possibility of contention The third and forth hyper-volmes were sed for backp of the database. Configration of hyper-volmes and mirroring is done at the EMC level (Operating System sees each hyper-volme as a separate disk, sch as c2t15d0) and the hyper-volmes sed for mirroring are not seen by the Operating System. Software Details Solaris 2.6 JNI Fibre Channel SCSI HBA driver (64 bit) - version EMC VERITAS Database Edition for Oracle VERITAS File System (VxFS) VERITAS Volme Manager (VxVM) VERITAS Qick I/O Database Details Oracle8i Release 2 (8.1.6) Database sed for testing is an extract of Oracle Acconts Receivables application schema and the total size of the database is 50 GB inclding system, rollback segment and temporary tablespaces. System tablespace :500MB 3 x redo logs :100MB (each) Rollback tablespace :2000MB Tools tablespace :200MB Temp tablespace :10GB Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 15

16 VI. Appendix Data tablespace Index tablespace :30 GB :10 GB EMC Disk Configrations Step-by-Step Setp Disk Configration 1 (1x32) VxFS with Qick I/O Stripe depth (nit) 256K - 1MB, Stripe width 1x32 (stripe Oracle files over 32 drives) (mirror on the same 32 drives) Disk Configration 2 (1x16) VxFS with Qick I/O Stripe depth (nit) 256K - 1MB, Stripe width 1x16 for everything (mirror on the other 16 drives) Disk Configration 3 (1x2,1x2,1x12) VxFS with Qick I/O Stripe depth (nit) 256K - 1MB, Stripe width 1x2 for redo log1, 1x2 for redo log2, 12 for everything else (mirror on the other 16 drives) 1. Install and configre the EMC Symmetrix 2. Install JNI fibre adapter hardware for EMC Contact EMC Systems Engineer assigned to the cstomer site to develop a Symmetrix configration optimal to yor environment. Refer to the recommendations listed in Figre A of the appendix. In or test environment, we sed JNI 64-bit S-Bs fibre adapter (FC EMC-S 64-bit adapter with integrated non-ofc optical interface short wave). Install the adapter according to hardware installation gide. Reboot the host (command line >reboot -- -r) (boot prompt ok>boot -r) After reboot, verify presence of the adapter card with the following command: prtconf -v grep fcaw Response shold be: fcaw (driver not installed) 16 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

17 VI. Appendix 3. Configre JNI device driver software Install the JNI device driver package from the spplied CD-ROM. Note The CD-ROM normally contains the driver package for EMC. If it does not, yo can download it from Symmetrix/Solaris/v2.2.3.EMC. Select JNIfcawEMC.pkg and save the link. The driver version we sed in or test is EMC. The driver package is installed sing: pkgadd -d JNIfcawEMC.pkg After sccessfl installation of the driver, verify the device driver: prtconf -v grep fcaw Response shold be fcaw, instance #0 At this point, the operating system sees the JNI adapter card, bt not the target drives (EMC disks/hyper-volmes). 4. Install EMC Control Center (ECC): Cstomer selection of hyper-volmes will reqire: ECC Symmetrix Manager, version 4.01 ECC Symmetrix Disk Reallocation, version 4.01 Reference the ECC Prodct manals for installation and configration instrctions Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 17

18 VI. Appendix 5. Identify devices to be sed in striped volme sets: Cstomers shold identify devices to be sed in stripe sets, in a pattern sch that IO will be evenly distribted across as many of the backend physical disks and disk directors (controllers) as possible: Start the EMC Symmetrix manager Open the Disk Director Configration View All types of Symmetrix devices will be visible. Cstomers shold select only M1 (standard) devices. The portion of the disk device represented in yellow denotes the type of Symmetrix device. Select standard devices (ble icons) so that they are evenly distribted across as many of the backend disk directors as possible and across physical disk drives. For Example: In figre A (below), devices 0D, 0F, 11, and 13 are located across physical disks and across all available disk controllers. In or tests, two disk directors provided a total of eight backend adapter ports. Stripe sets in this environment shold be mltiples of 8 volmes in size to evenly distribte IO activity across the backend of the Symmetrix. Shold sixteen ports be available, stripe set increments of 16 volmes wold be recommended. Cstomers shold also select devices for a stripe set according to a wide then deep pattern. First select devices across all available backend disk directors (wide) before selecting devices from the same director (deep). For large stripe sets where striping deep is reqired, select the devices in a C, E, D, F pattern to take advantage of the dal processors on the disk directors. For Example, in Figre A there is one disk director (DA02) represented. The Symmetrix spports two to eight directors, depending on the model. Devices shold be selected across the available directors (DA02, DA03, DA04, etc.) before selecting devices down a director (DA02: C, E, D, or F). 18 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

19 VI. Appendix 6. Assignment of Devices to host channels: The devices that were identified in step 3B, now mst be evenly distribted across the channels connecting to the host. In the EMC Symmetrix Manager GUI, Open the Controls men; select SDR (Disk Reallocation) and open. Enter the cstomer password From the Symmetrix Disk Reallocation Window the nassigned Standard devices will be available in a pool at the bottom of the screen. Figre C is an example of this window. Select the devices chosen in step 3B and evenly distribte them across the channels attached to the host. Specific device nmbers shold be dragged from the available pool and dropped across the available host channels. In or prior example we selected for devices, 0D, 0F, 11, and 13. If possible, assigning each of these devices to a separate host channel will provide an even distribtion for IO. If there are two channels available, then 0D/0F shold be assigned to one channel and 11/13 to another. Assign a Target and LUN address for each device When all of the devices have been allocated, open the controls men, select SDR and commit. NOTE: EMC Systems Engineers can also pre-assign devices at the time of the Symmetrix installation if the cstomer reqests it. Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 19

20 VI. Appendix 4. Configre host and kernal settingst Edit /kernel/drv/sd.conf file and make entries for EMC disks (LUNs) For example: name="sd" class="scsi" target=15 ln=0; name="sd" class="scsi" target=15 ln=1; and so on for all LUNs and targets Reboot the host. Dring reboot, yo may see warnings like: Corrpt label - wrong magic nmber To fix the above warning for the EMC disks, invoke the format command, select EMC disks, and label them (except gatekeeper disks). To enable the necessary scsi fibre commands, we sed the following EMC related kernel parameters in or test environment (set in /etc/system file): set sd:sd_max_throttle=20 (defalt is 256, bt in most EMC configrations, it is set to 20) set scsi_options = 0x7F8 set sd:sd_io_time = 0x78 For more information, see the EMC Fibre Channel Prodct Gide. Note I/O transfer size from host to EMC Symmetrix is controlled by kernel parameter maxphys with a defalt vale of 128K. If an I/O block size exceeds the defalt vale, the I/O reqest will be broken p into more than one reqests - each reqest does not exceed the defalt size. Please refer the following JNI file for frther details: /Solaris/v2.2.3.EMC/release.txt. See Section 1.2, Raw I/O tning Recommendations. Set defalt vale to 1MB. At this point, the operating system sees the EMC drives. 20 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

21 VI. Appendix 5. Install VERITAS software packages Install VERITAS Database Edition for Oracle (Solaris 2.6). Please refer to the VERITAS Database Edition for Oracle Installation Gide for complete details. As part of VERITAS software installation, we installed the following components: VRTSdbes VERITAS Database Edition for Oracle VRTSdbpat VERITAS Database Edition for Oracle VxFS Patch VRTSqio VERITAS file device interface VRTSvxfs VERITAS File System VRTSvmsa VERITAS Volme Manager Storage Administrator VRTSvsma VERITAS Storage Manager Agent VRTSvxva VERITAS Volme Manager Visal Administrator VRTSvxvm VERITAS Volme Manager VRTSvxvm.2 VERITAS Volme Manager, Binaries VRTSvmman VERITAS Volme Manager (manal pages) VERITAS related kernel parameters in or test environment (set in /etc/system file) * vxvm_start (do not remove) forceload: drv/vxdmp forceload: drv/vxio forceload: drv/vxspec *vxvm_end (do not remove) * vxfs_start -- do not remove the following lines: * VxFS reqires a stack size greater than the * defalt 8K. * The following vales allow the kernel stack * size for all threads to be increased to 16K. set lwp_defalt_stksize=0x4000 set rpcmod:svc_rn_stksize=0x4000 * vxfs_end We are now ready to add EMC drives into VERITAS Volme Manager control. Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 21

22 VI. Appendix 6. Create a volme Start vmsa GUI tool for VERITAS storage configration /opt/vrtsvmsa/bin/vmsa The vmsa tool has easy interface to add and initialize the disks. Once all EMC drives are initialized (nder some disk grop sch as emcdg), we can create a volme of desired properties. In or SAME method, we created a volme called emcvol1 with the following layot: striped, 16 colmns, Stripe Unit Size of 256K (Configration 1). Click on the Assign disks btton and select 16 disks. Then, click on the Add file system btton and select VxFS FS type. The above VERITAS step can be done at the command level as well. Now, we shold have one volme striped across a desired nmber of disks with selected Stripe Unit Size, with a VxFS file system created and monted (for example, the mont point is /emcfs_data). Note Oracle and VERITAS recommend sing the SAME volme for the Oracle database only. 7. Enable Qick I/O and datafile creation By defalt, the monted vxfs file system is not Qick I/O enabled. To add Qick I/O spport, pre-allocate database files sing: /sr/sbin/qiomkfile -s 500M /emcfs_data/system.dbf This command creates two files, the actal file (.system.dbf) of specified size, and a soft link file (system.dbf) pointing to the actal file: > ls -al /emcfs_data/*system.dbf -rw-rw-r-- 1 oracle dba Mar 8 17:47.system.dbf lrwxrwxrwx 1 oracle dba 23 Feb 28 17:21 system.dbf >.system.dbf::cdev:vxfs: Datafiles referred by the database shold be the soft link file (system.dbf), not the actal file (.system.dbf). Pre-allocate all datafiles before being sed in tablespace creation inclding redo log files When sing pre-allocated Qick I/O files, yo do not need to specify the size of the datafile (for example, Create tablespace xyz datafile /emcfs_data/system.dbf rese. In this case, Oracle will determine datafile size and create the tablespace. Please note that specifying size 0 will give an ORA-1257 error) Oracle I/O related init.ora parameters we set in or test are: db_block_size=4096 # defalt 2048 db_file_mltiblock_read_cont=256 # defalt 8 # set to 256 to have mltiblock read I/O of 1M size (256*4096) db_file_direct_io_cont=256 # defalt 64 # set to 256 to have datafile initialization I/O of 1M size (256*4096) 22 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

23 VI. Appendix Figre A Figre B Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 23

24 VI. Appendix Figre C 24 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

25 VI. Appendix EMC Soltions: The following is a brief description of the EMC prodcts discssed in this docment. More detailed prodct information can be obtained from the EMC company website: EMC Symmetrix: The Symmetrix series Enterprise Storage systems provide a shared repository for a company s most valable resorce its information. Symmetrix systems provide the indstry s highest performance, availability, and scalable capacity with niqe information protection, management, and sharing capabilities for all major systems, mainframe, and other environments. EMC Control Center: EMC Control Center (ECC) is a centralized, server-resident software application for managing an EMC Enterprise Storage configration from a single console. ECC provides extensive ser management of storage components across the Enterprise Storage network inclding monitoring, configration, control, tning and planning capabilities. In this docment we discssed two components of ECC: EMC Control Center Symmetrix Manager: Symmetrix manager is the fondation of the ECC soltion, providing convenient access to internal configration, operational stats and real-time performance information. EMC Control Center Symmetrix Disk Reallocation: Symmetrix Disk Reallocation (SDR) gives an administrator the ability to reassign existing Symmetrix open systems logical volmes between Fibre and SCSI adapters, Target/LUN addresses or open system hosts. Using a drag-and-drop window SDR facilitates workload balancing by allowing volmes to be evenly distribted across the Symmetrix. EMC PowerPath: PowerPath is a server-resident software prodct from EMC that works with a Symmetrix storage system to deliver intelligent I/O path management. With EMC PowerPath, administrators can improve the server s ability to manage heavy storage loads throgh continos, intelligent I/O balancing. PowerPath atomatically configres mltiple paths and dynamically tnes for performance as workloads change. PowerPath also adds to the high-availability capabilities of the Symmetrix storage system by atomatically detecting and recovering from server-to-storage path failres VERITAS Database Edition for Oracle VERITAS Database Edition for Oracle prodct information can be obtained from VERITAS company s web site: VERITAS Database Edition incldes the following major components. VERITAS File System The VERITAS File System (referred to as VxFS) is an extent-based, intent logging file system intended for se in environments that deal with large volmes of data and that reqire high file system performance, availability, and manageability. VxFS also provides enhancements that make file systems more viable in database environments. Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 25

26 VI. Appendix VERITAS Qick I/O Databases can rn on either file systems or raw devices. Database administrators often create their databases on file systems becase it makes common administrative tasks (sch as moving, copying, and backing p) easier. However, rnning databases on most file systems significantly redces database performance. When performance is an isse, database administrators create their databases on raw devices. VxFS with Qick I/O presents reglar, preallocated files as raw character devices to the application. Using Qick I/O, yo can enjoy the management advantages of databases created on file systems and achieve the same performance as databases created on raw devices. More specifically, Qick I/O s ability to access reglar files as raw devices improves database performance by: Spporting Kernel Asynchronos I/O Asynchronos I/O is form of I/O that performs non-blocking system level reads and writes, which enables the system to handle mltiple I/O reqests simltaneosly. Operating systems sch as Solaris provide kernel spport for asynchronos I/O on raw devices, bt not on reglar files. As a reslt, even if the database server is capable of sing asynchronos I/O, it cannot isse asynchronos I/O reqests when the database rns on file systems. Lack of asynchronos I/O significantly degrades performance. Qick I/O lets the database server take advantage of kernel-spported asynchronos I/O on file system files accessed sing the Qick I/O interface. Spporting Direct I/O and Avoiding Doble Bffering Most database servers maintain their own bffer cache and do not need the system bffer cache. Database data cached in the system bffer is therefore redndant and reslts in wasted memory and extra system CPU tilization. By spporting direct I/O, Qick I/O eliminates doble bffering. Data is copied directly between DBMS cache and disk, which lowers CPU tilization and frees p memory that can then be sed by the database server bffer cache to frther improve transaction processing throghpt. 26 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.

27 VI. Appendix Avoiding Kernel Write Locks When database I/O is performed sing the write() system call, each system call acqires and releases a write lock inside the kernel. This lock prevents mltiple simltaneos write operations on the same file. Becase Oracle databases implement their own locks for managing concrrent access to files, per file writer locks nnecessarily serialize I/O operations. Qick I/O bypasses file system locking and lets the database server control data access. VERITAS Volme Manager The VERITAS Volme Manager (referred to as VxVM) bilds virtal devices called volmes on top of physical disks. Volmes are accessed by a file system, a database, or other applications in the same way physical disk partitions wold be accessed. Using volmes, VxVM provides the following administrative benefits for databases: Spanning of mltiple disks eliminates media size limitations. Striping increases throghpt and bandwidth. Mirroring or RAID-5 increases data availability. Online relayot allows online volme layot changes to improve database performance. As databases grow and sage patterns change, online relayot lets yo change volmes to a different layot. This is accomplished online and in place. Use online relayot to change the redndancy or performance characteristics of the storage, sch as data organization (RAID levels), the nmber of colmns for RAID-5 and striped volmes, and stripe nit size. Hot-relocation atomatically restores data redndancy in mirrored and RAID 5 volmes when a disk fails. Fast volme resynchronization ensres that all mirrors contain exactly the same data and that the data and parity. Volme snapshots allows backp of volmes based on disk mirroring. Dynamic mltipathing (DMP) allows for transparent failover, load sharing, and hot plgging of SCSI devices. Free space pool management simplifies administration and provides flexible se of available hardware. Online administration allows configration changes withot system or database down time. Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved. 27

28 VI. Appendix 28 Copyright April 26, 2000 VERITAS Software Corporation. All rights reserved.