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

• 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

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:

• 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

• SP2013 utiliza Shredded Storage, se recomienda dejar las settings por default de esta feature. Video, Video2, Documento Técnico.
• Revisar el doc de límites relacionados a la base de datos: http://technet.microsoft.com/en-us/library/cc262787(v=office.15).aspx#ContentDB
• Latencia de disco :

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