¿Tiene alguna complicación con la base de datos de SQL Server que tenga una clasificación diferente a la del servidor?

Question

Estamos en el proceso de migrar las bases de datos de un antiguo servidor SQL Server 2k EE con la intercalación predeterminada "Latin1_General_CI_AS" en los nuevos servidores SQL Server 2005 & 2008 con la intercalación predeterminada "SQL_Latin1_General_CP1_CI_AS". No hay caracteres internacionales que requieran Unicode que yo sepa, por lo que las dos páginas de códigos son casi las mismas para fines prácticos.

El DBA principal de SQL Server es inflexible en que cada base de datos (la mayoría de las cuales están compiladas por aplicaciones de terceros) debe reconstruirse con la nueva intercalación antes de migrarlas.

Sé que desde SQL Server 2000 ha sido posible establecer bases de datos individuales para tener una clasificación diferente de la predeterminada. ¿Pero cuáles son las consecuencias reales de correr con intercalaciones mixtas?One article from Microsoft sugiere complicaciones con el tempdb compartido, por ejemplo (¿pero se puede evitar fácilmente?).

Y, quizás lo más importante, ¿qué podemos hacer para evitar estos problemas si necesitamos admitir múltiples intercalaciones en los nuevos servidores?

Answer 1

bien no es la mejor respuesta, pero

Se preguntó: "¿Cuáles son las consecuencias reales de ejecución con diferentes colaciones" Puede ser un dolor de cabeza. El artículo que mencionaste por Microsoft lo clava en la cabeza. En mi experiencia personal, me he encontrado con ese problema y no fue fácil de evitar. Las intercalaciones no coincidentes aparecerán en lugares no planificados a menos que lo pruebe bien.

También preguntó "¿qué podríamos hacer para evitar estos problemas si necesitamos admitir varias intercalaciones en los nuevos servidores?" Nada viene a la mente, excepto para probar como loco.

Realmente les deseo suerte, puede ser un problema común y peludo que no le deseo a nadie.

Answer 2

Mi respuesta no es una buena idea también, pero:

que tienen varios servidores de suscriptor al sincronizar con nuestra base de datos principal, y en algunos de ellos tienen una colación que no es uno de la editorial. Al iniciar la replicación, seguimos obteniendo este "mensaje de bienvenida" que nos dice que, "como las intercalaciones no son idénticas, la sincronización podría no tener éxito".

Aunque este problema nunca ocurrió, creo que hay un riesgo en alguna parte, y creo que este riesgo podría estar relacionado con cosas como la integridad referencial y otras restricciones establecidas en los campos de caracteres.

Ah, y también existe este problema en minúsculas \ mayúsculas en las instrucciones T-SQL ... comprobar éste here

@ Michael y su DBA tienen razón .... limitar los riesgos, y el uso de un único colación.

Answer 3

El problema con las diferentes intercalaciones entre el servidor y la base de datos es como se menciona antes de que las tablas temporales se crearán por defecto con la intercalación del servidor. Eso hará que falle cualquier comparación en los campos de caracteres entre una tabla temporal y una tabla normal. Esto puede ser evitado por los desarrolladores de aplicaciones de terceros usando COLLATE database_default para campos de caracteres de tablas temporales.

create table #Tmp(Col1 nvarchar(50) COLLATE database_default) 

Vengo del "otro lado".No soy un DBA, sino un desarrollador de software de terceros y creo que es mi responsabilidad construir mi aplicación para trabajar en un entorno donde la intercalación es diferente entre la base de datos y el servidor. También es mi responsabilidad que mi aplicación funcione con intercalación sensible a mayúsculas y minúsculas.