Archivo de la categoría: Errores ORA

errores ORA-16698: en la creación del data guard boker

Posted on por
Responder

Hoy vamos a ver un a entrada rápida y sencilla sobre un error bastante común en la creación de una configuración del dataguard broker.

Supongamos tenemos un dataguard funcionando y que queremos gestionar mediante el dataguard broker.

Nuestros primeros pasos serán intentar crear una configuración con

DGMGRL> create configuration cdbtest_DG as primary database is cdbtest connect identifier is cdbtest ;

Pero recibimos el siguiente error:

ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added

Si nuestro dataguard está funcionando correctamente , y esta aplicando los logs …¿A que es debido?

Si miramos en nuestra base de datos 


SQL> show parameter LOG_ARCHIVE_DEST_2 

NAME			   TYPE	 VALUE
----------------------- ------------------------------
log_archive_dest_2	   string	 service=cdbtest_standby ASYNC
					 NOAFFIRM delay=0 optional comp
					 ression=disable max_failure=0
					 max_connections=1 reopen=300 n
					 et_timeout=30 DB_UNIQUE_NAME=c
					 dbtest_standby valid_for=(onli
					 ne_logfile,all_roles)
log_archive_dest_20		     string

Esto no debería de ser problema, pero la realidad es que si que lo es, y no por un bug, sino por indicación del propio Oracle.
Para poder crear la configuración este parámetro deberá de estar limpio , así pues si lo vaciamos y ejecutamos el comando tendremos que:

SQL> alter system set log_archive_dest_2='';
System altered.
SQL> quit

[oracle@alone creacion_dataguard]$ dgmgrl sys/XX
DGMGRL> create configuration cdbtest_DG as primary database is cdbtest connect identifier  is cdbtest ;
Configuration "cdbtest_dg" created with primary database "cdbtest"
DGMGRL>

Más información en escenarios en la creación de dataguard

Trazando sqlnet en el servidor de Base de datos

Posted on por
Responder

Hoy veremos una entrada sobre diagnósticos de la base de datos.

Supongamos que tenemos algún tipo de error entre cliente y servidor en la capa OCI, la accion lógica en estos casos es activar una traza del sqlnet para detectar donde se encuentra el problema.
Si seguimos la nota de Oracle SQL*Net & Oracle Net Services – Tracing and Logging at a Glance (Doc ID 219968.1) veremos como , con las siguientes líneas deberíamos de tener en el directorio /home/oracle/trazas_problema_sqlnet una traza por cada uno de los procesos de conexion a la base de datos.

trace_level_server = 6
trace_file_server = svr
trace_directory_server = /home/oracle/trazas_problema_sqlnet
trace_unique_server = on
trace_timestamp_server = on
log_file_server = svr
log_directory_server = /home/oracle/trazas_problema_sqlnet

Sin embargo, cuando añadimos nuestros parámetros de traza vemos que en el directorio que hemos marcado para las trazas no aparece ningún fichero.
¿Que ocurre?

¿por que ocurre esto?

Si miramos la documentacion del sqlnet en https://docs.oracle.com/cd/B28359_01/network.111/b28317/sqlnet.htm#NETRF419

vemos como desde la version 11 en adelante tenemos los parámetros que funcionan con el ADDR-DIAG habilitado y los que funcionan cuando esta deshabilitado.
En nuestro caso, el problema es que al estar habilitado por defecto el diagnistico unificado de Oracle, no está haciendo caso a nuestras directrices.

¿Como lo solucionamos

La solución no puede ser mas sencilla, simplemente deberemos de decirle en el mismo sqlnet.ora que no use el diagnostico unificado de Oracle, esto lo haremos añadiendo la línea

DIAG_ADR_ENABLED = OFF

Con esto comenzará a trazar en la ubicación designada.

NOTA:
Debemos de recordar eliminar esta línea cuando acabemos de trazar ya que, ademas de poder llenar el filesystem por la traza, estamos indicando al servidor que no use el DIAG_ADR algo que no es conveniente .

Como siempre mas información en :

  • SQL*Net & Oracle Net Services – Tracing and Logging at a Glance (Doc ID 219968.1)
  • documentacion de Sqlnet

Error en el Opacth «Java (1.6) could not be located. OPatch cannot proceed!»

Posted on por
Responder

Hoy vamos a ver una solución rápida para un error común.

Cuando actualizamos el Opatch de la base de datos al ultimo OPatch(versión 6880880) podemos encontrarnos con que el binario no detecte el Java

-bash-4.2$ ./opatch lsinventory
Java (1.6) could not be located. OPatch cannot proceed!
OPatch returns with error code = 1

La solución es muy sencilla la propia instalación de binarios de Oracle cuenta con un jdk que es válido para la ejecución del Opatch, así que solamente tendremos que indicarle al Opatch donde esta esta ruta. Para ello usaremos el flag -jdk en el que le diremos que puede usar el propio $ORACLE_HOME/jdk

-bash-4.2$ ./opatch lsinventory -jdk $ORACLE_HOME/jdk
Oracle Interim Patch Installer version 12.2.0.1.9
Copyright (c) 2017, Oracle Corporation.  All rights reserved.
Oracle Home       : /opt/app/oracle/product/12.1.0/db_1
Central Inventory : /opt/app/oraInventory
   from           : /opt/app/oracle/product/12.1.0/db_1/oraInst.loc
OPatch version    : 12.2.0.1.9
OUI version       : 12.1.0.2.0
Log file location : /opt/app/oracle/product/12.1.0/db_1/cfgtoollogs/opatch/opatch2017-06-12_19_10-54PM_1.log
Lsinventory Output file location : /opt/app/oracle/product/12.1.0/db_1/cfgtoollogs/opatch/lsinv/lsinventory2017-06-12_19_10-54PM.txt
--------------------------------------------------------------------------------
Local Machine Information::
Hostname: PRUEBAS
ARU platform id: 226
ARU platform description:: Linux x86-64
Installed Top-level Products (1):
Oracle Database 12c                                                  12.1.0.2.0
There are 1 products installed in this Oracle Home.
There are no Interim patches installed in this Oracle Home.
--------------------------------------------------------------------------------
OPatch succeeded.

Como veis, una solución sencilla que nos evitará tener que lidiar con los distintos JAVA instalados en el servidor.

Como siempre, mas información en :

  • Descargar el ultimo opatch (6880880) Versión (Doc ID 274526.1)
  • Master Note For OPatch (Doc ID 293369.1)

Nuevas funcionalidades 12c: PGA_AGGREGATE_LIMIT

Posted on por
Responder

Hoy vamos a ver una entrada sencilla sobre una nueva funcionalidad de la 12c , el parámetro PGA_AGGREGATE_LIMIT

Desde la versión 9i Oracle ha apostado por la gestión automática de la memoria, uno de los problemas que generaba Al motor la gestión total de la configuración del tamaño de la PGA y SGA es que el motor podía llegar a configuraciones donde el espacio asignado a la PGA fuese muy alto, repercutiendo sobre la SGA y produciendo un exceso de paginación en la base de datos.

Como han solucionado esto ?

Sencillamente han introducido un parámetro nuevo llamado PGA_AGGREGATE_LIMIT

Este nuevo parámetro va a ser un límite del tamaño total de las PGAs de la base de datos, al contrario de lo que ocurria con PGA_AGGREGATE_TARGET que actuaba como valor de referencia , el nuevo PGA_AGGREGATE_LIMIT actúa como límite , y no solo no dejará que este valor se sobrepase, sino que eliminará sesiones que estén usando mas memoria PGA con el nuevo error ora
ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT

¿Cual es el patrón que usa oracle para matar las sesiones

El proceso de background CKPT comprueba cada tres segundos si la cantidad de memoria usada excede el parámetro PGA_AGGREGATE_LIMIT, si este límite es excedido Oracle hará lo sigiuiente

  • Las llamadas de las sesiones que están consumiendo mas PGA son abortadas.(untunable PGA memory)
  • Si el tamaño de la PGA sigue por encima del límite, las sessiones y los procesos que mas PGA usan son terminados (untunable PGA memory)
  • Los procesos de SYS y background no se ven afectados por estas reglas

El motor notifica al cliente el problema con un ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT

¿Como se calcula el valor ?

EL PGA_AGGREGATE_LIMIT es un valor dinámico , por lo que puede modificarse en cualquier momento , su valor es calculado de manera automática en el arranque por el motor al mayor de estos tres valores

  • 2 GB
  • 200% of PGA_AGGREGATE_TARGET
  • PROCESSES ( valor del parámetros de incializacion) * 3 MB
  • Nunca excederá al 120% de la memoria física menos el total del tamaño la SGA .

¿Como lo deshabilito?

Si fijamos en el spfile el valor de esta variable a cero, la base de datos se comportará como lo hacía en la version 11g, y no eliminará las sesiones que sobrepasen este límite.
Esto podemos hacerlo con :

alter system set pga_aggregate_limit=0 scope=both;

Mas información en

Problemas con la clausula EDITIONABLE en DBMS_METADATA.GET_DDL

Posted on por
Responder

Una de las librerías mas útiles de Oracle para obtener código de una base de datos es la librería DBMS_METADATA.GET_DDL.
Con la llegada de 12c tenemos la nueva funcionalidad de objetos «EDITIONABLE/NONEDITIONABLE » , si usamos la librería DBMS_METADATA.GET_DDL, el código de aplicación que nos generará incluirá esta propiedad.

Pero que pasaría al intentar ejecutarlo en otra base de datos 11g, si ejecutamos el código 

CREATE OR REPLACE EDITIONABLE PROCEDURE "ESQUEMA"."PRUEBA" (

Nos encontraremos con el error 

ERROR en línea 1:
ORA-00922: falta la opción o no es válida

¿Como mitigamos este error?
Actualmente hacemos las llamadas de la forma

DBMS_METADATA.GET_DDL('${TIPO}','${OBJETO}','${ESQUEMA}')

Simplemente tendremos que poner un parámetro adicional de compatibilidad de código ,fijándolo a la 11.2.0, que es la última versión donde no está definido el EDITIONABLE en el código 

DBMS_METADATA.GET_DDL('${TIPO}','${OBJETO}','${ESQUEMA}','11.2.0')

Como siempre ,más información en soporte

    Doc ID 2079143.1How to Remove EDITIONABLE/NONEDITIONABLE Clause when DBMS_METADATA.GET_DDL