ORA-15124: ASM file name contains an invalid alias name

El error aparece en el momento de realizar cualesquieras de las siguientes tareas:

  • startup mount
  • startup nomount

En nuestro caso en particular ocurre en el momento de montaje luego de realizar el restore del controlfile.

RMAN> sql 'alter database mount standby database';
ORA-15124: ASM file name '+DATA_EXA2A/ebsprod/controlfile/current.695.965565833' contains an invalid alias name

La solucion ofrecida:

  • Cambiar los db_file_name_conver de forma prolija
  • Verificar que tenga commilas simple y que esten debidamente separadas.
SQL> alter system set log_file_name_convert='/data1/oracle/PROD/db/apps_st/data','+DATA_EXA2A','/data2/oracle/PROD/db/apps_st/data','+DATA_EXA2A','/data1/oracle/PROD/db/apps_st/archives','+RECO_EXA2A' scope=spfile sid='*';

Entendiendo las diferencias:

Antes
-----
'/data1/oracle/PROD/db/apps_st/data,+DATA_EXA2A','/data2/oracle/PROD/db/apps_st/data,+DATA_EXA2A','/data1/oracle/PROD/db/apps_st/archives,+RECO_EXA2A'

Despues
-------
'/data1/oracle/PROD/db/apps_st/data','+DATA_EXA2A','/data2/oracle/PROD/db/apps_st/data','+DATA_EXA2A','/data1/oracle/PROD/db/apps_st/archives','+RECO_EXA2A'

 

How to Check Clusterware Version and Name on Cluster Upgrades

Como comentara en uno de los últimos posts de UPGRADE de Cluster, fue necesario conocer la release.

Pero en ocasiones siempre doy por hecho que todo el mundo conoce de lo que estoy hablando.

Esta semana me han escrito alguno colegas preguntando como obtengo esas salidas.

Aquí mi respuesta …

Cluster Software Version

Nos posicionamos en un nodo, de los n nodos que tengamos.

Si estamos realizando tareas en modo rolling upgrade , podríamos utilizar softwareversion que nos muestra la ultima versión del software, que obtuvo el ultimo start sucesfully en un determinado nodo.

crsctl query crs softwareversion [node_name]

Ejemplo de la ejecución en el mismo nodo donde nos encontramos

[oragrid@exa2adbadm01 ~]$ crsctl query crs softwareversion
Oracle Clusterware version on node [exa2adbadm01] is [12.1.0.2.0]

Ejemplo de ejecucion en un nodo remoto.

[oragrid@exa2adbadm01 ~]$ crsctl query crs softwareversion exa2adbadm02
Oracle Clusterware version on node [exa2adbadm02] is [12.1.0.2.0]

Cluster Active Version

Ahora bien, (más…)

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

(más…)

Big Data | Data Governance Initiative 

Importancia del Gobierno de Datos e implicancias

Hoy vamos a estar analizando algunos puntos donde debemos hacer foco en el Gobierno de Datos.

Es importante entender que con el volumen de datos que es generado a diario, este debe ser observado como un todo para ser administrado, mejorado y dar un mayor aprovechamiento de nuestra información, para que ella misma pueda ayudarnos a generar una percepción de calidad y poder generar confianza en la toma de decisiones y operaciones que deriven de ellas en la organización.

Cuando carecemos de un Gobierno de Datos, los datos no se integran como un todo, y ellos no tienen una visión general desde la organización, si no que queda acotada a la visión de cada departamento que actúa con ella. (Podríamos decir marketing, finanzas o sistemas).

Así mismo, podemos inferir que el Gobierno de datos toma el rol de organizar, controlar , coordinar las diferentes departamentos de la empresa, de manera interactiva que derivan en definición de Roles y Responsabilidades.

Este escenario nos permite establecer standares, políticas y procesos.

Entendiendo el mínimo concepto de que es el gobierno de datos procederemos a conocer los 5 puntos en que debemos focalizarnos para poder analizar y gobernar:

  • Social Media.
  • IoT (Internet of things).
  • Grandes volúmenes de datos transaccionales.
  • Datos Biometricos.
  • Datos Generados por la Humanidad.

(más…)

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 !