En esta sección: Cómo: |
Es poco habitual que la integridad estructural de un origen de datos de FOCUS esté dañada. Sin embargo, ocasionalmente pueden producirse daños estructurales por el fallo de una unidad o el uso de un archivo máster incorrecto. En estos casos, el comando REBUILD CHECK realiza dos tareas esenciales:
Aunque CHECK es capaz de informar acerca de una gran cantidad de datos, que de otra forma se perderían, es importante recordar que la mejor manera de evitar la pérdida de datos es realizar copias de seguridad de sus orígenes de datos FOCUS, de modo habitual.
Ocasionalmente, CHECK no es capaz de descubrir un daño estructural. Si tiene motivos para creer que su origen de datos está dañado, aunque CHECK indique lo contrario, existe otro método para comprobar la integridad de los orígenes de datos. Éste método utiliza los comandos ? FILE y TABLEF. Aunque no se trata de una función REBUILD, está incluida al final de esta sección por su importancia con respecto a CHECK.
Los siguientes pasos describen cómo usar el subcomando CHECK:
REBUILD
Están disponibles las siguientes opciones:
1. REBUILD (Optimize the database structure) 2. REORG (Alter the database structure) 3. INDEX (Build/modify the database index) 4. EXTERNAL INDEX (Build/modify an external index database) 5. CHECK (Check the database structure) 6. TIMESTAMP (Change the database timestamp) 7. DATE NEW (Convert old date formats to smartdate formats) 8. MDINDEX (Build/modify a multidimensional index)
CHECK or 5
En z/OS, introduzca el ddname.
En UNIX, Windows y OpenVMS, introduzca filename. El origen de datos que se va a reconstruir aparece citado en un comando USE. Si no hay ningún comando USE en vigor, el origen de datos se buscará utilizando la variable EDAPATH.
Las estadísticas aparecen durante el procedimiento REBUILD CHECK:
DELETE indica que los datos se han borrado y que no se deberían haber recuperado.
OFFPAGE indica que la dirección de los datos no está en un página perteneciente al segmento.
INVALID indica que el tipo de enlace no se puede identificar. Puede tratarse de una porción destruida del origen de datos.
El siguiente procedimiento:
1. REBUILD 2. CHECK 3. EMPLOYEE
Se verifica el origen de datos y se generan las estadísticas correspondientes.
Cómo: |
Si piensa que su origen de datos está dañado, aunque REBUILD CHECK indique lo contrario, emplee los comandos ? FILE y TABLEF para comparar el número de segmentos mencionados, después de invocar cada comando. La disparidad indica la presencia de un problema estructural.
? FILE filename donde:
Es el nombre del origen de datos de FOCUS que está examinando.
Un informe muestra detalles sobre el estado del origen de datos. El número de copias de cada segmento aparece listado en la columna ACTIVE COLUMN.
SET ALL = ON
TABLEF FILE filename COUNT field1 field2 END
donde:
Es el nombre del archivo máster del origen de datos de FOCUS.
Son los nombres de los campos del origen de datos. Nombre un campo de cada segmento. No importa el campo que nombre en el segmento.
El informe generado muestra el número de veces que ocurre un campo nombrado y, por tanto, el número de copias de cada segmento. Estos números deberían coincidir con los números correspondientes de las copias de los segmentos, mostrados en el comando ? FILE (excepto los segmentos únicos, para los que el comando TABLEF indica el número de copias en el segmento principal). Si los números no coinciden o el comando ? FILE, o TABLEF, finaliza de forma anormal, lo más seguro es que el origen de datos esté dañado.
La entrada del usuario aparece en negrita. Las respuestas del PC están en mayúscula:
? FILE STATUS OF FOCUS FILE: c:employee.foc ON 01/31/2003 AT 16.17.32 ACTIVE DELETED DATE OF TIME OF LAST TRANS SEGNAME COUNT COUNT LAST CHG LAST CHG NUMBER EMPINFO 12 05/13/1999 16.17.22 448 FUNDTRAN 6 05/13/1999 16.17.22 12 PAYINFO 19 05/13/1999 16.17.22 19 ADDRESS 21 05/13/1999 16.17.22 21 SALINFO 70 05/13/1999 16.17.22 448 DEDUCT 448 05/13/1999 16.17.22 448 TOTAL SEGS 576 TOTAL CHAR 8984 TOTAL PAGES 8 LAST CHANGE 05/13/1999 16.17.22 448 SET ALL = ON TABLEF FILE EMPLOYEE COUNT EMP_ID BANK_NAME DAT_INC TYPE PAY_DATE DED_CODE END PAGE 1 EMP_ID BANK_NAME DAT_INC TYPE PAY_DATE DED_CODE COUNT COUNT COUNT COUNT COUNT COUNT ------ --------- ------- ----- -------- -------- 12 12 19 21 70 448 NUMBER OF RECORDS IN TABLE= 488 LINES= 1
Observe que el recuento de BANK_NAME, en el informe TABLEF, es distinto al número de copias de FUNDTRAN, mencionado por la consulte ? FILE. Esto se debe a que FUNDTRAN es un segmento único y siempre se considera presente como una extensión de su segmento principal.
| WebFOCUS |