Archivo de la categoría: Errores ORA

Error PRKO-2207 : Warning:–spfile option has been deprecated and will be ignored

Posted on por
Responder

Hoy me he encontrado con un eroor curioso.
Cuando he intentado modificar la ubicacionn del spfile con el comando

srvctl modify asm -spfile +DATA/ASM/ASMPARAMETERFILE/initasm.ora

El sistema me ha devuelto el error
PRKO-2207 : Warning:-spfile option has been deprecated and will be ignored

Cual ha sido mi sorpresa al ver que la modificacion del spfile o el listener en el asm con el comando srvctl esta deprecated.
Segun lanota de soporte «PRKO-2207 : Warning:-spfile option has been deprecated and will be ignored» for ASM instance (Doc ID 2227045.1) la manera de llevarlo a cabo ahora es mediante os comandos de oracle, estoson:

Problemas con el fichero crsgenconfig_params al intentar extender un rac

Posted on por
Responder

Hoy vamos a ver un caso curioso .

En el proceso de añadir un nodo en el rac nos encontramos con el error

2021/02/10 20:14:04 CLSRSC-594: Executing installation step 4 of 19: 'GenSiteGUIDs'.
oracle.ops.mgmt.cluster.ClusterException: scp: /u01/app/19c/grid/crs/install/crsgenconfig_params: No such file or directory

2021/02/10 20:14:06 CLSRSC-180: An error occurred while executing the command '/u01/app/19c/grid/bin/cluutil -copy -sourcefile /u01/app/19c/grid/crs/install/crsgenconfig_params -fromnodesfile /tmp/7pqMR5nHtf -destfile /u01/app/19c/grid/crs/install/crsgenconfig_params -nodelist rac1'
2021/02/10 20:14:06 CLSRSC-571: failed to copy file '/u01/app/19c/grid/crs/install/crsgenconfig_params' from node 'rac2' to file '/u01/app/19c/grid/crs/install/crsgenconfig_params' on local node
Died at /u01/app/19c/grid/crs/install/crsutils.pm line 15809.

Afortunadamente el error es claro , nos falta el fichero /u01/app/19c/grid/crs/install/crsgenconfig_params del nodo del que estamos extendiendo el rac, lo que hace que falle el punto 4 de la ejecucion del root.sh
Si buscamos por internet veremos varias entradas en las que nos indican que es un problema en la descompresion de los paquetes originales, lo que no nos ayuda.
La ayda viene en la nota 12.2 GI Upgrade fails with : CLSRSC-635: Failed to get EXTENDED_CLUSTER_SITE_GUIDS (Doc ID 2259672.1)
En la que nos indican que solo hemos de poner el EXTENDED_CLUSTER_SITE_GUIDS en ese fichero y reejecutar el root.sh

La idea parece buena, pero … cual deberia de ser el contenido de ese fichero ?

El contenido de ese fichero es el siguiente

EXTENDED_CLUSTER_SITE_GUIDS=rac

Donde, el valor del campo EXTENDED_CLUSTER_SITE_GUIDS es el mismo que aparece en el campo CLUSTER_NAME del fichero /opt/app/19c/grid/crs/install/crsconfig_params

CLUSTER_TYPE=DB
VNDR_CLUSTER=false
OCR_LOCATIONS=
CLUSTER_NAME=rac
NODE_NAME_LIST=rac1,rac2
PRIVATE_NAME_LIST=
VOTING_DISKS=
#VF_DISCOVERY_STRING=%s_vfdiscoverystring%

Mas informacion en

  • 12.2 GI Upgrade fails with : CLSRSC-635: Failed to get EXTENDED_CLUSTER_SITE_GUIDS (Doc ID 2259672.1)

Errores Heap size XX exceeds notification threshold

Posted on por
Responder

Hoy vamos a volver con las entradas para dummies

Uno de las alertas con las que podemos encontrarnos en el fichero de log es :

2019-08-25T21:51:19.646997+01:00
PDB$SEED(2):Memory Notification: Library Cache Object loaded into SGA
Heap size 52942K exceeds notification threshold (51200K)
Details in trace file /u01/app/oracle/diag/rdbms/test/TEST/trace/TEST_ora_32087.trc
2019-08-25T21:51:19.647135+01:00
PDB$SEED(2):KGL object name :grant read on ku$_m_view_piot_view to public
2019-08-25T21:51:33.513723+01:00
PDB$SEED(2):Memory Notification: Library Cache Object loaded into SGA
Heap size 52903K exceeds notification threshold (51200K)
Details in trace file /u01/app/oracle/diag/rdbms/test/TEST/trace/TEST_ora_32087.trc
2019-08-25T21:51:33.513818+01:00
PDB$SEED(2):KGL object name :grant read on ku$_zm_view_piot_view to public

A pesar del susto que nos puede dar esta alerta , no se trata de un error, sino de un warning. A partir de la version 10g oracle introdujo un umbral a partir del cual nos avisa cuando superamos ese umbral en la carga de objetos en el shared pool .
Este umbral viene definido por el parametro oculto _kgl_large_heap_warning_threshold

Si queremos saber el valor actual de este valor podemos ejecutar la consulta

[code lang=»sql»]
select
nam.ksppinm NAME,
nam.ksppdesc DESCRIPTION,
val.KSPPSTVL
from
x$ksppi nam,
x$ksppsv val
where nam.indx = val.indx and nam.ksppinm like ‘%kgl_large_heap_%_threshold%’;
[/code]

En caso de que quieresemos que dejasen de apareer alertas (especialmente por que vienen asociadas a una traza ) podemos modificar el parametro con :

 alter system set "_kgl_large_heap_warning_threshold"=XXXXXX   comment='motivo aqui ' scope=spfile;

Como podeis ver, hemos de acutalizar en el spfile por lo que habra que reiniciar la base de datos si quremos que haga efecto

Como siempre podemos tener mas informacion en la nota de soporte KGL-heap-size-exceeded] (Doc ID 330239.1)

DIA-49803: Purge not possible due to incompatible schema version.

Posted on por
Responder

Hoy vamos a ver una sencilla entrada que tiene que ver con el adrci ( Interprete de comandos ADR ).
El otro dia me encontre con que algunos de los automatismos de limpieza de logs fallaban con el eror DIA-49803: Purge not possible due to incompatible schema version

[oracle@testserver ~]$ adrci
ADRCI: Release 12.1.0.2.0 - Production on Thu Mar 16 09:34:45 2019
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
ADR base = "/u01/app/oracle/admin"
adrci> show homes
ADR Homes: 
diag/rdbms/test1/TEST1
diag/rdbms/test2/TEST2
adrci> purge -age 180 -type alert   
DIA-49803: Purge not possible due to incompatible schema version.

A que puede deberse esto ?
Si miramos en la documentacion de soporte de Oracle nos encontramos con algunos poibles bugs , como el bug Bug 27718599 o un efecto secundario del bug 28375106.
Pero, antes de meterse en berenjenales, lo mas sencillo es intentar migrar la version de los logs.

Como lo hacemos?

Algo tan sencillo como 

adrci> migrate schema
Schema migrated.

Tras la ejecucion de este sencillo comando, veremos como nuestros comandos vuelven a funcionar correctamente

Errores psdgbt: bind csid (X) does not match session csid (YY)

Posted on por
Responder

Hoy vamos a ver una entrada rapida y sencilla que nos ayudara a evitar una cascada de errores en el alert.log

Es posible que, la reiniciar alguna e nuestras bases de datos que se encuentran bajo la monitorizacion de un Enterprise manager veamos que el alert.log de nuestra base de datos comienza a mostrar continuamente errores del tipo 

Errors in file /u01/app/oracle/diag/rdbms/TEST_stby/TEST/trace/TEST_ora_743.trc:
Mon March 11 12:24:47 2019
Errors in file /u01/app/oracle/diag/rdbms/TEST_stby/TEST/trace/TEST_ora_743.trc:
Mon March 11 12:25:06 2019
Errors in file /u01/app/oracle/diag/rdbms/TEST_stby/TEST/trace/TEST_ora_743.trc:

Si comprobamos la traza podemos ver como se trata de errores del tipo

psdgbt: bind csid (1) does not match session csid (46)
psdgbt: session charset is XXX

Donde el charset variara en funcion de nuestra base de datos, veamos una de estas trazas

ORACLE_HOME = /u01/app/oracle/product/12.1.0/db
System name: Linux
Node name: test.pamplona.name
Release: 3.8.13-118.19.12.el6uek.x86_64
Version: #2 SMP Tue Oct 31 12:31:15 PDT 2017
Machine: x86_64
Instance name: TEST
Redo thread mounted by this instance: 1
Oracle process number: 32
Unix process pid: 743, image: oracle@test.pamplona.name

*** 2019-03-11 21:20:06.886
*** SESSION ID:(2.57596) 2019-03-11 21:20:06.886
*** CLIENT ID:() 2019-03-11 21:20:06.886
*** SERVICE NAME:() 2019-03-11 21:20:06.886
*** MODULE NAME:(emagent_SQL_oracle_database) 2019-03-11 21:20:06.886
*** CLIENT DRIVER:(jdbcthin) 2019-03-11 21:20:06.886
*** ACTION NAME:(ME$icc_dbs_age_last_backup) 2019-03-11 21:20:06.886

psdgbt: bind csid (1) does not match session csid (46)
psdgbt: session charset is WE8ISO8859P15

*** 2019-03-11 21:20:06.886
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=1, mask=0x0)
—– Error Stack Dump —–
—– Current SQL Statement for this session (sql_id=a0qc12302fzfk) —–
begin dbms_application_info.set_module(:1 , :2 ); end;

La solucion para este problema es muy muy sencila, simplemente, reinicia el agente del enterprise manager del servidor donde se encuentra ubicada la base de datos.

Como siempre, mas informacion en soporte de Oracle
Doc ID 956222.1