Let's face it, today's IT environments are in constant flux. Acquisitions, mergers, global economies, and the general unrest in the marketplace continually put stress on IT infrastructures. It has become increasingly difficult for IT organizations to predict, plan, and deploy proper computing environments that will satisfy current and future requirements.
Corporations, when planning for database systems, seem to be a constant battle between purchasing systems that meet today's requirements against systems that might potentially satisfy future expectations. The unfortunate reality is that both of these approaches are inadequately suited when compared to the dynamic nature of the systems we must supply to the end user community.
When systems are built against today's requirements, without looking to the future, what's often left after requirements change, is a set of small discrete systems scattered around the organization each supporting one or two applications. These independent systems typically are improperly sized, too small or too big for the applications they support, and are likely to become islands of computing power that are spread thinly around a corporation. To make matters worse these discrete systems are often unable to facilitate communications across application layers or even simply share data between themselves. Look at any of these systems across an enterprise and you will also see wasted or unused CPU cycles, wasted disk storage subsystems, and over-worked DBAs and Administrators trying desperately to keep some for of control on these systems.
Purchasing large centralized servers or systems larger then what is currently required is no better. Companies going this route often put every application on one server or are purchasing more computing power then they currently need. Designing systems in this manner has proven to be very costly and wasteful of money and resources.
Downtime is always disastrous but having everything run on one system has the potential of bringing down every aspect of your business at the same time. This goes for unplanned downtime as well as planed downtime such as maintenance windows.
When systems are too large with unending processing power, these systems are often taken for granted and sloppy or ill-tested applications are deployed without ever going through some form of performance or scalability tests. Down the road when additional CPU, memory, or disk resources are needed, they are just not there.
Vigilant's prides itself in taking the time to consider your requirements, transforming them into viable solutions, and selecting the proper set of components for your computing environment.
Both small discreet and large dedicated systems do share one thing in common. They both often have multiple single points of failure that limit their ability to supply the high availability required in today's 24X7X365 environments. All it takes is one component to fail and then, regardless of how little or much money you have spent, your system has just become useless and potential revenue is lost because of the downed system.
Don't get me wrong. Small discrete and large dedicated systems have their place. They have served us well for many years. But these environments just do not supply the required infrastructure for scalability, performance, and availability. For those environments needing more, they are turning to Oracle's Real Application Clusters (RAC).
What is RAC
Before going much further it would be a good idea to give a brief explanation as to what Oracle RAC is. Singly, and most 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 coined nodes in the cluster. Each node in the cluster accepts requests from applications or users to query or update the single shared database. The shared data model employed by Oracle RAC requires each instance on the nodes to maintain individual components but also communicate through a sophisticated inter-process communication channel that synchronizes access to the shared components, such as memory cache or disk arrays.
Vigilant Technologies is proficient in designing, architecting, installing, and testing all Oracle environments including RAC systems.
It is amazing how RAC solves all the issues surrounding small discreet and large dedicated systems. RAC allows for scalability, high availability, and failover, each of which is critical in today's demanding database environments.
While it is true that nothing is free, Oracle RAC allows you to scale up or down the number of nodes in your RAC environment such that it sufficiently meets your immediate, short term, or future computing requirements. You choose. Purchase what you need now and then, through the use of modular components, upgrade the system as your business grows.
While Oracle touts that you can build your system with low-cost commodity parts, I am not too sure how many would want their mission critical applications running on low-cost hardware. But what Oracle RAC really provides is for you to purchase hardware that keeps in line with your budget, business needs, and processing requirements. You need only buy today what you really need today and then plug-in or remove hardware when needed. Increasing or decreasing your computing power can be done "on-the-fly" without disturbing current requests to the database.
This is especially important when thinking about database consolidation. Often times we don't really know how much processing power will be required. All we really know is that when we look at our dispersed systems we are wasting resources in the form of CPU, memory, and disk space. RAC allows consolidate databases with the flexibility to add additional nodes if we miss the mark.
High Availability can be summed up in two words, "Always On". In a RAC environment, since multiple nodes share the servicing of requests to a single database. By having additional nodes, you gain a higher probability that access to a database will always available if a node failure were to 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 to service requests on behalf of that failed node.
Closely related to high availability is failover. While high availability ensures that access to a database is never hindered through 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 seamlessly and transparently provides complete failover for an application. Oracle RAC maintains and hides all system-side failures from the users and provides complete recoverability for an application.
Moving to RAC
Now you may be saying to yourself, "Yes, I know about RAC and we are dedicated to building our Oracle RAC environment". Well this is all fine and good but do you really understand what you are getting yourself into? Do not foul yourself, RAC is a complex and difficult beast to handle and should only be architected 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 with someone who is just tinkering with the system?
Moving to Oracle RAC is not an overnight task. The full corporate IT structure needs to be involved and they each have specific tasks. From management setting the budget constraints, through database, system, and network administrators that configure these systems, and down to developers, testers, and users that must test, validate, and use the system.
CRS, OCFS, ASM, TAF, FaN, FCF, NIC, and RAID, these are but 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 floundered when configuring a RAC environment. Again, this is not something you want to just inker with. Performance issues will arise.
Oracle RAC is a special case and Vigilant will guide you through the maze, assisting in the selection process of hardware and software. Vigilant will install and configure a RAC solution that is going to perform with the reliability and high availability you require.
From sizing the complete hardware for Server Consolidation, Upgrading to Oracle 10g, or installing and upgrading E-business suites, Vigilant has done it and can quote you a fixed up-front cost.
Surviving on RAC
Putting a RAC system in place is only half of the equation. Oracle RAC is a completely different beast that can not be maintained like the typical single instance Oracle database that most DBAs are familiar with.
Vigilant understands that there is a difference between single database instances and multi-node RAC configurations. RAC performance issue should not be approached in the same manner 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. Networking protocols but be understood, hardware specifications and configurations are more critical, plus the monitoring of the different instances on each RAC node is different. A complete understanding of how all the pieces fit together is essential for troubleshooting performance and reliability issues.
Free Web Directory