Esecuele Sin Fronteras

SQL Server, Reporting Services y Biztalk Server
  • Esecuele Sin Fronteras

    He borrado mi grupo de cluster con el recurso de SQL. ¿Y ahora?

    • 0 Comments

    Hoy vamos a hablar de cómo recrear un grupo de cluster de SQL Server bajo Windows Server 2008 cuando sea eliminado por error.

    Si lo que quieres es montarlo por primera vez, es necesario seguir este link, http://msdn.microsoft.com/en-us/library/ms179530.aspx , el cual nos ira guiando desde la planificación, hasta la consecución de nuestro objetivo. Siguiendo este link, además de crear el grupo de cluster, se deja configurado automáticamente el grupo de cluster y el servicio de SQL.

    Supongamos esta situación, Mike, nuestro DBA senior, le pide a Paul, un recién contratado DBA, que modifique la configuración del cluster. Paul borra, accidentalmente, el grupo del cluster.

    ¿Como puede Mike recuperar nuestro grupo perdido de cluster?

    Primero, Mike se conectara a la consola de cluster del nodo activo.

    clip_image002

    Dentro de “Services and Applications”, tendremos que generar nuestro contenedor. Botón derecho sobre “Services and applications” > “More Actions” > “Create Empty Service or application”

    Vamos a ponerle un nombre que nos diga algo, por ejemplo “test_moises”

    clip_image004

    Como vemos, esta vacío, así que vamos a añadir todos nuestros resources…

    Primero, para SQL Server, debemos añadir un “Client Access Point”, donde pondremos nuestro “Virtual name”, y nuestro “Virtual Address”, y la subred a la que va a escuchar, en caso de que haya varias...

    clip_image006

    Bien, pues ya está montado, ahora añadiremos los discos que utilizaremos para SQL Server, para ello pulsaremos sobre “Add storage”, y seleccionaremos los discos que necesitemos.

    clip_image008

    Perfecto, y ahora a por nuestro objetivo real, el resource de SQL Server.

    Pulsamos sobre “Add a resource” > “More resources” > “Add Sql Server”

    clip_image010

    Ojo, porque todavía no está configurado. Botón derecho sobre el recién estrenado SQL Server resource, y propiedades. En la pestaña “General”, podremos cambiar el nombre del recurso. Esto es solo para que nosotros nos acordemos, el cluster trabaja por debajo con los GUID.

    En la pestaña “Dependencies”, añadiremos las dependencias necesarias, en este caso, SQL Server, VirtualName y discos:

    clip_image012

    En la pestaña “Properties”, añadiremos el value del “VirtualServerName” y del “InstanceName”. (ejemplo grafico de que es el VirtualServerName y el InstanceName)

    clip_image014

    Por último, el SQL Server Agent. Pulsamos sobre “Add a resource” > “More resources” > “Add Sql Server Agent”.

    clip_image016

    La dependencia que pondremos es el resource de “SQL Server”, y en la pestaña “Properties”, configuramos, al igual que en el caso del resource de “SQL Server”, los values del “VirtualServerName” y del “InstanceName”.

    Si tuviésemos algún problema con las propiedades, podemos guiarnos por este kb: http://support.microsoft.com/kb/810056

    *Cuidado con este link, porque la traducción automática en castellano también modifica los valores del registro a editar, que realmente no se deben cambiar...

    clip_image017

    Pero en registro veremos:

    clip_image019

    Mike volverá a tener su cluster funcionando, y los usuarios no han tenido perdida de servicio.

     

    Moisés Romero Senosiain

    Ingeniero de soporte de SQL Server

  • Esecuele Sin Fronteras

    ¿Dónde está mi memoria?–Lock Pages in Memory (x64)

    • 0 Comments

    Acabamos de comprar un flamante nuevo servidor, 24 cores, 128GB de RAM, discos SSD en RAID 0… Instalamos SQL Server, 64 bits por supuesto, activamos Lock Pages in Memory (http://msdn.microsoft.com/en-us/library/ms190730.aspx) para que SQL no sea paginado fuera de RAM. Y para deleitarnos con nuestra obra cogemos contadores de carga de CPU, bloqueos, memoria…. Y ahí empieza el problema, ¡dónde está mi memoria!

    La memoria puede estar “perdida”, entre comillas ya que la memoria está siendo realmente usada, por diversos motivos, para los ejemplos usaré mi modesto Xeon de 4 cores y 12GB de RAM. Para capturar el uso de RAM física se usara la herramienta RAMMap de Mark Russinovich y Bryce Cogswell que podemos bajar de sysinternals: http://technet.microsoft.com/en-us/sysinternals/ff700229

    1 – Task Manager y lock pages in memory.

    Para realizar las pruebas se hace una SELECT de 10.000.000 de registros.

    Si usamos task manager para comprobar el uso de RAM de SQL podemos llevarnos una sorpresa.

    image

    Esta memoria es el Working Set (la memoria física usada actualmente por SQL Server). Apenas 116MB de uso, esto no cuadra con una base de datos que mueve cientos, miles o millones de datos por segundo por tanto algo debe estar mal.

    Si vamos a Management Studio y ejecutamos

    DBCC MEMORYSTATUS

    SQL nos proporcionará un resumen del uso de RAM que para nada coincidirá con lo que nos indica el task manager.

    Memory Manager                           KB        
    ---------------------------------------- -----------
    VM Reserved                                 19015912
    VM Committed                                  119148
    Locked Pages Allocated                        747776
    Reserved Memory                                 1024
    Reserved Memory In Use                             0

    Vamos a fijarnos únicamente en los valores VM Committed y Locked Pages Allocated (AWE Allocated en SQL Server 2005).

    VM Commited: Éste valor es el tamaño de memoria virtual (del proceso) que actualmente está siendo manejado por SQL Server, esta memoria puede ser paginada, el working set es un sub conjunto de esta memoria, por tanto los valores obtenidos tienen lógica.

    Locked Pages Allocated (AWE allocated en SQL Server 2005): Este valor indica la cantidad de RAM física bloqueada en memoria por SQL Server y que no se puede ser paginada. Por tanto esta valor más el working set nos darán una idea aproximada del tamaño de la RAM física consumida por SQL Server (En este caso 118972KB + 747776KB, unos 846MB)

    La explicación de este comportamiento es que al activar  Lock Pages in Memory en x64 se está haciendo uso de algo muy conocido por la gente que ya ha trabajado con SQL en x86, me refiero a: Address Windowing Extensions (AWE) http://msdn.microsoft.com/en-us/library/aa366527(v=vs.85).aspx. Esta API sigue estando presente en las ediciones de 64 bits de Windows debido a su utilidad ya que es la única forma que tiene un programa de usuario de bloquear RAM física para su uso. Para los programadores que tenga curiosidad les recomiendo que vean la entrada de msdn VirtualAlloc(http://msdn.microsoft.com/en-us/library/aa366887(v=vs.85).aspx) con el flag MEM_PHYSICAL. Esta memoria está fuera de la memoria virtual del proceso y por tanto no aparece en el Working Set del Task Manager.

    A continuación lanzamos RAMMap para ver en que se está usando la RAM física.

    image

    Como podemos ver el valor consumido por AWE coincide exactamente con el de Lock Pages Allocated, 744776KB.

    Hemos encontrado nuestra memoria.

    2 – Lock Pages Allocated no coincide con el valor de AWE. Presentamos “Large Page Extensions”

    Ahora realizamos la misma prueba con una máquina i7 de 4 cores y 16GB de RAM. Arrancamos SQL Server, lanzamos Management Studio, hacemos una SELECT de 10.000.000 de registros y…

    image

    Un working set de 131468KB. Mas o menos como antes. Ahora veamos la salida de DBCC MEMORYSTATUS

    Memory Manager                           KB        
    ---------------------------------------- -----------
    VM Reserved                                 23200928
    VM Committed                                  174292
    Locked Pages Allocated                        682048
    Reserved Memory                                 1024
    Reserved Memory In Use                             0

    Parece que todo está mas o menos como en el ejemplo anterior, 174292KB para VM Commited y 682048KB para Lock Pages Allocated. Pero cuando vamos a RAMmap vemos esto:

    image

    Y… oops. AWE está consumiendo 731200de RAM, lo que nos deja con la siguiente pregunta ¿Donde están mis 48MB?

    La respuesta está en “Large Page Extension” (http://msdn.microsoft.com/en-us/library/aa366720.aspx). Basicamente SQL Server 64bits si se encuentra más de 8GB libres al arrancar usará parte de la memoria para "Large Pages” este tipo de páginas de memoria proporcionan un aumento de rendimiento para grandes cargas de datos y se reserva usando el API de AWE, por tanto RAMMap la muestra como memoria AWE, mas información (http://blogs.msdn.com/b/psssql/archive/2009/06/05/sql-server-and-large-pages-explained.aspx). Si en vez de utilizar DBCC MEMORYSTATUS usamos DMV’s podremos ver este tipo de reservas de memoria. Usaremos la siguinte query (Esta query solo funciona en SQL Server 2008 y superiores):

    SELECT large_page_allocations_kb, locked_page_allocations_kb FROM sys.dm_os_process_memory

    En mi caso el resultado es el siguiente:

    image

    Lo que nos dice que 682048KB están en Locked Pages y 49152KB están en Large Pages, lo que nos suma los 731200KB. En caso de SQL Server 2005 no hay ninguna query con la que podamos consultar este tipo de memoria, con lo que tendremos que hacer un acto de fe.

    Notas sobre Large Pages:

    - Solo está disponible en Developer y Enterprise

    - Cuanto más RAM tenga el sistema más RAM se reserva para Large Pages.

    - Las Large Pages solo se activan si tenemos más de 8GB libres cuando arranca SQL Server.

    - Large Pages no está limitado por Max Server Memory.

    - Con mirar nuestro ERROLOG sabremos si están activas las Large Pages, se registrara lo siguiente:

    2011-09-02 13:13:47.41 Server      Large Page Extensions enabled.
    2011-09-02 13:13:47.41 Server      Large Page Granularity: 2097152
    2011-09-02 13:13:47.41 Server      Large Page Allocated: 32MB
    2011-09-02 13:13:47.43 Server      Using locked pages for buffer pool.

    Pablo Gavela López – Microsoft Customer Support Services

Page 1 of 1 (2 items)