Este es un caso de incidencia real acontecida en un entorno HP-UX aunque posteriormente tambien se reporto en un AIX, entiendemos que se puede producir en cualquier otro S.O.
Por los motivos que sea se debe reiniciar un listener ya sea por opertavia automática o de forma manual.
La cosa es que no vuelve a levantar debidamente, reportando un error similar al siguiente:
LSNRCTL> START
Starting /oracle/app/oracle/product/920/bin/tnslsnr: please wait…
TNSLSNR for HPUX: Version 9.2.0.6.0 – Production
System parameter file is /oracle/app/oracle/product/920/network/admin/listener.ora
Log messages written to /oracle/app/oracle/product/920/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.177.6.32)(PORT=1521)))
Error listening on: (ADDRESS=(PROTOCOL=ipc)(PARTIAL=yes)(QUEUESIZE=1))
No longer listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.177.6.32)(PORT=1521)))
TNS-12546: TNS:permission denied
TNS-12560: TNS:protocol adapter error
TNS-00516: Permission denied
HPUX Error: 13: Permission denied
La solución pasa por revisar el fichero sqlnet.ora dicho fichero es posible que contenga los siguientes parametros:
tcp.validnode_checking = yes
tcp.excluded_nodes = ( aaa.es, bbb.com ,...)
Si lo encontramos tenemos dos opciones:
1. Tenemos prisa, no podemos esperar; cambiamos el parametro tcp.validnode_checking =no o comentamos ambos.
2. Podemos revisarlo con cierta "tranquilidad", se deberia probar si desde el host del listener podemos resolver los nombres indicados en tcp.excluded_nodes, quitando de la lista los no accesibles.
Una vez realizadas las dos acciones y tras guardar los cambios de sqlnet.ora; podriamos iniciar el listener sin dicho error.
lunes, 24 de marzo de 2014
jueves, 6 de marzo de 2014
Ficheros de traza y dump
Lo primero que haremos es mantener la calma y no lanzarnos a borrar ficheros como posesos ya que podríamos perder información importante que nos puede ayudar a solucionar un problema mayor que el propio hecho de que se nos llene un filesystem. En función del espacio que nos quede en el disco procederemos a comprimir los ficheros o a moverlos a otra ubicación por si nos fuera necesario consultarlos más adelante.
Al inicio de estos ficheros de traza ( .trc ) tenemos una serie de información que nos será muy útil para localizar el proceso que ha generado dicho fichero. Uno de los "campos" que más información nos va a dar es el "campo" MODULE_NAME. En nuestro caso hemos podido ver que la aplicación de monitorización del sistema es la que estaba provocando la generación de estos ficheros de traza.
En la versión 11g tenemos la aplicación ADR (Automatic Diagnostic Repository) que nos permite definir la gestión que queremos realizar de estos ficheros de traza y por lo tanto definir el número de días que queremos guardar. Está claro que cuando se produce una generación masiva de ficheros de traza con un tamaño importante deberemos aplicar otras medidas que ahora explicaremos.
La limpieza automática de los ficheros de traza y ficheros dump la realiza el proceso MMON y se basa en los valores que tenemos definidos en ADR. Para ello tenemos 2 atributos que podemos definir:
- LONGP_POLICY (long term): por defecto este atributo tiene un valor de 365 días y se encarga de gestionar incidentes y avisos del Health
- SHORTP_POLICY (short term): por defecto este segundo atributo tiene un valor de 30 días y se encarga de gestionar los ficheros de traza y dump
Para ver estos valores y/o modificarlos utilizaremos adrci. A continuación os mostramos algunos comandos útilies:
1. Ver los valores actuales: show control
ADRCI: Release 11.1.0.7.0 - Production on Fri Mar 7 01:17:20 2014
Copyright (c) 1982, 2007, Oracle. All rights reserved.
ADR base = "/u02/shared_admin1/PANDORAP"
adrci> show control
ADR Home = /u02/shared_admin1/PANDORAP/diag/rdbms/pandorap/PANDORAP:
*************************************************************************
ADRID SHORTP_POLICY LONGP_POLICY LAST_MOD_TIME LAST_AUTOPRG_TIME LAST_MANUPRG_TIME ADRDIR_VERSION ADRSCHM_VERSION ADRSCHMV_SUMMARY ADRALERT_VERSION CREATE_TIME
-------------------- -------------------- -------------------- ---------------------------------------- ---------------------------------------- ---------------------------------------- -------------------- -------------------- -------------------- -------------------- ----------------------------------------
188366471 2 3 2014-03-06 22:15:42.214130 +01:00 2014-02-27 01:28:51.843695 +01:00 2014-03-06 20:58:54.281200 +01:00 1 2 65 1 2010-02-01 15:48:44.829787 +01:00
1 rows fetched
adrci>
2. Modificar los valores actuales: set control
adrci> set control (longp_policy = 60) el valor informado es el número de días que queremos mantener
adrci> set control (shortp_policy = 15) el valor informado es el número de días que queremos mantener
adrci> set control (longp_policy = 60) el valor informado es el número de días que queremos mantener
adrci> set control (shortp_policy = 15) el valor informado es el número de días que queremos mantener
3. En el caso que queremos realizar un borrado de ficheros de traza utilizaremos el comando purge. En el siguiente ejemplo borraremos los ficheros más antiguos de 7 días
adrci> purge -age 10080 -type TRACE (en este caso el valor informado son minutos)
adrci> purge -age 10080 -type TRACE (en este caso el valor informado son minutos)
Este post ha sido confeccionado a partir de la información extraida del siguiente enlace: http://gavinsoorma.com/2010/09/purging-trace-and-dump-files-with-11g-adrci/
--
reconoce tus errores, antes de que otros los exageren - Andrew Mason, CEO of Groupon
jueves, 27 de febrero de 2014
Espacio .... La ultima frontera
buenas noches , como os comente en el post anterior estaba haciendo un script de tamaño de tablespaces , os lo dejo aqui , tiene sus fallos como por ejemplo no tener en cuenta los tablespaces en autoextend
en cuanto tenga un momentito lo modifico , no me acuerdo de donde lo saque , me parece que es un refrito de varios scripts , bueno aqui os lo dejo
-- -----------------------------------------------------------------------------------
-- File Name : Moni_tablespaces
-- Author : EOT
-- Description : Nos realiza unlistado de los tamaños de los tablespaces
-- Requirements : Access to the V$ views.
-- Call Syntax : @Moni_tablespaces.sql
-- Last Modified: 21/08/2012
-- -----------------------------------------------------------------------------------
SET LINESIZE 145
SET PAGESIZE 9999
SET VERIFY OFF
COLUMN tablespace_name FORMAT A30 HEADING 'Tablespace Name'
COLUMN total FORMAT 99,999,999,999 HEADING 'Mb |Total'
COLUMN libres FORMAT 99,999,999,999 HEADING 'Mb | Libres'
COLUMN ocupados FORMAT 999.99 HEADING 'Usado %'
SELECT a.tablespace_name , (a.BYTES / 1024 / 1024) total,
(b.BYTES / 1024 / 1024) libres,
ROUND (((a.BYTES - b.BYTES) / a.BYTES) * 100, 2) ocupados
FROM (SELECT tablespace_name, SUM (BYTES) BYTES FROM dba_data_files
GROUP BY tablespace_name) a,
(SELECT tablespace_name, SUM (BYTES) BYTES, MAX (BYTES) largest
FROM dba_free_space
GROUP BY tablespace_name) b
WHERE a.tablespace_name = b.tablespace_name
ORDER BY 4 Desc;
Enrique Ortiz
El destino favorece a los niños, a los locos y a las naves llamadas Enterprise
en cuanto tenga un momentito lo modifico , no me acuerdo de donde lo saque , me parece que es un refrito de varios scripts , bueno aqui os lo dejo
-- -----------------------------------------------------------------------------------
-- File Name : Moni_tablespaces
-- Author : EOT
-- Description : Nos realiza unlistado de los tamaños de los tablespaces
-- Requirements : Access to the V$ views.
-- Call Syntax : @Moni_tablespaces.sql
-- Last Modified: 21/08/2012
-- -----------------------------------------------------------------------------------
SET LINESIZE 145
SET PAGESIZE 9999
SET VERIFY OFF
COLUMN tablespace_name FORMAT A30 HEADING 'Tablespace Name'
COLUMN total FORMAT 99,999,999,999 HEADING 'Mb |Total'
COLUMN libres FORMAT 99,999,999,999 HEADING 'Mb | Libres'
COLUMN ocupados FORMAT 999.99 HEADING 'Usado %'
SELECT a.tablespace_name , (a.BYTES / 1024 / 1024) total,
(b.BYTES / 1024 / 1024) libres,
ROUND (((a.BYTES - b.BYTES) / a.BYTES) * 100, 2) ocupados
FROM (SELECT tablespace_name, SUM (BYTES) BYTES FROM dba_data_files
GROUP BY tablespace_name) a,
(SELECT tablespace_name, SUM (BYTES) BYTES, MAX (BYTES) largest
FROM dba_free_space
GROUP BY tablespace_name) b
WHERE a.tablespace_name = b.tablespace_name
ORDER BY 4 Desc;
Enrique Ortiz
El destino favorece a los niños, a los locos y a las naves llamadas Enterprise
Variables SQLPLUS
Estaba yo intentando hacer un script de espacio de tablespaces e intenté poner lo que todos vosostros pondríais en la cabecera , el nombre de la base de datos , el dia . Despues de varios intentos con declares y bloques pl/sql , descubri una cosita que me ha parecido interesante , existe una forma de crear variables dentro de sqlplus , la cuestion es crear una columna utilizando el formato new_value del tipo
column <nombre_campo> new_value <nombre_variable>
en mi caso
column v_fecha new_value var_fecha
entonces puedes hacer sql del tipo :
select to_char(sysdate,'DD-MM-YYYY HH24-MI') v_fecha from dual;
y luego utilizar este campo como si fuera una variable de sql , osease &v_fecha
en mi caso lo utilizo en un report html ( sql plus puede hacer reports html ) de la siguente manera:
column v_fecha new_value var_fecha
column instance_name new_value var_db
column version new_value var_version
column instance_name new_value var_db
column version new_value var_version
select to_char(sysdate,'DD-MM-YYYY HH24-MI') v_fecha from dual;
select instance_name ,version from v$instance;
select instance_name ,version from v$instance;
para visualizarlas utilizo el prompt
prompt <center>Database &var_db<center>
<div class="subtitle1">Oracle Version &var_version</div>
<div class="subtitle2">&var_fecha</div></CENTER>
es recomendable cuando hagais pruebas con las variables tener los settings de "set echo on" y "set termout on", dado que si os equivocais en el nombre o no le dais valor a las variables sqlplus os lo pedirá , si no teneis estos dos settings lo unico que hará sqlplus es esperarse sin sacar nada por pantalla, no os tengo que explicar lo estresante que es contenplar una pantalla en negro sin saber que se está ejecutando .<div class="subtitle1">Oracle Version &var_version</div>
<div class="subtitle2">&var_fecha</div></CENTER>
Enrique Ortiz
Nunca me he fiado de los Klingons y nunca lo haré.
jueves, 6 de febrero de 2014
How Find ORACLE_HOME
Metodo sencillo para desde sqlplus obtener el path de ORACLE_HOME:
SQL> var OHM varchar2(100);
SQL> EXEC dbms_system.get_env('ORACLE_HOME', :OHM);
PL/SQL procedure successfully completed.
SQL> PRINT OHM
OHM
--------------------------------------------------------------------------------
/u01/app/oracle/product/11.1.0/db_1
Fuente: http://nm-mathan.blogspot.fr/
Antonio Redondo
Oracle DBA
jueves, 30 de enero de 2014
Wait Event Classes
Compartimos con vosotros este documento que encontramos hace unos días por los mares de Internet a raíz de un problemilla de rendimiento en una base de datos Oracle 10g. El documento recoge algunas esperas típicas de Oracle, agrupadas por tipologías y nos da unas cuantas alternativas para mirar de reducir dichas esperas y mejorar el rendimiento global de nuestras bases de datos Oracle.
Esperamos que os pueda servir de ayuda!
Oscar Pin Niebla
Senior Oracle DBA
Esperamos que os pueda servir de ayuda!
Oscar Pin Niebla
Senior Oracle DBA
martes, 28 de enero de 2014
Select count(*) y select * no coinciden
Caso abierto: 10101
Realizamos un select count(*) from table desde una sesión de base de datos y nos devuelve un valor. Realizamos la misma consulta para ver los datos (select * from table) y no nos devuelve ningún registro
Escenario de operaciones: Oracle RAC 11gR2
Sin solución para la versión 11gR2
Aplicado workaround con resultado favorable
En noviembre de 2013 los Servicios de Información reciben un comunicado en el cual se informa de un comportamiento anómalo en una de las bases de datos a su cargo. Dos usuarios al realizar la misma consulta contra dicha base de datos simultáneamente reciben datos diferentes.
Una vez descartado que estén aplicando diferentes filtros y/o que estén consumiendo sustancias estupefacientes, se aísla la consulta para proceder a investigar este extraño caso de desaparición de registro.
El problema viene dado por el bug 13004894 que afecta a la versión 11R2 y que en principio queda resuelto en la versión 12.1.0.1 aunque este punto no lo hemos podido confirmar. El workaround que propone Oracle es modificar el valor del parámetro STATISTICS_LEVEL=TYPICAL, en nuestro caso teníamos este parámetro con el valor STATISTICS_LEVEL=ALL. Este cambio se puede realizar en caliente.
Una vez realizado el cambio del valor de este parámetro el comportamiento de la consultas es el esperado: al realizar un select count(*) from table y select * from table devuelve el mismo número de registros.
Realizamos un select count(*) from table desde una sesión de base de datos y nos devuelve un valor. Realizamos la misma consulta para ver los datos (select * from table) y no nos devuelve ningún registroEscenario de operaciones: Oracle RAC 11gR2
Sin solución para la versión 11gR2
Aplicado workaround con resultado favorable
En noviembre de 2013 los Servicios de Información reciben un comunicado en el cual se informa de un comportamiento anómalo en una de las bases de datos a su cargo. Dos usuarios al realizar la misma consulta contra dicha base de datos simultáneamente reciben datos diferentes.
Una vez descartado que estén aplicando diferentes filtros y/o que estén consumiendo sustancias estupefacientes, se aísla la consulta para proceder a investigar este extraño caso de desaparición de registro.
El problema viene dado por el bug 13004894 que afecta a la versión 11R2 y que en principio queda resuelto en la versión 12.1.0.1 aunque este punto no lo hemos podido confirmar. El workaround que propone Oracle es modificar el valor del parámetro STATISTICS_LEVEL=TYPICAL, en nuestro caso teníamos este parámetro con el valor STATISTICS_LEVEL=ALL. Este cambio se puede realizar en caliente.
Una vez realizado el cambio del valor de este parámetro el comportamiento de la consultas es el esperado: al realizar un select count(*) from table y select * from table devuelve el mismo número de registros.
Oscar Pin Niebla
Senior Oracle DBA
Suscribirse a:
Entradas (Atom)