MERCADOS FINANCIEROS

Track all markets on TradingView

martes, 2 de agosto de 2016

Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte II )

Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte II )

Por Joel Pérez y Wissem El Khlifi
Publicado en enero 2014
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 )

...Una vez que poseemos el “Backup” de la base de datos, iniciemos por establecer un directorio en el cual coloquemos los “scripts” de “Pre-Upgrade”. Tal como se puede apreciar, los scripts “preupgrd.sql” & “utluppkg.sql” son provenientes del “Home Oracle Database 12c”
$ mkdir -p /home/oracle/forupgrading
$ cp /u01/app/oracle/product/12.1.0.1/db_1/rdbms/admin/preupgrd.sql 
  /home/oracle/forupgrading
$ cp /u01/app/oracle/product/12.1.0.1/db_1/rdbms/admin/utluppkg.sql 
  /home/oracle/forupgrading

Ejecución de “script preupgrd.sql”. Nótese la generación de los siguientes archivos:

  • “Log”:  preupgrade.log
  • “Pre-Upgrade Fixups Script”:  preupgrade_fixups.sql
  • “Post Upgrade Fixups Script”:  postupgrade_fixups.sql
$ export ORACLE_SID=tst11g
$ ORAENV_ASK=NO
$ . oraenv
$ ORAENV_ASK=YES
$ cd /home/oracle/forupgrading
$ sqlplus / as sysdba

SQL> @preupgrd.sql
Loading Pre-Upgrade Package...
Executing Pre-Upgrade Checks...
Pre-Upgrade Checks Complete.
      ************************************************************

Results of the checks are located at:
 /u01/app/oracle/cfgtoollogs/tst11g/preupgrade/preupgrade.log

Pre-Upgrade Fixup Script (run in source database environment):
 /u01/app/oracle/cfgtoollogs/tst11g/preupgrade/preupgrade_fixups.sql

Post-Upgrade Fixup Script (run shortly after upgrade):
 /u01/app/oracle/cfgtoollogs/tst11g/preupgrade/postupgrade_fixups.sql

      ************************************************************

         Fixup scripts must be reviewed prior to being executed.

      ************************************************************

      ************************************************************
                   ====>> USER ACTION REQUIRED  <<====
      ************************************************************

 The following are *** ERROR LEVEL CONDITIONS *** that must be addressed
                    prior to attempting your upgrade.
            Failure to do so will result in a failed upgrade.

           You MUST resolve the above errors prior to upgrade

      ************************************************************

SQL>
Ejecución del “Script” generado:  preupgrade_fixups.sql  el cual emite recomendaciones para un exitoso y rápido “Upgrade”
SQL> @/u01/app/oracle/cfgtoollogs/tst11g/preupgrade/preupgrade_fixups.sql
Pre-Upgrade Fixup Script Generated on 2013-07-24 15:00:32  Version: 12.1.0.1 Build: 006
Beginning Pre-Upgrade Fixups...

PL/SQL procedure successfully completed.


PL/SQL procedure successfully completed.


**********************************************************************
Check Tag:     DEFAULT_PROCESS_COUNT
Check Summary: Verify min process count is not too low
Fix Summary:   Review and increase if needed, your PROCESSES value.
**********************************************************************
Fixup Returned Information:
WARNING: --> Process Count may be too low

     Database has a maximum process count of 150 which is lower than the
     default value of 300 for this release.
     You should update your processes value prior to the upgrade
     to a value of at least 300.
     For example:
        ALTER SYSTEM SET PROCESSES=300 SCOPE=SPFILE
     or update your init.ora file.
**********************************************************************


PL/SQL procedure successfully completed.


**********************************************************************
Check Tag:     EM_PRESENT
Check Summary: Check if Enterprise Manager is present
Fix Summary:   Execute emremove.sql prior to upgrade.
**********************************************************************
Fixup Returned Information:
WARNING: --> Enterprise Manager Database Control repository found in the database

     In Oracle Database 12c, Database Control is removed during
     the upgrade. To save time during the Upgrade, this action
     can be done prior to upgrading using the following steps after
     copying rdbms/admin/emremove.sql from the new Oracle home
   - Stop EM Database Control:
    $> emctl stop dbconsole

   - Connect to the Database using the SYS account AS SYSDBA:

   SET ECHO ON;
   SET SERVEROUTPUT ON;
   @emremove.sql
     Without the set echo and serveroutput commands you will not
     be able to follow the progress of the script.
**********************************************************************


PL/SQL procedure successfully completed.


**********************************************************************
Check Tag:     DBMS_LDAP_DEPENDENCIES_EXIST
Check Summary: Check for dependency on DBMS_LDAP package
Fix Summary:   Network Objects must be reviewed manually.
**********************************************************************
Fixup Returned Information:
WARNING: --> Existing DBMS_LDAP dependent objects

     Database contains schemas with objects dependent on DBMS_LDAP package.
     Refer to the Upgrade Guide for instructions to configure Network ACLs.
     USER APEX_030200 has dependent objects.
**********************************************************************


PL/SQL procedure successfully completed.


**********************************************************************
Check Tag:     AMD_EXISTS
Check Summary: Check to see if AMD is present in the database
Fix Summary:   Manually execute ORACLE_HOME/oraolap/admin/catnoamd.sql 
script to remove OLAP.
**********************************************************************
Fixup Returned Information:
INFORMATION: --> OLAP Catalog(AMD) exists in database

     Starting with Oracle Database 12c, OLAP is desupported.
     If you are not using the OLAP Catalog component and want
     to remove it, then execute the
     ORACLE_HOME/oraolap/admin/catnoamd.sql script before or
     after the upgrade.
**********************************************************************


PL/SQL procedure successfully completed.


**********************************************************************
                      [Pre-Upgrade Recommendations]
**********************************************************************


PL/SQL procedure successfully completed.

                        *****************************************
                        ********* Dictionary Statistics *********
                        *****************************************

Please gather dictionary statistics 24 hours prior to
upgrading the database.
To gather dictionary statistics execute the following command
while connected as SYSDBA:
    EXECUTE dbms_stats.gather_dictionary_stats;

^^^ MANUAL ACTION SUGGESTED ^^^


PL/SQL procedure successfully completed.


           **************************************************
                ************* Fixup Summary ************

 4 fixup routines generated INFORMATIONAL messages that should be reviewed.


PL/SQL procedure successfully completed.

**************** Pre-Upgrade Fixup Script Complete *********************

PL/SQL procedure successfully completed.

SQL>
Cambios sugeridos:
ALTER SYSTEM SET PROCESSES=300 SCOPE=SPFILE;

SET ECHO ON;
SET SERVEROUTPUT ON;
-- emremove.sql scrip located in the 12c home.
@/u01/app/oracle/product/12.1.0.1/db_1/rdbms/admin/emremove.sql

-- Removing this before the upgrade will result in the errors shown below.
-- These errors are not show-stoppers, but if you want a cleaner run through,
-- remove this feature after the upgrade.
@?/olap/admin/catnoamd.sql

EXECUTE dbms_stats.gather_dictionary_stats;

-- Shutdown the database.
SHUTDOWN IMMEDIATE;
Copia del archivo de parámetro y “passwordfile” al nuevo “Home 12c”
$ cp /u01/app/oracle/product/11.2.0.3/db_1/dbs/spfiletst11g.ora 
/u01/app/oracle/product/12.1.0.1/db_1/dbs
$ cp /u01/app/oracle/product/11.2.0.3/db_1/dbs/orapwtst11g 
/u01/app/oracle/product/12.1.0.1/db_1/dbs
Editar archivo “/etc/oratab” para realizar el cambio en la referencia del home de la base de datos
tst11g:/u01/app/oracle/product/12.1.0.1/db_1:Y
“Startup” de la base de datos en modo “Upgrade”
$ sqlplus / as sysdba

SQL> STARTUP UPGRADE;
SQL> EXIT;
Ejecución del “Parallel Upgrade Utility”
$ cd $ORACLE_HOME/rdbms/admin
$ $ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql
Una vez ejecutado el “Parallel Upgrade Utility”, verifiquemos el resumen de la actividad
$ sqlplus / as sysdba

SQL> STARTUP;
SQL> @utlu121s.sql
.
Oracle Database 12.1 Post-Upgrade Status Tool           07-24-2013 17:24:18
.
Component                               Current         Version  Elapsed Time
Name                                    Status          Number   HH:MM:SS
.
Oracle Server
.                                      UPGRADED      12.1.0.1.0  00:16:48
JServer JAVA Virtual Machine
.                                         VALID      12.1.0.1.0  00:04:47
Oracle Workspace Manager
.                                         VALID      12.1.0.1.0  00:01:17
OLAP Analytic Workspace
.                                         VALID      12.1.0.1.0  00:00:53
.                                         VALID      12.1.0.1.0  00:00:46
Oracle XDK
.                                         VALID      12.1.0.1.0  00:00:48
Oracle Text
.                                         VALID      12.1.0.1.0  00:01:07
Oracle XML Database
.                                         VALID      12.1.0.1.0  00:04:35
Oracle Database Java Packages
.                                         VALID      12.1.0.1.0  00:00:22
Oracle Multimedia
.                                         VALID      12.1.0.1.0  00:02:42
Spatial
.                                         VALID      12.1.0.1.0  00:06:21
Oracle Application Express
.                                         VALID     4.2.0.00.27  00:25:28
Final Actions
.                                                                00:02:47
Total Upgrade Time: 01:09:24

PL/SQL procedure successfully completed.

SQL>
Ejecución del “script catuppst.sql” para determinar si hubiese que realizar un “fix” posterior. La ejecución del mismo generara contenido de “fixes” a realizarse en el archivo “postupgrade_fixups.sql”
SQL> @catuppst.sql
Ejecutar el mismo si tuviese recomendaciones
SQL> @/u01/app/oracle/cfgtoollogs/tst11g/preupgrade/postupgrade_fixups.sql
Representa una buena práctica y asegurado de resultados la ejecución de los siguientes “scripts”
-- The following item is probably included in your postupgrade_fixups.sql script.
EXECUTE DBMS_STATS.gather_fixed_objects_stats;

-- Recompile invalid objects.
@utlrp.sql

-- Check for newly invalid objects.
@utluiobj.sql

-- Run again to check the final outcome of the upgrade.
@utlu121s.sql
Arribados a este punto ya tenemos nuestra base de datos actualizada en versión “12.1.0.1.0” 
$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Wed Jul 26 12:34:56 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> SELECT name, open_mode FROM v$database;

NAME      OPEN_MODE
--------- --------------------
TST11G      READ WRITE

SQL>
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 “Command-line Upgrade Utility” es un proceso no complejo. Se puede llevar a cabo para escenarios donde ambos manejadores se encuentren en el mismo “Hardware Server” o separados. 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 servidor(es) 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.
Publicado por en

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)