Servidores Anti-Terremoto

Curioso

HP Seismic Rack Solution

Link interesante de Linux sobre z/VM

Actualmente estoy con unas pruebas de concepto de RAC sobre Linux en servidor Mainframe (system z10, S/390) mas conocido como zLinux.

Realmente desde el punto de vista de Oracle RAC no varia mucho que cualquier otro Linux en plataforma x86.

Mirando el tema de acceso a almacenamiento he encontrado este link, bastante interesante para el tema, Linux sobre z/VM

ORA-25402: transaction must roll back, problema con el TAF

Otro dia realizando unas pruebas de TAF se ha visto que una caida del nodo podria provocar inconsistencias en la aplicacion.

La prueba es facil, basicamente es configurar un servicio de TAF, abrir una sesion mediante este servicio, insertar un registro y antes del commit provocar la caida de la red privada/interconnect y seguidamente ejecutar el commit.

Esta sesion se quedaria colgada durante un tiempo y dara el error ORA-25402: transaction must roll back, viendo este error da la sensacion de que la transaccion del insert no se ha validado la sorpresa es que desde otras sesiones consultant a la tabla SI se ve que se ha validado.

El problema es que este error podria provocar que una aplicacion realizando otra vez el insert asumiendo que se ha hecho rollback que es falso.

La prueba se ha realizado en 10.2.0.3 aunque parece que es reproducible en 10.2.0.4 (pendiente de confirmar)

Se puede descargar una prueba aqui Test ORA-25402

Bigfile Tablespace no es para Oracle 10g

El problema de un Bigfile es el backup & restore.

En el mundo real un backup de un fichero de 1.8TB (le esta pasando a un colega) a una cabina de discos SATA tarda 23 horas, hay dos problemas aqui:

1. Los discos no deben de estar muy bien configurados, un throughput de 20MB/seg en un backup sin compresión es pésimo.
2. Antes de Oracle 11g RMAN solo puede paralelizar a nivel de datafiles, cada canal gestiona un datafile y no un trozo como en 11g en el cual se le puede especificar la clausula “SECTION SIZE” para paralelizar la operación a un nivel mas granular.

Considerando que la base de datos (RAC de 4 nodos) ocupa 3TB y el backup de 1.2TB tarda unas 6 horas porque estos al ser datafiles más pequeños y numerosos se paralelizan sin problemas tanto a nivel de datafiles como nodos de RAC. Pero el tiempo de backup se dispara por la existencia de un Bigfile. En mi opinión hay que pensarselo dos veces antes de optar por los Bigfiles en la versión 10g a no ser que no se pueda manejar 64K datafiles de 128G cada uno (con db_block_size a 32).

Sería menos problemático con las tecnologias tipo Split Mirror ó Snapshots con VTL sin embargo tampoco sería perfecto. Sería muy interesante conocer más ejemplos reales de bases de datos de considerable tamaño y que utilicen Bigfiles.

Cuando no tienes que tocar algo que no lo conoces

Hace unos 7 años cuando todavia no usaba de manera muy extensiva RMAN hice un script de backup para Oracle sobre Linux. Desde hace unos 5 años solamente hago backups con RMAN y el script este ya lo tengo como una reliquia en mi repositorio de scripts varios.

Hace unos dias (un fin de semana) tuve que acudir urgentemente a un cliente el cual estuve en el año 2003 y no he vuelto a estar. En su dia deje este script para que puedan hacer sus backups en caliente. Cuando llegue ví que estaban todos los archive logs desde el último backup y los backups de los 3 últimos dias. Pensé que esto va a ser chupado, restore, recover y pacasa. Empecé realizando el restore, como el script generaba un restore.sh era simplemente ejecutarlo. Una horita para el restore y empece a ejecutar el proceso de recover para mi sorpresa es que al intentar aplicar el recover de primer archive log salió un error quejandose de que los datafiles del tablespace de UNDO son más recientes que el fichero de control. Improbable, impensable e imposible porque acabo de restaurar todo incluido el fichero de control! (alguien intento hacer recover antes de que llegara y se jodio los ficheros de control actuales)

Empecé a ver las fechas de modificación de los datafiles de UNDO y comparando con el resto y efectivamente los datafiles de UNDO eran 6 horas mas recientes que el backup. Revisando el directorio donde se guardaba todos los backups me di cuenta que no existia los datafiles de UNDO, no me lo podia creer, me entró la idea de que entregue un script defectuoso al cliente hace 6 años y me sentía responsable de su situación sin embargo tampoco me cuadraba porque el script lo tenía puesto en varios clientes donde se han hecho recover con exito. Eche un vistazo el fichero de alert (que no se ha tocado en los ultimos 6 años) y me di cuenta que “alter tablespace undotbs1 begin backup” se dejó de ejecutarse el 30 de abril de 2004 (y la plataforma empezó a funcionarse desde 2003). Eso indicaba que alguien había modificado el script sin tener mucha idea de lo que estaba tocando.

En el script se invoca una función (Obtain_data_files) para obtener los datafiles a copiar, es una query contra dba_data_files y dba_tablespaces y se debe de copiar todos aquellos tablespaces que no sean del tipo TEMPORARY. Pues bien algún estimado cambió la condición de “where b.contents != ‘TEMPORARY’” a “where b.contents = ‘PERMANENT’” y el UNDO precisamente no se considera PERMANENT sino UNDO. Asi que desde esa modificación no se ha vuelto a hacer backups de UNDO durante los últimos 5 años……….

Por suerte se pudo recuperar pero siempre me quedará la duda del por qué de este cambio, sera que no gustaba la palabra temporary?