IBM MQSeries con .NET 2008 - II Parte

Descriptor de mensajes

Recordemos que un mensaje consiste del control de la información y los datos de la aplicación. El control de la información en una estructura descriptora de mensaje (MQMD) contiene lo siguiente:

• El tipo del mensaje.
• El identificador del mensaje (muy importante cuando se usa grouping) .
• La prioridad de envío del mensaje.

La estructura y contenido de los datos de aplicación son determinados por los aplicativos participantes, no por WebSphere.

¿Qué es una cola de mensajes?

Una cola de mensajes, llamada simplemente cola, es un encapsulamiento por el cual los mensajes pueden ser enviados. Los mensajes pueden ser almacenados en colas hasta que son devueltos por los aplicativos que dan el servicio a esas colas. Las colas residen y son administradas por un administrador de colas. Una cola también puede ser un área de buffer volátil, o un conjunto de datos permanente en un dispositivo de almacenamiento, como un disco. La administración física de colas es responsabilidad del administrador de colas y no de los aplicativos participantes.
Los aplicativos pueden acceder a las colas solamente a través del administrador de colas (de hecho, no habría forma física de acceso de nos ser así), debido a que éste objeto es el lleva las credenciales de acceso del usuario, el puerto y el canal en una tabla hash o por directivas de ambiente. De esta manera se pueden llevar a cabo operaciones como, abrir una cola (open), colocar mensajes (put), obtener mensajes de respuesta (get), y cerrar colas (close). Además, se pueden "setear" los atributos de las colas, por decir, el formato, la conversión de datos, las banderas de comportamiento, etc.

¿Qué es un administrador de colas?

Es un componente que provee servicios de colas a las aplicaciones. El cual, expone un API que permite colocar (hacer put) y obtener (hacer get) mensajes hacia y desde las colas. Un administrador de colas provee funciones adicionales para crear nuevas colas, modificar las propiedades de las existentes, y controlar la operación de éstas.

Para que los servicios de mensajería de colas estén disponibles en un sistema; debe haber un administrador de colas corriendo sobre un sistema operativo compatible, tales como: OS/400, z/OS, OS/2, Windows, UNIX o Linux. También se puede tener varios administradores de colas corriendo en un mismo sistema (para escenarios de prueba y producción por separado). Se debe tener en cuenta que para cada aplicativo, cada administrador de colas es identificado por un connection handle (Hconn) propio.

Muchos aplicativos diferentes pueden hacer uso de los servicios de administración de colas al mismo tiempo y no estar relacionados unos con otros, ni en tecnología, ni en función u objetivos.

Para que un aplicativo use estos servicios, debe establecer una conexión al administrador de colas (con los datos adecuados obviamente). Además, para que éstos puedan enviar mensajes entre aplicaciones, todos los administradores de colas deben comunicarse entre sí, por canales en común ya establecidos. WebSphere logra esta implementación debido al protocolo de almacenaje y envío (store-and-forward protocol), el cual asegura la entrega de los mensajes debido a que es orientado a conexión.

Nos queda poco por cubrir con respecto a definiciones, así que, preparados porque ya casi vemos código. Nos vemos.

Comprimir TempDB en SQL Server

Debido a situaciones de origen laboral, en la oficina se ha tenido que contar muchas veces con la opción de comprimir la base de datos temporales de sistema que tiene SQL Server (2005-2008).

Encontre dos maneras (lo que indica que no existan más formas) de realizar esa tarea, los describo de seguido.

Método 01: Comprimir y modificar archivo

Según leí, Microsoft desestima comprimir cualquier TempDB que este siendo usada constantemente. Esto es porque "you may receive multiple consistency errors" que podrían no solamente interrumpir actividades de usuarios cuando se da la operación de compresión. Sin embarga esa actividad normalmente es mínima o nula, en todo caso, aquí están los pasos:

1. Corra el comando DBCC SHRINKFILE en cada archivo que usted quiera reducir el tamaño:
   USE TempDB
   GO
   DBCC SHRINKFILE (N'logical_file_name', 5) -- reducir en 5 MB
2. Luego corra ALTER DATABASE, con el tamaño que usted quiere que sean. Esto causará que el nuevo tamaño se registre en master.sys.master_files, la cual es un catalogo de sistema que SQL Server usa para recrear una nueva TempDB en blanco cada vez que una server/instance es reiniciada.
   USE MASTER
   GO
   ALTER DATABASE TEMPDB MODIFY FILE (NAME=' logical_file_name, SIZE=6MB)

Note que hasta que SQL Server es reiniciado (cuando TempDB es recreada) los cambios no mostraran los nuevos valores en la Database Properties o en la Shrink File GUI. Sin embargo, se pueden verificar los cambios inmediatamente con:

SELECT DB_NAME(DATABASE_ID)DBNAME, [NAME] LOGICAL_FILENAME, [SIZE]*8/1024 SIZE_MB
FROM MASTER.SYS.MASTER_FILESWHERE DB_NAME(DATABASE_ID) = 'TEMPDB'

Método 02: Modificar archivos en modo de usuario restringido

Este método elimina el riesgo de errores de consistencia. Con la salvedad, que tendrás que desconectar a todos los usuarios antes de hacer algún cambio. Sin embargo, si lo planeas bien, se podrá hacer esos cambios en 10 minutos haciendo estos pasos:

1. Establezca una Coenxion Dedicada de Administrador (DAC) en el Management Studio para conectarse. Tan sencillo como anteponiendo "Admin:" en frente de la instacia de nombre. P.E., ADMIN:Rep-Server\Instancia1.

2. Corra:

• ALTER DATABASE with the REMOVE -- opción para marcar los .ndf como obsoletos.
• USE MASTER GO ALTER DATABASE TEMPDB REMOVE FILE logical_file_name

3. Detenga la instancia desde el command prompt. Para la default instance use:

• C:\>NET STOP MSSQLSERVER
• o
• NET STOP "SQL Server (MSSQLSERVER)"
• o para la named instance:
• C:\> NET STOP "SQL Server ( instancename )"
• o
• NET STOP MSSQL$instancename

4. Inicie la instancia en modo restringido con:

• C:\SQL\MSSQL.1\MSSQL\Binn>sqlservr.exe -c -f

5. Mofique la TempDB con el nuevo tamaño inicial para el .mdf y el .ldf desde la conexión dedicada en SSMS (hasta que reinicie SQL Server en modo normal, será la única conexión disponible).

• USE MASTER
• GO
• ALTER DATABASE TEMPDB MODIFY FILE (NAME='logical_file_name', SIZE=6MB)

6. Regrese al command prompt y teclee Ctrl + C para salir del modo restringido (diga si cuando el prompt pregunte si quiere detener SQL Server). Entonces inicie la instacia en modo normal. Para la default instance:

• C:\NET START MSSQLSERVER
• o
• NET STOP "SQL Server (MSSQLSERVER)"

7. Modifique la TempDB con la opción Add File activada con el nuevo tamaño para los archivos .ndf.

• ALTER DATABASE TEMPDB ADD FILE (NAME=logical_file_name, FILENAME='C:\bla\bla\Data\logical_file_name.ndf', SIZE=6MB)

8. Al final corra esta consulta para asegurarse de que todos los cambios fueron realizados apropiadamente en la base de datos Master:

• SELECT DB_NAME(DATABASE_ID)DBNAME, [NAME] LOGICAL_FILENAME, [SIZE]*8/1024 SIZE_MB FROM MASTER.SYS.MASTER_FILES WHERE DB_NAME(DATABASE_ID) = 'TEMPDB'

Podemos observar que el primer método es más simple y rápido, pero pero se corre un riesgo inherente de corromper los datos en la TempDB. Además, la operación de compresión puede no terminar debido al uso concurrente de dichos archivos. Ahora bien, el segundo método es más elaborado pero asegura una operación limpia. Sin embargio requiere detener el sistema.
Espero les sirva.

IBM MQSeries con .NET 2008 - I Parte

Esta es la primera entrega de una serie de artículos sobre el uso de MQ's en .NET, utilizando VB .NET 2008. Esta serie de artículos es dirigido a arquitectos y desarrolladores que están buscando una manera de integrar las aplicaciones de .NET con servidores IBM WebSphere MQ (IBM MQSeries).

Introducción

La mensajería por colas de espera se ha usado durante muchos años. Normalmente usado hoy en día para el correo electrónico. Sin utilizar colas, enviar un mensaje electrónico sobre grandes distancias requiere que cada nodo en la ruta esté disponible para remitir dichos mensajes. En un sistema de formación de colas de espera, se guardan los mensajes en nodos intermediarios hasta el sistema está listo para remitirlos o procesarlos. Por supuesto que eso causa cierto grado de overhead en la red, pero pondremos en la balanza ciertos beneficios para justificar este proceder.

Aun así, se procesan billones de transacciones comerciales complejas sin hacer queuing. Si éste es el caso; ¿entonces por qué necesitamos la formación de colas de espera? Piense detenidamente en un sistema que consiste en nodos múltiples dónde estos necesitan comunicarse entre sí. Si un nodo del sistema sufre un problema, muchos otros podrían quedar inutilizables. En un ambiente de queuing, cada programa del juego que constituye el sistema se diseña para desempeñarse como debe ser, como una función autónoma en respuesta a una solicitud específica. Para comunicarse con otro programa, este debe poner un mensaje en una cola predefinida, el otro programa recupera el mensaje de la cola y procesa el mensaje. En pocas palabras queuing es un estilo de comunicación programa-a-programa.

Queuing es el mecanismo por el que se sostienen los mensajes hasta que una aplicación está lista a procesarlos. Este tipo de comunicación permite:

• La comunicación entre programas (puede cada uno está corriendo en los ambientes diferentes) sin tener que escribir el código de comunicación.
• Seleccionar el orden en que un programa procesa los mensajes.
• El balanceo de cargas en un sistema, colocando más de un programa para reparar una cola cuando el número de mensajes excede el umbral permitido.
• Aumentar la disponibilidad de sus aplicaciones, al levantar un sistema alternativo para reparar las colas si su sistema primario está caído.

¿Qué es un mensaje?

En queuing, un mensaje es simplemente una colección de datos enviada por un programa a otro intencionalmente. MQ WebSphere define cuatro tipos de mensaje principalmente:

• Datagrama (Datagram): Un mensaje simple para el que ninguna contestación se espera.
• Solicitud (Request): Un mensaje para el cual se espera una contestación.
• Respuesta (Reply): Una contestación a un mensaje solicitado.
• Reporte (Report): Un mensaje que describe un evento, como la ocurrencia de un error.

Para manipular mensajes se necesita control de la información y de los datos de la aplicación. El control de la información se define en una estructura descriptora de mensajes (MQMD), la cual contiene:

• El tipo de mensaje.
• Un identificador para el mensaje.
• La prioridad para el envío del mensaje.
• La estructura y contenido de los datos de aplicación son definidos por los programas en sí, no por Websphere MQ.

Bueno hasta aquí por hoy.

Bienvenidos

Este es mi primer post de introducción. Espero que de ahora en adelante podamos compartir conocimientos de diferentes áreas de desarrollo de software, arquitectura, bases de datos y más.

Espero que los posts sean de su agrado.