6 comments on “Oracle Golden Gate on Exadata | Configuring ACFS”

Oracle Golden Gate on Exadata | Configuring ACFS

Good Morning Guys ! I am started on a new challenge, and my articles will be write in English Mode, because the best part of my public, and messages that I receive every day are from India, England, USA and many countrys from world.

I love the Community and promess continuing givin support and answers to a lots of mails on Spanish that I receive every week. Let’s start!

Matrix Installation

Product Version
Oracle Golden Gate 12.2.0.2.2
Exadata Image Version 12.1.2.3.6.170713
Oracle Grid Infrastructure 12.1.0.2

Pre Requisites

We’ll start with an summary of tasks that we need keep in mind to start with confguration and installation of Oracle Golden Gate on a RAC environment. It’s necessary :

  • An a share file system, we choice ACFS (ASM Cluster File System) under grid infrastructure 12.1.0
  • Oracle Golden Gate.

Creating and configuring ACFS on Exadata

When we working on an Oracle RAC environment, we must install an OGG on a cluster file system. As part of the architecture design, we choose the ACFS, but we could use NFS or DBFS.

My desicion was based on my experience with this FS and listening the council from others partners , that were used on ODA implementations.

Basically, my procedure are same that on Non Exadata Environments:

export DISPLAY=xxx.xxx.xxx.xxx:0
. oraenv
asmca

On the next screen, we can see the name of the candidate DG.

Generally, we find typically three disk groups.

  • We choose the DBFS_DG .

Oracle Exadata Database Machine Documentation Release 18c (18.1)

Tengo el agrado de comunicarles que vamos a estar compartiendo una serie de articulos de Oracle 18c en Exadata, ya que contamos con un ambiente para el despliegue.

Oracle Database 18c es la ultima generacion de Bases de Datos Oracle, ya disponible en Oracle Cloud Services , Oracle Exadata y para realizar el download.

Permite a las Empresas de diferentes rangos de Negocio, el acceso a la tecnología de base de datos más rápida, escalable y confiable, para el despliegue seguro y rentable de cargas de trabajo transaccionales y analíticas en la nube, en las instalaciones y configuraciones híbridas de la nube.

En julio de 2017, Oracle realizo una importante transición a una estrategia más flexible y acogible para el software de base de datos, con el lanzamiento de un proceso diseñado para incorporar nuevas características al mercado cada año.

Oracle Database 18c es la primer versión anual del modelo de lanzamiento de software de base de datos.

Trae nuevas funcionalidades y mejoras a los features publicados anteriormente en Oracle Database 12c, que incluye:

  •  Multitenant Architecture para un ahorro de costes masivo y agilidad.

  • In-Memory Column Store para performance de rendimiento masivas para análisis en tiempo real.

  • Native Database Sharding para alta disponibilidad de aplicaciones web masivas.

  • Más capacidades críticas para mejorar el rendimiento de la base de datos, la disponibilidad, la seguridad, análisis y desarrollo de aplicaciones

Podemos ver a la version de Oracle Database 18c, como el primer parche de la version 12c Release 2 en el modelo de la versión anterior.

De cara al futuro, los clientes ya no tendran que esperar varios años para la última generación de Oracle Database, y podra realizar la introducción a nuevas características y mejoras, de forma anual y regular.

Oracle 18c ( y las publicaciones anuales posteriores ) también figurarán de manera destacada como un componente central de los servicios de nube Autonomous Database Cloud Services, anunciados recientemente por Oracle.

En este blog estaremos realizando una revision de la presente lista de temas:

  • Licenciamiento.
  • Seguridad.
  • System Overview.

Comparto el link de la documentation oficial, de donde realizaremos el punto de partida.

Oracle Exadata Database Machine Documentation Release 18c (18.1)

Enjoy Oracle Database 18c Now !

Juan Andres Mercado | Oracle DMA

Redirecting an Oracle Restore Using SET NEWNAME

Estamos en proceso de migracion de bases de datos a nuevas versiones, y como parte del proceso, en los clientes donde no tienen licencia para OGG, procedemos con la opcion de generar un Dataguars y luego realizar el UPGRADE.

Como las versiones de las cuales migramos hacia 12.2 son 11gR2, o 12c1, de bases que no estaban bajo la tecnologia de ASM, y si en filesystem procedemos a utilizar las opciones en el restore el set de comandos:

  • SET NEWNAME FOR DATABASE
  • SET NEWNAME FOR TABLESPACE

Con estos comandos es importante espcificar las varibles de paths de discos, para evitar problemas y que las piezas se restoreen donde es indicado:

Problema

En este caso en particular, el inconveniente que nos encontramos fue:

El TABLESPACE SYSTEM, contenia datafiles con el mismo nombre en el path /data01/datafiles y el path /data02/datafiles , provenientes del SOURCE y no teniendo habilitada la caracteristica OMF:

channel ORA_DISK_16: restoring datafile 00073 to +DATA_EXA2A/undotbs1.002.dbf
channel ORA_DISK_16: restoring datafile 00086 to +DATA_EXA2A/a_txn_data23.dbf
channel ORA_DISK_16: reading from backup piece /backup/EBSPROD/full_backup_diario_dbf_PROD_20180118_t965701613_p1_s92352.bkp
channel ORA_DISK_12: ORA-19870: error while restoring backup piece /backup/EBSPROD/full_backup_diario_dbf_PROD_20180118_t965698895_p1_s92347.bkp
ORA-19504: failed to create file "+DATA_EXA2A/system12.dbf"
ORA-17502: ksfdcre:4 Failed to create file +DATA_EXA2A/system12.dbf
ORA-15005: name "system12.dbf" is already used by an existing alias

Procedimiento

Para evitar colicionamiento de nombres, hay que especificas al menos una de las varibles, donde sustituiremos el nombre de los datafiles repetidos provenientes de diferentes filesystems.

Exadata Apply patch post upgrade

Instalación de Parche en Exadata X5

Cuando administramos un Oracle Exadata Machine es importante encontrarnos con el roadmap actualizado de la fixes de seguridad, patchsets, etc.

Como parte de estas tareas que nos previenen de bugs y otras incidencias, como así también poder migrar los motores de bases de datos, es que decidimos hacer un upgrade  poder llevar a la ultima release de la versión de GridInfra Structure, realizando el upgrade a 12.1.0.2 y decidimos hacer este trabajo en modo rolling :

Verificamos la release actual:

[oragrid@exa2adbadm01 ~]$ crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [12.1.0.0.0]

Stopeamos los servicios del nodo del Cluster:

Run the pre root script.
As the root user execute:

# /crs/install/rootcrs.pl -unlock
2 comments on “Exadata Opatch found error changing permission during 12.1.0.2.170117 patch installation”

Exadata Opatch found error changing permission during 12.1.0.2.170117 patch installation

chmod: changing permissions of ‘$ORACLE_HOME/bin/extjobO’:Operation not permitted”

Como parte de nuevas políticas que propusimos en la empresa donde nos encontramos brindando servicios, como políticas de Roadmap de Equipos de computo, bases de datos y otros sistemas, comenzamos con un trabajo de actualizacion de Oracle Database Machine X5.

A raíz de realizar el UPGRADE de Grid Infraestructure, desde 11.2.0.4 hacia 12.1.0.2 , luego de ejecutar los pasos con opatch, nos encontramos con siguiente WARNING:

 [OPSR-TIME] Backup area for restore has been cleaned up. For a complete list of files/directories
 deleted, Please refer log file.
 Composite patch 26609798 successfully applied.
 UtilSession: N-Apply done.
 --------------------------------------------------------------------------------
 The following warnings have occurred during OPatch execution:
 1) OUI-67215:
 OPatch found the word "error" in the stderr of the make command.
 Please look at this stderr. You can re-run this make command.
 Stderr output:
 chmod: changing permissions of `/u01/app/grid/12.1.0.2/bin/extjobO': Operation not permitted
 make: [iextjob] Error 1 (ignored)
 --------------------------------------------------------------------------------
 OUI-67008:OPatch Session completed with warnings.
 Finishing UtilSession at Wed Nov 29 14:53:02 ART 2017
 Log file location: /u01/app/grid/12.1.0.2/cfgtoollogs/opatch/opatch2017-11-29_14-38-07PM_1.log

Dont Worry, Be happy

Es un bug de Oracle y en la nota de Support Doc ID (2265726.1) dice que debemos ignorarlo.

Debo decir que de forma previa ejecute el rollback del patch y lo aplique nuevamente y el problema desaparecio.

opatch rollback -id <PATCH_ID>
opatch apply

Voila !

Analyzing SQL with SQL Tuning Advisor on Cloud Control 12c

Buenas Tardes Amigos, esta semana estuvimos realizando tareas de peformance en algunos customers puntuales.

Me sentí alegre, al poder recordar varias buenas practicas de Oracle con las cuales ya venimos operando con los consultores que están en mi equipo.

Problemática

  • Nos encontramos con aplicaciones que esta semana introdujeron un ciclo de cambios en producción mediante diferentes deploys.
  • Algunos querys pasaron de tiempos medidos en , mili segundos, segundos a minutos.
  • algunas aplicaciones dejaron de responder a tareas puntuales por medio time out.

Plan de acción

Como plan de acción (que ampliare en varios artículos de esta semana) decidimos hacer unas serie de tareas de monitoreo y con ello, proponer mejoras.

En el articulo de hoy, utilizaremos la herramienta Cloud Control, pero también comenzaremos a realizar las tareas por linea de comandos con el uso de los scripts sqltrpt.sql que nos servirá en caso de estar en un Customer , en donde no tengamos acceso a dicha herramienta o no esta instalado.

Cloud Control

En Cloud control , con el nombre de nuestra instancia de base de datos que fue seleccionada para ser analizada, usamos el siguiente proceso:

Performance >> Top Activity

En el browser podemos observar un escenario parecido a este:

Exadata | Password Expiration Policy

Password Expiration Policy on Exadata

Hubo momentos en los que realizamos tareas de soporte o de implementaciones en diferentes customers, notando que los administradores no se encontraban bajo politicas de seguridad SOX o bajo reglamentaciones standart y que contaban con practicas como:

  • Actividades con Cron (Practica no recomendada)
  • JOBS desde consolas web, con el usuario oracle. (Practica no recomendada, se recomienda usar otro user mon)
  • otras tareas de administracion con el usuario oracle u oragrid , o grid.

Pudimos observar que al intentar loguearnos con el usuario oracle, que se nos solicito cambiar la contraseña por que la misma se encontraba expirada.

Por ello decidimos utilizar el comando chage para poder actualizar nuestra policy de expiracion.

Ejecutamos el comando chage con el wildcard -h para poder comprender mejor las opciones:

La salida se corresponde con todas las opciones