Astumaiden - 29/12/2010 (UTC)
Hola , antes que todo, quiero felicitarte por el gran aporte que haces a todos los de nuestra área con resolver inquietudes y exponer material de gran importancia. Soy nuevo en esta web y me inscribí, precisamente por su contenido.

Tengo algunas dudas y me gustaría que me pudieras ayudar. Mi tema, ALTA DISPONIBILIDAD PARA SQL (MIRRORING).

He estado investigando opciónes y creo que mirroring es la que mas se adecua a lo que necesito hacer. Te comento que es:

Tengo 1 servidor con WINDOWS 2008 SERVER ENTERPRISE que corre una BD con SQL SERVER 2008 Enterprice. A ese servidor se conectan 300 clientes diariamente a cualquier hora, el problema está, si se me ce tal servidor, queda la graaande. Es por esto, que he optado por tener un sistema con ALTA DISPONIBILIDAD. (no quiero virtualizar, ni tener un storage aparte).

1) ¿Como lo hago?, ¿Mirroring es la mejor opción?
2) Frente a lo que tu tienes, es posible que expongas los pasos a realizar detalladamente tanto en windows y en SQL?
3) Los pasos de instalacion de que debe ir tanto en los 2 servidores y en el witness.
4) Es necesario crear un clúster antes de isntalar SQL??

Sinceramente, espero que puedas ayudarme ya que estoy contra el tiempo.


Mis cordiales saludos.

GuilleSQL - 30/12/2010 (UTC)
Hola,

Las principales dos opciones que tienes son Mirroring o Clustering. Quizás te pueda resultar de mayor interés el Clustering. Intento hacerte un resumen, ya que ambos temas dan para escribir libros.

1) Mirroring. Se configura a nivel de cada BBDD por separado. Problema: las aplicaciones no suelen estar preparadas => si se cae la máquina que actúa como Principal del Mirror (ej: ServerA), el Secundario del Mirror (ej: ServerB) empieza a actuar como Principal dando servicio, pero las aplicaciones podrían seguir conectadas al ServerA (pérdida de servicio aun con las BBDD OK y sin pérdida de datos). No requiere almacenamiento compartido, pero se duplicará el Almacenamiento (Principal y Secundario, ambos almacenarán una copia de las BBDD configuradas en Mirror).
2) Clustering. Se configura a nivel de Instancia, y es transparente para las aplicaciones. Requiere de almacenamiento compartido, pero no se duplica información (como ocurre con Mirroring).

El único entorno que conozco con Database Mirroring, está configurado así para MOSS 2007 en un entorno con CPDs distribuidos geográficamente. El problema: MOSS 2007 no está soportado por Microsoft para utilizar SQL Server sobre un Cluster Geográfico (dos nodos en ubicaciones separadas, con cabinas de discos separadas que replican sus datos de forma síncrona o asíncrona). Si no fuera por esto, no estaríamos usando Database Mirroring, y usaríamos Clustering.

Te puedes encontrar con más cosillas, como por ejemplo, que el Software de Backup (ej: Veritas) o la Monitorización tampoco sepa trabajar con Database Mirroring.

Espero haberte podido orientar con estas líneas.

Saludos !

Javifdo - 10/08/2011 (UTC)
Buenas Noches
Actualmente tengo una Base de Datos en modo Mirroring SQLServer2008R2, replicando en otro servidor(destino). La Base principal(origen) genera mucha transaccionalidad y el log de transacciones crece demasiado rápido hasta llenar un disco de 500 GB.
Mi pregunta es como hago para truncar el archivo log de transacciones, en las Bases de datos origen y destino cuando estas se encuentran en estado Mirroring, SIN tener que deshacer, desbaratar toda la configuración del mirror para poderlo truncar. Este archivo no se deja truncar cuando está en mirror y termina por llenar el disco y por consiguiente tumba la Base de Datos.
Muchas gracias

GuilleSQL - 10/08/2011 (UTC)
Hola Javifdo,

A priori, se me ocurre realizar un Backup de LOG previo al SHRINK de los ficheros de LOG. Esto debería marcar las páginas utilizadas del LOG (y de las que se ha realizado Backup) como reutilizables, evitando el crecimiento de los ficheros de LOG.

También podría resultar necesario, realizar los Backups de LOG con mayor frecuencia.

Con esto debería ser sufiente, pero también es cierto que hay casos que podrían dar guerra. Por ejemplo, si al hacer el Backup de LOG, existe una transacción abierta que está escribiendo sobre la última página del fichero de LOG, no podrás reducir el tamaño de LOG... será necesario que finalice dicha transacción y realizar un nuevo Backup de LOG.

Saludos,
Guille

Mocana - 04/02/2013 (UTC)
Hola
Tengo un entorno configurado con mirroring sin testigo. Debido al crecimiento de la informacion se decidio aumentar otro disco a los servidores, principal y mirror. En este disco se va a colocar el archivo de log, para darle mayor capacidad. La consulta es la siguiente, para mover mi archivo de log al nuevo disco, es necesario desconfigurar el mirroring, o puedo hacerlo de alguna forma sin tener que reconfigurarlo.
Saludos y gracias

edgard - 11/06/2015 (UTC)
Hola Guille... 2 dudas
En SQLS 2012 hay una forma de acceder al mirror en solo lectura estando activa la Primary?....es decir leer de ambas a la vez...

Y otra : que desvnetajas sino uso la testigo?

dudas ambas de SQL2012


gracias