Oracle Database Server 12c Pros and Cons Hans Forbrich Forbrich Consulting Ltd
Based in Alberta, Canada
Fact Oracle DB 12c is the largest architectural change since Oracle8i
Fact Oracle documentation refers to the non- Multi-Tenant architecture as Pre-12c
Fact Multi-Tenant is available in ALL Editions of Oracle Database 12c. Personal Enterprise Standard
Fact Multi-Tenant Option is required ONLY WHEN MULTIPLE PLUGS ARE USED
Fact The changes in commands due to the new Multi-Tenant architecture can take a long time to become comfortable If you have been using Oracle DB since Oracle9i or older, PLAN on 6 months to retrain your fingers
Fact Multi-Tenant Architecture Is the FUTURE Get Used to it NOW
SO What has changed? And Are there concerns and benefits?
The way we were Background processes for each instance http://docs.oracle.com/database/121/index.htm Reference Manual, Appendix F 99+ Background Processes *possible* For Each Instance
The way we were DBA access to the database:
The way we were And verify our database information
The way we were And create a new user
New Architecture Exactly the same but different
The way we need to be With the new architecture, access Service
Some of the Architecture changes to think about Single Instance or RAC Cluster Multiple, pluggable, databases One set of redo logs per instance One target standby One undo tablespace per instance One OR more temp tablespaces
Services Not necessarily in tnsnames.ora
Services But each PDB has it s own service
Reality We use SID everywhere Many of our methods/scripts will break Any applications need to be reviewed Watch for Java, JEE apps using SID Opportunity Convert to Service NOW Decide which to use EZ-Connect, which TNS
Admin Scripts Many use / as sysdba Use SERVICE to get to correct container Do not use OS Authentication Many new roles: OSBACKUP, OSKM, OSDG Now need to be aware of CON_ID Not all actions at all levels Some actions restricted to ROOT Some actions may be performed at PDB
One SID to Bind Them One per host? SLA Patching SGA PGA Huge Pages Backup Standby
One Instance per host We have long wanted ONE instance per host Properly use available resources Manage memory, CPU, I/O But have had to oversize hosts for peak load And then add more instances to use free space Now this is possible But is that a good thing?
Before: Instances Plural!! Many background processes duplicated DBA manually balances SGA, PGA, etc No ALTER TO MOUNT Shutdown entire instance
Now: Instances Likely one per host!! Background processes not duplicated But may have slave processes Or threads Resource manager balances Individual databases Individually started/stopped
SLA $ORACLE_HOME One HOME = one Service Level Agreement Patching Everything in one HOME patched together No proper resource management Intra-Instance ONLY
Service Level Agreement (SLA) The Service Level Agreement is a formal (documented) or informal (discussed) agreement related to Uptime Maintenance Down time Unscheduled Down time response Patch level, patch frequency
Before: SLA We basically used ORACLE_HOME to implement one SLA Multiple Instances in same HOME IF they can (must be) patched together Often one HOME = one Application Tricky to administer
Now: SLA We basically used Instance to implement one SLA Multiple Databases in same Instance - IF they can (must be) patched together One Database = one Application? But potentially costly to administer
Before: Patching Many patches required some down time Especially non-rac Stop instance Apply patch Test patch Make instance available again
Now: Patching It may be possible to *move* the Pluggable Database (PDB) to another instance during the patch process, and then restore it after patch Minimize down time
Shared Global Area (Memory) SGA Multi-tenant does not significantly save on SGA, as compared to multiple instances New SGA size = Σ Individual SGA Need to size Memory & Semaphores based on possible maximum utilization to avoid restart entire instance May impact kernel configuration Interaction with Sys Admins
Process Global Area (Memory) PGA Theoretically fewer processes Same number of user processes Duplicate background processes eliminated However, these are all in ONE instance Need to look at PGA_AGGREGATE_TARGET May need to manually manage more sessions
Huge Pages (Memory) The SGA is now potentially much bigger There is NO reason to avoid Huge Pages Except that Automatic Memory Management is not compatible with Huge Pages
Impact on Tuning Simple Tuning involves ONE SQL statement in isolation Advanced (and recommended) Tuning involves one or more SQL concurrent statements, and interactions
Impact on Tuning One huge tuning problem has been the impact of non-visible resources on instance resources Other instances Other applications Multi-tenant should reduce the instances and make advanced tuning potentially simpler.
Backup Why do we back up? Recovery Second copy Archive With pluggable databases, we may want to re-think the purpose of backups
Backup differences Multi-tenant allows backup of Entire Container Database (CDB) Root only RMAN: BACKUP DATABASE ROOT; One, or more, Pluggable Databases RMAN: BACKUP PLUGGABLE DATABASE HR, ; Many backup strategies will need to be rethought
Backup Differences The REDO Logs are common to all PDBs Need to think about ArchiveLog backup when backing up individual PDBs Use Backup Optimization to include only those ArchiveLogs that are needed Backup *all* ArchiveLogs as a completely separate job? Recovery Catalog HIGHLY recommended
StandBy and High Availability RAC is fully compatible with Multi-tenant Even better, as RAC already thinks services Data Guard is another matter One standby for Container As of 12.1.0.2 CREATE PLUGGABLE DATABASE includes a STANDBYS=ALL NONE
EM Express Enterprise Manager Too light? Suitable for quick DBA checks Cloud Control 12c Significant time investment to get started But worth it!
Enterprise Manager Cloud Control Cloud Control 12c (12.1.0.4) is aware of Multi-Tenant
OEM CC Monitor and manage Instance & Cluster Monitor and manage CDB$ROOT Monitor and manage PDBs Create, Move, Destroy PDBs Everything can be scripted
Cloud Control I would not want to run a multi-tenant environment without Oracle Enterprise Manager 12c Cloud Control 12.1.0.4 Core is included with DB license Good graphical overview EM CLI will become very important
Conclusion Multi-tenant is a significant architectural change It IS the future and NOW is the time to get started There are lots of things to look at, think about and worry about Reference the Concepts Manual, Chapters 17,18 and Administrator s Guide, Chapters 36-46 http://docs.oracle.com
Questions?
Thank You Hans Forbrich mailto:hans@forbrichcomputing.ca http://www.forbrichcomputing.com