Si tu sistema es OLTP intensive cuidadin con el Bug 21275952

Hace poco estuve en un cliente por un problema de performance porque el sistema al ser un sistema OLTP con una intensidad de uso bastante elevado (aproximadamente 7000 transacciones por segundo repartidos en 4 nods de RAC) el numero de escrituras es alto. Despues de analizar los datos de performance se ha visto que de las 4500 physical writes por segundo solamente 1000 eran de redo log, el resto eran de datafiles, comparando estos datos con otro sistema que tiene el cliente se ha visto que en el otro sistema para procesar mas o menos la mismca cantidad de trafico solamente hacia 1900 physical writes por segundo. La gran cantidad de escritura afectaba al tiempo de commit y generaba encolamiento de trafico.

Este comportamiento es provocado por el Bug 21275952 SLOW PERFORMACE DUE TO HIGH PHYSICAL IO AND LOW ESTIMATED_MTTR. Si tenemos FAST_START_MTTR_TARGET activado es probable que nos de este problema.

El problema es al activar FAST_START_MTTR_TARGET el DBWR escribe de manera mucho mas agresiva los dirty blocks a los datafiles, en nuestro caso casi triplica el numero de physical writes! El root cause parece que es por un mal calculo o una corrupción de un array de la SGA el db cache size parece bastante mas grande de lo que es.

El bug afecta 11.2.0.4 hacia atras (nosotros teniamos 11.2.0.3), el workaround es desactivar FAST_START_MTTR_TARGET o aplicar el one-off patch de este bug.

Cambios en el licenciamiento en Oracle 12c Standard Edition (SE2)

Por fin ha salido Oracle Database 12.1.0.2 Standard Edition (SE2) despues de 1 año de espera.

Sin embargo es frustrante para los clientes que han apostado por Standard Edition (porque simplemente no necesitan más, les sobra Standard Edition). El cambio de licenciamiento y la limitacion de uso de CPU puede traer colas:

  1. SE2 pasar de poder utilizar 4 sockets a 2 sockets maximo, en un RAC solamente se puede utilizar un socket por nodo.
  2. Aparte de reducir el numero de sockets SE2 limita el uso maximo de threads de CPU a 16, esto quiere decir si en e servidor hay 2 CPU con 8 core cada uno tendriamos 32 threads con Hyperthreding pero SE2 solo hará uso de 16.

Update: Parece ser que si hay varias bases de datos ubicados en un mismo servidor de 2 sockets con bastantes cores y threads, por ejemplo 72 threads, cada una de estas bases de datos puede usar un maximo de 16 threads, con esto mas o menos no esta tan mal SE2. Eso si en RAC solamente se puede usar servidores de Single Socket, para esto se puede hacer Hard Partitioning para usar solamente un socket.

ACFS en RHEL/OEL 6.x unrecognized file system type 0x61636673

En RHEL/OEL 6.5 (posiblemente tambien en 6.4) al hacer un tail de un fichero ubicado en ACFS podemos observar este warning:

unrecognized file system type 0x61636673

Parece que es por una funcionalidad nueva de tail que viene con coreutil 8.2 y 8.4 de Linux, hace una comprobacion del tipo de filesystem y ACFS al no estar presente en fs.h el tail no lo reconoce.

Es un warning que se puede ignorar tranquilamente

Cuidado a partir de GoldenGate 11.2.1.0.7

Recientemente actualice la version de GoldenGate de 11.2.1.0.6 a 11.2.1.0.9 y el rendimiento del extract cayó en picado en la etapa de escritura a los trails, despues de hacer unos debug y traceos se ha visto que el extract al escribir en los trails se realiza tantas llamadas a la funcion fsync que el performance es totalmente inaceptable.

11.2.1.0.6 es capaz de generar 60000 cambios por segundo y 11.2.1.0.9 solamente 20…..! (aplica tanto para el classic extract como integrated extract)

Parece el problema esta en el intervalo de checkpoint que realiza a partir de la version 11.2.1.0.7, subiendo el intervalo de checkpoint de 10 segundos (por defecto) a 100 soluciona el problema (y dobla el rendimiento de 11.2.1.0.6) pero cualquier modificacion de este parametro se deberia de consultar a soporte.

Nota publicada por Soporte el 7 de Octubre: GOLDENGATE EXTRACT (11.2.1.0.7 – 11.2.1.0.12) IS SLOW WRITING TO TRAIL FILE, TOO MANY FSYNC CALLS (Doc ID 1589437.1)

Bug 17434145 : 11.2.1.0.7+ EXTRACT IS SLOW WRITING TRAIL FILE, TOO MANY FSYNC CALLS

GoldenGate BATCHSQL falla por Database error 100 (retrieving bind info for query)

En algunas ocasiones cuando utilizamos la opcion de BATCHSQL en el Replicat este falla por el error Database error 100 (retrieving bind info for query) y no existe ningun tipo mas de error (suele venir acompañado de ORA-00001 o ORA-01043).

Posiblemente el extractor principal de datos o el extractor de data pump se ha reiniciado durante la transaccion y al reiniciar uno de los procesos de extractores escriben una entrada RestartAbend en el trail y el Batchsql o incluso insert normal pero con Grouptrans activado (por defecto) cuando leen esta entrada el Replicat tiene que abortar el insert y volver a leer el trail y esquivar la entrada. Si se utiliza BATCHSQL pues el Replicat abortara dos veces, una por batchsql y otra por grouptrans.

Tipico mensaje que se puede observer en el log y report de replicat con BATCHSQL activado:

WARNING OGG-01498  Aborting BATCHSQL transaction. Database error 100 (retrieving bind info for query).

WARNING OGG-01137  BATCHSQL suspended, continuing in normal mode.

INFO    OGG-01020  Processed extract process RESTART_ABEND record at seq 156, rba 93730614 (aborted 865789 records).

En caso de no tener BATCHSQL activado:

INFO    OGG-01020  Processed extract process RESTART_ABEND record at seq 156, rba 93730614 (aborted 865789 records).

BATCHSQL ofrece un rendimiento bastante atractivo, activado y replicando una tabla de 32 campos (avg_row_len de 105) se puede obtener una velocidad de 14000 filas por segundo, desactivado solamente se llega a obtener unas 4500 filas por segundo.

WARNING: Waited 15 secs for write IO to PST y _asm_hbeatiowait

Hace un par de meses estuve realizando unas pruebas de Cluster de 11gR2 con ASM configurado en un cliente, una de las pruebas era perdida de caminos a la cabina de discos.

El software de Multipath utilizado es MPIO de IBM AIX 6.1 y la version de Grid Infrastructure es 11.2.0.3.6 + el parche 10109915, la prueba falló porque ASM detectaba perdida de I/O a los 15 segundos considera que los discos eran inaccesibles.

Los errores son (en traza de gmon y alert):

WARNING: Waited 15 secs for write IO to PST disk 0 in group x

Despues de este error es probable que desmonte el Disk Group (aunque tenga normal redundancy el Disk Group), en una de las pruebas que hice la instancia de la base de datos cayó.

Según la experiencia esto no pasaba antes, despues de darle vueltas y abrir un SR con soporte el problema era que en el parche 10109915 se introdujo el parametro _asm_hbeatiowait que tiene un valor por defecto de 15 segundos mientras tanto MPIO de AIX espera 30 segundos antes de dar como muerto un camino de multipath. El workdaround is aumentar de 15 a 35_asm_hbeatiowait de esta manera ASM espera a la capa de Multipath antes de caerse.

Como se puede observar las pruebas que se realiza para validar un Cluster puede que no sean validas por una simple introduccion de un parche one-off, creo que introduccion de tal funcionalidad merece una nota oficial y asi le hice saber al analista de soporte y acaban de publicar esta nota:

ASM Disks Offline When Few Paths In The Storage Is Lost (Doc ID 1581684.1)