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:
- La verificación de la integridad de la BD
- La desfragmentación de índices, reorganizándolos o reconstruyéndolos.
- La configuración del “fill factor”
- 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:
Continuamos con la base Published. El resultado es el siguiente:
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
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:
- http://technet.microsoft.com/library/ms189036(SQL.90).aspx (Maintenance Plan Wizard)
- http://www.epmfaq.com/ssanderlin/project-server-2007/maintenance-plans-for-project-server-2007-dbs (Maintenance Plans for Project Server 2007 DBs)
En la siguiente imagen se ve desde dónde comenzar la creación de un plan de mantenimiento en SQL Server Management Studio:
Estas son las opciones elegidas:
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.
Elegimos el lugar en donde dejar el log: C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG. 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:
Esta es la pantalla de fin:
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:
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).
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.
0 comentarios:
Publicar un comentario