Archivo de Febrero de 2012 Una práctica que llevan a cabo muchas empresas en sus Granjas corporativas de MOSS 2007 es deshabilitar la creación de Sitios Personales (My Site), una funcionalidad que viene habilitada por defecto. Dado que cada Sitio Personal es una Colección de Sitios asignada a un usuario, una empresa de 20.000 usuarios podría llegar a tener 20.000 Colecciones de Sitios, un coste que muchas empresas no están dispuestas a asumir (ej: almacenamiento, bases de datos de contenido en SQL Server, backup, etc.). Recientemente estuve pegándome con un error en una Granja de MOSS 2007 SP2. Las búsquedas no funcionaban, y al revisar los diferentes servidores de la Granja se podían encontrar errores diversos: Errores con Event ID 1088 de ASP.NET 2.0 (Failed to execute request because the App-Domain could not be created. Error: 0x80070005 Access is denied) en un servidor de Búsqueda, errores con Event ID 6482 de Office SharePoint Server en el Index Server, mensaje Server Application Unavailable al acceder al Web Service SearchAdmin.asmx, etc. Incluso si nuestro trabajo se limita a la administración de SharePoint, disponer de un entorno de desarrollo de MOSS, nos resultará de gran utilidad en diferentes situaciones, tanto para poder resolver incidencias (ej: ver los WorkFlows de SharePoint Designer), como para realizar diferentes tareas administrativas (ej: consultar el tamaño de un SubSite desde SharePoint Designer, o exportar un Site sin incluir sus SubSites), o desarrollar nuestras propias Tools. Por ello, en esta ocasión vamos a explicar cómo montar un entorno de desarrollo de SharePoint, tanto para MOSS 2007 como para MOSS 2010. Un problema que nos podemos encontrar al trabajar con Jobs incrementales de Content Deployment en MOSS 2007 es el famoso error de violación de clave primaria: Violation of PRIMARY KEY constraint PK__#ExportObjects: Cannot insert duplicate key in object dbo.#ExportObjects. Este error, suele implicar la ejecución de consultas costosas y bloqueos en SQL Server, que producen que el Job tarde mucho tiempo en ejecutarse para finalmente finalizar con este error, e incluso bajo algunas circunstancias, producir una pérdida de servicio, requiriendo un reciclado de Application Pools, IISRESET, etc. ¿Qué hacemos? Bajo diferentes circunstancias nos puede interesar consultar en SQL Server sobre qué Base de Datos de Contenido de MOSS (y en que servidor SQL) se almacena una Colección de Sitios determinada, para lo cual, tan sólo tendremos que ejecutar una sencilla consulta SQL sobre la base de datos de configuración de MOSS (SharePoint_Config). Pero ¿Cómo lo hacemos? Un problema que nos podemos encontrar en una Granja de MOSS 2007 con Excel Services, es que algunos usuarios al intentar abrir un fichero Excel, en vez de abrirlo en su Microsoft Office Excel local, sólo puedan abrirlo en formato Web (con Excel Web Access, aún configurando las Bibliotecas de Documentos para utilizar la aplicación cliente Microsoft Excel), lo cual puede ser un serio inconveniente, ya que muchas funcionalidades de Excel no están soportadas por Excel Services, y en ese caso el intento de acceso a Excel terminará en un Error al usuario. Aún más frustrante, cuando a algunos usuarios les ocurre y a otros no. Una problemática típica en cualquier Granja de MOSS es la gestión de las Bases de Datos de Contenido y la creación de nuevas Colecciones de Sitios, especialmente cuando estamos utilizando múltiples Bases de Datos de Contenido en una misma Aplicación Web. En este caso ¿Cómo podemos controlar sobre qué Base de Datos de Contenido se va a crear una nueva Colección de Sitios? ¿Cómo podemos organizar las Bases de Datos de Contenido en una Aplicación Web sobre la que se crea una gran cantidad de Colecciones de Sitios de forma automática (ej: My Sites)? Hasta el momento, hemos visto cómo pueden producirse los eventos de traza Hash Warning / Sort Warning como resultado de la reutilización de un Plan de Ejecución con Operadores Costosos entre invocaciones con diferentes valores de los parámetros de entrada, incurriendo en una subestimación de Memoria de Consulta. El presente artículo muestra un caso diferente, en particular, la ocurrencia de eventos Hash Warning y Sort Warning como resultado de unas estadísticas incorrectas o poco actualizadas, para lo cual hemos falseado las estadísticas con UPDATE STATISTICS WITH ROWCOUNT o PAGECOUNT. En esta quinta entrega de la serie de artículos sobre los eventos de traza Hash Warning y Sort Warnings, vamos a realizar un ejemplo paso a paso para reproducir un evento Hash Warning y evidenciar la penalización de rendimiento por el acceso a TEMPDB (debido a la subestimación de memoria de consulta por la reutilización del Plan de Ejecución) y por la utilización de un Operador incorrecto en el Plan de Ejecución (Hash Match vs Merge Join). |
