1. Oracle 12c New Features
Real Application Cluster (RAC)
@saifulmuhajir
2. Why 12c?
Many Oracle customers have large numbers of “departmental” applications
built on Oracle RDBMS. They:
• Do NOT use a significant percentage of the hardware on which they are
deployed
• Have instance and storage overhead preventing large numbers of
“departmental” databases from being placed on the same physical and
storage server
• Are NOT sufficiently complex to require 100% of the attention of a full
time administrator
• Do require significant time to patch or upgrade all applications
3. Oracle 11g Characters
Multiple monolithic or non-CDBs share nothing:
- Too many background processes
- High shared/process memory
- Many copies of Oracle metadata
4. New Multitenant Architecture: Benefits
Operates multiple databases in a centrally managed platform to lower costs:
- Less instance overhead
- Less storage cost
Reduces DBA resources costs and maintains security
- No application changes
- Fast and easy provisioning
- Time saving for patching and upgrade
- Separation of duties between:
• Different application administrators
• Application administrators and DBA
• Users within application
5. Multitenant Container Database
Multitenant Container Database (CDB)
Datafiles Controlfiles Redo logs
ROOT
Datafiles
APPLICATION(1)
Datafiles
APPLICATION(2)
Datafiles
APPLICATION(3)
System Global Area
Instance
Process structures
Single Instance
Multitenant
Container Database
SERVER
Shares:
• Background processes
• Shared/process memory
• Oracle metadata
7. Cloning, Upgrade & Patching
• Cloning:
- Local CDB
- Remote CDB (same or different server)
- Remote clone for converting non-CDB
• Upgrade & Patching: not as simple and quick as Oracle said. Require both
pre-upgrade and post-upgrade steps
10. Flex ASM
• Avoid ASM instance single-point-failure
• Number of ASM instances running is called the ASM cardinality
11. Flex ASM: More
• Supports larger LUN sizes for Oracle Database 12c clients (20 PB -> 32 PB)
• Maximum number of Disk Groups supported is 511 (from 63)
• Flexibility to rename an ASM Disk in a Disk Group
• All the instances in an ASM cluster ensure they are running the same code
release by validating the patch level across the cluster.
12. ASM Disk Scrubbing
• Monitors all the disks in the ASM disk groups
• Verifies the logical data corruption on all ASM disks
• Auto-magic error correction using mirrored data
• ASM 12c scrubbing occurs in two ways:
- As part of rebalance operations
SQL> alter diskgroup DGDATA set attribute ‘content.check’ = ‘TRUE’
- On demand scrubbing: can be performed on a Disk Group, individual
files or individual disks
SQL> alter diskgroup DGDATA scrub repair;
SQL> alter diskgroup DGDATA scrub disk data_0004 repair power auto;
13. Rebalance Improvements
• Establish upfront estimates before actually doing a rebalance operation
SQL> EXPLAIN WORK SET STATEMENT_ID='ADD_DISK' FOR ALTER
DISKGROUP DG_DATA AD DISK data_005;
SQL> SELECT est_work FROM V$ASM_ESTIMATE
WHERE STATEMENT_ID = 'ADD_DISK’;
• Improved accuracy of rebalance estimates
14. RAC: More
• IPv6 support for client connectivity, helps the customers meet the PCI,
SOX and other Security Compliance standards
• Auto root.sh execution on all nodes
• Multiple SCAN per Subnet
• New GHCTL utility for patching improvements
• Shared password file in ASM: A single password file can now be stored
in the ASM diskgroup and can be shared by all nodes
• What-if Command: simulate the command without it actually being
executed or making any changes
$ ./srvctl stop database –d MYDB –eval
$ ./crsctl eval modify resource <resource_name> -attr “value”