Oracle Multitenant Technical Deep Dive Webinar

Oracle Multitenant:
Technical Deep Dive
23-04-2020
Ángel Freire R.
Principal Solution Architect
Webinar

Oracle Multitenant: Technical Deep Dive
Webinar - Oracle Multitenant: Technical Deep Dive 2
• Arquitectura Multitenant
• Creación de una PDB (dbca)
• Migración y consolidación en arquitectura multitenant
• Oracle Multitenant y Oracle Cloud
• Oracle Multitenant: Casos de uso
• Oracle Multitenant: Patch & Update
• Q&A

Arquitectura Multitenant

Arquitectura tradicional requiere memoria, procesos y ficheros de base de datos

Arquitectura tradicional requiere memoria, procesos y ficheros de base de datos
System Resources

Descripción
• Un Container Data Base (CDB) es una base de datos física que contiene cero, una, o muchas Pluggable
DBs (PDBs) creadas por el usuario.
• Una base de datos conectable (PDB) es una colección de esquemas, objetos de esquema y objetos no-
schema que se presenta a un cliente de Oracle Net como una no-CDB.
• Una base de datos no-CDB es una base de datos tradicional Oracle que no puede contener PDBs.
• A partir de Oracle Database 12c Release 1 (12.1), una base de datos debe crearse como una CDB o no-
CDB. A continuación se puede conectar una no-CDB dentro de una CDB como una PDB.
• Los clientes deben conectarse a las PDBs utilizando un nombre de servicio que se ha creado dentro de la
CDB durante la fase de creación de la PDB.

Componentes de un Multitenant Container Database (CDB)
PDBs
Root
Pluggable Databases (PDBs)
CDB

• Soporte para hasta 252 PDBs concurrentes
• Una PDB se percibe y opera de forma análoga a
una no-CDB
• PDB o no-CDB no son diferenciables desde el
punto de vista de las conexiones de los clientesDatabase
Link

• PDBs comparten SGA y los procesos de
background
• Las sesiones foreground de los clientes
unicamente conocen la PDB a la que están
conectadas

Escalabilidad
Pluggable Database
• Únicamente pequeños incrementos en el consumo de memoria
para cada una de las PDBs añadidas
2,5
22
11,,55
1
000,,,55
0
ERP HCM ERPERP ERP BI BI
DW
GGBB

Ficheros en la CDB Namespaces
• Cada PDB tiene su propio conjunto de tablespaces
incluyendo los de SYSTEM y SYSAUX
• Las PDBs comparten: UNDO, REDO
• y control files, (s)pfile
• Por defecto cada CDB tiene un único TEMP
tablespace, pero pueden añadirse tantos como
sean necesarios

Usuarios
• Los local users son los equivalentes a los users-
customer-defined en una no-CDB
• Un local user se define unicamente en una PDB
• Un local user puede administrar una PDB
• Un common user se define en el root y está
representado en cada PDB
• Un common user puede conectarse a cualquier
PDB donde tenga permiso de “Create Sesion” y
puede administrarla
• Los propietarios del sistema Oracle son los
common users

Unplug / plug Simplemente desenchufar la PDB de la CDB…

…y enchufar en la nueva CDB…
Arquitectura Multitenant - Unplug / plug
• El movimiento entre CDBs re reduce al simple
movimiento de los metadatos de la PDB
• Los Upgrades y parcheados se simplifican
enormemente
• Una PDB desenchufada contiene toda su
información particular, acerca de la clave de
encriptación, opatch, etc.

Ejemplo
Arquitectura Multitenant - Unplug / plug
alter pluggable database HCM
unplug into '/u01/app/oracle/oradata/…/hcm.xml'
Unplug
Plug
create pluggable database My_PDB
using '/u01/app/oracle/oradata/…/hcm.xml'

Backup de todas las Data Bases como una; recovery a nivel de PDB
Gestionar muchas Data Bases como una con Multitenant
Un Backup
Point-in-time recovery
A nivel de PDB

Una única Standby Database incluye todas las PDBs
Gestionar muchas Data Bases como una, con Multitenant
Dataguard

Selección flexible para el parcheado y Upgrade de Databases
Upgrades Simplificados

Pluggable databases aprovisionables desde 0 (“seed”)
Aprovisionamiento ultra-rápido

Clonado rápido de PDBs
• PDBs clonables desde el interior de la misma CDB
• PDBs clonables desde CDBs remotas (DB link)

Ejemplo
Clonado de una PDB
create pluggable database HCMBI from HCM
Local
Remote (DB Link)
create pluggable database HCMBI from HCM@us.acme.db1

Reducción CapEx & OpEx, mayor agilidad y fácil adopción
Ventajas de la Arquitectura Multitenant
• PDB auto-conteniendo cada Aplicación
• Transparente a las Aplicaciones
• Aprovisionamiento rápido (via clones)
• Portabilidad (via plug/unplug)
• Memoria y procesos background compartidos
• Más aplicaciones por servidor
• Mayor densidad de consolidación
• Operaciones comunes efectuadas a nivel CDB
• Gestión muchos como uno (upgrade, HA, backup)
• Control granular cuando se necesita

Alta Eficiencia: 6x menos recursos H/W, 5x más escalabilidad
Databases: Pluggable vs no-CDB
OLTP benchmark comparison
Para 50 Databases unicamente 3GB
de RAM y 27% CPU vs. los 20GB de
RAM y 36% CPU utilizados por las
instancias con la arquitectura
tradicional
Las Pluggable databases escalan hasta
más de 250 instancias mientras que las
instancias por separado solo lo hacen
hasta 50 sobre la misma infraestructura

Beneficios clave
Beneficio Característica
Reducción CapEx • Más Aplicaciones por servidor
Reducción OpEx
• Gestión muchos como uno
• Procedimientos y SLA estandarizados
• Aprovisionamiento rápido
Mayor Agilidad
• Clonado para desarrollo / test
• Portabilidad mediante “pluggability”
• Escalabilidad via RAC
Facil Adopción • Transparente a las Aplicaciones

Creación de una PDB (dbca)

Creación de una nueva PDB (DBCA)

• En este punto podemos escoger entre
crear una nueva PDB vacía desde la
SEED o clonar desde una PDB ya
existente.
• Si optamos por la opción de clonado, el
tiempo de creación dependerá del
tamaño de la PDB.
• Si se trata de una Base de Datos
encriptada, esta encriptación se traslada
a la copia de la PDB.

• En este menú podemos escoger entre
crear un nuevo administrador de la PDB
y por otro lado podemos bloquear los
usuarios para evitar que los mismos
usuario se conecten a esta nueva PDB

Migración y consolidación en arquitectura multitenant

Migración a PDB
• En una arquitectura estándar nos podemos encontrar con múltiples servidores que
contienen múltiples Bases de Datos.
• Cada uno de estos servidores requieren un mantenimiento y actualizaciones
periódicas.
• Pasa lo mismos con las Bases de Datos, múltiples Bases de Datos requieren
muchas horas de mantenimiento.
• A continuación veremos un proceso de Upgrade y consolidación en arquitectura
multitenant
ERP
11.2.0.4
RRHH
11.2.0.4
CRM
11.2.0.4

Migración a PDB
• El proceso de migración de una arquitectura tradicional a Container Database
pasa por hacer un Unplug de una Base de Datos en arquitectura tradicional y
luego realizar el Plug en un contenedor de DDBB.
• Estos procesos de migración son físicos por lo que la arquitectura deberá ser la
misma. A pesar de que podríamos convertir los Datafiles de arquitectura, lo mejor
es no mesclar estos cambios.
• Con lo anterior el primer paso vendrá dato por subir de versión todas las DDBB a
la versión objetivo.
ERP
11.2.0.4
RRHH
11.2.0.4
CRM
11.2.0.4

Migración a PDB
• El siguiente paso en este proceso de migración y consolidación será la creación
de un container vacío para alojar todas nuestras Bases de datos.
ERP
19c
RRHH
19c
CRM
19c

Migración a PDB
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP OPEN READ ONLY;
Source DataBase
Creación de un XML File de la misma forma que para una PDB
SQL> BEGIN
DBMS_PDB.DESCRIBE(
pdb_descr_file => ‘/stage/db19c.xml');
END;
/
SQL> SHUTDOWN IMMEDIATE;
Source DataBase

Migración a PDB
SQL> CREATE PLUGGABLE DATABASE PDBMEET1 using '‘/stage/db19c.xml'
NOCOPY TEMPFILE REUSE;
Target DataBase
Borrado del Diccionario de DDBB
SQL> ALTER SESSION SET CONTAINER=PDBMEET1;
SQL> @$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
SQL> ALTER SESSION SET CONTAINER= PDBMEET1;
SQL> ALTER PLUGGABLE DATABASE OPEN;
Startup la PDB
En este caso se ha utilizado la condición de “NOCOPY”, esto significa que reutilizaremos los Datafiles reduciendo
de forma considerable esta migración. La condición “COPY” realizaría una copia de los Datafiles.

Migración a PDB
• Con este proceso de migración y consolidación
hemos concentrado varios servidores en uno solo.
• La mayoría de las tareas administrativas solo
afectarán a una PDB determinada como puede ser:
• Restore (En caso de una corrupción solo afecta a
esa PDB)
• Flashback Database
• Llenado de UNDO , TEMP
• Podemos excluir una PDB de una réplica por
DataGuard
• Snapshot a nivel de PDB

Oracle Multitenant y Oracle Cloud

Singularidades de Oracle Cloud
• Todas las Base de Datos provisionadas en el Cloud de Oracle se crean
en arquitectura Pluggable Database (PDB) (Oracle 12.1 en adelante)
• En infraestructura Bare Metal y Exadata las Bases de Datos se podrían
crear igual que en infraestructura tradicional.
• En VM Standar solo se puede crear una DDBB por cada DBCS por lo
que la opción de Multitenant permite la consolidación de muchas Bases
de Datos en un único DBCS.
• La arquitectura Multitenant permitirá poder disponer de copias de una
Base de Datos (PDB) en el mismo servidor y en un mínimo tiempo.
HR
Oracle Cloud

Singularidades de Oracle Cloud
• Desde la versión 19c podemos crear hasta tres PDBs sin necesidad de
hacer una suscripción adicional a EE.
• Oracle DBCS ahora permite el cambio de Shape con lo que si
necesitamos realizar una prueba en la DDBB con un alto consumo de
recursos podemos hacer la siguiente operativa:
 Cambiar de Shape de DBCS
 Generar un Clon de la PDB
 Realizar las pruebas sobre el Clon
 Volver al Shape Original
• Las tareas de Backup y Restore en el Cloud afectan a toda la DDBB,
para realizar esta operativa sobre una única PDB tenemos que recurrir
a la manera tradicional.
HR
Oracle Cloud

Oracle Multitenant: Casos de uso

Creación de una nueva PDB (command line)
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDBMEET1 READ WRITE NO
SQL> CREATE PLUGGABLE DATABASE PDBMEET2 ADMIN USER PDBADMIN IDENTIFIED BY "RexTon022020##" ;
Base de datos de conexion creada.
SQL> ALTER PLUGGABLE DATABASE PDBMEET2 OPEN READ WRITE;
Base de datos de conexion modificada.
SQL> show pdbs
---------- ------------------------------ ---------- ----------
Clone PDB

SQL> CREATE PLUGGABLE DATABASE PDBETE from PDBAVT KEYSTORE IDENTIFIED BY “XXXXXXXXXxx##";
SQL> show pdbs
---------- ------------------------------ ---------- ----------
3 PDBAVT READ WRITE NO
4 PDBETE MOUNTED
SQL> alter pluggable database PDBETE open;
Pluggable database altered.
SQL> show pdbs
---------- ------------------------------ ---------- ----------
4 PDBETE READ WRITE NO
Clone PDB

Borrado de una PDB
SQL> show pdbs
---------- ------------------------------ ---------- ----------
5 PDBAVT2 READ WRITE NO
SQL> ALTER PLUGGABLE DATABASE PDBAVT2 CLOSE IMMEDIATE;
Pluggable database altered.
SQL> DROP PLUGGABLE DATABASE PDBAVT2 INCLUDING DATAFILES;
Pluggable database dropped.
Clone PDB

Backup y recuperación PDBs
RMAN> BACKUP PLUGGABLE DATABASE PDBMEET2;
Starting backup at 16-APR-20
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=69 instance=MEETDB1 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00016
name=+DATA/MEETDB/A3678C44EE067C86E053700013AC2EAC/DATAFILE/sysaux.348.1037884521
name=+DATA/MEETDB/A3678C44EE067C86E053700013AC2EAC/DATAFILE/system.347.1037884519
name=+DATA/MEETDB/A3678C44EE067C86E053700013AC2EAC/DATAFILE/undotbs1.346.1037884519
channel ORA_DISK_1: starting piece 1 at 16-APR-20
channel ORA_DISK_1: finished piece 1 at 16-APR-20
piece
handle=+RECO/MEETDB/A3678C44EE067C86E053700013AC2EAC/BACKUPSET/2020_04_16/nnndf0_tag20200416t
132312_0.315.1037884993 tag=TAG20200416T132312 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 16-APR-20
Backup

RMAN> ALTER PLUGGABLE DATABASE PDBMEET2 CLOSE IMMEDIATE;
Statement processed
-- Desde asmcmd
ASMCMD> rm -f +DATA/MEETDB/A3678C44EE067C86E053700013AC2EAC/DATAFILE/sysaux.348.1037884521
-- Intentamos arrancar la PDB
SQL> ALTER PLUGGABLE DATABASE PDBMEET2 OPEN READ WRITE;
ALTER PLUGGABLE DATABASE PDBMEET2 OPEN READ WRITE
*
ERROR en linea 1:
ORA-01157: no se puede identificar/bloquear el archivo de datos 16 - consulte el archivo de
rastreo del DBWR
ORA-01110: archivo de datos 16:
'+DATA/MEETDB/A3678C44EE067C86E053700013AC2EAC/DATAFILE/sysaux.348.1037884521'
Borrado de un Datafile

RMAN> run {
RESTORE PLUGGABLE DATABASE PDBMEET2;
RECOVER PLUGGABLE DATABASE PDBMEET2;
ALTER PLUGGABLE DATABASE PDBMEET2 open;
}2> 3> 4> 5>
Starting restore at 16-APR-20
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
...
Finished restore at 16-APR-20
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 16-APR-20
Statement processed
Restore de la PDB

Snapshot Database
• La tecnología Snapshot nos permite programar un
Snapshot de una PDB de forma automática.
• Por defecto, el número máximo de Snapshots es
de 8.
• Podemos borrar los Snaps de forma manual así
como crearlos.
GL-2GL GL-3
Original
PDB Snap
of PDB
New
Seed
PDB New PDB
From Seed

Snapshot Database
SQL> ALTER SESSION SET CONTAINER = PDBMEET2;
Sesion modificada.
SQL> ALTER PLUGGABLE DATABASE SNAPSHOT MODE EVERY 5 MINUTES;
CON_ID PDB_NAME SNAPSHOT_MODE SNAPSHOT_INTERVAL
---------- ---------- --------------- -----------------
2 PDB$SEED MANUAL
3 PDBMEET1 MANUAL
4 PDBMEET2 AUTO 5
-- Comprobamos cuantos Snaps tenemos por Default
CON_ID PDB_NAME PROPERTY_NAME PROPERTY_VALUE DESCRIPTION
---------- ---------- -------------------- --------------- ----------------------------------
----------------
4 PDBMEET2 MAX_PDB_SNAPSHOTS 8 maximum number of snapshots for a
given PDB
Creación de una política de Snap

Flashback Pluggable Database (PDB)
Sesion modificada.
SQL> CREATE RESTORE POINT PDBMEET1_BEFORE_CHANGES;
Punto de restauracion creado.
Sesion modificada.
SQL> ALTER PLUGGABLE DATABASE PDBMEET1 CLOSE;
SQL> CREATE CLEAN RESTORE POINT PDBMEET1_CLEAN_RESTORE_POINT;
Creación de un Restore Point Normal
Creación de un Clean Restore Point

SQL> CREATE CLEAN RESTORE POINT PDBMEET1_CLEAN_RESTORE_POINT FOR PLUGGABLE DATABASE PDBMEET1;
Sesion modificada.
SQL> CREATE CLEAN RESTORE POINT PDBMEET1_CLEAN_RESTORE_POINT_GUAR FOR PLUGGABLE DATABASE
PDBMEET1 GUARANTEE FLASHBACK DATABASE;
Creación de un Restore Point desde el contenedor
Creación de un Restore Point desde el contenedor con GUARANTEE

• El Flashback de una PDB lo tenemos que hacer hacia un Clean Restore Point por lo que
necesariamente tendremos que parar la PDBs para realizar es punto de restauración.
• La utilización de esta tecnología implica que el UNDO no sea local para cada una de las DDBBs
SQL> FLASHBACK PLUGGABLE DATABASE PDBMEET1 TO RESTORE POINT PDBMEET1_CLEAN_RESTORE_POINT;
Flashback terminado. *
SQL> ALTER PLUGGABLE DATABASE PDBMEET1 OPEN RESETLOGS;
Flashback desde un Clean Restore Point

Oracle Multitenant: Patch & Update

Oracle Database PSU Apply (Out of Place)
• En una arquitectura tradicional tendríamos múltiples Bases de Datos sobre un
único Oracle Home. A estas Bases de Datos se pretende aplicar un PSU con el
mínimo de DownTime y en distintas ventanas de mantenimiento.
• Para este propósito crearemos un nuevo ORACLE_HOME y aplicaremos el PSU.
• El siguiente paso será ir moviendo una por una las Bases de Datos y aplicando los
SQLs correspondientes.
• Esto nos garantizara un mínimo de parada y elimina la necesidad de parar todas
las Bases de Datos al mismo tiempo.
12.2.0.2
12.2.0.2 +
PSU

Oracle Database PSU Apply (Out of Place) Multitenant
• En una arquitectura Multitenant la necesidad sería la misma: Poder
aplicar un parche o actualización con el mínimo tiempo de parada y en
distintas ventanas de mantenimiento.
• Si el container reside sobre un ORACLE_HOME, como podríamos
conseguir este objetivo ?
• Para poder garantizar las mismas condiciones de parcheo que en una
arquitectura tradicional, volveremos a recurrir a Out of Place
• El primer paso para cumplir este propósito será la creación de un
nuevo ORACLE_HOME con los parches y actualizaciones aplicados.
• Lo siguiente que haremos será la creación de una CDB vacía y con
los parches aplicados
CRMPricing Retail
ORACLE_HOME 12.2.0.1
ORACLE_HOME 12.2.0.1 + PSU

• l siguiente paso será el movimiento de cada una de las PDBs al nuevo
contenedor en sus respectivas ventanas de mantenimiento.
• Una vez movido la PDB por procedimiento UNPLUG & PLUG es
necesario aplicar los SQLs una vez por cada una de las PDBs.
• El procedimiento de UPLUG & PLUG es inmediato ya que no
movemos los Datafiles solo el metadato
CRMPricing Retail

• Una vez que terminemos de mover todas las PDBs ya podremos
borrar el contenedor inicial.
• Este proceso de parcheo tiene alguna consideraciones a tener en
cuenta:
 Tras mover la PDB es necesario recrear el servicio en la capa de
Grid Infraestructure.
 Este procedimiento no requiere almacenamiento adicional.
 El proceso de marcha atrás es tan simple como volver a llevar la
PDB el contenedor de origen.
 Este proceso permite realizar una primera prueba mediante del
clone vía DB_LINK.
CRMPricing Retail

Ángel Freire R
Principal Solution Architect
Angel.freire@avanttic.com
+34 653 356 411

Oracle Multitenant Technical Deep Dive Webinar

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Oracle Multitenant Technical Deep Dive Webinar

Similar to Oracle Multitenant Technical Deep Dive Webinar (20)

More from avanttic Consultoría Tecnológica

More from avanttic Consultoría Tecnológica (20)

Recently uploaded

Recently uploaded (10)

Oracle Multitenant Technical Deep Dive Webinar