Oracle 19c Bring it

on

Julian Dontcheff
Martin Bach
Julian Dontcheff

• More than 30 years of Database Experience

• Accenture Global Database Lead
• Accenture Global Oracle Technology Lead
• Accenture Enkitec Group ITL Lead
• Oracle Certified Professional 8i-12c
• First Oracle Certified Master in Europe: 2002
• Oracle ACE Director
• More than 10.000 hours of on-call DBA duty
• Blog at juliandontcheff.wordpress.com
Martin Bach

Principal Director at Accenture

17 years of experience working in IT
Full-stack approach
• Focus on cloud technology and Oracle Engineered Systems
• Highly-Available Solutions Open Source Software
• Open Source Software
Active member of the Oracle Community
• Helped write multiple books about Oracle technology
• Active blogger since 2004
• International speaker
Ace Director, Oak Table Member, Oracle Certified Master
https://martincarstenbach.wordpress.com @MartinDBA
Our Agenda
1. Discussing the update target release

2. Understanding changes with the new release

3. Embrace the Container Database Architecture

4. Considerations for the application tier

5. Don’t forget the monitoring layer

6. The Golden Opportunity for automation

7. Other technologies that might play a role

8. Upgrading to Oracle 20c

Upgrading the Oracle database to Release 19c

A view with a wider angle

There are lots of moving parts during an upgrade
• The database is the most important one, but there are many more components to
consider
• There should be little discussion about Oracle 19c as the target release
The application tier requires special attention

Monitoring solutions must be compatible with Oracle 19c

You should consider automation as much as possible

Thinking clearly
about the upgrade
With a nod to @CaryMillsap
You should aim for Oracle 19c

There are different types of Oracle

Database releases
Interim vs Terminal release

• Interim releases offer new functionality at a quicker

cycle than previously possible

• However they do not benefit from Extended Support,

and patching will end at some point

• Patching for 18c ends June 2021

• Patching for 12.2.0.1 ends March 2022 *

hp::h:::h:::h0::h:::h:::h:::h:::h:::h:::h:::h:::h:::hr::h:::h:::h:::h:::h:::h
The DBA should know about important changes

Every release adds (and sometimes removes) features

The relevant information can be found in the Upgrade Guide

• New features are ... new

• Deprecated features are going to disappear at some point

• De-supported features are not part of the release

• Some features even have a come-back

Please integrate the Upgrade Guide into your upgrade plan

Noteworthy changes for admins in 19c since 12c Release 1

Multi-Tenant is the strategic direction Sharding

01. Oracle pays a lot of attention to it and invested a lot of
time and effort into improving the Multi-Tenant option
04. Some application need the ability to scale massively, and
by leveraging the Oracle sharding option there are more
with every release ways to do so

Data Guard and Active Data Guard Exadata enhancements

02. Recovery of non-logged blocks, multiple instance apply in
RAC, DML redirection, multiple observers and read-only
05.
observers for Fast Start Failover …
Automatic Indexing, High Frequency statistics collection
and Real Time Statistics for many operations. Did we say
Database In-Memory yet?

Database In-Memory Automatic Update

03. Another growth area in terms of Features. Integration
with Data Guard, and tight coupling with Exadata provides
06. Upgrading the database has been simplified with the
introduction of the Automatic Update tool you already
even more performance heard about
Noteworthy changes for admins in 19c since 12c Release 1

Software installation based on images High Availability in 19c Standard Edition

07. Simplified installation and patching of the Oracle binaries.
Read-only Oracle homes are possible. Golden Images.
10. The Real Application Clusters option has been replaced
with Standard Edition High Availability in Oracle Standard
Fleet Provisioning/Patching Edition

GIMR becomes optional again Streams is de-supported in Oracle 19c

08. Beginning with 19c the Grid Infrastructure Management
Repository can be an optional component
11. While it has been deprecated in Oracle 12.1 Streams is
finally de-supported with Oracle 19c. It has been replaced
with Oracle Golden Gate

EZ Connect Plus There are many more changes to know about

09. EZ Connect is much enhanced greatly simplifying the 12. While planning the upgrade make sure to check the 19c
Upgrade guide for behaviour changes, deprecated and de-
database connection definition
supported features
Prepare for the
Container
Database NOW
With a nod to @MikeDietrichDE
Embrace the Container Database architecture

-- Oracle Database 20c – Database Upgrade Guide chapter 9

The Oracle Container Database

CDB$ROOT

SYSTEM UNDOTBSn Control files Others

Container Database

SYSAUX
PDB$SEED TEMP Redo logs

SYSTEM TEMP

PDBn
PDB1

PDB2
SYSAUX …

Service Service Service

PDB1 PDB2 PDBn
The Oracle Container Database

Container databases are a bit different

There is more than “a database”

• Root container

• Pluggable database

It is very common to use CDBs as consolidation target

• Management benefits

• Better use of hardware

Database consolidation before CDBs
Database consolidation with CDBs

The container database is host to the CDB$ROOT, the seed

(pluggable) database as well as user pluggable databases.

Each PDB is independent and forms its own namespace.

CDB$ROOT

PDB$SEED APP1 APP2

Database consolidation with CDBs

CDB$ROOT

CDB ADMINS

You can separate administrative duties at

the container and pluggable database
PDB$SEED APP1 APP2 level
APP2 ADMINS

APP1 ADMINS
Selected implications for administrators

A new class of views in the dictionary

New top-level views in CDB$ROOT

• Prefixed CDB%

• They take over from the DBA%-views as magical-see-it-all-views

New important column CON_ID in CDB%-views and V$-views

You may have to change your scripts

• The sooner you do it the better you are prepared

Selected implications for administrators
New class of users and roles
Common user
• Maintained in the CDB’s root
• Naming convention is to use C##username
• A common user potentially has access to PDBs
All Oracle administrative users are common
users
New class of users and roles
Local User
• Exists exclusively in a PDB
• You cannot connect to the root using a local user
account
• No namespace collision: multiple PDBs can each have
a SCOTT account (for example)
• Great advantage for consolidating applications
Selected implications for administrators

Patching is similar yet slightly different

The usual patching steps include

• Patching the binaries

• Executing datapatch for all databases in scope

• Oracle Support Doc ID 1585822.1 has more information on datapatch

And please ensure sufficient effort is invested in testing

Some more implications for administrators

There are many other things to consider

The introduction of the Container Architecture also affects

• Data Guard

• Enterprise Manager monitoring

• Backup and Recovery

• Flashback Database operations

The newer the Oracle release, the more feature-rich it is

Don’t forget the
database’s
ecosystem
After all, there’s an application running on top of the
database …

Commercial package or in-house development?

Scope matters

• Vendors are usually quite strict about application requirements

• If you developed software yourself you are in charge of the upgrade

Upgrading the eco-system together with the database

• Finally time to test the application with current ([JO]DBC) drivers

• In general terms, you should try and limit the number of changes
Consideration about the application

Who connects to the database? Consider upgrading drivers

Auditing should tell you all about your database users and tools. Review Too often drivers aren’t updated after initial deployment, causing
the application to assess whether updates to these are needed problems and exposing security risks. Check MOS 207303.1 and 401934.1
for driver compatibility

Don’t break it Do you know about instant-client?

Make sure to not only catch regular users, identify everyone. Even those You can now yum-install the instant client without having to agree to the
irregular but highly critical ones. Think of the person running that crucial license agreement making it simple to automate a deployment
report at the end of the quarter

Review database links Oracle JDBC drivers are now on Maven Central
Does the system in scope of the upgrade feed others via database links? It should now be much easier to include current JDBC drivers in an
Or vice versa? Are these releases compatible after the upgrade? application as part of the development and upgrade cycle
Monitoring
13.4.x has since
been released

Consider upgrading the monitoring

solution
Enterprise Manager users: check Oracle’s
compatibility matrix

• Does the Management Server (OMS) work with the

installed agent?

• Does the agent have the minimum required plugin to

monitor 19c?

Keep an eye out on your legacy release

Time for new
technology?
There are opportunities with every challenge

Automation and standardisation

Use the upgrade as an opportunity for new ways of working

• Oftentimes upgrades go hand-in-hand with hardware refreshes

• Standardising the database estate is paramount these days

• Standards can be enforced by automation

You should probably invest time in automation

• A bit more effort now, but pays off big time in the long run
There are opportunities with every challenge

Automation using Ansible

Ansible is a very popular automation tool

• Agentless; the only requirement is the use of Python on the target

• Instructions are written in YAML

• And they are easy to read and write

Ansible has become the de-facto standard for automation

There are opportunities with every challenge

Why Ansible
It takes away the dreaded, mundane tasks

• How many Oracle installations did you complete in your career?

• Are they still exciting?

Ansible is a better approach to other attempts at automation

• Previously we coerced the installer into a platform specific installation format and it
wasn’t fun

• The all-too-common shell script is hard to maintain, too

There are opportunities with every challenge

There are plenty further opportunities

You may have low hanging fruits in your environment

Enterprise Manager is a good example

• Do you use administration groups?

• Template collections?

• If not, you may want to have have a look

Monitoring all targets is a critical aspect of keeping the lights on

Opportunities in the cloud

Might cloud technology be an option for you?

Cloud technology allows you to automate even further

• Spin up infrastructure using Terraform

• Use immutable infrastructure thanks to Packer

• Let someone else run your database, as a service, for your application

• Or maybe use a largely self-managing system, Autonomous Database

Opportunities in the cloud

# main.tf
Terraform is the de-facto standard for creating ## it all starts with the virtual cloud network
infrastructure as code resource "oci_core_vcn" "app1_vcn" {
cidr_block = var.vcn_cidr_block
• After a little learning phase you get productive very compartment_id = var.compartment_ocid
display_name = "app1-VCN"
quickly dns_label = "app1vcn"
}

• The big advantage is the ability to create exactly the ## an Internet Gateway is required for outside connectivity

same infrastructure, always resource "oci_core_internet_gateway" "app1_igw" {

compartment_id = var.compartment_ocid
vcn_id = oci_core_vcn.app1_vcn.id
• It’s declarative approach makes it safe to re-run display_name = "app1-IGW"
enabled = true
}
• Syntax is very flexible and allows you to re-use code in
## lots more resources to come
modules …
Opportunities in the cloud

Moving to cloud is similar to a Data Centre move

Only that it’s easier to pull off

• No need to worry about hardware and wiring

• Focus on the important bits such as automation and security

• It is incredibly rewarding to spin up a database with a single command

• And finally you can enforce standards properly during the build

Don’t repeat the mistakes you made in the past, think fresh
And what about containers?

Containers started a new trend in software development

There is a realisation that deploying applications can be difficult

• Keeping track of dependencies for open-source software is hard

• Getting it wrong is easy

People don’t usually appreciate when someone jumbles their runtime up

Avoiding the “it worked on my laptop” symptom

And what about containers?

Containers started a new trend in software development

Wouldn’t it be better if you could “freeze” software and its dependencies?

• Need a new version of insertFavouriteToolHere?

• Simple: Build a new container image!

• Deploy by trashing the old container, replacing it with the new one

• Every container runs somewhat isolated from its peers

And what about containers?

Containers need to be managed

Practically everyone thinks of Kubernetes in this context

• Kubernetes is a container orchestration layer

• It takes care of scheduling containers and managing their lifecycles

• Amongst a great many other things

• A container in Kubernetes is referred to as a “pod”

Pods can potentially be started/terminated on all nodes in the cluster

And what about containers?

But does this work with a persistence store?

Containers and persistence are a difficult topic

• A non-issue for stateless containers

• Very much an issue for handling state

Oracle plans to certify its latest versions for Docker

• See My Oracle Support Doc ID 2216342.1

And what about containers?

But does this work with a persistence store?

Think about the implications
• Containers in Kubernetes might fail more frequently

• Kubernetes is managing your Oracle pod

• Scaling workloads up/down is difficult

Routine tasks are also more difficult

• Tuning

• Backup and Recovery

And what about containers?

Does that mean no Oracle

applications on Kubernetes?
That would be the wrong conclusion

• You can have the application tier managed by

Kubernetes

• While keeping the database tier in an IaaS or PaaS

environment
hp::h:::h:::h0::h:::h:::h:::h:::h:::h:::h:::h:::h:
• Oracle even provides an example application

Potentially the best of both worlds

Thinking about
upgrading to
Oracle 20c
Oracle Database 20c Upgrade

You can perform a direct upgrade to the new release from the following
releases:
• Any 19c

• Any 18c

• 12.2.0
Oracle Database 20c Upgrade

Need to know about compatibility:

• Before upgrading to Oracle Database 20c, you must set the COMPATIBLE initialization parameter to at least 12.2.0

• In Oracle Database 20c, when the COMPATIBLE initialization parameter is not set in your parameter file, the
COMPATIBLE parameter value defaults to 20.0.0

• Installing earlier releases of Oracle Database on the same computer that is running Oracle Database 20c can cause issues
with client connections
Oracle Database 20c Upgrade

CDB Architecture
• Starting with Oracle Database 20c, non-CDB Oracle Database upgrades to non-CDB architecture are desupported

Option 1: Convert the non-CDB to a PDB before upgrade

• With this option, you plug in the non-CDB Oracle Database release to the same release CDB. (For example, plug in a non-
CDB Oracle Database Release 19c into an Oracle Database 19c release CDB). Finish converting the non-CDB Oracle
Database to a PDB. Then, upgrade the entire CDB, with its PDBs, to Oracle Database 20c.

Option 2: Plug in the non-CDB, upgrade, and finish converting the non-CDB to a PDB after upgrade

• With this option, you plug in a non-CDB Oracle Database release to an OracleDatabase 20c CDB. Upgrade the plugged-in
non-CDB Oracle Database to Oracle Database 20c. Then, finish converting the non-CDB Oracle Database to a PDB.
Oracle Database 20c Upgrade

DBUA and the Oracle home:

• Starting with Oracle Database 20c, Database Upgrade Assistant (DBUA) is replaced by the AutoUpgrade utility

• Starting with Oracle Database 20c, the default network administration directory changes from the previous default in
the local Oracle home, Oracle_home/network (for example, /u01/app/oracle/product/19.1.0/dbhome_1/network), to a
new location.

• The new default location is the shared Oracle Base Home, in the path ORACLE_BASE/
homes/HOME_NAME/network/admin

• Starting with Oracle Database 20c, an Oracle Database installation configures all Oracle Database homes in read-only
mode by default
Oracle Database 20c Upgrade

Security and parameters

• Starting with Oracle Database 20c, the data types DBMS_CRYPTO_TOOLKIT_TYPES and package DBMS_CRYPTO_TOOLKIT
are desupported

• The init.ora parameters UNIFIED_AUDIT_SGA_QUEUE_SIZE, UNIFIED_AUDIT_SGA_QUEUE_SIZE, AUDIT_FILE_DEST,

AUDIT_SYS_OPERATIONS, AUDIT_SYSLOG_LEVEL and AUDIT_TRAIL have been desupported

• Desupport of IGNORECASE parameter for passwords

• Starting in Oracle Database 20c, the IGNORECASE parameter for the orapwd file is desupported and all newly created
password files are case-sensitive

• Desupport of DISABLE_DIRECTORY_LINK_CHECK

• The DISABLE_DIRECTORY_LINK_CHECK parameter is desupported, with no replacement

New features to consider after 20c Upgrade
Blockchain Tables
• Blockchain tables are insert-only tables that organize rows into a number of chains and is a new concept starting with
Oracle 20c.

• Each row in a chain, except the first row, is chained to the previous row in the chain by using a cryptographic hash. For
each Oracle RAC instance a blockchain table contains thirty two chains, ranging from 0 through 31.
New features to consider after 20c Upgrade
Automatic Index Optimization
• SQL> alter system set HEAT_MAP = ON;

• The optimization process includes actions such as compressing, shrinking or rebuilding the indexes:

Compress: Compresses portions of the key values in an index segment (~3 times)

Shrink: Merges the contents of index blocks where possible to free blocks for reuse

Rebuild: Rebuilds an index to improve space usage and access speed

• There are 2 options for enabling Automatic Index Optimization:

ADD POLICY TIER in order to perform the operation on a say low cost/ tier 2 tablespace when tier 1 storage is under space
pressure: alter index price_idx ILM ADD POLICY TIER TO BC_DATA;

ADD POLICY OPTIMIZE in order to kick off the process after a certain number of days passes without accessing the index: alter
index price_idx ILM ADD POLICY OPTIMIZE AFTER 3 DAYS OF NO ACCESS;
New features to consider after 20c Upgrade
Automatic Zone Maps
• A zone is a set of a contiguous data blocks on disk.

• A zone map is an index-like structure built on a table and stores information about the zones of that table.

• There are 2 major differences between indexes and zone maps:

1. A zone map stores information per zone instead of per row which makes it much more compact than an index

2. A zone map is not actively managed the way an index is kept in sync with the DML on the table