Usando DBMS_ROLLING para Upgrade de Oracle Database 12c hacia 18c

Por Julio César Ayapán Oracle Associate
Publicado en Septiembre 2018

Revisado por Francisco Riccio



Introducción:


Recientemente y después de una larga espera se ha liberado Oracle Database 18.3.0 on premise para Linux, disponible para descarga en la pagina de OTN.

Oracle 18c incluye nuevas e interesantes características que meses atrás solo era posible experimentar con ellas a través de Oracle Cloud, pero ahora, con esta versión on premise, muchos de los entusiastas de Oracle Database podemos explorarlas en un ambiente Linux. Lamentablemente, en este artículo no hablaré acerca de alguna de estas, eso lo dejaré para otra ocasión mas adelante.

Aprovechando el upgrade de las bases de datos de prueba que utilizo, el objetivo principal de este articulo es hablar sobre el paquete DBMS_ROLLING, disponible desde Oracle 12c (12.1). Así que voy a describir su funcionalidad mediante un ejemplo práctico.




DBMS_ROLLING:


El problema principal cuando se hace un parchado o un upgrade de versión de base de datos es el downtime que este implica. Oracle, a través de los años, ha añadido nuevas características para reducir el tiempo de baja de nuestros servicios a lo mínimo posible. En este caso el método que voy a utilizar es el paquete DBMS_ROLLING, disponible desde 12c Release 1 y que podremos utilizar si tenemos la licencia de Active Data Guard. Con DBMS_ROLLING el downtime se verá reducido considerablemente al tiempo que nos tome hacer un cambio de role (switchover) entre base de datos Primaria y base de datos Standby.

Este método está completamente automatizado y nos lleva a través de una serie de pasos para completar nuestro parchado o upgrade de base de datos. A continuación veremos como funciona DBMS_ROLLING.

El primer paso del método DBMS_ROLLING será definir que base de datos será nuestra   “Primaria Futura”. Esta Primaria Futura es actualizada o parchada primero, después, se le asigna el rol Primario a través de un cambio de rol, dejando la  base de datos Primaria Original libre para actualizar o parchar.

Las bases de datos Primaria Futura y Primaria Original deberán estar dentro de grupos de bases de datos de rastreo y principal, que de ahora en adelante llamaremos TRAILLING y LEADING respectivamente.

El grupo TRAILLING contiene la Primaria Futura y opcionalmente puede contener una o mas bases de datos Physical Stanby que nos servirán para proteger a la base de datos Primaria Futura, que desde ahora llamaremos (Leading Group Master – LDG).

El grupo LEADING contiene la base de datos Primaria Original y opcionalmente  puede contener una o mas bases de datos Physical o Logical Standby para proteger a la base de datos Primaria Original, que desde ahora llamaremos (Trailling Group Master – TGM).

A continuación se describen los pasos anteriores de una manera grafica para una mejor comprensión:

Paso 1: Definir Primaria Futura y Primaria Original dentro de los grupos Leading y Trailling






Paso 2: realizar upgrade o parchado del Leading Group completo






Paso 3: cambiar el role primario, desde el Trailling group hacia el Leading Group.






Paso4: realizar upgrade o parchado del Trailling Group completo


Opcionalmente, al final del procedimiento podemos volver a revertir los roles de las bases de datos para obtener el escenario que teníamos al inicio.

El objetivo de las bases de datos opcionales dentro de cada grupo es reemplazar al LGM o TGM en caso de que ocurra un error muy grave durante el procedimiento.

Una vez entendido el proceso, vamos al ejemplo.




Upgrade de 12c hacia 18c


Escenario inicial:

El escenario utilizado para este artículo consta de dos bases de datos, una base de datos primaria rhdb y una base de datos physical standby rhdbstb con Active Data Guard activado. Se utilizó Data Guard Broker para mantener la configuración de las bases de datos. Las características son las siguientes:

Base de datos Primaria:
db_unique_name: rhdb
versión: 12.1.0.2

Base de datos Phisical Standby con Active Data Guard:
db_unique_name: rhdbstb
versión: 12.1.0.2



El objetivo principal es hacer upgrade de la versión 12.1.0.2 hacia 18.3.0.

Nota: Los binarios de 18c ya fueron instalados en cada uno de los servidores donde residen las bases de datos.


Requisitos:

Antes de comenzar, analicemos algunos requisitos para alcanzar la versión 18.3.0 y para utilizar DBMS_ROLLING.

Para actualizar nuestra base de datos hacia 18.3.0 la versión actual de nuestra base de datos puede ser:

  • 11.2.0.3 y 11.2.0.4
  • 12.1.0.1 y 12.1.0.2
  • 12.2.0.1

Para usar DBMS_ROLLING sin toparnos con inconvenientes a medio camino se deben cumplir los siguientes requisitos en todas las bases de datos que pertenecerán al grupo LEADING o TRAILLING.

  1. Flashback Database debe estar activado.
  2. El parámetro log_archive_config debe de estar configurado de la misma manera en todas las bases de datos. Incluyendo todos los db_unique_name de los participantes.
  3. Los parámetros log_archive_dest_n deben estar configurados en todas las bases de datos participantes, recordemos que el procedimiento involucra un cambio de rol así que los destinos deben de estar definidos con las opciones VALID_FOR correctas.
  4. DBMS_ROLLING hace una transformación de PHYSICAL hacia LOGICAL en el leading group, por lo que las tablas con tipos de datos no soportados (en caso existan), deben ser mantenidos manualmente durante el procedo de cambio de rol.
  5. Si estamos utilizando Data Guard Broker para mantener nuestra configuración de Data Guard, este debe ser deshabilitado antes de comenzar con el procedimiento y habilitado al final de este.
  6. El parámetro COMPATIBLE debe establecerse como 12.1 o superior.


Procedimiento:

La ejecución de DBMS_ROLLING esta compuesto por el siguiente PATH:

  • Especificar parámetros para la operación de upgrade o parchado, como la versión final objetivo de base de datos, las bases de datos participantes, retrasos o timeouts durante la operación y nivel de logging generado durante la operación. Para eso utilizaremos las funciones DBMS_ROLLING.INIT_PLAN, DBMS_ROLLING.SET_PARAMETER y la vista DBA_ROLLING_PARAMETERS.
  • Generar un plan de upgrade y realizar validaciones, todo esto a través de la función DBMS_ROLLING.BUILD_PLAN.
  • El plan de upgrade se llevara a cabo usando las funciones DBMS_ROLLING.START_PLAN, DBMS_ROLLING.SWITCHOVER y DBMS_ROLLING.FINISH_PLAN.
  • Validar el estado de nuestro plan de upgrade y resolución de problemas mediante las vistas DBA_ROLLING_PARAMETERS y DBA_ROLLING_EVENTS.

Antes de comenzar validaremos ciertos prerrequisitos para evitar cualquier falla durante el procedimiento.



Paso 1: Activar Flashback database en cada una de las bases de datos:

SQL> alter database flashback on;

Database altered.



SQL> select flashback_on, database_role from v$database;

FLASHBACK_ON	   DATABASE_ROLE
------------------ ----------------
YES	   	   PHYSICAL STANDBY


SQL> select flashback_on, database_role from v$database;

FLASHBACK_ON	   DATABASE_ROLE
------------------ ----------------
YES	   	   PRIMARY

    




Paso 2:  Deshabilitar la configuración de Data Guard Broker

DGMGRL> show configuration

Configuration - dgrh

  Protection Mode: MaxPerformance
  Members:
  rhdb    - Primary database
  rhdbstb - Physical standby database 

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 51 seconds ago)

DGMGRL> disable configuration
Disabled.
    


En cada una de las bases de datos involucradas:

SQL> alter system set dg_broker_start=false;
    
System altered.





Paso 3:  Validar los valores de los parámetros log_arhiche_dest_n en cada base de datos:

Primaria:

SQL> show parameter log_archive_dest_2

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2		     string	 service="rhdbstb", ASYNC NOAFF
						 IRM delay=0 optional compressi
						 on=disable max_failure=0 max_c
						 onnections=1 reopen=300 db_uni
						 que_name="rhdbstb" net_timeout
						 =30, valid_for=(online_logfile
						 ,all_roles)

    


Standby:

SQL> show parameter log_archive_Dest_2

NAME				     TYPE	 VALUE
------------------------------------ -----------------------------------------
log_archive_dest_2		     string	 service="rhdb", ASYNC NOAFFIRM
						  delay=0 optional compression=
						 disable max_failure=0 max_conn
						 ections=1 reopen=300 db_unique
						 _name="rhdb", valid_for=(onlin
						 e_logfile,all_roles)

    

Ahora comenzaremos con la ejecución de RBMS_ROLLING.




Paso 4: iniciamos con el plan de upgrade, en la base de datos primaria, ejecutamos:

SQL> exec DBMS_ROLLING.INIT_PLAN(FUTURE_PRIMARY=>'rhdbstb');
    
PL/SQL procedure successfully completed.
 

rhdbstb hace referencia a la base de datos standby que será nuestra futura primaria, en este momento, rhdbstb se convierte en la base de datos LGM. Podemos validar el resultado con las siguientes consultas:

SQL> SELECT REVISION, STATUS, PHASE FROM DBA_ROLLING_STATUS;

  REVISION STATUS	PHASE
---------- ------------ --------------
	 0  READY       BUILD PENDING



Podemos observar los parámetros actuales del plan usando la vista DBA_ROLLING_PARAMETERS:

SQL> SELECT SCOPE, NAME, CURVAL FROM DBA_ROLLING_PARAMETERS ORDER BY SCOPE, NAME;

SCOPE		     NAME				   CURVAL
-------------------- ------------------------------------ -----------------
rhdb		     INVOLVEMENT			   FULL
rhdb		     MEMBER				   NONE
rhdbstb 	     INVOLVEMENT			   FULL
rhdbstb 	     MEMBER				   TRAILING
		     ACTIVE_SESSIONS_TIMEOUT		   3600
		     ACTIVE_SESSIONS_WAIT		   0
		     BACKUP_CONTROLFILE 		   rolling_change_backup.f
		     DICTIONARY_LOAD_TIMEOUT		   3600
		     DICTIONARY_LOAD_WAIT		   0
		     DICTIONARY_PLS_WAIT_INIT		   300
		     DICTIONARY_PLS_WAIT_TIMEOUT	   3600
		     EVENT_RECORDS			   10000
		     FAILOVER				   0
		     GRP_PREFIX 			   DBMSRU_
		     IGNORE_BUILD_WARNINGS		   1
		     IGNORE_LAST_ERROR			   0
		     LAD_ENABLED_TIMEOUT		   600
		     LOG_LEVEL				   INFO
		     READY_LGM_LAG_TIME 		   600
		     READY_LGM_LAG_TIMEOUT		   60
		     READY_LGM_LAG_WAIT 		   0
		     SWITCH_LGM_LAG_TIME		   600
		     SWITCH_LGM_LAG_TIMEOUT		   60
		     SWITCH_LGM_LAG_WAIT		   1
		     SWITCH_LGS_LAG_TIME		   60
		     SWITCH_LGS_LAG_TIMEOUT		   60
		     SWITCH_LGS_LAG_WAIT		   0
		     UPDATED_LGS_TIMEOUT		   10800
		     UPDATED_LGS_WAIT		           1
		     UPDATED_TGS_TIMEOUT		   10800
		     UPDATED_TGS_WAIT			   1

31 rows selected.

    




Paso 5 (opcional): Los parámetros mostrados en la consulta anterior son configurables dentro de la ejecución del plan. Podemos usar la función DBMS_ROLLING.SET_PARAMETER para establecer valores diferentes a los default.

SQL> exec dbms_rolling.set_parameter(name=> 'ACTIVE_SESSIONS_TIMEOUT', value => 3000);

PL/SQL procedure successfully completed.

SQL> select scope, name, curval from dba_rolling_parameters where 
name='ACTIVE_SESSIONS_TIMEOUT';

SCOPE      NAME                           CURVAL
---------- ------------------------------ ------------------------------
           ACTIVE_SESSIONS_TIMEOUT        3000

    




Paso 6: una vez estén configurados nuestros parámetros podemos comenzar a ejecutar el plan, el plan es una serie de pasos y validaciones que ejecutara DBMS_ROLLING para alcanzar nuestro objetivo: actualizar nuestra base de datos.

SQL> exec dbms_rolling.build_plan;

PL/SQL procedure successfully completed. 



Hasta este momento no deberíamos de tener ningún error, podemos validar nuevamente el estado de nuestro procedimiento con las siguiente consulta:

SQL> select revision, status, phase from dba_rolling_status;

  REVISION STATUS	PHASE
---------- ------------ --------------
	 1 READY	START PENDING
     


Los pasos y validaciones del plan pueden ser consultados con la vista DBA_ROLLING_PLAN:

SQL> SELECT instid, target, phase, description FROM DBA_ROLLING_PLAN order by 1;

    INSTID TARGET	PHASE	DESCRIPTION
---------- -------      ------ ----------------------------------------
	 1 rhdb 	START	Verify database is a primary
	 2 rhdb 	START	Verify MAXIMUM PROTECTION is disabled
	 3 rhdbstb	START	Verify database is a physical standby
	 4 rhdbstb	START	Verify physical standby is mounted
	 5 rhdb 	START	Verify server parameter file exists and is modifiable
	 6 rhdbstb	START	Verify server parameter file exists and is modifiable
	 7 rhdb 	START	Verify Data Guard Broker configuration is disabled
	 8 rhdbstb	START	Verify Data Guard Broker configuration is disabled
	 9 rhdb 	START	Verify flashback database is enabled
	10 rhdb 	START	Verify available flashback restore points
	11 rhdbstb	START	Verify flashback database is enabled
	12 rhdbstb	START	Verify available flashback restore points
	13 rhdbstb	START	Stop media recovery
	14 rhdbstb	START	Drop guaranteed restore point DBMSRU_INITIAL
	15 rhdbstb	START	Create guaranteed restore point DBMSRU_INITIAL
	16 rhdb 	START	Drop guaranteed restore point DBMSRU_INITIAL
	17 rhdb 	START	Create guaranteed restore point DBMSRU_INITIAL
	18 rhdbstb	START	Start media recovery
	19 rhdbstb	START	Verify media recovery is running
	20 rhdb 	START	Verify user_dump_dest has been specified
	21 rhdb 	START	Backup control file to rolling_change_backup.f
	22 rhdbstb	START	Verify user_dump_dest has been specified
	23 rhdbstb	START	Backup control file to rolling_change_backup.f
	24 rhdb 	START	Get current redo branch of the primary database
	25 rhdbstb	START	Wait until recovery is active on the primary's redo branch
	26 rhdbstb	START	Stop media recovery
	27 rhdb 	START	Execute dbms_logstdby.build
	28 rhdbstb	START	Convert into a transient logical standby
	29 rhdbstb	START	Open database
	30 rhdbstb	START	Get redo branch of transient logical standby
	31 rhdbstb	START	Get reset scn of transient logical redo branch
	32 rhdbstb	START	Configure logical standby parameters
	33 rhdbstb	START	Start logical standby apply
	34 rhdbstb	START	Enable compatibility advance despite presence of GRPs
	35 rhdb 	START	Log pre-switchover instructions to events table
	36 rhdbstb	START	Record start of user upgrade of rhdbstb
	37 rhdbstb	SWITCH	Verify database is in OPENRW mode
	38 rhdbstb	SWITCH	Record completion of user upgrade of rhdbstb
	39 rhdbstb	SWITCH	Scan LADs for presence of rhdb destination
	40 rhdbstb	SWITCH	Test if rhdb is reachable using configured TNS service
	41 rhdb 	SWITCH	Enable log file archival to rhdbstb
	42 rhdbstb	SWITCH	Start logical standby apply
	43 rhdbstb	SWITCH	Archive all current online redo logs
	44 rhdbstb	SWITCH	Wait until apply lag has fallen below 600 seconds
	45 rhdb 	SWITCH	Log post-switchover instructions to events table
	46 rhdb 	SWITCH	Switch database to a logical standby
	47 rhdbstb	SWITCH	Wait until end-of-redo has been applied
	48 rhdb 	SWITCH	Archive all current online redo logs
	49 rhdbstb	SWITCH	Switch database to a primary
	50 rhdb 	SWITCH	Enable compatibility advance despite presence of GRPs
	51 rhdb 	SWITCH	Synchronize plan with new primary
	52 rhdb 	FINISH	Verify only a single instance is active
	53 rhdb 	FINISH	Verify database is mounted
	54 rhdb 	FINISH	Flashback database
	55 rhdb 	FINISH	Convert into a physical standby
	56 rhdbstb	FINISH	Verify database is open
	57 rhdbstb	FINISH	Save the DBID of the new primary
	58 rhdbstb	FINISH	Save the logminer session start scn
	59 rhdb 	FINISH	Wait until transient logical redo branch has been registered
	60 rhdb 	FINISH	Start media recovery
	61 rhdb 	FINISH	Wait until apply/recovery has started on the transient branch
	62 rhdb 	FINISH	Wait until upgrade redo has been fully recovered
	63 rhdb 	FINISH	Prevent compatibility advance if GRPs are present
	64 rhdbstb	FINISH	Prevent compatibility advance if GRPs are present
	65 rhdb 	FINISH	Drop guaranteed restore point DBMSRU_INITIAL
	66 rhdbstb	FINISH	Drop guaranteed restore point DBMSRU_INITIAL

66 rows selected.
    




Paso 7: iniciamos la ejecución del plan, durante este procedimiento se ejecutaran todos los pasos marcados con fase START en la consulta anterior.

SQL> exec dbms_rolling.start_plan();
    
PL/SQL procedure successfully completed.
 


Podemos validar el estado de los pasos consultando el estado actual de la base de datos Standby, si todo se ha ejecutado correcto, nuestra base de datos standby tuvo que haber sido convertida en una Logical Standby.

SQL> select revision, status, phase from dba_rolling_status;

  REVISION STATUS	PHASE
---------- ------------ ---------------
	 1 READY	SWITCH PENDING


SQL> select dbun, role, engine_status,update_progress from dba_rolling_databases;

DBUN		ROLE	     ENGINE_STATUS  UPDATE_PROG
--------------- ------------ -------------- -----------
rhdb		PRIMARY      NOT APPLICABLE NOT STARTED
rhdbstb 	LOGICAL      RUNNING	    NOT STARTED

--base de datos standby
SQL> SELECT NAME,OPEN_MODE,DATABASE_ROLE FROM V$DATABASE;

NAME	  OPEN_MODE	       DATABASE_ROLE
--------- -------------------- ----------------
RHDB	  READ WRITE	       LOGICAL STANDBY

    


Hasta ahora, hemos completado solo la primera de tres fases de la ejecución del plan, antes de continuar con el paso de switchover debemos hacer el  upgrade manual de la base de datos standby. Así que vamos a eso. El método que he elegido para actualizar la base de datos es mediante DBUA, a continuación un paréntesis en el procedimiento principal para mostrar la actualización manual de la base de datos.




Paso 8: Upgrade de base de datos Standby.

Dentro de la base de datos Logical Standby (Antes Physical Standby) rhdbstb:

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down. 


Definimos nuestras variables de entorno hacia el nuevo ORACLE_HOME, como ya mencione antes, los binarios de 18c ya fueron instalados en ambos servidores involucrados previo a comenzar con esta practica.

[oracle@stby-db db_home1]$ export ORACLE_HOME=/u02/app/oracle/product/18.3/db_home1
[oracle@stby-db db_home1]$ export PATH=$ORACLE_HOME/bin:$PATH
[oracle@stby-db db_home1]$ dbua 




Upgrade paso1: Identificar la base de datos que será actualizada, ingresar usuario y contraseña de administrador.




Upgrade paso 2: validación de requisitos, si la siguiente pantalla muestra el valor de ERROR en la columna Severity, debemos resolverla manualmente antes de continuar, de lo contrario tendremos problemas durante la ejecución final de la actualización.




Upgrade paso 3: seleccionar opciones de Upgrade, he utilizado los valores default del asistente.




Upgrade paso 4: método de recuperación en caso de errores irrecuperables, como en este caso Flashback database estaba activado como uno de los requisitos de DBMS_ROLLING puedo aprovecharlo para crear un punto de restauración en lugar de utilizar un backup de rman.




Upgrade paso 5: seleccionamos el listener que atenderá a la base de datos, utilizo el mismo que estaba usando en 12c, este será trasladado a los binarios de 18c.




Upgrade paso 6: podremos observar un resumen de las opciones seleccionadas antes de comenzar con el procedimiento de upgrade.




Upgrade paso 7: presionamos ejecutar y esperamos a que la actualización finalice correctamente.





Habiendo finalizado con este paréntesis, podemos continuar con la ejecución de nuestro plan con DBMS_ROLLING.



Paso 9: ejecutamos el procedimiento de switchover que ejecutara los pasos marcados con fase SWITCH en el listado de pasos definido por DBMS_ROLLING.

SQL> exec dbms_rolling.switchover;
    
PL/SQL procedure successfully completed. 



Para validar este paso podemos consultar los roles actuales de nuestras bases de datos:

SQL> SELECT NAME,OPEN_MODE,DATABASE_ROLE,DB_UNIQUE_NAME FROM V$DATABASE;

NAME	  OPEN_MODE       DATABASE_ROLE	   DB_UNIQUE_NAME
------    --------------  ---------------- ----------------------
RHDB	  READ WRITE	  LOGICAL STANDBY  rhdb


SQL> SELECT NAME,OPEN_MODE,DATABASE_ROLE,DB_UNIQUE_NAME FROM V$DATABASE;

NAME	  OPEN_MODE       DATABASE_ROLE	   DB_UNIQUE_NAME
------    --------------  ---------------- ----------------------
RHDB	  READ WRITE	  PRIMARY	   rhdbstb

    


Este paso es el unico dentro del procedimiento que involucra downtime ya que implica hacer un cambio de rol de nuestra base de datos primaria. El tiempo maximo que deberia de tardar el cambio de rol es de 12 segundos.

Ya estamos por finalizar asi que hasta ahora todo deberia de marchar de manera correcta.




Paso 10: upgrade de la base de datos Primaria Original, que en este momento, por el cambio de rol, debería de ser una Logical Standby.

No entraré en detalle sobre el upgrade de esta base de datos, los pasos son los mismos que los ejecutados durante el paso 8, donde actualizamos la Primaria Futura, así que pasaremos directo al paso final.




Paso 11: Si todo se ha ejecutado correctamente no queda más que finalizar la ejecución del plan de DBMS_ROLLING y ejecutar las validaciones de estados correspondientes a cada base de datos.

SQL> execute DBMS_ROLLING.FINISH_PLAN;
    
PL/SQL procedure successfully completed. 



Validaciones de rol:

SQL> select name,open_mode,database_role from v$database;

NAME	  OPEN_MODE	       DATABASE_ROLE
--------- -------------------- ----------------
RHDB	  READ WRITE	       PRIMARY


SQL> select name,open_mode,database_role from v$database;

NAME	  OPEN_MODE	       DATABASE_ROLE
--------- -------------------- ----------------
RHDB	  MOUNTED	       PHYSICAL STANDBY

    



Pasos posteriores:

  • Como recordarán, al inicio del procedimiento tenía configurado Data Guard Broker para administrar la configuración de Data Guard, uno de los prerrequisitos para usar DBMS_ROLLING fue deshabilitar esa configuracion, una vez finalizada la ejecución del upgrade podemos volver a habilitar la configuracion.

    --en cada base de datos
    SQL> alter system set dg_broker_start=false;
    
    System altered.
    
    --y luego
    DGMGRL> enable configuration
    Enabled. 


  • Otro paso importante, despues de finalizada la operación es revertir los roles actuales para obtener la configuracion original, este paso es opcional y dependerá si nuestra base de datos puede volver a tener un pequeño downtime. En mi caso, como volví a activar Data Guard Broker, el switchover se puede ejecutar de una manera más sencilla.

    DGMGRL> switchover to rhdb
    Performing switchover NOW, please wait...
    Operation requires a connection to database "rhdb"
    Connecting ...
    Connected to "rhdb"
    Connected as SYSDBA.
    New primary database "rhdb" is opening...
    Operation requires start up of instance "rhdb" on database "rhdbstb"
    Starting instance "rhdb"...
    Connected to an idle instance.
    ORACLE instance started.
    Database mounted.
    Connected to "rhdbstb"
    Switchover succeeded, new primary is "rhdb"
    
    
    DGMGRL> show configuration
    
    Configuration - dgrh
    
      Protection Mode: MaxPerformance
      Members:
      rhdb    - Primary database
      rhdbstb - Physical standby database 
    
    Fast-Start Failover: DISABLED
    
    Configuration Status:
    SUCCESS   (status updated 60 seconds ago)
    


Hasta aqui el contenido del articulo.



Julio Ayapan, Ingeniero en Ciencias y Sistemas, Administrador de base de datos Oracle con más de 4 años de experiencia en proyectos de infraestructura, Bases de Datos Oracle 10g, 11g y 12c sobre Linux y Solaris. Posee la certificación “Oracle Certified Professional 11g y 12c” y Oracle ACE Associate. Ha sido Conferencista en OTN Tour Latinoamericano 2016 y 2017 en Guatemala. Es parte de la junta directiva del Grupo de Usuarios Oracle de Guatemala (GOUG). Actualmente es Consultor de Bases de datos Oracle en eProseed Central America. Publica artículos frecuentemente en su blog http://oraclehomegt.blogspot.com. Twitter @jayapangt.

Este artículo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las normas y prácticas para el uso de los productos Oracle.