Las intercalaciones de SQL Server y MOSS 2007

Recientemente he realizado varios SharePoint RAP's y me he encontrado algo que cada vez es más común en las granjas de SharePoint, algunos de los clientes no consideran a SharePoint una aplicación crítica para el negocio y deciden compartir SQL Server con otras aplicaciones que igualmente no son críticas o que tienen alguna interacción con SharePoint, desafortunadamente y aunque los clientes saben que esto no es recomendado debido a los problemas de desempeño que se pueden presentar lo siguen haciendo y tratan de "mejorar" la parte de compartir el motor de base de datos creando instancias para cada aplicación. Creando instancias los administradores de bases de datos son capaces de configurar las intercalaciones (collation) dependiendo de la necesidad de cada aplicación, por lo que el entorno general de SQL Server maneja un tipo de intercalación y cada instancia por particular otro.

Pero antes de continuar definamos que es la intercalación en SQL Server (https://msdn.microsoft.com/es-es/library/ms187582(v=SQL.105).aspx):

Las intercalaciones especifican las reglas que determinan la forma en que las cadenas de caracteres se ordenan y comparan en función de las normas de cada idioma y configuración regional. Por ejemplo, en una cláusula ORDER BY, un angloparlante esperaría que la cadena de caracteres 'Chiapas' se mostrara antes que 'Colima' en orden ascendente. Sin embargo, un hispanoparlante de México esperaría que las palabras que empiezan con 'Ch' se mostraran al final de una lista de palabras que empiezan por 'C'. Las intercalaciones establecen estos tipos de reglas para la ordenación y comparación. La intercalación Latin_1 General ordenará 'Chiapas' delante de 'Colima' en una cláusula ORDER BY ASC, mientras que la intercalación Traditional_Spanish ordenará 'Chiapas' después de 'Colima'.

Cuando se especifica una intercalación para los datos de caracteres que no son Unicode, como los datos char, varchar y text, se asocia una página de códigos determinada con la intercalación. Por ejemplo, si la columna char de una tabla se define con la intercalación Latin1_General, los datos de esa columna son interpretados y mostrados por SQL Server mediante la página de códigos 1252. Para obtener más información acerca de las páginas de códigos y las intercalaciones, vea Arquitectura de página de códigos.

Varias intercalaciones pueden utilizar la misma página de códigos en datos no Unicode.

Las intercalaciones especificadas para datos de solo Unicode, como nchar, nvarchar y nvarchar(max), no tienen páginas de códigos asociadas. Los datos Unicode tratan la mayoría de caracteres universales. Para obtener más información, vea Trabajar con datos Unicode.

La intercalación de SQL Server se convierte en un factor importante al momento en el que los administradores de SharePoint generan un esquema de repaldos y pruebas de restauración, me he encontrado con un problema común cuando las pruebas de respaldos se ponen en práctica. ¿Qué pasa si yo tomo un respaldo completo de la granja de SharePoint utilizando el sitio de la Administración Central de SharePoint o utilizando stsadm, que tipo de intercalación es la que se almacena en el respaldo, la configurada en el motor de base de datos o la configurada para la instancia donde las bases de datos de SharePoint viven?, ¿Que pasa cuando el DBA instala un nuevo SQL Server para realizar las pruebas de respaldo y no toma en cuenta el tipo de intercalación de la instancia de SharePoint?, peor aún ¿Qué pasa cuando no existe un DBA y el administrador de SharePoint tiene que instalar SQL Server y no tiene ni idea de que variables debe tomar en cuenta?

Pareciera no ser un tema importante y que instalar SharePoint o restaurar una granja completa de SharePoint es algo más sencillo de lo que parece. Pues déjenme platicarles mi ultima experiencia, un cliente con una granja de SharePoint pequeña experimentó este inconveniente con las intercalaciones de su SQL Server, desafortunadamente para ellos no existía un DBA y los administradores de SharePonit no tenían conocimiento de este elemento de configuración, después de una mala implementación de flujos de trabajo, tuvieron un problema con el espacio en bases de datos y dicha aplicación dejó de operar. Finalmente resolvieron el problema de los flujos de trabajo pero no tenian un respaldo de SharePoint de ningún tipo, por ahí hacian respaldos de colecciones de sitios usando stsadm pero nada más. Intentaron crear una granja alterna de SharePoint para realizar pruebas de restauración pero instalaban SQL Server por defecto.

Resulta, y respondiendo a las preguntas en el párrafo anterior al ejemplo de éste cliente, que podían hacer respaldos de SharePoint usando CA o stsadm y mediante las herramientas de SQL Server pero cuando trataban de restaurar en otro SQL Server fallaba, si lo hacian por medio de CA o stsadm recibían un mensaje sobre que el respaldo falló debido a un objeto en la base de datos y si lo hacían por medio de SQL Server el mensaje decia que el esquema de la base de datos que se quiere restaurar no corresponde al esquema actual en el motor de base de datos.

1. Al hacer un respaldo de SharePoint usando CA o stsadm la configuración de las intercalaciones es la que refiere a la instancia de SQL Server no al motor de SQL Server.

2. Si el DBA instala SQL Server por defecto sin tomar en cuenta la configuración de la intercalación de la instancia de SharePoint, será imposible restaurar un respaldo de bases de datos que tiene una configuración de intercalación distinta.

3. Si el administrador de SharePoint no tiene experiencia con SQL Server no se dará por enterado de que se puede configurar de manera personalizada la configuración de intercalación de SQL Server y las pruebas de restauración de SharePoint no tendrán éxito.

Para Microsoft Office SharePoint Server 2007 (MOSS) la intercalación debe ser configurada como case-insensitive, accent-sensitive, kana-sensitive y with-sensitive, esto para asegurar que los nombres de archivos sean consistentemente únicos con el sistema operativo (https://technet.microsoft.com/en-us/library/cc288970(office.12).aspx), sin embargo cualquier intercalación CI (Case-Insensitive) es soportada (https://support.microsoft.com/kb/2008668). El cambio de intercalación no es soportado por Microsoft para bases de datos de SharePoint.

Nota: Si la intercalación de SQL Server no es Case-Insensitive o comparaciones Non-Binary no podrán provisionar la granja de SharePoint al momento de ejecutar el asistente de configuración.

Bien pues espero ésto les sirva y recuerden que cuando generen su esquema de respaldos y pruebas de restauración deben documentar que tipo de intercalación tiene el motor de SQL Server actual o bien la instancia de SQL donde las bases de datos de SharePoint viven, y no olviden no esta recomendado compartir SQL Server con otras aplicaciones por cuestiones de desempeño.