Oracle Database 12C: “Upgrade” a “Oracle Database 12C”
“Database12c” la nueva versión de manejador de base de datos de “Oracle Corporation”, nosotros los tecnólogosOracle nos preguntábamos “que mas…” podría Oracle adicionar como nuevas características?, de qué forma Oracle nosiba a sorprender esta vez y como siempre, las nuevas características y nueva arquitectura no solo nos sorprenden sinoque una vez más nos llevan a otra era, “Cloud Computing"
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 manejadorpara operaciones de tipo “Cross-Platform” en general: Transporte de Tablespaces, Datafiles & Bases de Datos. Lasalternativas de “Upgrade” a partir de “Oracle Database 12c” son mayores lo cual impacta positivamente en los clientesque 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 queadicionar unos 500 más debido a que a partir de “Oracle Database 12c” no solo tenemos que pensar en el “Path” y modode “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 artículo: OracleDatabase 12c: “Oracle Multitenant” ( Parte I ). Uno de los principalmente beneficiados en todo este proceso es el cliente, yaque el “Software” & Compania “Oracle” ha colocado en disponibilidad una vez más un “Release” lleno de nuevas alternativas para hacer que la administración de una base de datos “Oracle” sea más un placer que un requisito delmercado 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 más importantes y decisivos por lo cuales los clientes siempre deciden llevar a caboel “Upgrade” de sus bases de datos a una nueva versión es para poder contar con las nuevas características, “OracleDatabase 12c” incluye excelentes nuevos”Features” como: “Oracle Multitenant Option”, “Oracle Active Data Guard FarSync”, mejoras en “Information Lifecycle Management”, nuevos tipos de datos y más.
“Database Upgrade”: el acto de llevar a cabo “Upgrades” en bases de datos “Oracle” envuelve una actividad demodificar el diccionario de datos para que el mismo sea compatible con la versión del “Oracle Database Software”. Lastí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 más 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 más. La nueva arquitectura está 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 práctica a través de estos artículos.
Selección de un Método: la selección del método es el tramo más 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 más… ) 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 más mínima prueba en el cliente y/o proyectar las vías alternas en caso de los recursos provean más 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”
· 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.
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” |
|
2.- Fase de “Upgrade” |
|
3.- Fase de “Post-Upgrade” |
|
“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.
“System” & “Sysaux”. Además es capaz de transportar “Tablespaces” encriptados.
El realizar “Upgrades” entre plataformas heterogéneas siempre ha sido un reto para empresas y “DBAs” incurriendo en muchas oportunidades a escogencia de otras soluciones y/o estrategias para sortear la dificultad. En muchos casos la inversión económica es tan alta en consideración para estos escenarios, que conlleva a la toma de decisiones de cambiar radicalmente la plataforma destino u otras. Ej: sucede con alta frecuencia que en las empresas los gerentes y/o directores de “IT” toman decisiones de adquisición de “Hardware” para llevar a cabo “Upgrades” de BBDD y de “Hardware” sin conocer a fondo las posibles implicaciones de la decisión de escoger una plataforma u otra. Hasta versiones previas a “Oracle Database 12c”, escoger un nueva plataforma para “Upgrade” con un “Endian Format” distinto a la plataforma original implicaba un gran desafío posterior para los “DBAs” y en muchas ocasiones implicaciones “post” económicas para llevar a cabo la tarea. En mas de 13 años como “DBA” siempre he confrontado este caso en innumerables ocasiones y ha sido muy frecuente el que haya tenido que viajar a otros países solo para explicar las implicaciones económicas que tendrá un “Upgrade” a una plataforma heterogénea, mas específicamente cuando los “Endian Formats” son diversos.
Afortunadamente para las empresas esta nueva característica Cross-Platform” de “Full Transportable Export/Import” podrá solventar ese tipo de casos intrincados de “Upgrade” entre plataformas de “Endian Format” distintos. La única condición base es que la misma esta disponible para BBDDs a partir de versión 11.2.0.3. Ej: si una empresa posee una BBDD en versión 10.2.0.5 y quería realizar un “Upgrade” a una plataforma diversa para trabajar en 11.2.0.3, porque no solo deseaba subir de versión sino cambiar de “Hardware” también pero que poseía la dificultad de la cual ya hemos venido conversando. Una solución excelente seria aplicar “Upgrade” rápido y momentáneo en el mismo servidor original de 10.2.0.5 a 11.2.0.3 y desde esta versión realizar “Upgrade” inmediato a “Oracle Database 12c” en el hardware destino de plataforma y “Endian Format” distinto. Esta indudablemente podría ser una de las tantas justificadas razones por la cual una empresa podría programar su “Upgrade” a “Oracle Database 12c”. En esta serie de artículos tendremos unos ejemplos altamente interesante de esta nueva característica.
“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” 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. | La BBDD origen debe permanecer en modo “mount” para realizar el procedimiento lo cual anula la posibilidad de un “Rolling Upgrade”. |
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 | 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”. | 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/Descripción 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 “Command-line Upgrade Utility”. 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 | 11.2.0.3 |
Versión de manejador en el Destino | 12.1.0.1.0 |
Sistema Operativo Origen | Linux x86 64bits |
Sistema Operativo Destino | Linux x86 64bits |
Herramienta(s) a ser utilizadas | “Command-line Upgrade Utility” ( “Manual Upgrade” ) |