MXPA04010351A - Recuperacion de archivo de datos. - Google Patents

Abstract

La estructura de datos de los datos removidos de una base de datos puede ser almacenada con los datos removidos. Los datos removidos pueden ser restaurados a la misma o a una estructura de datos diferente. La informacion de identificacion acerca de los datos removidos puede ser almacenada. Una etiqueta atributo que identifica la coleccion de los datos dentro d la base de datos puede ser asociada con cada elemento de datos removido. Un elemento de datos removido puede ser restaurado a la base de datos mediante el comparar la etiqueta de atributo del elemento de datos removido con las etiquetas de atributo en la estructura de datos actual y agregar el elemento de datos a la base de datos como se indico por la etiqueta de atributo correspondiente.

Description

RECUPERACIÓN DE ARCHIVO DE DATOS CAMPO TÉCNICO Esta descripción se refiere a técnicas para restaurar datos archivados en un almacén en linea en un sistema de computadora .

ANTECEDENTES Un sistema de computadora puede almacenar una gran cantidad de datos. Algunos datos pueden requerir el estar disponibles para acceso en linea por los usuarios del sistema de computadora, mientras que otros datos no requieren estar disponibles para el acceso en linea. Los datos que no requieren estar disponibles para el acceso en linea pueden ser archivados en un medio fuera de linea y ser removidos del almacén en linea.

Los datos almacenados en los medios fuera de linea pueden requerir el ser restaurados para el acceso en linea. Algunos de los datos almacenados fuera de linea pueden no ser adecuados para restaurarse en estructuras de datos en linea que existen cuando los datos van a ser restaurados. Por ejemplo, si la estructura de datos en linea cambia después de que los datos son archivados, los datos archivados pueden no ser capaces de ser restaurados. Este problema puede ser resuelto mediante el almacenar la estructura de datos en adición a los datos archivados. Un programa de conversión puede ser desarrollado y aplicado en el momento de la restauración para mover los datos archivados a la estructura de datos en linea cambiada. Frecuentemente el nivel de esfuerzo requerido para desarrollar un programa de conversión para restaurar datos archivados puede ser significante. Como resultado, la información en un almacén fuera de linea puede hacerse menos valiosa con el tiempo debido a la dificultad de restaurar los datos archivados.

SÍNTESIS En un aspecto general, el restaurar los datos archivados incluye el mover físicamente los datos de una colección de datos a otra colección de datos. La información de estructura de datos está asociada con los datos movidos, y los datos movidos son restaurados a una tercera colección de datos basándose sobre una comparación de la información de estructura de datos de la tercera colección de datos con la información de estructura de datos asociada con los datos movidos.

Las implementaciones pueden incluir una o más de las siguientes características. Por ejemplo, la información de estructura de datos, tal como una etiqueta de atributo, puede ser asociada con los datos movidos o la colección de datos. Los datos movidos pueden incluir una serie de valores de atributo movidos, cada uno de los cuales pueden estar asociados con una etiqueta de atributo. Un mapa de datos puede ser creado que asocia una etiqueta de atributo de datos movidos con una etiqueta de atributo en una colección de datos. Y aparte una estructura de datos puede estar asociada con la colección de datos de la cual los datos archivados son físicamente movidos, y una estructura de datos diferente puede estar asociada con la conexión de datos a la cual los datos archivados son restaurados.

Una primera estructura de datos puede tener un primer grupo de atributos que incluye un primer atributo y un segundo atributo. Una segunda estructura de datos puede tener un segundo grupo de atributos que incluye un tercer atributo y un tercer grupo de atributos que incluye un cuarto atributo. Los datos que tienen un primer valor de atributos asociado con el primer atributo y un segundo valor de atributo asociado con el segundo atributo pueden ser movidos físicamente de la conexión con la primera estructura de datos y restaurarse a una tercera conexión de datos con una segunda estructura de datos mediante el asociar el primer valor de atributo con el tercer atributo y asociar el segundo valor de atributo con el cuarto atributo.

Las colecciones de datos pueden ser sistemas de base de datos de relación. Alternativamente, las colecciones de datos pueden ser sistemas de base de datos orientados-objeto.

Los sistemas y técnicas descritos pueden ser usados para restaurar datos archivados en sistemas de procesamiento de transacción en línea a gran escala (OLTP) o en sistemas que almacenan datos en ambientes de base de datos muy grandes (VLDB) . Los sistemas de procesamiento de transacción en linea a gran escala típicamente generan grandes cantidades de da os que requieren estar en línea por un periodo de tiempo. Al hacerse menos útiles con la edad, los datos pueden ser archivados fuera de línea y pueden algunas veces ser necesario el restaurar los datos en estructuras que existen en línea. Los datos de operación en línea almacenados en ambientes de base de datos muy grandes pueden exceder dos terabytes, 900 tablas de base de datos, y 17,000 atributos.

Las implementaciones de las técnicas discutidas anteriormente pueden incluir un método o proceso o software de computadora sobre un medio accesible por computadora.

Los detalles de una o más de las implementaciones se establecen en los dibujos acompañantes y en la descripción que sigue. Otras características y ventajas serán evidentes de la descripción y dibujos y de las reivindicaciones.

DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 es un diagrama de bloque de un sistema programable para restaurar datos archivados en un almacén en línea.

La Figura 2 es un diagrama de bloque que ilustra un expediente que incluye datos archivados y la estructura usada para los datos archivados.

La Figura 3 y la Figura 4 son diagramas de bloque y que ilustran tablas de base de datos que almacenan datos archivados que se han restaurados.

La Figura 5 es un esquema de flujo de un procedimiento para archivar datos.

La Figura 6 es un esquema de flujo de un procedimiento para restaurar datos archivados en un almacén en linea.

Los símbolos de referencia iguales en los varios dibujos indican elementos iguales.

DESCRIPCIÓN DETALLADA Refiriéndose a la Figura 1, un sistema programable 100 para restaurar datos archivados de un almacén fuera de línea a un almacén en línea incluye una variedad de dispositivos de entrada/salida (1/0) (por ejemplo, un mouse 103, un teclado 105, un exhibidor 107) y una computadora 110 que tiene una unidad procesadora central (CPU) 120, una unidad de entrada/salida 130, una memoria 140 y un dispositivo de almacén de datos 150. El dispositivo de almacén de datos 150 puede almacenar las instrucciones que pueden ser ejecutadas por la máquina, los datos y varios programas tales como un sistema de operación 152 y uno o más programas de aplicación 154 para restaurar los datos archivados, todos los cuales pueden ser procesados por la unidad procesadora central 120. Cada programa de computadora puede ser implementado en un procedimiento de alto nivel o en lenguaje de programación orientado-objeto, o en un lenguaje de máquina o de conjunto si se desea; y en cualquier caso, el lenguaje puede ser un lenguaje compilado o interpretado. El dispositivo de almacén de datos 150 puede ser cualquier forma de una memoria no volátil, incluyendo por vía de ejemplo dispositivos de memoria semi-conductora, tal como una Memoria De Sólo Leer Programable y que puede ser borrada (EPROM) , una Memoria De Sólo Leer Que Puede Ser Programada Eléctricamente Borrable (EEPROM) , y un dispositivo de memoria instantánea, discos magnéticos tal como discos duros internos y discos removibles; discos ópticos; y una Memoria De Sólo Leer De Disco Compacto (CD-ROM) .

El Sistema 100 puede incluir uno o más dispositivos de almacenamiento en línea periféricos 156 para almacenar datos en línea y uno o más dispositivos de almacén fuera de línea periférico 157 para almacenar y accesar medios de almacén fuera de línea, tal como un accionador de cinta, un tocadiscos de cinta, accionadores de discó estacionarios o removibles (de estado magnético, óptico o sólido; solo o bien organizado en arreglo) o dispositivos de estado-sólido. El dispositivo de almacén en línea periférico 156 puede usar cualquier medio de almacenamiento (incluyendo medios de almacenamiento de estado sólido, magnético u óptico) o cualquier tipo de dispositivo de almacén (incluyendo un accionador, un microaccionador, un disco compacto (CD) un disco compacto que puede ser registrado (CD-R) , un disco compacto que puede ser escrito de nuevo (CD-RW) , memoria instantánea o tarjetas de disco suave de estado sólido (SSFDC) ) .

El Sistema 100 también puede incluir medios de almacén fuera de linea removibles 158 y 159 que no estén físicamente conectados al sistema 100. Tales medios de almacén fuera de linea removible 158 y 159 pueden incluir cualquier tipo de medios de almacén (incluyendo medios de almacén magnético, óptico o sólido) o cualquier tipo de dispositivo de almacenamiento (incluyendo un accionador, un microaccionador, un disco compacto (CD) , un disco compacto que puede ser registrado (CD-R) , un disco compacto que puede ser escrito de nuevo (CD-RW) , memoria instantánea, o tarjetas de disco suave de estado sólido (SSFDC) ) .

El Sistema 100 también puede incluir un dispositivo o tarjeta de comunicación 160 (por ejemplo, un modem y/o un adaptador de red) el cambiar datos con la red 170 usando un enlace de comunicación 175 (por ejemplo, una linea de teléfono, una conexión inalámbrica de red, una conexión de red de alambre, o una red de cable) . Otros ejemplos del sistema 100 pueden incluir un dispositivo sostenido en la mano, una estación de trabajo, un servidor, un dispositivo como un componente, otro equipo o alguna combinación de éstos capaz de responder y de ejecutar instrucciones en una manera definida. Cualquiera de los anteriores pueden ser complementados o incorporados en un ASICs (circuitos integrados de aplicación especifica) .

Refiriéndonos a la Figura 2, los datos en linea pueden ser almacenados en un sistema de base de datos de relación que organiza lógicamente los datos en una serie de tablas de base de datos. Una tabla de base de datos arregla los datos asociados con una entidad en una serie de columnas e hileras. Cada columna describe un atributo de la entidad para la cual los datos están siendo almacenados. Cada hilera representa una colección de valores de atributo para una entidad particular. Cuando una hilera puede ser identificada por un atributo, el atributo es frecuentemente mencionado como una clave .

Los datos en linea pueden ser almacenados en un sistema de base de datos de objeto que lógicamente organiza los datos en una serie de objetos. Cada objeto está asociado con una serie de atributos, y cada caso de un objeto está asociado con una serie de valores de atributo.

Los datos en linea pueden ser almacenados en uno o más expedientes de datos sin usar un sistema de base de datos de relación o un sistema de base de datos de objeto. Cada expediente de datos almacena una serie de registros. Un registro es una colección de artículos de datos relacionados, y cada registro puede consistir de varios campos de datos.

La Figura 2 muestra un expediente 200 para datos archivados que incluyen los datos archivados y la estructura usada para los datos. Un expediente de archivo puede almacenar datos archiyados, por ejemplo, de una o más tablas de base de datos de relación, las circunstancias de objeto, u otros tipos de expedientes de datos. El expediente de archivo 200 almacena datos de la tabla de base de datos de relación. Por brevedad, sólo una parte del expediente de archivo 200 está ilustrada.

El expediente de archivo 200 almacena una serie de etiquetas de atributo 210-219 y los valores de datos asociados 220-229 para los datos archivados. Cada etiqueta de atributo 210-219 identifica en forma única la columna de base de datos usada para almacenar un valor de datos asociado 220-229 en el sistema de base de datos de relación. Por ejemplo, la etiqueta 210 tiene una etiqueta de atributo T00476" que corresponde a una columna particular en la base de datos de relación en linea. El valor de datos 220 CA" es el valor que viene de la columna identificada por la etiqueta de atributo ?,?00476" .

Para restaurar el valor de datos 220 "CA" a la estructura de base de datos en linea, el valor de datos , ??" se insertará a la columna identificada por la etiqueta de atributo ,??00476" en la estructura de base de datos en linea, aún si la columna está localizada en una tabla de base de datos diferente a la tabla de base de datos en la cual la columna estaba localizada cuando los datos fueron archivados.

La identificación de una columna particular asociada con una etiqueta de atributo particular puede ser lograda mediante el emplear el nombre de columna en la tabla de base de datos como la etiqueta de atributo para la columna, usando el número de identificación (el cual puede ser referido como una "columna ID" ) de la columna como la etiqueta de atributo para la columna o mediante el identificar cada columna con una etiqueta de atributo única, almacenar la asociación entre la etiqueta de atributo y la columna y almacenar la asociación de columna-atributo-etiqueta en el expediente de archivo .

Los datos archivados pueden ser restaurados con base en un valor de clave particular o un rango de valores de clave. El expediente de archivo 200 almacena un atributo clave 230 ó 231 y un valor de clave asociado 235 ó 236 identifica una hilera asociada con los valores de atributo almacenados. Aquí, el valor clave 235 "2002-03-18,854" para el atributo clave 230 "17,14" está asociado con las etiquetas de atributo 210-214 con los valores de datos asociados 220-224. El valor de clave 236 "2002-03-18,878" para el atributo clave 231 "17, 14" está asociado con las etiquetas de atributo 215-219 con los valores de datos asociados 225-229.

El expediente de archivo 200 puede ser desarrollado usando XML ("Lenguaje de Marcado Extensible"). El lenguaje de marcado extendible es un lenguaje similar a un lenguaje de marcado de hipertexto (HTML) pero con la flexibilidad adicional de ser capaz de describir estructuras de datos que pueden ser procesados directamente como datos por un programa. El expediente de archivo 200 puede usar un formato de expediente de texto, tal como un expediente usando un código ASCII (Código Estándar Americano para Intercambio de Información) código o Unicode para representar cada carácter almacenado. Algunas implementaciones pueden almacenar datos archivados en un formato de expediente diferente, tal como un expediente binario o una tabla de base de datos.

Mediante el almacenar la estructura de los datos (aquí, una etiqueta de atributo único) dentro del expediente de archivo que almacena los datos, los datos archivados pueden ser restaurados a la misma o a una diferente estructura de datos en linea .

Algunas implementaciones pueden almacenar la estructura de los datos en un expediente de archivo y los datos en un expediente de archivo separado. Por ejemplo, la estructura de datos puede ser almacenada en un expediente de archivo desarrollado usando el lenguaje de marcado extensible y los datos almacenados en el segundo expediente de archivo, tal como un expediente de texto delimitado-coma.

La Figura 3 ilustra una tabla de base de datos 300 que almacena los datos archivados que se han restaurado desde el expediente de archivo 200. La tabla de base de datos 300 tiene las columnas 310-314 que son identificadas por las etiquetas de atributo 210-214 y 215-219 en el expediente de archivo 200. Por ejemplo, las etiquetas de atributo 210 y 215 identifican la columna 310, todas las cuales son identificadas por la etiqueta ,??00476", las etiquetas de atributo 211 y 216 identifican la columna 311, todas las cuales son identificadas por la etiqueta ,??01198" y otros. La tabla de base de datos 300 tiene la columna 315 que está identificada por el número de clave ,?17,14" y almacena un valor de clave para cada hilera.

Los valores de datos 220-224 y el valor de clave asociado 235 en el expediente de archivo 200 se han insertado como valores de datos 320-324 y el valor de clave 325 en la hilera 326 de la base de datos 300. En forma similar, los valores de datos 225-229 y el valor clave asociado 236 en el expediente de archivo 200 se han insertado como los valores de datos 330-334 y el valor de clave 335 en la hilera 336 de la tabla de base de datos 300.

Los datos archivados del expediente de archivo 200 pueden ser restaurados a la tabla de base de datos 300 debido a que la estructura de datos (aquí, una etiqueta de atributo único) es almacenada dentro del expediente de archivo. La Figura 4 ilustra dos tablas de base de datos 410 y 412 que almacenan los datos archivados que se han restaurado desde el expediente de archivo 200. La tabla de base de datos 410 tiene las columnas 415-417 que son identificadas por las etiquetas de atributos 210-212 y 215-217 en el expediente de archivo 200. La tabla de base de datos 410 tiene la columna 420 que es identificada por el número clave ,?17, 14" y almacena un valor de clave para cada hilera.

Los valores de datos 220-222 y el valor de clave asociado 235 en el expediente de archivo 200 se han insertado como valores de datos 425-427 y el valor de clave 428 en la hilera 430 de la tabla de base de datos 410. En forma similar, los valores de datos 225-227 y el valor clave asociado 236 en el expediente de archivo 200 se han insertado como valores de datos 435-437 y el valor clave 434 en la hilera 440 en la tabla de base de datos 410.

La tabla de base de datos 412 tiene las columnas 450-452 que son identificadas por las etiquetas de atributo 212-214 y 217-219 en el expediente de archivo 200. La tabla de base de datos 412 tiene la columna 455 que es identificada por el número de clave ,?17,14" y almacena un valor clave para cada hilera .

Los valores de datos 222-224 y el valor clave asociado 235 en el expediente de archivo 200 se han insertado como valores de datos 460-462 y el valor clave 463 en la hilera 465 de la tabla de base de datos 412. En forma similar, los valores de datos 227-229 y el valor clave asociado 236 en el expediente de archivo 200 se han insertado como los valores de datos 470-472 y el valor clave 473 en la hilera 475 en la tabla de base de datos 412.

Los valores de datos 222 y 227 aparecen en la tabla de base de datos 410 y la tabla de base de datos 412 debido a que cada tabla de base de datos tiene una columna 417 y 450 respectivamente, que es identificada por la etiqueta de atributo ,?00836" que está asociada con los valores de datos 222 y 227.

Mediante el almacenar la estructura de datos con los datos de archivo en el expediente de archivo, los datos de archivo pueden ser restaurados en una estructura de datos en linea diferente de la que existió en el momento cuando los datos fueron archivados.

Refiriéndonos a las Figuras 5 y 6, para propósitos ilustrativos, está descrita una implementación particular de un sistema de restauración de archivo de datos. En la implementación descrita, un sistema de manejo de base de datos de relación, tal como un Oracle 8 base de datos o una base de datos Oracle 9i disponible de Oracle Corporation o de un software de administración de datos Informix de IBM® se usa para el almacenamiento de datos en linea. La base de datos de relación almacena datos en las tablas de base de datos con cada registro almacenado como una hilera, y cada atributo almacenado como una columna en la tabla de base de datos . Cada columna es identificada en forma única en el sistema de base de datos con una etiqueta de atributo. Un juego de datos es un grupo de tablas de base de datos relacionadas, y varios juegos de datos están incluidos en la base de datos. Por ejemplo, un juego de datos de cliente puede ser un grupo de cinco tablas de base de datos que almacenan información de cliente en una base de datos que contiene 500 tablas de base de datos. Cada tabla de base de datos en el juego de datos de cliente puede contener un identificador de cliente, una clave que identifique en forma única la información para un cliente en particular en las tablas de base de datos incluidas en el juego de datos del cliente.

Refiriéndonos a la Figura 5, un proceso 500 controla un procesador para archivar datos y la estructura usada para los datos archivos. El proceso 500 es iniciado cuando se hace una determinación de que un juego de datos particular va a ser archivado (paso 510) . Esta determinación puede hacerse con base en el paso de un periodo de tiempo predeterminado ya que el último tiempo en que el juego de datos o la base de datos fueran archivados o sobre un programa determinado para uno o más juegos de datos incluidos en la base de datos o en la base de datos completa.

El procesador accesa la información de estructura de datos alrededor de el juego de datos que está siendo archivado (paso 520) . La información de estructura de datos puede ser accesada desde un diccionario de datos, directamente desde la estructura de base de datos o desde una configuración de expediente que describe la estructura de datos de la base de datos .

El procesador entonces accesa las reglas de archivo de datos para las tablas de base de datos incluidas en un juego de datos particular que está siendo archivado (paso 530) . Las reglas de archivo de datos describen la decisión lógica que controla cuando una hilera puede ser removida de una tabla de base de datos en linea particular. Puede haber una regla de archivo de datos diferente para cada tabla de base de datos. Una hilera puede ser removida de una tabla de base de datos en línea a un expediente de archivo con base en la duración de tiempo desde que los datos sobre la cual la hilera fue creada. Por ejemplo, una hilera en una tabla de base de datos particular puede ser removida de esa tabla de base de datos en línea particular al expediente de archivo cuando por lo menos han pasado 120 días desde que la hilera fue creada. Una hilera en una tabla de base de datos diferente puede ser removida de esa tabla de base de datos en línea particular cuando por lo menos han pasado 180 días desde que la hilera fue creada.

Algunas implementaciones pueden remover una hilera basada sobre los datos sobre los cuales la hilera fue por último modificada o una combinación de los datos de creación (o la fecha de la última modificación) de la hilera y otro factor, tal como el tamaño de la tabla de base de datos, un juego de datos, o una base de datos, o la tasa de crecimiento de una tabla de base datos, un juego de datos o una base de datos.

Algunas implementaciones pueden no remover una hilera de algunas tablas de base de datos. Por ejemplo, las hileras en una tabla de referencia que asocian nombres de estado y abreviaciones postales pueden no ser removidas de un almacén en linea. Puede haber una regla explícita que indique que no van a ser removidas las hileras por el proceso de archivo de una tabla de base de datos particular, otra regla puede ser implicada por la ausencia de una regla de archivo para una tabla particular.

Algunas implementaciones pueden incluir una regla de archivo por falla que va a ser usada para todas las tablas de base de datos a menos que sea definida una regla de archivo específica para la tabla de base de datos. Por ejemplo, la regla de archivo por falla puede ser que una hilera en cada tabla de base de datos en un juego de datos particular pueda ser archivada no tan pronto de 120 días después de que la hilera fue creada. Una regla de archivo para una tabla de base de datos particular es que el juego de datos puede ser definido como remover una hilera de la tabla de base de datos particular cuando por lo menos han pasado 45 días desde que la hilera fue creada. Una hilera en la tabla de base de datos particular será archivada 45 dias después de la fecha en que la hilera fue creada más bien que después de que la reqla de falla y el juego de datos de 120 dias.

El procesador entonces archiva hileras en la base de datos por el procesamiento de una tabla de base de datos una después de otra hasta que todas las tablas en la base de datos y en el juego de datos se han procesado (pasos 540-580) . El procesador copia al expediente de archivo las hileras que satisfacen el criterio de archivado para la tabla de base de datos particular que está siendo procesada (paso 540) . Para cada hilera copiada, el procesador incluye la etiqueta de atributo para la clave de hilera, un valor de clave de hilera, y una serie de etiquetas de atributo y valores de datos para cada columna en la tabla de base de datos, como se describió anteriormente con respecto a la Figura 2.

Cuando el procesador ha completado la escritura de cualquier hileras para el expediente de archivo desde todas las tablas de base de datos en el juego de datos de acuerdo a las reglas de archivado, el procesador actualiza la información de archivo para el juego de datos (paso 550) . La información de archivo puede ayudar a identificar los datos que están almacenados en un expediente de archivo particular. La información de archivo para cada juego de datos incluye un Indice de archivo, una identificación de índice de archivo, y una tabla de base de datos de archivo en línea.

El expediente de índice de archivo y el expediente de identificación de índice de archivo describen los datos almacenados en el expediente de archivo para el juego de datos. Un expediente de índice de archivo y un expediente de identificación de índice de archivo están asociados con cada expediente de archivo. El expediente de índice de archivo describe el tipo de datos (tal como datos de cliente, datos de factura, o datos de aseguramiento de calidad) incluidos en el expediente de archivo. El expediente de identificación de índice de archivo incluye una lista de los valores clave asociados con cada hilera almacenada en el expediente de archivo.

La tabla de base de datos de archivo en línea identifica el expediente de archivo, el expediente de índice de archivo, el expediente de identificación de archivo creado y los valores de clave de las hileras archivadas durante el proceso de archivado 500.

Otras implementaciones pueden almacenar diferente información de archivo o pueden organizar la información de archivo en una manera diferente. Por ejemplo, algunas implementaciones pueden almacenar información acerca de más de un expediente de archivo en un expediente de índice de archivo o pueden incluir el tipo de datos y valores clave en un expediente de índice de archivo único. Algunas implementaciones pueden usar sólo una tabla de base de datos o sólo usar un expediente de texto para almacenar la información de archivo.

El procesador entonces suprime las hileras de la tabla de base de datos en línea que están siendo procesadas que se han copiado al expediente de archivo (paso 560) .

Algunas implementaciones pueden procesar una hilera restaurada en la misma manera como una hilera no restaurada en una tabla de base de datos. A menos que el criterio de archivado usado para la tabla de base de datos que incluyó la hilera restaurada haya cambiado desde el momento en que la hilera restaurada fue originalmente archivada, la hilera restaurada es re-archivada cuando el proceso de archivo para el juego de datos es enseguida llevado a cabo, y la hilera restaurada es duplicada en más de un expediente de archivo.

El procesador en algunas implementaciones puede suprimir hileras que se han restaurado de un expediente de archivo a una tabla de base de datos en línea más bien que el volver a archivar las hileras restauradas (paso 565) . La decisión lógica para suprimir una hilera restaurada puede ser basada sobre un periodo de tiempo desde el cual la hilera fue restaurada (por ejemplo, suprimir todas las hileras restauradas por no menos de 30 días después de la fecha sobre la cual la hilera fue restaurada) y puede aplicar a una tabla de base de datos particular en el juego de datos, todas las tablas de base de datos en el juego de datos, todas las tablas de base de datos o una regla de falla para un juego de datos que puede ser modificado por una regla particular para la tabla de base de datos .

Algunas implementaciones pueden mover algunas hileras para separar el almacenamiento en lugar de archivar la hilera. Por ejemplo, los valores de datos incorrectos en una tabla de base de datos pueden ser corregidos mediante el insertar una hilera que tiene los valores de datos exactos e identificar la hilera previa como "corregida" . La hilera "corregida" ya no es valida y puede ser movida de la tabla de base de datos en linea a un almacén separado (tal como una tabla de base de datos separada que tiene una latencia de acceso superior que la tabla de base de datos en linea correspondiente) , almacenada por un periodo de tiempo, y suprimido subsecuentemente de un almacén separado- El almacenamiento de la hilera "corregida" en un almacén separado por un periodo de tiempo en vez de archivar la corrección puede proporcionar un camino de auditar para la corrección, reduce la cantidad de datos almacenados en linea y reduce la cantidad de datos que son archivados.

El procesador copia hileras en la tabla de base de datos en linea que está siendo procesada que satisface un criterio para ser movidos a un almacén separado y suprime aquéllas hileras de la tabla de base de datos en línea (paso 570) . Por ejemplo, la decisión lógica puede ser la de que cualquier hilera que no se ha accesado o cualquier hilera que fue accesada sobre 30 días antes de la fecha en la cual se lleva a cabo el proceso de archivo se mueve a un almacén separado. La decisión lógica puede aplicarse a todas las tablas de base de datos en el juego de datos, puede aplicarse a una tabla de base de datos particular en el juego de datos, o puede ser una regla de omisión para un juego de datos que es modificado por una regla particular para la tabla de base de datos. El procesador entonces suprime las hileras de almacén separado que satisfacen la decisión lógica para hacer esto (paso 575) . Por ejemplo, la decisión lógica puede ser que una hilera sea suprimida de un almacén separado después de que un número predeterminado de días ha transcurrido desde que la hilera fue movida a un almacén separado o después de que el proceso de archivo sea llevado a cabo por el juego de datos por un número predeterminado de veces desde que la hilera fue movida a un almacén separado. La decisión lógica puede aplicarse a una tabla de base de datos particular en el juego de datos, a todas las tablas de base de datos en el juego de datos, puede ser una regla de omisión para un juego de datos que es modificada para una regla particular para la tabla de base de datos o puede aplicar a todas las tablas de base de datos.

El procesador determina si cualquiera de las tablas de base de datos en linea adicionales en el juego de datos necesita ser procesada (paso 580) . Si esto es asi, el procesador copia las hileras al expediente de archivo que satisfacen el criterio de archivo para la tabla de base de datos en linea (paso 540) y procede como se describió previamente.

Cuando se procesa cada tabla de base de datos en el juego de datos esté completo (paso 580), el procesador puede suprimir la información de archivo no necesaria (paso 590) . Por ejemplo, el procesador puede suprimir el expediente de archivo, el expediente de Índice de archivo, y el expediente de identificación de índice de archivo después de que ha pasado un periodo de tiempo predeterminado desde que los expedientes fueron creados o ha pasado un periodo de tiempo predeterminado desde que los expedientes fueron usados.

Refiriéndonos a la Figura 6, un proceso 600 controla un procesador para restaurar datos de un expediente de archivo a una base de datos en línea usando la estructura de los datos archivados almacenados en el expediente de archivo. El proceso 600 es iniciado cuando una petición para restaurar datos desde un expediente de archivo es recibido (paso 610) . La petición identifica un valor clave particular en un expediente de archivo particular para el cual los datos de archivo para el valor clave almacenado en el expediente de archivo va a ser restaurado a la base de datos en línea. El proceso 600 restaura todos los valores de datos asociados con el valor clave identificado en el expediente de archivo. Como se describió previamente con respecto a la Figura 5, el expediente de archivo almacena datos para una serie de tablas de base de datos en un juego de datos. El proceso 600 restaura los valores de datos de las tablas de base de datos archivadas para un valor clave particular .

Algunas implementaciones' pueden restaurar datos para un valor clave particular de una tabla de base de datos particular que fue archivada o puede restaurar todos los datos de archivo en un expediente de archivo particular.

La información contenida en la base de datos de archivo en linea, el expediente de índice de archivo, o el expediente de identificación de índice de archivo puede ser usada para formular una petición para restaurar los datos archivados.

El proceso de restauración 600 requiere que el expediente de archivo particular esté disponible (paso 620) . El procesador puede controlar un dispositivo de archivo, tal como una cinta o una rocola CD, para hacer los medios sobre los cuales el expediente de archivo es almacenado disponible o un operador de sistema puede hacer que esté disponible el expediente de archivo, por ejemplo, mediante el colocar una cinta o CD apropiada en un dispositivo de entrada-salida apropiado de manera que el procesador puede accesar el expediente de archivo.

El procesador lee el expediente de archivo identificado por la petición de restauración para localizar el valor de clave identificado dentro del expediente de archivo (paso 630) . El procesador compara las etiquetas de atributo almacenadas en el expediente de archivo con las etiquetas de atributo asociadas con columnas en la base de datos en linea actual para determinar en donde cada inserto archivo valor de datos. Cuando una etiqueta de atributo en el expediente de archivo es la misma que una etiqueta de atributo en la base de datos en linea, el procesador inserta el valor de datos de archivo asociado con la etiqueta de atributo para el valor clave a ser restaurado en la columna de base de datos en linea que corresponde a la etiqueta de atributo que hace juego sin importar la tabla de datos en la cual está localizada la columna. Algunas implementaciones pueden crear el mapa de datos usando Rational ROSE, una herramienta de modelado de objeto disponible de Rational Corporation, o XML Spy, una herramienta de desarrollo XML disponible de Altova Corporation. El procesador entonces crea un registro que va a ser restaurado a la estructura de base de datos en linea actual (paso 440). El procesador puede crear un mapa de datos que asocia cada etiqueta de atributo en el expediente de archivo con una etiqueta de atributo correspondiente y la tabla de base de datos en la cual la columna asociada con la etiqueta de atributos está localizada en la base de datos en linea.

El procesador crea hileras que van a ser insertadas de acuerdo a la estructura de base de datos en linea actual. El procesador lleva a cabo cualquier conversión de datos necesaria para igualar la estructura de base de datos en linea actual. Por ejemplo, el procesador puede convertir un valor entero del expediente de archivo a un valor de número real correspondiente que es insertado en la tabla de base de datos en linea actual que almacena el atributo asociado con la etiqueta de atributo que iguala el número de etiqueta de atributo almacenado. El procesador puede aumentar el tamaño de un valor de atributo que va a ser restaurado mediante el agregar caracteres neutrales, tal como espacios o ceros delanteros, para igualar el tamaño de la columna si la columna requiere datos de longitud fija.

El procesador entonces continúa para insertar las hileras creadas en la estructura de datos en linea (paso 650) . El procesador continúa para insertar las hileras creadas en cada tabla de base de datos en linea hasta que se han insertado todas las hileras.

Los beneficios de almacenar la información de estructura de datos con los datos removidos de una base de datos usando las técnicas descritas no están limitadas a almacenar fuera de linea datos. Por ejemplo, los datos archivados pueden ser almacenados en un almacén secundario que está disponible en linea .

Las implementaciones pueden incluir un método o un proceso, un aparato o sistema, o programa de computadora sobre un medio de computadora. Se entenderá que pueden hacerse varias modificaciones sin departir del espíritu y alcance de las reivindicaciones siguientes. Por ejemplo, los resultados ventajosos aún pueden ser archivados si los pasos de las técnicas discutidas fueran realizados en un orden diferente y/o si los componentes en los sistemas descritos fueran combinados en una manera diferente y/o remplazados o complementados por otros componentes. Otras implementaciones están dentro del alcance de las siguientes cláusulas.

Claims (21)

REIVINDICACIONES

1. ün método implementado por computadora para restaurar datos, el método comprende: mover físicamente datos desde una primera colección de datos a una segunda colección de datos, asociar la información de estructura de datos con los datos movidos, y restaurar los datos movidos a una tercera colección de datos desde la segunda colección de datos, los datos movidos siendo restaurados con base en una comparación de la información de estructura de datos de la tercera colección de datos con la información de estructura de datos asociada con los datos movidos.

2. El método tal y como se reivindica en la cláusula 1 caracterizado porque comprende: la información de estructura de datos asociada con los datos movidos comprende una etiqueta de atributo, la información de estructura de datos de la tercera colección de datos comprende una etiqueta de atributo de colección, y los datos movidos comprenden una serie de valores de atributo movidos cada uno de los cuales está asociado con una etiqueta de atributo.

3. El método tal y como se reivindica en la cláusula 2 caracterizado además porque, comprende crear un mapa de datos que asocia una etiqueta de atributo con una etiqueta de atributo de colección.

4. El método tal y como se reivindica en la cláusula 1 caracterizado además porque comprende: asociar una primera estructura de datos con la primera colección de datos; y asociar una segunda estructura de datos con la tercera colección de datos, en donde la primera estructura de datos no es la misma que la segunda estructura de datos.

5. El método tal y como se reivindica en la cláusula 4 caracterizado porque: la primera estructura de datos comprende un primer grupo de atributos asociado con un primer atributo y un segundo atributo; la segunda estructura de datos comprende un segundo grupo de atributos asociado con un tercer atributo y un tercer grupo de atributos asociado con un cuarto atributo, mover físicamente los datos de una primera colección de datos a una segunda colección de datos comprende el mover físicamente un primer valor de atributo asociado con el primer atributo y un segundo valor de atributo asociado con el segundo atributo, y restaurar los datos movidos a una tercera colección de datos desde la segunda colección de datos comprende el asociar el primer valor de atributo con el tercer atributo y asociar el segundo valor de atributo con el cuarto atributo.

6. El método tal y como se reivindica en la cláusula 1 caracterizado porque, la primera colección de datos y la tercera colección de datos son sistemas de base de datos de relación.

7. El método tal y como se reivindica en la cláusula 1 caracterizado porque, en la primera colección de datos y la tercera colección de datos son sistemas de base de datos orientas por objeto.

8. Una señal propagada o medio que puede ser leído por computadora que tiene incluido en el mismo un programa de computadora configurado para restaurar datos, el medio comprende un segmento de código configurado para: físicamente mover datos de una primera colección de datos a una segunda colección de datos, asociar la información de estructura de datos con los datos movidos, y restaurar los datos movidos a una tercera colección de datos desde la segunda colección de datos, los datos movidos siendo restaurados con base en una comparación de la información de estructura de datos de la tercera colección de datos con la información de estructura de datos asociada con los datos movidos.

9. El medio tal y como se reivindica en la cláusula 8 caracterizado porque: la información de estructura de datos asociada con los datos movidos comprende una etiqueta de atributo, la información de estructura de datos de la tercera colección de datos comprende una etiqueta de atributo de colección, y los datos movidos comprenden una serie de valores de atributo movidos cada uno de lo cuales está asociado con una etiqueta de atributo.

10. El medio tal y como se reivindica en la cláusula 9 caracterizado además porque, comprende un segmento de código configurado para crear un mapa de datos que asocia una etiqueta de atributo con una etiqueta de atributo de colección.

11. El medio tal y como se reivindica en la cláusula 8 caracterizado además porque, comprende un segmento de código configurado para: asociar una primera estructura de datos con la primera colección de datos, y asociar una segunda estructura de datos con la tercera colección de datos, en donde la primera estructura de datos no es la misma que la segunda estructura de datos.

12. El medio tal y como se reivindica en la cláusula 11 caracterizado porque: la primera estructura de datos comprende un primer grupo de atributos asociados con un primer atributo y un segundo atributo, la segunda estructura de datos comprende un segundo grupo de atributos asociados con un tercer atributo y un tercer grupo de atributos asociado con un cuarto atributo, mover físicamente los datos desde' una primera colección de datos a una segunda colección de datos comprende el mover físicamente un primer valor de atributo asociado con el primer atributo y un segundo valor de atributo asociado con el segundo atributo, y la restauración de los datos movidos a una tercera colección de datos desde la segunda colección de datos comprende asociar el primer valor de atributo con el tercer atributo y asociar el segundo valor de atributo con el cuarto atributo.

13. El medio tal y como se reivindica en la cláusula 8 caracterizado porque, la primera colección de datos y la tercera colección de datos son sistemas de base de datos de relación.

14. El medio tal y como se reivindica en la cláusula 8 caracterizado porque, la primera colección de datos y la tercera colección de datos son sistemas de base de datos orientados por objeto.

15. Un sistema para restaurar datos, el sistema comprende un procesador conectado a un dispositivo de almacenamiento y uno o más dispositivos de entrada/salida en donde el procesador está configurado para: físicamente mover datos de una primera colección de datos a una segunda colección de datos, asociar la información de estructura de datos con los datos movidos, y restaurar los datos movidos a una tercera colección de datos desde la segunda colección de datos, los datos movidos siendo restaurados con base en una comparación de la información de estructura de datos de la tercera colección de datos con la información de estructura de datos asociada con los datos movidos.

16. El sistema tal y como se reivindica en la cláusula 15 caracterizado porque: la información de estructura de datos asociada con los datos movidos comprende una etiqueta de atributo, la información de estructura de datos de la tercera colección de datos comprende una etiqueta de atributo de colección, y los datos movidos comprenden una serie de valores de atributo movidos cada uno de los cuales está asociado con una etiqueta de atributo.

17. El sistema tal y como se reivindica en la cláusula 16 caracterizado porque, el procesador está además configurado para crear un mapa de datos que asocia una etiqueta de atributo con una etiqueta de atributo de colección.

18. El sistema tal y como se reivindica en la cláusula 15 caracterizado porque, el procesador está además configurado para: asociar una primera estructura de datos con la primera colección de datos, y asociar una segunda estructura de datos con la tercera colección de datos, en donde la primera estructura de datos no es la misma que la segunda estructura de datos.

19. El sistema tal y como se reivindica en la cláusula 18 caracterizado porque: la primera estructura de datos comprende un primer grupo de atributos asociado con el primer atributo y el segundo atributo, la segunda estructura de datos comprende un segundo grupo de atributos asociado con un tercer atributo y un tercer grupo de atributos asociado con un cuarto atributo, mover físicamente los datos de una primera colección de datos a una segunda colección de datos comprende el mover físicamente un primer valor de atributo asociado con el primer atributo y un segundo valor de atributo asociado con el segundo atributo, y restaurar los datos movidos a una tercera colección de datos desde la segunda colección de datos comprende el asociar el primer valor de atributo con el tercer atributo y asociar el segundo valor de atributo con el cuarto atributo.

20. El sistema tal y como se reivindica en la cláusula 15 caracterizado porque, la primera colección de datos y la tercera colección de datos son sistemas de base de datos de relación .

21. El sistema tal y como se reivindica en la cláusula 15 caracterizado porque, la primera colección de datos y la tercera colección de datos son sistemas de base de datos orientados por objeto.