Skip to main content
main-content

Über dieses Buch

Throughout history, advances in technology have come in spurts. A single great idea can often spur rapid change as the idea takes hold and is propagated, often in totally unexpected directions. Exadata embodies such a change in how we think about and manage relational databases. The key change lies in the concept of offloading SQL processing to the storage layer. That concept is a huge win, and its implementation in the form of Exadata is truly a game changer.

Expert Oracle Exadata will give you a look under the covers at how the combination of hardware and software that comprise Exadata actually work. Authors Kerry Osborne, Randy Johnson, and Tanel Põder share their real-world experience, gained through multiple Exadata implementations with the goal of opening up the internals of the Exadata platform. This book is intended for readers who want to understand what makes the platform tick and for whom—"how" it does what it is does is as important as what it does. By being exposed to the features that are unique to Exadata, you will gain an understanding of the mechanics that will allow you to fully benefit from the advantages that the platform provides.

Changes the way you think about managing SQL performance and processing Provides a roadmap to laying out the Exadata platform to best support your existing systems Dives deeply into the internals, removing the "black box" mystique and showing how Exadata actually works

Inhaltsverzeichnis

Frontmatter

Chapter 1. What Is Exadata?

Abstract
No doubt you already have a pretty good idea what Exadata is or you wouldn’t be holding this book in your hands. In our view, it is a preconfigured combination of hardware and software that provides a platform for running Oracle Database (version 11g Release 2 as of this writing). Since the Exadata Database Machine includes a storage subsystem, new software has been developed to run at the storage layer. This has allowed the developers to do some things that are just not possible on other platforms. In fact, Exadata really began its life as a storage system. If you talk to people involved in the development of the product, you will commonly hear them refer the storage component as Exadata or SAGE (Storage Appliance for Grid Environments), which was the code name for the project.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 2. Offloading / Smart Scan

Abstract
Offloading is the secret sauce of Exadata. It’s what makes Exadata different from every other platform that Oracle runs on. Offloading refers to the concept of moving processing from the database servers to the storage layer. It is also the key paradigm shift provided by the Exadata platform. But it’ more than just moving work in terms of CPU usage. The primary benefit of Offloading is the reduction in the volume of data that must be returned to the database server. This is one of the major bottlenecks of most large databases.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 3. Hybrid Columnar Compression

Abstract
Hybrid Columnar Compression (HCC) is probably one of the least understood of the features that are unique to Exadata. The feature was originally rolled out in a beta version of 11gR2 and was enabled on both Exadata and non-Exadata platforms. The production release of 11gR2 restricted the feature to Exadata platforms only. Ostensibly this decision was made because the additional processing power available on the Exadata storage servers. Because the feature is restricted to Exadata, the recent documentation refers to it as Exadata Hybrid Columnar Compression (EHCC).
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 4. Storage Indexes

Abstract
Storage Indexes are the most useful Exadata feature that you never hear about. They are not indexes that are stored in the database like Oracle’s traditional B-Tree or bitmapped indexes. In fact, they are not indexes at all in the traditional sense. They are not capable of identifying a set of records that has a certain value in a given column. Rather, they are a feature of the storage server software that is designed to eliminate disk I/O. They are sometimes described as “reverse indexes.” That’s because they identify locations where the requested records are not, instead of the other way around. They work by storing minimum and maximum column values for disk storage units, which are 1 Megabyte (MB) by default. Because SQL predicates are passed to the storage servers when Smart Scans are performed, the storage software can check the predicates against the Storage Index metadata (maximum and minimum values) before doing the requested I/O. Any storage region that cannot possibly have a matching row is skipped. In many cases, this can result in a significant reduction in the amount of I/O that must be performed. Keep in mind that since the storage software needs the predicates to compare to the maximum and minimum values in the Storage Indexes, this optimization is only available for Smart Scans.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 5. Exadata Smart Flash Cache

Abstract
The marketing guys at Oracle must like the term “smart.” They have applied it to a dozen or so different features on the Exadata platform. They also seem to like the term “flash,” which is associated with at least a half dozen features as well. To add to the confusion, there are two features in Oracle Database 11g Release 2 that have almost exactly the same names, Database Smart Flash Cache (DBFC) and Exadata Smart Flash Cache (ESFC). While both features make use of flash-based memory devices, they are very different. This chapter is focused on ESFC so we’ll only mention DBFC in passing.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 6. Exadata Parallel Operations

Abstract
Exadata doesn’t have a special way of executing parallel operations that is not available on other platforms running 11gR2. However, parallel processing is a key component of Exadata because efficient handling of Data Warehouse workloads was a primary design goal for Exadata. In addition, because Offloading/Smart Scan depends on direct path reads, which are used by parallel query slaves, parallel operations take on a whole new importance. Traditionally, the use of parallel query has required careful control of concurrency in order to maximize the use of available resources without overwhelming the system. Oracle’s previous attempts at throttling parallel operations to allow them to be used in multiuser environments have not been entirely successful. 11gR2 provides some new capabilities for controlling parallel operations. In particular, a queuing mechanism has been introduced that allows the number of concurrent parallel processes to be managed more effectively. This approach appears to be much better suited to allowing a high degree of parallelism without overwhelming the available resources than previous attempts. 11gR2 also introduced the ability for Oracle to automatically calculate a degree of parallelism on a statement-by-statement basis.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 7. Resource Management

Abstract
If resources were unlimited, there would be no need to manage them. We see this in all aspects of our daily lives. If yours was the only car on the road, traffic signals wouldn’t be necessary. If you were the only customer at the bank, there would be no need for the winding ropes that form orderly lines. But as we all know, this is rarely the case. It is the same for database servers. When the load on the system is light, there is very little need for resource management. Processes complete in a fairly consistent period of time. But when the system gets busy and resources become scarce, we can find ourselves with an angry mob on our hands.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 8. Configuring Exadata

Abstract
Oracle offers an optional service that handles the process of installing and configuring your Exadata Database Machine from start to finish. Many companies purchase this service to speed up their implementation time and reduce the complexity of integrating Exadata into their IT infrastructure. If you’re reading this chapter, you may be considering performing the configuration yourself, or perhaps you’re just interested in gaining a better understanding of how it’s done. The process we’ll discuss here closely resembles the installation process Oracle uses, largely because we will be using the same utility Oracle uses to configure Exadata. The utility is called OneCommand. It takes site-specific information you provide and performs the entire configuration from network, to software, to storage. When the process is complete, your Exadata Database Machine will be fully functional, including a starter database.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 9. Recovering Exadata

Abstract
You may have heard the saying “disk drives spin, and then they die.” It’ not something we like to think about, but from the moment you power up a new system, your disk drives begin aging. Disk drives have come a long way in the past 30 years, and typical life expectancy has improved dramatically. At the end of the day, though, it’s a matter of “when” a disk will fail, not “if.” And we all know that many disk drives fail long before they should. Knowing how to diagnose disk failures and what to do when they occur has generally been the responsibility of the system administrator or storage administrator. For many DBAs, Exadata is going to change that. Many Exadata systems out there are being managed entirely by the DBA staff. Whether or not this is the case in your data center, the procedure for recovering from a disk failure on Exadata is going to be a little different than you are used to.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 10. Exadata Wait Events

Abstract
The Oracle database is a very well instrumented piece of code, and it has been so for quite a while. It keeps track of the amount of time spent in discrete operations via the use of wait events. While the database software is quite complex, wait event analysis allows performance analysts to determine precisely where the database is spending its time. Many difficult performance problems can be resolved by analyzing these wait events. The introduction of Exadata has resulted in the creation of several new wait events to support the unique operations that are performed on the platform. This chapter will focus on describing these new events and how they relate to the activities actually being performed, while contrasting them with the wait events used by the database on non-Exadata platforms. It will also describe a few wait events that aren’t specific to Exadata but play an important role on Exadata platforms.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 11. Understanding Exadata Performance Metrics

Abstract
Oracle Exadata is a big step forward from the traditional database server architecture; however, it is still running the standard Oracle Database software. Most of the usual database performance rules still apply, with the addition of some that recognize the advantage of Exadata functionality like Smart Scans, cell join filtering and the flash cache. In this chapter we will cover the Exadata-specific and -related performance topics, metrics, and some relevant internals.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 12. Monitoring Exadata Performance

Abstract
By now you have learned about the key Exadata performance features and the related performance metrics. Let’s see how we can use these for everyday tasks. We will look at standard tools available for database-layer and cell performance monitoring, and how to interpret their output.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 13. Migrating to Exadata

Abstract
So the day is finally here. Your Exadata Database Machine is installed, configured, tuned, tweaked and ready to go. By now you’ve probably invested many, many hours learning about Exadata, proving its value to the company, and planning how you will make the most of this powerful database platform. No doubt it has been a long road to travel but you aren’t there quite yet. Now the real work begins— migration.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 14. Storage Layout

Abstract
In Oracle 10gR1, Oracle introduced Automatic Storage Management (ASM) and changed the way we think of managing database storage. Exadata is tightly integrated with ASM and provides the underlying disks that have traditionally been presented to ASM by the operating system. Looking at all the various intricacies of cell storage can be a little daunting at first. There are several layers of abstraction between physical disks and the ASM disk groups many DBAs are familiar with. If you’ve never worked with Oracle’s ASM product there will be a lot of new terms and concepts to understand there as well. In Chapter 8 we discussed the underlying layers of Exadata storage from the physical disks up through the cell disk layer. This chapter will pick up where Chapter 8 left off, and discuss how cell disks are used to create grid disks for ASM storage. We’ll briefly discuss the underlying disk architecture of the storage cell and how Linux presents physical disks to the application layer. From there, we’ll take a look at the options for carving up and presenting Exadata grid disks to the database tier. The approach Oracle recommends is to create a few large “pools” of disks across all storage cells. While this approach generally works well from a performance standpoint, there are reasons to consider alternative strategies. Sometimes, isolating a set of storage cells to form a separate storage grid is desirable. This provides separation from more critical systems within the Exadata enclosure so that patches may be installed and tested before they are implemented in production. Along the way we’ll take a look at how ASM provides fault resiliency and storage virtualization to databases. Lastly, we’ll take a look at how storage security is implemented on Exadata. The storage cell is a highly performant, highly complex, and highly configurable blend of hardware and software. This chapter will take a close look at how all the various pieces work together to provide flexible, high-performance storage to Oracle databases.
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 15. Compute Node Layout

Abstract
The term node is a fairly generic one that has many different meanings in the IT industry. For example, network engineers call any addressable device attached to their network a node. Unix administrators commonly use the term interchangeably with host or server. Oracle DBAs often refer to a database server that is a member of an RAC cluster as a node. Oracle’s documentation uses the term compute node when referring to the database server tier of the platform. This chapter is about the various ways in which you can configure your Exadata compute nodes, whether they are members of an RAC cluster (nodes), or nonclustered (database servers).
Kerry Osborne, Randy Johnson, Tanel Pöder

Chapter 16. Unlearning Some Things We Thought We Knew

Abstract
Oracle does some things very differently when running on Exadata than when running on non-Exadata platforms. The optimizations provided by Exadata are designed to take a different approach than Oracle has traditionally followed. This change means that we need to attack some problems with a completely different mindset. That is not to say that everything is different. In fact, most of the fundamental principles remain unchanged. After all, the same database software runs on Exadata that runs on other platforms. But there are some things that are just fundamentally different.
Kerry Osborne, Randy Johnson, Tanel Pöder

Backmatter

Weitere Informationen

Premium Partner

    Bildnachweise