Mejoras al rendimiento de Project Server 2007 [Parte 1]

Este artículo es el primero de una serie de artículos sobre la mejora en el rendimiento de Project Server.  En este  primer documento se describen buenas prácticas de mantenimiento de la base de datos de Project Server 2007, lo que incluye fundamentalmente:

  1. La verificación de la integridad de la BD
  2. La desfragmentación de índices, reorganizándolos o reconstruyéndolos.
  3. La configuración del “fill factor”
  4. El monitoreo del tamaño de la base de datos

En el documento se explica en detalle los puntos 1 y 2. Para mayor información sobre los puntos 3 y 4, consultar el siguiente artículo: http://surpoint.blogspot.com.ar/2012/03/sharepoint-2007monitoreo-de-la-la-base.html

Incluye además pruebas realizadas en un ambiente de estas características:

  • Project Server 2007 con Services Pack 3
  • Windows SharePoint Services 3.0 con Services Pack 3
  • SQL Server 2005 con Service Pack 4(importante, no aplicar este procedimiento si no se aplicó SP2 de SQL Server)

 

Introducción

Antes de comenzar, es importante recordar que Project Server tiene 4 bases de datos:

  • Draft
  • Published
  • Archive
  • Reporting

Draft soporta la información de los proyectos aún no publicados, no tiene comunicación con Project Web Access. Maneja también las tablas utilizadas por el servicio de cola de Project Server.

Published almacena los proyectos publicados que pueden ser accedidos desde PWA. También incluye información específica de PWA como timesheets, vistas o la definición propia de los campos personalizados.

Archive almacena copias de seguridad en línea.

Reporting contiene la información de Published, pero optimizada para reportes y para la carga de los cubos OLAP. Se actualiza prácticamente en tiempo real, es sencilla de entender y está optimizada para operaciones de lectura.

Además existen las bases de datos de SharePoint:

  • Una o más bases de datos de contenido.
  • La base de datos de configuración de SharePoint.
  • Una o más bases de datos de SSP.

Más información en: http://technet.microsoft.com/en-us/library/cc973099(v=office.12)

 

Antes de comenzar

Antes de comenzar con las tareas e mantenimiento, verificar que:

  • Tengamos los backups de nuestras bases de datos
  • Sepamos el tiempo de ejecución de las tareas y el impacto que puedan ocasionar
  • Planificar la ejecución de estas tareas, fuera del horario de trabajo, dentro de lo posible

Algunas buenas prácticas a tener en cuenta para nuestro plan de mantenimiento:

  • Aplicar reorganización de índices o reconstrucción, no ambas.
  • Comenzar siempre por el chequeo de integridad y no continuar si este falla.
  • En SharePoint, la única base sobre la que puede ser necesario reducir tamaño (shrink) es la base de contenido. No suele ser necesario y podría generar fragmentación si lo hacemos sobre las bases de configuración, SSP, búsqueda o incluso la BD de contenido de Central Administration.

Algunas otras recomendaciones pueden ser consultadas en este artículo: http://technet.microsoft.com/en-us/library/cc973104(v=office.12)

 

Verificación de integridad de la Base de Datos

Este primer paso se ejecuta para cada base de datos desde SQL Server Management Studio. Utilizamos DBCC CHECKDB. Más información en http://msdn.microsoft.com/en-us/library/ms180226.aspx

USE ProjectServer_Draft

DBCC CHECKDB

USE ProjectServer_Published

DBCC CHECKDB

USE ProjectServer_Reporting

DBCC CHECKDB

USE ProjectServer_Archive

DBCC CHECKDB

USE WSS_Content

DBCC CHECKDB

USE SharedServices1_DB

DBCC CHECKDB

USE SharePoint_Config

DBCC CHECKDB

Si no encontramos problemas, debería aparecer un mensaje como el siguiente:

DBCC results for ‘ProjectServer_Draft’.

CHECKDB found 0 allocation errors and 0 consistency errors in database ‘SharePoint_Config’.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Las pruebas realizadas en un ambiente de prueba arrojaron estos tiempos:

Base de Datos

Tiempo

Draft

2 minutos

Published

3 minutos

Reporting

2 minutos

Archive

2 minutos

SharePoint – Contenido

1 minuto

SharePoint – Configuración

Despreciable

SharePoint – SSP

Despreciable

Total

10 minutos

 

Desfragmentación de índices – Análisis

Comenzamos por medir el estado de desfragmentación de la base de datos utilizando sys.dm_db_index_physical_stats. Más información en http://technet.microsoft.com/en-us/library/ms188917(SQL.90).aspx

Si especificamos todos los parámetros en nulo, medirá todo lo que tenemos en la instancia de SQL Server. Si necesitamos ejecutarlo para una base en particular, podemos especificar el ID de la base de datos. Para conocer el ID de la base de datos utilizamos BD_ID. Más información en http://technet.microsoft.com/en-us/library/ms186274(v=sql.90).aspx

Para comenzar, vamos a verificar los índices de la base de datos Draft de la siguiente forma:

USE ProjectServer_Draft

SELECT DATABASE_ID,

CAST(DB_NAME(DATABASE_ID) AS VARCHAR(30)) AS ‘DatabaseName’,

CAST(OBJECT_NAME([OBJECT_ID]) AS VARCHAR(40)) AS ‘TableName’,

INDEX_ID,

CAST(INDEX_TYPE_DESC AS VARCHAR(30)) AS INDEX_TYPE_DESC,

AVG_FRAGMENTATION_IN_PERCENT

FROM SYS.DM_DB_INDEX_PHYSICAL_STATS (DB_ID(N’ProjectServer_Draft’),NULL,NULL,NULL,NULL )

ORDER BY AVG_FRAGMENTATION_IN_PERCENT DESC;

Es importante manejarse con cuidado a la hora de pasar parámetros a este procedimiento usando funciones del sistema. Para mayor información, consultar la sección “Using System Functions to Specify Parameter Values” en este enlace: http://msdn.microsoft.com/en-us/library/ms188917.aspx

Debemos esperar un valor que tienda a 0 y que en lo posible no supere el 10% en el campo AVG_FRAGMENTATION_IN_PERCENT.

Obtendremos un resultado de este tipo:

clip_image002

Continuamos con la base Published. El resultado es el siguiente:

clip_image004

Realizamos el mismo proceso con el resto de las bases de datos. A continuación los tiempos de ejecución:

Base de Datos

Tiempo

Draft

Medio minuto

Published

Medio minuto

Reporting

Medio minuto

Archive

1 minuto

SharePoint – Contenido

Medio minuto

Total

Las acciones a tomar pueden depender del nivel de fragmentación:

Acción

Nivel de fragmentación

Reorganización

Hasta 10%

Reonstrucción

10% a 75%

Reconstrucción fuera de línea

Más del 75%

En SharePoint no están soportados los comandos DROP INDEX y CREATE INDEX, en su lugar se debe usar ALTER. En rigor, para desfragmentar los índices de SharePoint, se recomienda ejecutar el procedimiento almacenado tal como se indica en este artículo: http://support.microsoft.com/kb/943345/en-us

Para ProjectServer, utilizaremos un asistente de plan de mantenimiento de Base de Datos.

 

Desfragmentación de Índices – Ejecución

Antes de comenzar con las tareas de re construcción de índices, vamos a tomar los tiempos que lleva la publicación de un proyecto de 2.000 tareas. Vemos en la pantalla de la cola de Project Server los resultados obtenidos: 7 minutos

clip_image006

Vamos a ejecutar el proceso de reconstrucción de índices paras las base de datos de Project Server (ya mencionamos anteriormente que el procedimiento es diferente al recomendado para SharePoint).

Para ello, creamos un plan de mantenimiento con la única opción de reconstruir los índices, recordar que ya habíamos verificado la integridad de la base de datos anteriormente. En un plan productivo, deberíamos incluir más opciones. Más información sobre planes de mantenimiento en estos enlaces:

En la siguiente imagen se ve desde dónde comenzar la creación de un plan de mantenimiento en SQL Server Management Studio:

clip_image008

Estas son las opciones elegidas:

clip_image010

Nuevamente, se necesita SP2 de SQL Server 2005, para aplicar este procedimiento.

En caso contrario, no sólo no es seguro, sino que podemos romper la base de datos.

clip_image012

clip_image014

Elegimos el lugar en donde dejar el log: C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLLOG. Luego ejecutamos el plan de mantenimiento.

Importante:

  • Ejecutar en ambiente de prueba
  • Trabajar en conjunto con un DBA
  • Asegurarse de tener los procedimientos de backup activos.
  • Asegurarse de haber probado los procedimientos de restore.

Esta es la pantalla de inicio de la ejecución:

clip_image016

Esta es la pantalla de fin:

clip_image018

Una vez finalizado el plan, vamos a revisar el estado de fragmentación de los índices, en este caso de la base Published. El resultado se ve en la siguiente imagen:

clip_image020

Algunos cambios como el resaltado son importantes.

Al publicar nuevamente el mismo proyecto, se observa una mejora de 2 minutos, que en este caso equivale al 28% (la medición no es científica).

clip_image022

 

Conclusión

Realizar tareas de mantenimiento sobre SQL Server es una tarea relativamente sencilla, pero fundamental, ya que estamos hablando de un componente central de la arquitectura, que puede impactar en el rendimiento general.

En el caso de Project Server, la desfragmentación de índices es importante, pero debería ser combinada con otros puntos como:

  • Monitoreo de consultas de SQL
  • Monitoreo de memoria y procesador
  • Monitoreo de tamaño de la base de datos y de los logs de transacciones
  • Mantenimiento específico de las bases de datos de SharePoint
  • Monitoreo de red

Nos vemos en el próximo artículo de la serie.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *