Compartir a través de

Descargar el procesamiento por lotes

  • Artículo

Algunas aplicaciones requieren que se realicen en los datos operaciones de procesamiento intensivo por lotes. En muchos casos, estas operaciones por lotes no se pueden realizar en el servidor de procesamiento de transacciones en línea, porque la sobrecarga de procesamiento interfiere con otras operaciones del servidor. En este caso es necesario realizar el procesamiento por lotes en un servidor independiente. En algunos casos, el procesamiento por lotes simplemente se descarga; en otros, los resultados del proceso por lotes se propagan de nuevo al servidor de procesamiento en línea.

En el siguiente diagrama se muestra una situación típica con datos que se replican en un servidor de procesamiento por lotes:

Replicar datos para procesar lotes

Ejemplo de Adventure Works Cycles

Adventure Works Cycles es una compañía ficticia que se utiliza para mostrar situaciones y conceptos de bases de datos. Para obtener más información, vea Ejemplos y bases de datos de ejemplo.

Adventure Works Cycles utiliza al procesamiento por lotes para comprobar si hay fraudes con tarjeta de crédito en su sitio Web. Los datos recopilados de las transacciones en el sitio Web se replican desde el servidor Microsoft SQL Server que da servicio al sitio Web en un servidor SQL Server independiente que se utiliza para una serie de aplicaciones de Adventure Works Cycles. En el servidor de procesamiento por lotes, los datos se comprueban en busca de patrones de fraude con tarjetas de crédito. Aunque la detección del fraude produce una pequeña cantidad de datos (datos de actualización en un pequeño número de columnas si una cuenta muestra actividad sospechosa), las comprobaciones realizan una actividad intensiva de cálculo y requieren considerables recursos de servidor. Una vez que se ejecuta el proceso por lotes, se envía de nuevo al servidor OLTP del sitio Web una pequeña cantidad de datos que indican las cuentas que muestran posibles indicios de fraude.

Requisitos habituales en este escenario

Las aplicaciones de procesamiento por lotes suelen tener los siguientes requisitos, que una solución de réplica adecuada debe satisfacer:

  • El sistema debe mantener la coherencia transaccional.
  • El sistema debe tener una latencia baja: las actualizaciones en el servidor de procesamiento por lotes deben llegar al servidor de procesamiento por lotes con rapidez.
  • El sistema debe tener un rendimiento alto: debe controlar la réplica de un gran número de transacciones.
  • El proceso de réplica debe producir una sobrecarga mínima en el servidor de procesamiento en línea.
  • Los cambios de datos pueden fluir en ambas direcciones: los resultados del procesamiento por lotes pueden propagarse de nuevo al servidor de procesamiento en línea.
  • Los datos requeridos en el servidor de procesamiento por lotes pueden ser un subconjunto de los datos disponibles en el servidor de procesamiento en línea.

Tipo de réplica que se debe utilizar en este escenario

SQL Server utiliza una metáfora del sector editorial para describir los componentes del sistema de réplica. Los componentes incluyen el publicador, los suscriptores, las publicaciones y artículos, y las suscripciones.

  • En el primer diagrama anterior, el servidor de procesamiento en línea es el publicador. Algunos o todos los datos del servidor de procesamiento en línea se incluyen en la publicación, donde cada tabla de datos es un artículo (los artículos también pueden ser otros objetos de la base de datos, como procedimientos almacenados). El servidor de procesamiento por lotes es un suscriptor de la publicación que recibe esquemas y datos como suscripción.
  • Si los resultados se propagan de nuevo al servidor de procesamiento en línea, el servidor de procesamiento por lotes es también un publicador (normalmente con una publicación idéntica a la del servidor de procesamiento en línea), y el servidor de procesamiento en línea se suscribe a dicha publicación.

Para obtener más información acerca de los componentes del sistema, vea Información general del modelo de publicación de réplica.

SQL Server ofrece diferentes tipos de réplica para distintos requisitos de aplicación: réplica de instantáneas, réplica transaccional y réplica de mezcla. La mejor implementación para este escenario es la réplica transaccional, que se adapta perfectamente para controlar los requisitos indicados en la sección anterior. Para obtener más información sobre la réplica transaccional, vea Información general de la réplica transaccional y Cómo funciona la réplica transaccional.

Por diseño, la réplica transaccional satisface los requisitos principales de este escenario:

  • Coherencia transaccional
  • Latencia baja
  • Rendimiento alto
  • Sobrecarga mínima

Las opciones que se deben considerar en este caso son el filtrado, la réplica transaccional de punto a punto y la réplica transaccional bidireccional:

Pasos para implementar esta situación

Para implementar esta situación, es preciso crear en primer lugar una publicación y suscripciones, y a continuación inicializar cada suscripción. Haga clic en los vínculos siguientes para obtener más información acerca de cada paso:

Cuando la suscripción se haya inicializado y los datos fluyan entre el publicador y los suscriptores, es posible que necesite consultar los siguientes temas para obtener información sobre tareas habituales de administración y supervisión:

Vea también

Otros recursos

Replicar datos en un entorno de servidor a servidor

Ayuda e información

Obtener ayuda sobre SQL Server 2005