< Day Day Up > |
Chapter 7: Designing Databases for RAC
7.1 Introduction
In the previous chapter we looked into the concepts of parallel processing, what its benefits are, how this is implemented, and how it is tuned. Parallel processing is not a feature of RAC but a feature that is also available in a single stand-alone configuration of Oracle. However, when used in a RAC environment an additional level of parallelism is obtained when multiple instances are used to process the requests. This helps in the utilization of unused resources because RAC only does parallel processing on single or multiple instances based on the available idle resources.
In Chapter 1 we discussed some of the modern business requirements. Business requirements like availability and scalability are some of the main features that are most often provided by the database vendor through some of their database products. For example, RAC is a feature that is available from Oracle Corporation that provides scalability. With RAC, multiple instances could access a common shared database and as the user base increases additional instances could be added. Similarly, the requirement to provide availability could be implemented using OAR, Oracle Data Guard (ODG), or RAC. Certain business requirements could be implemented directly using certain features of the database technology. Other requirements such as throughput, recoverability, maintainability, manageability, securability, and internationalization also come from a good database design. Database design using a set of features will help obtain these requirements.
Designing a good system is essential, regardless of the software chosen for the layered products including data and application management.
Like in the foundations of a building, if they are not laid out carefully, then there is a potential that the entire building could have a very short life, with potential risk of the building to collapse. So it is of utmost importance that the software foundations follow a good software architecture that is easy to maintain, perform, and scale, and meets the business requirements of the enterprise for the short-term and long-term strategies.
A major step in the software development life cycle is to analyze the requirements, the various functions of the system, and also the system in its entirety. Both the database and application designers approach their common goal from different perspectives. A good analogy is to imagine the application system as a house. The database design is the architectural plan that describes the house; it describes where different rooms are and how many doors or windows each room has. The application design, on the other hand, describes how the house will be used.
From the above analogy of building a house, the database designer must know what rooms the occupants will need and the application designer must make sure that the occupants can get from one room to the next in the manner that they expect.
So careful consideration should be given in designing the house to making it very efficient and this is possible by analyzing all the requirements carefully. Before laying the foundations and designing the house, it is important to start with a clear analysis of the requirements to build a house that is useful and long lasting.
The requirements captured during the analysis phase have to be stored in some form for future use. In earlier days this was done using plane flowcharts and even on paper. Today there are many varieties of tools available to help expedite this in a more concise and precise manner. A few examples are Oracle Designer, ERwin and Systems Architect. Of the modeling tools available, Oracle Designer is a very advanced and robust product. Like most of the Oracle development tools available today, Designer has been kept up-to-date with the enhancements in the Oracle RDBMS arena. All features added to Oracle have found a place in subsequent releases of Oracle Designer.
Figure 7.1 is an introductory screen of Oracle Designer. This snapshot shows all the features available in this product. Entity Relationship Diagrammer, Database Design Transformer, Repository Reports, etc., provide a complete set of features covering the entire design life cycle.
Figure 7.1: Oracle Designer Version 6i.
This chapter will focus on designing databases for a RAC environment and as part of these discussions we will look into some of the key features of Oracle RDBMS and their effect in a RAC environment. This includes discussions on partitioning (e.g., application and database partitioning) and its benefits and drawbacks, looking at the various data partitioning options available, types of indexes, and the pros and cons of using one type over the other in a RAC environment. These discussions will focus on how designing databases using some of these features will help get a better solution.
No comments:
Post a Comment