Replicacion y tablas vacías

11/12/2008 - 19:37 por Federico A. Colli | Informe spam
Hola gente.
Bien, tengo un problema que supongo se debe a la replicación de datos de SQL
Server y quería ver opciones para tomar una solución.
El esquema de replicación es el siguiente:
- SQL Server 2000 replicando una base de datos (1 servidor)
- SQL Server 2005 Express suscritas a la replicación anterior (n servidores)
- red Lan
- Aplicación de ventas en cada cliente donde utilizan su propia base en SQLS
erver 2005

La idea de la replicación es quitar carga al server principal y mantener
actualizados los datos de cada cliente.
El punto de error que yo estimo puede a causa de la replicación (ojo, no
digo que sea error de la replicación), es que es posible que cuando se lee
cierta tabla esta esté justo replicando y no posea datos (lo verificamos a
nivel de consultas y esto si pasa), con lo cual tenemos un "error" en la
carga de dichos datos y se supone que no existen.
Con esto estoy buscando una alternativa o condición donde se pueda verificar
(si es que existe) que cierto artículo este en un estado X (por ejemplo
replicando), en cuyo caso optamos por cierta solución.
Una solución provisoria es determinar con una simple consulta si hay
registros (con cierta condición) en la tabla del servidor principal (2000),
y en caso de que en la base local no se dispongan se esté justo en un
proceso de replicación. El problema es que ya necesitamos acceder al
servidor principal y queremos evitar total comunicación más de la debida,
por lo cual busco si se puede conocer mediante SP de sistemas u otra opción
el estado de dicho artículo en determinado momento.

Si se les ocurre otra alternativa es bienvenida.

Saludos y gracias.
AUS Federico A. Colli

Preguntas similare

Leer las respuestas

#1 Rubén Garrigós
12/12/2008 - 15:31 | Informe spam
Hola Federico,

No me queda muy claro el esquema de replicación que estais utilizando para
mantener los datos replicados. ¿Que tipo de replicación estais utilizando?
(Snapshot, Transaccional, Mezcla, etc.)

En caso de estar aplicando snapshots si sería posible, si no te he entendido
mal, que ocurriera un vaciado de la tabla completa en los suscriptores
previa aplicación del snapshot.

Un saludo,

Rubén Garrigós
Solid Quality Mentors

"Federico A. Colli" wrote in message
news:ehkSC%
Hola gente.
Bien, tengo un problema que supongo se debe a la replicación de datos de
SQL Server y quería ver opciones para tomar una solución.
El esquema de replicación es el siguiente:
- SQL Server 2000 replicando una base de datos (1 servidor)
- SQL Server 2005 Express suscritas a la replicación anterior (n
servidores)
- red Lan
- Aplicación de ventas en cada cliente donde utilizan su propia base en
SQLS erver 2005

La idea de la replicación es quitar carga al server principal y mantener
actualizados los datos de cada cliente.
El punto de error que yo estimo puede a causa de la replicación (ojo, no
digo que sea error de la replicación), es que es posible que cuando se lee
cierta tabla esta esté justo replicando y no posea datos (lo verificamos a
nivel de consultas y esto si pasa), con lo cual tenemos un "error" en la
carga de dichos datos y se supone que no existen.
Con esto estoy buscando una alternativa o condición donde se pueda
verificar (si es que existe) que cierto artículo este en un estado X (por
ejemplo replicando), en cuyo caso optamos por cierta solución.
Una solución provisoria es determinar con una simple consulta si hay
registros (con cierta condición) en la tabla del servidor principal
(2000), y en caso de que en la base local no se dispongan se esté justo en
un proceso de replicación. El problema es que ya necesitamos acceder al
servidor principal y queremos evitar total comunicación más de la debida,
por lo cual busco si se puede conocer mediante SP de sistemas u otra
opción el estado de dicho artículo en determinado momento.

Si se les ocurre otra alternativa es bienvenida.

Saludos y gracias.
AUS Federico A. Colli
Respuesta Responder a este mensaje
#2 Federico A. Colli
15/12/2008 - 13:53 | Informe spam
Exacto es del tipo Snapshot. La realidad es que los cambios en las tablas no
son en todo momento, por lo menos los maestro de datos que son los que
replican.

AUS Federico A. Colli

"Rubén Garrigós" escribió en el mensaje de
noticias:
Hola Federico,

No me queda muy claro el esquema de replicación que estais utilizando para
mantener los datos replicados. ¿Que tipo de replicación estais utilizando?
(Snapshot, Transaccional, Mezcla, etc.)

En caso de estar aplicando snapshots si sería posible, si no te he
entendido mal, que ocurriera un vaciado de la tabla completa en los
suscriptores previa aplicación del snapshot.

Un saludo,

Rubén Garrigós
Solid Quality Mentors

"Federico A. Colli" wrote in message
news:ehkSC%
Hola gente.
Bien, tengo un problema que supongo se debe a la replicación de datos de
SQL Server y quería ver opciones para tomar una solución.
El esquema de replicación es el siguiente:
- SQL Server 2000 replicando una base de datos (1 servidor)
- SQL Server 2005 Express suscritas a la replicación anterior (n
servidores)
- red Lan
- Aplicación de ventas en cada cliente donde utilizan su propia base en
SQLS erver 2005

La idea de la replicación es quitar carga al server principal y mantener
actualizados los datos de cada cliente.
El punto de error que yo estimo puede a causa de la replicación (ojo, no
digo que sea error de la replicación), es que es posible que cuando se
lee cierta tabla esta esté justo replicando y no posea datos (lo
verificamos a nivel de consultas y esto si pasa), con lo cual tenemos un
"error" en la carga de dichos datos y se supone que no existen.
Con esto estoy buscando una alternativa o condición donde se pueda
verificar (si es que existe) que cierto artículo este en un estado X (por
ejemplo replicando), en cuyo caso optamos por cierta solución.
Una solución provisoria es determinar con una simple consulta si hay
registros (con cierta condición) en la tabla del servidor principal
(2000), y en caso de que en la base local no se dispongan se esté justo
en un proceso de replicación. El problema es que ya necesitamos acceder
al servidor principal y queremos evitar total comunicación más de la
debida, por lo cual busco si se puede conocer mediante SP de sistemas u
otra opción el estado de dicho artículo en determinado momento.

Si se les ocurre otra alternativa es bienvenida.

Saludos y gracias.
AUS Federico A. Colli



Respuesta Responder a este mensaje
#3 Rubén Garrigós
15/12/2008 - 19:05 | Informe spam
Hola Federino,

El funcionamiento de la réplica Snapshot implica un vaciado de las tablas de
los suscriptores. Durante ese periodo no dispondrás de acceso a los datos o
te aparecerán las tablas vacías, depende del nivel de aislamiento que
utilicen tus consultas. Si necesitas mantener la tabla disponible en todo
momento quizás te convendría evaluar una replicación transaccional la cual,
una vez aplicado un snapshot, va enviando los cambios que se produzcan en el
publicador a los suscriptores de forma asíncrona pero continua evitando así
tener nunca las tablas vacías.

Rubén Garrigós
Solid Quality Mentors

"Federico A. Colli" wrote in message
news:
Exacto es del tipo Snapshot. La realidad es que los cambios en las tablas
no son en todo momento, por lo menos los maestro de datos que son los que
replican.

AUS Federico A. Colli

"Rubén Garrigós" escribió en el mensaje de
noticias:
Hola Federico,

No me queda muy claro el esquema de replicación que estais utilizando
para mantener los datos replicados. ¿Que tipo de replicación estais
utilizando? (Snapshot, Transaccional, Mezcla, etc.)

En caso de estar aplicando snapshots si sería posible, si no te he
entendido mal, que ocurriera un vaciado de la tabla completa en los
suscriptores previa aplicación del snapshot.

Un saludo,

Rubén Garrigós
Solid Quality Mentors

"Federico A. Colli" wrote in message
news:ehkSC%
Hola gente.
Bien, tengo un problema que supongo se debe a la replicación de datos de
SQL Server y quería ver opciones para tomar una solución.
El esquema de replicación es el siguiente:
- SQL Server 2000 replicando una base de datos (1 servidor)
- SQL Server 2005 Express suscritas a la replicación anterior (n
servidores)
- red Lan
- Aplicación de ventas en cada cliente donde utilizan su propia base en
SQLS erver 2005

La idea de la replicación es quitar carga al server principal y mantener
actualizados los datos de cada cliente.
El punto de error que yo estimo puede a causa de la replicación (ojo, no
digo que sea error de la replicación), es que es posible que cuando se
lee cierta tabla esta esté justo replicando y no posea datos (lo
verificamos a nivel de consultas y esto si pasa), con lo cual tenemos un
"error" en la carga de dichos datos y se supone que no existen.
Con esto estoy buscando una alternativa o condición donde se pueda
verificar (si es que existe) que cierto artículo este en un estado X
(por ejemplo replicando), en cuyo caso optamos por cierta solución.
Una solución provisoria es determinar con una simple consulta si hay
registros (con cierta condición) en la tabla del servidor principal
(2000), y en caso de que en la base local no se dispongan se esté justo
en un proceso de replicación. El problema es que ya necesitamos acceder
al servidor principal y queremos evitar total comunicación más de la
debida, por lo cual busco si se puede conocer mediante SP de sistemas u
otra opción el estado de dicho artículo en determinado momento.

Si se les ocurre otra alternativa es bienvenida.

Saludos y gracias.
AUS Federico A. Colli



Respuesta Responder a este mensaje
#4 Federico A. Colli
18/12/2008 - 18:42 | Informe spam
Gracias calculaba que venía por ese lado.

Sludos
AUS Federico A. Colli

"Rubén Garrigós" escribió en el mensaje de
noticias:
Hola Federino,

El funcionamiento de la réplica Snapshot implica un vaciado de las tablas
de los suscriptores. Durante ese periodo no dispondrás de acceso a los
datos o te aparecerán las tablas vacías, depende del nivel de aislamiento
que utilicen tus consultas. Si necesitas mantener la tabla disponible en
todo momento quizás te convendría evaluar una replicación transaccional la
cual, una vez aplicado un snapshot, va enviando los cambios que se
produzcan en el publicador a los suscriptores de forma asíncrona pero
continua evitando así tener nunca las tablas vacías.

Rubén Garrigós
Solid Quality Mentors

"Federico A. Colli" wrote in message
news:
Exacto es del tipo Snapshot. La realidad es que los cambios en las tablas
no son en todo momento, por lo menos los maestro de datos que son los que
replican.

AUS Federico A. Colli

"Rubén Garrigós" escribió en el mensaje de
noticias:
Hola Federico,

No me queda muy claro el esquema de replicación que estais utilizando
para mantener los datos replicados. ¿Que tipo de replicación estais
utilizando? (Snapshot, Transaccional, Mezcla, etc.)

En caso de estar aplicando snapshots si sería posible, si no te he
entendido mal, que ocurriera un vaciado de la tabla completa en los
suscriptores previa aplicación del snapshot.

Un saludo,

Rubén Garrigós
Solid Quality Mentors

"Federico A. Colli" wrote in message
news:ehkSC%
Hola gente.
Bien, tengo un problema que supongo se debe a la replicación de datos
de SQL Server y quería ver opciones para tomar una solución.
El esquema de replicación es el siguiente:
- SQL Server 2000 replicando una base de datos (1 servidor)
- SQL Server 2005 Express suscritas a la replicación anterior (n
servidores)
- red Lan
- Aplicación de ventas en cada cliente donde utilizan su propia base en
SQLS erver 2005

La idea de la replicación es quitar carga al server principal y
mantener actualizados los datos de cada cliente.
El punto de error que yo estimo puede a causa de la replicación (ojo,
no digo que sea error de la replicación), es que es posible que cuando
se lee cierta tabla esta esté justo replicando y no posea datos (lo
verificamos a nivel de consultas y esto si pasa), con lo cual tenemos
un "error" en la carga de dichos datos y se supone que no existen.
Con esto estoy buscando una alternativa o condición donde se pueda
verificar (si es que existe) que cierto artículo este en un estado X
(por ejemplo replicando), en cuyo caso optamos por cierta solución.
Una solución provisoria es determinar con una simple consulta si hay
registros (con cierta condición) en la tabla del servidor principal
(2000), y en caso de que en la base local no se dispongan se esté justo
en un proceso de replicación. El problema es que ya necesitamos acceder
al servidor principal y queremos evitar total comunicación más de la
debida, por lo cual busco si se puede conocer mediante SP de sistemas u
otra opción el estado de dicho artículo en determinado momento.

Si se les ocurre otra alternativa es bienvenida.

Saludos y gracias.
AUS Federico A. Colli








email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida