Archivo de la categoría: 12c

Restaurar el fichero de registro del cluster/GRID

Posted on por

Hoy vamos a ver una entada bastante sencilla que nos puede librar de algun susto que otro.

Uno de los componentes que pueden darnos problemas a la hora de arrancar un GRID es el fichero de configuración del cluster.
En el caso de un GRID control donde no hay mas miembros del cluster, esta información solamente está en el nodo de la base de datos, y , si esta información se daña o se pierde no podremos arrancar el ASM y la Base de datos
El fichero de configuración local del cluster/grid puede ubicar mirando en el fichero /etc/oracle/ocr.loc

  bash-3.2# cat /etc/oracle/ocr.loc
ocrconfig_loc=/opt/app/oracle/product/11.2.0/grid/cdata/localhost/local.ocr
local_only=TRUE

El GRID control tiene dos ficheros de configuración que deben de estar disponibles, el Oracle Cluster Registry configuration y el Oracle Local Registry configuration
Podemos ver su ubicación con el comando ocrconfig

root@gridalone:$ $GRID_HOME/bin/ocrcheck -config
Oracle Cluster Registry configuration is :
 Device/File Name: /opt/app/oracle/product/11.2.0/grid/cdata/localhost/local.ocr

root@gridalone:$ $GRID_HOME/bin/ocrcheck -local -config
Oracle Local Registry configuration is :
 Device/File Name: /opt/app/oracle/product/11.2.0/grid/cdata/localhost/sidora.olr

Estos dos ficheros no son ficheros de texto, con lo que no podremos salvaguardarlos ni restaurarlos de manera normal mediante los softwares de backup convencionales.
Para poder restaurarlos, deberemos de hacerlo mediante la opcion ocrconfig -restore

La sintaxsis para restaurarlos es :

Oracle Cluster Registry configuration

$GRID_HOME/bin/ocrconfig  -restore /opt/app/oracle/product/11.2.0/grid/cdata/localhost/backup_XXXXX.ocr

Oracle Local Registry configuration 

$GRID_HOME/bin/ocrconfig -local -restore /opt/app/oracle/product/11.2.0/grid/cdata/localhost/backup_XXXXX.olr

Algunas notas importantes sobre el comando ocrconfig son :

  • No se le indica en ningún sitio donde ha de restaurarlos, esto lo coge de la configuración del cluster
  • Los ficheros que se indican son los ficheros DE BACKUP
  • Necesita que el fichero destino exista, en caso de no existir habría que crearlos con un touch

Hemos de tener en cuenta que, tal y como decíamos en la entrada Oracle cluster registry OCR (componentes del grid) en la version 11gR2 se guardan automáticamene, pero no debemos de confiarnos y es recomendable el comprobar si exsisten backups con la opcion ocrconfig -showbackup para activarlos en caso de que no estén activos

Como siempre, mas información en la web de oracle http://docs.oracle.com/cd/E11882_01/rac.112/e16794/ocrsyntax.htm#CWADD92022

IMPDP con tablas particionadas

Posted on por

Hoy vamos a una entrada muy sencilla y corta, pero que puede salvarnos de algún que otro desastre.

¿Es posible truncar/reemplazar una única particion en una tabla durante un proceso de IMPDP?

La respuesta es rápida y clara . No
La documentacion de oracle indica claramente:
If you attempt to use Data Pump parameter table_exists_action=truncate, or even the replace option
be aware that the complete table will be truncated, not just the partition being imported!

Más información en la nota a a Single Partition be Truncated during Data Pump Import? (Doc ID 877792.1)

Uso de mayúsculas/minúsculas en ASM

Posted on por

Vamos a ver una entrada muy cortita sobre el uso del ASM.

¿Son los ficheros/directorios del ASM sensibles a las mayúsculas y minúsculas?

Si miramos la documentación del ASM de Oracle nos dice una frase algo enigmática
«Only the forward slash (/) is supported by ASMCMD. Filenames are not case sensitive, but are case retentive. If you type a path name as lowercase, ASMCMD retains the lowercase. «

Lo que quiere decir es que, los nombres de los ficheros (y directorios) de ASM no son case sensitive, pero, las cadenas de texto con la que nos lo muestra si.

Vamos a verlo con un ejemplo:

Supongamos tenemos ASM con una base de datos llamada SID.
He creado dos tablespaces con datafiles en SID y siD y no me ha dado error en ninguno de los dos

create tablespace prueba1 datafile '+DATA/SID/prueba1.dbf' size 3m;
create tablespace prueba2 datafile '+DATA/siD/prueba2.dbf' size 3m;

Sin embargo, si intento crear 

create tablespace prueba3 datafile '+DATA/SID/prueba2.dbf' size 3m;

Me da error por que ya existe el mismo fichero con el directorio siD

Conclusión: ASM no es «case sensitive», pero hemos de ser muy cuidadosos a la hora de elegir una política para la notación de los ficheros ya que el uso indiscriminado de unos y otros puede provocarnos errrores.

Obtener el código de un objeto con DBMS_METADATA.GET_DDL

Posted on por

En alguna otra entrada hemos visto el uso de la llamada DBMS_METADATA.
Hoy vamos a ver las pequeñas peculiaridades que rodean a la variable para poder extraer el código de varias tablas.

La primera de las cosas a tener en cuenta es el formateo de la salida.
Hemos de prever el tamaño del código de las tablas, con lo que deberemos de formatear el sqlplus, para ellos pondremos la línea al máximo permitido y un valor muy alto en long

set head off
set feedback off
set pages 0
set linesize 32767
set long  2000000

Lo segundo que hemos de tener en cuenta es que , no vamos a tener ningún tipo de carácter que nos marce la separación entre las sentencias, con lo que deberemos de decirle a la librería dbms_metadata que nos marque el carácter. Ese parámetro es un parámetro de sesión con lo que deberemos de ejecutarlo en cada sesión en la que queramos obtener los datos.

exec dbms_metadata.set_transform_param 
   (DBMS_METADATA.SESSION_TRANSFORM, 'SQLTERMINATOR',TRUE);

A partir de aquí ya podemos usar la llamada DBMS_METADATA.GET_DDL para obtener el código deseado :

select DBMS_METADATA.GET_DDL
 ('TABLE','NOMBRE_TABLA','OWNER') 
      from dual ;

Nota En el caso de las tablas podemos seleccionar algunas de las características que queremos mostrar (incluso transformarlas) como pueden ser las de almacenamiento o particionamiento con la opción SET_TRANSFORM_PARAM.

Mas información en lamágina de DBMS_METADATA de la documentación de Oracle.

Desinstalar el agente del oem12c

Posted on por

Una de las cosas que hay que llevar a cabo cuando se utiliza el Enterprise Manager de Oracle es el instalar/desisntalar los agentes.
Bien sea por que queremos actualizarlos, limpiar la máquina o simplemente por que decidimos hacerlo, tenemos que poder quitar los agentes de oracle.

Lo primero siempre será pararlo
parar_agente

Si el agente se ha instalado de manera correcta, no deberíamos de tener muchos problemas para desinstalarlo, ya que debe de estar contenido en el inventario y deberíamos de poder eliminarlo sin problemas.
Por ejemplo, en el caso de un equipo windows, deberíamos de poder eliminarlo desde el propio oracle installer.

desinstall_oem12c_win

En el caso de un sistema Unix, el encontrar en instalador suele ser mas complicado, por lo que lo tendremos que parar a mano.

Una de las maneras mas sencillas de encontrarlo es mirar en el fichero
 /etc/oragchomelist

/opt/app/oracle/product/oem12/agent12c/core/12.1.0.4.0:/opt/app/oracle/product/oem12/agent12c/agent_inst

/opt/app/oracle/product/oem13/agent13c/agent_13.2.0.0.0:/opt/app/oracle/product/oem13/agent13c/agent_inst

Aqui podemos ver como tenemos los agentes de la version 12 y 13.

Para eliminar el de la 12 deberiamos de

1- Parar el agente

/opt/app/oracle/product/oem12/agent12c/agent_inst/bin emctl stop agent

2- mediante el comando  AgentDeinstall.pl que nos eliminará la instalación del inventario y si se lo pedimos nos eliminará tambien el $AGENT_HOME

[server@OEM12c] export AGENT_HOME=/opt/app/oracle/product/12.1.0.3/oem12/
agent12c
core/12.1.0.4.0
[server@OEM12c] $AGENT_HOME/sysman/install/AgentDeinstall.pl -agentHome $AGENT_HOME
 Agent Oracle Home: /opt/app/oracle/product/12.1.0.3/oem12/core/12.1.0.4.0
aentHome = /opt/app/oracle/product/12.1.0.3/oem12/core/12.1.0.4.0

NOTE: The agent base directory: /opt/app/oracle/product/12.1.0.3/oem12 will be removed after successful deinstallation of agent home.


 DetachHome Command executed:/opt/app/oracle/product/12.1.0.3/oem12/core/12.1.0.4.0/oui/bin/runInstaller -detachHome -force -depHomesOnly -silent ORACLE_HOME=/opt/app/oracle/product/12.1.0.3/oem12/core/12.1.0.4.0 -waitForCompletion -invPtrLoc /opt/app/oracle/product/12.1.0.3/oem12/core/12.1.0.4.0/oraInst.loc
Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB.   Actual 53247 MB    Passed
The inventory pointer is located at /opt/app/oracle/product/12.1.0.3/oem12/core/12.1.0.4.0/oraInst.loc
'DetachHome' was successful.
Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB.   Actual 53247 MB    Passed
The inventory pointer is located at /opt/app/oracle/product/12.1.0.3/oem12/core/12.1.0.4.0/oraInst.loc
The Oracle home '/opt/app/oracle/product/12.1.0.3/oem12/sbin' could not be updated as it does not exist.


Deinstall Command executed:/opt/app/oracle/product/12.1.0.3/oem12/core/12.1.0.4.0/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/opt/app/oracle/product/12.1.0.3/oem12/core/12.1.0.4.0}" -waitForCompletion -removeAllFiles -invPtrLoc /opt/app/oracle/product/12.1.0.3/oem12/core/12.1.0.4.0/oraInst.loc
Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB.   Actual 53247 MB    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2018-03-21_09-43-48AM. Please wait ...Oracle Universal Installer, Version 11.1.0.12.0 Production
Copyright (C) 1999, 2014, Oracle. All rights reserved.

Starting deinstall


Deinstall in progress (Thursday, March 21, 2018 9:43:56 AM CET)
Configuration assistant "Agent Deinstall Assistant" succeeded
............................................................... 100%

 Done.

Deinstall successful

End of install phases.(Thursday, March 21, 2018 9:44:10 AM CET)
End of deinstallations
Please check '/opt/app/oraInventory/logs/silentInstall2018-03-21_09-43-48AM.log' for more details.

NOTE: The targets monitored by this Management Agent will not be deleted in the Enterprise Manager Repository by this deinstall script. Make sure to delete the targets manually from the Cloud Control Console for a successful deinstallation.


Deinstall successful

Como veis, no es algo a lo que debamos temer.

La información completa de como llevarlo a cabo, como siempre en la documentación de Oracle
http://docs.oracle.com/cd/E24628_01/install.121/e24089/deinstall_agent.htm#CBBJEHDI