Years ago, it was simple to figure out what hardware you would need to run an Oracle database effectively. But...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
things change. Oracle has evolved into a company offering many products beyond just databases and database-related tools. And so the burning question for many has become, “How do I plan hardware lifecycles around Oracle’s vast array of options?”
Today’s Oracle offers everything from middleware to applications to appdev tools and then some. It is enough to make a database manager’s head spin. Luckily, Oracle offers a great deal of guidance. But that guidance can be contradictory at times and difficult to discern, especially when you incorporate technologies such as virtualization and cloud services into the picture.
Perhaps the best starting point is to look as Oracle’s product families and extrapolate basic requirements to build a suitable hardware matrix. That methodology works well for creating a foundation of hardware requirements and creating the predictions needed for growth and increased demand.
First and foremost is to determine what performance metric is the most important for a given Oracle product. For example, some Oracle databases are I/O-intensive, requiring hardware that can process tens of thousands of transactions per second. Some Oracle middleware applications are processor-intensive, creating high CPU loads for a given process. Other metrics to look at include storage loads, temporary file creation, concurrent connections, replication loads and processing threads.
Those issues define what hardware to select, how to appropriately size that hardware and how to plan for the future. Assigning a bias to transactions, processing or storage comes down to looking at a combination of factors -- the architecture of the application, the intended usage and the maximum expected loads. Applying those three factors to the intended environment offers up many options for selecting hardware, and that’s simply because the environments themselves can vary.
Those environments may consist of virtualized servers, various network operating systems, cloud-based services, storage area networks (SANs) and so on -- which adds another layer to the hardware foundation. Perhaps the best advice is to look at a particular Oracle solution as a complete platform, a sum of the various parts that need to work as a whole.
How different editions of the same database require different hardware
Applying that ideology to various Oracle products proves to be one of the best methods of sizing hardware. Take Oracle 11g Database, which comes in multiple editions. The product is available in Enterprise Edition, Standard Edition, Standard Edition One and Express Edition. Each edition has differing hardware requirements. For example, Oracle Database 11g Enterprise Edition features advanced capabilities such as clustering, failover, advanced security and other enterprise-level features that drive the basic hardware requirement from a single-server installation to a multiserver cluster. Administrators must look at the expected loads, traffic, quantity of transactions and connectivity to come up with the appropriate hardware. The calculations involved could probably fill a book on their own.
Things get simpler when looking at the Standard Edition of Oracle Database 11g. That edition incorporates basic features, which can be translated into measurable server loads. Oracle offers some basic guidelines on their website for minimum hardware requirements, stating that the minimums are roughly 1.5 GHz dual-core Pentium processors, 2 GB of physical memory and 3 GB of free disk space. Of course, those minimums have to be added to the requirements of the base operating system, such as Windows Server, Linux or Unix.
Those requirements give a basic understanding for what is needed to run a fresh installation of Oracle Database 11g Standard Edition. Next, you should account for total database size, growth of the database, throughput needed (such as transactions per second, number of users and record size) and any management overhead. A free hardware sizing tool is available at www.sizinglounge.com. It does a decent job of calculating what hardware is needed to run an Oracle database. That calculator takes into account number of users, type of implementation, base version of the Oracle database and even takes into account anticipated processor utilization, as well as total cost of ownership (TCO) factors and energy utilization.
Of course, it gets more complicated when taking into account virtualized servers, simply because it is hard to estimate the performance offered by a virtual machine under a given configuration. To better fine-tune the requirements, a virtual server management suite should be incorporated that calculates performance as well as monitors availability and can run synthetic tests to gauge overall performance.
For other Oracle products, many of the same rules apply. For example, Oracle Fusion Middleware has basic requirements published on Oracle's website. It will be up to the administrator or implementer to calculate above and beyond the basic requirements to effectively size hardware to meet current and future needs. Depending upon the elements and options chosen the requirements can vary greatly. Oracle offers comprehensive information on its Oracle Technology Network website, which can be accessed from Oracle's main webpage.
It is important to note that the combination of products, features and management tools will dictate what the minimum requirements are, and most administrators will find their own minimum requirements unique for their particular environment. Perhaps the most important thing to know is that it takes extensive research to determine what hardware is best suited for particular Oracle product implementations. What's more, advanced capabilities such as clustering, high availability or grid-style implementations will further impact the hardware selected and even the deployment of that hardware, including the interconnects, as well as the base infrastructure.
Basic rules for picking hardware for Oracle environments
There are some basic rules to follow that can lay the foundation for hardware selection. That foundation will be based on specific elements such as CPU capabilities, I/O and overall throughput. However, the first decision to size hardware depends on the base operating system and whether virtualization will be used.
For example, virtualized server environments respond well to high-performance, multicore CPUs that incorporate virtualization technology. That requirement should trump all others when it comes to deploying Oracle on a virtualized server.
Oracle products that demand high I/O are better suited by systems that can run multiple threads, wide 64-bit data paths, and have high-speed interconnects incorporated into the system board. Those high-speed interconnects may consist of Fibre Channel connectivity for SAN deployments, 10 Gigabit Ethernet for high-speed communications between infrastructure components, and a high-performance backplane for intelligent rack-mounted systems.
Hardware selection should not be based solely upon server performance. Other elements such as serviceability, integration, expansion and management should all be primary considerations for selecting a hardware platform on which to run Oracle. Those considerations play well into return on investment (ROI) and overall TCO, which are critically important when it comes to budgeting and meeting the core needs of the business. Products that are easier to upgrade tend to deliver a lower TCO over time and improve ROI.
When selecting hardware for an Oracle ecosystem, it is always important to remember the primary factors to consider. Those factors not only include performance of the Oracle products deployed, but also the initial cost, the initial utilization, anticipated growth and hardware lifecycles. All those elements are used to calculate TCO, which has become the financial language of the IT department.