Showing posts with label Oracle Database. Show all posts
Showing posts with label Oracle Database. Show all posts

Tuesday, June 19, 2018

Multitenant Architecture and Pluggable Database

       Conceptual View of Multitenant Architecture and Pluggable Database 


Challenges with Database Consolidation till 11g 
Till 11g we have to create the multiple data base in the one environment than we have to define the schema and individual memory structure (SGA- System Global Area, it is a group of memory areas that is dedicated to oracle), if we can manage to this things then we can achieve the great consolidation density of hosting multiple data base in one system or server. 
And it gives availability to manage many-as-one, but this one the big drawback of the system, because all the system patched in the single database. 
But the problem arises with that is we have to move and do some changes with the core system then it will affect the entire database, because here we are following “Many-to-One” functionality of the data base. 
When we have to create a Database, we have s database file with background Process that manage the functionality with Memory (SGA). And whenever we have to create database we have to replicate the same database architecture. 
The resources are easily consumed. 
  • For consolidate hundreds of database in one machine we need PDB. 
Multitenant Architectures 
  • So for Overcoming to this database Oracle introduce Pluggable database which  follow Multitenant architecture. 
  • We can create number of database on the same sort of the memory and Background process. Pluggable database fully Self Contained Functional Database. 
  • Oracle Introduce one more new feature that is call root where we plug the Pluggable database and this root define upon the Container Database. 
  • So this Architectural interdependence y CDB+ROOT+PDB are called Multitenant database. 
  • Here we can move PDB from one CDB to another CDB this movement is calling Metadata Movement. 
  • We can also unplug a PDB from on premises and plug it into Cloud (or vice versa). 
  • Query for Unplugalter pluggable database HCM unplug into ‘HCM.xml location URL’. 
  • Query for Plug: create pluggable database MY_pdb using ‘Hcm.xml URL where we unplug the database’. 
What are Goal that achieved by Pluggable Database 
  • Earlier before 12c an empty database contains oracle meta dictionaries that stored the information of the row and column mapping by oracle database and relational database concepts 
  • Above the meta data , we create user data and it mingled with oracle metadata row, this make plug ability difficult, if we want to separate then we have to deal with row by row. 
  • Now with 12c Plugability feature we have Multitenant Architecture that defines Oracle metadata and user metadata separately. 
  • But it not totally separate, there is some pointer in the database that link with oracle metadata dictionaries, this concept is call Horizontal Metadata Partition through this definition oracle achieve In-Data Virtualization.    
  • Multitenant Scalability : We have to increase only small amount of memory with increasing the Pluggable Database. 
  • Multitenant Dynamics: Oracle design the Database like that Pluggable database only look at the SGA that associates to it and process took care of only that pluggable database that plug into it. 
  • Capabilities Enable: Manage by many to one, Backup database as one, recovery at pluggable database level. We have to Configure Data Guard we can configure databases for production and standby database, when a new database introduce in it then it will take benefits of it. 
  • Multitenant Upgrades: when we have to upgrade the when we set new set of binaries then we just have to upgrade the Container Database , all the Pluggable Database plug to it upgrade in one suites. 
  • Multitenant Patching: Multitenant Patching is the functionality where we can do partition between PDB for up-gradations. 
  • Multitenant Cluster: When can Specify the specific node open for specific services of the specific PDB. This allow partition of SGA virtually according to cluster.
  • Multitenant Cluster: When can Specify the specific node open for specific services of the specific PDB. This allow partition of SGA virtually according to cluster.
  • Multitenant Snapshot Cloning :  The coping or making clone of the database from one tenant to another this is call cloning, Same Concepts used by Snapshot cloning but the functionality are little different. 
      • It works on the concepts of data Block and Header. 
      • In cloning we make clone of the file of the database, file is the collection of the data blocks and headers. 
      • In snapshot cloning, it makes clone of header instead of making clone of whole blocks,  
      • If we have to make chancing in some file then we have to only copy that file. 
      • This one is known as copy on right. 
Multitenant Architecture Advantages 

      • Single self-contained PDB for each application. 
        • Applications run unchanged. 
        • Rapid provisioning (via clones). 
        • Portability (via pluggability). 
      • Shared memory and background processes. 
        • More application per Server. (Scalability) 
      • Common Operation Performed at CDS level. 
        • Manage many as one (upgrades, backup) 
        • Controlling also when required. 


      Managing Shared Resources between PDBs 


        • Using resources Manager we can control 
          • CPU 
          • Exadata I/O 
          • Sessions 
          • Parallel executive servers. 
        • Configure a policy that control how resources are utilized. 
        • The model is “industry standard” based on two notions; 
          • A number of shares is allocated to each PDB. 
          • A ‘cap’ (maximum utilization limits) may be applied to each PDB. 
        • A CDB resources plan uses ‘shares’ to specify how CPU is distributed between PDBs. 

      Thanks
      Welcome For Feedback, Suggestion and Comments.
      Next Blog About Creation Of Pluggable Database Through SQL Server