"Upgrade" de bases de datos Oracle 10g(R1/R2) a 11gR2 ( Parte I )
Por Joel Pérez 
Publicado en octubre 2012
Reciban estimados tecnólogos Oracle un cordial saludo. A través del presente artículo, tendremos la oportunidad de visualizar y adentrarnos un poco en el tema de "upgrade" de bases de datos 10g(R1/R2) a 11gR2.
Escenario y Método utilizado para el presente articulo:
- Herramienta(s) o Utilitario(s): DBUA ( Database Upgrade Assistant )
- Escenario: se llevara a cabo una migración de BBDD de 10g R2( Single Instance ) a 11g R2( Single Instance ) a través de DBUA en origen y destino.
- Los servidores origen y destinos son distintos.
Dentro de todas las posibles tareas que uno como DBA ( Database Administrator ) realiza, personalmente, una por las que mas siento afinidad es realizar "upgrades". Las condiciones, atributos, criticidad de negocio, ventanas de tiempo, etc, generalmente siempre son diversas entre un caso y otro.
Realizar un "upgrade" es como construir un traje a la medida. Diversas serán las vías pero el objetivo siempre será escoger la opción mas optima para el caso, ofreciendo el menor "Downtime" posible.
Enmarcaremos los métodos de "upgrade" de la siguiente manera:
"Upgrades" ( Lógicos ): un "upgrade" se lleva a cabo a través de vías y métodos lógicos cuando hacemos uso de utilitarios y soluciones tales como:
- export/import
- Data Pump export/import.
- Data Guard: SQL Apply
Las opciones lógicas comprenden internamente la ejecución de DMLs ( Data Manipulating Language )& DDLs ( Data Definition Language ).
"Upgrades" ( Físicos ): un "upgrade" se lleva a cabo físicamente cuando trasladamos nuestras bases de datos bloque a bloque tal cual como es la naturaleza de su almacenamiento. Para esta clasificación tenemos algunas opciones:
- RMAN Restore & Recover
- Manual Standby
- Data Guard
- Convert Database
- DBUA ( Database Upgrade Assistant )
Ahora, la pregunta es… cuando utilizar una opción o la otra… allí es cuando inicia la construcción del traje a la medida… Para la escogencia del método se analizaran principalmente las siguientes condiciones:
- La empresa tiene capacidad para un "Downtime" largo, moderado o casi nulo ?
- Capacidad de ocupación de la base de datos ( medida: 30GB, 200GB, 5TB..etc )
- "Endian Format" del Sistema operativo origen y destino
Cada una de las opciones poseen ventajas y desventajas, unas con respecto a las otras.
Analicemos posibles escenarios para proporcionarnos una idea de cómo seria el ciclo de vida de escoger la opción adecuada:
Caso 1.- Se desea migrar BBDD de 30GB de un servidor con sistema operativo (SO) Linux 64Bits a un servidor con SO HP-UX 11.31 64bits.
Elementos a considerar para el caso 1:
- La BBDD se puede considerar una BBDD de medida reducida.
- Los sistemas operativos origen y destinos no poseen el mismo "endian format" por lo tanto se opcionara en primer orden por un método lógico el cual no posee distinción en operación de acuerdo al sistema operativo origen o destino
- Si la BBDD origen es 9i o versiones anteriores tendremos que llevar a cabo el uso de Export/Import el cual existía para las nombradas versiones y posee su utilitario en versión superior en 10g(R1/R2) & 11g(R1/R2). Si el origen de BBDD es 10g(R1) o superior se podrá utilizar Data Pump Export/Import. Nota: en versiones 9i o anteriores no existían los utilitarios Data Pump Export/Import
Conclusión para el caso 1: se utilizarían los utilitarios Export/Import debido a que la BBDD no es de largo alcance y los sistemas operativos origen y destinos poseen distintos "endian formats". Se asume que estará permitido un "Downtime" necesario para llevar a cabo la tarea lo cual lo podríamos clasificar como un "Downtime" bajo.
Caso 2.- Se desea migrar BBDD de 5TB de un servidor con sistema operativo (SO) Linux 64Bits a un servidor con SO HP-UX 11.31 64bits.
Elementos a considerar para el caso 2:
- La BBDD esta vez si es de largo alcance. La opción de export/import ya no seria una opción aconsejable debido a que el "Downtime" posiblemente sea bastante largo.
- Los sistemas operativos origen y destinos no poseen el mismo "endian format" por lo tanto se anulan las posibilidades de traslados físicos por el principio mencionado. Para el presente caso las posibles vías de migración podrían ser a través de las siguientes herramientas y/o soluciones:
- Oracle Streams
- Oracle Golden Gate
- RMAN: Transportable Tablespaces
Cada una de estas herramientas poseen sus modos de usos, limitaciones, ventajas y desventajas de acuerdo al caso. Solo se podrá escoger la mejor vía si se posee el conocimiento de que tan versátil es cada una de estas y cuales son las implicaciones que cada una de ellas ( Soluciones de migración: utilitarios y/o métodos ) encierran.
Caso 3.- Se desea migrar BBDD de 3TB de un servidor con sistema operativo (SO) Linux 64Bits a un servidor con SO Linux 64bits.
Elementos a considerar para el caso 3:
- La BBDD es de largo alcance pero tenemos la mejor condición y/o atributo posible en casos de upgrade. Migración entre sistemas operativos que poseen el mismo "endian format". Dentro de esta clasificación hay 2 sub-clasificaciones mas:
- "Endian format" y Sistemas operativos origen y destino idénticos: con esta opción podremos utilizar: RMAN Restore & Recover, Data Guard, DBUA… etc.
- "Endian format" Iguales y Sistemas operativos origen y destino diversos: en esta opción tendremos que utilizar "RMAN: Convert Database"
En análisis de solo 3 casos podemos proyectar lo complejo que podría tornarse la escogencia del método idóneo para la migración de una BBDd.. La objetivo de la serie de artículos: "Upgrade de base de datos10g(R1/R2) a 11gR2" ( Parte I/II/III,…etc ) es proporcionarnos los criterios y las claves necesarias para escoger entre los diversos métodos, herramientas y/o soluciones para realizar un exitoso "upgrade".
El siguiente diagrama ilustra de manera mas organizada lo que seria la toma de decisiones para llevar a cabo una tarea de "upgrade". Tal como se puede visualizar, el principal elemento de discernimiento para la escogencia de la técnica es la versión del sistema operativo y su respectivo "Endian Format". Si nos encontramos en el mismo sistema operativo escogeríamos el siguiente elemento en el camino en base al "Downtime" permitido. Si el mismo puede ser mayor a 30minutos entonces podemos realizarlo con técnicas que conlleven la reconstrucción del catalogo como ( RMAN: Restore & Recover + catupgrd script ) o a través del DBUA el cual es el foco del presente articulo.
Si el origen y destino no se encuentra en el mismo sistema operativo entonces tenemos opciones como:
- Data Guard ( SQL Apply )
- Oracle Streams
- Transportable Database/Tablespaces
- Oracle Golden Gate
- Export/Import
Dado por terminado la introducción al presente articulo, iniciemos la secuencia de pasos para llevar a cabo la migración en base al escenario originalmente descrito.
Escenario y Método utilizado para el presente articulo
- Herramienta(s) o Utilitario(s): DBUA ( Database Upgrade Assistant )
- Escenario: se llevara a cabo una migración de BBDD de 10g R2( Single Instance ) a 11g R2( Single Instance ) a través de DBUA en origen y destino.
- Los servidores origen y destinos son distintos.
BBDD Origen: "DB10TO11G"
Sistema Operativo Origen: Linux x86 64-bit "MyjpServer1"
Versión de Oracle Server: 10.2.0.4
Ejecución del "Pre-Upgrade Tool"
Estando conectados en la BBDD origen debemos ejecutar el script "utlu112i.sql". Este script establece las condiciones necesarias para la posterior apertura de la BBDD en modo "upgrade". El mismo debe obtenerse en el "Oracle Home" del manejador destino, en el presente caso, el manejador destino es 11.2.0.3 tal como puede ser visualizado en el "feedback" de ejecución del mismo.
Dicho script realiza internamente la adición de un campo a la tabla "registry$database" y la actualización de su respectivo valor. Posterior a ello realiza el compilado del package "SYS.DBMS_REGISTRY" y de la vista "SYS.DBA_REGISTRY_DATABASE".
SQL> ALTER TABLE registry$database ADD (tz_version NUMBER);
SQL> UPDATE registry$database set tz_version =4;
SQL> ALTER PACKAGE "SYS"."DBMS_REGISTRY" COMPILE BODY;
SQL> ALTER VIEW "SYS"."DBA_REGISTRY_DATABASE" COMPILE;
Nota: Es importante divisar las recomendaciones plasmadas en el "feedback" de la ejecución del script ( tamaño mínimo de tablespaces, valor para opción "Flashback", "feedback" de componentes instalados en la BBDD, "Recycle bin", EM, estadísticas, parámetros, etc )
[oracle@MyjpServer1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Thu Aug 9 15:04:08 2012
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> start utlu112i.sql
Oracle Database 11.2 Pre-Upgrade Information Tool 08-09-2012 15:04:26
Script Version: 11.2.0.3.0 Build: 001
.
**********************************************************************
Database:
**********************************************************************
--> name: DB10TO11
--> version: 10.2.0.4.0
--> compatible: 10.2.0.3.0
--> blocksize: 8192
--> platform: Linux x86 64-bit
--> timezone file: V4
.
**********************************************************************
Tablespaces: [make adjustments in the current environment]
**********************************************************************
--> SYSTEM tablespace is adequate for the upgrade.
.... minimum required size: 719 MB
--> UNDOTBS1 tablespace is adequate for the upgrade.
.... minimum required size: 400 MB
--> SYSAUX tablespace is adequate for the upgrade.
.... minimum required size: 444 MB
--> TEMP tablespace is adequate for the upgrade.
.... minimum required size: 60 MB
.
**********************************************************************
Flashback: OFF
**********************************************************************
**********************************************************************
Update Parameters: [Update Oracle Database 11.2 init.ora or spfile]
Note: Pre-upgrade tool was run on a lower version 64-bit database.
**********************************************************************
--> If Target Oracle is 32-Bit, refer here for Update Parameters:
-- No update parameter changes are required.
.
--> If Target Oracle is 64-Bit, refer here for Update Parameters:
-- No update parameter changes are required.
.
**********************************************************************
Renamed Parameters: [Update Oracle Database 11.2 init.ora or spfile]
**********************************************************************
-- No renamed parameters found. No changes are required.
.
**********************************************************************
Obsolete/Deprecated Parameters: [Update Oracle Database 11.2 init.ora or spfile]
**********************************************************************
--> background_dump_dest 11.1 DEPRECATED replaced by "diagnostic_dest"
--> user_dump_dest 11.1 DEPRECATED replaced by "diagnostic_dest"
.
**********************************************************************
Components: [The following database components will be upgraded or installed]
**********************************************************************
--> Oracle Catalog Views [upgrade] VALID
--> Oracle Packages and Types [upgrade] VALID
--> JServer JAVA Virtual Machine [upgrade] VALID
--> Oracle XDK for Java [upgrade] VALID
--> Oracle Workspace Manager [upgrade] VALID
--> OLAP Analytic Workspace [upgrade] VALID
--> OLAP Catalog [upgrade] VALID
--> EM Repository [upgrade] VALID
--> Oracle Text [upgrade] VALID
--> Oracle XML Database [upgrade] VALID
--> Oracle Java Packages [upgrade] VALID
--> Oracle interMedia [upgrade] VALID
--> Spatial [upgrade] VALID
--> Data Mining [upgrade] VALID
--> Expression Filter [upgrade] VALID
--> Rule Manager [upgrade] VALID
--> Oracle OLAP API [upgrade] VALID
.
**********************************************************************
Miscellaneous Warnings
**********************************************************************
WARNING: --> Database is using a timezone file older than version 14.
.... After the release migration, it is recommended that DBMS_DST package
.... be used to upgrade the 10.2.0.4.0 database timezone version
.... to the latest version which comes with the new release.
WARNING: --> EM Database Control Repository exists in the database.
.... Direct downgrade of EM Database Control is not supported. Refer to the
.... Upgrade Guide for instructions to save the EM data prior to upgrade.
WARNING: --> Your recycle bin is turned on and currently contains no objects.
.... Because it is REQUIRED that the recycle bin be empty prior to upgrading
.... and your recycle bin is turned on, you may need to execute the command:
PURGE DBA_RECYCLEBIN
.... prior to executing your upgrade to confirm the recycle bin is empty.
.
**********************************************************************
Recommendations
**********************************************************************
Oracle recommends gathering dictionary statistics prior to
upgrading the database.
To gather dictionary statistics execute the following command
while connected as SYSDBA:
EXECUTE dbms_stats.gather_dictionary_stats;
**********************************************************************
Oracle recommends reviewing any defined events prior to upgrading.
To view existing non-default events execute the following commands
while connected AS SYSDBA:
Events:
SELECT (translate(value,chr(13)||chr(10),' ')) FROM sys.v$parameter2
WHERE UPPER(name) ='EVENT' AND isdefault='FALSE'
Trace Events:
SELECT (translate(value,chr(13)||chr(10),' ')) from sys.v$parameter2
WHERE UPPER(name) = '_TRACE_EVENTS' AND isdefault='FALSE'
Changes will need to be made in the init.ora or spfile.
**********************************************************************
SQL>
Purgando "Recycle bin"
De acuerdo a las recomendaciones dadas por el script anterior. Se aconseja ejecutar el "Purge" al "Recycle bin".
SQL> purge DBA_RECYCLEBIN;
Obtención de Plantilla con Datos en BBDD origen
Una vez ejecutado el script de "Pre-upgrade Tool". Procederemos a generar una plantilla con datos de la BBDD origen "DB10TO11G" a través del DBCA. Durante la generación de la plantilla el DBCA establece la BBDD en modo "mount" para generar así un "Cold Backup" comprimido como parte de la plantilla. Los backups comprimidos normalmente tardan 2 o 3 veces más el tiempo habitual de un backup sin comprimir y el restaurado del mismo también tarda aproximadamente 3 veces más tiempo respecto a un restaurado regular. Este factor es importante tomarlo en cuenta para calcular parte del "Downtime" que se llevara a cabo con la actividad.
[oracle@MyjpServer1 ~]$ dbca
Pantalla Inicial del DBCA:
Escogencia de la opción para trabajar con plantillas:
Escogemos la opción para generar una plantilla con datos:
Seleccionamos la BBDD en base a la cual se generara la plantilla:
Establecemos un nombre para la plantilla y la ruta por defecto de la misma:
Seleccionamos la opción
"convert the file locations to use OFA structure" de manera que tengamos flexibilidad para escoger las rutas de la BBDD a crear en base a la presente plantilla
OFA: "Oracle Flexible Arquitecture"
Se chequea la confirmación de la generación de la plantilla. Divisar el nombre y la ruta que se establecerá para la misma.
Una vez generada la plantilla podemos ver los 3 archivos generados en la ruta previamente establecida ( $ORACLE_HOME/assistants/dbca/templates ):
[oracle@MyjpServer1 templates]$ pwd
/u01/app/oracle/product/10.2.0/db_1/assistants/dbca/templates
[oracle@MyjpServer1 templates]$
[oracle@MyjpServer1 templates]$ ls -lt *DB10TO11G*
-rw-r----- 1 oracle oinstall 5236 Aug 9 13:49 Template_for_DB10TO11G.dbc
-rw-r----- 1 oracle oinstall 7061504 Aug 9 13:49 Template_for_DB10TO11G.ctl
-rw-r----- 1 oracle oinstall 98500608 Aug 9 13:49 Template_for_DB10TO11G.dfb
[oracle@MyjpServer1 templates]$
Los archivos de la plantilla serán transferidos al servidor destino en el cual se posee una instalación de Oracle Server11gR2. La ruta destino para los archivos de la plantilla es el siguiente ( $ORACLE_HOME/assistants/dbca/templates ). Es esta la ruta por defecto donde el DBCA 11gR2 ubicara las plantillas existentes para el "Oracle Server" en funcionamiento
[oracle@MyjpServer1 templates]$ scp *DB10TO11G*
MyjpServer2:/u01/app/oracle/product/11.2.0/dbhome_1/assistants/dbca/templates
The authenticity of host '16.0.0.118 (16.0.0.118)' can't be established.
RSA key fingerprint is 76:74:5e:63:0e:34:c6:36:d5:0c:f0:30:b0:60:3d:d8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '16.0.0.118' (RSA) to the list of known hosts.
oracle@16.0.0.118's password:
Template_for_DB10TO11G.ctl 100% 6896KB 6.7MB/s 00:00
Template_for_DB10TO11G.dbc 100% 5236 5.1KB/s 00:00
Template_for_DB10TO11G.dfb 100% 94MB 10.4MB/s 00:09
[oracle@MyjpServer1 templates]$
Visualización de archivos transferidos al servidor destino. Es importante transferir los archivos de la plantilla a la ruta señalada ( $ORACLE_HOME/assistants/dbca/templates ) para que el DBCA 11g pueda reconocer la misma de forma automática.
BBDD destino a ser construida: "DB11GR2"
Sistema Operativo Destino: Linux x86 64-bit "MyjpServer2"
Versión de Oracle Server: 11.2.0.3
[oracle@MyjpServer2 templates]$ pwd
/u01/app/oracle/product/11.2.0/dbhome_1/assistants/dbca/templates
[oracle@MyjpServer2 templates]$
[oracle@MyjpServer2 templates]$ ls -lt *DB10TO11G*
-rw-r----- 1 oracle oinstall 98500608 Aug 9 08:13 Template_for_DB10TO11G.dfb
-rw-r----- 1 oracle oinstall 7061504 Aug 9 08:13 Template_for_DB10TO11G.ctl
-rw-r----- 1 oracle oinstall 5236 Aug 9 08:13 Template_for_DB10TO11G.dbc
[oracle@MyjpServer2 templates]$
Una vez que se poseen los archivos de la plantilla en el servidor destino en la ruta señalada. Procedemos a iniciar el DBCA.
[oracle@MyjpServer2 ~]$ dbca
Seleccionamos la opción para crear una nueva BBDD:
Allí encontraremos disponible la plantilla que se transfirió
"Template for DB10TO11G":
Para el presente caso crearemos una BBDD llamada "DB11GR2":
En la presenta pantalla se encuentran escogidas las opciones para crear la BBDD y generar los scripts. Para el presente caso el DBCA no podrá crear via "wizard" satisfactoriamente la BBDD por un elemento que visualizaremos en los siguientes pasos. El procedimiento a llevar a cabo estará basado solamente en generar los scripts. Para ello solo escoja la generación de scripts.
Los scripts se generaran satisfactoriamente en disco:
Si se selecciono la creación de BBDD, el asistente iniciara la actividad:
Si se selecciono la creación de BBDD, el asistente iniciara la actividad. Internamente cuando intente abrir la BBDD el mismo se encontrara con el problema de que esta intentando restaurar una BBDD 10g en un "Oracle Server 11g" y por ello la opción posible es de modo "upgrade".
Siendo de esta manera. El asistente culminara su labor no satisfactoriamente. Los scripts ya fueron creados y ellos trabajaremos para poder llevar a cabo la tarea.
Los scripts generados por el DBCA son los siguientes:
[oracle@MyjpServer2 scripts]$ pwd
/u01/app/oracle/admin/DB11GR2/scripts
[oracle@MyjpServer2 scripts]$
[oracle@MyjpServer2 scripts]$ ls -lt
total 27644
-rw-r----- 1 oracle oinstall 2182 Aug 9 09:46 cloneDBCreation.sql
-rw-r----- 1 oracle oinstall 736 Aug 9 09:41 postDBCreation.sql
-rw-r----- 1 oracle oinstall 507 Aug 9 09:41 lockAccount.sql
-rwxr-xr-x 1 oracle oinstall 550 Aug 9 09:41 DB11GR2.sql
-rw-r----- 1 oracle oinstall 667 Aug 9 09:41 postScripts.sql
-rw-r----- 1 oracle oinstall 2524 Aug 9 09:41 initDB11GR2Temp.ora
-rw-r----- 1 oracle oinstall 277 Aug 9 09:41 CloneRmanRestore.sql
-rw-r----- 1 oracle oinstall 1361 Aug 9 09:41 rmanRestoreDatafiles.sql
-rw-r----- 1 oracle oinstall 2511 Aug 9 09:41 init.ora
-rwxr-xr-x 1 oracle oinstall 647 Aug 9 09:41 DB11GR2.sh
[oracle@MyjpServer2 scripts]$
[oracle@MyjpServer2 scripts]$
La tarea de crear la BBDD la llevaremos a cabo a través de los scripts. Para que la creación en el presente escenario se realice de forma satisfactoria solo deberemos modificar una línea de un script y adicionar otra.
Script a ser modificado: /u01/app/oracle/admin/DB11GR2/scripts/cloneDBCreation.sql
Línea a ser modificada: alter database
open resetlogs;
Valor original: alter database "DB11GR2" open resetlogs;
Valor posterior a la modificación: alter database "DB11GR2" open resetlogs upgrade;
Los scripts de BBDD originalmente aperturan la BBDD en modo resetlogs de manera de que los "Redo Log groups" sean creados automáticamente posterior a la recreación de controlfiles. La modificación a realizar es colocar la clausula "upgrade" de manera de que se realice la misma operación pero en modo "upgrade". Una vez aperturada la BBDD en modo "upgrade" es necesario ejecutar la re-construcción del catalogo lo cual no solo actualiza las vistas del catalogo sino que también realiza el "upgrade" de las opciones existentes en la BBDD ( Oracle Text, Oracle XML Database, etc ). La ejecución de este script es lo que mas consumo de tiempo toma al realizar el "upgrade" en el presente escenario, regularmente en promedio esta ejecución tarda de 30 a 90 minutos. La ejecución de las estadísticas del diccionario de datos ( EXECUTE dbms_stats.gather_dictionary_stats;) promoverá la rapidez de la ejecución de esta fase y la relacionada con la compilación de objetos inválidos.
Oracle Text, Oracle XML Database, etc ). La ejecución de este script es lo que mas consumo de tiempo toma al realizar el "upgrade" en el presente escenario, regularmente en promedio esta ejecución tarda de 30 a 90 minutos. La ejecución de las estadísticas del diccionario de datos ( EXECUTE dbms_stats.gather_dictionary_stats;) promoverá la rapidez de la ejecución de esta fase y la relacionada con la compilación de objetos inválidos.
Posterior a la línea de apertura se deberá adicionar la línea para la actualización del catalogo en modo "upgrede" con el siguiente script:
start /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/admin/catupgrd.sql
En definitiva las 2 lineas quedaran de la siguiente manera:
alter database "DB11GR2" open resetlogs upgrade;
start /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/admin/catupgrd.sql
El contenido completo del script mencionado es el siguiente:
[oracle@MyjpServer2 scripts]$ cat /u01/app/oracle/admin/DB11GR2/ scripts/cloneDBCreation.sql
SET VERIFY OFF
connect "SYS"/"&&sysPassword" as SYSDBA
set echo on
spool /u01/app/oracle/admin/DB11GR2/scripts/cloneDBCreation.log append
Create controlfile reuse set database "DB11GR2"
MAXINSTANCES 8
MAXLOGHISTORY 1
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
Datafile
'/u01/app/oracle/oradata/DB11GR2/system01.dbf',
'/u01/app/oracle/oradata/DB11GR2/undotbs01.dbf',
'/u01/app/oracle/oradata/DB11GR2/sysaux01.dbf',
'/u01/app/oracle/oradata/DB11GR2/users01.dbf'
LOGFILE GROUP 1 ('/u01/app/oracle/oradata/DB11GR2/redo01.log') SIZE 51200K,
GROUP 2 ('/u01/app/oracle/oradata/DB11GR2/redo02.log') SIZE 51200K,
GROUP 3 ('/u01/app/oracle/oradata/DB11GR2/redo03.log') SIZE 51200K RESETLOGS;
exec dbms_backup_restore.zerodbid(0);
shutdown immediate;
startup nomount pfile="/u01/app/oracle/admin/DB11GR2/scripts/initDB11GR2Temp.ora";
Create controlfile reuse set database "DB11GR2"
MAXINSTANCES 8
MAXLOGHISTORY 1
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
Datafile
'/u01/app/oracle/oradata/DB11GR2/system01.dbf',
'/u01/app/oracle/oradata/DB11GR2/undotbs01.dbf',
'/u01/app/oracle/oradata/DB11GR2/sysaux01.dbf',
'/u01/app/oracle/oradata/DB11GR2/users01.dbf'
LOGFILE GROUP 1 ('/u01/app/oracle/oradata/DB11GR2/redo01.log') SIZE 51200K,
GROUP 2 ('/u01/app/oracle/oradata/DB11GR2/redo02.log') SIZE 51200K,
GROUP 3 ('/u01/app/oracle/oradata/DB11GR2/redo03.log') SIZE 51200K RESETLOGS;
alter system enable restricted session;
alter database "DB11GR2" open resetlogs upgrade;
start /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/admin/catupgrd.sql
exec dbms_service.delete_service('DB10TO11');
exec dbms_service.delete_service('DB10TO11XDB');
alter database rename global_name to "DB11GR2";
ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/DB11GR2/temp01.dbf'
SIZE 20480K REUSE AUTOEXTEND ON NEXT 640K MAXSIZE UNLIMITED;
select tablespace_name from dba_tablespaces where tablespace_name='USERS';
select sid, program, serial#, username from v$session;
alter database character set INTERNAL_CONVERT WE8MSWIN1252;
alter database national character set INTERNAL_CONVERT AL16UTF16;
alter user sys account unlock identified by "&&sysPassword";
alter user system account unlock identified by "&&systemPassword";
alter system disable restricted session;
[oracle@MyjpServer2 scripts]$
Una vez realizado el cambio en el script ( /u01/app/oracle/admin/DB11GR2/scripts/cloneDBCreation.sql ). Se podrá iniciar la creación formal de la BBDD con la ejecución del script:
[oracle@MyjpServer2 scripts]$ /u01/app/oracle/admin/DB11GR2/scripts/DB11GR2.sh
Posterior a la finalización del script de construcción de BBDD. Es aconsejable adicionar la referencia de la nueva BBDD al archivo /etc/oratab de la siguiente manera:
DB11GR2:/u01/app/oracle/product/11.2.0/dbhome_1:Y
Esto se realiza con el objetivo de que el DBCA pueda tener referencia de existencia de la reciente BBDD creada para futuras tareas de mantenimiento relacionadas con la misma.
Después de la finalización del script de construcción de BBDD podemos visualizar si los componentes y/o opciones internas de la BBDD quedaron correctamente actualizadas mediante el siguiente script:
SQL> start $ORACLE_HOME/rdbms/admin/utlu112s.sql
Se aconseja validar objetos inválidos y proceder a la compilación de los mismos. A través de la siguiente consulta se pueden verificar los objetos inválidos:
SQL> SELECT UNIQUE object_name, object_type, owner FROM dba_objects WHERE status='INVALID';
Asegúrese que no queden objetos inválidos en los schemas sys y system.
Podrá Recompilar objetos inválidos con el siguiente script:
SQL> start $ORACLE_HOME/rdbms/admin/utlrp.sql
A partir de la versión de manejador 11.1.0.7 podrá comparar objetivos inválidos antes y posterior al "upgrade" a través de las siguientes vistas:
- registry$sys_inv_objs
- registry$nonsys_inv_objs
O ejecutar el siguiente script para el mismo objetivo:
SQL> start $ORACLE_HOME/rdbms/admin/utluiobj.sql
La vista dba_invalid_objs podrá ser consultada para determinar los objetos inválidos posterior al "upgrade".
Conclusión
La presente técnica mostrada posee características de ejecución que se adaptan para migraciones con perfil "No Zero Downtime". El tiempo de "Downtime" estará basado en el "cold backup" original, transferencia de los archivos de plantilla, restaurado de la BBDD, reconstrucción de catalogo y posteriores tareas finales. Dependiendo del tamaño de la BBDD esta pudiese ser una opción excelente por su sencillez, efectividad y confiabilidad. En un artículos posteriores abordaremos diversos escenarios de para realizar "upgrades" con DBUA en el mismo "host", en modo "Rolling Upgrade" de manera que nuestro "Downtime" no sea tan prolongado para BBDDs de largo alcance y demás escenarios posibles.
