Artículos

Está página pretende mostrar diferentes artículos de opinión relacionados tanto con las Bases de Datos IBM Informix y DB2 , así como con el Tratamiento de Datos con IBM Optim y la Protección de los Datos con Spectrum Protect.

Aug
31
2016

ARTÍCULO: Comprobando el estado de la HDR II

Como vimos previamente en el anterior artículo:

http://www.proyectosysoluciones.es/node/161

Existen varias formas de comprobar el estado de nuestra HDR hoy vamos a ver las siguientes:

onstat -g dri

Está forma nos da un poco más de información acerca del estado de la réplica, siendo diferente esta tanto en el primario como en el secundario.

En el primario nos dará una información como esta:
Data Replication at 600000043255438:
Type State Paired server Last DR CKPT (id/pg) Supports Proxy Writes

Jun
21
2016

ARTÍCULO: Comprobando el estado de la HDR I

En ocasiones resulta interesante comprobar el estado de nuestra réplica HDR para poder actuar si fuera preciso, ya que si solo estamos actuando sobre el nodo primario, podemos tener algún fallo en el secundario y que eso no se vea reflejado de inmediato en el rendimiento.

Vamos a ver 3 formas diferentes de poder chequear que todo está correcto:

onstat -

Es la forma más sencilla y rápida de comprobar el estado de la réplica. Al ejecutar este comando podemos apreciar que la réplica está funcionando correctamente tanto en el gestor primario como en el secundario.

May
18
2016

ARTICULO: Mensaje SCHAPI Estimate Compression en el online.log

Es posible que analizando el online.log veamos mensajes del tipo:

SCHAPI Estimate Compression

Esto se produce cuando utilizamos Open Admin Tool (OAT) y accedemos a la sección Almacenamiento de Administración de espacio. En ese momento OAT crea una nueva tarea llamada mon_compression_estimates. Cada vez que esta tarea se ejecuta aparece el mensaje en el online.log.

Apr
21
2016

ARTICULO: Optimizando el almacenamiento: Compress

Como ya vimos en un artículo anterior es posible que los datos en IBM Informix se nos fragmenten haciendo más ineficiente su gestión. Con repack podíamos recolocar todos los datos y no tener huecos libres de forma que los datos estén contiguos y con shrink podíamos liberar los extents vacíos y reducir los que estén casi vacíos. Ahora vamos a ver cómo funciona compress.

Mar
29
2016

ARTICULO: Optimizando el almacenamiento: shrink

Como ya vimos en otro artículo los datos en IBM Informix pueden fragmentarse haciendo más ineficiente su acceso. Ya vimos que con repack podíamos recolocar los datos en los primeros extents dejando libre la parte final de los mismos. Ahora vamos a ver cómo funciona shrink y qué nos aporta para complementar el repack.

Shrink reduce el tamaño de los extents o los libera en caso de que se hayan quedado vacíos. Esto libera de forma efectiva el espacio ocupado por una tabla ya que simplemente borrando registros no se libera espacio ya que el espacio sigue reservado.

Feb
16
2016

ARTICULO: Optimizando el almacenamiento: repack

IBM Informix almacena los datos en dbspaces. Éstos, a su vez, se componen de chunks y dentro de los chunks los datos se organizan en extents, que son zonas contiguas de almacenamiento de disco.

Todas las tablas disponen de un parámetro que se llama "first extent" que determina el tamaño reservado cuando se crea la tabla. Dispone también del parámetro "next extent" que determina de qué tamaño se coge el siguiente extent cuando el actual se ha llenado.

Dec
31
2015

ARTICULO: Identificando transacciones duraderas

En ocasiones resulta interesante saber qué transacciones llevan mucho tiempo activas. Esto puede desembocar en una Long Transaction, obligando a deshacer la transacción (Cuando se supera el umbral definido por LTXHWM), y eventualmente, bloqueando el gestor para todos los usuarios (Cuando se supera el umbral definido por LTXEHWM).

Lo primero de todo es saber encontrar qué transacciones llevan mucho tiempo. Para ello es necesario que sepamos en qué log nos encontramos actualmente, y para ello podemos hacer:
# onstat -l|grep C

Nov
25
2015

ARTICULO: Monitorizar tiempo de rollback de una sesión

En ocasiones, debido al funcionamiento normal de las aplicaciones, hay que cancelar alguna operación que está afectando al rendimiento de la base de datos, esto implica matar la sesión problemática mediante un onmode -z, con lo que el gestor se pondrá a realizar un rollback de las acciones realizadas por esta sesión.

Sep
30
2015

ARTICULO: Arreglando el error de máximo numero de paǵinas por tabla

Como ya comentamos en el artículo anterior: http://www.proyectosysoluciones.es/node/148

Informix tiene una limitación de máximo número de páginas por tabla en el caso de que esta sea no fragmentada. Una vez se alcanza ese límite, no se puede realizar ninguna escritura, solo permitiéndose lecturas, lo cual es un problema muy serio de malfuncionamiento. Llegados a este punto, existen varias formas para arreglar este problema:

HISTORIFICAR:

Aug
14
2015

ARTICULO: Monitorizar el número máximo de páginas por tabla

Informix tiene una limitación respecto al número máximo de páginas por tabla en caso de tablas no fragmentadas de 16777215. Este número viene de los bytes que se utilizan para poder direccionar cada página, siendo estos 3 bytes.

Syndicate content