Logshipping Como alta disponibilidad.

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.

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.

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.

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.

Gracias... creo que ya me hago una buena idea.

Un saludo y buen finde a todos.

"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.