Pre-RAC

Let’s face it, today’s IT environments are constantly changing. Acquisitions, mergers, global economies and general market malaise continually put pressure on IT infrastructures. It has become increasingly difficult for IT organizations to predict, plan, and implement suitable computing environments that meet current and future requirements.

Corporations, when planning database systems, seem to be in a constant battle between purchasing systems that meet current requirements and systems that might meet future expectations. The unfortunate reality is that both approaches are inadequate compared to the dynamic nature of the systems we must supply to the end-user community.

When systems are built based on today’s requirements, without looking to the future, what is often left behind after requirements change is a collection of small, discrete systems scattered throughout the organization, each supporting one or two applications. These stand-alone systems are often undersized, too small or too large for the applications they support, and are likely to become islands of computing power spread throughout the corporation. To make matters worse, these discrete systems are often unable to facilitate communications between application layers or even simply share data between them. Look at any of these systems in an enterprise and you’ll also see wasted or unused CPU cycles, wasted disk storage subsystems, and overworked DBAs and administrators desperately trying to maintain some control over these systems.

Buying large centralized servers or larger systems than what is currently required is not better. Companies that go this route often put all applications on one server or buy more computing power than they currently need. Designing systems in this way has proven to be very expensive and a waste of money and resources.

Downtime is always disastrous, but having everything running on one system has the potential to bring down every aspect of your business at the same time. This applies to both unplanned downtime and planned downtime, such as maintenance windows.

When systems are too large with endless processing power, these systems are often taken for granted and sloppy or poorly tested applications are deployed without going through some form of performance or scalability testing. In the future, when additional CPU, memory, or disk resources are needed, they simply aren’t available.

Vigilant prides itself on taking the time to consider your requirements, transform them into workable solutions, and select the right set of components for your computing environment.

Both small discrete and large dedicated systems share one thing in common. Both often have multiple single points of failure that limit their ability to provide the high availability required in today’s 24X7X365 environments. All it takes is for one component to fail and then regardless of how little or how much money you spent, your system simply becomes useless and potential revenue is lost due to the downed system.

Do not misunderstand. Small discrete and large dedicated systems have their place. They have served us well for many years. But these environments simply don’t provide the necessary infrastructure for scalability, performance, and availability. For those environments that need more, they turn to Oracle’s Real Application Clusters (RAC).

What is RAC?

Before going any further it would be a good idea to give a brief explanation of what Oracle RAC is. Separately, and more importantly, RAC is nothing more than a single database that is accessed and shared by many Oracle instances running on separate systems. These separate but linked systems in a RAC environment are wedged nodes in the cluster. Each cluster node accepts requests from applications or users to query or update the single shared database. The shared data model employed by Oracle RAC requires that each instance on the nodes maintain individual components, but also communicate through a sophisticated interprocess communication channel that synchronizes access to shared components, such as cache or memory. disk arrays.

Vigilant Technologies is proficient in the design, architecture, installation, and testing of all Oracle environments, including RAC systems.

Why RAC?

It’s amazing how RAC solves all the problems surrounding small discrete and large dedicated systems. RAC enables scalability, high availability, and failover, each of which is critical in today’s demanding database environments.

Scalability

While nothing is free, Oracle RAC allows you to scale up or down the number of nodes in your RAC environment to sufficiently meet your immediate, near-term, or future computing requirements. You choose. Buy what you need from time to time, using modular components, upgrade the system as your business grows.

While Oracle touts that it can build its system with low-cost building blocks, I’m not sure how many would want their mission-critical applications to run on low-cost hardware. But what Oracle RAC really offers is that you buy hardware that fits your budget, business needs, and processing requirements. You only need to buy today what you really need today, and then plug in or remove hardware when needed. Increasing or decreasing computing power can be done “on the fly” without disturbing current requests to the database.

This is especially important when thinking about database consolidation. Many times we don’t really know how much processing power will be required. All we really know is that when we look at our sparse systems, we are wasting resources in the form of CPU, memory, and disk space. RAC allows you to consolidate databases with the flexibility to add additional nodes if you don’t get it right.

High availability

High availability can be summed up in two words, “always on”. In a RAC environment, since multiple nodes share the service of requests to a single database. By having additional nodes, you get a higher chance that access to a database will always be available should a node failure occur. In a RAC configuration, if a node were to fail, the surviving nodes would perform recovery on behalf of the failed node and then begin servicing requests on behalf of that failed node.

Conmutation for mistake

Closely related to high availability is failover. While high availability ensures that access to a database is never impeded across multiple nodes, failover is the power of an application to continue running even when the node that was servicing its request might have failed. Oracle RAC provides complete and transparent failover for an application. Oracle RAC maintains and hides all system-side failures from users and provides full recoverability for an application.

Move to RAC

Now you may be saying to yourself, “Yes, I know about RAC and we’re dedicated to building our Oracle RAC environment.” Well, this is all very well, but do you really understand what you’re getting yourself into? Make no mess, RAC is a complex and unwieldy beast and should only be designed by experienced professionals. Someone who has done it, is not just trying to figure out how it works, and has the experience to pick up the pieces when something goes wrong is invaluable. Do you really want to trust your production data to someone who is just messing with the system?

Moving to Oracle RAC is not an overnight task. It is necessary to involve the entire IT structure of the company and each one has specific tasks. From the administration that sets budget constraints, to the database, system, and network administrators who set up these systems, to the developers, testers, and users who must test, validate, and use the system.

CRS, OCFS, ASM, TAF, FaN, FCF, NIC, and RAID are just a few of the acronyms and technologies that must be learned and understood before attempting a RAC installation. More importantly, there are literally dozens of decisions to be made or flooded when setting up a RAC environment. Again, this is not something you just want to ink with. Performance issues will arise.

Oracle RAC is a special case and Vigilant will guide you through the maze, assisting you in the hardware and software selection process. Vigilant will install and configure a RAC solution that will work with the reliability and high availability you need.

From sizing full hardware to server consolidation, upgrading to Oracle 10g, or installing and upgrading eCommerce suites, Vigilant has it done and can quote you a fixed cost up front.

Survive in RAC

Getting a RAC system up and running is only half the equation. Oracle RAC is a completely different beast that cannot be maintained like the typical single-instance Oracle Database most DBAs are familiar with.

Vigilant understands that there is a difference between single database instances and multi-node RAC configurations. The RAC performance issue should not be approached in the same way as a single instance database. Understanding is critical to tuning applications, meeting performance goals, and ultimately keeping your RAC installation up and running.

There are unique and different considerations. The network protocols, but please understand, the hardware specifications and configurations are more critical, also the monitoring of the different instances in each RAC node is different. A complete understanding of how all the pieces fit together is essential to troubleshooting performance and reliability issues.

If you don’t have a qualified staff or are in the process of gaining certification or experience, there is no substitute for having someone around who has “been there and done that.” When it comes to RAC, experience counts.

Vigilant Technologies has been helping customers by remotely managing their Oracle databases. Clients do not need to pay for a full-time DBA and Vigilant Technologies provides all DBA services for a fraction of the cost of a full-time DBA.