The Revival of Direct Attached Storage for Oracle Databases

Transcription

1 The Revival of Direct Attached Storage for Oracle Databases Revival of DAS in the IT Infrastructure Introduction Why is it that the industry needed SANs to get more than a few hundred disks attached to a highend Oracle system in the late 1990s and yet today s Oracle databases often reside on LUNs comprised of a handful of drives in a SAN? Kevin Closson, who has many years of experience as a Performance Architect for Oracle and other companies. Storage subsystems and their capacity have changed significantly since the late 90s, and because of these advancements, there has been a revival of direct attached storage (DAS), especially in small and medium businesses (SMB) and even in the enterprise. There are many enterprise vendors producing new products that use DAS or have added support of DAS to their product line. LSI is a market segment leader in DAS technology and is expanding the functionality of DAS by combining solid state storage, RAID data protection, and the implementation of intelligent caching technology that caches hot data blocks from hard disk drives (HDDs) to onboard flash storage. Why the push for DAS now after many businesses and corporations have gone to either using storage attached networks (SAN) or network attached storage (NAS)? 1. Performance - DAS performance is faster when compared to SAN or NAS. 2. Cost - There is no need to purchase an expensive external SAN or NAS storage subsystem along with the expensive host bus adapters (HBAs) that are required to access these systems. 3. Ease of use - Implementing DAS is very simple compared to the other storage subsystems. When working with the Oracle database, there is no need for a storage administrator to set up and maintain a DAS subsystem. See section The New Oracle DBA below. The Evolution of DAS DAS technology has significantly evolved since the late 1990s. Innovation has allowed vendors like LSI to overcome the key limitations that DAS had in the past. Here are a few past limitations that DAS has overcome with current technology: 1. Cost! This was one of the main reasons, if not the main reason, that SAN and NAS systems came into existence. With the price of disks so expensive, it was cost prohibitive to have unused disk space attached to a server that could not be utilized for another database or server. 2. Limited to a few numbers of spindles. 20 years ago that might have been true, but today, with the advent of SAS expanders and SAS switches, large storage disk subsystems can be created using DAS. Using new SAS switches (and underlying expanders) you can connect 100s of drives to a single server. 3. Storage is isolated and cannot be attached to and shared with other servers. Currently, a DAS subsystem cannot be shared with multiple hosts with each host accessing the same LUN. Oracle RAC users, look elsewhere. BUT, DAS is capable of attaching to multiple hosts for HA capabilities. By implementing SAS switches, multiple hosts can be attached to the same DAS subsystem to implement High Availability. 4. DAS has no GUI tools to administer the subsystem, it is hard to administer a DAS subsystem. However, LSI has developed a powerful and expansive set of GUI tools along with a comprehensive CLI interface to allow easier administration of a DAS subsystem.

2 Disk Subsystem Costs in the 90s Back in the 90s when database technology was taking off in the enterprise and database growth was increasing, the cost of HDDs was staggering. For example, this 1995 pricing came from the IBM document IBM offers industry s first disk storage subsystem based on Serial Storage Architecture (SSA); 7133 Subsystem Provides High-Performance, Low-Cost Alternative to SCSI Interface : PRICING AND AVAILABILITY IBM 7133 Serial Storage Architecture Disk Subsystem Model 010 (Rack Mount Unit) Standard Configuration: four 2.2 GB drives -- $17,500 Maximum Configuration: sixteen 4.5 GB drives -- $72,300 Model 500 (Deskside Unit) Standard Configuration: four 2.2 GB drives -- $18,000 Maximum Configuration: sixteen 4.5 GB drives -- $72,800 With the high cost of disk subsystems back in the 90s, this was a good reason to migrate to a SAN or NAS infrastructure. Having a few unused disk spindles per server could cost an enterprise hundreds of thousands of dollars, if not more. The prices of current disk technology have drastically changed since the 90s, with the price per terabyte (TB) today being much lower. If a server today has a couple of extra spindles not being utilized, it might cost the enterprise a couple hundred dollars, which is as nothing compared to these same costs a few years ago. An advantage to having a couple of unused spindles on a database server today is they could be used for tuning the storage system. The DBA could use these unused spindles to either isolate certain database objects for better performance, or allocate these spindles to an existing RAID LUN. When using all HDDs for a database and the database requires high throughput in IO per second (IOPS), allocating database objects over more spindles will increase database performance. When allocating more spindles to the disk subsystem to increase performance and not to increase the capacity, this is referred to as short stroking which helps to eliminate the delay in head repositioning by reducing the number of tracks that are used to contain data. Today s cost differences between DAS and SAN/NAS are staggering. If you browse the Internet to compare costs between these disk subsystems, you will see both sides claiming they are cheaper than the other. The biggest omission authors have when calculating these price comparisons is that they don t include the cost of the storage administrator (actually more The Revival of Direct Attached Storage for Oracle Databases 2

3 than one is needed so there is a backup) plus the cost of the infrastructure to deploy a SAN/ NAS, which would include the costs for: HBA Switches Specialized software to maintain SAN allocations/capacities across the enterprise. For DAS implementations, with the current state of technology, there is no need for all these extra expenses. For the Oracle DBA, with the ease of use deploying DAS directly or by using Oracle s Automatic Storage Management system (ASM) for example, the need for a storage administrator is diminished or even eliminated. In the 90s before SAN or NAS, the DBA or the operating system administrator would set up the DAS disks, and that was when it was more difficult since there were no GUI tools to aid in this area. The New Oracle DBA Being an Oracle DBA today is quite different compared to 15 or 20 years ago. Businesses and enterprises are striving to have the Oracle DBA do more with less people. LSI and Oracle Corporation have provided tools and functionality in their products to aid the DBA to do more with less effort as well as achieve better performance. LSI provides the DAS storage component along with the intelligent caching of HOT data blocks to on-board flash that aids the DBA to increase performance without tuning or modifying the database. In today s more complex database environments, it can be difficult and time consuming to fine-tune the database to achieve optimum performance of the storage layer. The goal to optimizing an IO bound database is to increase storage performance, which in turn will indirectly make the database more CPU bound. To increase storage performance in a typical database using all HDDs, the DBA will have to go through many steps to alleviate IO waits: Isolate HOT datafiles to cold disks. If the storage device is highly utilized, moving datafiles to other spindles will help even out the disk load. Possibly rebuild the storage to a different RAID configuration. Changing from a RAID 5 setup to a RAID 10 configuration could increase performance. Add more spindles to the array to get more IOPS. If the database requires high IOPS to get the necessary performance, adding more short stroked disks may be required. Adding these disks will not only result in increased costs for the disks, but the necessary ongoing costs of electricity, increased cooling capacity, and more real estate in the computer room. Consider adding more buffer space in the SGA. It is possible to increase the buffer cache and/or make use of the different caches inside of the SGA to fine-tune the database based on how the data is accessed. Move HOT data to tiered storage. Tiered storage devices could include: Flash Faster spindles Isolated devices with short stroked disks This involves the DBA in constantly looking at the database to determine which is the HOT data today and make the necessary changes to tier the data. The Revival of Direct Attached Storage for Oracle Databases 3

4 Consider looking into table/index/tablespace fragmentation. Depending on the access (especially for full table scans), fragmentation of these data objects can hurt performance. Verify database object statistics are current. There are more areas for the DBA to consider to fine-tune the database; I just touched on the more basic areas. Instead of the DBA fine-tuning the database, testing the changes and scheduling downtime for the database, implementing the LSI Nytro MegaRAID DAS solution can provide the intelligent caching technology to cache hot data blocks to the on-board flash to help achieve maximum efficiency from the storage subsystem. LSI DAS Technologies The LSI DAS products provide an easier way to increase performance of the database without the DBA performing any of the tuning steps above. LSI intelligent caching software on the Nytro MegaRAID card is designed to cache all HOT data from the attached DAS HDD to the on-board flash, which will decrease the latency of reading that data in future accesses. Instead of the DBA tiering HOT data on a frequent basis, the intelligent caching software on Nytro MegaRAID cards can achieve this automatically. The data that is cached in flash will be aged out automatically when that data become cold, i.e. infrequently accessed, leaving room for the new HOT data. In the LSI lab testing using an Oracle 11gR2 database running an Online Transaction Program (OLTP) benchmark, reductions of response times have been averaging from 5x to 10x without any changes to the database (depending on HDD setup). If the DBA would do some minor adjustments/tuning to the database, the results in our tests have seen up to a 29x reduction in database response times when compared to making the same modifications to an all-hdd configuration (see Figure 1 below) Average Baseline HDD Achieved Gains with Database Tuning Average Response Time (seconds) Figure 1: Achieved gains in lab and in show demos running OLTP benchmarks The Revival of Direct Attached Storage for Oracle Databases 4

5 Some of the tuning efforts that were applied to the lab benchmarks were: Decrease the size of the SGA from 10GB down to 2.8GB. Since hot data is in cache, the SGA can be resized to force more physical IO from the on-board flash. The real memory that was cut from the database can be used for another Oracle instance on the same server. Consider increasing database writers. Database writers were increased from the default to 16. Separate the table and index tablespaces onto their own dedicated LUNs and only use these LUNs for caching. Instead of caching the whole database when using one (1) LUN, move the data and index tablespaces onto a separate LUN(s) and point the Nytro MegaRAID cache to these LUN(s). Increase the size of the Online Redo Log to checkpoint less frequently. This benefits both an all-hdd setup as well as the Nytro MegaRAID card setup. Note: Before implementing the Nytro MegaRAID card with caching enabled, the server needs to have spare CPU bandwidth so when the database moves from being IO bound to indirectly more CPU bound, there is spare CPU capacity for the increased load. Oracle Database Features for the New DBA Oracle has provided enhancements to their database that enable the DBA to do more of the storage administration work. From the 90s to the early to mid 2000s, when using SAN and NAS, the storage allocated to the DBA would have to be configured by the storage administrator, and then the operating system administrator would mount these storage devices to the server, and then give the DBA rights to these volumes. This results in a lot of overhead and expense just to simply add disks to a database server. A few years ago when Oracle came out with database version 10g, Oracle included the Automatic Storage Management system. ASM is both a volume manager and a filesystem for the Oracle database files. ASM reduces the administrative overhead for managing database storage by consolidating data storage into a small number of disk groups. This enables the DBA to consolidate the storage for multiple databases to enable improved IO performance. ASM also provides the automatic process of redistributing data across new disk spindles for better data distribution over all the disk spindles again to improve performance with no database downtime. By implementing ASM, the DBA assumes the responsibility of managing the storage used by the databases, which takes the control of the storage away from the storage and operating system administrators. The usage of DAS in the Oracle database infrastructure will support the Oracle database features like Data Guard or standby server, with or without the LSI intelligent caching enabled. Conclusion The Oracle DBA of today has the tools to more easily manage the storage used by the databases compared to the technology of a few years ago. When combining the ease of use of DAS using the LSI Nytro MegaRAID card to create and cache the LUNs, and implementing Oracle s ASM to create the disk groups that will be used by the databases, the overhead of designing, implementing, and maintaining an Oracle database greatly decreases while database performance increases. To find out more information on the new DAS technologies which can aid the Oracle DBA in administering storage for their databases and features to increase database performance, visit the LSI website thesmarterwaytofaster.com which describes these and other technologies utilizing flash storage and intelligent caching of database data using DAS. For more information and sales office locations, please visit the LSI website at: North American Headquarters Milpitas, CA T: (within U.S.) T: (outside U.S.) LSI Europe Ltd. European Headquarters United Kingdom T: [+44] LSI KK Headquarters Tokyo, Japan T: [+81] LSI, the LSI & Design logo, the Storage.Networking.Accelerated. tagline, MegaRAID, and Nytro are trademarks or registered trademarks of LSI Corporation. All other brand or product names may be trademarks or registered trademarks of their respective companies. LSI Corporation reserves the right to make changes to any products and services herein at any time without notice. LSI does not assume any responsibility or liability arising out of the application or use of any product or service described herein, except as expressly agreed to in writing by LSI; nor does the purchase, lease, or use of a product or service from LSI convey a license under any patent rights, copyrights, trademark rights, or any other of the intellectual property rights of LSI or of third parties. Copyright 2012 by LSI Corporation. All rights reserved. > 0912