Una vez instaladas las correspondientes actualizaciones de SQL, para verificar el correcto funcionamiento de nuestro montaje, accederemos mediante la consola de SQL Management Studio al nombre que le hemos asignado al cluster de SQL, en mi caso: clu-sql
Durante la instalación no hemos cambiado el path de los logs de SQL, así que los cambiaremos ahora de la siguiente manera:
También aprovecharemos para ajustar la memoria de nuestro sistema de SQL, ya que sino cuando nuestro servidor esté en plena producción, el SQL se comerá toda la memoria que dispone el sistema operativo y esto nos puede ocasionar problemas. Yo normalmente de le dejo varias Gigas de Ram para el sistema operativo. Por ejemplo: si nuestro sistema operativo tiene 70GB, yo le dejaría 6GB libres al sistema operativo, eso quiere decir que le hemos de asignar 64GB (65536) a nuestro SQL:
Al haberle ajustado la RAM a nuestro servidor de SQL, corremos el riesgo de que cuando necesite más Ram el equipo nos pagine. Para evitar esto, le indicaremos a la cuenta encargada de arrancar los servicios del SQL que no puede usar la paginación. Este procedimiento lo hemos de realizar en los dos servidores de SQL:
Una de las cosas a tener muy en cuenta, es tanto el sistema de backups como la integridad de la base de datos. Para realizar estas dos tareas, crearemos un nuevo plan de mantenimiento.
Le pondremos un nombre descriptivo
Le indicaremos la periodicidad en el que se ejecutará nuestro plan de mantenimiento:
Acercaremos el ratón a la opción toolbox:
Y crearemos un “Check Database Integrity Task”, para que nos chequee la integridad de las bases de datos y posteriormente un “backup Database Task”, para poder realizar los backups de las bases de datos. Configuraremos el “Check Database Integrity Task”, para que realice un chequeo de todas las bases de datos con excepción de las creadas por el propio sistema:
Y configuraremos el sistema de backups. Yo lo he copiado en el disco duro del clúster, pero es más adecuado llevárselo fuera del sistema clusterizado.
Una vez acabado, lo grabaremos:
No os perdáis el resto de entradas sobre este Cluster de SQL:
Hola Oscar,
Con esas reservas de ram si el sistema tiene que paginar igualmente se va a caer, pero algún Driver habrá por ahí que se coma esos 20 GB del sistema operativo!.
Saludos
Hola Pep,
No entiendo muy bien tu pregunta ya que como indico, el sistema operativo tiene 70GB de RAM y los 20GB es el mínimo que se le va a asignar al MSSQL. Si te fijas, le dejo 6GB de RAM al sistema operativo para que funcione con fluidez. Aún así, estos son valores de ejemplo que puedes variar y ajustar en función de tus necesidades.
Aparte de esta aclaración, el sistema de MSSQL no puede paginar ya que le asigno una política local (puede ser de domininio mediante el GPMC) al usuario que gestiona el servicio del MSSQL, la cual consiste en que no pagine. De esta manera usará la memória del sistema y nuestro rendimeinto no caerá.
Igualmente esta configuración la tengo en producción con más de 10 servidores MSSQL y funciona de maravilla. Ni te quiero contar los problemas que tenía antes de implementarla.
Un saludo
He leido 20 reservados para el sistema, ya decia yo….. En realidad quien pagina es el S.O, con esa directiva lo que conseguimos es que “no toque” la ram de los procesos lanzados por esa cuenta, es más importante en este caso fijar la máxima que es la que cuenta a la hora de “reservar” para el sistema antes de que se ponga a paginar, quiero decir que si reservas la suficiente y no tienes ningun driver o software chapucero es dificil que te encuentres con paginacion incluso sin bloquearla explicitamente, no se si me explico, aunque lo correcto es lo que has hecho tú, maxima y bloqueo.
Saludos!