Logshipping Como alta disponibilidad.

¿y si los usuarios conectados a la BBDD del Log shipping modifican los
datos? Al restaurar el siguiente "paquete" se perderá la coherencia de la
misma ¿no?

A otra cosa. He visto que en el caso del Mirroring podemos almacenar el
nombre de los dos servidores en el Proveedor de conexión a la BBDD. ¿Puedo
utilizar la misma técnica para la conmutación por Error (manual) en el Log
shipping? o por el contrario, tengo que cambiar la conf de los usuarios para
que se conecten al servidor Secundario?

Un saludo


"Miguel Egea" escribió en el mensaje
news:

No es del todo así en ninguno de los dos casos.

En log shipping puedes establecer la recuperación como standby mode, y
entonces eliges entre dos alternativas a la hora de hacer el restore,
desconectar a los usuarios que estén o hacer que no se haga el restore,
ninguna de las dos alternativas es del todo buena, pero es lo que hay.

En mirroring por contra no se puede en absoluto, pero si si lo combinas
con Database Snapshot, puedes crearte un snapshot de una BBDD y entonces
consultar el snapshot, es una fotografía en un momento dado, vamos
indicada para informes.

Saludos
Miguel Egea

"Miguel" escribió en el mensaje
news:%

Me autocontesto y corregirme si me equivoco. Sí puedo realizar lecturas
en el caso del Log shipping (por tratarse de un procedimiento simple en
el que se restauran datos del log de transacciones) y "creo" que no en el
caso del Mirroring (supongo que por la propia naturaleza de la solución)

Y (sigo pensando en alto), si a alguien con acceso a la BBDD secundaria
del Log Shipping se le da por modificar los datos obviamente pierdo
la consistencia de la misma... ¿o esto no es posible?

Q lio.

Gracias.

"Miguel" escribió en el mensaje
news:

Genial... Ya me queda más claro. He visto las 2 opciones y ahora solo me
queda una duda. ¿es posible utilizar las BBDD de respaldo (tanto en el
caso de log como de Mirror) para explotación de datos (lectura)? O por
el contrario está vedado el acceso a estas BBDD secudarias?

Gracias por todo

Un saludo

"Miguel Egea" escribió en el mensaje
news:

Se basa en backups y restores, debe haber un principal pueden haber
tnatos secundarios como quieras. El proceso de failover es manual y
depende un poco de que sea lo que ha fallado. Puede suponer la pérdida
de la información introducida desde el último backup que se haya
copiado al secundario.

En resumen es una solución de alta disponibilidad que tiene puntos de
fallo y que necesita failover manual

Tienes una alternativa adicional que es Database Mirroring, repasalo en
los librosen pantalla y si tienes alguna duda, nos preguntas.

Saludos
Miguel Egea

"Miguel" escribió en el mensaje
news:%

Hola a todos.

Se trata de SQL Server 2005 y tengo que ofertar una solución en alta
disponibilidad sin puntos de falla. (A parte de la solución de
cluster) veo que la de Logshipping es una alternativa, pero no sé como
sería el funcionamiento en caso de caída del servidor principal. ¿Como
se conmutan los servidores? ¿es un proceso manual? ¿Que implica? Es
realmente una alternativa de alta disponibilidad?

Gracias anticipadas por vuestras aportaciones.

Un saludo.

Te contesto in-line
"Miguel" escribió en el mensaje
news:

¿y si los usuarios conectados a la BBDD del Log shipping modifican los
datos? Al restaurar el siguiente "paquete" se perderá la coherencia de la
misma ¿no?

No en absoluto las transacciones confirmadas se les hace rollforward, se
aplican las pendientes ni se confirma ni se borran permanecen en "standby"
hasta que se decida restaurar definitivamente,

A otra cosa. He visto que en el caso del Mirroring podemos almacenar el
nombre de los dos servidores en el Proveedor de conexión a la BBDD. ¿Puedo
utilizar la misma técnica para la conmutación por Error (manual) en el
Log shipping? o por el contrario, tengo que cambiar la conf de los
usuarios para que se conecten al servidor Secundario?

No existe la c´lausula failover partner en Log shipping, pero es "facil" de
implementar dos cadenas de conexión y usar un try catch...

Saludos
Miguel Egea

Un saludo


"Miguel Egea" escribió en el mensaje
news:

No es del todo así en ninguno de los dos casos.

En log shipping puedes establecer la recuperación como standby mode, y
entonces eliges entre dos alternativas a la hora de hacer el restore,
desconectar a los usuarios que estén o hacer que no se haga el restore,
ninguna de las dos alternativas es del todo buena, pero es lo que hay.

En mirroring por contra no se puede en absoluto, pero si si lo combinas
con Database Snapshot, puedes crearte un snapshot de una BBDD y entonces
consultar el snapshot, es una fotografía en un momento dado, vamos
indicada para informes.

Saludos
Miguel Egea

"Miguel" escribió en el mensaje
news:%

Me autocontesto y corregirme si me equivoco. Sí puedo realizar lecturas
en el caso del Log shipping (por tratarse de un procedimiento simple en
el que se restauran datos del log de transacciones) y "creo" que no en
el caso del Mirroring (supongo que por la propia naturaleza de la
solución)

Y (sigo pensando en alto), si a alguien con acceso a la BBDD secundaria
del Log Shipping se le da por modificar los datos obviamente pierdo
la consistencia de la misma... ¿o esto no es posible?

Q lio.

Gracias.

"Miguel" escribió en el mensaje
news:

Genial... Ya me queda más claro. He visto las 2 opciones y ahora solo
me queda una duda. ¿es posible utilizar las BBDD de respaldo (tanto en
el caso de log como de Mirror) para explotación de datos (lectura)? O
por el contrario está vedado el acceso a estas BBDD secudarias?

Gracias por todo

Un saludo

"Miguel Egea" escribió en el mensaje
news:

Se basa en backups y restores, debe haber un principal pueden haber
tnatos secundarios como quieras. El proceso de failover es manual y
depende un poco de que sea lo que ha fallado. Puede suponer la pérdida
de la información introducida desde el último backup que se haya
copiado al secundario.

En resumen es una solución de alta disponibilidad que tiene puntos de
fallo y que necesita failover manual

Tienes una alternativa adicional que es Database Mirroring, repasalo
en los librosen pantalla y si tienes alguna duda, nos preguntas.

Saludos
Miguel Egea

"Miguel" escribió en el mensaje
news:%

Hola a todos.

Se trata de SQL Server 2005 y tengo que ofertar una solución en alta
disponibilidad sin puntos de falla. (A parte de la solución de
cluster) veo que la de Logshipping es una alternativa, pero no sé
como sería el funcionamiento en caso de caída del servidor principal.
¿Como se conmutan los servidores? ¿es un proceso manual? ¿Que
implica? Es realmente una alternativa de alta disponibilidad?

Gracias anticipadas por vuestras aportaciones.

Un saludo.