SEVERE java.sql.SQLRecoverableException: IO Error: Connection reset – Linux system

Después de varios días volviéndonos locos y de sufrir con dos síntomas, por un lado, cuando creábamos una conexión en sqldeveloper aunque le pedíamos que guardara el password no lo hacía y con errores intermitentes de java, con timeout en las conexiones, Descubrimos que hay un problema con los poles de generación número aleatorios en las máquinas virtuales. Esto se puede solucionar instalando y levantando haveged que permite generar de manera más rápida los números random,con esto se acelera la generación de llaves SSL y hace la encriptación más efectiva.

Según Oracle cuando hay una diferencia muy grnade entre el número de estos dos ficheros, siendo mucho menor el segundo:

$ cat /proc/sys/kernel/random/poolsize

$ cat /proc/sys/kernel/random/entropy_avail

Puede haber problemas que se solucionan instalando y levantando havenged.

 

# yum install haveged

# systemctl start haveged

# systemctl enable haveged
Anuncios

REDUNDANCIA PARA VOTING DISK

Si decides almacenar el fichero de voting disk en el mismo diskgroup de ASM que los ficheros de datos, añadir un grupo de fallo puede suponer añadir un montón de espacio y puede que esto suponga un problema. Para solucionar esto, se introduce un nuevo grupo de fallo tipo quorum. Cuando se añade este tipo de grupo, solamente se utiliza para añadir una copia extra de voting dik en ese grupo de fallo, lo cual permite que este disco sea mucho menor al resto que compone el grupo.

Generaríamos el disckgroup de esta manera, siendo FG1 y FG2 del mismo tamaño y FG3 mucho menor ya que solo va almacenar el voting disk.

CREATE DISKGROUP PRUEBA NORMAL REDUNDANCY
FAILGROUP FG1 DISK 'ORCL:PRUEBA01' NAME PRUEBA01
FAILGROUP FG2 DISK 'ORCL: PRUEBA02' NAME PRUEBA02
QUORUM FAILGROUP FG3 DISK 'ORCL: PRUEBA03' NAME PRUEBA03
ATTRIBUTE 'compatible.asm' = '11.2';

ORA-01878: specified field not found in datetime or interval

El problema es que existen datos que queremos convertir con un función de timezone, en el intervalo horario del cambio de hora. Por ejemplo si el cambio de hora es el 27/3 a las 2:00. No podemos tener datos entre las 2:00 y las 2:59. El último tiene que ser a la 1:59 y el siguiente a las 3:00. Ya que ese intervalo de tiempo realmente no existe.

La solución es buscar los datos que se encuentran en ese intervalo con un betwen y actualizarlos a un valor a un valor correcto.

Realmente no es un problema de Oracle es la forma en que se tratan las horas con DST, cuando se modifica el offset , siempre hay una hora en que el tiempo se mueve hacia adelante (= no existe).

http://en.wikipedia.org/wiki/Daylight_saving_time

Función BITAND de Oracle (bitwise AND)

Lo que hace está función es convertir los dos argumentos en números binarios y luego los combina utilizando un operador bitwise AND y el resultado de convierte de vuelta a un numero entero. Los ejemplos de más abajo pueden ser más ilustrativos.

SELECT BITAND(0, 0) AS "0, 0", -- i.e. 0 AND 0 = 0
 BITAND(0, 1) AS "0, 1", -- i.e. 0 AND 1 = 0
 BITAND(1, 0) AS "1, 0", -- i.e. 1 AND 0 = 0
 BITAND(1, 1) AS "1, 1" -- i.e. 1 AND 1 = 1
 FROM DUAL;
 2 3 4 5
 0,0     0, 1     1, 0    1, 1
------  -------  ------  -------  
 0         0       0        1
Lo que sería igual a 
BITAND(0, 0) 
0000 0
0000 0
----
0000 0

BITAND(0, 1)
0000 0
0001 0
—-
0000 0

BITAND(1, 0)
0001 1
0000 0
—-
0000 0

BITAND(1, 1)
0001 1
0001 1
—-
0001 1

 

Estos enlaces pueden servir de referencia:

https://en.wikipedia.org/wiki/Bitwise_operation

Oracle BITAND function (bitwise AND)

Publicado en SQL

Hoy vamos a ver un poco del purgado de colas:

Tenemos 73 ordenes en coladas que se intentado procesar en multiples ocasiones y dan error.

select count(*) from EJEMPLOQUEUE_DRM_TAB;
COUNT(*)
----------
 73
select queue,msg_state,count(*) from aq$EJEMPLOQUEUE_TAB; group by queue,msg_state;
QUEUE MSG_STATE COUNT(*)
------------------------------ ---------------- ----------
CDBQUEUE_DRM READY 73

Con esto las purgamos, más detalles sobre este paquete en http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_aqadm.htm#i1014013

Ejemplo de la sentencia, basandonos en número de repeticiones.

DECLARE
 po_t dbms_aqadm.aq$_purge_options_t;
BEGIN
 dbms_aqadm.purge_queue_table('MMOADSL.EJEMPLOQUEUE_TAB;', 'qtview.RETRY_COUNT > 100' , po_t);
END;
select count(*) from EJEMPLOQUEUE_TAB;
COUNT(*)
----------
 0
 
 
Select Q_NAME, RETRY_COUNT from EJEMPLOQUEUE_TAB;
Q_NAME RETRY_COUNT
------------------------------ -----------
EJEMPLOQUEUE;_DRM 9892
EJEMPLOQUEUE;_DRM 17909
EJEMPLOQUEUE;_DRM 17912
EJEMPLOQUEUE;_DRM 17909
EJEMPLOQUEUE;_DRM 17917
EJEMPLOQUEUE;_DRM 17912
EJEMPLOQUEUE;_DRM 17912
EJEMPLOQUEUE;_DRM 17880
EJEMPLOQUEUE;_DRM 17878
EJEMPLOQUEUE;_DRM 17881
EJEMPLOQUEUE;_DRM 17871
Q_NAME RETRY_COUNT
------------------------------ -----------
EJEMPLOQUEUE;_DRM 17871
EJEMPLOQUEUE;_DRM 17873
EJEMPLOQUEUE;_DRM 17868
EJEMPLOQUEUE;_DRM 17869
EJEMPLOQUEUE;_DRM 17868
EJEMPLOQUEUE;_DRM 16813
EJEMPLOQUEUE;_DRM 16811
EJEMPLOQUEUE;_DRM 16811
EJEMPLOQUEUE;_DRM 15561
EJEMPLOQUEUE;_DRM 15306
EJEMPLOQUEUE;_DRM 15305
Q_NAME RETRY_COUNT
------------------------------ -----------
EJEMPLOQUEUE;_DRM 11617
EJEMPLOQUEUE;_DRM 11617
EJEMPLOQUEUE;_DRM 11617
EJEMPLOQUEUE;_DRM 11434
EJEMPLOQUEUE;_DRM 11428
EJEMPLOQUEUE;_DRM 11429
EJEMPLOQUEUE;_DRM 15350
EJEMPLOQUEUE;_DRM 25662
EJEMPLOQUEUE;_DRM 25666
EJEMPLOQUEUE;_DRM 25652
EJEMPLOQUEUE;_DRM 11918
Q_NAME RETRY_COUNT
------------------------------ -----------
EJEMPLOQUEUE;_DRM 11917
EJEMPLOQUEUE;_DRM 11917
EJEMPLOQUEUE;_DRM 5361
EJEMPLOQUEUE;_DRM 5360
EJEMPLOQUEUE;_DRM 5361
EJEMPLOQUEUE;_DRM 15629
EJEMPLOQUEUE;_DRM 21670
EJEMPLOQUEUE;_DRM 21674
EJEMPLOQUEUE;_DRM 15629
EJEMPLOQUEUE;_DRM 21669
EJEMPLOQUEUE;_DRM 15627
Q_NAME RETRY_COUNT
------------------------------ -----------
EJEMPLOQUEUE;_DRM 15611
EJEMPLOQUEUE;_DRM 15610
EJEMPLOQUEUE;_DRM 15610
EJEMPLOQUEUE;_DRM 8793
EJEMPLOQUEUE;_DRM 8790
EJEMPLOQUEUE;_DRM 8791
EJEMPLOQUEUE;_DRM 1871
EJEMPLOQUEUE;_DRM 25950
EJEMPLOQUEUE;_DRM 25941
EJEMPLOQUEUE;_DRM 25943
EJEMPLOQUEUE;_DRM 1871
Q_NAME RETRY_COUNT
------------------------------ -----------
EJEMPLOQUEUE;_DRM 1872
EJEMPLOQUEUE;_DRM 12769
EJEMPLOQUEUE;_DRM 12769
EJEMPLOQUEUE;_DRM 12768
EJEMPLOQUEUE;_DRM 12769
EJEMPLOQUEUE;_DRM 8795
EJEMPLOQUEUE;_DRM 8798
EJEMPLOQUEUE;_DRM 8794
EJEMPLOQUEUE;_DRM 9906
EJEMPLOQUEUE;_DRM 19360
EJEMPLOQUEUE;_DRM 19358
Q_NAME RETRY_COUNT
------------------------------ -----------
EJEMPLOQUEUE;_DRM 19353
EJEMPLOQUEUE;_DRM 15568
EJEMPLOQUEUE;_DRM 21100
EJEMPLOQUEUE;_DRM 21097
EJEMPLOQUEUE;_DRM 2787
EJEMPLOQUEUE;_DRM 2787
EJEMPLOQUEUE;_DRM 2785

Cambiar next_run_date en DBMS_SCHEDULER

Este atributo no se puede cambiar directamente, lo que se tiene que hacer es cambiar el start_date

exec dbms_scheduler.disable (‘<usuario>.<nombre_job>’);

declare
v_new_next_date timestamp with time zone;
begin
select to_timestamp_tz(to_char(trunc(sysdate),’DD-MON-YYYY’) || ‘ 12:05:00 PM +00:00′) into v_new_next_date
from dual;
dbms_scheduler.set_attribute(name=>'<usuario>.<nombre_job>’, attribute=>’START_DATE’,value=>v_new_next_date);
end;
/
EXEC dbms_scheduler.enable ( ‘<usuario>.<nombre_job>’);

/