Archivo

Archivo para Octubre, 2009

Catálogos web de artefactos de Maven

Lunes, 19 de Octubre de 2009 jarrarte Sin comentarios

Para los desearrolladores que utilizamos Maven como herramienta para el manejo de los proyectos y sus dependencias a librerías de terceros, generalmente nos encontramos con la necesidad de agregar una nueva dependencia, pero no tenemos claro cómo se llama el JAR (artifactId), a qué grupo pertenece (groupId) o qué versión deberíamos referenciar. Estos datos son utilizados para agregar un elemento en nuestro pom.xml.

Para encontrar los detalles de estos elementos tenemos algunas opciones en la web que nos facilitan el trabajo. MavenSearch, MVNRepository y MVNBrowser son una especie de directorios de librerías, las que indexan el repositorio central (link) en caso de MVNRepository, y el central más algunos otros para el caso de MVNBrowser (ver lista de repositorios indexados) y MavenSearch (ver lista de repositorios indexados).

¿En qué nos ayudan estas aplicaciones? Nos permiten hacer búsquedas por nombres de artefacto, nombres de grupo e inclusive, en caso de MavenSearch, nos permite utilizar comodines en esa búsqueda, por ejemplo “group:*jboss” para que retorne todos los artefactos del grupo org.jboss, jboss, etc.

Además de la funcionalidad principal, me parece interesante resaltar el POM report de MVNBrowser. Es un validador de las versiones de nuestras dependencias, en el que ingresamos un listado de artefactos tal como se representan en el pom.xml y nos retorna las actualizaciones a las versiones en uso. Por ejemplo, para una entrada así:

<dependencies>
	<dependency>
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
		<version>4.4</version>
		<scope>test</scope>
	</dependency>
	<dependency>
		<groupId>commons-io</groupId>
		<artifactId>commons-io</artifactId>
		<version>1.4</version>
	</dependency>
	<dependency>
		<groupId>commons-lang</groupId>
		<artifactId>commons-lang</artifactId>
		<version>2.4</version>
	</dependency>
	<dependency>
		<groupId>log4j</groupId>
		<artifactId>log4j</artifactId>
		<version>1.2.14</version>
	</dependency>
</dependencies>

Nos presenta una salida similar a la siguiente captura (le eliminé los ads): MvnBrowser

En resumen:

  • MavenSearch:
    • Permite búsquedas utilizando comodines
    • Indexa varios repositorios
    • Sitio muy rápido
  • MVNBrowser:
    • Indexa varios repositorios
    • POM report, para verificar si existen nuevas versiones de nuestras dependencias
  • MVNRepository:
    • Para un determinado artefacto, grafica los cambios de tamaño entre versiones
    • Indexa sólo el repositorio central
    • No se si es casualidad, pero me ha pasado varias veces que el sitio está bajo
Categories: Java, Maven Tags: ,

Listado de comandos de administración de Informix

Miércoles, 7 de Octubre de 2009 jarrarte Sin comentarios

Introducción

La idea de este post es listar algunos comandos útiles para el servidor de base de datos Informix, con el que algunos tenemos que sufrir trabajar día a día. Muchos de ellos se pueden ejecutar desde ambientes gráficos, pero generalmente no disponemos de dichos ambientes en servidores de testing o producción.

Intenteré ir actualizando la lista a medida que me vaya encontrando con otros comandos que considere que valgan la pena.

Los comandos

Bajar el motor

Desde la línea de comandos, ejecutar:

onmode -ky

Podemos hacerlo de forma más “delicada”, siguiendo los siguientes pasos:

Ejecutar

onmode -sy

para dejar no permitir nuevas conexiones, pero permitir que las conexiones que ya estaban abiertas se cierren de forma normal. luego de cerrar todas las conexiones, el servidor queda en quiescent mode, algo así como inactivo, pero no apagado.

El siguiente paso es movernos al siguiente log lógico, ejecutando:

onmode -l

Luego forzamos un checkpoint, de forma de estar seguros de escribir todos los buffers a disco:

onmode -c

Finalmente, ejecutamos el comando para dejar el servidor de Informix offline:

onmode -ky

Subir el motor

Para subir el motor de Informix, ejecutamos sin parámetros el comando:

oninit

En Linux/UNIX, debemos estar logueados como root o como informix para poder ejecutar oninit. En Windows, se debe ejecutar siendo miembro del grupo Informix-Admin.

Ver la descripción de un error

Dado un código de error, podemos obtener una descripción y posibles acciones correctivas ejecutando:

finderr numero#

El resultado es similar al siguiente (cambiando para cada error, claro está):

infordb:~ # finderr 167
-167    ISAM error: Storage-space size is not multiple of PAGESIZE.

The database server administrator sees this error. When you define a
storage space, you must specify a page size that is an integral multiple of
the system page size. The system page size is set in the Parameters
screen when the database server is first initialized.

Pasar una base de transaccional a no transaccional y viceversa

Al restaurar un respaldo de una base de datos, si no decimos explícitamente, la base restaurada no soportará transacciones, sino que quedará en modo no transaccional. Al intentar utilizarla desde nuestras aplicaciones, las sentencias de BEGIN WORK, COMMIT, ROLLBACK, etc. fallarán por estar trabajando la base en este modo.

En estos casos, podemos pasar la base de datos a transactional unbuffered ejecutando el siguiente comando en una terminal:

ontape -s -L 0 -U [database]

O el siguiente, para pasarla a transactional buffered:

ontape -s -L 0 -B [database]

Si por el contrario, queremos pasar una base de modo transaccional a no transaccional, ejecutamos:

ontape -s -L 0 -N [database]

Por información acerca de la diferencia los logging modes transactional unbuffered y transactional buffered, ver este otro post del blog.

Exportar una base de datos

El comando dbexport descarga todos los datos de cada tabla de una base de datos y genera un esquema de la base de datos. Para exportar una base de dato a archivos, debemos ejecutar el siguiente comando en una terminal:

dbexport [database]

Esto generará un directorio [database].exp con los datos de cada tabla, y desplegará por salida estandar (pantalla, al menos que se rediriga a un archivo) un script con la creación de los objetos de la base.

Importar una base de datos

Para importar una base de datos podemos ejecutar el comando dbimport. dbimport lee el archivo de esquema generado por el comando dbexport y crea una base de datos cargando los datos de los archivos. Se puede especificar un dbspace determinado, y el logging mode de la base importada:

dbimport [database] [-i directory] [-d dbspace] [-l [buffered]]

En donde:

  • en [database].exp están ubicados los archivos de datos a importar
  • -d dbspace: especifica el nombre del dbspace en donde la base será creada. Por defecto, será rootdbs.
  • -l: Establece que la base importada funcionará en modo unbuffered transaction logging
  • -l buffered: Establece que la base importada funcionará en modo buffered transaction logging

El parámetro [database] es la ubicación en de los archivos a importar; el comando buscará un directorio llamado [database].exp para leer los datos de las tablas. Si se especifica, se buscará ese directorio dentro de [directory]. Se asume que existirá un archivo [database].exp/[database].sql conteniendo la estructura de la base de datos (tablas, índices, contraints, etc.).

Mostrar información de uso de espacio físico

Ejecutando el siguiente comando desde una terminal, obtenemos un reporte de los diferentes dbspaces y el espacio utilizado en cada uno:

onstat -d

La salida es similar a la siguiente:

infordb:~ # onstat -d

IBM Informix Dynamic Server Version 10.00.FC7     -- On-Line -- Up 1 days 13:15:39 -- 38720 Kbytes

Dbspaces
address          number   flags      fchunk   nchunks  pgsize   flags    owner    name
450c8e78         1        0x60001    1        1        2048     N  B     Informix rootdbs
45253450         2        0x60001    2        1        2048     N  B     Informix datadbs
 2 active, 2047 maximum

Chunks
address          chunk/dbs     offset     size       free       bpages     flags pathname
450c9028         1      1      0          250000     58385                 PO-B  /opt/IBM/Informix/CHUNKS/rootdbs.000
45269db8         2      2      0          1048576    516245                PO-B  /opt/IBM/Informix/CHUNKS/datadbs.000
 2 active, 32766 maximum

NOTE: The values in the "size" and "free" columns for DBspace chunks are
      displayed in terms of "pgsize" of the DBspace to which they belong.

Expanded chunk capacity mode: always

El tamaño y el espacio libre de cada chunk (columnas size y free) están expresadas en páginas. El tamaño de cada página está expresada en bytes en la columna pgsize, por lo que el tamaño de cada chunk está determinado por size x pgsize. Cada chunk está asociado a un dbspace, y esta asociación se detalla en la columna chunk/dbs (el primer número es el id del chunk, el segundo es el id del dbspace).

Este reporte también muestra información de replicación, rutas en dispositivos físicos, etc. Por una descripción completa, ver la página de onstat -d en la Administrator’s Reference de Informix.

Actualizar las estadísticas

Desde dbaccess u otro cliente de Informix, podemos ejecutar los siguientes comandos para actualizar las estadísticas de la base de datos:

Actualizar estadísticas de todas las tablas la base de datos:

update statistics

Para actualizar además las estadísticas de distribución de cada tabla (es más lento):

update statistics high

Para actualizar las estadísticas para una tabla:

UPDATE STATISTICS [HIGH] FOR TABLE [tabla]

Lock mode de las tablas

En este post escribí acerca de los lock modes de Informix. Para obtener la información acerca del tipo de bloqueo que tienen las tablas de una base podemos ejecutar la sigiuente consulta:

SELECT tabname,locklevel FROM systables WHERE tabid>99

La columna tabname contiene el nombre de la tabla, la columna locklevel contiene ‘P’ si el lock mode es por página, o ‘R’ si es por tupla.

Para crear una tabla con un lock mode determinado lo especificamos al ejecutar el comando CREATE TABLE:

CREATE TABLE customer(customer_num serial, lname char(20)...)
LOCK MODE ROW|PAGE|TABLE;

Para cambiar el lock mode de una tabla utilizamos el comando ALTER TABLE:

ALTER TABLE [tabla] MODIFY
LOCK MODE (PAGE|ROW|TABLE)

Referencias

Categories: base de datos Tags:

Lock modes de tablas de Informix

Miércoles, 7 de Octubre de 2009 jarrarte Sin comentarios

El lock mode de una tabla especifica el nivel de granularidad que se tendrá para acceder a los datos de forma concurrente. Hay 3 niveles: por tupla (row), por página (page), o por tabla (table).

Al menos que se explicite, al crear una tabla el modo de bloqueo (lock mode) será por página. Si la tabla tiene muchos accesos concurrentes, se puede aumentar la granularidad y usar el modo de bloqueo a nivel de tupla. Este aumento de la granularidad conlleva a un aumento en la cantidad de objetos bloqueados que se deben mantener, lo que redunda en mayor uso de memoria y una posible baja de performance del motor.

Un nivel de bloqueo por tupla sirve cuando se actualizan pocas tuplas de una tabla, o cuando es necesario actualizar de forma concurrente (desde distintas sesiones) distintas tuplas de la misma página. En este caso, si los bloqueos son por página, es posible que las actualizaciones fallen, o tengan que esperar que se termine de actualizar una tupla de la misma página.

El tipo de bloqueo por tabla utiliza menos recursos que los bloqueos por página o tupla. Este tiplo de bloqueo se pueden utilizar en procesos batch, cuando es un único proceso que accede a cada tabla de la base de datos. De deben tener recaudos con este bloqueos de tablas en sistemas de tipo OLTP. Ante un bloqueo de una tabla, otros procesos de sólo lectura igual podrán acceder a los datos de la misma.

Para obtener la información acerca del tipo de bloqueo que tienen las tablas de una base podemos ejecutar la sigiuente consulta:

SELECT tabname,locklevel FROM systables WHERE tabid>99

La columna tabname contiene el nombre de la tabla, la columna locklevel contiene ‘P’ si el lock mode es por página, o ‘R’ si es por tupla.

Para crear una tabla con un lock mode determinado lo especificamos al ejecutar el comando CREATE TABLE:

CREATE TABLE customer(customer_num serial, lname char(20)...)
LOCK MODE ROW|PAGE|TABLE;

Para cambiar el lock mode de una tabla utilizamos el comando ALTER TABLE:

ALTER TABLE [tabla]
MODIFY LOCK MODE (PAGE|ROW|TABLE)
Categories: base de datos Tags:

Diferencias entre transactional unbuffered y transactional buffered en Informix

Miércoles, 7 de Octubre de 2009 jarrarte Sin comentarios

Vale la pena destacar la diferencia entre estos dos modos de trabajo (logging modes) de las bases de datos de Informix.

Informix siempre persiste los datos escribiendo a alguno de sus buffers de log lógico. Si la base de datos en la cual se están haciendo cambios está trabajando en modo unbuffered, estos cambios se escriben al disco duro inmediatamente después de que un registro de commit o rollback llega al log lógico. Si la base de datos está trabajando en modo buffered, el servidor mantiene estos cambios se mantienen en el log el mayor tiempo posible, hasta que ocurre alguno de los siguiente eventos:

  • Un buffer se llena
  • Se ejecuta un checkpoint
  • Se cierra la conexión contra la base de datos
  • Se hace un commit a una base que está trabajando en modo unbuffered

En el modo buffered, existen problemas si el sistema se bloquea antes de que el buffer de log lógico sea escrito al disco duro pero después de la transacción que el usuario completó ejecutando un commit. La transacción se considerará incompleta y se ejecutará un rollback cuando el motor sea reiniciado y se recupere. En modo unbuffered esto no sucede ya que luego del commit se escribirán los datos de la transacción en el disco duro y no se perderán.

Por defecto, se trabaja en modo unbuffered. Si bien enlententece un poco el motor, es más robusto que el modo buffered frente a caídas del motor en lo que a pérdida de datos respecta.

El tamaño de los buffers de logs lógicos se pueden averiguar en el archivo onconfig (parámetro LOGBUFF).

Referencias:

Categories: base de datos Tags: