sábado, 22 de marzo de 2014

Mejores Prácticas SQL Server para Sharepoint 2010/2013 (Best Practices SQL Server for Sharepoint 2010/2013)–Parte 2

Parte 1: Optimización de los servidores de SQL Server

Parte 2: Optimización de la instancia de SQL Server (acá estamos)

Parte 3: Mantenimiento de SQL Server

OPTIMIZACION DE LA INSTANCIA DE SQL SERVER

  • Setear Max Memory y Min Memory de la instancia.

Puede utilizar el siguiente script: Max Server Memory

Tendrás que setear dos variables dentro del script, y el mismo te generará un tamaño adecuado para el MaxMemory.

· MemToApps: default 512 MB

· RoomForOS: default 1 GB

Hay una fórmula que todos los consultores Sharepoint la utilizan:

SQL Max Memory = TotalPhyMem - (NumOfSQLThreads * ThreadStackSize) - (1GB * CEILING(NumOfCores/4))
NumOfSQLThreads = 256 + (NumOfProcessors*- 4) * 8    
ThreadStackSize = 2MB on x64 or 4 MB on 64-bit (IA64)  (*  If NumOfProcessors > 4, else 0)

Tanto el script como la fórmula, obtenes valores similares.

  • Max Worker Threads:

Total available logical CPU’s <= 4: max worker threads = 512
Total available logical CPU’s > 4: max worker threads = 512 + ((logical CPUS’s - 4) * 16)

  • Maxdop (Maximum Degree of Parallelization) = 1
  • Collation para la instancia=Latin1_General_CI_AS_KS_WS
  • Contained Database = 1 (sólo SQL Server 2012)
  • Auto shrink = false
  • Auto close = false
  • Page verify = checksum
  • Index Fill Factor = 80% (a nivel de instancia)
  • Autogrowth = false

Deberá crecer en tamaños fijos, no mediante porcentaje:

1 GB para los datafiles (dependen del tamaño de la base, se recomienda 25% del tamaño de la base). Mi experiencia que 1GB es un buen tamaño para evitar la fragmentación (puede haber un pequeño tiempo de espera hasta que se aloca 1 GB, prefiero pagar ese tiempo y tener menor fragmentación).

256MB para los logs (25% del tamaño del datafile de la base.)

SIEMPRE es recomendable hacer un pre-growth (pre-allocate) de storage por 4 meses, pero esto genera mucho soporte del equipo de BD.

Para la tempDB utilice la siguiente formula:

[MAX DB SIZE (KB)] X [.25] / [# CORES] = DATA FILE SIZE (KB)

El “starting size” de la tempDB debe ser el 25% de la base de contenido más grande. En el post 3, les dejaré un script para obtener un valor inicial de tempdb más certero.

  • Recovery model para base de datos de usuarios= full mode (depende de tu política de backups)
  • Recovery model para la tempdb= simple mode
  • Auto create statistics: false (en general es buena práctica habilitar esta feature, pero para el caso de Sharepoint se recomienda deshabilitar)
  • Auto update statistics= false (misma consideración que el punto anterior.)
  • Auto update statistics asynchronously= false (misma consideración que el punto anterior.)
  • Se debe 1 datafile por virtual core para la tempdb: ej: si yo tengo una VM con 8 cores, debo tener 8 datafiles. Max Files=8 (no hay mejora después de los 8 datafiles) y todos los datafiles de la tempdb deben ser del mismo tamaño (proportional fill algoritm). Algunos recomiendan tener 1/4 o 1/2 datafile por core (link, link2, link3), yo siempre use 1 datafile por core y nunca tuve problemas, así que sigo recomendando esa configuración. Si distribuyes esos datafiles en distintas LUNs tendrás una mejoría importante.

Otra recomendación es tener 1 sólo transaction log para la tempdb (link). El tamaño de este transaction log debe ser el 25% de la base más grande.

Los nombres de los datafiles deben ser: tempdb1, tempdb2, tempdb3, etc

Ej: 4 cores

image

  • Siempre hacer un pre-size de storage de la tempdb
  • Habilitar el trace flag 1117 (permite mantener los datafiles siempre con el mismo tamaño al hacer growth), se utiliza mucho para la tempdb.
  • Habilitar Instant File Initialization: especialmente para la cuenta que ejecuta el servicio de SQL Server. Se deberá setear la policy “Perform volume mintenance task”. Los logs NO son afectados por este feature.
  • IOPS recomendados: 2 por GB de dato para una performance optima. Sharepoint soporta hasta .25 por GB de dato.
  • Utilizar alias para la configuración de Sharepoint (link)
  • Raid 10 para tempDB
  • Cada 4 web servers (WFE) es recomendable tener otra instancia de SQL Server (otro servidor)
  • IOPS necesarios

Las bases que más consumen IOPS son las bases de Search (links)

Les recomiendo leer la siguiente pptx para tener un mejor capacity planning del Search:

http://video.ch9.ms/sessions/teched/na/2013/SES-B310.pptx

image_thumb[7]

image_thumb[9]

Las bases de contenido pueden variar entre 200 IOPS a 4000 IOPS, dependiendo del uso del contenido (Documentos, Videos, etc).

Las demás bases pueden variar entre 100 IOPS a 200 IOPS.

Les dejo un resumen para que lo tengan como referencia:

image_thumb[11]

  • Calcula prematuramente el tamaño estimado que vas a tener en la granja

Database size = ((D × V) × S) + (10 KB × (L + (V × D)))

10KB es el valor promedio de metadata que es requerido por SP2013.

D=Número de documentos

S=Tamaño promedio de los documentos

L=List Items

V=Número de versiones no actuales

Database data files:

     · Target: <10ms

     · Acceptable: 10-20ms

     · Unacceptable: >20ms

Database log files:

     · Target: <5ms

     · Acceptable: 5-15ms

     · Unacceptable: >15ms

Orden de prioridad:

     · tempDB data y logs files

     · Database transaction logs

     · Seach Data files

     · Content Database data files

  • Read Committed Snapshot Isolation NO está soportado
  • Configurar ModelDB: con parametros similares a los definidos para la content database.
  • NO se debe realizar consultas sobre la base de datos (puede ocasionar locks y rebuilds del schema): En el siguiente Link podrás encontrar más información. La UNICA base en la que se puede realizar queries es WSS_Logging. Link, Link 2. En el caso que quieras hacer queries contra la bases de Sharepoint, has un backup y utiliza ese backup para realizar queries.
  • Compress Backups = True
  • NO se puede ejecutar DBCC CHECKDB WITH REPAIR o sus variantes (no soportado). Si se puede ejecutar los siguientes comandos:
    • DBCC CHECKDB
    • DBCC_CHECKDB WITH REPAIR_FAST
    • REPAIR_REBUILD
  • Tener bases de contenido con tamaño máximo de 200GB (no es un límite de Sharepoint, es por cuestiones de administración principalmente)
  • Configurar la instancia de SQL Server con Mixed Mode, ya que el servicio de Access Service lo requiere.
  • Utiliza standarts para los nombres de las bases de datos.

Tipo

Nombre
Configuration SP_<Farm ID>_Config
Content DB SP_<Farm ID>_Content_<Nombre o Propósito>
Ej: SP_FCentral_Content_Intranet , donde FCentral hace referencia a la granja central
Service Application SP_<Farm ID>_Content_<Service Application>
  • Instalar siempre el último CU disponible para SQL Server (a la escritura de este post era el CU 9)
  • Latencia entre los servidores de SQL Server y los de Application Server/WFE < 1 ms
  • Excluir del antivirus las siguientes extensiones: *.mdf, *.ndf, *.ldf, *.bak. En el caso que tengas un cluster, también <$windir>/cluster
  • Utilizar la versión Enterprise de SQL Server

1 comentario:

  1. Remember to view if exists a string connection of SharePoint_Config data base in Sarepoint Server's Registry

    ResponderEliminar