SQL Server 2005 replicación

Question

Medio Ambiente: SQL Server 2005 SP2 (9.0.3077) publicaciones transaccionales (Producción y Beta)

Tengo una situación en la que tengo dos de la replicación Publicaciones diferentes que utilizan algunos de los mismos artículos . Cada una de estas publicaciones alimenta a un suscriptor en una máquina diferente. Uno de estos Artículos compartidos es una tabla. En un intervalo de tiempo regular, muchos de los registros de esta tabla envejecen y ya no son necesarios. En este momento se llama a un procedimiento almacenado que elimina registros.

Para ahorrar en recursos y mejorar los tiempos de latencia para los suscriptores, establecí la propiedad de replicación en este procedimiento almacenado en "Ejecución del procedimiento almacenado" en lugar de la predeterminada "Solo procedimiento almacenado". De esta forma, cuando el procedimiento almacenado borre más de 2,000,000 de registros, estos no se replicarán a los suscriptores. En su lugar, la ejecución del procedimiento almacenado se replica y se ejecuta el mismo procedimiento almacenado replicado en los suscriptores y elimina las mismas 2,000,000+ filas.

El problema que tengo es con mi segunda publicación. No necesitaba este tipo de comportamiento, así que dejé la propiedad del artículo en el procedimiento almacenado establecido en "Solo procedimiento almacenado" y esperaba que la replicación eliminara las filas del otro abonado, pero no fue así. La tabla en el suscriptor solo siguió ganando records. Entonces, para arreglarlo, establecí la propiedad del artículo en "Ejecución ..." y lo llamé bueno. Probablemente sea la mejor solución para que la versión beta coincida con la producción, pero todavía se siente como un obstáculo, ya que las propiedades de publicación deberían funcionar de forma independiente.

Pregunta: ¿Por qué la propiedad del artículo "Ejecución del procedimiento almacenado" tiene prioridad y se aplica a la otra publicación aunque esté configurada como "Definición del procedimiento almacenado solamente" en la otra publicación?

Answer 1

nos utilizar la replicación ampliamente en nuestra sociedad como lo hemos hecho 38 almacenes en varios países que se replican en nuestro servidor principal en Londres.

En primer lugar, sus filtros de replicación deben usar Vistas, incluso las simples. De esta forma, si necesita ajustar el filtro (lea la cláusula WHERE), solo necesita modificar la vista y lo hecho. De lo contrario, tiene que volver a publicar sus datos y volver a suscribir a todos los que pueden ser un verdadero dolor.

Mencionó que ejecuta la misma eliminación tanto en el suscriptor como en el editor para mantenerlos sincronizados. Esto envía escalofríos por mi columna vertebral. Es mucho mejor que los borre en un solo lugar y deje que el servidor replique a los suscriptores los cambios realizados. Desde SQL Server 2005, la replicación es muy rápida y eficiente ahora. SQL 2000 fue y es bastante lento para la replicación.Si usa SQL 2005/2008, solo asegúrese de que su nivel de compatibilidad (haga clic derecho en db, propiedades, opciones) esté configurado en 90 (2005) o 100 (2008). Esto cambia el servidor sql a los métodos de replicación rápidos y eficientes.

Otra forma es no borrar los datos, sino guardarlos y filtrarlos usando una cláusula where en la publicación.

Answer 2

Ha pasado mucho tiempo desde que administro activamente la replicación, pero sospecho que la respuesta tiene que ver con la arquitectura del lector de registro y que está compartiendo un artículo entre publicaciones. Según tengo entendido, el lector de registro rastrea el registro y busca operaciones en los elementos que se replican. Dependiendo de la configuración del artículo, los cambios individuales en los datos se pueden publicar en una tabla en la base de datos de distribución o se publicará un registro de la invocación del procedimiento. En cualquier caso, esta es una propiedad del artículo y no de la (s) publicación (es) de la que el artículo es miembro. Supongo (pero no he probado y verificado) que puedes crear varios artículos sobre el mismo objeto de base de datos y que uno se repita con @ type = 'logbased' y el otro con @ type = 'proc exec'

tome todo esto con una pizca de sal: a pesar de que ahora se desarrollan en SQL 2008, la última vez que lo hice nada con la replicación era SQL 7.

PJJH