Troubleshooting problemas de performance de SQL Server para Sharepoint–Parte 2

Seguimos con la serie de post sobre la performance de SQL Server para Sharepoint

Parte 1 

En este post estaré hablando sobre VLFs (Virtual Log Files). Los transaction logs de una base de datos están compuestos de uno o más archivos físicos. Por cada base de datos, SQL Server sólo escribe un transactional log físico a la vez.  Internalmente los archivos físicos que SQL Server usa para los Transaction Log son estructurados conocidos cómo Virtual Log Files (VLFs). SQL Server no debe tener un número excesivo de Virtual Log Files (VLFs) denntro de los Transaction Log. 

Algunos problemas de tener un número grande de VLFs:

• Restore´s o startup´s muy lentos.
• Insert, delete, updates muy lentos
• Locking excesivos
• Puede hacer lento el mirroring en ambiente de alta disponibilidad
• Backups muy lentos

Se puede ver la cantidad de VLFs para una base, mediante el siguiente comando: DBCC LOGINFO

En general un número excesivo de small´s autogrow generan muchos VLFs.

Para Sharepoint se recomienda tener entre 50 a 100 VLFs por base de datos. Un número chico (ej: 10) NO es recomendado o un número grande (Ej: 1000) tammpoco es recomendado

Bajen el siguiente script para ver la cantidad de VLFs por base de datos.

https://onedrive.live.com/redir?resid=137CB2CC363CB937%211519

Cómo podemos reducir los VLFs? Ejecutando el siguiente script

USE <Nombre_BaseDatos> --Setear el nombre de la base antes de ejecutarlo

DECLARE @file_name sysname,
@file_size int,
@file_growth int,
@shrink_command nvarchar(max),
@alter_command nvarchar(max)

SELECT @file_name = name,
@file_size = (size / 128)
FROM sys.database_files
WHERE type_desc = 'log'

SELECT @shrink_command = 'DBCC SHRINKFILE (N''' + @file_name + ''' , 0, TRUNCATEONLY)'
PRINT @shrink_command
EXEC sp_executesql @shrink_command

SELECT @shrink_command = 'DBCC SHRINKFILE (N''' + @file_name + ''' , 0)'
PRINT @shrink_command
EXEC sp_executesql @shrink_command

SELECT @alter_command = 'ALTER DATABASE [' + db_name() + '] MODIFY FILE (NAME = N''' + @file_name + ''', SIZE = ' + CAST(@file_size AS nvarchar) + 'MB)'
PRINT @alter_command
EXEC sp_executesql @alter_command

Ej: cuando lo ejecuté sobre WSS_Content, después los VLFs quedaron así.

VLF lecciones aprendidas:

• Evitar el autogrow automático en el caso que puedas. Pre-sizing tanto los datafiles como los log files
• Setear autogrow razonables (en el caso que requieras autogrow). El tamaño depende obviamente de tu ambiente. Entre 1GB a 3GB suele ser algo común. Para base de datos con alto crecimiento deberías tener un capacity planning adecuado

• Verificar mensualmente los VLFs y has un regrowing para reducir el número total de VLFs
• Nunca hagas un shrink de los datos o log files de forma regular. Shrinking debe ser algo extremadamente raro en respuesta de algo específico.

Tema adicional: fragmentación de los datafiles.

Cómo podemos ver la fragmentación de los datafiles? Con el programa Contig de SysInternals.https://technet.microsoft.com/en-us/sysinternals/bb897428

Ej: veamos la fragmentación de la base WSS_Content. Dejamos el .exe en el mismo path del datafile

Abrimos una línea de comando con permisos de administrador y ejecutamos lo siguiente.

contig -a WSS_Content.mdf

Cómo pueden ver tiene 119 fragmentos, no son muchos (se recomienda desfragmentar cuando se tiene más de 500 fragmentos)

Para desfragmentar hago lo siguiente.

Pongo la base en modo offline

ALTER DATABASE WSS_Content SET OFFLINE
GO

ejecuto lo siguiente

contig WSS_Content.mdf

Después ejecuto

ALTER DATABASE WSS_Content SET ONLINE
GO

Claramente tendrás corte de servicio, por eso es muy importante configurar correctamente el growth de los datafiles al crear la base de datos. Si tarda mucho las bases en ponerse offline, lee el siguiente artículo. http://blog.degree.no/2013/03/long-wait-time-when-taking-sql-server-database-offline/

Referencias recomendadas:

https://www.youtube.com/watch?v=lcmYeE-cqQo

http://www.sqlskills.com/blogs/kimberly/post/8-Steps-to-better-Transaction-Log-throughput.aspx

http://www.sqlskills.com/blogs/kimberly/transaction-log-vlfs-too-many-or-too-few/

http://www.mssqltips.com/sqlservertip/3008/solving-sql-server-database-physical-file-fragmentation/

DiskSpd–testing de storage para SQL Server de Sharepoint

Microsoft siempre recomendó SQLIO o IOMETER para hacer testing sobre el storage. Ultimamente está recomendado utilizar DiskSpd (https://github.com/microsoft/diskspd). La tool puede simular diferentes tipos de workloads para el storage. Cómo la performance de SQL Server impacta directamente sobre la performance de Sharepoint, vamos a probarla sobre el SQL Server de un Sharepoint montado sobre azure (A6, 4 núcleos y 28 GB de RAM).

Para bajar los binarios, ingrese acá: http://aka.ms/DiskSpd. En el zip vienen tres versiones amd64fre (para 64-bit systems), x86fre (para 32-bit systems) y armfre (para ARM systems).

Vamos a usar amd64fre en este caso.

Les recomiendo leer el siguiente artículo Storage and SQL Server capacity planning and configuration (SharePoint Server 2013)

En una sección del artículo comenta que una base de contenido tienden a estar en el rango de 0.2 IOPS/GB a 0.5 IOPS/GB, obviamente dependiendo del tipo de contenido, usuarios, frecuencia, etc. Pero es en general rondan esos IOPS una base de contenido. Les dejo un resumen para que sepan de forma más exacta la cantidad de IOPS que necesitan

Para las bases del search pueden llegar a los 10 IOPS/GB, cómo siempre depende del tipo de contenido y el tamaño que estás indexando.

Las bases de contenido se deben optimizar para “Read Operations”, ya que en general el 80% son lecturas para las bases de contenido (de nuevo depende de tu ambiente). En cambio la TempDb debería estar optimizada para “Write Operations”, al igual que los transaction logs. Tanto para la TempDb y los transaction logs se recomienda tener 2 IOPSxGB.

Abro una consola de powershell, voy hasta el path donde esta DiskSpd, y ejecuto lo siguiente

diskspd.exe -c1G -d60 -b64k  -w20  -h -L C:\testfile.dat

-c = tamaño en bytes del archivo a probar

-d = tiempo de la prueba

-b = tamaño de la operación de IO en KB, en general se recomienda tener formateado los sql con 64KB de block size, por cuestiones de performance. Les dejo un post donde defino las best practices para SQL Server para Sharepoint.

-w = 20% de writes, 80% de lectura. Depende de donde hagas las pruebas (Ej: partición de la tempdb o partición de la content database, puede variar este porcentaje)

-h = disabled hardware y software caching

-l = capturo la información de la latencia

PS C:\Users\administrador\Desktop\Diskspd-v2.0.15\amd64fre> .\diskspd -c1G -d60 -b64k  -w20  -h -L C:\testfile.dat

Command Line: C:\Users\administrador\Desktop\Diskspd-v2.0.15\amd64fre\diskspd.exe -c1G -d60 -b64k -w20 -h -L C:\testfile
.dat

Input parameters:

        timespan:   1
        -------------
        duration: 60s
        warm up time: 5s
        cool down time: 0s
        measuring latency
        random seed: 0
        path: 'C:\testfile.dat'
                think time: 0ms
                burst size: 0
                software and hardware write cache disabled
                performing mix test (write/read ratio: 20/100)
                block size: 65536
                using sequential I/O (stride: 65536)
                number of outstanding I/O operations: 2
                thread stride size: 0
                threads per file: 1
                using I/O Completion Ports
                IO priority: normal

 

Results for timespan 1:
*******************************************************************************

actual test time:       60.00s
thread count:           1
proc count:             4

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|   2.66%|   1.43%|    1.22%|  97.34%
   1|   1.04%|   0.91%|    0.13%|  98.96%
   2|   0.18%|   0.18%|    0.00%| 100.47%
   3|   0.29%|   0.29%|    0.00%| 107.21%
-------------------------------------------
avg.|   1.04%|   0.70%|    0.34%| 101.00%

Total IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      1251147776 |        19091 |      19.89 |     318.18 |    6.299 |    21.863 | C:\testfile.dat (1024MB)
-----------------------------------------------------------------------------------------------------
total:        1251147776 |        19091 |      19.89 |     318.18 |    6.299 |    21.863

Read IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      1003880448 |        15318 |      15.96 |     255.30 |    4.260 |    17.148 | C:\testfile.dat (1024MB)
-----------------------------------------------------------------------------------------------------
total:        1003880448 |        15318 |      15.96 |    255.30 |    4.260 |    17.148

Write IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |       247267328 |         3773 |       3.93 |      62.88 |   14.575 |    33.755 | C:\testfile.dat (1024MB)
-----------------------------------------------------------------------------------------------------
total:         247267328 |         3773 |       3.93 |      62.88 |   14.575 |    33.755

  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.088 |      6.141 |      0.088
   25th |      0.122 |      7.052 |      0.127
   50th |      0.173 |      8.019 |      0.215
   75th |      0.310 |     13.518 |      7.787
   90th |     13.661 |     22.534 |     15.612
   95th |     19.704 |     31.477 |     23.500
   99th |     31.262 |     84.047 |     37.936
3-nines |    245.343 |    525.326 |    267.420
4-nines |    485.116 |    880.573 |    878.033
5-nines |    528.841 |    880.573 |    880.573
6-nines |    528.841 |    880.573 |    880.573
7-nines |    528.841 |    880.573 |    880.573
8-nines |    528.841 |    880.573 |    880.573
    max |    528.841 |    880.573 |    880.573

Links recomendados:

http://www.emc.com/collateral/hardware/white-papers/h12468-sharepoint-server-best-practices-wp.pdf

http://blogs.technet.com/b/josebda/archive/2014/10/13/diskspd-powershell-and-storage-performance-measuring-iops-throughput-and-latency-for-both-local-disks-and-smb-file-shares.aspx

Troubleshooting problemas de performance de SQL Server para Sharepoint–Parte 1

Voy a arrancar una serie de post relacionados al troubleshooting de problemas de performance de SQL Server para Sharepoint. Anteriormente había creado una serie de post sobre las mejores prácticas de SQL Server para Sharepoint:

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

Parte 2: Optimización de la instancia de SQL Server

Parte 3: Mantenimiento de SQL Server

En este caso, me voy a enfocar especificamente en los problemas de performance (lentitud de consultas, consumo alto de RAM o CPU, etc).

Hoy voy a revisar el parámetro “Page Life Expectancy” (PLE). El cual es el tiempo esperado, en segundos, que una página de un data file es sacada (pushed out) del buffer pool (in-memory cache de data files pages) para hacer espacio para otra página diferente de un data file. En resumen, indica la presión sobre el buffer pool para leer páginas de data files. Un número alto es mejor, ya que si no hay memoria suficiente en el sistema, se sacan más rapidamente las páginas del buffer pool.

Microsoft recomendaba que este contador supere los 300 ms (>). Si nuestro ambiente. nos da que PLE ronda los 300 ms, significa que el buffer pool completo se saca (flushed) y se leer de forma completa cada 5 minutos. Este valor fue cambiando con los sistemas actuales, que tienen muchos GB de RAM.

La fórmula correcta para evaluar este parámetro es: ( Buffer pool memory in GB / 4 ) x 300

Con la siguiente query, puedo saber el valor de este contador.

SELECT object_name, counter_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%Buffer Manager%'
AND [counter_name] = 'Page life expectancy'

Recomiendo ejecutar este comando cada 6 horas, para tener una certeza más correcta de este comando. Ya que hay operaciones tales como DBCC CHECKDB o index rebuilds pueden afectar el valor de este contador.

En este caso, ejecuté el comando sobre un servidor con 16 GB de RAM (SQL Server 2012).

Para saber el tamaño del buffer pool memory, ejecuto el siguiente comando

select DB_NAME(database_id) Database_Name, count(*) Pages
from sys.dm_os_buffer_descriptors
group by database_id 
order by Pages desc

El cual nos devuelve todas las bases de datos que tienen páginas en el buffer

Un punto importante, para ver mediante esta consulta, es que nos da una idea de que bases de datos tienen más páginas en el buffer, con lo cual nos da un parámetro para saber que bases de Sharepoint son las que más actividad tienen. En la imagen superior, la base de contenido “WSS_Content_SPS_2” tiene casi 9 GB de datos cargados en la RAM (1146634*8/1024), lo cual es demasiado para una base. En este caso recomiendo crear otra base de contenidos y mover algunos sites collection a esa base, para bajar este número. Más adelante daré otros tips para subir el PLE lo cual puede mejorar la cantidad de páginas para esta base de contenido.

La suma de todas las páginas (de todas las bases) es : 1347406

(1347406*8)/1024 =~ 10526.61 –> 10.28 GB.

Agrego este valor a la fórmula anterior, y evaluo el resultado

(10.28GB /4) *300= 771 lo cual es un valor adecuado para el contador PLE.

Si este contador nos da demasiado bajo, podemos revisar lo siguiente:

• Índices no actualizados
• Estadísticas no actualizados
• Fragmentación de datafiles

La base de search en general tiene bastantes páginas en el buffer, ya que en general se obtienen datos random de las queries.

Una manera de revisar que queries son las que causan más lecturas, es ejecutando la siguiente query.

SELECT TOP 25 cp.usecounts AS [execution_count]
      ,qs.total_worker_time AS CPU
      ,qs.total_elapsed_time AS ELAPSED_TIME
      ,qs.total_logical_reads AS LOGICAL_READS
      ,qs.total_logical_writes AS LOGICAL_WRITES
      ,qs.total_physical_reads AS PHYSICAL_READS
      ,SUBSTRING(text,
                   CASE WHEN statement_start_offset = 0
                          OR statement_start_offset IS NULL 
                           THEN 1 
                           ELSE statement_start_offset/2 + 1 END,
                   CASE WHEN statement_end_offset = 0
                          OR statement_end_offset = -1 
                          OR statement_end_offset IS NULL 
                           THEN LEN(text) 
                           ELSE statement_end_offset/2 END -
                     CASE WHEN statement_start_offset = 0
                            OR statement_start_offset IS NULL
                             THEN 1 
                             ELSE statement_start_offset/2  END + 1
                  )  AS [Statement]       
FROM sys.dm_exec_query_stats qs 
   join sys.dm_exec_cached_plans cp on qs.plan_handle = cp.plan_handle
   CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st
ORDER BY qs.total_physical_reads DESC;

En este caso, veo que la query

SELECT          SUBSTRING(ADS.Content, @Offset, @Length)      FROM          TVF_AllDocStreams_SiteDocIdInternalVersion(@SiteId, @DocId, @InternalVersion) AS ADS     

AllDocStreams es la tabla donde se almacenan los documentos de Sharepoint.

Otra query para saber el tamaño en MB de las páginas que están en el buffer pool

SELECT count(*)*8/1024 AS 'Data Cache Size(MB)' ,CASE database_id WHEN 32767 THEN 'RESOURCEDB' ELSE db_name(database_id) END AS 'DatabaseName' FROM sys.dm_os_buffer_descriptors GROUP BY db_name(database_id) ,database_id ORDER BY 'Data Cache Size(MB)' DESC

Hay mucha información sobre PLE en Internet, la idea es mostrarle un par de consultas y parámetros para ayudarlos en algún problema que tengan con su SQL de Sharepoint.

Probar la performance de nuestro storage mediante SQLIO y powershell

La idea ejecutar un par de pruebas de stress sobre nuestro storage para evaluar la performance del mismo. En Sharepoint el cuello de botella suele ser nuestro SQL Server, mediante este script podremos probar si nuestro storage soporta la carga de IOPS requerida para que Sharepoint funcione correctamente.

Current enviroment:

• Azure IaaS A6, Datacenter Sur de Brasil
• Disco C (perpetuo, no se ve afectado por reinicios de la VM)
• Disco D (temporario, Azure mantiene una partición D para workload temporario, ej: logs de Base de datos)

Primero descargamos el siguiente script y sqlio

http://gallery.technet.microsoft.com/scriptcenter/Storage-IO-Performance-d628bad9

http://www.microsoft.com/en-us/download/details.aspx?id=20163

Lo dejamos en una carpeta temporal del C, ej. C:\Temp

Editamos el archivo de powershel

Y cambiamos los parámetros.

Algunas cosas a tener en cuenta:

• Trata de tener la cantidad de threads menor o igual a la cantidad de vCPU (threads <= vCPU). Yo por ejemplo tenía 8 cores, y le setee 1 a 4 threads.
• SQL Server en general escribe sequencial, pero la idea es hacer un stress de nuestro storage, así que deja los dos.
• El tamaño de los bloques de I/O dependerá de si se usa Eager Writes o Lazy Writer, pero has una prueba con los tres valores (8,64 y 256 KB).

Una vez que se ejecuta nos mostrará un archivo html con toda la información (IOPS, latencia, etc)

Estos datos podemos pasarlo a un excel y ver una comparativa de performance de nuestro storage.

Ej: promedio de IOPS y latencia de todas las combinaciones

En general Sharepoint requiere que tengamos tiempos de latencia promedio de :

Datafiles: <= 15ms

Logs: <= 5 ms

Obviamente depende del tipo de base que manejemos y del tamaño. Ej: las bases de search son las bases que más IOPS requieren, o bases de datos relacionadas a record center podriamos tener una latencia entre 20ms a 10 ms.

Les dejo un link a post que realicé hace un tiempo sobre las mejores prácticas de SQL Server para Sharepoint.

http://todosharepoint.blogspot.com.ar/2014/03/mejores-practicas-sql-server-para.html

Les dejo el link para descargar todos los archivos:

http://1drv.ms/1qMe0fa

 

Algunos links interesantes para entender estos resultados:

http://www.brentozar.com/archive/2008/09/finding-your-san-bottlenecks-with-sqlio/

http://blogs.technet.com/b/josebda/archive/2013/03/28/sqlio-powershell-and-storage-performance-measuring-iops-throughput-and-latency-for-both-local-disks-and-smb-file-shares.aspx

http://blogs.msdn.com/b/sqlmeditation/archive/2013/04/04/choosing-what-sqlio-tests-to-run-and-automating-sqlio-testing-somewhat.aspx

http://blogs.technet.com/b/sqlpfeil/archive/2012/12/04/working-with-sqlio-and-analyzing-it-s-output.aspx

http://technet.microsoft.com/en-us/library/cc966412.aspx

http://technet.microsoft.com/en-us/library/ff758657%28v=office.15%29.aspx

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

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

Parte 2: Optimización de la instancia de SQL Server

Parte 3: Mantenimiento de SQL Server (acá estamos)

MANTENIMIENTO DE SQL SERVER

• Verificar que no haya bases de contenido con tamaño >=200 GB. Se recomienda crear una nueva base de contenido y mover sites collection a esa base (Move-SPSite).
• Verificar latencia de disco para las bases de datos: utilizar el siguiente ReadAndWriteLatency.

El script nos retornará la latencia de disco (Avg Read Transfer/ms, Avg Write Transfer/ms). Microsoft sugiere los siguientes thresholds:

Database data files:

· Target: <10ms

· Acceptable: 10-20ms

· Unacceptable: >20ms

Database log files:

· Target: <5ms

· Acceptable: 5-15ms

· Unacceptable: >15ms

• Ejecutar semanalmente DBCC CHECKDB. Puedes utilizar el script de Hallengren: http://ola.hallengren.com/sql-server-integrity-check.html  (recuerda NO utilizar checkdb con la opción de rebuild, en cualquiera de sus formatos)

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'USER_DATABASES',
@CheckCommands = 'CHECKDB',
@PhysicalOnly = 'Y'

• Monitorear semanalmente por Wait Events. Puedes utilizar el siguiente script: WaitStats. Dependiendo de los eventos externos por los cuales SQL espera, se realizará una acción. Ej: agregar más CPU, distribuir los I/O, etc.  Más información

• Monitorear los growth de la tempDB. Deberían minimizarse al mínimo los growth de la tempDB. El siguiente script nos permite monitorear esos growth, y en el caso que haya muchos, deberíamos iniciar la tempDB con un tamaño mayor y tener tamaños más grande autogrowth: InitialSizeAndGrowth

• El siguiente script es similar al anterior, pero monitorea las bases de usuario. AutogrowthRecent

Si el script nos retorna que hubo >=7 growth para una base de usuario, significa que no está seteado correctamente el tamaño del autogrow.

Recuerda habilitar el trace en el caso que se haya deshabilitado.

select name, value_in_use

from sys.configurations

where name='default trace enabled'

Si value_in_use no es 1, se deberá habilitar.

sp_configure 'default trace enabled', 1

go

reconfigure with override

go

• Realizar desfragmentación de indices semalmente. Sharepoint tiene el store proc_UpdateStatistics, que realiza tareas de mantenimiento de indices. El problema de este store es que no se ejecuta para todas las bases de Sharepoint, sólo las de contendio. Se deberá ejecutar el siguiente script para evaluar la fragmentación de los índices:

Fragmentation Index.sql

Columna	Descripcion
avg_fragmentation_in_percent	El porcentaje de fragmentación lógica (páginas fuera de orden en el índice)
fragment_count	El número de fragmentos (páginas de hojas físicamente consecutivas)
avg_fragment_size_in_pages	Número promedio de páginas de un fragmento en un índice

Una vez verificado el estado de los índices, evaluar la siguiente tabla

avg_fragmentation_in_percent value	Sentencia correctiva
> 5% and < = 30%	ALTER INDEX REORGANIZE
> 30 %	ALTER INDEX REBUILD WITH (ONLINE= ON)

Para hacer un rebuild de los índices fragmentados, se deberá ejecutar el siguiente script (se utilizará el script de ola.hallengren.com):

1. Crear el procedimiento de desfragmentación de índices con el siguiente script

MaintenanceSolution.sql

2. Ejecutar el siguiente script

RebuildIndices.sql

El script anterior se puede crear un job para que se ejecute semanalmente (Sunday).

Ejecutar de nuevo el script FragmentationIndex.sql y ejecutar el siguiente script para verificar el estado de las estadísticas:

ReviewStatistics.sql

Si quieres utilizar el store de Sharepoint para desfragmentar los indices, puedes usar el siguiente script:

EXECUTE sp_msforeachdb
'USE [?];
IF DB_NAME() NOT IN(''master'',''msdb'',''tempdb'',''model'')
     begin
          print ''updating statistics in database  ==> '' + db_name()
          if exists (select 1 from sys.objects where name = ''proc_updatestatistics'')
             begin
                  print ''updating statistics via proc_updatestatistics''
                  exec proc_updatestatistics
             end
         else
             begin
                  print ''updating statistics via sp_updatestats''
                  exec sp_updatestats
             end
    end'

Más información en el siguiente link, link2.

• NUNCA hacer shrinks de datafiles (hay casos especiales, tales como borrado de mucha información, o tamaño excesivo de la base de crawl: link). Se puede hacer shrink de los logs, pero es preferible setear a modo simple las bases y evitar tamaños grandes de logs. En vez de Shrink de logs, se podría crear una buena política de backups y evitar el shrink, ya que al hacer el backup de las bases automaticamente realiza un shrink de los logs.
• En el caso excesivo de consumo de CPU y RAM en el crawl del Search, se puede utilizar Resource Governor. Link
• Verifica semanalmente las best practices definidas en el punto 2 de esta serie de post (Ej: auto update statistics=false, autoshrink=false, fill factor=80, etc)
• Instalar SQL Best Practices Analyser, y verificar mensualmente las mejores práctices (se actualiza de forma continua): http://www.microsoft.com/en-us/download/details.aspx?id=29302 (recuerda, no siempre las mejores prácticas de SQL Server aplican para Sharepoint)
• Semanalmente desfragmentar los volumenes donde se encuentran los datafiles de SQL Server. Una excelente herramienta para evaluar la fragmentación de los datafiles es contig de SysInternals.contig -a "E:\Data\nombreBaseDatos.mdf". Recuerda de poner la base de datos a offline y ejecutar el proceso de desfragmentación, al finalizar ponla de nuevo en online a la base de datos.
• Evaluar la base de datos que más memoria consume

MostMemoryXDatabase.sql

• Monitorear los archivos lógicos (VLF).Lo indicado en tener ente 20 a 100 vlf`s.  Más información en el siguiente link

ListVLFCounts.sql

En el caso que quiera evaluar específicamente la tempdb, puede ejecutar el siguiente comando:

DBCC LOGINFO

Para reducir la cantidad de vlfs, puede consultar los siguientes links:

http://blogs.msdn.com/b/saponsqlserver/archive/2012/02/22/too-many-virtual-log-files-vlfs-can-cause-slow-database-recovery.aspx

• Monitores útiles:

A continuación una lista de contadores a evaluar:

· Memory – Available MBytes

· Paging File – % Usage

· Physical Disk – Avg. Disk sec/Read

· Physical Disk – Avg. Disk sec/Write

· Physical Disk – Disk Reads/sec

· Physical Disk – Disk Writes/sec

· Processor – % Processor Time

· Processor – % Privileged Time

· Process: IO Read Bytes/sec

· Process: IO Read Bytes/sec

· Process (sqlservr.exe)

· SQLServer: Buffer Manager – Page life expectancy

· SQLServer: Buffer Manager – Lazy writes/sec

· SQLServer: General Statistics – User Connections

· SQLServer: Memory Manager – Memory Grants Pending

· SQLServer: SQL Statistics – Batch Requests/sec

· SQLServer: SQL Statistics – Compilations/sec

· SQLServer: SQL Statistics – Recompilations/sec

· System – Processor Queue Length

• Instalar SQL Server 2012 Performance Dashboard Reports

Se deberá instalar SQL Server 2012 Performance Dashboard Reports, el cual permite generar reportes de problemas de performance de forma rápida. Algunos reportes incluyen lo siguiente:

· CPU bottlenecks (and what queries are consuming the most CPU)

· IO bottlenecks (and what queries are performing the most IO)

· Index recommendations generated by the query optimizer (missing indexes)

· Blocking

· Latch contention

http://www.microsoft.com/en-us/download/details.aspx?id=29063

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

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

El artículo se divide en 3 posts:

• Parte 1: Optimización de los servidores de SQL Server (acá estamos)
• Parte 2: Optimización de la instancia de SQL Server
• Parte 3: Mantenimiento de SQL Server

 OPTIMIZACION DE LOS SERVIDORES DE SQL SERVER

• El servidor de SQL Server debe estar dedicado para Sharepoint, no compartas el servidor con otras apps.
• Page file: dejar el valor default que viene con Windows Server 2012 (Automatic manage paging file size for all drives), ya que el mismo administra mejor la memoria. Para WS2008 es recomendable 1.5 x RAM disponible.
• Networking: 1 GB network interface card. En el caso que tengas problemas de performance con el tráfico de red, puede utilizar dos placas de red para los WFE/App Server, una para el servicio con los usuarios y la otra para el procesamiento (requiere configuración adicional, lo cual complica el mantenimiento). Revisar los contadores \Network Interface(*)\Output Queue Length (>1: revisar) y \Network Interface(*)\Current Bandwidth (>80%: revisar)
• Policy Lock Pages in memory: se recomienda agregar la cuenta de servicio de SQL Server a la policy. Es importante setear Max Memory correctamente y deshabilitar Balloon Drive (ver más abajo). Si hay dos instancias o otras apps corriendo en el servidor, se recomienda no utilizar esta policy, ya que puede afectar la performance
• Particiones: todas las particiones (volumes) deben estar formateadas con 64KB de allocation unit size. MUY IMPORTANTE este punto, notarás una gran diferencia de performance..

Format <drive> /Q /FS:NTFS /A:64K /V:Volume /Y

Dependiendo de la estimación del espacio requerido, y teniendo en cuenta que los servidores SQL serán virtualizados con VMware, se recomienda la siguiente distribución de discos, en donde:

El disco C: es para el sistema operativo.

El disco D: es para los binarios de SQL y para las apps

El disco E: es para los archivos MDF de las bases de datos (datafiles).

El disco F (High Range): es para la TempDB.

El disco G: es para los archivos LDF de las bases de datos (logs).

Los discos H: en adelante también son para los archivos MDF de las bases de datos, los mismos serán mid-range.

El disco C albergará los binarios del sistema operativo, dumps, page file, service packs, hotfixes, logs, etc.

* La suma total de los VMDKs (NTFS 64KB block size) podría disponibilizarse en un único VMSF

* * Los VMDKs (NTFS 64KB block size) se deberán disponibilizar sobre otro volumen VMSF (LUN diferente)

* * * La suma total de los VMDKs (NTFS 64KB block size) podría disponibilizarse en un único VMSF

• VMware (sólo mostraré para VMWare, para hyper-v son similares):
  • Alinear los VMDK file ,VMFS volume y SAN LUN: Descripción detallada
  • Direct path I/O: permite acceder a la Phisical NIC en vez de una vNIC. Se recomienda probar en ambientes de DEV antes de implementarlo en PRD; se pierden algunos features de VMware. Más información
  • Adaptadores en formato VMXNet3
  • Deshabilitar la feature Balloon Drive para la VM donde reside el SQL Server.
  • Al provisionar la VM se recomienda utilizar el método Thick Provision Eager Zeroed.
  • 1:1 ratio de phisical cores a virtual cores
  • Se recomienda procesadores con alto cache L2 y L3.
  • En el caso de alto throughput de networking, se recomienda utilizar NIC teaming. Más información
• RAID recomendaciones:

Vas a notar una gran mejora si pones la tempdb en un RAID 10 (SAS 15.000 RPM, 210 IOPS), otra posibilidad es usar SSD (discos de estado sólido)

• PowerPlan: High Performance. NO utilizar BIOS power saving feature.
• Performance Appearance: adjust for the best performance
• Procesor Scheduling: Best Performance of Background Services
• Deshabilitar la feature 8.3 Naming
• Tener en todas las particiones un 25% de espacio disponible para futuros crecimientos (rebuild de indices, crecimiento innesperado)
• Excluir del antivirus los paths y extensiones definidos en el siguiente link
• Cant de Cores y memoria del servidor: cada configuración dependerá de la cantidad de usuarios y documentación a guardar en el servidor, pero les dejo unas recomendaciones:

CORES

>10 gb <=1 TB de datos: 4 cores (1000 usuarios concurrentes)

>1TB de datos: 8 cores (10.000 usuarios concurrentes)

RAM

<1TB de datos: 16 GB

>1TB a 2 TB: 32 GB

>2TB a 5TB: 64 GB

>5TB a 16 TB: >64 GB

IMPORTANTE: esta configuración depende mucho del acceso a la información (porcentaje de reads, writes, etc), del procesamiento de la misma (workflows, BI, etc) y del tipo de información (records center, listas largas, etc)

• Antes de iniciar la instalación de SQL Server, evalua la performance de I/O del storage. Puedes utilizar SQLIO, IOMETER y CrystalDiskMark. Hay muchos ejemplos en internet de sus usos.
• Contadores útiles para tener en cuenta en servidores de SQL Server (relacionados a WS2012, más abajo describiré los relacionados a SQL Server):

  · \LogicalDisk(*)\Avg. Disk sec/Read (es el tiempo promedio, en segundos de una lectura de datos al disco):

  >12ms: respuesta lenta

  >25ms: respuesta muy lenta

  · \PhysicalDisk(*)\Avg. Disk sec/Read:

  <10 ms: muy bueno

  >10ms y 20ms: delay

  >20ms y 50ms: lento, evaluar

  >50ms: indica un problema grave I/O.

  · \LogicalDisk(*)\Avg. Disk sec/Write (es el tiempo promedio, en segundos de una escritura de datos al disco):

  >15ms: respuesta lenta

  >25ms: respuesta muy lenta

  · \PhysicalDisk(*)\Avg. Disk sec/Write: se utiliza los mismos threshold que \LogicalDisk(*)\Avg. Disk sec/Write

  · \LogicalDisk(*)\Disk Transfers/sec (es la tasa de lectura y escritura en el disco):

  <80 I/O por segundo en promedio cuando la latencia es mayor que 25ms, indica demasiadas virtual LUNs usando el mismo disco físico de una SAN.

  · \Physical Disk\%Disk Time: representa el porcentaje de tiempo transcurrido que el disco está ocupado ofreciendo servicio de read y write.

  >70%: evaluar I/O (incluir en la evaluación el contador de queue I/O)

  · \Physical Disk\%Idle Time: mide cuando tiempo el disco permance en un estado idle.

  <40%: evaluar discos. Ya que está teniendo mucho procesamiento.

  · \Physical Disk\PhysicalDisk\ Current Disk Queue Length:

  > (Nº de discos + 2): evaluar con PhysicalDisk\ Avg. Disk Queue Length

  · \Process(*)\IO Data Operations/sec (La tasa actual en el cual el proceso emite operaciones de I/O de lectura y escritura, este contado cuenta la actividad de I/O generada por el proceso,incluye file´s, network y device I/Os):

  Revisar si el proceso usa más de 1000 I/Os por segundo.

  · \PagingFile\%Usage: describe la cantidad de uso del page file.

  >90% indica un problema

· \Memory\Available MBytes (Available MBytes es la cantidad de memoria física en MB disponible para procesos ejecutandose en el servidor, este contado sólo indica el último valor y no un promedio ):

          Bajo en memoria: menor a 10%

          Muy bajo en memoria: menor a 5%

          Fluctuaciones de 100MB por hora, esto indica un memory leak.

· \Memory\Pages/sec (si es alto, indica que el sistema se está quedando sin memoria y está tratando de paginar la memoria a disco, es la tasa de páginas que son leídas o escritas a disco. Este contador es un indicador primario de retrasos en el sistema. Picos en pages/sec son normales en backups, lectura de archivos de gran de tamaño:

           Si es mayor a 20 pages/sec,se debería revisar

· \Memory\Free System Page Table Entries (es el número de entradas de la tabla de páginas no está en que utiliza el sistema. Este análisis determina si el sistema se está quedando sin entradas libres de la tabla de páginas del sistema (PTE))

          Menor que 10,000: posiblemente tenga problemas de performance.

· Processor\% Processor Time (es el indicador principal de la actividad del processor activity, altos valores no siempren indican un problemasi se incrementan de forma lineal otros contadores tales como % Privileged Time o Processor Queue Length, se deberá revisar):

          <50% consumido: OK

          >50 y <90%: monitorear

          >90 y <=100%: crítico

· \Processor\% Privileged Time:

          Consistentemente sobre 75% indica un bottleneck.

· \System\Context Switches/sec (Context switching ocurre cuando un thread de mayor prioridad se antepone a un hilthreado de menor prioridad que se está ejecutando. Alto niveles de context switching pueden ocurrir cuando hay muchos threads que tienen el mismo nivel de prioridad. Esto indica que hay demasiados threads compitiendo por el tiempo del procesador:

· \Processor(*)\% Interrupt Time (Este contador indica el porcentaje de tiempo que el procesador invierte la recepción y el servicio de las interrupciones de hardware. Este valor es un indicador indirecto de la actividad de los dispositivos que generan interrupciones, tales como adaptadores de red. Un aumento dramático en este contador indica posibles problemas de hardware)

          High CPU Interrupt Time: >30% indica algún problema de HW

· System\Processor Queue Length (Si hay más tareas listas para ejecutarse que procesadores existentes, los threads se encolan. La cola del procesador es el conjunto de hilos que están listos, pero no podrá ser ejecutado por el procesador porque otro subproceso activo se está ejecutando actualmente. Una queue sostenida o recurrente de más de dos hilos es una clara indicación de un cuello de botella en el procesador. Se puede obtener más rendimiento al reducir el paralelismo en esos casos. Puede usar este contador junto con el contador Procesador \% de tiempo de procesador para determinar si su aplicación puede beneficiarse de más CPU.

          Si cada procesador tiene 10 o más threads esperando, podría indicar que el procesador está a su capacidad límite

          Si cada procesador tiene 10 o más threads esperando, podría indicar que el procesador está trabajando arriba de su capacidad

· \Network Interface(*)\Output Queue Length:

          High Network I/O : más de 1 thread en espera de network I/O

          Very High Network I/O: más de 2 threads en espera de I/O (si output queue length

           es mayor que 2)

· \Network Interface(*)\Current Bandwidth (Este contador indica si el tráfico del adaptador de red está saturado):

          High average network utilization: > 50%

          Very high average network utilization: >80%

· Server\Bytes Total/sec (Este contador indica el número de bytes enviados y recibidos por la red. Los valores altos indican el ancho de banda de red como cuello de botella. Si la suma de Bytes Total / sec para todos los servidores es aproximadamente igual a las velocidades máximas de transferencia de la red, es posible que tenga que segmentar la red)

· \Process(*)\Private Bytes (Private es el tamaño actual, en bytes, de la memoria que este proceso ha asignado y no puede compartir con otros procesos)

          Delta entre minimum size y maximun size no debe ser > 500MB

· \Process(*)\Working Set (Working Set es el tamaño actual, en bytes, del Working Set del proceso. Working Set es el conjunto de páginas de memoria que han sido accedidas por los threads del proceso. Si la memoria libre es mayor que un umbral las páginas se dejan en el Working Set incluso si no la están usando. Cuando hay poca memoria, se sacan del working set:

          Delta entre minimum size y maximun size no debe ser > 500MB

· \Process(*)Thread Count (el número de threads activos en el proceso):

          Para 2GB de memoria máxima, se recomienda un umbral de 6600 threads.

· \Process(*)\Handle Count (Determina cuantos handles ha abierto un proceso, un número grande indica leaks de handles o un procesamiento agresivo)

          >3000 handles indica un comportamiento sospechoso. Algunas excepciones son  System (20.000 handles), lsass.exe (30000), store.exe (50000), sqlsrvr.exe (50000)

• Utilizar siempre A records para los DNS de los servidores de SQL, ya que es necesario para configurar kerberos.
• Siempre mantener el servidor con los últimos patchs disponibles. En cada patch no sólo se solucionan bugs, sino se agregan mejoras de performance.
• Reinicios sanitarios: es recomendado reiniciar una vez por mes.

Links útiles #39 Sharepoint 2013

1-Configuración de SQL Server 2012 Always On para Sharepoint 2013

El documento nos explica como configurar la nueva feature de SQL Server 2012 Always On para Sharepoint 2013

http://technet.microsoft.com/en-us/library/jj715261(d=printer,v=office.15).aspx

2-Agregar Titles (Promoted Links) para Sharepoint 2013 y Sharepoint Online

Los siguientes links nos explican como crear una estructura estilo Titles de Windows 8 para Sharepoint 2013 y Sharepoint 2013.

http://geeks.ms/blogs/ciin/archive/2013/03/30/sharepoint-2013-como-agregar-tiles-a-una-p-225-gina.aspx

http://geeks.ms/blogs/ciin/archive/2013/04/12/sharepoint-2013-amp-sharepoint-online-sitios-promovidos-en-el-perfil-personal-de-un-usuario-i.aspx

3-Campo Geolocation – extracción de datos GPS de forma automática.

El artículo nos explica cómo obtener los datos de GPS de las fotos de forma automática, y subirlas a un campo de geolocation.

http://www.martinhatch.com/2013/04/automatically-extracting-gps-data-from.html

4-Site Mailbox en Sharepoint Online

El artículo nos explica la integración de Exchange y Sharepoint, en Office 365.

http://www.astaticstate.com/2013/04/email-and-process-automation-with.html

5-Cambiar la master page de un site de Sharepoint Online mediante CSOM

El artículo nos explica como cambiar la master page mediante javascript (CSOM)

https://www.nothingbutsharepoint.com/sites/devwiki/articles/Pages/SharePoint-Online-Changing-Master-Page-through-CSOM.aspx

http://www.sharemuch.com/2013/03/02/how-to-provision-entire-site-branding-as-a-sharepoint-2013-app/

Links útiles #29 Sharepoint 2013

1-Introducción a WOPI en Office Web Apps 2013

El siguiente articulo nos introduce en una nueva feature de Office Web Apps llamada WOPI (Web Application Open Platform Interface), el cual provee funcionalidades para ver y editar documentos desde apps externas

http://blogs.msdn.com/b/officedevdocs/archive/2013/03/20/introducing-wopi.aspx

2-Translations en Sharepoint 2013

Los siguientes artículos nos muestran como usar la feature Translations de Sharepoint 2013

http://blog.amtopm.be/2013/03/10/using-export-translations-and-import-translations/

http://www.mavention.com/blog/support-translation-sharepoint-2013

3-Remote Blob Staorage (RBS) para Sharepoint 2013

El siguiente artículo nos indica como activar implement Remote Blob Storage (RBS) usando FileStream Provider.

 

http://stevemannspath.blogspot.com.ar/2012/07/bang-two-pound-four-remote-blob-storage.html

4-Tuning SQL Server 2012 para Sharepoint 2013

Los siguientes videos nos guiarán para configurar SQL Server 2012 de forma correcta para soportar Sharepoint 2013 con las mejores prácticas.Super recomendado.

• Mod 01: Key SQL Server and SharePoint Server Integration Concepts
• Mod 02: Best Practices for SQL Server Database Settings
• Mod 03: Server Settings for SQL Server
• Mod 04: SQL Server and SharePoint Availability

5-Comparación de Office 365 (Sharepoint Online) con Sharepoint 2013 On-premise

En el siguiente se publica una matrix de comparación de Sharepoint Online y Sharepoint 2013 On Premise.

https://skydrive.live.com/?cid=bdded38f29ae68b5&id=BDDED38F29AE68B5%21475#!/view.aspx?cid=BDDED38F29AE68B5&resid=BDDED38F29AE68B5%216076&app=Excel

Tips Info #96 Sharepoint 2010

1-Web Analytics jobs

Web Analytics tiene varios jobs:

• Microsoft SharePoint Foundation Site Inventory Usage Collection – Por default, este job corre diariamente. Es responsable de coleccionar el inventario de información de sites de cada site collection en la granja. Este job es el primero que debe ejecutarse.
• Microsoft SharePoint Foundation Usage Data Import – Por default, este job corre cada 30 minutos. Es responsable de importar datos de uso y guardarlos en la base de logging.
• Microsoft SharePoint Foundation Usage Data Processing – Por default, este job corre diariamente. Es reponsable de procesar los datos que han sido acumulados y guardarlos en la base de Staging.
• Web Analytics Trigger Workflows Timer Job – Por default, este job corre diariamente. Es responsable de iniciar los workflows que permite la distribución automática de los reportes de analytics.

2-No hay datos de web analytics en Sharepoint 2010

Verificar 1: el servicio de analytics se esté ejecutando

Central Administration > Application Management > Service Applications > Manage Services on Server

Verificar que estén iniciados los siguientes servicios:

• Web Analytics Data Processing Service

• Web Analytics Web Service

Verificar 2: Configurar correctamente Usage Data reporting

Central Administration > Monitoring > Reporting > Configure usage and health data collection

Verificar que el usage data collection esté habilitado.

Verificar 3: configurar correctamente la definición de jobs

Central Administration > Monitoring > Timer Jobs > Review job definitions

• Microsoft SharePoint Foundation Usage Data Import (30 minutos)

• Microsoft SharePoint Foundation Usage Data Processing  (diario)

• Microsoft SharePoint Foundation Site Inventory Usage Collection  (diario)

Verificar 4: verificar permisos de la carpeta de usage logs

Default: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS\

Verifica los siguientes permisos de grupos de seguridad:

• WSS_Admin_WPG: everything but Full Control

• WSS_RESTRICTED_WPG: read and write

• WSS_WPG: read and write

Verificar 5: verificar que esté prendida la feature a nivel de site collection

Site Collection Administration -> Site Collection Features -> Advanced Web Analytics

Verificar 6: verificar que el servicio de windows SPTraceV4 esté iniciado

Recuerda que tarda 24 hs en procesar la información completa.

4-The Server is busy now – Try again later

SharePoint incluye un sistema para la limitación de diversos contadores de rendimiento de Windows Server 2008 y para la limitación (es decir, el bloqueo) de las solicitudes HTTP, si alguno de dichos contadores indica que un servidor se encuentra muy ocupado para atender todas las solicitudes que recibe. El sistema de limitación y supervisión puede activarse y desactivarse para una aplicación web de SharePoint específica en la aplicación de Administración central o por medio de un comando de PowerShell (Set-SPWebApplicationHttpThrottlingMonitor). El sistema puede modificarse mediante el modelo de objetos de SharePoint o mediante los cmdlets de la Consola de administración de SharePoint.

Se envía un error HTTP 503 al cliente de las solicitudes bloqueadas.

El Health Score es calculated desde un conjunto de Performance Counters. Por default se usa dos erformance counters para esto:

Memory/Available MBytes
ASP.NET/Requests Current

Puedes consultar estos contadores mediante el siguiente comando:

Get -SPWebApplicationHttpThrottlingMonitor http://url_web_application

Una calculadora de puntuación de estado convierte un valor sin formato de un contador de rendimiento (o el resultado de alguna función aplicada a varios valores sin formato) en una puntuación de estado de 0 a 10, donde 0 representa la puntuación con el mejor estado posible del contador y 10 representa la puntuación con el peor estado.

Más información en los siguientes links:

http://www.wictorwilen.se/sharepoint-2013-sharepoint-health-score-and-throttling-deep-dive

http://blogs.msdn.com/b/besidethepoint/archive/2010/09/13/http-request-throttling-in-sharepoint-2010.aspx

http://blogs.msdn.com/b/besidethepoint/archive/2010/09/14/http-request-throttling-in-sharepoint-2010-part-2.aspx

http://msdn.microsoft.com/en-us/library/ff407390(v=office.14).aspx

5-Migrar bases de datos de SQL Server a otro servidor de SQL

Detener todos los servicios de windows

• SharePoint 2010 Administration
• SharePoint 2010 Timer
• SharePoint 2010 Tracing
• SharePoint 2010 User Code Host
• SharePoint 2010 VSS Writer
• SharePoint Foundation Search V4
• World Wide Web Publishing Service
• SharePoint Server Search 14
• Web Analytics Data Processing Service
• Web Analytics Web Service

Detener el IIS

• iisreset /stop

Detach de todas las bases de datos del SQL Server viejo

Mover todos los archivos (.ldf, .mdf y .ndf) de base de datos al nuevo SQL Server y realizar un attach de los mismos

Migrar las user accounts y permisos del servidor viejo al nuevo

http://support.microsoft.com/kb/918992

Verifica que los puertos del nuevo SQL Server estén abiertos

Agrega el alias del sql server nuevo en el servidor de Sharepoint mediante cliconfig

Inicia todos los servicios de windows

• SharePoint 2010 Administration
• SharePoint 2010 Timer
• SharePoint 2010 Tracing
• SharePoint 2010 User Code Host
• SharePoint 2010 VSS Writer
• SharePoint Foundation Search V4
• World Wide Web Publishing Service
• SharePoint Server Search 14
• Web Analytics Data Processing Service
• Web Analytics Web Service

Has un iisreset /start