3TC Presentacion 2021 MigracionesMInimoTiempo19c

Our mission is to help people see
data in new ways, discover insights,

unlock endless possibilities.
Migraciones a 19c con mínimo tiempo de parada.
Junta de Andalucía
Paola Juárez Gómez

Oracle Advanced Support Engineer
Septiembre 2021
Oracle Database 19c Administrator Certified Professional
Oracle Database 12c Maximum Availability Certified Expert
Oracle Cloud Infrastructure 2020 Certified Architect Associate
Oracle Autonomous Database Cloud 2020 Certified Specialist
Click to add image Oracle Certified Expert, Oracle Database 12c: RAC and Grid Infrastructure
Oracle Certified Expert, Oracle Database 12c: Data Guard Administrator
Oracle Certified Associate, Oracle WebLogic Server 12c Administrator
Remoto desde Utrera (Sevilla)
4
Agenda
Introducción
Estrategias de Migración. Buenas practicas y casos de éxito.
1. Dataguard
2. Dataguard Rolling Upgrade
3. TTS / FTEX
4. xTTS / Cross Platform tablespace + Incrementales
5. Golden Gate
5
Agenda
Introducción
1. Dataguard
3. TTS / FTEX
5. Golden Gate
6
Upgrade vs Migración
Upgrade Migración
• No se mueven datos • Hay movimiento de datos
• Independiente del tamaño
7
Numeración de las nuevas versiones
8
Tipos de “releases”. Long Term Support vs Innovation
9 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

Actualizaciones
de Base de datos
¿ Por qué Migrar?
10
Versiones de base de datos y tiempos de soporte hasta 19c
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
11.2.0.4 EXTENDED MDS Jan 2021: 11gR2 in Sustaining Support
12.1.0.2 EXTENDED
Dec 2020-Mar 2022: Limited Error Correction
12.2.0.1 (Severity 1 and Security Updates only)
12c release family 18c (12.2.0.2)
19c (12.2.0.3) EXTENDED1
Oracle 21
Waived Paid
Premier Support Extended Support 1 Oracle Database 19c is the long term support release.
Extended Support Fee
Always check My Oracle Support
Limited Error My Oracle Support Note 742060.1 for the latest schedule.
Correction
11
Políticas de Soporte
Bug fixing support regardless of severity
Extra cost extension, 10% / 20% extra cost

Included in ULA/PULA contracts
Extended support gets waived to everybody

having a valid Support contract for the product
Extra cost extension after Extended Support

Fixes done only for critical and security issues
Extension for Oracle 12.2.0.1 at no extra cost

Only applicable for Sev.1 and security issues
Oracle Support assists as long as the customer

is using the product – but no new fixes will be delivered
12
13
¿ Por qué seguimos hablando de la version 19c?
https://docs.oracle.com/en/database/oracle/oracle-database/19/ntqrf/desupported-features-for-oracle-
database-19c.html#GUID-9FA3DE19-5B7B-4A87-832D-CA85242C3FAE

Políticas Soporte Oracle
https://www.oracle.com/support/lifetime-support/index.html
Database, FMW, Enterprise Manager, TimesTen In-Memory Database, and OCS Software Error
Correction Support Policy (Doc ID 209768.1)
15
Upgrade Directo
16
Upgrade en 2 pasos.
Origen Intermedio Destino

12.1.0.1 12.1.0.2 / 12.2.0.1 / 18.x 19c
11.2.0.1 a 11.2.0.4 11.2.0.4 19c
11.1.0.6 a 11.1.0.7 11.2.0.4 19c
10.2.0.2 a 10.2.0.5 11.2.0.4 / 12.1.0.2 19c
10.1.0.5 11.2.0.4 / 12.1.0.2 19c
≦ 9.2.0.8 11.2.0.4 19c
DBUPGRADE & DBUA & AutoUpgrade
17
Basicos | Parcheo vs Upgrade
18
¿Cuándo utilizar RUs o RURs?
La bases de datos en producción inicialmente utilizarán el ultimo RU para alcanzar una estabilización
más rápida
• Los RUs consolidan parches para los problemas más comunes encontrados, y Oracle los prueba de
forma exhaustiva en conjunto antes de publicarse
Cuando se alcanza la estabilidad en producción, se cambia a RURs
• Los RURs contienen principalmente el contenido de los RU, que se ha probado ya ampliamente y un
tiempo suficiente, y las correcciones a las regresiones que se hayan encontrado en ese periodo
Production Q1 Q2 Q3 Q4 Q5
19.1.0 19.2.0 19.3.0 19.4.0 19.5.0 19.6.0
19.2.1 19.3.1 19.4.1 19.5.1
19.2.2 19.3.2 19.4.2
19
Ejemplo de Timeline| 2022
20
Tradicional VS Multitenant
Oracle “depreco” la arquitectura tradicional desde la versión 12c.
Según la documentación actual está arquitectura se “desoporta” a partir de la versión 20.
• Deprecada= No se invierte en mejoras , pero se da soporte.
• Desoportada= Fuera de soporte.
La arquitectura tradicional estaría soportada hasta la 19c , cuya fecha fin de soporte es
Marzo de 2023 o Marzo de 2026 si incluimos el soporte extendido.
https://docs.oracle.com/database/121/UPGRD/deprecated.htm#BABDBCJI
Estas fechas, son susceptibles de cambio https://www.oracle.com/us/assets/

lifetime-support-technology-069183.pdf
A partir de la versión 19c se permite el uso de hasta 3 PDBs sin coste adicional.
https://docs.oracle.com/en/database/oracle/oracle-database/19/dblic/
Licensing-Information.html#GUID-0F9EB85D-4610-4EDF-89C2-4916A0E7AC87
21
Migración a 19c
¿Cuál es la mejor opción?
22
¿Cuál es la mejor opción para migrar?
Depende de:
• Downtime
• Version destino
• Si existe cambio de Endian
• Si existe cambio de Hardware
• Si cambiamos de Non-CDB a CDB/PDB
• Si existe cambio de Character Set
23
Depende de:
• Downtime
• Version destino
24
Depende de:
• Downtime
• Version destino
25
Depende de:
• Downtime
• Version destino
26
Depende de:
• Downtime
• Version destino
• Si existe cambio de Hardaware
27
Depende de:
• Downtime
• Version destino
• Si existe cambio de Hardaware
28
Upgrade vs Migración vs Parcheo
29
Upgrade vs Migración vs Parcheo
30
¿Cuánto tardará en realizarse mi upgrade?
A tener muy en cuenta!

• Numero de componentes instalados
• Tamaño y complejidad del diccionario
Afectara igualmente:
• velocidades CPU y disco
• SGA/PGA
No esta directamente relacionado:

• Cantidad de datos de usuario
31
Opciones Upgrade / Migración.
Upgrade
exp/imp, expdp/impdp
CTAS, COPY, SQL Loader
N ¿Same SO? S
413484.1
N Downtime >30’
SQL Apply &
Transient Standby
S
Transportable Tablespaces
Full Transportable Export/Import

DBUA
CLI Auto
Upgrade
Oracle Golden Gate $> catctl.pl
tool
32
Estrategias de Migración
• Data Pump
• Transportable Tablespaces
• Full Transportable Export/Import
• Data Guard
• Incremental Backups
• Oracle GoldenGate
33
34
Pre Migración | Buenas Practicas
Reparar todos los objetos INVALID ANTES de la actualización/migración
No debe haber objetos inválidos en los esquemas de los usuarios SYS y SYSTEM
Antes de actualizar, se debe recompilar los objetos inválidos con utlrp.sql
SQL> select unique OBJECT_NAME, OBJECT_TYPE, OWNER

2 from DBA_OBJECTS
3 where STATUS='INVALID';
Hay que tratar de reparar todos los componentes NO VALID ANTES de la actualización/migración
Si utlrp.sql no corrige el estado del componente:
Information On Installed Database Components (Doc ID 472937.1)

How to diagnose Components with NON VALID status (Doc ID 753041.1)
SQL> select substr(COMP_ID, 1,10) compid,

2 substr(COMP_NAME,1,24) compname, STATUS, VERSION
3 from DBA_REGISTRY
4 where STATUS<>'VALID';

Actualizar estadísticas de diccionario

Health Check | hcheck.sql
Si se va a realizar una migración de un entorno productive se recomienda realizar un heath

check previo. Este script es no-intrusive y revisa la consistencia del diccionario
hcheck.sql - Script to Check for Known Problems (Doc ID 136697.1)

Validación Integridad de los datos
RMAN> backup check logical validate database;

39
40
41
Rendimiento
“Es fundamental recopilar suficiente información antes de la actualización”
Suficiente significa: Comenzar al menos un mes antes
Obtención de estadísticas significativas del entorno de producción

Statspack / AWR [FAQ- Statspack Complete Reference (Doc ID 94224.1)]
• Snapshots cada 30-60 minutos, y una retención de mínimo 40 días
• Generar reports de momentos significativos para poder comparar el rendimiento tras la
actualización
Preservar las estadísticas del CBO en la actualización [MOS 465787.1]
42
Agenda
Introducción
1. Dataguard
3. TTS /FTEX
4. TTS/FTEX incrementales
5. Golden Gate
43
Agenda
Introducción
1. Dataguard
3. TTS / FTEX
5. Golden Gate
44
Data Guard
45
Data Guard
Ventajas Consideraciones
• Método preferido si hay cambio de hardware con • No válido para cross-Endian

misma Plataforma y mantenemos la versión. • Cross-platform*. Data Guard Support for
• Rapido y simple Heterogeneous Primary and Physical Standbys in Same
Data Guard Configuration [ID 413484.1]
• Se evita consumir el tiempo de “copy”
• Se puede testear las veces que se desee.
• Independiente del almacenamiento: File system,
ASM, etc.
Documentación:
• Oracle 19c Data Guard Concepts and Administration

Data Guard | Migración
RMAN> DUPLICATE TARGET DATABASE

FOR STANDBY
FROM ACTIVE DATABASE ...


Data Guard | Buenas Practicas
Antes de realizar el switchover, validar el entorno final. Podemos incluso abrir la base de datos en modo read-write
( snapshot standby)
Configurar Transparent Client Failover.
Transparent client failover . How To Configure Client Failover For Data Guard Connections Using
Database Services (Doc ID 1429223.1)
How To Configure Client Failover For Data Guard Connections Using Database Services (Doc ID
1429223.1)

Data Guard | Información adicional
MOS Note: 273015.1

Migrating to RAC using Data Guard
MOS Note: 413484.1
DG Support for Heterogeneous Primary and Physical Standbys in Same DG Configuration
MOS Note: 1079563.1
RMAN DUPLICATE/RESTORE/RECOVER Mixed Platform Support
MOS Note: 2439602.1
Implement Standby in OCI (Bare Metal) and how to gather diagnostic information for any failure
MOS Note: 881421.1
Using Active Database Duplication to Create Cross Platform Data Guard Setup (Windows/Linux)
MOS Note: 1617946.1
Creating a Physical Standby using RMAN Duplicate (RAC or Non-RAC)
MOS Note: 1055938.1
Migrating from HP Oracle Database Machine to Sun Oracle Database Machine 11.2 using Data Guard

Rolling Upgrades with
Transient Logical Standby
52
Rolling Upgrade | Transient Logical Standby
• Hacemos uso de nuestra standby fisica para realizar • No válido para cross-Endian
el upgrade. • Cross-platform*. Data Guard Support for
• Reducimos el tiempo de parada a menos de 10 Heterogeneous Primary and Logical Standbys in
min* Same Data Guard Configuration [ID 1085687.1]
• Útil para tareas de mantenimiento. • Se usa log miner (SQL Apply)
• Exiten tipos de datos NO soportados en 19c :
• ROWID, UROWID
• Nested tables
• Objects with nested tables
• Identity columns
• Tipos de particionamiento NO soportados en 19c:
Documentación:
• System
Oracle 19c Data Guard Concepts and Administration • Reference

Rolling Upgrade | Tipos de standby
• Redo apply • SQL apply

• Actualización realizada actualizando los bloques • Actualización realizada ejecutando las SQL
• Copia exacta bloque a bloque • Copia exacta tabla a tabla

RMAN> DUPLICATE TARGET DATABASE

FOR STANDBY
FROM ACTIVE DATABASE ...
11.2.0.4 11.2.0.4
19.X


Transient Logical Standby - Workflow
1 Guaranteed
Restore Point
2
Logminer
PROD Build PROD PROD
SWITCHOVER
synchronize
synchronize
synchronize
5 6
PSTBY
PROD
LSTBY LSTBY
New $OH
+
KEEP IDENTITY Upgrade
58
Transient Logical Standby - Workflow
Guaranteed FLASHBACK CONVERT TO

Restore Point DATABASE TO ... PHYSICAL
New $OH
PROD PSTBY PROD
SWITCHOVER
synchronize
= UPGRADE
PROD PROD PSTBY
59
Opciones Actualización / Migración standby
Upgrade
exp/imp, expdp/impdp
CTAS, COPY, SQL Loader
N ¿Same SO? S
413484.1
N Downtime >30’
SQL Apply &
Transient Standby
S
Transportable Tablespaces
Full Transportable Export/Import

DBUA
CLI Auto
Upgrade
Oracle Golden Gate $> catctl.pl
tool
60
AutoUpgrade tool
START 1. DOWNLOAD. 2. CONFIG 3. DEPLOY SUCCESS
Versiones de origen soportadas:

• 11.2.0.4
• 12.1.0.2
• 12.2.0.1
• 18
• 19
Valido para todas las arquitecturas (CDB y non-CDB)
Valido para todos los sitemas operativos
Valido para todas las ediciones (SE2, EE)
Valido para todas las configuraciones (single instance and RAC)
61
AutoUpgrade tool
Descargarse el software desde la siguiente nota:

AutoUpgrade Tool ID 2485457.1
62
AutoUpgrade tool
Realizar la configuración básica:
upg1.source_home=/u01/app/oracle/product/12.2.0.1
upg1.target_home=/u01/app/oracle/product/19
upg1.sid=CDB1
63
AutoUpgrade tool
Ejecutar:
$ java -jar autoupgrade.jar -config cdb1.cfg -mode deploy
Existen opciones avanzadas de monitorización y logging
64
AutoUpgrade tool
Versiones destino soportadas:
• 12.2.0.1
• 18
• 19
• 21
• Versiones posteriores
65
AutoUpgrade tool
66
AutoUpgrade tool
Herramienta de línea de comando que se introduce en 19c

Emplea un fichero de configuración para realizar estas tareas
Funcionamiento:
• Ejecuta los prechecks sobre múltiples bases de datos
• Resuelve el 99% de los problemas potenciales
• Establece un restore point por si algo va mal
• Actualiza las bases de datos
• Realiza la tareas de postupgrade, recompilado y ajuste de time zone
67
Automatizar el “Rolling Upgrade” | Opciones
Rolling Upgrade Shell Scripts
• “Physru”. ID 949322.1 Database Rolling Upgrade • Se require la funcionalidad Active Data Guard
Shell Script
• Se necesita tener Enterprise Edition (EE)
• El origen debe ser >= 11.1.0.7

Validar la migración en un entorno de test. Casos de uso, rendimiento, etc
Hacer pruebas y seleccionar el método de Upgrade que más nos convenga. Se recomienda validar el procedimiento
AutoUpgrade. ID 2485457.1
Reparar objetos DUPLICADOS en SYS/SYSTEM antes de actualizar. How to Clean Up Duplicate Objects Owned by
SYS and SYSTEM Schema ID 1030426.6
Antes de realizar el switchover, validar el entorno final. Podemos incluso abrir la base de datos en modo read-write
( snapshot standby)

Revisar que los registros están identificados de forma única y que no existen tipos de datos NO soportados:
SQL> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE WHERE (OWNER,

TABLE_NAME) NOT IN (SELECT DISTINCT OWNER, TABLE_NAME FROM
DBA_LOGSTDBY_UNSUPPORTED) AND BAD_COLUMN = 'Y';
no rows selected


no rows selected
✓ Si existieran datos no soportados de forma nativa, existen tres opciones:

1. Evitar cambios en esos tipos de datos durante el procedimiento
2. Intentar minimizar los cambios y una vez finalizado el procedimiento importar los cambios no registrados de la
tabla DBA_LOGSTDBY_EVENTS
3. Usar EDS (Extended Datatype Support). Ver nota 949516.1


no rows selected



no rows selected

2. Intentar minimizar los cambios y una vez finalizado el procedimiento importar los cambios no registrados de
la tabla DBA_LOGSTDBY_EVENTS


no rows selected


Caso de Uso Junta de Andalucía
O11PRD O11PRD
DOWNTIME <= 30 Minutos
La base de datos O11PRD se migró de 11.2 a 12.2 usando Transient Logical Rolling Upgrade con Dataguard en
enero del 2019.
Durante el procedimiento seguido en RTVA se realizaron dos switchover :
• El primer switchover y migración del servicio a 12c, se realizó el lunes 14 de enero a las 8.30.
• El segundo switchover, para volver a dar servicio desde la maquina original, se realizó el 22 de enero a las
9:00.
Contacto: JOSE MANUEL LOPEZ DEL TORO <jmlopezt@rtva.es>

75
Rolling Upgrade | Información adicional
White pappers:
Transient Rolling Upgrade Using DBMS_ROLLING - Beginners Guide

Oracle Database Rolling Upgrades Using a Data Guard Physical Standby Database
Notas MOS:
Rolling upgrade using DBMS_ROLLING - Complete Reference (Doc ID 2086512.1)

MAA Whitepaper: SQL Apply Best Practices (Doc ID 1672310.1)
Step by Step How to Do Swithcover/Failover on Logical Standby Environment (Doc ID 2535950.1)
How To Skip A Complete Schema From Application on Logical Standby Database (Doc ID 741325.1)
Handling ORA-1403 ora-12801 on logical standby apply (Doc ID 1178284.1)

77
Transportable Tablespaces ( TTS)
Full Transportable Export/Import (FTEX)
78
Concepto TTS / FTEX
75TB 75TB
79
Concepto TTS / FTEX
Autocontenido?
Read Only
75TB 75TB
80
Concepto TTS / FTEX
expdp "'"sys/sys as sysdba"'" …

TRANSPORT_TABLESPACES=TS1,TS2 …
75TB 75TB
81
Concepto TTS / FTEX
impdp "'"sys/sys as sysdba"'"…

TRANSPORT_DATAFILES=…
75TB 75TB
82
Concepto TTS / FTEX
Read Write
75TB 75TB
83
Conceptos TTS / FTEX
TTS FTEX
TTS desde Oracle 8i FTEX export soportado desde la version Oracle 11.2.0.3
xTTS desde 10g FTEX import soportado desde la version 12.1.0.1
• Es necesarios explicitamente indicar el nombre de • Transporta la base de datos completa, ya no es necesario

todos los tablespaces que se quieren transportar. el requisito ”self-contained”
• Se requiere de trabajo adicional si se quieren FULL=Y TRANSPORTABLE=ALWAYS
mover objetos de los tablespaces SYSTEM/SYSAUX.
• Cross version, cross platform, 32-bits 64 bits, cross

endian*.
• Cross version, cross platform, 32-bits 64 bits, cross
endian*.
• Soportado para components como Spatial, Text,
Multimedia, OLAP, etc y adaptado a arquitectura
Multitenant
Diferencias TTS / FTEX
Recomendado para mover datos en los siguientes niveles:
• Database
Se recomienda usar la funcionalidad full transportable export/import (FTEX) para mover/migrar una base
de datos completa
• Tablespaces
Se recomienda usar TTS para mover un conjunto de tablespaces entre distintas bases de datos.
• Tablas , particiones o subparticiones

Se recomienda usar TTS para mover un conjunto de tablas, particiones o subparticiones entre distintas
bases de datos.
85
Concepto TTS / FTEX

Concepto TTS / FTEX
Cómo movemos los datafiles?
CP RMAN
• Movemos los datafiles desde la maquina origen al Usamos RMAN para mover los datafiles.
destino.
• El tablespace tiene que estar en read only, Opciones RMAN:
afectando al dowtime.
• BackupSets
• Image copies.

Conceptos RMAN
Cómo movemos los datafiles con RMAN?
Backupsets Image Copies

Concepto TTS / FTEX Incremental Backup
SOURCE Database 11.2.0.4 DESTINATION Database 19c

VIEWS
SYSTEM CODE
SYSTEM
SYSAUX SYSAUX
SCOTT
UNDO UNDO
TEMP
PRIVS
TEMP
HUGO
89

VIEWS
SYSTEM CODE
SYSTEM
SYSAUX SYSAUX
SCOTT
UNDO UNDO
TEMP
PRIVS
TEMP
HUGO
90

VIEWS
SYSTEM CODE
SYSTEM
SYSAUX SYSAUX
SCOTT
UNDO UNDO
TEMP
PRIVS
TEMP
HUGO
91

VIEWS
SYSTEM CODE
SYSTEM
SYSAUX SYSAUX
SCOTT
UNDO UNDO
TEMP
PRIVS
TEMP
HUGO
92

VIEWS
SYSTEM CODE
SYSTEM
SYSAUX SYSAUX
SCOTT
UNDO UNDO
TEMP
PRIVS
TEMP
HUGO
93

VIEWS
SYSTEM CODE
SYSTEM
SYSAUX SYSAUX
SCOTT
UNDO UNDO
TEMP
PRIVS
TEMP
HUGO
94
¡Downtime!
Read Only VIEWS
SYSTEM CODE
SYSTEM
SYSAUX SYSAUX
SCOTT
UNDO UNDO
TEMP
PRIVS
TEMP
HUGO
95
¡Downtime!
Read Only VIEWS Read Write VIEWS
SYSTEM CODE
SYSTEM
CODE
SYSAUX SYSAUX
SCOTT SCOTT
UNDO Data Pump UNDO
TEMP
PRIVS
TEMP PRIVS
HUGO HUGO
96
Migración de Non CDB a PDB con FTEX
▪ Creamos PDB nueva

▪ Creamos un dblink al origen PDB$ PDB Database Link
SEED
▪ Ponemos los Tablespaces read-only – downtime! 1 impdp
Copiamos los datafiles al destino

▪
CDB
▪ Ejecutamos impdp sobre NETWORK_LINK
impdp oow/passwd@PDB1 Read Only

NETWORK_LINK=DB1 VERSION=12 FULL=Y TRANSPORTABLE=ALWAYS
METRICS=Y LOGFILE=oow_dir:src112fullimp.log
TRANSPORT_DATAFILES='/oradata/ts1.dbf' … DB1
97
TTS y FTEX incrementales | Buenas Practicas
TTS --> Flexible, metodo de migración cross-platform cuando la base de datos origen es < 11.2..0.3 y la base de
datos destino es < 12c.
FTEX--> Flexibilidad y sencillez, cuando en la migracion cross-platform la base de datos origen es >= 11.2.0.3 y el
destino es >= 12c.
Configurar Block Change tracking para realizar los backups incrementales
Para versiones >= 12c user NETWORK_LINK para ahorrarnos el expdp
Usar una standby como origen de los ficheros en caso de que el Origen este muy alejado del entorno destino.
Transportable tablespace on standby. Id 788176.1

Si estamos realizando FTEX y la version origen en menor a 12, es neceario usar el parámetro VERSION=12
$ expdp system/manager full=y transportable=always version=12 \
directory=dp_dir dumpfile=full_tts.dmp \
metrics=y exclude=statistics \
encryption_password=secret123word456 \
logfile=full_tts_export.log
FTEX no transporta el repositorio XDB o las estadisticas AWR.

Realizar el EXPDP con EXCLUDE=TABLE_STATISTICS,INDEX_STATISTICS

MOS Note:1517267.1 – TTS Using Datapump Expdp and Impdp Exports Statistics Despite Setting
EXCLUDE=STATISTICS
Lanzar estadísticas del diccionario de datos y de la base de datos al finalizar el TTS.

Gathering Dictionary Statistics Post TTS Import to Improve Statistics Table Import Performance: What Specific
Tables to Gather Statistics On, Rather Than Gathering Statistics on All Tables (Doc ID 2452739.1)
exec dbms_stats.gather_table_stats('SYS','TABPART$');
exec dbms_stats.gather_table_stats('SYS','TABCOMPART$');
exec dbms_stats.gather_table_stats('SYS','OBJ$’);
exec dbms_stats.gather_index_stats('SYS','I_FILE#_BLOCK#');
exec dbms_stats.gather_index_stats('SYS','I_OBJ2');
exec dbms_stats.gather_index_stats('SYS','I_DEPENDENCY2');
exec dbms_stats.gather_index_stats('SYS','I_OBJ#');
Transportable Tablespace Method Does Not Transport Global Temporary Tables (Doc ID 2369318.1)
"You cannot transport the SYSTEM tablespace or objects owned by the user SYS.”
Una vez finalizado el TTS compilar todos los objetos en destino.

SQL> connect / as sysdba
@?/rdbms/admin/utlrp.sql
Si existen vistas materializadas revisar la siguiente nota How to Handle Materialized Views When You Upgrade or
Clone a Database (Doc ID 1406586.1)
TTS y FTEX | Información adicional
Best Practices for Using Transportable Tablespaces (TTS) (Doc ID 1457876.1)
Upgrading a Database Using Transportable Tablespaces (TTS) (Doc ID 1457743.1)
Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where
Applicable (Doc ID 1454872.1)
Master Note for Transportable Tablespaces (TTS) -- Common Questions and Issues
(Doc ID 1166564.1)
Escenario Real - Amadeus Customer Case

http://www.oracle.com/technetwork/database/features/availability/s281209-amadeus
130978.pdf
cross Platform
Transportable Tablespaces (xTTS)
12c Cross-Platform Data Transport
103
Cambio de Plataforma con distinto Endian
SQL> SELECT platform_name, endian_format FROM v$transportable_platform

WHERE endian_format!='Little’;
PLATFORM_NAME ENDIAN_FORMAT
____________________________________ ________________
AIX-Based Systems (64-bit) Big
Apple Mac OS Big
HP-UX (64-bit) Big
HP-UX IA (64-bit) Big
IBM Power Based Linux Big
IBM zSeries Based Linux Big
Linux OS (S64) Big
Solaris[tm] OE (32-bit) Big
Solaris[tm] OE (64-bit) Big
Cross platform support

LITTLE ENDIAN • V$TRANSPORTABLE_PLATFORM
PLATFORMS
HP IA Open VMS
HP Open VMS FILE RMAN BIG ENDIAN PLATFORMS
HP Tru64 UNIX
Linux IA (32-bit) CONVERT HP-UX (64-bit)

Linux IA (64-bit)
COPY
HP-UX IA (64-bit)
Linux x86 64-bit
FILE AIX-Based Systems (64-bit)
Microsoft Windows IA (64-bit) IBM zSeries Based Linux
DBMS_FILE_TR IBM Power Based Linux
Microsoft Windows x86 64-bit
Microsoft Windows IA (32-bit) ANSFER
COPY Solaris[tm] OE (32-bit)
Solaris[tm] OE (64-bit)
Solaris Operating System (x86)
Solaris Operating System (x86-64)
• You cannot transport an encrypted tablespace to a platform with different endianness. 106
RMAN Convert
• Crea un “file copy”
• Tarda casi el mismo tiempo que un backup y necesita espacio de almacenamiento.
• Se puede configurar varios canales.
• Podemos realizar convert database, tablespace o datafile.
• Se puede realizar en origen o en destino , se recomienda en destino.
RMAN> CONVERT TABLESPACE users,example
TO PLATFORM 'Linux IA (32-bit)'
FORMAT='/stage/transport_linux/%U‘;
RMAN> CONVERT TABLESPACE users,example

FROM PLATFORM 'Linux IA (32-bit)'
FORMAT='/stage/transport_linux/%U‘;
108
DBMS_FILE_TRANSFER
• Usa un dblink
• Realiza conversión implícita en 11.2.0.4 y <=12
• No requiere espacio de almacenamiento
• Es más lento en general
• Máximo tamaño de fichero permitido 2Tb
109
Opciones disponibles migración mínimo tiempo de parada
¿Qué metodo uso?
Platform Migration Using TTS 11.1

¿Mismo Endian?
N S
413484.1: “Data Guard Support for
v origen 11.1
xTTS N Heterogeneous Primary and Standby
Systems in Same Data Guard
v destino >=12.1
v origen >=12.1 Configuration”
v origen >=11.2.0.4 Cross-Platform Transport of Tablespaces Using

Inconsistent Backups
11G - Reduce Transportable
Tablespace Downtime using Cross 395982.1: “Data Guard
12c How Perform Cross-Platform Database Support for Mixed HP
Platform Incremental Backup (Note Transport to different Endian Platform with S
1389592.1) PARISC 64-bit and HP
RMAN Backup Sets (Doc ID 2013271.1) Itanium Environments”
$> catctl.pl
12C - Reduce Transportable
Tablespace Downtime using Cross Perl Scripts V4
Platform Incremental Backup (Note (Doc ID 2471245.1) Dataguard Transcient logical
2005729.1)
110
Full Transportable Export/Import con Image Copies
Rolling forward images copies
Transport with Incremental Backups | 6 Fases
Fase 1 | Configuración – Creación base de datos destino
Identificamos los tablespaces que queremos Creamos la base de datos destino:

Migrar:
• El parámetro COMPATIBLE >=
• Mismos:
✓ Database Character sets
✓ National Character sets
✓ Time zome versions*
✓ Database time zone settings*
*workaround
Fase 1 | Descargar y configurar - PERL Scripts
V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)
Phase 1 | RMAN convert
11G - Reduce Transportable Tablespace Downtime using Cross Platform

Incremental Backup (Doc ID 1389592.1)
Phase 1 | xtt.properties
Editamos el fichero xtt.properties y creamos los correspondientes directorios
Phase 2 | Realizamos Backup FULL Level-0
Phase 2 | Realizamos Conversion / Restauración del backup level-0
Phase 3 | Realizamos backup Incremental level-1
Phase 3 | Realizamos Convert/Merge del Backup Incremental level-1
Phase 3 | Repetimos backup Incremental Level-1: Backup/Convert/Merge
Phase 4 | Downtime - Read Only
¡Downtime!
Phase 4 | realizamos el ultimo Level 1: Backup/Convert/Merge
¡Downtime!
Phase 5 | Full Transportable Export/Import
¡Downtime! Precrear usuarios owner tablespaces
*TRANSPORTABLE=KEEP_READ_ONLY
Phase 6 | Validation y limpieza
Read write
Read write
RMAN> validate tablespace TS1, TS2 check logical;
Minimal Downtime Migration with Full Transportable Export Import (FTEX) and
Incremental Backups
https://www.youtube.com/watch?v=gBINDNfNIlA&t=526s
Limitaciones PERL scripts
• Revisar los nombres de los datafiles si se restauran en el mismo directorio destino

• No deben existir tablespaces gestionados por el diccionario.
• El procedimieno no permite tener multiples directorios de restauración de datafiles.
• El procedimiento reinicia la base de datos destino. NOTE: The script will shutdown and startup, in
NOMOUNT, the destination database before the --restore.
• Si temenos windows como origen o destino no podremos usar este método de migración.
• La base de datos origen debe estar en modo ARCHIVADO.
• Podemos ubicar los ficheros finales en ASM, pero los backups deben almacenarse en filesystem
• No podemos usar una Snapshot Standby como origen de datos.
• Tablespaces encriptados con TDE no pueden moverse usando este metodo, se deben migrar con
EXPDP/IMPDP
PERL scritps | Buenas Practicas
Lanzar estadísticas del diccionario y de la base de datos al finalizar el TTS.
En el caso del diccionario tener en cuenta la siguiente nota: Gathering Dictionary Statistics Post TTS Import to
Improve Statistics Table Import Performance: What Specific Tables to Gather Statistics On, Rather Than Gathering
Statistics on All Tables (Doc ID 2452739.1)
exec dbms_stats.gather_table_stats('SYS','TABPART$');
exec dbms_stats.gather_table_stats('SYS','TABCOMPART$');
exec dbms_stats.gather_table_stats('SYS','OBJ$’);
exec dbms_stats.gather_index_stats('SYS','I_FILE#_BLOCK#');
exec dbms_stats.gather_index_stats('SYS','I_DEPENDENCY2');
exec dbms_stats.gather_index_stats('SYS','I_OBJ#');
PERL scritps | Buenas Practicas
Incluir la opcion de debug cuando se ejecuta el script xttdriver

$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3
$ORACLE_HOME/perl/bin/perl xttdriver.pl --restore --debug 3
Realizar pruebas y validaciones en entorno pequeños inicialmente para conocer el procedimiento
Configurar Block Change tracking para realizar los backups incrementales más rápido
IMPDP TTS usar TRANSPORTABLE=KEEP_READ_ONLY
RDBMS 89 bases de datos

DOWNTIME <= 2:30*
31 bases de datos entornos GIRO
V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup ID 2471245.1
Migraciones con cambio de:

• Version: 11.2.0.4 a 19.5.1.0
• Plataforma: Solaris SPARC 64-bits a Linux Intel x86-64 (Big Endian- Little Endian)
• Arquitectura: Filesystem a ASM
Contactos:
Juan Jesus Perez Gomez <JJPEREZ@ayesa.com>
Peña Jaramillo, Juan Carlos <jcpena@ayesa.com>
130
Consideraciones:
Al tiempo de downtime asociado al ultimo backup incremental y la migración de metadatos hay que sumar en
el caso de CFyFE:
• Tiempo de compilación. Bases de datos complejas con dependencias entre objetos.

• Migración de tablas temporales.
• Cambio ip temporales y reconfiguraciones del clusterware necesarias.
• Configuración block_change_traking en destino.
• Cambio de contraseñas en destino.
• Pruebas disponibilidad.
• Cambio de la base de datos a archivelog.
131
Opciones disponibles migración mínimo tiempo de parada
¿Qué metodo uso?
Platform Migration Using TTS 11.1

¿Mismo Endian?
N S
413484.1: “Data Guard Support for
v origen 11.1
xTTS N Heterogeneous Primary and Standby
Systems in Same Data Guard
v destino >=12.1
v origen >=12.1 Configuration”
v origen >=11.2.0.4 Cross-Platform Transport of Tablespaces Using

Inconsistent Backups
11G - Reduce Transportable
Tablespace Downtime using Cross 395982.1: “Data Guard
12c How Perform Cross-Platform Database Support for Mixed HP
Platform Incremental Backup (Note Transport to different Endian Platform with S
1389592.1) PARISC 64-bit and HP
RMAN Backup Sets (Doc ID 2013271.1) Itanium Environments”
$> catctl.pl
12C - Reduce Transportable
Tablespace Downtime using Cross Perl Scripts V4
Platform Incremental Backup (Note (Doc ID 2471245.1) Dataguard Transcient logical
2005729.1)
132
12C Cross-Platform Data Transport
Read Only
RMAN> backup for transport format '/tmp/stage/tbs1.bkset’

datapump format '/tmp/stage/tbs1.dmp’
tablespace* tbs1;
RMAN> backup to transport 'Linux x86 64-bit'

format '/tmp/stage/tbs1.bkset’
datapump format '/tmp/stage/tbs1.dmp’
tablespace* tbs1;
12C Cross-Platform Data Transport
RMAN> restore from platform 'Solaris[tm] OE (64-bit)’ foreign

tablespace tbs1 format '/u01/app/oracle/oradata/tbs1.dbf’
from backupset '/tmp/stage/tbs1.bkset’
dump file
from backupset '/tmp/stage/tbs1.dmp’;
RMAN> restore
foreign tablespace tbs1 format
'/u01/app/oracle/oradata/tbs1.dbf’
from backupset '/tmp/stage/tbs1.bkset’
dump file
from backupset '/tmp/stage/tbs1.dmp’;
12C Cross-Platform Transport of Tablespaces Using Inconsistent Backups
RMAN > backup for transport allow inconsistent
incremental level 0 format '/refresh/backup2/datos_%U.bkp’
tablespace datos;
RMAN> restore from platform 'Solaris[tm] OE (64-bit)’

all foreign datafiles to new* from backupset
'/refresh/backup2/datos_1609rvd9_1_1.bkp’;
DESTINATION Database 19c Linux

VIEWS
SOURCE Database 11.2.0.4 Solaris
Read Write SYSTEM
SYSTEM CODE
SYSAUX SYSAUX
SCOTT
UNDO UNDO
TEMP
PRIVS
TEMP
HUGO
*db_create_file_dest 135
RMAN > backup for transport allow inconsistent
incremental level 1 format '/refresh/backup2/datos_Level1%U.bkp’
tablespace datos;
RMAN> recover from platform 'Solaris[tm] OE (64-bit)

foreign datafilecopy
'/refresh/oradata/ORCL/datafile/o1_mf_datos_jnvtlvrc_.dbf’
from backupset '/refresh/backup2/datos_Level11709rvfi_1_1.bkp' ;
DESTINATION Database 19c Linux

VIEWS
SOURCE Database 11.2.0.4 Solaris
Read Write SYSTEM
SYSTEM CODE
SYSAUX SYSAUX
SCOTT
UNDO UNDO
TEMP
PRIVS
TEMP
HUGO
*db_create_file_dest 136
RMAN > backup for transport
incremental level 1 format '/refresh/backup2/datos_Level1%U.bkp’
DATAPUMP FORMAT '/refresh/backup2/trans_ts_dmp.dmp’
tablespace datos;
RMAN> recover from platform 'Solaris[tm] OE (64-bit)’
foreign datafilecopy
'/refresh/oradata/ORCL/datafile/o1_mf_datos_jnvtlvrc_.dbf’
from backupset '/refresh/backup2/datos_Level11809rvir_1_1.bkp';
VIEWS
Read Only SYSTEM

SYSTEM CODE
SYSAUX SYSAUX
SCOTT
¡Downtime!
UNDO UNDO
TEMP
PRIVS
TEMP
HUGO
SOURCE Database 11.2.0.4 Solaris DESTINATION Database 19c Linux 137
RMAN> restore from platform 'Solaris[tm] OE (64-bit)’
dump file datapump
destination '/refresh/app/oracle/admin/orcl/dpdump’
from backupset '/refresh/backup2/trans_ts_dmp.dmp’;
impdp dumpfile=data_pump_dir:backup_tts_ORCL_82391
logfile=data_pump_dir:tts_impdp.log
transport_datafiles='/refresh/oradata/ORCL/datafile/o1_mf_datos_jnvtlvrc_.dbf';
VIEWS
Read Write
Read Only SYSTEM
SYSTEM CODE
SYSAUX SYSAUX
SCOTT
UNDO UNDO
TEMP
PRIVS
TEMP
HUGO
SOURCE Database 11.2.0.4 Solaris DESTINATION Database 19c Linux 138
12C Cross-Platform TTS | Buenas Practicas
Buena comunicación entre los servidores origen y destino
Realizar la conversión en destino , limitamos el consumo de recursos en el entorno productivo y acelearmos el

proceso porque la máquina destino suele ser más rápida.
OPAGD
DOWNTIME 1 hora*
• Migraciones de 11.1.0.7 a 19 usando xTTS + Incrementales de RMAN
• Se reutilizan backups incrementales diferenciales y acumulativos de la política de backup de RMAN de la

base de datos origen.
• Cross platform (Solaris SPARC 64-bits a Linux Intel x86-64) Big Endian- Little Endian
• Se usan scripts personalizados
140
Se descartó el uso de los scripts de PERL por requerir 11.2.0.3 como versión mínima de origen.
Otras limitaciones:
• No permite renombrar los ficheros, sino que todo lo restaura en un único directorio. No compatible con las
bases de datos del SAS.
• Durante el procedimiento se reinicia la base de datos destino. El SAS quería migrar a base de datos existentes
que ya estaban dando servicio productivo.
• No se quería interferir en la política de backup de RMAN existente del entorno origen, se reutilizan los backups
existentes en Netbackup. *Block Change Tracking sólo puede controlar los últimos 8 backups.
141
Se extrae información de la base de datos Origen: Se importa en la base de datos Destino:
• Usuarios • Profiles
• Roles • Roles
• Profiles • Usuarios
• Tablespaces por Defecto • Privilegios de Sistema
• Privilegios de Sistema • Import TTS de los tablespaces
• Se purga la DBA_RECYCLEBIN • Import sin filas de los propietarios y usuarios de aplicación
• Se comprueban los segmentos externos dependientes • Import con filas de los usuarios personales de solo lectura
• Se comprueba el Transport Set • Import sin filas de las réplicas centralizadas
• Se ponen los tablespaces en READ ONLY • Asignamos tablespaces por defecto
• Export TTS de los tablespaces • Ponemos tablespaces en READ WRITE
• Export sin filas de los propietarios y usuarios de aplicación • Refresco Full de las vistas materializadas de réplica centralizada
• Export sin filas de las réplicas centralizadas • Se crean índices de función
• Export con filas de los usuarios personales de solo lectura • Se crean tablas temporales
• Se truncan y purgan los logs de vistas materializadas
• Se realizan algunos ajustes específicos
Se realiza un último backup incremental a disco sin Netbackup ni catálogo de • Se comprueban los objetos inválidos
RMAN, que se copia por red y aplica en destino. • Se actualizan las estadísticas con histogramas AUTO y estimate percent AUTO
• Se realiza un Backup Validate
• Se realiza un Tablespace Verify
142
TTS + RMAN Incrementales | Información adicional
11G – Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.1)
12C – Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2005729.1)
12c How Perform Cross-Platform Database Transport to different Endian Platform with RMAN Backup Sets (Doc ID
2013271.1)
https://www.oracle.com/assets/full-transportable-wp-12c-1973971.pdf
19c. Transporting Data Across Platforms
Upgrade and Migrate to Oracle Database 19c
Oracle Golden Gate
144
GoldenGate | Definición
GoldenGate | Definición
Independiente de la versión/plataforma
GoldenGate
• Downtime CERO • Requiere licencia adicional, no incluido en contrato

• Flexible JdA.
• Válido para cualquier migracion • Procedimiento complejo
• Sin limitacion de versiones
• Fallback
• Active Data Guard incluye licencia OGG
Thank you !
paola.juarez@oracle.com
148

3TC Presentacion 2021 MigracionesMInimoTiempo19c

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3TC Presentacion 2021 MigracionesMInimoTiempo19c

Uploaded by

Copyright:

Available Formats

Our mission is to help people see

data in new ways, discover insights,

Paola Juárez Gómez

Remoto desde Utrera (Sevilla)

Estrategias de Migración. Buenas practicas y casos de éxito.

2. Dataguard Rolling Upgrade

4. xTTS / Cross Platform tablespace + Incrementales

Estrategias de Migración. Buenas practicas y casos de éxito.

2. Dataguard Rolling Upgrade

4. xTTS / Cross Platform tablespace + Incrementales

9 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

12c release family 18c (12.2.0.2)

19c (12.2.0.3) EXTENDED1

Extra cost extension, 10% / 20% extra cost

Extended support gets waived to everybody

Extra cost extension after Extended Support

Extension for Oracle 12.2.0.1 at no extra cost

Oracle Support assists as long as the customer

14 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

Origen Intermedio Destino

DBUPGRADE & DBUA & AutoUpgrade

Estas fechas, son susceptibles de cambio https://www.oracle.com/us/assets/

A tener muy en cuenta!

No esta directamente relacionado:

CTAS, COPY, SQL Loader

Full Transportable Export/Import

SQL> select unique OBJECT_NAME, OBJECT_TYPE, OWNER

Information On Installed Database Components (Doc ID 472937.1)

SQL> select substr(COMP_ID, 1,10) compid,

35 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

Actualizar estadísticas de diccionario

36 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

Health Check | hcheck.sql

Si se va a realizar una migración de un entorno productive se recomienda realizar un heath

hcheck.sql - Script to Check for Known Problems (Doc ID 136697.1)

37 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

Validación Integridad de los datos

RMAN> backup check logical validate database;

38 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

“Es fundamental recopilar suficiente información antes de la actualización”

Suficiente significa: Comenzar al menos un mes antes

Obtención de estadísticas significativas del entorno de producción

Preservar las estadísticas del CBO en la actualización [MOS 465787.1]

Estrategias de Migración. Buenas practicas y casos de éxito.

2. Dataguard Rolling Upgrade

Estrategias de Migración. Buenas practicas y casos de éxito.

2. Dataguard Rolling Upgrade

4. xTTS / Cross Platform tablespace + Incrementales

• Método preferido si hay cambio de hardware con • No válido para cross-Endian

• Oracle 19c Data Guard Concepts and Administration

46 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

RMAN> DUPLICATE TARGET DATABASE

48 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

49 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

Configurar Transparent Client Failover.

50 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

MOS Note: 273015.1

51 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

53 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

• Redo apply • SQL apply

54 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted

RMAN> DUPLICATE TARGET DATABASE

56 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted