MXPA04004203A

MXPA04004203A - Metodo y sistema para validar una base de datos remota.

Info

Publication number: MXPA04004203A
Application number: MXPA04004203A
Authority: MX
Inventors: Thomas Mcmillen Bradley
Original assignee: Verisign Inc
Priority date: 2001-11-01
Filing date: 2002-11-01
Publication date: 2005-05-16
Also published as: US20070100808A1; ZA200404266B; NZ532773A; AU2002356886A1; EA200400618A1; US20030084039A1; CN1610906A; EP2503476A1; EA200400614A1; WO2003038596A1; WO2003038653A1; BR0213807A; EP1449049A4; MXPA04004201A; CA2466117C; CN100557595C; MXPA04004202A; EP2477126A3; US20090106211A1; BR0213862A

Abstract

Las modalidades de la presente invencion proporcionan un metodo y sistema para validar actualizaciones de base de datos remota a traves de una red. Un registro de base de datos local (200) y un registro de base de datos remota pueden ser comparados y se pueden generar excepciones. Cada excepcion puede describir una discrepancia entre los registros de bases de datos remota y local (200). Un identificador de excepcion puede ser asociado con cada excepcion, en donde el identificador de excepcion puede ser asociado con un identificador del registro. Un identificador de evento puede ser asociado con cada evento en la actualizacion, cuando en identificador de evento puede estar asociado con un identificador del registro. Los eventos y las excepciones corresponden al registro pueden ser comparados para determinar si la actualizacion es valida.

Description

METODO Y SISTEMA PARA VALIDAR UNA BASE DE DATOS REMOTA RECLAMACION DE PRIORIDAD/REFERENCIA CRUZADA A SOLICITUDES RELACIONADAS Esta solicitud no provisional reclama el beneficio de la Patente Provisional de E.U.A. No. 60/330,842, presentada el 1o. de noviembre del 2001, la cual se incorpora por referencia en su totalidad, y la Solicitud de Patente Provisional de E.U.A. No. 60/365,169, presentada el 19 de marzo del 2002, la cual se incorpora por referencia en su totalidad.

CAMPO TECNICO Las modalidades de la presente invención se refieren en general a bases de datos de computadoras. Más específicamente, las modalidades proporcionan un método y sistema para validar de manera confiable actualizaciones de bases de datos remotas.

ANTECEDENTES DE LA INVENCION Con el tamaño incrementante y altamente distribuidas estructuras de las bases de datos, se ha convertido más difícil de manera increméntate asegurar que las bases de datos relacionadas en una red contienen las mismas versiones de datos. Si existen cambios significativos en una base de datos, otras bases de datos pueden necesitar ser actualizadas para incluir estos cambios tan pronto como sea posible. Hacer estos cambios puede involucrar mover frecuentemente gran cantidad de datos actualizados a múltiples bases de datos. La complejidad potencial de dicho proceso puede ser tremenda. Este problema además se combina en sistemas en donde las comunicaciones no son confiables. En este caso, los datos pueden perderse durante el transporte. Es decir, los datos deben ser retransmitidos y las otras bases de datos actualizadas otra vez. Dicha repetición significativamente reduce la eficiencia del sistema el extensión a la cual las bases de datos contienen datos actualizados a la fecha decir.

BREVE DESCRIPCION DE LOS DIBUJOS La Figura 1 es un diagrama de bloque, de acuerdo con una modalidad de la presente invención. La Figura 2 es un diagrama de bloque de un concentrador de puertos del sistema de acuerdo con una modalidad de la presente invención. La Figura 3 describe una transmisión ilustrativa de actualizaciones de base de datos a partir de una base de datos local a una base datos remota de acuerdo con una modalidad de la presente invención. La Figura 4 muestra un archivo de envío de acuerdo con la modalidad de la presente invención. La Figura 5 muestra un archivo de envío de inicialización de acuerdo con una modalidad de la presente invención. La Figura 6 es una gráfica de cronometraje ilustrativa de la generación del archivo de envío y de la inicialización del archivo de envío de acuerdo con una modalidad de la presente invención. La Figura 7 es una gráfica de flujo de una modalidad de la presente invención en la cual los archivos actualizados de una base de datos local pueden ser generados. La Figura 8 es una gráfica de flujo de una modalidad de la presente invención en la cual la base de datos remota puede recibir archivos actualizados de una base de datos local. La Figura 9 es una gráfica de flujo de otra modalidad de la presente invención en la cual una base de datos remota puede recibir y validar archivos actualizados de una base de datos local. La Figura 10A es una gráfica de flujo de una modalidad de la presente invención en la cual los archivos actualizados pueden ser validados. La Figura 10B es una gráfica de flujo de otra modalidad de la presente invención en la cual los archivos actualizados pueden ser validados. La Figura 11 es una ilustración de la validación de un archivo actualizado de acuerdo con una modalidad de la presente invención.

DESCRIPCION DETALLADA Las modalidades de la presente invención proporcionan un método y sistema para validar actualizaciones de bases de datos remotas. Un registro de una base de datos local y un registro de una base de datos remota pueden ser comparados y las excepciones generadas. Cada excepción puede describir una discrepancia entre los registros de la base de datos local y la remota. Un identificador de excepción puede estar asociado con cada excepción, en donde el identificador de excepción puede estar asociado con un identificador del registro. Un identificador de evento puede estar asociado con cada evento en la actualización, en donde el identificador del evento puede estar asociado con un identificador del registro. Los eventos y las excepciones que corresponde al registro pueden ser comparados para determinar si esta actualización es válida. La Figura 1 es un diagrama de bloque que ilustra un sistema de acuerdo con una modalidad de la presente invención. Generalmente el sistema 100 puede hospedar una base de datos residente en memoria, grande, recibir solicitudes de búsqueda y proporcionar respuestas de búsqueda a través de una red. Por ejemplo, el sistema 100 puede ser una computadora de multiprocesamiento, simétrica (SMP), tal como, por ejemplo, una IBM RS/6000® o S80 fabricada por International Business Machines Corporation of Armonk, Nueva York, una Sun Enterprise™ 1000 fabricada por Sun Microsystems, Inc. de Santa Clara, California, etc. El sistema 100 también puede ser una computadora personal multiprocesador, tal como por ejemplo, una Compaq ProLiant™ (incluyendo dos procesadores Intel Pentium® III 866 MHz) fabricada por Hewlett-Packard Company de Palo Alto, California. El sistema ciento 100 puede incluir un sistema operativo de multiprocesamiento, tal como, por ejemplo, el Ambiente Operativo IBM AIX® 4, Sun Solaris™, Red Hat Linux® 6.2, etc. El sistema 100 puede recibir actualizaciones periódicas a través de la red 124, las cuales pueden ser concurrentemente incorporadas en la base de datos. Las modalidades de la presente invención pueden lograr el rendimiento total de búsquedas y actualizaciones de bases de datos muy altas a través de la incorporación de cada actualización a la base de datos sin el uso de controles de bloqueo o acceso a la base de datos. En una modalidad, el sistema 100 puede incluir por lo menos un procesador 102-1 acoplado al conductor común 101. El procesador 102-1 puede incluir un caché de memoria interna (por ejemplo, un caché L1, no mostrado para clarificar). Un caché de memoria secundaria 103-1 (por ejemplo un caché L2, cachés L2/L3, etc.) pueden residir entre procesador 102-1 y el conductor común 101. En una modalidad preferida, el sistema 100 puede incluir una pluralidad de procesadores 102-1...102-P acoplados al conductor común 101. Una pluralidad de cachés de memoria secundaria 103- 1...103-P también reside entre la pluralidad de procesadores 102- 1...102-P y el conductor común 101 (por ejemplo, una arquitectura de echar una ojeada), o, alternativamente, por lo menos un caché de memoria secundaria 103-1 puede estar acoplada al conductor común 101 (por ejemplo, una arquitectura de ver además). El sistema 100 puede incluir la memoria 104, tal como, por ejemplo, la memoria de acceso aleatorio (RAM), etc., está acoplada al conductor común 101, para almacenar información e instrucciones que se van ejecutar a través de la pluralidad de procesadores 102-1....102-P. La memoria 104 puede almacenar grandes bases de datos, por ejemplo, para traducir nombres de dominio en direcciones de Internet, para traducir nombres y números telefónicos en direcciones de red, para proporcionar y actualizar los datos del perfil de suscriptor, para proporcionar y actualizar los datos de la presencia del usuario, etcétera. Ventajosamente, ambos, el tamaño de la base de datos y el número de traducciones por segundo pueden ser muy grandes. Por ejemplo, la memoria 104 puede incluir por lo menos 64 GB de RAM y puede hospedar 500M (es decir, 500x106) de registros de bases de datos de nombre de dominio, un registro de 500M de la base de datos del suscriptor, un registro de 450M de la base de datos de probabilidades de números telefónicos, etc. En una arquitectura del sistema de 64 bits ilustrativo, tal como por ejemplo, un sistema que incluye por lo menos un procesador big-endian (bit más significativo primero) 102-1 acoplado a por lo menos al conductor común 101 de 64 bits y una memoria de 64 bits 104, un valor de apuntador de 8 bytes puede ser escrito en una dirección de memoria en un límite de 8 bytes (es decir, una dirección de memoria visible a través de ocho, o por ejemplo 8N) utilizando una operación ininterrumpible, individual. Generalmente, la presencia del caché de la memoria secundaria 103-1 puede simplemente retrasar la escritura del apuntador de 8 bytes a la memoria 104. Por ejemplo, en una modalidad, el caché de memoria secundaria 103-1 puede ser un caché de mirar-a través de de operando en modo de escribir-a través de, por lo que una instrucción de almacenamiento de 8 bytes puede mover ocho bytes de los datos desde el procesador 102-1 a la memoria 104, sin interrupción, y tan poco como dos ciclos del reloj del sistema. En otra modalidad, el caché de memoria secundaria 103-1 puede ser un caché de mirar-a través de operando en un modo de escribir-otra vez, por lo que el apuntador de 8 bytes puede primero ser escrito en el caché de la memoria secundaria 103-1, la cual puede entonces escribir el apuntador de 8 bytes en la memoria 104 después, tal como, por ejemplo, cuando la línea del caché en la cual el apuntador de 8 bytes está almacenado es escrito a la memoria 104 (es decir, por ejemplo, cuando la línea de caché particular, o el caché de la memoria secundaria total, es "descargado"). Finalmente, a partir de la perspectiva del procesador 102-1, una vez que los datos son asegurados en los pins de salida del procesador 102-1, todos los ocho bytes de datos son escritos en la memoria 104 en una transferencia ininterrumpida, contigua, la cual puede ser retrasada por los efectos del caché de la memoria secundaria 103-1 si está presente. A partir de la perspectiva de los procesadores 102-2...102-P, una vez que los datos son asegurados en los pins de salida del procesador 102-1, todos los ocho bytes de los datos son escritos en la memoria 104 en una transferencia ininterrumpida, contigua, lo cual se refuerza a través del protocolo de coherencia del caché a lo largo de los cachés de memoria secundaria 103-1....103-P, lo cual puede retrasar la escritura en la memoria 104 si está presente. Sin embargo, si un valor de apuntador de 8 bytes es escrito en una ubicación desalineada en la memoria 104, tal como la dirección de memoria que cruza el límite de 8 bytes, todos los ocho bytes de los datos no pueden ser transferidos del procesador 102-1 utilizando una instrucción de almacenamiento de 8 bytes, individual. En su lugar, el procesador 102-1 puede emitir dos instrucciones de almacenamiento separadas. Por ejemplo, sí la dirección de la memoria empieza cuatro bytes antes del límite de 8 bytes (por ejemplo, 8N - 4), la primera instrucción de almacenamiento transfiere los cuatro bytes más significativos a la memoria (por ejemplo, 8N - 4), mientras que la segunda instrucción de almacenamiento transfiere los cuatro bytes de memoria menos significativos a la memoria 104 (por ejemplo, 8N). Es muy importante entre estas dos instrucciones separadas, que el procesador 102-1 pueda ser interrumpido, o el procesador 102-1 pueda perder el control del conductor común 101 a otro componente del sistema (por ejemplo, procesador 102-P, etc.). Consecuentemente, el valor de apuntador que reside en la memoria 104 será inválido hasta que el procesador 102-1 pueda completar la segunda instrucción de almacenamiento. Si otro componente inicia una lectura de memoria ininterrumpible, individual en su ubicación de memoria, un valor inválido será devuelto como uno presumiblemente válido. Similarmente, un nuevo valor de apuntador de 4 bytes puede ser escrito a una dirección de memoria disponible por cuatro (por ejemplo, 4N), utilizando una operación ininterrumpible, individual. Notar que en el ejemplo discutido anteriormente, un valor de apuntador de 4 bytes puede ser escrito a una ubicación de memoria de 8N - 4 utilizando una instrucción de almacenamiento individual. Por supuesto, si un valor de apuntador de 4 bytes que cruza un límite de 4 bytes, por ejemplo 4N - 2, los cuatro bytes de datos no pueden ser transferidos desde el procesador 102-1 utilizando una instrucción de almacenamiento individual, y el valor del apuntador residente en la memoria 104 puede ser inválido durante algún periodo de tiempo. El sistema 100 también puede incluir una memoria de solo lectura (ROM) 106, u otro dispositivo de almacenamiento estático, acoplado al conductor común 101 para almacenar información estática e instrucciones para el procesador 102-1. Un dispositivo de almacenamiento 108, tal como un disco magnético u óptico, puede estar acoplado al conductor común 10 para almacenar información e instrucciones. El sistema 100 también puede incluir el despliegue 110 (por ejemplo, un monitor LCD) y el dispositivo de entrada 112 (por ejemplo, teclado, ratón, seguibola, etc.) acoplado a conductor común 101. El sistema 100 también puede incluir una pluralidad de interfases de red 114-1 ,...114-0, la cual puede enviar y recibir señales eléctricas, electromagnéticas u ópticas que pueden llevar corrientes de datos representando varios tipos de información. En una modalidad, la interfase de red 114-1 puede estar acoplado al conductor común 101 y una red de área local (LAN) 122, mientras la interfase de red 114-0 puede estar acoplado al conductor común 101 y red de área amplia (WAN) 124. La pluralidad de interfases de red 114-1 , ....114-0 puede soportar varios protocolos de red, incluyendo, por ejemplo. Gigabit Ethernet (por ejemplo, IEEE Estándar 802.3-2002, publicado en 2002). El Canal de Fibra (por ejemplo, ANSI Estándar X.3230-1994, publicado en 1994), etc. La pluralidad de las computadoras de red 120-1 , ....120-N puede estar acopladas a la LAN 122 y WAN 124. En una modalidad, LAN 122 y WAN 124 pueden ser físicamente distintas redes, mientras en otra modalidad, LAN 122 y WAN 124 pueden ser a través de una compuerta de red o direccionador (no mostrado para claridad). Alternativamente, LAN 122 y WAN 124 pueden ser la misma red. Como se observó anteriormente, el sistema 100 proporciona servicios de resolución DNS. En una modalidad de resolución DNS, lo servicios de resolución DNS pueden generalmente ser divididos entre las funciones de transporte de datos y de búsqueda de datos. Por ejemplo, el sistema 100 puede ser un motor secundario o de búsqueda (LUE) optimizado para la búsqueda de datos en grandes datos fijos, mientras la pluralidad de las computadoras de red 120-1,.,.120-N puede ser una pluralidad de motores del protocolo del extremo frontal (PEs) optimizados para el procesamiento de la red y transporte. El LUE puede ser un servidor multiprocesador poderoso que almacena el grupo de registros DNS completo en la memoria 104 para facilitar la búsqueda y actualización de alto rendimiento, y alta velocidad. En una modalidad alternativa, los servicios de resolución DNS pueden ser provistos a través de series de servidores multiprocesador poderosos, o LUEs, cada uno almacenando un subgrupo de grupos de registro DNS completos para facilitar la búsqueda y actualización de alto rendimiento, alta velocidad. Inversamente, la pluralidad de PEs puede ser máquinas en base a PC, bajo perfil, genéricas, corriendo un sistema operativo multitareas eficiente (por ejemplo, Red Hat Linux® 6.2), que minimiza la carga de transporte de procesamiento de la red en el LUR con el fin de maximizar los recursos' disponibles para la resolución DNS. Las PEs pueden manejar las matrices del protocolo DNS de línea cableada, responde a investigaciones DNS inválidas y multiplaza investigaciones DNS válidas para el LUE a través de la LAN 122. En una modalidad alternativa incluyendo múltiples LUEs almacenando subgrupos de registro DNS, los PEs pueden determinar que LUE deberá recibir cada investigación DNS válida, e investigaciones DNS válidas multiplexadas a los LUEs apropiados. El número de PEs para un LUE individual puede ser determinado, por ejemplo, mediante el número de búsquedas DNS que van a ser procesadas por segundo y las características de funcionamiento del sistema particular. Otras mediciones también pueden ser utilizadas para determinar las relaciones de mapeo y comportamientos apropiados. Generalmente, otras modalidades basadas en búsquedas, de volumen grande puede ser soportadas, incluyendo, por ejemplo, resolución de números de teléfono, procesamiento de señalización SS7, determinación de ubicación geográfica, mapeo del número-a-suscriptor telefónico, ubicación del suscriptor y determinación de presencia, etc. En una modalidad, un servidor de procesamiento de transacción en línea central (OLTP) 140-1 puede estar acoplado a WAN 124 y recibe adiciones, modificaciones y eliminaciones (es decir, tráfico de actualizaciones) a la base.de datos 142-1 de varias fuentes. El servidor OLTP 140-1 puede enviar actualizaciones al sistema 124. El servidor OLTP 140-1 puede ser optimizado para procesar tráfico de actualizaciones. En varios formatos y protocolos, incluyendo, por ejemplo, el Protocolo de Transmisión de Hipertexto (HTTP), el Protocolo de Registro de Registros (RRP), el Protocolo de Aprovisionamiento Extensible (EEP), la Interfase Genérica Mecanizada del Sistema/800 de Administración del Servicio (MGI), y otros protocolos de aprovisionamiento en linea. Una constelación de LUEs de solo lectura puede ser utilizada en un concentrador de puertos y arquitectura de palabras para proporcionar capacidad de búsqueda de alta velocidad con actualizaciones increméntales, de alto volumen desde el servidor OLTP 140-1. En una modalidad alternativa, los datos pueden ser distribuidos a través de múltiples servidores OLTP 140-1, ...140-S, cada uno de los cuales puede estar acoplado a la WAN 124. Los servidores OLTP 140-1 140-S pueden recibir adiciones, modificaciones y eliminaciones (es decir, tráfico de actualización) a sus respectivas bases de datos 142-1....142-S (no mostradas por claridad) de varias fuentes. Los servidores OLTP 140-1 140-S pueden enviar actualizaciones al sistema 100, el cual puede incluir copias de bases de datos 142-1 , ...142-S, otros datos dinámicamente creados, etc. a través de la WAN 124. Por ejemplo, en una modalidad de ubicación geográfica, los servidores OLTP 1401-1.....140-S pueden recibir tráfico de actualización de grupos de sensores remotos. En otra modalidad alternativa, la pluralidad de computadoras de red 120- 1 120-N también pueden recibir adiciones, modificaciones y eliminaciones (es decir, tráfico de actualización) de varias fuentes a través de la WAN 124 o LAN 122. En esta modalidad, la pluralidad de redes de computadora 120-1 , ...120-N puede enviar actualizaciones, así como búsquedas, al sistema 100. En una modalidad, el sistema 100 puede incluir una base de datos remota (por ejemplo, base de datos remota 210). La nueva información, o el tráfico de actualización, pueden ser recibidos, por ejemplo, a través de la WAN 124 a partir del servidor OLTP 140-1. En una modalidad, la nueva información puede incluir modificaciones a por lo menos un elemento existente dentro de la base de datos remota. El sistema 100 puede crear un nuevo elemento de la base de datos remota sobre la nueva información recibida a través de la red, y sin acceso de búsqueda restringido para la base de datos remota, escribir un apuntador en el nuevo elemento a la base de datos remota utilizando una operación ininterrumpible individual, tal como, por ejemplo, una instrucción de almacenamiento. En una modalidad, el procesador 102-1 puede incluir un tamaño de palabra de por lo menos n bytes, la memoria 104 puede incluir un ancho de por lo menos n bytes y la instrucción de almacenamiento puede escribir n bytes a una dirección de memoria remota localizada en un límite de n bytes. En otra modalidad, el sistema 100 puede físicamente eliminar un elemento existente de la memoria 104, correspondiente al nuevo elemento, después de que el apuntador es escrito en la base de datos remota. En la modalidad de resolución DNS, cada PE (por ejemplo, cada una de la pluralidad de redes de computadora 120- 1 , ...120-N) puede combinar, o multiplexar varios mensajes de búsqueda DNS, recibir a través de una red de área amplia (por ejemplo, WAN 124), en un Super Paquete de Solicitud y enviar el Super Paquete de Solicitud a LUE (por ejemplo, sistema 100) a través de una red de área local (por ejemplo, LAN 122). El LUE puede combinar, o multiplexar, varias contestaciones de mensajes de búsqueda DNS en un Super Paquete de Respuesta y enviar el Super Paquete de Respuesta al PE apropiado a través de la red de área local. Generalmente, el tamaño máximo de una Super Paquete de Respuesta o de Solicitud puede estar limitado por la unidad de transmisión máxima (MTU) de la capa de la red física (por ejemplo, Ethernet Gigabit). Por ejemplo, el tamaño de los mensajes de búsqueda y de respuesta DNS típico de menos de 100 bytes y 200 bytes, respectivamente, permite que aproximadamente 30 búsquedas sean multiplexadas en un Super Paquete de solicitud individual, así como alrededor de 15 respuestas sean multiplexadas supimos en un Super Paquete de respuesta individual. Sin embargo, un número más pequeño de búsquedas (por ejemplo, 20 búsquedas) puede estar incluido en un Super Paquete de solicitud individual con el fin evitar el sobre flujo MTU en la respuesta (por ejemplo 10 contestaciones). Para tamaños de MTU más grandes, el número de búsquedas y contestaciones multiplexadas puede ser incrementado por consiguiente. Cada PE de multitareas puede incluir un paquete entrante y un paquete saliente para manejar búsquedas y respuestas DNS, respectivamente. Por ejemplo, el paquete entrante puede no estar colocado los componentes de búsqueda DNS a partir de los paquetes de búsqueda DNS entrantes recibidos a través de la red de área amplia y multiplexar varios milisegundos de búsquedas en un Super Paquete de solicitud. El paquete entrante entonces puede enviar el Super Paquete de Solicitud a LUE a través de una red de área local. Adversamente, el paquete de salida puede recibir el Super Paquete de Respuesta desde LUE, desmultiplicar las respuestas contenidas ahí, y colocar los varios campos en una contestación DNS válida, la cual después puede ser transmitida a través de una red de área amplia. Generalmente, como se notó anteriormente, otras modalidades basadas en búsquedas, de volumen grande pueden ser soportadas. En una modalidad, el Super Paquete de Solicitud también puede incluir información de estado asociada con cada búsqueda DNS, tal como, por ejemplo, la dirección fuente, el tipo de protocolo, etc. El LUE puede incluir la información de estado, y contestaciones DNS asociadas, dentro del Super Paquete de Respuesta. Cada PE entonces puede ser construido y devolver mensajes de contestación DNS válidos utilizando la información transmitida de LUE. En consecuencia, cada PE puede ventajosamente operar como una máquina sin información sobre el estado anterior, es decir, las contestaciones DNS válidas pueden estar formadas a partir de la información contenida en el Super Paquete de Respuesta. Generalmente, LUE puede devolver el Super Paquete de Respuesta a PE a partir del Super Paquete de origen entrante; sin embargo, otras variaciones pueden obviamente ser posibles. En una modalidad alternativa, cada PE puede mantener la información de estado asociada con cada búsqueda DNS e incluir una referencia, o manipulador, de la información de estado dentro del Super Paquete de Solicitud. LUE también puede incluir las referencias de la información de estado, y contestaciones DNS asociadas, dentro del Super Paquete de Respuesta. Cada PE puede entonces ser construido y devolver mensajes de contestación DNS válidos utilizando las referencias de la información de estado transmitidas desde LUE, así como la información de estado mantenida en el mismo. En esta modalidad, LUE puede devolver el Super Paquete de Respuesta a PE a partir del cual el Super Paquete de Entrante se origina. La Figura 2 es un diagrama de bloque de un concentrador de puertos y una arquitectura de palabras de acuerdo con una modalidad de la presente invención. Generalmente, el sistema puede incluir una base de datos local 200 (la cual puede estar incluida en el concentrador de puertos OLPT central 140) y una o más bases de datos remotas 210 (las cuales pueden estar incluidas en LUEs 100) conectadas a la base de datos local 200 a través de cualquier mecanismo de conexión, por ejemplo Internet o LAN 122. Las bases de datos pueden enviar y recibir datos actualizados. Haciendo referencia ahora a la Figura 3, en las modalidades de la presente invención, las bases de datos locales 200 envían archivos de envío F 300- .300-F e inicializan el archivo de envió 310 en la base de datos remota 210 con el fin de actualizar la base de datos remota 210. Los archivos de actualización pueden ser enviados individualmente o en lotes, tales como archivos de envió múltiples 300, un archivo de envió 300 y un archivo de envió de inicialización 310, múltiples archivos de envió 300 y un archivo de envío de inicialización 310, archivo de envió 300 solo, o archivo de envío de inicialización 300 solo. En una modalidad de la presente invención, el procesador 104 puede recibir el archivo de envío 310 incluyendo datos actualizados de la base de datos local 200. El sistema 150 recibe el archivo de envío 300 y el archivo de envío de inicialización 310 en la base de datos remota 210 a través de una ¡nterfase de comunicación 118. El procesador 104 puede entonces comparar los datos actualizados en el archivo de envío 300 o el archivo de envío de inicialización 310 contra los datos correspondientes en la base de datos remota 210. Si los datos son diferentes en la base de datos remota 210, entonces el procesador 104 puede aplicar el archivo de envío 300 o el archivo de envío de inicialización 310 a la base de datos remota 210. Por consiguiente, la base de datos remota 210 puede subsecuentemente tener datos actualizados que coincidan con los datos actualizados de la base de datos local 200. La Figura 4 muestra el archivo de envío 300 de acuerdo con una modalidad de la presente invención. Los campos del archivo 300 pueden incluir, por ejemplo, un identif icador de archivo 400, el tiempo de generación del archivo 402, el número de transacciones N en el archivo 404, el tamaño total del archivo 406, una suma de - control o cualquier indicador de verificación de error 408, y transacciones 410-1,... 400-N (incluyendo los identif icadores transacciones). Estos campos del archivo de envío son ejemplos que pretenden ilustrar, y no limitar, el alcance de las modalidades de la presente invención. Cualquier campo útil puede ser incluido en el archivo de envío 300. El archivo de envío 300 incluye los cambios a la base de datos local 200 entre dos puntos en el tiempo. Estos cambios pueden incluir, por ejemplo, adiciones de nuevos identif icadores (es decir, identificadores de registros de datos), eliminaciones de identificadores existentes, modificaciones de uno o más registros de datos con un identificador, renombrar un identif icador, un no-op, etc. Uno o más de estos cambios pueden ocurrir en un secuencia y pueden ser llamados transacciones. El archivo de envío 300 puede incluir identificadores únicos de estas transacciones. El archivo de envío 300 puede incluir identificadores únicos de estas transacciones. Las transacciones pueden ser registradas en el archivo de envío 300 con el fin de que ocurran en la base de datos local 200. Adicionalmente, para transacciones que incluyen más de un cambio, los cambios deben ser registrados dentro de la transacción con el fin de que ocurran en la base de datos local 200.

Generalmente, los identificadores de transacción pueden ser asignados a transacciones en cualquier orden. Es decir, los identificadores de transacción no necesitan ser incrementados de manera monotónica a través del tiempo. Por ejemplo, dos transacciones secuenciales pueden tener identificadores transacción de 10004 seguido por 10002. Por consiguiente, el orden en que una transacción ocurre puede ser determinado a través de su colocación en el archivo actual 300-F o su colocación en un archivo precedente 300-(F-1). Generalmente, las transacciones no deben extenderse a archivos adyacentes con el fin de completar totalmente una actualización de la base de datos remota dentro de una aplicación de archivo de envío. Esto previene una interrupción de una actualización debido a un retraso en la red, lo cual podría resultar en datos erróneos en la base de datos remota 210. La Figura 5 muestra el archivo de envío de inicialización 310 de acuerdo con una modalidad de la presente invención. Los campos del archivo de envío de inicialización 310 pueden incluir, por ejemplo, un ¡dentif icador de archivo 500, el tiempo de generación del archivo 502, el número de transacciones N en el archivo 504, el tamaño total del archivo 506, una suma de control o cualquier indicador de verificación de error 508, y la copia de la base de datos local completa (datos) 516. El archivo de envío de inicialización 310 además puede incluir el campo 510, el cual es el identificador del archivo 400 del último archivo de envío 300 generado antes de la generación del archivo 310, y el campo 512 el cual es el identificador de la última transacción comprometida con la base del datos local 200 antes de la generación del archivo de envío de inicialización 310. Los datos en las bases de datos local y remota 200, 210 pueden ser asignados en cuadros residentes en las bases de datos 200, 210. Las bases de datos 200, 210 pueden soportar un número arbitrario de cuadros. Por lo tanto, cuando las bases de datos tienen cuadros, el archivo de envío de inicialización 310 puede incluir un campo para cada cuadro incluyendo el número de registros grabados en el cuadro. Por ejemplo, una base de datos de nombre de dominio puede incluir un cuadro de dominio y un cuadro de nombre de servidor. Por lo tanto, el archivo de envío de inicialización puede incluir un campo indicando el número de registros en el cuadro de dominio y un campo indicando el número de registros en el cuadro de nombre de servidor.

El campo puede especificar, por ejemplo, el nombre del cuadro, una clave utilizada para indexar registros el cuadro, y el número de registros en el cuadro. Adicionalmente, el archivo de inicialización 310 puede incluir un campo indicando la versión del archivo de envío de inicialización 310, usualmente 1.0. Estos campos del archivo de envío de inicialización son ejemplos que pretenden ilustrar, y no limitar, el alcance de las modalidades de la presente invención. Cualquier campo útil puede ser incluido en el archivo de envío de inicialización presuntos 310. El archivo de envío de inicialización 310 puede incluir, por ejemplo, una copia consistente de lectura de la base de datos local completa 200, como se manifestó previamente. El archivo de envío de inicialización 310 puede volverse consistente con la base de datos local 200 en un punto en el tiempo entre ts y tf, en donde ts es el tiempo en el cual la generación del archivo de envío de inicialización 310 se inicia y tf es el tiempo en el cual la generación se completa. Es decir, la única operación que debe ocurrir en el archivo de envío de inicialización 310 es una operación "Agregar". Es decir, cuando el archivo de envío de inicialización 310 es generado, las copias de la base de datos local completa 200 en el tiempo t pueden ser registradas en el archivo de envío de inicialización 310. Por lo tanto, una operación de "Agregar" puede ser realizada para registrar la base de datos local 200 en el archivo de envío de inicialización 310. Los identif icadores pueden ser registrados en el archivo de envío de inicialización 310 en cualquier orden. Alternativamente, en presencia de identificadores foráneos, los registros de los datos referenciados pueden ser registrados antes de un registro de datos referenciados. La adición de los campos 510 y 512 puede proporcionar un archivo de envío de i nicialización 310 con algunas advertencias de que los archivos de envío 300 que pueden ser generados y comprometidos con la base de datos remota 210 mientras el archivo de envío de inicialización 310 está siendo generado. Sin embargo, las generaciones del archivo de envío 300 y del archivo de envío de inicialización 310 pueden ser desacopladas una de la otra con respecto a la carencia de la dependencia de uno con el otro para la generación. Dicha estructura y proceso pueden prevenir un método menos eficiente, en el cual la generación del archivo de envío y la aplicación se pueden suspender hasta que la generación del archivo de impíos de inicialización puede ser completada. Al continuar generando y aplicando archivos envío 300 mientras se generan archivos de envío de inicialización 310, como en una modalidad de la presente invención, la verificación de error fuerte, de los archivos envío 300 puede ser hecha así como la colocación de limitantes en la base de datos remota 210, por ejemplo limitantes únicos o limitantes de identif icador foráneo, pueden ser hechos. La colocación de limitantes puede proteger la integridad de los datos en las bases de datos remota 210, no permitir a las transacciones que violan modelos relaciónales de la base de datos remota 210. Por ejemplo, una limitante única puede prevenir que la misma clave sea almacenada en la base de datos 210 más de una vez. La Figura 6 es una gráfica de cronometraje si ilustrativa de la generación de un archivo de envío y de un archivo de envío de inicialización de acuerdo con una modalidad de la presente invención. En la Figura 6, los archivos envío 300 (sf- 1 a s-21) son generados en intervalos de tiempo regulares. En una modalidad alternativa, los archivos envío 300 pueden ser generados a intervalos de tiempo irregulares. Generalmente, la generación del archivo de envío no toma el intervalo de tiempo completo. Por ejemplo, si los archivos son generados en intervalos de cinco minutos, no toma los cinco minutos completos para completar la generación del archivo. Adicionalmente, si ocurren cambios en la base datos local 200 mientras el archivo de envío 300 está siendo generado, esos cambios serán capturados en el siguiente archivo de envío 300. Por ejemplo, si el archivo de envío sf-4 inicia su generación a las 12:05:00 y se termina a las 12:05:02, entonces cualesquiera cambios a la base de datos local 200 que ocurran entre las 12:05:00 y las 12:05:02 son capturados en el archivo de envío sf-5 (por ejemplo, 300-5), el cual captura el periodo de tiempo de las 12:05:00 a las 12:10:00. Los archivos envío 300-5 y 300-19 se ilustran en la Figura 6. Estos archivos muestran, entre otros campos, un identif icador de archivo 601 (sf-5, sf-19), un tiempo de generación de archivo 603, e identificadores de transacción 605 (por ejemplo, 10002). Observar que los identificadores de transacción pueden mostrar ordenados en forma monotónica. Como se mencionó previamente los identificadores de transacción pueden tener valores aleatorios. Sin embargo, las transacciones asociadas mismas son registradas en el archivo de envío 300 con el fin de que ocurran en la base de datos local 200. Ya que la generación del archivo de envío de inicializacion 310 y la generación del archivo de envío 300 pueden estar desacopladas, el archivo de envío de inicialización 310 puede ser generado en cualquier momento. Por ejemplo, el archivo de envío de inicialización 310 puede ser generado antes, durante o después de la generación del archivo de envío 300. La Figura 6 ilustra el archivo de inicialización 310 siendo generado en medio entre el cuarto y el quinto archivo de envío (por ejemplo, sf-4 y sf-5). En una modalidad, el archivo envío de inicialización 310 puede incluir, entre otros campos, un identificador de archivo 610 (sf-1), un identif icador de archivo 615 del último archivo de envío generado antes de la generación del archivo de envío de inicialización, y el identificador de transacción 620 de la última transacción comprometida antes de la generación del archivo de envío de inicialización. En este ejemplo, el último archivo de envío generado es el archivo de envío sf-4 y la última transacción comprometida es la transacción 10001. El archivo de envío de inicialización 310 inicia la generación 611 a las 12:07:29. La primera mitad de las transacciones en el archivo de envío 300-5 (sf-5), transacciones 10002, 10005, y 10001 ya han estado comprometidas con la base de datos local 200 cuando el archivo de envío de inicialización 310 inicia la generación. Por consiguiente, el archivo de envío de inicialización 310 puede tener una advertencia de estas transacciones y puede capturar estas transacciones en el archivo de envío de inicialización 310. Sin embargo, el archivo de envío de inicialización 310 puede no estaba advertido la transacciones subsiguientes 10003 y 10004 que ocurran después del inicio de la generación del archivo de envío de inicialización. Mientras se genera el archivo de envío de inicialización 310, los archivos de envío que inician con el archivo de inicia 300-5 pueden continuar siendo generados a intervalos regulares. Estos archivos pueden ser enviados a la base de datos remota 210 y ser aplicados. El archivo de envío de inicialización 310 puede completar la generación a la 1:15:29, a la mitad entre la generación del 18° y del 19° archivo de envío 300 (sf-18 y sf-19), y puede no afectar la generación del 19° archivo de envío 300-19. Después de recibir y cargar el archivo de envío de inicialización 310 en la base de datos remota 210, la base de datos remota 210 puede no considerar los archivos de envío generados antes de la generación del archivo de envío de inicialización 310.

Esto puede ser debido a, por ejemplo, el archivo de y motivo de inicialización 310 incluyendo todos los cambios a la base de datos local 200 que fueron registrados en archivos envío anteriores 300. En este ejemplo, la base datos remota 210 puede no necesitar considerar del primero al cuarto archivo de envío (sf-1 a sf-4). Estos cambios registrados en estos archivos envío sf-1 a sf-4 también puede ser registrados en el archivo de envío de inicialización 310. Estos archivos envío anteriores (sf-q a sf-4) pueden ser eliminados o, alternativamente archivados. Similarmente, la base de datos remota 210 puede no considerar transacciones comprometidas antes de la generación del archivo de envío de inicialización 310 que fueron incluidas en un archivo de envío 300 generado posteriormente. El archivo de envío de inicialización 310 puede incluir estas transacciones cuando el archivo de envío de inicialización 310 es generado. Por ejemplo, la base de datos remota 210 puede no necesitar considerar las primeras tres transacciones 10002, 10005, 10001 el archivo de envío sf-5 debido a estas transacciones. Estas transacciones registradas en el archivo de envío sf-5 también pueden ser registradas en el archivo de envío de inicialización 310. Las transacciones comprometidas pueden ser eliminadas, cual alternativamente archivadas. La Figura 7 es una gráfica de flujo de una modalidad de la presente invención en la cual los archivos actualizados de una base de datos local pueden ser generados. Un sistema puede generar (705) una pluralidad de actualizaciones periódicas en base a los cambios increméntales a la base datos local. Cada actualización puede incluir una o más transacciones. El sistema entonces puede enviar (710) las actualizaciones periódicas a la base datos remota. Mientras datos actualizaciones periódicas están siendo generadas, el sistema puede inicia la generación (715) de una actualización de inicialización en el tiempo de inicio. La actualización de inicialización puede incluir una versión de la base de datos local completa. El sistema puede determinar (720) la última actualización periódica generada antes de tiempo de inicio en la última transacción comprometida antes de tiempo de inicio. Entonces el sistema puede enviar (725) la actualización de inicialización a la base datos remota. La actualización de inicialización puede incluir un identificador de actualización asociado con la última actualización periódica y el identificador de transacción asociado con la última transacción comprometida. Por ejemplo, OLTP 140 puede generar (705) los archivos envío 300 a un intervalo de tiempo regular o irregular. OLTP 140 puede entonces enviar (710) archivos envío 300 a la base datos remota 210. Mientras los archivos envío 300 están siendo generados, OLTP 140 puede iniciar la generación (715) del archivo de envío de inicialización 310 en el tiempo de inicio 611. El archivo de envío de inicialización 310 puede entre una copia de la base datos local completa 200. OLTP 140 puede entonces determinar (720) el último archivo de inicio 300 generado antes de tiempo de inicio 611 para la generación del archivo de envío de inicialización 310 y la última transacción comprometida antes de tiempo de inicio 611 para la generación del archivo de envío de inicialización 310. OLTP 140 entonces puede enviar (725) el archivo de envío de inicialización 310 a la base de datos remota 210. El archivo de envío de inicialización 310 puede incluir el identificador del archivo de envío 615 asociado con el último archivo de envío 300 generado y un identificador de transacción 620 asociado con la última transacción comprometida. La Figura 8 es una gráfica de flujo de una modalidad de la presente invención en la cual ha base de datos remota puede recibir archivos actualizados de la base datos local. Un sistema puede recibir (805) una pluralidad de actualizaciones periódicas. Cada actualización puede incluir una o más transacciones. Las actualizaciones periódicas pueden ser recibidas individualmente o en lotes. El sistema puede recibir (810) una actualización de inicialización en algún momento. La actualización de inicialización puede incluir una versión de la base de datos local completa. El sistema puede leer (815) el identificador de la última actualización periódica y el identificador de la última transacción a partir de la actualización de inicialización. El sistema puede entonces determinar (820) la última actualización periódica asociada con el identificador de actualización y la última transacción asociada con el identificador de transacción. La actualización periódica y la transacción pueden ser las últimas generadas y comprometidas, respectivamente, antes de la generación de la actualización de inicialización. El sistema puede aplicar (825) las transacciones no comprometidas restantes en la actualización periódica correspondiente a la base de datos remota. El sistema puede entonces aplicar (830) las actualizaciones periódicas restantes generadas después de la última actualización periódica a la base datos remota. La aplicación de la actualización de inicialización ventajosamente aplica cualquier actualización periódica perdida previamente. Por ejemplo, LUE 100 puede recibir (805) archivos envío 300 a intervalos de tiempo regulares o irregulares. Los archivos de envío 300 pueden ser recibidos individualmente o en lotes. LUE 100 puede recibir (810) el archivo de envío de inicialización 310 en algún momento. LUE 100 puede leer (815) el identif icador del archivo de envío 615 y el identificador de transacción 620 a partir del archivo de envío de inicialización 310. LUE 100 puede entonces determinar (820) el archivo de envío 300 asociado con el identificador del archivo de envío 615 y la transacción 605 asociada con el identificador de transacción 620. El archivo de envío y la transacción pueden ser los últimos generados y comprometidos, respectivamente, antes de la generación del archivo de envío de inicialización 310. LUE 100 puede aplicar (825) las transacciones no comprometidas restantes 605 en el archivo de envío 300 correspondiente a la base de datos remota 210. LUE 100 puede entonces aplicar (830) los archivos de envío restantes 300 después del último archivo de envío sf-4 a la base de datos remota 210. En una modalidad alternativa, por ejemplo, LUE 100 puede descartar o archivar archivos de envío 300 que no han sido aplicados a la base de datos remota 210 y/o que tienen un tiempo de generación 603 anterior a la generación del archivo de envío de inicialización 611. Los archivos de envío 300 descartados o archivados pueden incluir el archivo de envío sf-4 asociado con el identif icador del archivo de envío 615. Se puede entender que después de que el archivo de envío de inicialización 310 es aplicado, cualesquiera archivos de envío 300 posteriores que pueden haber sido ya aplicados a la base de datos remota 210 pueden perderse debido a que la base de datos remota 210 se puede volver en consistente en la lectura con el archivo de envío de inicialización 310. Por consiguiente, estos últimos archivos de envío 300 pueden ser reaplicados. En una modalidad de la presente invención, los archivos de envío 300 y el archivo de envío de inicialización 310 pueden ser enviados de la base de datos local 200 a la base de datos remota 210 sin aprobación, es decir, sin una señal ACK/NACK para indicar que los archivos fueron exitosamente recibidos. Esto ventajosamente reduce los gastos indirectos que una señal ACK/NACK puede crear. En una modalidad alternativa, una señal ACK/NACK puede ser enviada de la base de datos remota 210 para indicar la recepción exitosa de los archivos. En esta modalidad, la señal ACK/NACK puede ser enviada en sistemas con comunicaciones no confiables. La Figura 9 es una gráfica de flujo de otra modalidad de la presente invención en la cual el sistema puede validar los archivos actualizados enviados desde la base de datos local y recibidos en la base de datos remota. Aquí, un sistema puede enviar (905) una pluralidad de actualizaciones periódicas. Cada actualización puede incluir una o más transacciones. Las actualizaciones periódicas pueden ser enviadas individualmente o en lotes. El sistema puede enviar (910) una actualización de inicialización en algún momento y aplicar la actualización de inicialización a la base de datos remota. La actualización de inicialización puede incluir una versión de la base de datos local completa. El sistema puede primero identificar (915) las discrepancias entre la base de datos local y remota comparando las bases de datos. El sistema puede determinar (920) si las discrepancias son válidas o erróneas. El sistema entonces puede aplicar (925) las actualizaciones periódicas a la base de datos remota de acuerdo con una modalidad de la presente invención. Esta modalidad ventajosamente puede asegurar que no hay errores en la base de datos remota como un resultado de la recepción de actualizaciones de la base de datos local. Por ejemplo, OLTP 140 puede enviar (905) archivos de envío 300 en intervalos de tiempo regulares o irregulares a la base de datos remota 210. Los archivos de envío 300 pueden ser enviados individualmente o en lotes. OLTP 140 puede enviar (910) el archivo de envío de inicialización 310 en algún momento a LUE 100 y LUE 100 puede aplicar el archivo de envío de inicialización a la base de datos remota 210. OLTP 140 puede comparar la base de datos local 200 con la base de datos remota 210 e identificar (915) las discrepancias entre ellas. OLTP 140 puede entonces determinar (920) si las discrepancias son válidas o erróneas. OLTP 140 puede entonces notificar a LEU 100 aplicar (925) los archivos de envío 300 a la base de datos remota 210 de acuerdo con una modalidad de la presente invención. LUE 100 puede entonces aplicar los archivos de envío 300 a la base de datos remota 210. En una modalidad alternativa, el sistema puede aplicar ambos, los archivos de envío y el archivo de envío de inicialización antes de la identificación y validación de las discrepancias. Alternativamente, el sistema puede aplicar ambos, el archivo de envío y el archivo de envío de inicialización después de identificar y validar las discrepancias. Se puede entender que el proceso de validación puede ser realizado en cualquier dato transmitido a través de una red de una fuente a un destino para el propósito de aplicar los datos transmitidos al destino. La Figura 10A es una gráfica de flujo de una modalidad de la validación del archivo de envío y del archivo de envío de inicialización de acuerdo con la presente invención. Después de enviar una pluralidad de actualizaciones periódicas y una actualización de inicialización a la base de datos remota, un sistema puede validar estas actualizaciones. Cada actualización puede incluir una o más transacciones realizadas en la base de datos local. Cada transacción puede incluir uno o más eventos. Un evento en una acción u ocurrencia de la base de datos, por ejemplo adición, modificación, eliminación, etc. con respecto a los datos en la base de datos. Primero, el sistema puede comparar (1000) un registro en la base de datos remota con un registro correspondiente en la base de datos local. El sistema puede generar (1005) una excepción que describe una discrepancia entre los registros de la base de datos local y la remota, en donde una excepción puede ser generada para cada discrepancia. Una discrepancia puede ser cualquier diferencia en por lo menos un valor de dato entre dos versiones del mismo registro. Por ejemplo, un registro de datos en la base de datos local puede ser (12345, xyz.com, 123.234.345). Un registro de datos correspondiente en la base de datos remota, el cual se supone que es el mismo, puede ser (12345, abc.com, 123.234.345). Por consiguiente, existe una discrepancia en el segundo valor de datos del registro. De esta manera, una modalidad de la presente invención puede generar una excepción que describe esta discrepancia. Una excepción puede describir una discrepancia simplemente indicando que esa discrepancia existe; especificando la ubicación de la discrepancia; describiendo la diferencia entre los dos valores de datos en la discrepancia, etc. Un registro de datos en la base de datos local corresponde a un registro de datos en la base de datos remota (y viceversa) si dos registros se suponen que contienen los mismos datos. Se puede entender que una discrepancia puede referir una diferencia entre uno o más valores de datos en un registro o el registro en su totalidad. El sistema puede asociar (1010) un identif icador de excepción con cada excepción, en donde el identif icador de excepción puede estar asociado con un identificador del registro. Por ejemplo, el registro de datos (12345. xyz.com, 123.234.345) puede tener un identif icador d10. Por consiguiente, el identif icador de excepción también puede ser d10. Cada excepción puede ser clasificada como perteneciendo a cualquiera de muchos tipos de excepciones (o discrepancias). Una lista de excepciones puede ser formada para incluir los tipos de excepción y el identif icador de excepción de la excepción clasificada en la misma. La lista de excepción y los diferentes tipos de excepciones se describirán en detalle más adelante. El sistema también puede asociar (1015) un identificador de evento con cada evento en la actualización, en donde el identificador del evento puede estar asociado con un identificador del registro. Por ejemplo, el registro de datos (12345, xyz.com, 123.234.345) puede tener un identificador d10. Por consiguiente, el identificador del evento puede también ser d10. Cada evento en la actualización se puede encontrar a partir de un historial de eventos. Un historial de eventos puede ser un listado, etc. de los eventos realizados en los registros en la base de datos local durante un período de tiempo. El historial de eventos será descrito más adelante en detalle. El sistema entonces puede determinar (1020) s la actualización del registro es válida. La Figura 10B es una gráfica de flujo de una modalidad de la determinación de la validación. Esta determinación puede ser hecha como sigue. Cada evento puede ser comparado (1022) con cada excepción. Si cada excepción es justificada (1024) a través de un evento, entonces la actualización puede ser designada (1026) como válida y la actualización puede ser aplicada a la base de datos remota. De lo contrario, si cada excepción no es justificada (1024) por un evento, entonces la actualización puede ser designada (1028) como inválida y las excepciones pueden ser registradas como errores. Una excepción puede ser justificada cuando un identificador de evento corresponde al identificador de la excepción y el evento asociado corresponde a una secuencia válida de eventos asociados con el tipo de excepción. Las secuencias válidas serán descritas en detalle más adelante. Si la excepción es justificada, el sistema puede remover el identificador de la excepción de las lista de excepciones. La excepción que está siendo justificada puede indicar que la discrepancia es una válida, por ejemplo, la base de datos remota aún no ha recibido la actualización, pero ciertamente coincidirá con la base de datos local cuando se reciba la actualización. Durante la validación, el sistema puede identificar los errores latentes o fallas en actualizaciones periódicas y de inicialización. El sistema puede asegurar que estas actualizaciones pueden ser estructuralmente y semánticamente correctas, que estas actualizaciones pueden ser aplicadas exitosamente sin generar excepciones o por el contrario dañar de forma torpe, que las comparaciones entre las bases de datos local y remota pueden exactamente detectar errores, y que los datos del perfil alto pueden no ser accidentalmente eliminados. El sistema puede asegurar que las actualizaciones periódicas y de inicialización pueden ser exitosamente aplicadas a la base de datos remota.

Muchos errores pueden ventajosamente ser descubiertos a través del intento de aplicar las actualizaciones a la base de datos remota durante la validación. Por ejemplo, las advertencias de errores céntricos de datos de que un objeto ya existe en la base de datos remota, o advertencias de que existe una violación del identificador foráneo pueden ser descubiertas durante un intento de aplicación. De esta manera, después de realizar el proceso de validación de una modalidad de la presente invención, el sistema puede intentar aplicar estas actualizaciones a la base de datos remota. El intento puede fallar, lo cual puede indicar que hay errores adicionales en las actualizaciones que invalidan las actualizaciones. Por consiguiente, no se debe hacer ningún intento adicional para aplicar estas actualizaciones a la base de datos remota. En una modalidad alternativa, se puede hacer un intento de aplicar por lo menos una de las actualizaciones antes de llevar a cabo la validación. Si el intento falla, entonces la validación deber ser saltada y la actualización descartada. Por otro lado, sin intento es exitoso, entonces la validación puede ser llevada a cabo y la actualización válida se mantiene el actualización inválida se registra para discrepancias. En una modalidad ilustrativa, OLTP 140 puede validar archivos envió 300 y archivos de envío de inicialización 310 para asegurar que los archivos envío 300 y los archivos de envío de inicialización 310 pueden ser exitosamente aplicados a la base de datos remota 210.

En modalidades alternativas, las computadoras entre 121, LUE 100, o cualquier combinación de los sistemas existentes pueden llevar a cabo la validación. Haciendo referencia Figura 10A, OLTP 140 puede comparar la base de datos local 200 y la base de datos remota 210 para determinar cualesquiera excepciones entre ellas. La excepciones pueden incluir tres tipos: los datos puede estar en la base de datos remota 210 y no en la base de datos local 200; los datos puede estar en la base de datos local 200 y no en la base de datos remota 210; o, los datos correspondientes puede estar en la base local 200 y en la base de datos remota 210, pero los datos pueden ser diferentes. Por supuesto, los datos correspondientes pueden estar en la base de datos local 200 y la base de datos remota 210 y los datos pueden ser los mismos, en cuyo caso, los datos pueden ser considerados válidos, esta manera no requiriendo procesamiento adicional a través de OLTP 140. Se puede entender que la discrepancia puede referirse a uno o más valores de datos en el registro o el registro su totalidad. Por consiguiente, OLP que 140 puede comparar (1000) registros correspondientes en la base de datos local 200 y la base de datos remota 210. OLTP 140 puede generar (1005) una excepción que describe una discrepancia entre el registro en la base de datos remota 210 y el registro la base de datos local 200, en donde una excepción puede ser generada para cada discrepancia. OLTP 140 puede asociar (1010) un identif icador de excepción con cada excepción, en donde el identificador de excepción puede estar asociado con un identificador del registro. Una lista de excepción puede ser formada para incluir los tipos de excepción y el identificador de excepción para la excepción que pertenece a ese tipo de excepción. En una modalidad, la excepción puede ser designada como una excepción "Lista 1" (o discrepancia) si la excepción pertenece al primer tipo de excepción, o una excepción "Lista 2" si la excepción pertenece al segundo tipo de excepción, o una excepción "Lista 3" si la excepción pertenece al tercer tipo de excepción. La Figura 11 muestra una lista de excepción ilustrativa 1140. Se puede entender que la presencia de un identificador de excepción en la lista de excepción puede no implicar que el archivo de envío 300 o el archivos de envío de inicialización 310 es malo, ya que, por ejemplo, los tres tipos excepciones pueden legítimamente ocurrir debido a un retraso del tiempo entre los cambios de la base de datos local 200 y las actualizaciones aplicadas a la base de datos remota 310. Dicho retraso puede ser causado por congestión de red, por ejemplo. Es decir, la validación puede proporcionar un mecanismo para limpias datos legítimos de los datos erróneos. Para el archivo de envío de inicialización 310, OLTP 140 puede comparar la base de datos local 200 y la base de datos remota 210 realizando una exploración de cuadro completo bidireccional en ambas bases de datos 200, 210. Es decir, todos los datos en la base de datos local 200 pueden ser comparados contra todos los datos en la base de datos remota 210. Entonces, todos los datos en la base de datos remota 210 pueden ser comparados contra todos los datos en la base de datos local 200. Esto ventajosamente proporciona una comparación exhaustiva de las bases de datos 200, 210 para descubrir todas las discrepancias. Para el archivo de envío 300, OLTP 140 puede comparar solamente los registros de datos en la base de datos local 200 y la base de datos remota 210 está registrada en el archivo de envío 300. Esto ventajosamente proporciona una búsqueda rápida para descubrir discrepancias objetivo. Alternativamente, un muestreo aleatorio de los datos en el archivo de envío de inicialización 310 y/o el archivo de envió 300 puede ser conducido. OLTP 140 entonces puede comparar los datos muestreados aleatoriamente en la base de datos local 200 y la base de datos remota 210. La lista de excepción 1140 puede corresponder a eventos perdidos, por ejemplo, adiciones (agregar), modificaciones (modificar), y eliminaciones (eliminar) a la base de datos local 200 que son inconsistentes con la base de datos remota 210. Por lo tanto, para identificar estos eventos candidato, OLTP 140 puede examinar las transacciones recientes comprometidas con la base de datos local 200. Generalmente, para cada transacción comprometida, se debe hacer una entrada, en un cuadro de registro almacenado la base de datos local 200. La entrada puede incluir el identificador del registro que fue cambiado, la transacción (o eventos) que cambiaron el registro (por ejemplo, un agregar, modificar y/o del evento), un número de secuencia de registro que indica la ordenación de la transacción, etc. Un cuadro de registro ilustrativo 1100 se muestra en la Figura 11. En este ejemplo, el archivo de envío 300 incluir transacciones 1108-1114, mostrados en el cuadro de registro 1100. La primera entrada 1101 muestra que, en la primera transacciones 1108, los datos (nombres de servidor) n1 y n2 fueron agregados a los datos (dominio) asociados con el identificador d1. Por lo tanto, el identificador es d1, elemento es "agregar" y el número de secuencia de registro es 11526. Similarmente, la segunda entrada 1102 indica que, en la segunda transacción 1109, los datos n8 y n9 fueron agregados a los datos asociados con el identificador d2. La tercera entrada 1103 indica que, en la tercera transacción 1110, los datos asociados con el identificador d3 fueron eliminados. La cuarta entrada 1104 indica que, en la cuarta transacción 1111, los datos asociados con el identificador d1 fueron modificados para agregar datos n5. Para la quinta transacción 1112, la quinta entrada 1105 indica que los datos n6 y n7 fueron agregados a los datos asociados con el identificador d3. Para la sexta transacción 1113, la sexta entrada 1106 indica que los datos asociados con el identificador d4 fueron modificados para remover los datos n3. La entrada Rava 1107, en la transacción Rava 1114, indica que los datos asociados con el identificador d5 fueron eliminados. Por consiguiente, como se muestra en Figura 10A, OLTP 140 puede asociar (1015) un identificador de evento con cada evento en la actualización, en donde el identificador del evento puede estar asociado con un identificador del registro. Cada evento en la actualización puede ser encontrado a partir un historial eventos. Un historial eventos, indexado y ordenado mediante identificador eventos puede ser generado partir del cuadro de registro 1100. Un historial de evento ilustrativo 1120 se muestra en la Figura 11. Aquí, la primera y cuarta entradas 1101, 1104 en el cuadro de registro 1100 indica cambios a los datos asociados con el identificador d1. Esta manera, el historial eventos 1120 incluyen el identificador d1 1121, y dos eventos 1126, "agregar" seguido por "modificar", realizados sobre los datos asociados con el identificador d1. La segunda entrada 1102 indica los cambios a los datos asociados con el identificador d2. Esta manera el historial eventos 1120 incluyen el identificador d2 1122 y un evento "agregar" 1127. El historial eventos 1120 incluye el identificador d3 1123 y dos eventos 1128, "eliminar" seguido por "modificar", indicativo de la tercera y quinta entradas 1103, 1105, las cuales incluyen cambios a los datos asociados con el identificador d3. La sexta entrada 1106 indica cambios a los datos asociados con el identificador d4. Por consiguiente el historial eventos 1120 incluye el identificador d4 1124 y un evento "modificar" 1129. La entrada Rava 1107 indica cambios a los datos asociados con el identificador d5 y un historial eventos 1120 incluye el identificador d5 1125 y un evento "eliminar" 1130. Los identificador es 1121-1125 están ordenados de d1 a d5.

Haciendo referencia otra vez a la Figura 10A, OLTP 140 puede determinar (1020) si la actualización es válida. Esta determinación puede ser realizada, de acuerdo con una modalidad de la Figura 10b. Primero OLTP 140 puede comparar (1022) los identificadores de evento 1121-1125 con los identificadores de excepción 1140 para determinar que identificadores corresponden. Por ejemplo, en la Figura 11, el identificador de evento d1 1121 en el identificador de historial 1120 corresponde a identificador de excepción d1 en la "Lista 2" de la lista de excepción 1140. Después de encontrar un evento correspondiente y una excepción, OLTP 140 puede determinar (1024) si el evento justifica la excepción. La justificación puede ser hecha como sigue. Para cada identificador de evento 1121-1125 en el historial de eventos 1120, OLTP 140 puede determinar si cada secuencia de eventos 1126-1130 en el historial de eventos 1120 es válida. Esto puede ser hecho, por ejemplo, examinando la lista de excepción 1140 para determinar a que tipo de excepción cada identificador de excepción pertenece, determinando cual debe ser una secuencia válida de eventos para ese tipo de excepción, y después buscando en el historial de eventos 1120 el identificador de evento correspondiente y la secuencia del identificador del evento de los eventos. Las secuencias válidas para cada tipo de excepción se detallarán más adelante. Si una secuencia de eventos 1126-1130 en el historial de eventos 1120 coincide con una secuencia válida, en entonces el identificador de evento correspondiente 1121-1125 tiene una secuencia válida. Es decir, la excepción asociada con el identificador de excepción puede ser justificada. Y, la transacción correspondiente 1108-1114 la cual incluye que el identificador del evento es uno legítimo y no erróneo. En este caso, OLTP 140 puede remover el identificador de excepción de la lista de excepción 1140. Una secuencia de eventos válida para la el tipo de excepción de la "Lista 1" puede ser (modificar)* (eliminada). Esta secuencia puede incluir una secuencia de cero o más eventos "modificar" seguida por un evento "eliminar" seguido de nada. El tipo de excepción de la "Lista 1" puede corresponder a los datos que pueden existir en la base de datos remota 210, pero no en la base de datos local 200. En este caso, los datos deben haber sido eliminados recientemente de la base de datos local 200 y la transacción aún no se escribe en el archivo de envío 300. Por lo tanto, el archivo de envío 300 puede aún no haber sido aplicado a la base de datos remota 210. Esto puede ser considerado como siendo una discrepancia legítima debido a que en algún punto del archivo de envío 300 se espera que sea generado y aplicado a la base de datos remota 210. Por lo que, si cualquiera de dichas secuencias 1126-1130 se encuentra en el historial de eventos 1120 para un identificador de excepción en la Lista 1 de la lista de excepción 1140, entonces la transacción correspondiente puede ser considerada válida. Por ejemplo, en la Figura 11, el identificador d5 1125 y sus datos asociados han sido eliminados de la base de datos local 200, como se muestra en la entrada Rava 1114 del cuadro de registro 1100 e indexado en el historial de eventos 1120. En el momento de la validación, d5 ha sido eliminado de la base de datos local 200, pero no de la base de datos remota 210. Por lo que, la lista de excepción 1140 incluye el identificador d5 en la Lista 1. De acuerdo con el historial de eventos 1120, el evento 1130 asociado con el identificador d5 1125 es "eliminar". OTLP 140 puede comparar la secuencia válida del tipo de excepción de la "Lista 1", es decir (modificar)*, contra el evento d5 1130 en el historial de eventos 1120. Ya que la secuencia válida de la "Lista 1" y el evento 1130 coinciden, la transacción de eliminación 1114 asociada el identificador d5 puede ser considerada como legítima y no un error. Por consiguiente, el identificador d5 pude ser removido de la lista de excepción 1140. Una secuencia válida de eventos para el tipo de excepción de la "Lista 2" puede ser (agregar). Esta secuencia puede incluir un evento "agregar" seguido de nada. El tipo de excepción de la "Lista 2" puede corresponder a los datos que existen en la base de datos local 200, pero no en la base de datos remota 210. En este caso, los datos puede haber sido recientemente agregados a la base de datos local 200 y la transacción aún no se escribe en el archivo de envío 300. Por lo tanto, el archivo de envío 300 puede aún no haber sido aplicado a la base de datos remota 210. Por lo que, los datos pueden no existir en la base de datos remota 210. Esto también puede ser considerado como siendo una discrepancia legítima debido a que en algún punto del archivo de envío 300 se espera que se genere y aplique a la base de datos remota 210. Por consiguiente, si cualquiera de dichas secuencias 1126-1130 se encuentra en el historial de eventos 1120 para un identif icador de excepción en la Lista 2 de la lista de excepción 1140, entonces la transacción correspondiente puede ser considerada válida. Haciendo referencia otra vez a la Figura 11, los identificadores d1 y d2 1121,1123 pueden estar asociados con los datos que fueron inicialmente agregados a la base de datos local 200, por ejemplo. Ya que sus secuencias de eventos 1126, 1127 empiezan con los eventos "agregar", los identificadores d1 y d2 1121, 1123 coinciden con las secuencias válidas para un tipo de excepción de la "Lista 2". Por consiguiente, las transacciones 1108, 1109 incluyendo estos identificadores pueden ser consideradas válidas y los identificadores d1 y d2 ser removidos de la lista de excepción 1140. Notar que el identif icador d3 1123 también incluye un evento "agregar" en su secuencia 1128. Sin embargo, el evento "agregar" no es el primero en la secuencia. Por consiguiente, la secuencia 1128 no califica como un tipo de la "Lista 2". Adicionalmente, ya que d3 no está designado en la Lista 2 de la lista de excepción 1140, OLTP 140 puede no verificarlo para la secuencia válida de la Lista 2. Las secuencias válidas de eventos para el tipo de excepción de la "Lista 3" pueden ser (eliminar) (agregar) o (modificar). Estas secuencias pueden incluir un evento "eliminar" seguido de nada. El tipo de excepción de la "Lista 3" corresponde a los datos que existen en ambas bases de datos 200, 210, pero es diferente. En este caso, los datos pueden haber sido recientemente modificados en la base de datos local 200 y la transacción aún no se escribe en el archivo de envío 300. Por lo tanto, el archivo de envío 300 puede aún no haber sido aplicado a la base de datos remota 210. Por lo que, los datos asociados con el identificador pueden aún no estar modificados en la base de datos remota 210. Otra vez, esto puede ser considerado como siendo una discrepancia legítima debido a que en algún punto el archivo de envío 300 se espera que sea generado y aplicado a la base de datos 210. Por consiguiente, si cualquiera de dichas secuencias 1126-1130 se encuentra en el historial de eventos 1120 para un identificador de excepción en la Lista 3 de la lista de excepción 1140, entonces la transacción correspondiente puede ser considerada válida. Por ejemplo, en la Figura 11, los identificadores d3 y d4 pueden estar asociados con los datos que fueron modificados en la base de datos 200. En el caso del identificador d3 1123, el identificador d3 1123 y sus datos fueron inicialmente eliminados y después vueltos agregar con nuevos datos, de tal manera que sus secuencias de eventos 1128 pueden incluir "eliminar" seguido de "agregar". En el caso del identificador d4 1124, los datos d4 fueron modificados para remover los datos, es decir su secuencia de eventos 1129 puede incluir "modificar". Ya que estas secuencias de eventos 1128, 1129 coinciden con las secuencias válidas para un tipo de excepción de la "Lista 3", sus transacciones correspondientes 1110, 1112, 1113 pueden ser consideradas válidas y los identificadores d3 y d4 removidos de la lista de excepción 1140. Haciendo referencia a la Figura 10B, si todas las excepciones indicadas a través de sus identificadores en la lista de excepción 1140 ha sido justificadas (1024) por los evento, es decir, si la lista de excepción 1140 está vacía, OLTP 140 puede designar (1026) el archivo de envío 300 o el archivo de envío de inicialización 310 como válido y notificar a LUE 100 que aplique el archivo de envío 300 o el archivo de envío de inicialización 310 a la base de datos remota 210. LUE 100 puede entonces aplicar el archivo de envío 300 o el archivo de envío de inicialización 310 a la base de datos remota 210. Por el contrario, si todas las excepciones no han sido justificadas (1024) por los eventos, es decir, si la lista de excepción 1140 no está vacía, entonces las excepciones restantes pueden indicar errores en el archivo de envío 300 o el archivo de envío de inicialización 310. Por consiguiente, OLTP 140 puede designar (1028) el archivo de envío 300 o el archivo de envío de inicialización 310 como inválido y registrar los errores en un archivo de error. En una modalidad alternativa, por ejemplo, si el archivo de envío 300 o el archivo de envío de inicialización 310 fue designado como inválido, después de un período predeterminado de tiempo, OLTP 140 puede repetir el proceso de validación sobre el archivo de envío 300 o el archivo de envío de inicialización 310 inválido para asegurar que las discrepancias son ciertamente errores. Este retraso predeterminado permite a la red más tiempo para transmitir cualesquiera archivos de envío 300, 310 lentos y las bases de datos 200, 210 más tiempo para volverse consistentes en lectura. En una modalidad de la presente invención, los datos en la base de datos remota 210 pueden "rezagar" los datos en la base de datos 200 a través de un período de tiempo significativo. Por consiguiente, con el fin de comparar las bases de datos 200, 210 y detectar errores, las bases de datos 200, 210 pueden ser hechas consistentes en lectura en el mismo punto en el tiempo de tal manera que son copias exactas una de la otra. Generalmente, la base de datos remota 210 puede ser recorrida hacia delante a la base de datos local 200, en donde los datos en la base de datos remota 210 pueden ser hechos esencialmente los mismos que los datos en la base de datos local 200. Por consiguiente, para acelerar la validación, cualquier archivo de envío de inicíalización generado actualmente 310 y archivos de envío subsecuentes 300 pueden ser aplicados a la base de datos remota 210 antes de iniciar la validación. Es decir, el número de discrepancias puede ser significativamente reducido. Este procesamiento de lotes de los archivos de envío 300, 310 puede ser referido como agrupación. El primero y el último de estos archivos de envío 300, 310 en la agrupación puede ser llamado marcas de agua baja y alta, respectivamente. La primera agrupación, llamada la agrupación inicial, puede incluir el archivo de envío de inicíalización 310. Todas las siguientes agrupaciones, llamadas agrupaciones terminales, pueden incluir solamente los archivos de envío 300. La agrupación puede proporcionar la validación de grupo en lugar de la validación en aislamiento. Por consiguiente, si un error es detectado en una agrupación, la agrupación completa puede ser designada como inválida, no solamente el archivo de envío 300 o el archivo de envío de inicialización 310 en donde ocurrió el error. Los mecanismos y métodos de las modalidades de la presente invención pueden ser implementados utilizando un microprocesador de propósito general programado de acuerdo con las enseñanzas de las modalidades. Las modalidades de la presente invención de esta manera incluyen un medio legible por máquina, el cual puede incluir instrucciones, las cuales pueden ser utilizadas para programar un procesador para realizar un método de acuerdo con las modalidades de la presente invención. Este medio puede incluir, pero no está limitado a, cualquier tipo de disco incluyendo disco flexible, disco óptico, y CD-ROMs. Varias modalidades de la presente invención son específicamente ilustradas y descritas aquí. Sin embargo, se apreciará que las modificaciones y variaciones de la presente invención están cubiertas por las enseñanzas anteriores y dentro del rango de las reivindicaciones anexas sin apartarse del espíritu y el alcance pretendido de la invención.

Claims

REIVINDICACIONES

1. Un método para validar una actualización de un registro en una base de datos remota a través de una red, la actualización incluye por lo menos un evento, que comprende: comparar el registro en la base de datos remota con un registro correspondiente en la base de datos local; generar una excepción que describe una discrepancia entre el registro de la base de datos remota y el registro de la base de datos local, para cada discrepancia; asociar un identificador de excepción con cada excepción, en donde cada identificador de excepción está asociado con un identificador del registro; asociar un identificador del evento con cada evento en la actualización, en donde cada identificador de evento está asociado con un identificador del registro; y determinar si la actualización es válida comparando los eventos y las excepciones que corresponden a este registro.

2. El método de acuerdo con la reivindicación 1, en donde la actualización del registro es válido si cada excepción correspondiente al registro está justificado a través de un evento correspondiente al registro.

3. El método de acuerdo con la reivindicación 2, en donde los tipos de excepciones incluyen: un primer tipo de excepción en el cual el registro está en la base de datos remota y no en la base de datos local; un segundo tipo de excepción en donde el registro está en la base de datos local y no en la base de datos remota; y un tercer tipo de excepción en donde el registro está en la base de datos local y la base de datos remota y un valor de un campo del registro en la base de datos local es diferente que el valor del mismo campo en el registro de la base de datos remota.

4. El método de acuerdo con la reivindicación 3, en donde el evento justifica la excepción si: el evento es una eliminación del registro de la base de datos local y la excepción es el primer tipo de excepción, el evento es una modificación del registro en la base de datos local y la excepción es el tercer tipo de excepción, o el evento es una eliminación seguida por una adición del registro en la base de datos local y la excepción en el tercer tipo de excepción.

5. El método de acuerdo con la reivindicación 1, que comprende además: repetir el método para validar la actualización de una cantidad de tiempo dada después de que la actualización se determinó como inválida, si la actualización se determina como siendo inválida.

6. El método de acuerdo con la reivindicación 1, en donde la comparación incluye: comparar la base de datos completa contra la base de datos remota completa.

7. Un método para validar una base de datos, que comprende: enviar a la base de datos una pluralidad de actualizaciones periódicas sobre cambios increméntales a una base de datos local, cada una de la pluralidad de actualizaciones periódicas tiene por lo menos una transacción; enviar a la base de datos remota una actualización de inicialización que incluye una versión de la base de datos como la base de datos local en el tiempo de inicio, en donde la actualización de inicialización se aplica a la base de datos remota; identificar las discrepancias entre la base de datos local y la base de datos remota; determinar si las discrepancias son válidas; y notificar a la base de datos remota para aplicar las actualizaciones periódicas que tienen un tipo de inicio posterior al tiempo de inicio de la actualización de inicialización.

8. El método de acuerdo con la reivindicación 7, que comprende además: repetir el método para validar la actualización en una cantidad dada de tiempo después de que la actualización se determinó como inválida, si la actualización se determina como siendo inválida.

9. El método de acuerdo con la reivindicación 7, en donde las discrepancias incluyen: un primer tipo de discrepancia en el cual un registro está en la base de datos remota y no en la base de datos local; un segundo tipo de discrepancia en donde el registro está en la base de datos local y no en la base de datos remota; y un tercer tipo de discrepancia en el cual el registro está en la base de datos local y en la base de datos remota y un valor de un campo del registro en la base de datos local es diferente del valor del mismo campo en el registro de la base de datos remota.

10. Un sistema para validar una actualización para un registro en una segunda base de datos remota a través de una red, en donde la actualización incluye por lo menos un evento, el sistema comprende: por lo menos un procesador acoplado a la red; y una memoria acoplada al procesador, la memoria incluye una base de datos e instrucciones adaptadas para ser ejecutadas mediante el procesador para implementar un método para validar la actualización del registro en la base de datos remota a través de la red, el método incluye: comparar el registro en la base de datos remota con un registro correspondiente en la base de datos local; generar una excepción que describe una discrepancia entre la base de datos remota y la base de datos local, para cada discrepancia, asociar un identificador de excepción con cada excepción, en donde cada identificador de excepción está asociado con un identificador del registro, asociar un identificador de evento con cada evento en la actualización, en donde cada identificador de evento está asociado con un identificador del registro, y determinar si la actualización es válida a través de la comparación con los eventos y excepciones que correspondan al registro.

11. El sistema de acuerdo con la reivindicación 10, en donde la actualización del registro es válida si cada excepción correspondiente al registro se justifica a través de un evento correspondiente al registro.

12. El sistema de acuerdo con la reivindicación 11, en donde los tipos de excepciones incluyen: un primer tipo de excepción en el cual el registro está en la base de datos remota y no en la base de datos local; un segundo tipo de excepción en el cual el registro está en la base de datos local y no en la base de datos remota; y un tercer tipo de excepción en el cual el registro está en la base de datos local y el base de datos remota y un valor de un campo del registro en la base de datos local es diferente del valor del mismo campo en la base de datos remota.

13. El sistema de acuerdo con la rei indicación 12, en donde el evento justifica la excepción si: el evento es una eliminación del registro de la base de datos local y la excepción es el primer tipo de excepción, el evento es una adición del registro a la base de datos local y la excepción es el segundo tipo de excepción, el evento es una modificación del registro en la base de datos local y la excepción es el tercer tipo de excepción, o el evento es una eliminación seguida por una adición del registro a la base de datos local y la excepción es el tercer tipo de excepción.

14. El sistema de acuerdo con la reivindicación 10, en donde si la actualización se determina como siendo inválida, el procesador repite el método para validar la actualización una cantidad de tiempo dada después de que la actualización se determinó como siendo inválida.

15. El sistema de acuerdo con la reivindicación 11, en donde el procesador compara la base de datos local completa contra la base de datos remota completa.

16. Un medio legible por máquina que incluye instrucciones de programa adaptadas para ser ejecutadas a través de un procesador para implementar un método para validar una actualización a un registro en una base de datos remota a través de una red, el método comprende: comparar el registro en la base de datos remota con un registro correspondiente en una base de datos local; generar una excepción que describe una discrepancia entre el registro de la base de datos remota y el registro de la base de datos local, para cada discrepancia; asociar un identificador de excepción con cada excepción, en donde cada identificador de excepción está asociado con un identificador del registro, asociar un identificador de evento con cada evento en la actualización, en donde cada identificador de evento está asociado con un identificador del registro; y determinar si la actualización es válida a través de la comparación con los eventos y excepciones que correspondan al registro.

17. El medio legible por máquina de acuerdo con la reivindicación 16, en donde, si la actualización se determina como siendo inválida, el procesador repite el método para validar la actualización en un cantidad de tiempo dada después de que la actualización fue determinada como siendo inválida.

18. El medio legible por máquina de acuerdo con la reivindicación 16, en donde la actualización del registro es válida si cada excepción correspondiente al registro se justifica a través de un evento correspondiente al registro.

19. El medio legible por máquina de acuerdo con la reivindicación 16, en donde los tipos de excepciones incluyen: un primer tipo de excepción en el cual el registro está en la base de datos remota y no en la base de datos local; un segundo tipo de excepción en el cual el registro está en la base de datos local y no en la base de datos remota; y un tercer tipo de excepción en el cual el registro está en la base de datos local y el base de datos remota y un valor de un campo en el registro en la base de datos local es diferente del valor del mismo campo en la base de datos remota.

20. Un método para validar una transmisión de datos a través de una red, que comprende: Identificar las discrepancias de datos entre una fuente y un destino; Identificar los cambios de datos en la fuente que fueron incluidos en la transmisión; y comparar las discrepancias con los cambios para determinar si la transmisión es válida.

21. El método de acuerdo con la reivindicación 20, en donde la fuente y el destino son servidores de nombre de dominio.

22. El método de acuerdo con la reivindicación 20, en donde las discrepancias incluyen: un nombre de dominio que está en la fuente y no en el destino; un nombre de dominio que está en el destino y no en la fuente; y los nombres de dominio correspondientes que son diferentes en la fuente y en el destino.

23. El método de acuerdo con la reivindicación 20, en donde los cambios incluyen por lo menos uno de la adición de un nombre de dominio a un servidor de nombre de dominio, eliminación de un nombre de dominio de un servidor de nombre de dominio, y modificación de un nombre de dominio en un servidor de nombre de dominio.

24. Un validador, que comprende: medios para identificar discrepancias de datos entre una fuente y un destino; medios para identificar cambios de datos en la fuente que fueron incluidos en la transmisión; y medios para comparar las discrepancias con los cambios para determinar si la transmisión es válida.

25. El sistema de acuerdo con la reivindicación 10, que comprende además: por lo menos un procesador remoto acoplado a la red; y una memoria remota acoplada al procesador remoto, la memoria remota almacena la base de datos remota e instrucciones adaptadas para ser ejecutadas mediante el procesador remoto para: crear un nuevo elemento basado en la nueva información recibida de la base de datos a través de la red; y sin restricción en el acceso de búsqueda a la base de datos remota, escribir un apuntador al nuevo elemento a la base de datos remota utilizando un operación ininterrumpible individual.

26. El sistema de acuerdo con la reivindicación 25, en donde las instrucciones además están adaptadas para: físicamente eliminar un elemento existente después de que el apuntador es escrito en la base de datos.

27. El sistema de acuerdo con la reivindicación 25, en donde la operación ininterrumpible individual es una instrucción de almacenamiento.

28. El sistema de acuerdo con la reivindicación 27, en donde el procesador remoto tiene un tamaño de palabra de por lo menos n bytes, la memoria remota tiene un ancho de por lo menos n bytes y la instrucción de almacenamiento escribe n bytes a una dirección de memoria remota localizada en un límite de n bytes.