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!

bugs bugs & bugs

Desde hace unos 7 años siempre recomiendo a la gente ir al terminal release de una version en concreto en cuanto puedan aunque no les afecte ningún bug en sus versión actual.

La gente siempre hacia caso omiso por lo de “si todo funciona no lo toques”. Tengo muchas historias que contar sobre este tipo de situaciones, voy a exponer 2 hoy.

Situacion 1: Hace tiempo un cliente tiene una BBDD de la versión 9.2.0.5 y llevaba años funcionando sin dar ningún tipo de problema y lógicamente no veía ninguna razón para actualizar la versión aunque yo le habia mencionado un par de veces que hay que estar siempre en terminal release, 9.2.0.8. Un día tuvo que importar unas filas a una de las tablas core de la aplicacion y cayó en el bug 3798351 Importing a pre-existing table may DROP the table on an error, este bug es curioso porque borra la tabla donde estas importando, una herramienta de recovery como import en vez de recuperar te borra la tabla! La tabla tenia 1200 millones de filas.

Situacion 2: Una aplicacion de mensajeria que lleva funcionando años en 9.2.0.6, otro cliente que piensa que no se debe de tocar cuando todo funciona. La aplicación hace uso extenso de LOB. Un día de repente la aplicación literalmente dejó de funcionar, todas las operaciones de DML contra las tablas de LOB se serializaban, cayeron en el bug 6376915 – HW enqueue contention for ASSM LOB segments, era cuestión de tiempo, era una bomba de relojeria. Lo peor es si hubiesen estado en la versión 9.2.0.8 el fix era simplemente aplicar un parche one-off que tarda 5 minutos en aplicar pero al estar en 9.2.0.6 Oracle no sacaba parches para las versiones non-terminal-release. Resultado subiendo a 9.2.0.8 sin probar el aplicativo con la advertencia del proveedor del aplicativo que no garantizaban un funcionamiento correcto de su aplicativo en 9.2.0.8.

SQL – STATSPACK TOP 5 EVENTS

with top_events as (
select snap_id, stime, name, null waits, round(diff/100) time
from (
    select  c.snap_id,
            to_char(c.snap_time, ‘yyyymmdd hh24′) stime,
            b.name,
            b.value,
            lag(b.value) over (partition by name order by b.snap_id) last_val,
            b.value – lag(b.value) over (partition by name order by b.snap_id) diff
    from    stats$sysstat b,
            stats$snapshot c
    where   c.snap_id = b.snap_id
    and     b.name = ‘CPU used by this session’
    and     c.snap_time between to_date(:start_date, ‘yyyymmdd hh24miss’)
                            and to_date(:end_date, ‘yyyymmdd hh24miss’)
    order by 3, 1)
where last_val is not null
union all
select snap_id, stime, event, waits, wait_seconds time
from (
     select snap_id, stime, event, rank() over (partition by snap_id order by diff_wait_time_micro desc) ranking,
            round(diff_waits) waits,
            round(diff_wait_time_micro/1000000) wait_seconds
       from (
         select  c.snap_id,
                 to_char(c.snap_time, ‘yyyymmdd hh24′) stime,
                 b.event,
                 b.total_waits,
                 lag(b.total_waits) over (partition by b.event order by b.snap_id) last_total_waits,
                 b.time_waited_micro,
                 lag(b.time_waited_micro) over (partition by b.event order by b.snap_id) last_total_time_micro,
                 b.total_waits – lag(b.total_waits) over (partition by b.event order by b.snap_id) diff_waits,
                 b.time_waited_micro – lag(b.time_waited_micro) over (partition by b.event order by b.snap_id) diff_wait_time_micro,
                 d.wait_class
         from    stats$system_event b,
                 stats$snapshot c,
                 v$system_event d
         where   c.snap_id = b.snap_id
         and     b.event_id = d.event_id
         and     d.wait_class != ‘Idle’
         and     c.snap_time between to_date(:start_date, ‘yyyymmdd hh24miss’)
                                 and to_date(:end_date, ‘yyyymmdd hh24miss’)
         order by 3, 1)
     where diff_waits is not null
)
order by 1, 5 desc)
select b.*
  from (select row_number() over (partition by snap_id order by time desc) rn, a.*
          from top_events a) b
 where rn <= 5;