news Oracle 12c A Multitude of new Features for an Optimised Database Platform ... the smarter way of information

Transcription

1 12c A Multitude of new Features for an Optimised Database Platform... the smarter way of information

2 page 2/6 Larry Ellison announced the 2013 release of version 12c at this year s Open World. As Ellison explained, the new database will for the first time offer multi-tenancy on database level. According to this announcement, has realigned its focus with this new version of their flagship database. The version has been named 12c, with the c suggesting that the new version has been developed to target cloud computing. This new alignment becomes quickly apparent when examining the host of new features added. Companies using multiple databases and high data volumes and those with high availability requirements should benefit most from the new version. HSM (Hierarchical Storage Management) now offers the opportunity to create time-controlled compressions of tables and/or individual blocks of data, and/or their relocation into other tablespaces. Another aspect has additionally come into focus, which in many companies has increasingly taken centre stage in terms of data management: The consolidation of databases on optimised database platforms. This entails 4 important objectives: Cost reduction for administration and operation Reduction in data centre and storage costs Cost reduction for high availability Improved performance based on improved resource management and better resource utilisation promises to reach all objectives with version 12 without having to implement significant changes to existing applications. Let us introduce three of these new features in more detail with this aspect in mind: Pluggable Database, HSM and Application Continuity. Pluggable Database The concept of PDB is not new, as it has already been used in other environments. A pluggable database is a database instance containing multiple independent databases. The implementation in version 12c differentiates between a Container Database (CDB) and Pluggable Databases (PDB). Root PDB 1 PDB 2 PDB n Intra-CDB db link Basic structure of the Pluggable Databases. A database Container (root) including many Pluggable Databases.

3 page 3/6 CDB is - as the name suggests - a container for holding the Pluggable Databases. The CDB contains the data dictionary, global users, roles and global objects. The individual PDBs - of which version 12.1 can hold max. 254 per CDB - are the actual databases. They are identical to the pre-12c databases, and behave just like independent databases, i.e. there is no common namespace and access from one PDB to another is not available, unless database links are used. The connection between the individual PDBs is implemented by way of services. Each PDB registers with the listener using the name of the PDB. Once a connection to this service is established, then the user is connected directly with the relevant PDB and it will appear to the user just like any normal database. Root PDB 1 PDB 2 PDB n DBLinks Each PDB is encapsulated and appears to the user and applications as a separate, independent database and is registered to the listener with the same service name. Additional services can be created as usual. dflt service other services Listener Listener App. Server, SQLplus, Tools App. Server, SQLplus, Tools Resource management occurs via the popular Resource Manager on CDB level, and now also allows assignment to PDB-based resources. A distribution of resources among individual PDBs can, for example, be achieved by ensuring that PDB A will be guaranteed to receive 50% of all resources, while PDB B and PDB C will receive 25% each. In addition to the distribution on PDB level, resources can also be further distributed within the PDB based on user or schema names. In continuation of the example above, the allocated 50% for PDB A can be once again distributed in equal parts to the various schemas.

4 page 4/6 control files redo log files flashback log files Root Suppied Common User/Schemas/Objects SYS Public CDBA Customer Common User/Schemas/Objects SYSTEM SYSAUX UNDO (global) TEMP (global) PDB ERP PDB DW PDB CRM SYSTEM Public SYSTEM Public SYSTEM Public SYSAUX CDBA SYSAUX CDBA SYSAUX CDBA ERP SYS TEMP SYS TEMP SYS ERP DW DW CRM CRM Schematic description of the physical layout of a Container Database (CDB) with three Pluggable Databases (e.g. ERP, CRM and DW). Contol files, redo logs, flashback logs, UNDO tablespace and - optionally - the TEMP only exists once per CDB. The CDB itself, like all other databases, uses a SYSTEM and SYSAUX tablespace containing the data dictionary The PDB itself also contains a SYSAUX and SYSTEM tablespace in which local information (such as the names of the tables created by users) are stored. The TEMP tablespace can be created separately for each PDB or it can be used the global TEMP. In the above figure the PDB ERP is using global TEMP while the other two PDBs have their own TEMP. Furthermore, global users and roles are defined in the CDB which are passed on to the PDBs. Thus, the users SYS, Public and CDBA are so-called global user who can login into all databases. Additional rights can be added to these global users in each PDB. Local users can be created in addition for each PDB. In the above example the users ERP, DW and CRM are created. These local users can only be granted permissions and rights to objects within the PDB its-self. No global permissions or permissions to other PDBs are possible. The pluggable database concept offers many advantages. Database consolidation suddenly becomes very easy, as an existing database can simply be linked with a CDB to become instantly usable. A consolidation of various applications by separating them into individual schemas is no longer necessary. The process furthermore saves time during database upgrades, as a database upgrade between different database versions is carried out in the background starting with version 12c - and the database is ready to use immediately. Fast provisioning allows the cloning of an existing PDB into a new PDB. RMAN was extended in such a way that a recovery can now be carried out on PDB level. PDBs can also be unplugged for easy transport. That means that the data files in the PDB can then simply

5 page 5/6 be copied and pasted into a new CDB ( calls this a plug-in ). Starting with version 12c, this process will also work between different database versions, and is set to become the new standard procedure for database upgrades. A segregation of duty is now also possible on PDB level. It entails global users and roles that are created in the CDB and are inherited by all PDBs, and also local users and roles that only exist in a PDB. Version 12c will furthermore allow assigning global users without privileges higher rights in a specific PDB. These rights will then - of course - only be valid for that specific PDB. In other words: a global user could be assigned DBA rights in one PDB, without giving him the same rights for any other database. This will simplify consolidation enormously, as only some tasks actually require DBA rights. Pluggable databases are also supported by RAC and Data Guard. HSM Storage has traditionally been one of the great cost drivers in data management. The idea to move less frequently used data to slower and cheaper storage is far from new. The only problem to date: implementation within the database. In its latest version, integrates HSM into the database. This new feature provides an automated option to compress data on record, data block, partition, or table level, and/ or to move that compressed data to another tablespace (which was created at a slower storage location). Possible criteria for automated migration could be most recent read/write activities. Even multi-level processes can be implemented. That would allow the compression of historical data automatically after 30 days, and a migration to another tablespace on slower storage with a higher compression after 90 days without read access.

6 page 6/6 Application Continuity AC has been the magic formula for database high availability for some time now, even if experts have been arguing about whether RAC is primarily a high availability solution or only a performance solution for the same length of time. Everyone, however agrees: Not every application is able to fully utilise all RAC features. For applications to be able to use the benefits of an RAC in terms of high availability, some adjustments have been and still are needed, e.g. the processing of messages sent via Notification Service, or an automatic reconnect in case a connection is dropped. Also, the use of transparent application failover (TAF) made it possible for SELECT statements to restart on a new node transparently without the user knowing, when one instance failed. A similar solution for INSERT, UPDATE, or DELETE statements was not provided. Version 12c now expands this concept to such an extent as to maintain the status of transactions when a node or instance fails. calls this feature Application Continuity. Best case scenario here would be that an application no longer notices a node failure, and will be able to continue at exactly the same spot where it was interr Bottom line The new features in version 12c - specifically the pluggable database - help in the consolidation of applications to reduce costs. That manifests itself specifically in day-to-day operations in terms of increased hardware utilisation and less administration - on the basis of less databases. Information Lifecycle Management will help reduce costs for storage by compressing and/or migrating tables unused for long periods of time to slower and therefore cheaper storage solutions. Imprint Date: June 2013 Author: Ronny Egner Contact: marketing@avato-consulting.com avato consulting