Oracle Database Server 12c Pros and Cons - PEOUG | · PDF fileOracle Database Server 12c Pros...

Oracle Database Server 12c

Pros and Cons

Hans Forbrich

Forbrich Consulting Ltd

Oracle DB 12c MultiTenant


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 re-

train 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


http://docs.oracle.com/database/121/index.htm

http://docs.oracle.com/database/121/index.htm

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


$ORACLE_HOME

• SLA

• 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


Enterprise Manager

• EM Express

• 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:[email protected]

http://www.forbrichcomputing.com

Oracle Database Server 12c Pros and Cons - PEOUG | · PDF fileOracle Database Server 12c Pros...

Documents

Transcript of Oracle Database Server 12c Pros and Cons - PEOUG | · PDF fileOracle Database Server 12c Pros...