Es más que conveniente, necesario, seguir las indicaciones del siguientes artículo de soporte de Microsoft "Compatibilidad con los cambios en las bases de datos que utilizan productos de servidor de Office y Windows SharePoint Services" (http://support.microsoft.com/kb/841057/en-us) , puesto que si no seguimos sus indicaciones a raja tabla a nivel de operaciones en las bases de datos en SQL Server, podemos encontrarnos con que hemos perdido el soporte de nuestro producto.
Aparte de no "tocar" directamente en las bases de datos, es decir, modificar, eliminar o insertar valores, fundamentalmente no debemos crear procedimientos almacenados ni índices de los propuestos por las herramientas de administración de SQL Server para mejorar el rendimiento de consultas.
Sobre el primer punto, la modificación directa sobre las tablas de las bases de datos, nos encontramos una pega, puesto que en ocasiones ante fallos en la instalación de parches puede que tengamos que eliminar los registros de los trabajos de actualización fallidos, tal y como expliqué en el post "Procedimiento de instalación de parches en WSS y MOSS".
Respecto de los procedimientos almacenados, nos choca que en uno de los "white papers" de ajuste de rendimiento de las bases de datos de SharePoint se nos instaba a generar un procedimiento que debíamos ejecutar a modo de plan de mantenimiento de SQL Server. Sobre esto, hice alusión en el post "Mantenimiento de base de datos de Office SharePoint Server 2007" Es curioso, pero en concreto la parte de dicho mantenimiento que hacía alusión en el KB "Cómo desfragmentar bases de datos de Windows SharePoint Services 3.0 y bases de datos de SharePoint Server 2007" ya no nos la recomiendan desde soporte, aunque siga publicada en la documentaciól oficial de Microsoft, así que cuidado con ello. Conclusión: no seguir el KB y no crear los procedimientos almacenados.
Por último, cualquier buen DBA de SQL Server a la hora de hacer el "tunning" de base de datos analizará la creación de índices propuestos por las herramientas de administración para ganar en velocidad y mejorar en rendimiento de aquellas consultas pesadas. En el caso de las bases de datos de SharePoint, deberemos por tanto obviar dicha creación de índices y sufrir los tiempos que puedan estarse generando en determinadas tablas de gran volumen.
Aparte de no "tocar" directamente en las bases de datos, es decir, modificar, eliminar o insertar valores, fundamentalmente no debemos crear procedimientos almacenados ni índices de los propuestos por las herramientas de administración de SQL Server para mejorar el rendimiento de consultas.
Sobre el primer punto, la modificación directa sobre las tablas de las bases de datos, nos encontramos una pega, puesto que en ocasiones ante fallos en la instalación de parches puede que tengamos que eliminar los registros de los trabajos de actualización fallidos, tal y como expliqué en el post "Procedimiento de instalación de parches en WSS y MOSS".
Respecto de los procedimientos almacenados, nos choca que en uno de los "white papers" de ajuste de rendimiento de las bases de datos de SharePoint se nos instaba a generar un procedimiento que debíamos ejecutar a modo de plan de mantenimiento de SQL Server. Sobre esto, hice alusión en el post "Mantenimiento de base de datos de Office SharePoint Server 2007" Es curioso, pero en concreto la parte de dicho mantenimiento que hacía alusión en el KB "Cómo desfragmentar bases de datos de Windows SharePoint Services 3.0 y bases de datos de SharePoint Server 2007" ya no nos la recomiendan desde soporte, aunque siga publicada en la documentaciól oficial de Microsoft, así que cuidado con ello. Conclusión: no seguir el KB y no crear los procedimientos almacenados.
Por último, cualquier buen DBA de SQL Server a la hora de hacer el "tunning" de base de datos analizará la creación de índices propuestos por las herramientas de administración para ganar en velocidad y mejorar en rendimiento de aquellas consultas pesadas. En el caso de las bases de datos de SharePoint, deberemos por tanto obviar dicha creación de índices y sufrir los tiempos que puedan estarse generando en determinadas tablas de gran volumen.
No hay comentarios:
Publicar un comentario