Oracle 12c Database New Features

Geert De Paep
Join the buzz:

•  Wifi available
•  Twitter
–  #oracleopenxperience
–  @oopenxperience

2
Disclaimer

•  Oracle 12c is planned for 2013

–  No documentation / presentations available yet
•  Based on OOW sessions
•  Based on OOW demogrounds
•  Based on MLC (My Little Camera)
•  Nothing is guaranteed to be included in
Oracle 12c production
•  Nothing is guaranteed to be implemented as
explained here
3
 ASM ASM Resync ASM
Data Guard
standby
Db Db Db Db Db Db

RAC Failover
transparancy DataGuard
Datafiles Failover
Db restore
Performance RMAN Monitoring and
Backup management

Large data
Volumes

4
 RMAN - Recovery manager

•  Restoring a datafile
–  May require tapes+heads to be available
RMAN
–  May be slow
Backup

•  12c
–  Recover from physical standby database
•  Transfer files from physical sby to primary
•  Advantages:
–  Easier and faster restore
–  Less dependent from backup infrastructure
5
 Recovery manager

•  Accidental ‘drop table’, ‘truncate table’, wrong

script, human error, ...
•  Pre 12c
RMAN
Backup –  Import from older export file (if available)
–  Restore older backup to extract table (+++work)
–  Flashback physical standby (+work)
–  ...
•  12c: Table recovery
–  Restore + recover individual tables from rman
backup
–  To any point in time
–  Fast and easy
6
 Recovery manager

•  Further RMAN improvements

–  Automate the use of incremental backup to bring
RMAN a standby back in sync
Backup
•  Now a complex and manual procedure
–  Auto conversion for cross-platform backup/restore
•  Cfr “convert database” statement

•  Rman 12c
–  Makes a lot of tasks easier

7
 Application continuity

•  Traditional RAC failover

–  TAF: queries are transparant, ins/upd/del not
–  FCF: no tcpip timeouts
Inst1 Inst2
•  Any sql gets “connection closed” and needs to
handle this (incl. select)
•  12c: “Real Transparant Failover Mechanism”
–  For queries and transactions
–  Currently only for java connection pool or plain jdbc
–  100% transparant failover

8
 Data Guard - Global data services

Stby •  Failover: standby db becomes primary

–  Clients have to be redirected
–  No ‘out of the box’ solution until now
•  Dns change, on role-change trigger, ldap,
tnsnames.ora, ...
Prim
•  12c: global data services
–  Purpose: no client reconfiguration in case of
failover or switchover
–  + other advantages

9
 Global data services Primary
Physical standby
open read only

Stby
•  Features LSNR
–  Awareness which site is primary
•  Can connect clients always Golden Gate
to primary site
–  Rule based
•  Can direct applications to active data guard
•  If active DG 1 not available go to other active DG or
Prim
primary
–  Affinity
•  Prefer local databases
•  Any replication technology
–  “Global load balancing and failover for replicated
databases”

10
 Data Guard – Far sync standby

Stby •  Far sync standby

–  Instance with only standby and archive logs
–  Acts as a ‘dispatcher’ for multiple standby’s
•  Reduced WAN traffic
•  Easier failover
Prim
–  “validate database” before switchover
WAN Far sync
WAN standby
Primary Network
Primary Network Physical Standby’s

11
 ASM ASM
Mem + proc Mem + proc

Grid Infrastructure

Big stack
DB DB
Mem + proc Mem + proc
DB DB
Mem + proc Mem + proc
•  Pre 12c, every node has /acfs /acfs
–  Cluster software
–  ASM software
ASM
–  One or more database instances
Inst1 Inst2
–  Optionally ACFS (ASM cluster file system)
–  Optionally applications running
•  New concepts
–  Flex Cluster
–  Flex ASM
12
 Appl. server ASM
Mem + proc Mem + proc

Grid Infrastructure

Light-weight

Cluster
DB
Mem + proc
DB
Mem + proc
•  Flex cluster
/acfs
–  Group database + application
servers in one cluster
ASM
–  However, application servers
Inst1 Inst2
•  Do not need ASM instance
•  Longer timeoutsSolution
•  Light-weight stack
–  No inter-node traffic
–  Local storage or NFS
–  Cloud!
•  Integrated cluster solution
13
 Grid Infrastructure

•  Flex ASM
–  5 node-cluster
–  Less than 5 nodes run ASM instance
ASM
•  Database requests file mapping from remote
Inst1 Inst2
ASM
ASM ASM ASM ASM ASM
Mem + proc Mem + proc Mem + proc Mem + proc Mem + proc

DB DB DB DB DB
Mem + proc Mem + proc Mem + proc Mem + proc Mem + proc

14
ILM

•  Scope
–  Historical data – archiving - compression
–  Applications usually work on recent data
–  Older data may take a lot of place
•  Solution pre 12c
–  Move data to other tablespaces on other disks
–  Change compression level
–  Set tablespaces read only
–  à Manually, scripts, 3rd party tools, ...
15
 ILM – Oracle 12c

•  “In-database archive”
–  Archive infrequently used data within the database
•  By marking data as archived
•  Making rows ‘invisible’
–  Query can choose to (not) see archived data
•  Advanced data optimization
–  Automatically move data based on policies
•  Other tablespace, read only, compression level
–  Online
– 
alter table ... compress for query after 3 months of no modification
16
ILM

•  Advanced compression
–  Faster and smaller 100%
transparant
–  In-memory scan
•  Data not expanded in memory during scan
•  Up to 3x faster for low cardinality data
•  Heat maps
–  Track access (read and write) to tables/partitions/
rows
–  Information used for ILM

17
 SQL Enhancements

•  Duplicate indexes
–  “ORA-01408: such column list already indexed”
–  Can have both B-tree and bitmap index on same
SQL column(s)
WITH
function is_number(n varchar2)
return char is
•  WITH-plsql function begin
–  4-8x faster execution <check if n is a number>
end
select * from <table>
where is_number(sal) = ‘NO’;

18
 SQL Enhancements

•  Varchar2(32K)
–  Currently max is 4000 bytes

SQL
•  Auto-populate column from a sequence
–  Using the DEFAULT clause for a column

19
 SQL Enhancements
100%
transparant

•  In-memory global temporary tables

–  Useful during reports
–  12c: purely in memory
SQL
•  No IO for redo and undo
•  Can be used on Active Data Guard db
•  In-memory LOB queries and updates
–  Speed up LOB operations
•  Concatenate, substring, length ,instr, ...

20
 Other useful enhancements

•  Data pump
–  Impdp can be done in NOLOGGING
•  Must faster imports
SQL
•  Move datafiles online
–  While read and write activity are going on
–  Allows easy migration to other storage
•  SQL*Net
–  Larger buffers, data compression

21
 The database

Performance is slow !!

•  Very often caused by bad execution plans

–  Usually due to bad statistics
•  Old or missing statistics
•  Hard to predict number of returned rows
–  Complex predicates
•  where substr(to_char(edate,’YYMMDD’),2,2) > 8
–  Join cardinalities
–  Data skew, correlation
•  Solutions
–  Adaptive cursor sharing (11g)
–  Adaptive statistics (12c)
–  Adaptive execution plans (12c)
22
 100%
Performance transparant

•  12c: Adaptive statistics

–  Actual number of rows <> estimates
–  Statistics marked as ‘incorrect’ / ‘unreliable’
–  Next query will do ‘dynamic sampling’
•  Results in much better estimates
•  Better execution plans

23
 100%
Performance transparant

•  Adaptive execution plans

–  E.g. 2 options in execution plan
•  Join using nested loops
–  Best when few rows need to be joined
•  Join using hash join
–  Best when a lot of rows need to be joined
–  “Inflection point”
•  Rows are buffered during execution of query
•  Inflection point reached or not?: take plan 1 or 2
–  Result: “deferred execution plan”
24
EM Express

•  Replaces Oracle 11g DbConsole

•  Embedded in 12c database
•  Preconfigured & installed with the database
•  Uses less disk space and memory
–  +/- 20Mb footprint
•  Subset of OEM12c features
–  Similar interface

25
EM Express

•  Enhanced Real Time ADDM

–  Proactive problem detection and analysis
•  Lightweight check runs every 3 sec
•  On detection of bad performance, analysis is
triggered
–  High cpu, io spikes, memory, hangs, ...
•  Collects rich set of data for analysis
•  Stores reports in AWR (persistent - purged)
–  Can be triggered manually

26
EM Express

•  Monitor composite operations

–  ‘label’ a unit of work
•  E.g. SQL*Plus script, batch job, dpump job, ...
–  View top SQL and performance metrics
•  “Database Performance Hub”
–  Single view of all performance related info
•  ADDM, Top SQL, ASH analytics, ...
•  Switch easily between sql monitoring, ash,
addm, ... 27
OEM 12c

•  Database Instant Cloning

–  Using copy-on-write
•  Initial clone takes no space
•  Only modified blocks take space
–  Functional testing with minimal space
consumption
•  Integrated subsetting and masking
–  One-step masking + subsetting as data leaves the
source db

28
Oracle12c + OEM12c =
extreme database management

29
 Pluggable databases

•  Cloud -> shared infrastructure -> multi-tenancy

•  One application for multiple customers
•  Customers may not see each others data
PDB

–  Solution?
•  Add extra column + where condition (+++work)
•  Create multiple databases
–  High resource usage
•  Memory (1 SGA per database)
•  Processes (a lot per database)

30
 Pluggable db

•  Solution 12c
–  One ‘container database’
•  Background processes
PDB

•  Memory allocation
–  Multiple ‘pluggable databases’
•  The union of
–  Tables, views, procedures, ... all application objects
–  User definitions
–  Privileges
•  Can be plugged in a container database
•  Can easily be moved to another container database

31
 Pluggable databases

•  Resource usage
–  6x less H/W resource, 5x more scalable
PDB

32
 Pluggable databases

•  Use cases
–  Consolidation
•  Typical 11.2 database has +/- 30
PDB

background processes
•  x15 database = 450 processes
–  + user processes
–  “Application as a Service”
•  Multiple customers for same appl
•  Each a separate PDB

33
 Pluggable databases

•  Advantages
–  Less resources
–  Security
PDB

–  Role separation
•  Administrator of PDB can <> administrator of
CDB
–  Less applications in one database
–  Faster upgrades
•  Unplug from 12.1, plug into 12.2

34
Oracle 12c

Cloud

•  Use of shared infrastructure

•  OEM 12c for provisioning, management,
metering, ...
35
Conclusion

•  12c features
–  Data Guard
•  Get more from Active Data Guard
•  Making Data Guard easier and better
–  RMAN
•  Making backup and recovery easier and better
–  Table recovery, cross platform, incr bup for
standby, ...
–  Performance
•  Making the database faster
–  Optimizer, SQL, ...
–  ...
36
Conclusion

•  Awareness
–  Management of large volumes of data
•  Compression
•  ILM
•  Automation
–  Management of the environment
•  OEM 12c
–  Get more out of your Diagnostic and Tuning
Pack
•  More than just the database
•  Lifecycle management
37
Conclusion

•  Architecture
–  Grid infrastructure
•  Larger RAC clusters
–  Cloud infrastructure
•  Provisioning and management of database
resources
•  Private cloud
–  Pluggable databases
•  Change database management
•  Very likely to become a ‘natural thing’
38
 Want to know more?
Contact: [email protected]