Anil nair rac_internals_sangam_2016

Editor's Notes

1. Reminder for
2. [title, bullets under coming soon]
3. Let’s review the history and evolution of RAC. When dealing with customers, it’s important to stress that RAC is a tested, proven and mature technology. Oracle announced Oracle RAC in 2001, so the product is now 13 years old, and quite mature. But the evolution of RAC started long before 2001. It started as far back as Oracle 6, with a product called Oracle Parallel Server, or OPS. OPS was Oracle’s first parallel database. But, with OPS, only certain types of workload would scale across multiple servers. In June 2001, Oracle introduced Oracle RAC as a priced database option to Oracle9i. Oracle RAC introduced an improved method of sharing data across the database instances in the cluster. Oracle RAC is able to pass the block across the network to the requesting instance. Since the network is orders of magnitude faster than flushing the block to disk and reading into memory the way OPS handled it, Oracle RAC is able to scale without rewriting the applications. This was a breakthrough. However, Oracle RAC was a challenge to install and support. It relied on various 3rd-party components such as a clusterware component, and a shared storage manager. Integrating Oracle RAC with these 3rd-party components was a pain point for customers in the early years of RAC adoption. Oracle10g was introduced in January 2004. Oracle made some great enhancements to Oracle RAC. To address the complexity, Oracle began providing it’s own clusterware, Oracle Clusterware, and storage manager, Oracle Automatic Storage Management or ASM. Now, Oracle provided the entire stack for the RAC deployment, putting an end to the complexity of integrating and supporting 3rd-party components into the cluster. With ASM, storage became an elastic pool, making it simple to share disk IO and storage capacity across databases, and to add or remove storage while the database was online. Oracle10g also improved upon the flexibility of the database, introducing database services as a way to manage multiple workloads running in a shared cluster. Now, resources could be aligned with workload requirements, giving customers greater control over resources to simplify meeting their quality of service objectives—even as demand changed over time. With Oracle Database 11g, Oracle made RAC even easier to deploy and manage. This was done in two ways. Perhaps most importantly, Oracle introduced Oracle Engineered Systems as a deployment platform for Oracle RAC. Oracle Exadata, first introduced on Oracle Database 11g, is fundamentally a pre-packaged Oracle RAC cluster. Now, customers could order a single product, and get a fully functional highly available and scalable RAC cluster deployed within days of receiving their hardware. Later, we introduced the Oracle Database Appliance, which introduced Engineered Systems to a new class of smaller customers, letting them too deploy highly available RAC databases without the deep knowledge previously required. In Oracle Database 11g Release 2, we introduced many manageability features, including a streamlined deployment using the Oracle Universal Installer, and improved patching. All this flexibility made RAC an ideal platform for database consolidation. Customers began consolidating multiple databases within a RAC cluster, to enable pooling and sharing of resources across all their databases. Also, in contrast to VM style consolidation, cluster consolidation reduced the number of operating system instances requiring management. This reduced the workload of systems, network, and storage administrators Our newest release, Oracle Database 12c, establishes Oracle RAC as the premier infrastructure for building private database cloud. We’ll be covering more of the details of what’s in the 12c release for RAC in another Guided Learning Path module. But, as you’ve already heard, headlining the 12c release is the new Oracle multitenant architecture, an architecture that allows customers to consolidate databases without changes or namespace collisions. Customers can now benefit from managing many databases as one, yet still get the isolation they require between databases. And…, the release provides breakthroughs in high availability with Application Continuity. Application Continuity masks database failures from the applications themselves, eliminating the disruption caused by failures at the database tier, and ensuring end-users can continue to work uninterrupted. So over its 13 year history, RAC has shown considerable evolution, and maturation and the development teams are not sitting still –a lot of great enhancements and improvements are already planned and being incorporated into upcoming Oracle Database releases
4. With respect to storage management, ASM has until now been Diskgroup-centric. You create a Diskgroup and store all your database files there. In Oracle 12.2 ASM introduces a new style of management called Database Oriented Storage Management. Database Oriented Storage Management is made available with a new type of Diskgroup called the Flex Diskgroup. As before, we have External, Normal, and High Redundancy Diskgroups, and now we have a new type of Diskgroup called the Flex Diskgroup. Flex Diskgroups enable a new concept of a File Group which is a logical container of files in a Diskgroup that belong to an individual database or PDB. The File Group’s name is usually the database or PDB name. File Groups allow operations to be targeted against all the files belonging to a database collectively. File Groups do not change the way ASM stripes files across the ASM Disks as before. The provide new management efficiency and a set of new capabilities.
5. A key feature Flex Diskgroups and File Groups is quota management. Quota management is provided with Quota Groups. Quota Groups are a way of specifying the amount of storage that a databases in a File Group can consume. You can have one File Group in a Quota Group or some number of File Groups in a single Quota Group. No longer will you need to put databases in their own Diskgroup to constrain the amount of storage space they consume. Flex Diskgroups changes the way redundancy is handled. Rather than have a Diskgroup-wide redundancy setting that is fixed when the Diskgroup is created, redundancy for Flex Diskgroups is specified at the File Group level and is modifiable. Furthermore, for write once files such as archive logs and backups, parity protection similar to RAID 5 and 6 is available. And lastly, with Flex Diskgroups, the redundancy of a File Group can be used to split off a copy of the File Group as a Shadow Copy of the File Group. When the Shadow Copy is split off, a new full instantiated File Group representing a copy of the database or PDB is created. This is perhaps one of the most requested capabilities for ASM and is available in Oracle 12c Release 2.
6. Domain id is a seriamechanism