Ficheros Secuenciales vs Ficheros VSAM ¿Cuál es el mejor?

Ficheros Secuenciales

Hoy vamos a tratar el tema, de archivos secuenciales contra VSAM, y para aquellos que son principiantes con el tema, vamos a desmenuzar un poco algo de cada uno de los ficheros con el fin de que a la hora de desarrollar sepan cual es el más óptimo.

Un archivo secuencial es aquel que consta de registros que se almacena y se accede a ellos de modo secuencial (de principio a fin), es decir que si quieres hacer la lectura del registro ocho, tienes que hacer las siete lecturas de los registros, para llegar.

Te recomendaría este tipo de archivo si quisieras que

•          El tamaño de memoria fuera mínimo
•          El archivo fuera fácilmente editable

Se pueden enumerar los principales atributos del archivo de organización secuencial

• Un nuevo registro no se puede insertar ni en medio ni al principio del archivo, este siempre se insertara al final del archivo.
• Después de especificar el tamaño de un registro en un archivo secuencial, no es posible, reducir o alargar un registro.
• El orden de  los registros, tal y como se insertan no puede ser cambiado.
•  Es posible la actualización de un registro, pero esto solamente es posible “a manita” a través de la opción del TSO,  de edición. Se puede también sobrescribir un registro, siempre y cuando la nueva longitud de registro sea la misma.
• Los archivos secuenciales para la escritura de registros de salida son una buena opción, teniendo en cuenta, que no requieren de más especificaciones que el tamaño del registro sea el tamaño del archivo.

Dentro del programa siempre se podrá especificar la sintaxis de la organización del archivo secuencial:

       FILE-CONTROL                                           

       SELECT ENTRADA ASSIGN TO ENTRADA                

                       ORGANIZATION IS SEQUENTIAL       

                       ACCESS MODE  IS SEQUENTIAL       

                       FILE STATUS IS WS-FS-ENTRADA.   

Donde

ENTRADA: Archivo que se va a tomar de entrada, el cual deberá de ser secuencial

ORGANIZATION: Se especifica que su organización es secuencial

ACCESS MODE: El modo de acceso, el cual se especifica que es secuencial

FILE STATUS: El estatus del archivo el cual deberá de comenzar con 00.

Mientras que en el JCL nosotros podemos encontrarlo como se muestra en el ejemplo de a continuación:

//ENTRADA  DD  DSN=MOVDELL.R08.I1OUP10.SORTINYU,

//             DISP=(OLD,KEEP,KEEP)                

ENTRADA: Archivo que se va a mandar a llamar para entrada del proceso.

También vamos a mencionar algunos de los inconvenientes que tienen estos archivos:

•          A tamaño grande la lectura se ralentiza
•          El acceso a los archivos es puramente secuencial

Por lo cual dependiendo del tamaño de información que vas a procesar, si esta información aumenta o si es constante, o dependiendo de que tantos reportes o movimiento de información vas a realizar con ella, son puntos que debes de tomar en cuenta para validar si es viable este tipo de archivos.

Ficheros VSAM

Definidos como Virtual Storage Access Method, es un tipo de fichero que trata de mejorar lo que se hace con los ficheros secuenciales  y el cual soporta que se tenga un mayor número de registros, y que estos de igual forma puedan ser procesados en un tiempo más óptimo y con un acceso más eficaz.

Estos archivos se caracterizan por tener una llave (clave) de acceso a cada uno de los registros lo cual permite que se tenga un mejor acceso a los archivos,

En la actualidad existen tipos de ficheros: VSAM, KSDS, RRDS, RRDS, ESDS y LDS. 

Se muestra a continuación una breve explicación de en que consiste cada uno de ellos:

• Entry Sequenced Data Set (ESDS): Se trata de un fichero VSAM, equivalente al clásico Fichero Secuencial
• Key Sequenced Data Set (KSDS): Emplea dos subficheros para el tratamiento de los datos. Uno para el almacenamiento de los índices, y otro para la información (Registros de datos) asociada a cada índice.
• Relative Record Data Set (RRDS): Se trata del VSAM mas eficiente. Se asigna un numero relativo a cada registro, que es el que se usara para recuperar la información. Obviamente, si dicha asignación no se actualiza correctamente cada vez que borramos registros del fichero, entonces iran quedando espacios de memoria sin uso y el acceso será cada vez menos eficiente.
• Linear Data Set (LDS): Este tipo de fichero se emplea para almacenar los TABLESPACE de las bases de datos DB2.

Puede ser raro que veas un desarrollo hecho en archivos VSAM. Esto debido a que cuando se implementó no se tenían bien especificadas las reglas de las bases de datos relacionales dentro del DB2, pero ahora se ha vuelto una práctica más usual que se utilicen las bases de datos relacionales con los archivos secuenciales. O que en casos muy especiales se utilicen desarrollos con archivos VSAM.

Te mostraremos así mismo algunas de las ventajas/ desventajas que tienen estos archivos.

•      Estos archivos pueden ser de una longitud fija o variable   
•     Están organizados en bloques de tamaño fijo llamados intervalos de control (IC) y a su vez en divisiones más grandes llamadas Áreas de Control (AC)
•     El tamaño de los intervalos se miden en bytes
•     Las áreas de control se miden en número de pistas o cilindros de disco.

La manipulación de ficheros VSAM (“borrar” y “definir”) se realiza normalmente a través de la utilidad de IDCAMS. Los programas propios pueden acceder a ficheros VSAM mediante sentencias de “data definition” (DD) en los JCL o en las regiones online de CICS.

DB2 está implementado sobre ficheros VSAM usando su estructura de datos. 

Espero que te haya gustado el tema. :D

DB2 - Sequences

Seguramente todos conocemos la posibilidad de definir una columna de una tabla con IDENTITY, para que de esa forma se nos autogeneren valores y no tengamos que preocuparnos de realizar el típico SELECT MAX. Otro método un poco más desconocido para realizar esto son las SEQUENCES.

Una SEQUENCE es un objeto almacenado que permite generar una secuencia de números en forma ascendente o descendente. Aunque hay similitudes con una columna IDENTITY, la principal diferencia es que mientras la columna IDENTITY se define dentro del ámbito de una tabla, una SEQUENCE no está ligada a una sola tabla, por lo que puede ser usada desde varias. Esto permite usar la SEQUENCE para generar una clave primaria y coordinarla entre registros de distintas tablas.

Las principales características de una secuencia son:

• Garantiza valores únicos.
• Genera valores de forma creciente o decreciente dentro de un rango.
• Puede incrementar valores en más de 1 unidad
• Si se produce un error en DB2 la secuencia se reconstruye a partir del log, lo que garantiza que se seguirán generando correctamente los valores tras un fallo.

 Aquí va un ejemplo de cómo crear una secuencia:

CREATE SEQUENCE EJEMPLO_SEQ
       START WITH 1
       INCREMENT BY 1

Indicamos que deseamos crear la secuencia EJEMPLO_SEQ que comenzará en 1 y se incrementará en una unidad.

Ahora, suponiendo que la secuencia no se ha usado todavía, vamos a generar el primer valor y lo usaremos para insertar en la columna ID de la tabla EJEMPLO_TAB1. Tenemos dos opciones, generar el valor en el INSERT o generar el primer valor en una variable y luego utilizarlo en el INSERT.

Ejemplo de generarlo directamente en el INSERT:

INSERT INTO EJEMPLO_TAB1 (ID, NOMBRE)
VALUES (NEXT VALUE FOR EJEMPLO_SEQ, 'LOBOC');

Ejemplo de generar el valor sobre una variable y luego usarla en el INSERT:

SELECT NEXT VALUE FOR EJEMPLO_SEQ INTO :VAR_SEQ;

INSERT INTO EJEMPLO_TAB1 (ID, NOMBRE)
VALUES (:VAR_SEQ, 'LOBOC');

Cuando generamos un valor para una secuencia con NEXT VALUE (aunque este se realice en un SELECT) ese valor es consumido, y la próxima vez que se solicite un valor se generará uno nuevo. Esto ocurre incluso cuando se produce un fallo en la sentencia que contiene el NEXT VALUE o cuando se realiza rollback.

Justamente una de las potencias de las secuencias, el que garanticen que un NEXT VALUE siempre genera un nuevo valor bajo cualquier circunstancia podría llegar a ser un inconveniente. Por ejemplo, imaginemos que en un proceso batch generamos un fichero de LOAD donde para cada registro generamos un valor con NEXT VALUE. Si el fichero tiene 100.000 registros, habremos incrementado la secuencia en 100.000. Luego por cualquier problema o error, ese fichero de LOAD no se llega a cargar y se descarta. Esos 100.000 valores ya se habrán consumido y se habrán quedado huérfanos. En ciertos casos, donde sea importante que los números sean correlativos y no existan "huecos" (ej: numeración de las facturas) o donde tengamos el ID bastante ajustado en tamaño y no queremos que se nos consuman más valores de los estrictamente necesarios, quizás el uso de SEQUENCES no sea lo más recomendado.

Para profundizar más en el tema de las SEQUENCES os remitimos al  SQL Reference (SC19-2983-03) de IBM

NOTA: Para conocer las secuencias que ya están definidas podemos usar la siguiente consulta:

SELECT * FROM SYSIBM.SYSSEQUENCES

Fuente: SQL Reference (SC19-2983-03) IBM