Triple C - Centralize, Cloudify and Consolidate Dozens of Oracle Databases (Oracle Groundbreaker Tour EMEA, 2021, OUGN))

Triple C -
Centralize,
Cloudify and
Consolidate
Dozens of
Oracle
Databases
Oracle Groundbreakers EMEA Virtual Tour 2021
Lucas Jellema, Architect & CTO AMIS | Conclusion

Classificatie: vertrouwelijk
Lucas Jellema
CTO for AMIS | Conclusion
Cloud Solution Architect
Triple C - Centralize, Cloudify and Consolidate Oracle Databases
lucas.jellema@amis.nl | technology.amis.nl | @lucasjellema | lucas-jellema

Publiek
#OGBEMEA
Triple Play - Centralize, Cloudify and Consolidate
IST
SOLL

Publiek
#OGBEMEA
Starting Point
• 120+ sites
• Local Setup – the same for all sites (except for data)
• Server, 4CPU with Hyperthreading, 32GB or 64GB; 4 VMs
• Oracle Database 12c R1 Enterprise Edition
• 12-15 GB data (60% site specific)
• 30-100K transactions per day
• Java-based Integration platform
• 100s background jobs & daemons
• Shell script, Perl, C++ (binary), PL/SQL, SQL
• UI platform (Oracle Forms & modern low code, Java based)
• Database dates back to late ‘90s
• Business relevance
site
site
Site
Apps (jobs &
daemons)
integration
platform
UI
Application
Oracle
Database
12.1
Mobile
equipment
Printer

Publiek
#OGBEMEA
Desire to Consolidate Databases
• Reduce operational effort, technical maintenance and
Oracle license & support fees
• Constraints
• Each site only access to their own data (like a private database)
• Minimal impact on existing application code
• Target platform: Azure Cloud
• Performance on par
• Migration must be low risk to business operations
• Network upgrade for all sites may be assumed
site
site
Site
Apps (jobs &
daemons)
integration
platform
UI
Application
Mobile
equipment
Printer
Centralized,
Cloudified,
Consolidated
Oracle
Database
19c
Oracle
Database
19c &
VPD
site
site
Site
Apps (jobs &
daemons)
integration
platform
UI
Application
Oracle
Database
12.1
Mobile
equipment
Printer

Publiek
#OGBEMEA
Virtual Private Database
“access database as if each site is the only one”
• Every table has a column SITE_ID
• Every SQL statement has a WHERE condition for each table accessed:
• WHERE SITE_ID = <current site’s identifier>
COL A COL B SITE_ID
AB 21 23
CD 18645 36
EF 651 11
GH 121223 23
IJ 5633 36
Site 23
Site 36
Table X
select *
from X
select *
from X
COL A COL B SITE_ID
AB 21 23
GH 121223 23
COL A COL B SITE_ID
CD 18645 36
IJ 5633 36
select *
from X
where SITE_ID = <>

Publiek
#OGBEMEA
Oracle Database Enterprise Edition - Virtual Private Database
Fine Grained Access or Row Level Security Access Policy
• Policy is applied to a Table or View
• It specifies a function to invoke to return a filter condition to be added to
SQL statements (SELECT & DML)
COL A COL B SITE_ID
AB 21 23
CD 18645 36
EF 651 11
GH 121223 23
IJ 5633 36
Table X
add RLS policy for all
types of SQL statements –
invoke policy function
Site Filter
Policy Function
always return the string
“WHERE SITE_ID =
SYS_CONTEXT(‘MY_CTX’,’CURRENT_SITE_ID’)
”
Application Context
MY_CTX
CURRENT_SITE_ID
SQL
memory cache
with session
wide
parameters

Publiek
#OGBEMEA
Proof of Concept
• Prove
• that and how consolidation (centralized and cloudified) can work
• Solution Design of End State (SOLL)
• how will it be
• sizing
• cost (OPEX)
• Roadmap for migrating to end state
• how do we get there
• how much effort will it be
• what do we need (time, budget, skills, specific people, tools, ...)
• Impact
• Risk
• Benefits

Publiek
#OGBEMEA
Triggers, Drivers, Objectives, Bonus Benefits
• Costs: Hardware, Software licenses & support fees
• Operational effort (and risk)
• Business & Technology agility & innovation
• Increasing feature release frequency
• Data freshness on site & in central
• Mobile Apps – used on site and
running against central systems can use real time site data
• Reduction in vulnerability
• Scalability – short term peaks & long-term growth (or decline)
• Accelerating provisioning (& decommissioning) of sites
• Focus scarce IT staff on business value (away from IaaS)
• Implementing the Cloud Strategy and moving forward on architecture roadmap
• Reduce Oracle footprint

Publiek
#OGBEMEA
PoC Setup
• Oracle Database 19c EE Multitenant Architecture on Azure VM
• Create PDB - a centralized clone of a local site database
• to test 19c upgrade and cloudification
• Create PDB as the consolidated database
• Import into consolidated PDB an export from a site database – schemas and
database objects only
• excluding schemas for UI App and Integration platforms
• Prepare VPD in PDB
• extend tables with column SITE_ID, create application context,
create package, create and apply VPD policy function
• Create PDB as the staging database to load individual site exports into
• Import site export into staging database
• Transfer data from staging data
to application tables in consolidated database
• and set value for SITE_ID column
Consolidated Site
Database
Staging
Site
Database
Site 1
Database
Site 2
Database
Site 3
Database
Centralized
Site
Database
testing 123

Publiek
#OGBEMEA
VPD Set Up in Consolidated Database
• Define VPD Policy with a Function to return Query Filter
• Apply VPD policy on all application tables
• Create Package to set site_id in application context
• When to call this package? – with minimal impact on existing application code!
• For jobs, daemons and other stateful database sessions
• Each site uses a site-specific database service name (tnsnames.ora) (or proxy user)
• all service names end up in the same database instance
• On Logon trigger intercepts database session initialization, inspects the database service name
(using sys_context & USERENV), determines site_id and calls sited procedure to set app context
Site Filter Policy
Function
Application Context
my_ctx
current_site_id
Package
ON LOGON
trigger
UI App
Daemons
& Jobs Connect through
site specific
database service

Publiek
#OGBEMEA
Cloudify & Consolidate
• Site is no longer the only inhabitant of the database
• Shared objects or unique names: pipe, alert, Table Lock, DDL operations
• Unique & Primary (and therefore Foreign) Keys extended
• Indexes extended with column SITE_ID
• New Table Indexes with only SITE_ID => Table Partitioning
• partition (at least large, heavily accessed) tables by Site
• Proxy User per site – site specific credentials
• used in ON LOGON trigger to set Site Identifier in Application Context
• Sequences set to highest value in any of the imported databases
• Single Record Table (max_trans = 2)
• In Cloud no access allowed from database to environment
• abandon utl_file, DIRECTORY, utl_tcp, utl_http, External Table

Publiek
#OGBEMEA
PoC ++
• In addition to C3 for Site Databases
• with all database clients running locally, on site
• Now also apply C3 to
• local background applications, jobs & daemons
• local UI Applications
• local integrations & integration platform
SOLL++
site
site
Site
Apps (jobs &
daemons)
integration
platform
UI
Application
Mobile
equipment
Printer
Centralized,
Cloudified,
Consolidated
Oracle
Database
19c
site
site
Site
Mobile
equipment
Printer
Centralized, Cloudified,
Consolidated
Oracle
Database
19c & VPD
integration
platform
UI Applications
Oracle
Database
19c & VPD
Apps (jobs &
daemons)
SOLL Oracle
Database
19c & VPD
A few Apps (jobs
& daemons)

Publiek
#OGBEMEA
Exploring & Demonstrating
Consolidated Database Performance
• Will the consolidated database(s) be able to provide performance on par with today’s local
on-site behavior?
• How many consolidated, central database instances will be required
• and what will the sizing be of VMs and Databases?
 Strategies
 Scale Up - vertical
 Scale Out – horizontal
 Tune, Redesign, Refactor, leverage “performance enhancing features” (for example
materialized views, in memory database, move read only workload to standby database)
 We require flexibility in scale (aka elasticity)
 Uncertainty regarding performance after migration
 Variable load (daily, seasonal, incidents)
 Future growth (organic & through acquisitions)

Publiek
#OGBEMEA
Elasticity – Scale Up and Down
• Increase VM Shape
• CPU, Memory, #IOPS, I/O Throughput,
Storage Size & Speed, Network Connections & Bandwidth
• Scale Up Application Server and Database
• No impact on application code or configuration
• Substantial impact on price
• VM cost
• Software License cost
• Limited by the VM shapes on (affordable) offer
• there are boundaries
• All eggs in one basket?

Publiek
#OGBEMEA
Elasticity – Scale Out and In
• Add VM instances
• with additional Database and App Server instances
• Move data to new database instance
• Move jobs to different app servers,
move UI apps to different UI app servers
• Reconfigure Job definitions –
for different sets of sites
• Update routing rules –
site go to different app server
• Impact
• spread the workload
• distribute risk (impact of any database failing)
• increase license and cloud resource fees ?
• increase DBA/Ops effort ?
• Scaling from one to two is hard, beyond that
it is quite straightforward
Reverse Proxy
UI
App A
UI
App A
UI
App B

Publiek
#OGBEMEA
Load Test with Realistic Workload
• How to put a realistic load on the consolidated database?
• the same combination of SQL statements and PL/SQL activities as locally
on site
• scaling the load to a multifold of the single site load – 10-30 times the
local load
• Oracle Real Application Testing
• Capture workload in live database
(filtering out specific users)
• Replay workload on any target database
• stretch in and out (elastic time)
• scale up the replayed workload (run multiple workloads in parallel)
• Analyze the actual performance of the replay
• resource usage, errors, bottlenecks, query timings, AWR, ASH reports

Publiek
#OGBEMEA
How to run workloads for dozens of sites
(from only three RAT captures and three data sets)
• A special Consolidated Performance Test Database has been set up
• Based on data sets from three sites, data has been created for X sites
• RAT recordings have been made on three production sites: 1516, 3036 and 5805
– from July 29th, 16:00 hours until July 30th, 16:00
• RAT Recordings are replayed through a site-specific database service against the consolidated
database and executed in the VPD for the site derived from the database service
TEST DB
Tables
Data was loaded from three sites.
All records have been duplicated
several times for different site:
SITE_ID is changed in each copy
Site DB
Site DB
SIte DB
RAT
RAT was used to capture 24h
workload in three Site DBs
RAT is used to replay each of
the workloads multiple times.
All replays take place through
different site specific
database service names
Logon
Trigger
Logon trigger sets SITE_ID in
Application Context based on
database service name used by RAT.
All RAT sessions run in different VPDs

Publiek
#OGBEMEA
Challenges in Achieving Proper RAT Results
• VM and Database configuration for running RAT
• disk size, flashback area, file system interaction
• overhead caused by RAT tooling itself
• Running tests takes a long time (to prepare and process)
• EMCC 13c (Enterprise Manager Cloud Control)
• Determining meaningful results is not trivial
• from RAT reports
• from ASH, AWR, SQL Tuning Set
• Additional option: while the RAT workload is replayed – run a simple periodic load test with
some indicative queries (using JMeter for example) and measure the execution times (that
ran in the context of representative workload)
• Database Workload not suited for concurrent execution (refactoring required)
• Missing indexes on foreign keys
• Lock Table
• Create and Drop Table
• Update Single Data Block table
• Use of isolated objects in non-isolated environment: pipe & alert
• Write logging through UTL_FILE

Publiek
#OGBEMEA
RAT Approach
• Run multiple tests to mutually compare
• Run workloads for an increasing number of sites
• Run workloads on a number of VM shapes
• CPU, Memory, IOPS and throughput/bandwidth, disk size and mapped Database
configuration settings (SGA, PGA, UGA, #processes, parallel_max_servers)
• Run workloads with various database design and code refactorings and workarounds
• Disable dbms_alert, apply Table Partitioning, comment out utl_file calls
• Determine performance for each workload from
• database resource usage metrics (cpu, disk io, IO wait time)
• query & transaction performance (execution time and throughput)
• Our aim: determine the number of sites that we can support in a single VM / Database instance
(with reasonable shape)
• and calculate the total number of instances required
for 120 (now) and 200 (later) sites
• show a (linear) relationship between the number of
sites and the performance
and between the VM shape and the performance
for a fixed number of sites
• determine the bottleneck factor(s) at play

Publiek
#OGBEMEA
RAT Findings
• Findings
• without any refactoring and code improvements
• 20-30 sites in a single Database instance
• VM shape: E64ds (64 vCPU, 504 GB) + P40 disks
• 2.3 (?) Azure vCore per site
• Bottlenecks
• CPU
• IOPS
• disk size (from logging written through utl_file)
20 sites 30 sites 40 sites

Publiek
#OGBEMEA
Lots of Opportunities for Improvement –
to host more sites in a single database instance
• optimizations without application impact
• partitioning of tables
• index design (add, refine, remove indexes, partitioning of indexes - auto index design)
• execution plan optimizations for bottleneck actions
• Materialized Views (for heavily queried datasets)
• in memory database option (for heavily queried datasets)
• resource plans (and consumer groups) to assign resources to high priority jobs
• explicitly work with generic data - remove data records shared across site
• clean up redundant/discarded data
• scale up of VM shape & DB configuration (IOPS, memory, CPU, SGA, parallelization, # processes..)
• optimizations with some application impact
• purge redundant data and/or archive cold data in external storage (NoSQL, Azure Blob)
• spread jobs differently over the day (to reduce peaks)
• using standby databases in read only mode – to reduce the load on the primary database, achieve higher overall performance
and even allow us a smaller VM shape for all databases (license consequences)
• remove unused objects
• rewriting SQL query (of poorly performing queries)
• code optimization (remove usage of shared resources - alerts, pipes, DDL, table locks)
• BO App job consolidation across multiple sites (make jobs process multiple sites at once)

Publiek
#OGBEMEA
Application Server Scripts, Daemons & Jobs
• Local Setup – specific to one site
• (only) desired version of each of 50+ applications installed
(shell, binary compiled from C++, Perl, SQL, PL/SQL)
• Hard coded directories & credentials in code
• Configuration Files
• Data Directories
• Daemons & scheduled Jobs – process all
• Central App Server with all sites consolidated
• all [in use] versions of all applications are installed
• no hard coded location/configuration references anywhere– refer to environment variables
• database connection based on Oracle Wallet and TNS_ADMIN environment variable
• site specific data directories – referred to through environment variables
• run daemons and jobs per site (or better yet: consolidate across all sites)
• unique name
• site specific settings for environment variables
(application version directories, TNS_ADMIN, data directories)

Publiek
#OGBEMEA
Change Management
• Design principles for change management process:
low risk, fine grained control, high flexibility, high degree of
automation, minimal downtime and efficient usage of cloud resources
• A new release (bundle of application versions at a certain cut-off date)
should not be rolled out at once, big bang to all sites
• controlled multi-stage rollout – with one or some, several and many
(or all) sites adopting a new release at different moments
• Roll out of a release should have minimal impact and
cause minimal downtime
• discern between the installation & configuration of new versions
and the activation of new versions for sites
• A roll out can easily be undone
• sites can be moved between versions quickly and easily

Publiek
#OGBEMEA
Multiple application versions co-exist
• Not all sites are on the same application version
• Multiple versions of each application coexist on app server
• Not all sites use the same versions of database objects (canary site, early adopter, laggard)
• different versions of Packages, Types and Views
• requiring evolved definitions of Tables
• How can we support multiple “database releases” to coexist within the same multi-site
consolidated database?
• so we do not have to move sites between databases?

Publiek
#OGBEMEA
Introducing Oracle Database Edition Based Redefinition (EBR)
• Edition Based Redefinition EBR – introduced in Oracle Database 11gR2 (2012)
(created to support zero down-time roll out of new releases of Oracle eBusiness Suite)
• free feature in all flavors of Oracle Database
• Editions add a “release” dimension to the database – orthogonal to schemas
• an edition is a collection of database objects ( object_name, object_type and schema)
• in an editioned database, the full coordinates of a database object become (
object_name, object_type, schema, edition)
• two editions can contain different versions of a database object (package, view, type,
synonym, function)
• each session runs in a specific edition – this current edition determines which version
of each database object is used (during name resolution as part of statement parsing)

Publiek
#OGBEMEA
Oracle Database Name Resolution
• When a Statement is Parsed or Evaluated – Name Resolution determines which database objects to
access
• For example:
• begin X(42); end;
• Oracle Database has to decide what exactly X is (name resolution)
• PL/SQL unit in current user’s schema (or the schema of the schema set with alter session set current schema)
• private synonym (in current schema) and the associated object it refers to – which can be a PL/SQL unit or
synonym
• public synonym and the associated object it refers to – which can be a PL/SQL unit or another synonym
Schema A
Schema B
Schema C
Procedure
X
Synonym X
Public
Synonym X
Procedure
X
alter session set current_schema B
begin x(42); end;
Schema D
alter session set current_schema C
begin x(42); end; alter session set current_schema D
begin x(42); end;

Publiek
#OGBEMEA
Edition R2
Edition R3
• Name Resolution in editioned database uses Current Edition to determine the Object Version
• For example:
• begin X(42); end;
• Oracle Database has to decide what exactly X is (name resolution)
• PL/SQL unit in current user’s schema (or the schema of the schema set with alter session set current schema)
• private synonym (in current schema) and the associated object it refers to – which can be a PL/SQL unit or synonym
• public synonym and the associated object it refers to – which can be a PL/SQL unit or another synonym
• in an editioned database, name resolution also needs to check which version of the object lives in
the current edition
Schema A
Schema B
Schema C
Synonym X Public Synonym
X (2.0)
Procedure
X
alter session set current_schema B
alter session set edition = R2
begin x(42); end;
Schema D
alter session set current_schema C
alter session set edition = R3
begin x(42); end;
alter session set current_schema D
begin x(42); end;
Edition R2
Edition R3
Procedure X
(1.1)
Procedure X
(1.2)
Public Synonym
X (3.0)

Publiek
#OGBEMEA
• Database object versions in a “site release” are in a database edition
• a database edition inherits all object versions from its predecessor –
then overwrites this inheritance with its own specific changes
• Tables are outside editions - there is only one version of a table
• table changes must be backward compatible
• Advanced: There can be multiple versions of data records (domain values, configuration data, …)
• add an “edition from” and an “edition until” column to each table that contains versioned data
• define a VPD policy on the table with a filter that checks the current edition vs these edition columns
Edition R2
Edition R3
Procedure X
(1.1)
Procedure X
(1.2)
Edition R1
Procedure X
(1.0)
View Y
(1.0)
Package Z
(1.0)
Package Z
(1.1)
Type Q
(1.0)
Type Q
(1.0)
Table A
Table B
Sequence K

Publiek
#OGBEMEA
Working with Database Editions
to Support Multiple Releases from a Single Database
• Each site is associated with one specific database edition
• all database actions performed for that site are done in
the context of that edition
• Each site uses one specific version of each application
• the application versions used by the site must be compatible
with the site’s database edition and with each other
• The application version & database compatibility matrix (“what can
go together”) is crucial in managing the mutual compatibilities
TriPle C - Centralize, Cloudify and Consolidate Oracle Databases
Application version compatibility matrix
Edition R2
Edition R3
Edition R1
Table A
Table B
Edition
R2
APP P - 1.3
APP P - 1.3
APP P - 1.3
APP P - 1.3
APP Q - 1.1
APP Q - 1.2
APP R – 2.0
APP R- 3.0
APP R – 3.1
APP S - 1.0
APP S - 1.1
APP P - 1.3
APP Q - 1.2
APP R- 3.0
APP S - 1.0
Site 44

Publiek
#OGBEMEA
UI Application: each UI App version can work with one (or
more) database editions
sites 1-30, 104
sites 31-51, 100-103
sites 52-88, 104-115
Site 1 Site 38 Site 44 Site 101 Site 66 Site 110
UI App Server
UI App A UI App B
local
central
UI App A
1.2
UI App A
1.3
UI App A
1.4
Ed 3
Ed 4
Ed 5

Publiek
#OGBEMEA
UI Application – Routing, Versions and Editions
sites 1-30, 104
sites 31-51, 100-103
sites 52-88, 104-115
Site 1 Site 38 Site 44 Site 101 Site 66 Site 110
UI App Server
UI App A
1.2
local
central
Ed 3
Ed 4
Ed 5
Ed 3
Ed 4
Ed 5
Ed 3
Ed 4
Ed 5
Reverse Proxy
routing
rules
UI App Server
UI App A
1.2
UI App Server
UI App A
1.3
UI App Server
UI App A
1.4
Site specific
URLs for
the UI App
Stored procedure
call to DB to pass
Site Identifier for
VPD
Database
Connection
associated with
Database Edition

Publiek
#OGBEMEA
Change Management Process
• Prior to Release
• designate application & database object versions to ship
• establish mutual compatibility between all versions in the release
• and backwards compatibility from earlier releases still supported for sites
(the new stuff should not break any existing still in use)
• note: all database table changes are backwards compatible
• Prepare release on Production environment
• Build up a new UI App Server with the new UI App version
• Install new background application versions on App Server – next to existing
• Create new Database Edition and create new versions of database objects
• note: no one is using any of the new things
• Initial roll out – for a test or dummy site or a real site canary release
• Generate Reverse Proxy routing rules that will route users on site to new UI App version
• Generate App Server symbolic links and environment variables for site to use new App versions & DB edition
• Update site to database edition mapping records – to associate site with new DB edition
• Once success is confirmed, repeat for additional sites
• In case of failure, reverse the steps to roll site back to original release
Release Initial Rollout
Test/Accept Prepare/Install Smoke Test/Use
Next Rollout
Edition R2
APP P - 1.3
APP Q - 1.2
APP R- 3.0
APP S - 1.0
R4.6

Publiek
#OGBEMEA
Summary & Conclusions
• [20 years of accumulated] Technical Debt catches up with us
• hard coded values, lack of automated regression tests, old technology (and no more skills),
lack of documentation (how, what, why), limited application portfolio/life cycle management
(which applications & features are still in use; dependencies between applications)
• Many refactor opportunities
• to reduce complexity and increase maintainability, improve performance, reduce operational
effort, reduce cloud resource usage
• Know the out-of-the-box (or easily purchasable) mechanisms of the Oracle Database

Publiek
#OGBEMEA
Applied Oracle Database features
Feature Since License / Cost Purpose
Virtual Private Database 8i every edition, no cost option Fine grained (row level) access control
Database Link ? (< 7) every edition, no cost option SQL against other Oracle Databases
Instead Of Trigger 8.0 every edition, no cost option Handle DML statements against Views
Table Function 9iR1 every edition, no cost option Create View on top of PL/SQL Function i/o table or view
Proxy User 9iR2 every edition, no cost option Light-weight, schema-less database user
Application Context
(session or global)
8i every edition, no cost option In memory data cache
Logon Trigger 8i every edition, no cost option Programmatic intercept Database Session initialization
Real Application Testing 11gR1 separate license Capture and Replay actual database workload
Sharding 12cR2 EE up to 3 shards; >3: Active
Data Guard, RAC or Golden Gate
Physically partition Oracle Database in shards – allowing
cross shard operations as if on a single logical database
Table Partitioning 8.0, 9i Partitioning Option Physically partition table data – improve query & DML
Multitenant (PDBs) 12cR1 every, no cost up to 3PDBs Consolidated DBA across PDBs – including clone DB
Edition Based
Redefinition
11gR2 every edition, no cost option Zero down time application upgrades [by supporting
multiple parallel releases of database objects]

Publiek
#OGBEMEA
Summary & Conclusions
• [20 years of accumulated] Technical Debt catches up with us
• hard coded values, lack of automated regression tests, old technology (and no more skills),
lack of documentation (how, what, why), limited application portfolio/life cycle management
(which applications & features are still in use; dependencies between applications)
• Many refactor opportunities
• to reduce complexity and increase maintainability, improve performance, reduce operational
effort, reduce cloud resource usage
• Know the out-of-the-box (or easily purchasable) mechanisms of the Oracle Database
• Decoupling – between sites, applications, application & database, application & environment
• to allow (independent) scaling, fine grained release rollout, implementation changes
• Steppingstone for short term gains and longer term innovation & improvement
• paid for from cost reduction in hardware & software (and reduced OPS effort)
• Controlled Migration: add sites, move jobs, migrate UI apps
• Network is pivotal (capacity & stability)
• some application offline capabilities maybe required

Classificatie: vertrouwelijk
Tusen Takk
Thank you very much
lucas.jellema@amis.nl | technology.amis.nl | @lucasjellema | lucas-jellema

Triple C - Centralize, Cloudify and Consolidate Dozens of Oracle Databases (Oracle Groundbreaker Tour EMEA, 2021, OUGN))

Recommended

More Related Content

What's hot (20)

Similar to Triple C - Centralize, Cloudify and Consolidate Dozens of Oracle Databases (Oracle Groundbreaker Tour EMEA, 2021, OUGN)) (20)

More from Lucas Jellema (20)

Recently uploaded (20)

Triple C - Centralize, Cloudify and Consolidate Dozens of Oracle Databases (Oracle Groundbreaker Tour EMEA, 2021, OUGN))

Editor's Notes