Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte I )
Por Joel Pérez 
& Wissem El Khlifi 
Publicado en diciembre 2013
Indice
1. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte I )
2.
Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte II ) 3.
Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte III ) 4.
Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte IV )
“Database12c” la nueva versión de manejador de base de datos de “Oracle Corporation”, nosotros los tecnólogos Oracle nos preguntábamos “que mas…” podría Oracle adicionar como nuevas características?, de que forma Oracle nos iba a sorprender esta vez y como siempre, las nuevas características y nueva arquitectura no solo nos sorprenden sino que una vez mas nos llevan a otra era…, “Cloud Computing”…
Personalmente he tenido la oportunidad de trabajar con tecnología Oracle como DBA desde su versión 8. “8”i la era del internet, “9i” la era del internet con mayores elementos, recuerdo que uno de los componentes de mayor importancia fue la presentación de RAC9i “la era naciente de RAC…”, “10g” nos sorprendió con el concepto de ASM… y filosofía “Grid Computing”, 11g & 11g R2 sobre todo por sus mejoras de alto nivel relacionadas con RAC & Data Guard…, 12c… Cloud Computing, nuevas características… mas de 500 las cuales iremos cubriendo gradualmente a través de artículos y otros elementos de ayuda.
“Upgrade”… para mi Joel Pérez en conjunto con Wissem El Khlifi es un tanto difícil iniciar esta serie de artículos de “Upgrade” ya que esta afamada tarea posee tantas posibles direcciones, alternativas, herramientas, modos de aplicación, etc… que tuvimos que sentarnos un preciado momento en Barcelona,España para organizar como íbamos a desplegar tanto información en la menor cantidad de artículos posible.
Entremos en materia... bien podríamos afirmar que la historia de las probidades, flexibilidades y alternativas de “Upgrades” de base de datos ( BBDDs ) Oracle ha ido en aumento a través de sus versiones. Sin embargo existe un hito muy particular que dista a “Oracle Database 12c” de las versiones anteriores y son las posibilidades de gran alcance que ahora posee el manejador para operaciones de tipo “Cross-Platform” en general: Transporte de Tablespaces, Datafiles & Bases de Datos. Las alternativas de “Upgrade” a partir de “Oracle Database 12c” son mayores lo cual impacta positivamente en los clientes que desean realizar “Upgrade” de sus bases de datos sin el mayor impacto posible en sus actividades de negocios.
Si la escogencia de “paths” de “Upgrade” antes se podría haber considerado una caja de 1000 caminos ahora hay que adicionar unos 500 mas debido a que a partir de “Oracle Database 12c” no solo tenemos que pensar en el “Path” y modo de “Upgrade” sino también escoger a que nueva arquitectura iremos: Non-CDB ( “Non-Container Database” ) o PDB ( “Pluggable Database” ). Los conceptos de ambas podrán ser mayormente aclarados en nuestro articulo:
Oracle Database 12c: “Oracle Multitenant” ( Parte I ). Uno de los principalmente beneficiados en todo este proceso es el cliente, ya que el “Software” & Compania “Oracle” ha colocado en disponibilidad una vez mas un “Release” lleno de nuevas alternativas para hacer que la administración de una base de datos “Oracle” sea mas un placer que un requisito del mercado de tener lo mejor de lo mejor en manejador de BBDD.
La pregunta de los clientes siempre es basada en: “Upgrade” o no “Upgrade”…?, podríamos escribir miles de líneas al respecto pero uno de los motivos mas importantes y decisivos por lo cuales los clientes siempre deciden llevar a cabo el “Upgrade” de sus bases de datos a una nueva versión es para poder contar con las nuevas características, “Oracle Database 12c” incluye excelentes nuevos”Features” como: “Oracle Multitenant Option”, “Oracle Active Data Guard Far Sync”, mejoras en “Information Lifecycle Management”, nuevos tipos de datos y mas.
Nota: La palabra que utilizaremos a lo largo del artículo para referirnos a “Upgrade” es “Upgrade” mas no la palabra “Migracion” aunque parecen términos sinónimos, realmente en contexto “Oracle” no lo es. La palabra “Migracion” es utilizada en contexto “Oracle” para el movimiento de datos de una base de datos No-Oracle a una BBDD Oracle. Más cuando nos referimos a “Upgrade”, lo estamos realizando en un contexto de movimiento de datos de BBDDs “Oracle” a BBDDs “Oracle”.
“Database Upgrade”: el acto de llevar a cabo “Upgrades” en bases de datos “Oracle” envuelve una actividad de modificar el diccionario de datos para que el mismo sea compatible con la versión del “Oracle Database Software”. Las típicas acciones que pueden ser parte de un “Oracle Database Upgrade” son las siguientes:
- Adicionado, Borrado o modificación de columnas en tablas y vistas de “System”
- Creación de nuevos “Packages” o “Procedures”
- Modificación de “Packages” o “Procedures” de “System” existentes
- Creación, Modificación o borrado de usuarios de bases de datos, roles y privilegios
- Y modificación de “Data” particular utilizada por los “Oracle Database Components”
Todas y cada una de estas acciones afectan el diccionario de datos de la BBDD. La modificación de estos objetos no conlleva modificación de código o datos de aplicación mas si la validez de “PL/SQL Program Units” los cuales obtienen des compilación cuando se modifica el diccionario de datos. Dentro de los scripts de cambio del diccionario de datos también se encuentra un extracto que recompila los “PL/SQL Program Units” de aplicación.
“Multitenant Arquitecture”: es la nueva opción para “Oracle Database 12c Enterprise Edition” la cual ayuda a los clientes a reducir costos en el área de “IT” a través de la simplificación, consolidación, aprovisionamiento, “Upgrades” y mas. La nueva arquitectura esta basada en una base de datos “Container” la cual puede albergar muchas BBDDs ( Bases de Datos ) denominadas “Plugaggable Databases”. La arquitectura “Oracle Multitenant” es escalable y aplicable de forma total a soluciones ya conocidas como “RAC ( Oracle Real Application Clusters )” & “Oracle Data Guard”. Una simple BBDD no “Pluggable Database” o bien llamada “Non-CDB” ( “Non Container Database” ) puede ser convertida fácilmente a una BBDD “Pluggable Database” sin afectar su contenido, operación y manejo para las aplicaciones relacionadas con la misma.
En el contexto de “Upgrade”, establecerse en “Oracle Database 12c” bajo esta arquitectura puede conllevar una serie de pasos adicionales los cuales estaremos detallando de forma practica a través de estos artículos.
Selección de un Método: la selección del método es el tramo mas complejo en todo proyecto de “Upgrade”; personalmente el “task” que mayormente llevo a cabo a nivel Internacional, es llevar a cabo “Upgrades”. En la red podemos acceder a la técnica de todos los métodos existentes ( “DBUA: Database Upgrade Assistant”, “Manual Rolling Upgrade”, “Export/Import”, “Oracle Golden Gate”, “Oracle Streams”… y mas… ) sin embargo la escogencia de un método exige conocer muy bien las prestaciones, ventajas y desventajas de cada uno de ellos, en base a experiencia real lo cual conlleva a que el “DBA” tendrá que poseer un “Expertise” bastante amplio en este tipo de tarea para la escogencia del método ideal sin necesidad de realizar la mas mínima prueba en el cliente y/o proyectar las vías alternas en caso de los recursos provean mas bajo rendimiento del promedio esperado. Se consideran “ítems” como los siguientes
- La escogencia inicia principalmente por el conocimiento del “Downtime” requerido por el cliente
- Análisis de versión origen y destino, nivel de “patch sets”
- Análisis de “Endian Formats” de plataformas origen y destino
- Posible planificación de cambio en: ‘Character sets”, “Partitioning”, “Encryption”, “Compression”…
- Conocimiento si la técnica a utilizar se vera beneficiada por el uso de paralelismo si el cliente posee licencia “Enterprise Edition”
- Recursos de los equipos ( Red, Disco, Memoria )
- Arquitectura de “Backups” en la compañía ( Disco, Cintas, etc… )
- Tipo de Licencia
- Tamaño de la base de datos
- Cuando se escogen métodos lógicos, la naturaleza interna de los objetos de la base de datos
- Escogencia de la arquitectura final: Non-CDB ( “Non-Container Database” o “PDB” ( “Pluggable Database” )
Y podría seguir una lista de mas 100 “ítems” a escoger, un “Upgrade” es una tarea que requiere de un alto nivel de análisis y “Expertise sobretodo si el mismo se desea realizar en modo “Zero Downtime”…
Siempre expreso en mis conferencias que realizar un “Upgrade” es similar a realizar un traje a la medida: no hay cuerpos iguales ni bases de datos tampoco… todas tienen características únicas que la definen: “ítems” internos, criticidad de negocio, etc..
“Advice”: Como experto, aconsejo a las empresas, jamás dejar en manos no-expertas la responsabilidad de un “Upgrade” de BBDD…
“Upgrade” Directo a “Oracle Database 12c”: un “Upgrade” directo es aquel que es realizado a través de “DBUA” o por línea de comando haciendo uso de los “scripts” de “pre” y “post” “Upgrade”. Los “scripts” de “pre” y “post” “Upgrade” es el fundamento de técnicas de alto nivel como “Manual/Data Guard Rolling Upgrade” y otras. El “Upgrade” directo es soportado bajo las siguientes condiciones de versión del origen:
- Es soportado para versiones iguales o mayores a 11.2.0.2
- Para 11.2.0.1 habría que aplicar “Patch” al manejador para ir a 11.2.0.2 o superior o si no desea aplicar “Patch” al manejador se tendría que escoger otro método
- Es soportado para versión igual a 11.1.0.7
- Para 11.1.0.6 habría que aplicar “Patch” al manejador para ir a 11.1.0.7. Si no desea aplicar “Patch” al manejador se tendría que escoger otro método
- Es soportado para versión igual a 10.2.0.5
- Para 10.2.0.4 habría que aplicar “Patch” al manejador para ir a 10.2.0.5. Si no desea aplicar “Patch” al manejador se tendría que escoger otro método
- Para todas las versiones “9i” se tendría que utilizar otro método o aplicar “Patch” para ir a una versión directa permitida como: “10.2.0.5”, “11.1.0.7” o “11.2.0.2”
A continuación presentaremos 2 cuadros para visualizar una relación de complejidad, versiones, rapidez, ventajas, desventajas y otras características relacionadas con los siguientes 4 métodos. Antes describiendo en líneas generales la esencia de cada uno.
“Database Upgrade Assistant ( DBUA )”
El “DBUA” es un “Graphical User Interface” (“GUI”) que guía al “DBA” a través del proceso de “Upgrade” presentando una serie de pantallas que permitirán la especificación de opciones para el “Upgrade” de base de datos. Durante el proceso de “Upgrade” el “DBUA” invoca los mismos “scripts” utilizados por la “Command-line Upgrade”. El “DBUA” también lleva a cabo pasos de validación “pre-upgrade” y puede automatizar tareas “post-upgrade”. Utilizando el “DBUA” se puede reducir significativamente la cantidad de esfuerzo manual requerido para realizar un “Upgrade”.
“Command-line Upgrade”
En “Oracle Database 12c” es introducido un nuevo utilitario de línea de comando llamado “catctl.pl”, este utilitario reemplaza el ampliamente conocido: catupgrd.sql de versiones anteriores. El nuevo “Command-line upgrade utility” permite procesamiento paralelo durante el “Upgrade” de la base de datos, resultando en un mejor rendimiento y reducción de “Database Downtime”.
El “Command-line upgrade” sigue los mismos pasos que el “DBUA” y toma los mismos tiempos para realizar las tareas de “Upgrade” respecto a este. Es utilizado de forma directa por los “DBAs” para tomar mayor control de la tarea o en escenarios donde las bases de datos están siendo movidas a nuevos “Hardware Server” en conjunto con la aplicación del proceso de “Upgrade”.
A partir de “Oracle Database 12c” el “Pre-Upgrade Information Tool” ( preupgrd.sql ) automáticamente genera “fixup scripts” para asegurar todos los elementos necesarios para un “Upgrade” exitoso. La fase “Post-upgrade” también ha sido mejorada para las fases de ejecución posteriores al “Upgrade”.
El proceso de “Upgrade” con el “Command-line Upgrade” es llevado a cabo en 3 fases:
Fases
|
Pasos & Descripciones
|
| 1.- Fase “Pre-upgrade” |
- Ejecutar el nuevo “Pre-Upgrade Information Tool” ( preupgrd.sql ) el cual realiza validaciones a la BBDD objeto del “Upgrade”
- Ejecutar el “script” “preupgrade_fixups.sql” para automáticamente resolver todos los “ítems” señalados por el “Pre-Upgrade Information Tool”
- Llevar a cabo “Manual Fixups” señalados por el “Pre-Upgrade Information Tool”
|
| 2.- Fase de “Upgrade” |
- Ejecucion del “Parallel Upgrade Utility” ( catctl.pl )
|
| 3.- Fase de “Post-Upgrade” |
- Ejecución del “script” “postupgrade_fixups.sql” para automáticamente resolver cualquier “ítem” identificado por el “Pre-Upgrade Information Tool”
- Ejecución del “Post-Upgrade Status Tool” (utlu121s.sql) para visualizar un resumen de los resultados del “Upgrade”
- Realizar chequeo de los archivos “logs” generados por el “Parallel Upgrade Utility”
- Recompilar objetos inválidos ejecutando ( utlrp.sql )
- Verificar el estatus de los objetos recompilados ( utluiobj.sql )
|
“Full Transportable Export/Import or Transportable Tablespaces”
“Full Transportable Export/Import” es una nueva característica de “Oracle Database 12c” que facilita el movimiento de una base de datos completa utilizando la característica “Transportable Tablespace”. Este automatiza el proceso de movimiento de “Metadata” y es capaz de mover “Data” que reside en “Tablespaces” no transportables como “System” & “Sysaux”. Además es capaz de transportar “Tablespaces” encriptados.
“Transportable Tablespaces” permite una copia de un conjunto de “Tablespaces” de una base de datos a otra. Esta técnica pudiera ser muchísimo mas rápido que el tradicional “Export/Import” de la “Data” de esos correspondientes “Tablespaces” debido a que los “Tablespaces” ( “Datafiles” ) se están copiando físicamente en lugar de interpretar entidades lógicas como registros o índices contenidos en esos archivos. Con la técnica de “Transportable Tablespace” aparte de transportar los “Datafiles” se debe exportar la “Metadata” del mismo a través de “Data Pump export/import”.
“Transportable Tablespace” puede transferir información a otra base de datos que pudiera estar en un sistema operativo distinto o ejecutando en una versión distinta de “Oracle Database Software”. A partir de “Oracle Database 12c” la nueva característica “Full Transportable export/import” combina velocidad de transporte con un marco procedimental mas sencillo para llevar a cabo la tarea.
Es posible utilizar la mencionada técnica para transportar BBDDs a partir de “Oracle Database 11g Release 2 (11.2.0.3)”
Oracle Data Pump Export/Import
“Oracle Data Pump” provee un movimiento de “Data” & “Metadata” de alta velocidad entre bases de datos Oracle. Poseen una extrema flexibilidad y facilidad de uso. Es una opción para trasladar BBDDs de manera muy fácil entre base datos pertenecientes a plataformas o versiones distintas. “Data Pump” puede transferir “Data” desde una fuente en disco o a través de la red. En líneas generales son utilitarios que pueden trasladar “Data” de manera sencilla y versátil.
Original Export/Import
Desde la aparición de “Data Pump Export/Import” en 10g, “Oracle Corp,” ha recomendado su uso en comparación con el “Original Export/Import”, sin embargo es altamente útil para realizar “Upgrades” lógicos desde versiones como “9i”.
Veamos un cuadro de Ventajas y desventajas de las mencionadas herramientas y métodos:
Método
|
Herramienta
|
Ventajas
|
Desventajas
|
Método 1
| DBUA ( “Database Upgrade Assistant” ): esta basado en un utilitario GUI (“Graphical User Interface”) el cual se ha encontrado presente en al menos 4 generaciones de versiones de base de datos previas. El “Upgrade” con el “DBUA” es comúnmente denominado “Upgrade in place” debido a que realiza la operación sobre una BBDD que se encuentre de forma local en el mismo servidor donde se encuentre instalado el “software” de nivel superior, que para el presente caso, seria una versión de “Oracle Database 12c” | Posee un asistente de fácil uso indicando todos los pasos a realizar en cada etapa.
Reduce en gran medida esfuerzos manuales.
En el “Wizard” Posee capacidad de ajustar recursos para reducir el tiempo efectivo de “Upgrade”: paralelismo, cantidad de ‘CPUs”, calculo de estadísticas, recompilado de objetos,etc | La BBDD origen debe permanecer en modo “mount” para realizar el procedimiento lo cual anula la posibilidad de un “Rolling Upgrade”.
Es realizado sobre la BBDD origen por lo tanto hay que asegurar previamente un “Backup de la misma lo cual podría extender el “Downtime” del “Upgrade”
Las 2 versiones de manejador ( origen y destino ) deben estar instaladas en el mismo servidor. Esto representa una desventaja para cuando se desean realizar “Upgrades” trasladando la BBDD a otro nuevo hardware.
DBUA no es “restartable” una vez iniciado. |
Método 1
| “Command-line upgrade scripts”: Para “Oracle Database 12c” es introducido un nuevo utilitario de línea de comando llamado “catctl.pl”, este utilitario reemplaza el ampliamente conocido: catupgrd.sql de versiones anteriores | Es uno de los métodos mas efectivos por la versatilidad de controlar al 100% el proceso de “Upgrade” y la posibilidad de combinar este método con filosofías “Zero Downtime” en modo “Rolling Upgrade” | Es de grado complejo. El “DBA” necesitara familiarizarse excelentemente bien con el método para saber combinar el mismo con otras técnicas: paralelismo, “flash cards”, etc para disminuir el tiempo de reconstrucción del catalogo |
Método 2
| “Transportable Tablespaces” ( TTS ) Export/Import: esta basado en el traslado de la “Data” a través del transporte de solo los “Tablespaces” que contienen datos de aplicación | Sus nuevas propiedades permiten realizar el transporte de “Tablespaces” con menores pasos con respecto a versiones anteriores
Existe la posibilidad de movimiento de bases de datos enteras en modo multiplataforma de 11.2.0.3 a 12c con la característica “Full Transportable Export/Import” | El proceso posterior debe lidiar con el traslado físico de los “Datafiles”, “Export” & “Import” de la “Metadata”. Estas características promueven un “Downtime” prolongado si no se utilizan estrategias y recursos adecuados. |
Método 3
| “Oracle Data Pump Export/Import”: esta basado en un procedimiento de “Export” & “Import” lógico de la BBDD | Es un método lógico fácil y de alta consistencia en los detalles de “Import” en comparación al antiguo “Import Utility”.
Es combinable con otros métodos de aceleración como: paralelismo.
El “Export/Import Data Pump” posee propiedades de “stop/resumable/customizing” de la actividad lo cual lo hace flexible y versátil en modo de ejecución.
Excelente para migraciones complejas entre plataformas heterogéneas. | No alcanza tiempos tan bajos para BBDDs de largo alcance como para considerarlo un método “Zero Downtime” |
Método 4
| “Original Export/Import Utility”: es la versión original de Export/Import ( Utilitarios para movimientos de “Data” en forma lógica ) | La principal ventaja es que los manejadores de versiones superiores lo poseen aun por motivos de portabilidad con respecto a versiones anteriores lo cual brinda la oportunidad de realizar un “Upgrade” directo de “8i”,”9i” a versiones superiores | La efectividad en el transporte lógico no es tan exacta, fidedigna y flexible como su sucesor “Oracle Data Pump Export/Import” |
Le mostramos el siguiente cuadro con el objetivo de completar y/o adicionar otras variables para la toma de decisiones relacionadas con los 4 métodos explicados en el cuadro anterior. En el podrán ver otras características de los métodos relacionados con: complejidad, velocidad, versión mínima, movimiento a servidores nuevos, cambio de sistema operativo y funcionalidades adicionales tales como: ‘Character sets”, “Partitioning”, “Encryption”, “Compression” y otras.
Existen otras soluciones, herramientas y métodos tales como: “Oracle Golden Gate”, “Oracle Streams”, “Rolling Upgrade” con “Oracle Data Guard”, “Manual Rolling Upgrade”, “RMAN Cross-Platform Incremental Backups”, etc las cuales están fuera de orden del análisis del presente articulo. Lo más importante es poder proyectar con toda esta información, lo complejo que puede tornarse la toma de decisión del método a escoger para realizar un “Upgrade”. Desde nuestro punto de vista. El camino efectivo para dominar el arte del “Upgrade” esta basado en los siguientes elementos:
- Adquirir amplio conocimiento del uso de cada una de las soluciones, métodos y herramientas en bajo, medio y alto nivel de exigencia
- Experiencia Real de enfrentarse al planteamiento y ejecución de múltiples tareas de “Upgrade” en distintos escenarios, con diversos clientes, con BBDDs de diversos tamaños, con divergencia de recursos, con plataformas distintas, con arquitecturas distintas, etc…. Solo la reflexión de realizar planteamientos reales potenciaran las habilidades en esta área
- En líneas generales para ser un experto en “Upgrade” es necesario experiencia Real en muchos escenarios reales de “Upgrade”…
Ya estando en contexto de la naturaleza de saber lo concerniente al arte del “Upgrade”, pasemos a desarrollar uno de los tantos escenarios que desplegaremos en esta serie de artículos dedicados al “Upgrade”.
| Objetivo/Descripcion de escenario de “Upgrade” |
- “Upgrade” de BBDD en modo “No Zero Downtime”. En modo “No Zero Downtime” el tiempo de “Downtime” puede ser prolongado. Se realizara la actividad en un mismo servidor donde se encuentran los manejadores origen y destinos señalados en este cuadro. Se utilizara como herramienta de “Upgrade”, el “DBUA”, este exige que la BBDD se encuentre en disposición total para la actividad de “Upgrade”, es decir, a partir del momento del inicio de la actividad, el “DBUA” toma posesión de la misma. La BBDD origen se encuentra en modo “No Archive” por lo tanto se tomara un determinado espacio de tiempo para tomar un “Cold Backup” a la misma, en condiciones regulares una BBDD de producción debería siempre estar establecida en Modo “Archive” lo cual implica que pudiera ser objeto de un “Hot Backup” para ahorrar este tiempo de “Downtime” efectuando el “Cold Backup”.
|
| Versión de manejador en el Origen |
|
| Versión de manejador en el Destino |
|
| Sistema Operativo Origen |
|
| Sistema Operativo Destino |
|
| Herramienta(s) a ser utilizadas |
|
| Nombre de BBDD Origen |
|
| Nombre de BBDD Destino |
|
Iniciemos…
Base de Datos inicial de nombre ( TST11G ), objeto de “Upgrade”:
sandbox1(tst11g):/home/oracle>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Fri Jul 19 17:32:44 2013
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SYS@tst11g SQL>select open_mode , name from v$database;
OPEN_MODE NAME
-------------------- ---------
READ WRITE TST11G
SYS@tst11g SQL>
SYS@tst11g SQL>exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
sandbox1(tst11g):/home/oracle>
“Backup” de la BBDD previo al proceso de “Upgrade”. Una de las pantallas del “DBUA” indicara señalar si ya se tenía un “Backup” previo al procedimiento.
Nota: se recomienda el establecimiento de “Controlfile and spfile autobackup” si no se esta utilizando “Recovery Catalog”
sandbox1(tst11g):/jv01/app/oracle/cfgtoollogs/tst11g>rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Fri Jul 19 17:42:05 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: TST11G (DBID=4119453581)
RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name TST11G are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/opt/app/oracle/product/11.2.0/db_1/dbs/snapcf_tst11g.f'; # default
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored
RMAN>
RMAN> shutdown immediate;
using target database control file instead of recovery catalog
Oracle instance shut down
RMAN> startup mount;
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area 835104768 bytes
Fixed Size 2232960 bytes
Variable Size 490737024 bytes
Database Buffers 335544320 bytes
Redo Buffers 6590464 bytes
RMAN>
SYS@tst11g SQL>
Database altered.
RMAN> backup database;
Starting backup at 07/19/2013 17:46:09
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=133 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=00001 name=/jv01/app/oracle/oradata/TST11G/datafile/o1_mf_system_8ymc4j4o_.dbf
input datafile file number=00002 name=/jv01/app/oracle/oradata/TST11G/datafile/o1_mf_sysaux_8ymc4vp4_.dbf
input datafile file number=00003 name=/jv01/app/oracle/oradata/TST11G/datafile/o1_mf_undotbs1_8ymc50pn_.dbf
input datafile file number=00004 name=/jv01/app/oracle/oradata/TST11G/datafile/o1_mf_users_8ymc5ml7_.dbf
channel ORA_DISK_1: starting piece 1 at 07/19/2013 17:46:11
channel ORA_DISK_1: finished piece 1 at 07/19/2013 17:46:26
piece handle=/jv01/app/oracle/fast_recovery_area/TST11G/backupset/2013_07_19/o1_mf_nnndf_TAG20130719T174610_8ymdx31m_.bkp tag=TAG20130719T174610 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:15
Finished backup at 07/19/2013 17:46:26
Starting Control File and SPFILE Autobackup at 07/19/2013 17:46:26
piece handle=/jv01/app/oracle/fast_recovery_area/TST11G/autobackup/2013_07_19/o1_mf_s_821209377_8ymdxlkd_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 07/19/2013 17:46:27
RMAN>
RMAN> alter database open;
database opened
RMAN>
Invocado del “DBUA” desde el “Home” “12c”. Escogencia de la opción “Upgrade Oracle Database”
Selección de la base de datos para el “Upgrade”. Nótese todos los detalles de:
• “Source Oracle Home”, “Target Oracle Home”, “Source Oracle Home Release” y otros
Chequeo de Pre-requisitos con el uso del “Pre-Upgrade Information Tool” explicado al principio del articulo.
“Pre Upgrade Utility” ejecutado en conjunto con chequeos previos.
Establecimiento de Paralelismo para las actividades de “Upgrade” ( Reconstrucción de Catalogo ). En “Upgrade Options” podemos realizar el establecimiento de:
- Grado de paralelismo para el compilado de objetos posterior al “Upgrade”
- Escogencia de “Upgrade” del “Timezone Data”
- Opción de calcular estadísticas previo al “Upgrade”
- Opción de establecimiento en modo “Read Only” de “Tablespaces” de “Data”
“Set” de rutas para el “Diagnostic Destinantion” & “ Audit File Destination”
Para el presente caso establecimos el parámetro de Paralelismo para el “Upgrade” en 4. Se recomienda que este parámetro sea máximo la cantidad de CPUs del “Hardware Server”
Para el presente caso establecimos el parámetro de Paralelismo para la recopilación de objetos en 2. Se recomienda realizar “test” previos para el valor de este parámetro, es decir, normalmente antes de llevar a cabo un “Upgrade” se realizan múltiples pruebas y ejercicios del método a utilizar. La cantidad de “Program Units” no esta relacionado con el tamaño de BBDD, es decir, se podrán tener BBDDs de no muy alta capacidad pero con gran cantidad de “Program Units y asi sucesivamente. El tener estos en estado valido es parte del “Upgrade” y del “Application Downtime”, entonces se recomienda realizar “tests” previos para la recolección de cuanto se tomaría el recompilado con valor de paralelismo “1”,”2”,”3”,etc.. . Para preparar el ciclo de vida de un “Upgrade” real se recomienda la duplicación de la BBDD de producción y la aplicación en esta ( la BBDD clonada ) en un ambiente lo mas aproximado o igual al ambiente donde será llevado a cabo el “Upgrade” real.
Especificación de si se desea la ejecución de “Custom Scripts” previo o posterior al “Upgrade”
Especificar si se desea “OEM Express” ( Nuevo en “12c” ) o registrar la BBDD en un “EM Cloud Control” existente.
Escogencia de posible movimiento de “Datafiles” y/o “Fast Recovery Area” como parte del “Upgrade”
Escogencia del “Listener” en el cual la BBDD se ha de registrar. De manera natural se ha de escoger el del nuevo “12c Home”
Escogencia del la opción de recuperación de la BBDD para el caso de un “Upgrade” no exitoso. En nuestro caso escogemos la opción “I have my own backup and restore strategy” en base al “Cold Backup” que realizamos al principio del procedimiento, de lo contrario tuviésemos que llevar a cabo un “Backup” bajo las opciones presentes en la pantalla.
”Database Upgrade Summary”: en la siguiente pantalla se muestran los components a ser actualizados, los componentes dependen de forma directa a las opciones activadas en la BBDD origen. El estatus “VALID” al lado de cada componente especifica que ya el mismo fue validado para ser actualizado.
Avance del “Upgrade”..
Avance del “Upgrade”..
Los botones “Activity Log” & “Alert Log” pueden ser presionados para el monitoreo de las actividades.
“Upgrade” listo al 100%
“Upgrade Results”
“Upgrade Results”
“Upgrade Results”
Conclusión
Llegados a este punto la BBDD estaría actualizada a la nueva versión “12c” y lista para su uso. El “Upgrade” a través del “DBUA” es un proceso claramente simple, es ideal principalmente cuando el nuevo “Hardware Server” será el mismo de la versión anterior. Para este escenario se recomienda:
- Duplicar la BBDD de producción en el mismo servidor de producción a través de alguno de los tantos métodos de duplicación de BBDD Oracle. Es altamente recomendable utilizar un método de duplicado físico tales como: “RMAN Duplicate” u otros de manera de tener una copia de la BBDD con la misma distribución física respecto a la BBDD de producción ( distribución bloque a bloque ).
- La actividad de “Upgrade” implicara un “Application Downtime” que estará basado en diversos factores, entre los cuales uno de los mas importantes es el rendimiento del “Hardware Server” ( CPU, Memoria, etc ) donde se realizara la actividad, por lo tanto no hay mejor “Hardware Server” ideal para realizar estas pre-pruebas de “Upgrade” mas que en el mismo servidor donde se realizara la actividad real de “Upgrade”, a excepción de si se poseen servidores con soluciones “Data Guard Server” o “Manual Standby Server” ( leer detalles de este punto en el penúltimo “ítem” ). Esto ( el duplicado de BBDD de producción “in site” ) pudiera conllevar riesgos con respecto a la BBDD de producción si el “DBA” no posee alta experiencia en Duplicados de BBDD en un mismo servidor. Muchos clientes optan por solicitar un servidor con las mismas características o cualquier solución que les conlleve a no trabajar directamente en el servidor de producción y tener el resultado lo mas parecido posible a cuando se realice la actividad directamente en producción. En dado caso se estaría incurriendo en un precio de gestión paralela por no poseer en el “task” manos expertas para ello.
- Muchas empresas optan por realizar los ejercicios de “Upgrade” en el o los servidores con soluciones “Data Guard” o “Manual Standby”. Si el servidor a ser utilizado posee las mismas características del servidor de producción estaría justificable la estrategia o inclusive el “Upgrade” real se podría realizar en estos servidores mencionados “Data Guard Server” o “Manual Standby Server”. Esto ofrece una gran ventaja ya que el procedimiento no se realizara directamente sobre la BBDD origen de producción sino en una copia físicamente igual con inclusive el mismo nombre. Una de las principales ventajas esta basada en que si el “Upgrade” obtuviera algún problema de ejecución, la actividad podría ser pospuesta pero la BBDD original estaría intacta por lo tanto se podrían restablecer las operaciones de producción de forma inmediata.
- Es aconsejable que siempre se persigan los siguientes objetivos:
- Realizar las actividades de “Upgrade” en el o los servidores reales donde se llevara a cabo finalmente la actividad para tener la certeza de los tiempos esperados para el momento del “Upgrade” real
- Trazar una estrategia en la cual se resguarde al 100% la BBDD de producción
- Trazar una estrategia en la cual la BBDD de producción pueda retornar a sus actividades de forma casi inmediata en caso de que el proceso de “Upgrade” real llegara a fallar
- Y por supuesto realizar todo tipo de pruebas de funcionalidad y rendimiento con una base de datos piloto actualizada a la nueva versión antes de llevar a cabo el “Upgrade” real de producción
- En líneas generales, el “DBA” siempre debe trazar estrategias para escenarios satisfactorios o no satisfactorios en la actividad, de manera de garantizar el servicio del cliente en la versión superior u original
