Recently I've worked in some SharePoint RAP's and I've found something which is most common in SharePoint farms, customers share SQL Server to host several applications, since many times SharePoint is not considered as a critical application its databases are allocated in a shared SQL Server, unfortunatelly and eventhough customers know that this is not recommended because of performance issues they still doing it. Customer creates different SQL Server instances to host different applications, sometimes other applications uses a different collation to reach business needs. Therefore SQL Server engine uses a specific collation and every instance configured a different one.
First will define SQL Server Collation (http://msdn.microsoft.com/en-us/library/ms187582(v=SQL.105).aspx):
Collations specify the rules for how strings of character data are sorted and compared, based on the norms of particular languages and locales. For example, in an ORDER BY clause, an English speaker would expect the character string 'Chiapas' to come before 'Colima' in ascending order. However, a Spanish speaker in Mexico might expect words beginning with 'Ch' to appear at the end of a list of words starting with 'C'. Collations dictate these kinds of sorting and comparison rules. The Latin_1 General collation will sort 'Chiapas' before 'Colima' in an ORDER BY ASC clause, whereas the Traditional_Spanish collation will sort 'Chiapas' after 'Colima'.
When a collation is specified for non-Unicode character data, such as char, varchar, and text data, a particular code page is associated with the collation. For example, if a char column in a table is defined with the Latin1_General collation, the data in that column is interpreted and displayed by SQL Server using the 1252 code page. For more information about code pages and collations, see Code Page Architecture.
Multiple collations can use the same code page for non-Unicode data.
Collations specified for Unicode-only data, such as nchar, nvarchar, and nvarchar(max), do not have associated code pages. Unicode data handles most universal characters. For more information, see Working with Unicode Data.
SQL Server collation becomes an important thing when a SharePoint farm will be provisioned or when SharePoint admins are creating a backup/restore plan, I've seen a common problem when database restore tasks are implemented. What does it happen when a full backup is performed using CA or stsadm, what type of collation is saved, SQL's or SharePoint instance?, What does it happen when DBA installs a new SQL Server for testing and restoration processes and does not care about collation? worst what does it happen when a DBA role does not exist in the organization and SharePoint administrators have to install SQL Server and they do not know how to install it?
It does not seem to be important and install SharePoint or restore and entire SP Farm is so easy. Let me tell you that in my last experience a customer with a small SharePoint farm experienced this problem with SQL Server collation, there is no a dba and SharePoint admins do not have SQL knowledge, after a bad SharePoint workflow experience they had an issue with database available space and a custom application stopped working because of the lack of disk space. Finally they got fix the workflow issue but they did not have any SharePoint backup, some Site Collection backups were done in the past but they were not certain that those backups were healthy, then they install a new test SharePoint farm using SQL Server defaults.
Well answering the previous questions using customer example every attempt to restore a database failed, if they tried usign CA or stsadm they got a message about a database object failure or if they try with SQL Server tools they got a database schema inconsistency.
1. When a SharePoint database backup is done the collation saved is the one to refers to the SharePoint instance not SQL Server engine.
2. If DBA installs SQL Server by default without paying attention to collation already configured for SharePoint databases, we cannot restore the SharePoint database backup.
3. If SQL Server collation is not set properly, restore tasks will not work.
The SQL Server database collation must be configured for case-insensitive, accent-sensitive, Kana-sensitive, and width-sensitive. This is to ensure file name uniqueness consistent with the Windows operating system (http://technet.microsoft.com/en-us/library/cc288970(office.12).aspx), however, we do not support changing the default collation (Latin1_General_CI_AS_KS_WS) for SharePoint databases to any other collations (CI, AS, KS, WS). We support any CI collation for the SQL instance (for master, tempdb databases). However we recommend using SQL_Latin1_General_CP1_CI_AS as the instance (master, tempdb databases) collation since that’s where the bulk of our testing has been (http://support.microsoft.com/kb/2008668).
Note: If SQL Server collation is not Case-Insensitive and Non-Binary comparisons SharePoint farm cannot be installed.
Hope this help you when you're planning to deploy a SharePoint farm or building backup/restore plans, before document SQL Server configurations and do not forget that sharing SQL Server for SharePoint is not recommended.
FYI: Pay attention to Windows Server 2008 hotfix KB979917 , this hotfix can be required if you are using web applications with CLAIMS as authentication provider, you can see the following message "The Health Analyzer reports that web applications using claims authentication require an update to fix potential security risks. This is described in the KB article KB979917 that the hotfix can be obtained by contacting Microsoft Support."
Before to apply this hotfix directly on production SharePoint farms update SharePoint to February 2010 CU and test it. If you are not using CLAIMS over SharePoint do not apply the hotfix on SharePoint servers, specially if this is not required.
You will probably see the following messages on event viewer application logs:
Search crawl component index path error - Events 2589 (SharePoint Server 2010)
Search gatherer disk is full - Event 23 (SharePoint Server 2010)
Search database out of space - Event 52 (SharePoint Server 2010)
Search indexer initialization index failed - Event 71 (SharePoint Server 2010)
Search indexer low disk space - Event 80 (SharePoint Server 2010)
Search administration component failed - Event 121 (SharePoint Server 2010)
Note: Search issues could be faced after applying the fix.
While we were drinking caipiriñas on Brazil, the SQL PFE’s were sharing some of our experiences on clients, and one of them was corrupt pages on SQL Server.
First of all, ¿What is a page? On the SQL Server context a page is the smallest unit of allocation of data, with 8KB of size. For more information visit: http://msdn.microsoft.com/en-us/library/ms190969(v=SQL.105).aspx (Pages and Extents)
Now, ¿Why does pages get corrupted? There's not a specific cause for this, but generally it’s because of hardware failures.
Here we have three simple steps to identify if they exist on a database:
DBCC CHECKDB ('NombreBasedeDatos') WITH ALL_ERRORMSGS
GO
SELECT *
FROM msdb..suspect_pages
WHERE (event_type = 1 OR event_type = 2 OR event_type = 3)
Once you have identified the corrupt page, you can solve the problem with the following steps:
DBCC CHECKDB (NombreBasedeDatos, REPAIR_REBUILD)
USE master
RESTORE DATABASE Northwind
PAGE = '1:265'
FROM DISK = N'D:\DBBackup\NorthwindBackup.bak'
There are a few restrictions to use this feature; in general, you can’t use page level restoration on the following pages:
For more information: http://msdn.microsoft.com/en-us/library/ms175168.aspx (Page Restoration)
As a last resort you could use the command REPAIR_ALLOW_DATA_LOSS with DBCC CHECKDB, however we don’t recommend this options, because it will allow the loss of data without assurance of the page recovery.
We’ll keep drinking the caipiriñas while talking about SQL Server. Until the next blog!
“The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft”
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 (http://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 (http://technet.microsoft.com/en-us/library/cc288970(office.12).aspx), sin embargo cualquier intercalación CI (Case-Insensitive) es soportada (http://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.
FYI: Pongan mucho cuidado al hotfix KB979917 de sistema operativo (Windows Server 2008) posiblemente si están experimentando algún problema con alguna aplicación web que contiene un proveedor de autenticación basado en CLAIMS éste hotfix podría ser requerido "El analizador de salud reporta que aplicaciones web usando autenticación basada en CLAMIS requeiren una actualización para reparar un potencial riesgo de seguridad. Éste está descrito en el artículo de la base de datos de conocimiento KB979917 y puede ser obtenido contactando al Soporte de Microsoft"
Antes de aplicar dicho Hotfix asegurence de tener instalado el Update Acumulativo de Febrero de 2010 y hacer sus pruebas en un ambiente distinto al de producción. Si ustedes no tienen aplicaciones web que usen CLAIMS eviten instalarlo en la medida de lo posible sobre todo si no ha sido requerido.
Ustedes podrían visualizar los siguientes mensajes en el log de aplicaciones:
Los problemas que pudieran experimentar en SharePoint son variados como por ejemplo las búsquedas pueden dejar de funcionar.
Mientras nos tomábamos unas caipiriñas en Brasil, el grupo de PFE de SQL estuvimos compartiendo algunas experiencias en clientes y una de ellas fue la corrupción de páginas en SQL Server.
Primero que nada, ¿Qué es una página?, en el contexto de SQL Server es la unidad mínima de almacenamiento para los datos, con una medida de 8KB. Para mayor información, consulta en http://msdn.microsoft.com/es-es/library/ms190969.aspx (Descripción de páginas y extensiones).
Ahora, ¿por qué se corrompen las páginas?, si bien no existe una causa específica, generalmente de debe a fallas a nivel de hardware.
Existen tres pasos simples para identificar si existe el escenario mencionado:
Una vez identificada la página corrupta, puedes solucionar el problema mediante los siguientes pasos:
Existen algunas restricciones para utilizar esta funcionalidad, en general, no es posible utilizar recuperación a nivel de página cuando sea de alguno de los siguientes tipos:
Adicionalmente, será necesario ejecutar pasos adicionales de acuerdo a las opciones que tengamos habilitadas en la base de datos, para mayor información consulta en http://msdn.microsoft.com/es-es/library/ms175168.aspx (Realizar restauraciones de página).
Como última opción puedes usar el comando REPAIR_ALLOW_DATA_LOSS con DBCC CHECKDB, sin embargo no recomendamos usar esta opción ya que permite la pérdida de datos sin asegurar la recuperación de las páginas.
Continuaremos bebiéndonos las caipiriñas mientras platicamos sobre SQL Server. Hasta el próximo blog!
“Las opiniones e ideas expresadas en este blog son las de los Autores y no necesariamente declaran o reflejan la opinión de Microsoft”
Este material tambien lo podras acceder en http://blogs.technet.com/b/sql_pfe_latam/