Bug 21275952 es mortal si tu sistema es OLTP intensive

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 que 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 probabe que nos de este problema.

El problema es al activar FAST_START_MTTR_TARGET provoca que DBWR escribe de manera mucho mas agresiva los dirty blocks a los datafiles, en nuestro caso casi triplica el numero de physical writes!

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). El cambio de licenciamiento y la limitacion de uso d CPU puede traer colas.

  1. SE2 pasar de poder utilizar 4 sockets a 2 sockets maximo, en un RAC solamente se puede sar un socket por nodo.
  2. Aparte de reducir 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.

Ire actualizando la info, algo que tengo pendiente de averiguar es si se pueda hacer Hard Parttioning con SE2 en Oracle VM.

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)

12c Released

Ya esta disponible Oracle Database 12c! Los links de descarga de OTN

http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html

Las nuevas funcionalidades:

  1. Posibilidad de ejecutar los procesos de la base de datos como threads en vez de procesos del Sistema Operativo
  2. Transaction Guard & Application Continuity
  3. Flex Cluster
  4. Flex ASM
  5. ASM Scrubbing para detección de corrupciones y reparaciones
  6. ASM Intelligent Data Placement
  7. ACFS puede ubicar para todo tipo de ficheros incluidos los de la base de datos (redo log, controlfile, data files)
  8. Global Data Services, integración entre bases de datos primarias y Active Data Guards o replicas de GoldenGate
  9. Rolling Upgrade con Active Data Guard
  10. Active Data Guard Far Sync
  11. Duplicación de RMAN sin tener que abrir la base de datos
  12. Backup & Restore con RMAN entre distintas plataformas
  13. Invocación de SQL en RMAN
  14. Role de SYSBACKUP
  15. Mejoras de operaciones online, como DROP INDEX, DROP CONSTRAINT, movimiento de Data Files en caliente, movimiento de particiones etc
  16. Columnas auto-incrementales (secuencias)
  17. Mejoras en Instance Caging (utilizando subset de juego de procesadores)
  18. Pluggable Database (PDB) orientado para Cloud
  19. Mejoras de CloneDB en NAS
  20. Tracking de Outliers de I/O
  21. Optimizador Adaptativo
  22. Se ha eliminado el limite de 254 buckets en histogramas
  23. Indices Parciales sobre tablas particionadas (indices sobre unas particiones de la tabla y no todas las particiones)
  24. Nuevo Database Control, Enterprise Manager Database Express 12c

Y mucho mas!