ORACLE isn't a one-person job, as the database interfaces with hundreds of capabilities and components. Data architects, database administrators (DBAs), storage managers, plus a host of other business personnel must work coordinate in order to appropriately configure storage for ORACLE and appropriately tune the storage for optimal performance. I've included several tips to be able to simplify system configuration and performance tuning on your storage system.
Configuring the Big Four
You'll find four key hardware components to consider when constructing or fine-tuning an Oracle hardware infrastructure. Architects need to ensure a balanced design, as the whole system is only as powerful as the weakest link.
CPU Memory Data Storage Network
Although frequently an improvement in one or many of the above components may possibly generate an improvement in performance, there are limits to that improvement based on which variable might be developing a efficiency constraint.
Carefully identifying the dilemma component will make it easier and much more cost-effective to alleviate any performance constraints that may possibly be occurring. Any performance increases that result from adding hardware need to be deemed short-term relief, as increased application use is likely to cause the exact same difficulties in the near future.
Speak with a storage professional to establish what program is likely to scale most successfully for your environment when sizing or deploying a brand new system to support your Oracle databases.
Symptoms and Difficulties
Slow Physical I/O - This results when disks have been configured improperly or too few resources have been allocated to support the database.
Excessive CPU Usage - Excessive CPU usage means there is small to no idle CPU on the storage system. This can happen when a program has not been sized adequately as a result of inability of the CPU to scale and meet demand.
Outages - This can happen when proper redundancy has not been built into the system in order to account for failures
Usually, the symptoms are indication of an underlying problem in the hardware, poorly configured solutions, or untuned SQL statements.
Hardware and I/O Considerations
I/O efficiency is a key component when designing Oracle systems. When I/O workloads are specially intensive, the underlying I/O or storage program ought to be designed to meet these requirements. Under-sizing a remedy can lead to lost time and wasted resources for your organization. These five guidelines can help you guarantee that your system is effectively built to support your databases for the entire life-cycle of the application.
Configure I/O for Bandwidth Before Capacity
Storage configurations should be assembled based on I/O bandwidth, and not only on their overall storage capacity. The capacity of each disk drive is growing significantly quicker than their I/O throughput rates, creating a scenario where a modest quantity of disks can hold a significant data volume. Even so, these disks cannot manage the throughput of smaller disks. For example, spreading data over multiple 146GB or 73GB drives will lead to far better efficiency than a single 600GB disk.
Stripe as "Far and Wide" As Feasible
Oracle recommends utilizing multiple disks and channels across database objects. This can be accomplished by striping datafiles of the Oracle databases bring deployed.
Use Redundancy
Disk redundancy is actually a requirement to protect against hardware failure. A key consideration is that usually a balance should be struck between redundancy and efficiency. RAID 5 may be less high-priced than RAID 10, even so it might not perform also. If price constraints are an problem, a storage consultant can assist you to decrease the price of the answer and still meet your needed efficiency levels.
Test The System Just before Constructing A Database
Examine I/O and tune the program prior to the database is developed. As soon as the file is created, reconfiguring the files becomes a lot a lot more hard. Greater collaboration across system resources makes this a troubling effort. It is crucial to keep in mind that I/O bandwidth need to be tested to validate that expected I/O levels are becoming achieved.
Program for Growth
It is imperative to plan for future growth of an Oracle database. The key would be to be able to grow and not compromise I/O bandwidth. Not properly planning for growth will eventually trigger over-utilization of resources and efficiency issues.
Note: You can't simply add disks to an existing system and add a brand new database table across new disks. Correctly sizing the disk program the first time prevents complicated upgrades and migration in order to grow an I/O system inside the array.
Bottleneck Elimination
The purpose of tuning would be to lessen resource consumption or reduce time for an operation to be completed. In general, efficiency difficulties result when a resource is over-used. This produced a bottleneck within the method. Contention is a symptom that could typically be fixed by producing the changes below:
Modifications in the way the application is being utilized Changes in your Oracle database Changes in hardware configurations
Get It Right The very first Time
Consider these requirements when designing a storage program and SAN to support your Oracle databases:
Storage - Minimum disk capacity and spindle count. Remember that a lot more spindles yields far better efficiency. Availability - Is this a 24/7 system or will it only be utilized in the course of enterprise hours? 24/7 utilization demands proper engineering that could handle maintenance with no outages. Efficiency - I/O throughput and application response times will determine the necessary configuration
Configuring the Big Four
You'll find four key hardware components to consider when constructing or fine-tuning an Oracle hardware infrastructure. Architects need to ensure a balanced design, as the whole system is only as powerful as the weakest link.
CPU Memory Data Storage Network
Although frequently an improvement in one or many of the above components may possibly generate an improvement in performance, there are limits to that improvement based on which variable might be developing a efficiency constraint.
Carefully identifying the dilemma component will make it easier and much more cost-effective to alleviate any performance constraints that may possibly be occurring. Any performance increases that result from adding hardware need to be deemed short-term relief, as increased application use is likely to cause the exact same difficulties in the near future.
Speak with a storage professional to establish what program is likely to scale most successfully for your environment when sizing or deploying a brand new system to support your Oracle databases.
Symptoms and Difficulties
Slow Physical I/O - This results when disks have been configured improperly or too few resources have been allocated to support the database.
Excessive CPU Usage - Excessive CPU usage means there is small to no idle CPU on the storage system. This can happen when a program has not been sized adequately as a result of inability of the CPU to scale and meet demand.
Outages - This can happen when proper redundancy has not been built into the system in order to account for failures
Usually, the symptoms are indication of an underlying problem in the hardware, poorly configured solutions, or untuned SQL statements.
Hardware and I/O Considerations
I/O efficiency is a key component when designing Oracle systems. When I/O workloads are specially intensive, the underlying I/O or storage program ought to be designed to meet these requirements. Under-sizing a remedy can lead to lost time and wasted resources for your organization. These five guidelines can help you guarantee that your system is effectively built to support your databases for the entire life-cycle of the application.
Configure I/O for Bandwidth Before Capacity
Storage configurations should be assembled based on I/O bandwidth, and not only on their overall storage capacity. The capacity of each disk drive is growing significantly quicker than their I/O throughput rates, creating a scenario where a modest quantity of disks can hold a significant data volume. Even so, these disks cannot manage the throughput of smaller disks. For example, spreading data over multiple 146GB or 73GB drives will lead to far better efficiency than a single 600GB disk.
Stripe as "Far and Wide" As Feasible
Oracle recommends utilizing multiple disks and channels across database objects. This can be accomplished by striping datafiles of the Oracle databases bring deployed.
Use Redundancy
Disk redundancy is actually a requirement to protect against hardware failure. A key consideration is that usually a balance should be struck between redundancy and efficiency. RAID 5 may be less high-priced than RAID 10, even so it might not perform also. If price constraints are an problem, a storage consultant can assist you to decrease the price of the answer and still meet your needed efficiency levels.
Test The System Just before Constructing A Database
Examine I/O and tune the program prior to the database is developed. As soon as the file is created, reconfiguring the files becomes a lot a lot more hard. Greater collaboration across system resources makes this a troubling effort. It is crucial to keep in mind that I/O bandwidth need to be tested to validate that expected I/O levels are becoming achieved.
Program for Growth
It is imperative to plan for future growth of an Oracle database. The key would be to be able to grow and not compromise I/O bandwidth. Not properly planning for growth will eventually trigger over-utilization of resources and efficiency issues.
Note: You can't simply add disks to an existing system and add a brand new database table across new disks. Correctly sizing the disk program the first time prevents complicated upgrades and migration in order to grow an I/O system inside the array.
Bottleneck Elimination
The purpose of tuning would be to lessen resource consumption or reduce time for an operation to be completed. In general, efficiency difficulties result when a resource is over-used. This produced a bottleneck within the method. Contention is a symptom that could typically be fixed by producing the changes below:
Modifications in the way the application is being utilized Changes in your Oracle database Changes in hardware configurations
Get It Right The very first Time
Consider these requirements when designing a storage program and SAN to support your Oracle databases:
Storage - Minimum disk capacity and spindle count. Remember that a lot more spindles yields far better efficiency. Availability - Is this a 24/7 system or will it only be utilized in the course of enterprise hours? 24/7 utilization demands proper engineering that could handle maintenance with no outages. Efficiency - I/O throughput and application response times will determine the necessary configuration
About the Author:
If you are in the market for EMC Storage or IBM Storage, we are the leading supplier for all your technology storage needs. You'll save thousands on excellent new and refurbished hardware equipment.
No comments:
Post a Comment