# Descripción de la arquitectura y configuración de Babelfish
El clúster de base de datos de Aurora PostgreSQL-Compatible Edition que ejecuta Babelfish se administra de la misma manera que cualquier clúster de base de datos de Aurora. Es decir, se beneficia de la escalabilidad, la alta disponibilidad con compatibilidad con la conmutación por error y la replicación integrada que proporciona un clúster de base de datos de Aurora. Para obtener más información acerca de estas capacidades, consulte [Administración del rendimiento y el escalado para clústeres de base de datos Aurora](Aurora.Managing.Performance.md), [Alta disponibilidad para Amazon Aurora](Concepts.AuroraHighAvailability.md) y[Replicación con Amazon Aurora](Aurora.Replication.md). También tiene acceso a otras muchas herramientas y utilidades de AWS, como las siguientes:
+ Amazon CloudWatch es un servicio de supervisión y observabilidad que le proporciona datos e información procesable. Para obtener más información, consulte [Supervisión de métricas de Amazon Aurora con Amazon CloudWatch](monitoring-cloudwatch.md).
+ Información sobre rendimiento es una característica de ajuste y supervisión del rendimiento de la base de datos que ayuda a evaluar rápidamente la carga de la base de datos. Para obtener más información, consulte [Monitoreo de la carga de base de datos con Performance Insights en Amazon Aurora](USER_PerfInsights.md).
+ Las bases de datos globales de Aurora abarcan múltiples Regiones de AWS, lo que permite lecturas globales de baja latencia y proporcionan una recuperación rápida de cualquier interrupción que pueda afectar a toda una Región de AWS. Para obtener más información, consulte [Uso de una base de datos global de Amazon Aurora](aurora-global-database.md).
+ La aplicación automática de revisiones de software mantiene la base de datos actualizada con las revisiones de características y seguridad más recientes cuando estén disponibles.
+ Los eventos de Amazon RDS le notifican por correo electrónico o mensaje SMS los eventos importantes de la base de datos, como una conmutación por error automatizada. Para obtener más información, consulte [Supervisión de eventos de Amazon Aurora](working-with-events.md).
A continuación, podrá conocer la arquitectura de Babelfish y cómo las bases de datos de SQL Server que se migran las gestiona Babelfish. Cuando cree el clúster de base de datos de Babelfish, tendrá que tomar algunas decisiones por adelantado sobre si se trata de una o varias bases de datos, intercalaciones y otros detalles.
**Topics**
+ [Arquitectura de Babelfish](babelfish-architecture.md)
+ [Configuración del grupo de parámetros del clúster de base de datos para Babelfish](babelfish-configuration.md)
+ [Comprensión de las intercalaciones de Babelfish para Aurora PostgreSQL](babelfish-collations.md)
+ [Administración de la gestión de errores de Babelfish con escotillas de escape](babelfish-strict.md)
# Arquitectura de Babelfish
Al crear un clúster de Aurora PostgreSQL con Babelfish activado, Aurora aprovisiona el clúster con una base de datos PostgreSQL denominada `babelfish_db`. Esta base de datos es donde residen todos los objetos y estructuras de SQL Server migrados.
**nota**
En un clúster Aurora PostgreSQL, el nombre de la base de datos `babelfish_db` está reservado para Babelfish. La creación de su propia base de datos "babelfish\$1db" en un clúster de base de datos de Babelfish impide que Aurora aprovisione correctamente Babelfish.
Al conectarse al puerto TDS, la sesión se coloca en la base de datos `babelfish_db`. En T-SQL, la estructura tiene un aspecto similar a estar conectado a una instancia de SQL Server. Puede ver las bases de datos `master`, `msdb` y `tempdb`, y el catálogo `sys.databases`. Puede crear bases de datos de usuario adicionales y cambiar entre bases de datos con la instrucción USE. Cuando se crea una base de datos de usuario de SQL Server, se aplana en la base de datos `babelfish_db` de PostgreSQL. La base de datos retiene la sintaxis y la semántica entre bases de datos iguales o similares a las proporcionadas por SQL Server.
## Uso de Babelfish con una base de datos única o varias bases de datos
Al crear un clúster de Aurora PostgreSQL para usarlo con Babelfish, elija entre utilizar una sola base de datos de SQL Server por sí sola o varias bases de datos de SQL Server juntas. Su elección afecta a la manera en la que aparecen los nombres de los esquemas de SQL Server dentro de la base de datos `babelfish_db` en Aurora PostgreSQL. El modo de migración se almacena en el parámetro `migration_mode`. No debe cambiar este parámetro después de crear el clúster, ya que podría perder el acceso a todos los objetos SQL creados anteriormente.
En el modo de una sola base de datos, los nombres de los esquemas de la base de datos de SQL Server siguen siendo los mismos en la base de datos `babelfish_db` de PostgreSQL. Si decide migrar solo una base de datos, se puede hacer referencia a los nombres de esquema de la base de datos de usuario migrada en PostgreSQL con los mismos nombres que se utilizan en SQL Server. Por ejemplo, los esquemas `dbo` y `smith` residen dentro de la base de datos `dbA`*.*
![\[\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/babelfish_single_db_mode.png)
Al conectarse a través de TDS, puede ejecutar `USE dba` para ver los esquemas `dbo` y `dev` de T-SQL, como lo haría en SQL Server. Los nombres de esquema sin cambios también están visibles en PostgreSQL.
En el modo de varias bases de datos, los nombres de esquema de las bases de datos de usuario se convierten en `dbname_schemaname` cuando se accede a ellas desde PostgreSQL. Los nombres de esquema siguen siendo los mismos cuando se accede a ellos desde T-SQL.
![\[\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/babelfish_multi_db_mode.png)
Como se muestra en la imagen, el modo de base de datos múltiple y el modo de base de datos única son iguales a los de SQL Server cuando se conectan a través del puerto TDS y utilizan T-SQL. Por ejemplo, `USE dbA` enumera los esquemas `dbo` y `dev` tal como se hace en SQL Server. Los nombres de esquema asignados, tales como `dba_dbo` y `dba_dev`, están visibles en PostgreSQL.
Cada base de datos sigue conteniendo sus esquemas. El nombre de cada base de datos se antepone al nombre del esquema de SQL Server, y se utiliza un guion bajo como delimitador, por ejemplo:
+ `dba` contiene `dba_dbo` y `dba_dev`.
+ `dbb` contiene `dbb_dbo` y `dbb_test`.
+ `dbc` contiene `dbc_dbo` y `dbc_prod`.
Dentro de la base de datos `babelfish_db`, el usuario de T-SQL aún necesita ejecutar `USE dbname` para cambiar el contexto de la base de datos, de modo que la apariencia se mantenga similar a SQL Server.
## Elección de un modo de migración
Cada modo de migración tiene ventajas y desventajas. Elija el modo de migración en función del número de bases de datos de usuario que tenga y de sus planes de migración. Después de crear un clúster para usarlo con Babelfish, no se puede cambiar el modo de migración, ya que se puede perder el acceso a todos los objetos de SQL que se han creado anteriormente. Al elegir un modo de migración, tenga en cuenta los requisitos de las bases de datos de usuario y los clientes.
Al crear un clúster para usarlo con Babelfish, Aurora PostgreSQL crea las bases de datos del sistema, `master` y `tempdb`. Si ha creado o modificado objetos en las bases de datos del sistema (`master` o `tempdb`), asegúrese de volver a crear esos objetos en el nuevo clúster. A diferencia de SQL Server, Babelfish no reinicializa `tempdb` después de reiniciar el clúster.
Utilice el modo de migración de base de datos única en los siguientes casos:
+ Si va a migrar una sola base de datos de SQL Server. En el modo de base de datos única, los nombres de esquema migrados a los que se accede desde PostgreSQL son idénticos a los nombres de esquema de SQL Server originales. Esto reduce los cambios de código en las consultas SQL existentes si desea optimizarlas para que se ejecuten con una conexión de PostgreSQL.
+ Si su objetivo final es una migración completa de forma nativa a Aurora PostgreSQL. Antes de migrar, consolide los esquemas en un solo esquema (`dbo`) y, a continuación, migre a un solo clúster para reducir los cambios necesarios.
Utilice el modo de migración de varias bases de datos en los siguientes casos:
+ Si desea disfrutar de la experiencia predeterminada de SQL Server con varias bases de datos de usuarios en la misma instancia.
+ Si es necesario migrar varias bases de datos de usuarios juntas.
# Configuración del grupo de parámetros del clúster de base de datos para Babelfish
Cuando crea un clúster de base de datos Aurora PostgreSQL y elige **Turn on Babelfish** (Activar Babelfish), se crea automáticamente un grupo de parámetros de clúster de base de datos si elige **Create new** (Crear nuevo). Este grupo de parámetros del clúster de base de datos se basa en el grupo de parámetros del clúster de base de datos de Aurora PostgreSQL para la versión de Aurora PostgreSQL elegida para la instalación, por ejemplo, la versión 14 de Aurora PostgreSQL. Se le asigna un nombre mediante el siguiente patrón general:
```
custom-aurora-postgresql14-babelfish-compat-3
```
Puede cambiar la siguiente configuración durante el proceso de creación del clúster, pero algunas opciones no pueden cambiarse una vez que se han almacenado en el grupo de parámetros personalizados, así que elija con cuidado:
+ Base de datos única o bases de datos múltiples
+ Configuración regional de intercalación predeterminada
+ Nombre de intercalación
+ Grupo de parámetros de base de datos
Para utilizar un grupo de parámetros existente del clúster de base de datos de Aurora PostgreSQL versión 13 o superior, edite el grupo y establezca el parámetro `babelfish_status` como `on`. Especifique cualquier opción de Babelfish antes de crear el clúster de Aurora PostgreSQL. Para obtener más información, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md).
Los siguientes parámetros controlan las preferencias de Babelfish. A menos que se indique lo contrario en la descripción, los parámetros se pueden modificar. El valor predeterminado se incluye en la descripción. Para ver los valores permitidos de cualquier parámetro, haga lo siguiente:
**nota**
Al asociar un nuevo grupo de parámetros de base de datos con una instancia de base de datos, los parámetros estáticos y dinámicos modificados se aplican solo después de reiniciar la instancia de base de datos. Sin embargo, si modifica los parámetros dinámicos en el grupo de parámetros de base de datos después de asociarlos a la instancia de base de datos, dichos cambios se aplican inmediatamente sin reiniciar.
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Elija **Parameter groups** (Grupos de parámetros) en el panel de navegación.
1. Elija el grupo de parámetros del clúster de base de datos `default.aurora-postgresql14` en la lista.
1. Ingrese el nombre de un parámetro en el campo de búsqueda. Por ejemplo, escriba `babelfishpg_tsql.default_locale` en el campo de búsqueda para mostrar este parámetro, además de su valor predeterminado y su configuración permitida.
**nota**
Las bases de datos globales de Babelfish para Aurora PostgreSQL solo funcionan en regiones secundarias si los siguientes parámetros están activados en esas regiones.
| Parámetro | Descripción | Tipo de aplicación | Es modificable |
| --- | --- | --- | --- |
| babelfishpg\$1tsql.apg\$1enable\$1correlated\$1scalar\$1transform | Permite al planificador transformar una subconsulta escalar correlacionada en Babelfish. (Valor predeterminado: on) (Valor permitido: on, off) | dinámica | true |
| babelfishpg\$1tsql.apg\$1enable\$1subquery\$1cache | Permite el uso de la memoria caché para subconsultas escalares correlacionadas en Babelfish. (Valor predeterminado: on) (Valor permitido: on, off) | dinámica | true |
| babelfishpg\$1tds.tds\$1default\$1numeric\$1scale | Establece la escala predeterminada de tipo numérico que se va a enviar en los metadatos de la columna TDS si el motor no lo especifica. (Valor predeterminado: 8; permitido: 0 a 38). | dinámica | true |
| babelfishpg\$1tds.tds\$1default\$1numeric\$1precision | Un entero que establece la precisión predeterminada del tipo numérico que se va a enviar en los metadatos de la columna TDS si el motor no lo especifica. (Valor predeterminado: 38; permitido: 1 a 38). | dinámica | true |
| babelfishpg\$1tds.tds\$1default\$1packet\$1size | Un entero que establece el tamaño de paquete predeterminado para conectar clientes de SQL Server. (Valor predeterminado: 4096; permitido: 512 a 32767). | dinámica | true |
| babelfishpg\$1tds.tds\$1default\$1protocol\$1version | Un entero que establece una versión de protocolo de TDS predeterminada para conectar clientes. (Valor predeterminado: DEFAULT; permitido: TDSv7.0, TDSv7.1, TDSv7.1.1, TDSv7.2, TDSv7.3A, TDSv7.3B, TDSv7.4, DEFAULT). | dinámica | true |
| babelfishpg\$1tds.default\$1server\$1name | Una cadena que identifica el nombre predeterminado del servidor de Babelfish. (Valor predeterminado: Microsoft SQL Server; permitido: nulo). | dinámica | true |
| babelfishpg\$1tds.tds\$1debug\$1log\$1level | Un entero que establece el nivel de registro de TDS; 0 desactiva el registro. (Valor predeterminado: 1; permitido: 0, 1, 2, 3). | dinámica | true |
| babelfishpg\$1tds.listen\$1addresses | Una cadena que establece el nombre de host o las direcciones IP en las que se escuchará TDS. Este parámetro no se puede modificar una vez creado el clúster de base de datos de Babelfish. (Valor predeterminado: \$1; permitido: nulo). | – | false |
| babelfishpg\$1tds.port | Un entero que especifica el puerto TCP utilizado para las solicitudes en la sintaxis de SQL Server. (Valor predeterminado: 1433; permitido: 1 a 65535). | estática | true |
| babelfishpg\$1tds.tds\$1ssl\$1encrypt | Un booleano que activa el cifrado (0) o lo desactiva (1) para los datos que recorren el puerto del agente de escucha de TDS. Para obtener información detallada sobre el uso de SSL para las conexiones de clientes, consulte [Configuración SSL de Babelfish y conexiones de cliente](#babelfish-ssl). (Valor predeterminado: 0; permitido: 0, 1). | dinámica | true |
| babelfishpg\$1tds.tds\$1ssl\$1max\$1protocol\$1version | Una cadena que especifica la versión máxima del protocolo SSL/TLS que se utilizará para la sesión TDS. (Valor predeterminado: "TLSv1.2"; permitido: "TLSv1", "TLSv1.1", "TLSv1.2") | dinámica | true |
| babelfishpg\$1tds.tds\$1ssl\$1min\$1protocol\$1version | Una cadena que especifica la versión mínima del protocolo SSL/TLS que se utilizará para la sesión TDS. (Predeterminado: “TLSv1.2” de Aurora PostgreSQL versión 16, “TLSv1” para versiones anteriores a Aurora PostgreSQL versión 16) (Permisible: “TLSv1”, “TLSv1.1”, “TLSv1.2”) | dinámica | true |
| babelfishpg\$1tds.unix\$1socket\$1directories | Una cadena que identifica el directorio socket Unix del servidor TDS. Este parámetro no se puede modificar una vez creado el clúster de base de datos de Babelfish. (Valor predeterminado: /tmp; permitido: nulo). | – | false |
| babelfishpg\$1tds.unix\$1socket\$1group | Una cadena que identifica el grupo socket Unix del servidor TDS. Este parámetro no se puede modificar una vez creado el clúster de base de datos de Babelfish. (Valor predeterminado: rdsdb; permitido: nulo). | – | false |
| babelfishpg\$1tsql.default\$1locale | Una cadena que especifica la configuración regional predeterminada que se utiliza para las intercalaciones de Babelfish. La configuración regional predeterminada es solo la configuración regional y no incluye ningún calificador. Establezca este parámetro cuando aprovisione un clúster de bases de datos de Babelfish. Después de aprovisionar el clúster de base de datos, se ignoran los cambios de este parámetro. (Valor predeterminado: en\$1US; permitido: consulte las [tablas](babelfish-collations.md)). | estática | true |
| babelfishpg\$1tsql.migration\$1mode | Una lista no modificable que especifica la compatibilidad con bases de datos de uno o varios usuarios. Establezca este parámetro cuando aprovisione un clúster de bases de datos de Babelfish. Después de aprovisionar el clúster de base de datos, no puede modificar el valor de este parámetro. (Valor predeterminado: multi-db desde Aurora PostgreSQL versión 16, single-db para versiones anteriores a la versión 16 de Aurora PostgreSQL) (Permitido: single-db, multi-db, null). | estática | true |
| babelfishpg\$1tsql.server\$1collation\$1name | Una cadena que especifica el nombre de la intercalación utilizada para acciones de nivel de servidor. Establezca este parámetro cuando aprovisione un clúster de bases de datos de Babelfish. Después de aprovisionar el clúster de bases de datos, no modifique el valor de este parámetro. (Valor predeterminado: bbf\$1unicode\$1general\$1ci\$1as; permitido: consulte las [tablas](babelfish-collations.md)). | estática | true |
| babelfishpg\$1tsql.version | Una cadena que establece la salida de la variable @@VERSION. No modifique este valor para clústeres de base de datos de Aurora PostgreSQL. (Valor predeterminado: nulo; permitido: default). | dinámica | true |
| rds.babelfish\$1status | Una cadena que establece el estado de la funcionalidad de Babelfish. Cuando este parámetro se establece en `datatypesonly`, Babelfish se desactiva, pero los tipos de datos de SQL Server siguen disponibles. (Valor predeterminado: off; permitido: on, off, datatypesonly). | estática | true |
| unix\$1socket\$1permissions | Un entero que establece los permisos de socket Unix del servidor de TDS. Este parámetro no se puede modificar una vez creado el clúster de base de datos de Babelfish. (Valor predeterminado: 0700; permitido: 0 a 511). | – | false |
## Configuración SSL de Babelfish y conexiones de cliente
Para exigir conexiones SSL/TLS al clúster de base de datos de Babelfish para Aurora PostgreSQL, use el parámetro `rds.force_ssl`.
+ Para requerir conexiones SSL/TLS, establezca el valor del parámetro `rds.force_ssl` en 1 (activado).
+ Para desactivar las conexiones SSL/TLS requeridas, establezca el valor del parámetro `rds.force_ssl` en 0 (desactivado).
El valor predeterminado de este parámetro depende de la versión de Aurora PostgreSQL:
+ Para las versiones 17 y posteriores de Aurora PostgreSQL: el valor predeterminado es 1 (activado).
+ Para las versiones 16 y más antiguas de Aurora PostgreSQL: el valor predeterminado es 0 (desactivado).
**nota**
Cuando realiza una actualización de versión principal de Aurora PostgreSQL versión 16 o anterior a la versión 17 o posterior, el valor predeterminado del parámetro cambia de 0 (desactivado) a 1 (activado). Este cambio puede provocar errores de conectividad en las aplicaciones que no estén configuradas para SSL. Puede volver al comportamiento predeterminado anterior estableciendo este parámetro en 0 (desactivado).
Para obtener información específica sobre el controlador, consulte [Conexión a un clúster de base de datos de Babelfish](babelfish-connect.md).
Cuando un cliente se conecta al puerto TDS (predeterminado: `1433`), Babelfish compara la configuración de la capa de sockets seguros (SSL) enviada durante el protocolo de enlace del cliente con la configuración de los parámetros SSL de Babelfish (`tds_ssl_encrypt`). A continuación, Babelfish determina si se permite una conexión. Si se permite una conexión, el comportamiento de cifrado se aplica o no, según la configuración de los parámetros y la compatibilidad con el cifrado ofrecido por el cliente.
En la tabla siguiente se muestra cómo se comporta Babelfish para cada combinación.
| Configuración de SSL del cliente | Configuración de SSL de Babelfish | rds.force\$1ssl | ¿Se permite la conexión? | Valor devuelto al cliente |
| --- | --- | --- | --- | --- |
| ENCRYPT\$1ON | Cualquiera | Cualquiera | Permitido, toda la conexión está cifrada | ENCRYPT\$1ON |
| ENCRYPT\$1OFF | tds\$1ssl\$1encrypt=1 | Cualquiera | Permitido, toda la conexión está cifrada | ENCRYPT\$1REQ |
| ENCRYPT\$1OFF | tds\$1ssl\$1encrypt=0 | rds.force\$1ssl=0 | Permitido, el paquete de inicio de sesión está cifrado | ENCRYPT\$1OFF |
| ENCRYPT\$1OFF | tds\$1ssl\$1encrypt=0 | rds.force\$1ssl=1 | No, conexión cerrada | ENCRYPT\$1OFF |
| ENCRYPT\$1NOT\$1SUP | tds\$1ssl\$1encrypt=0 | rds.force\$1ssl=0 | Sí | ENCRYPT\$1NOT\$1SUP |
| ENCRYPT\$1NOT\$1SUP | tds\$1ssl\$1encrypt=1 | Cualquiera | No, conexión cerrada | ENCRYPT\$1REQ |
| ENCRYPT\$1NOT\$1SUP | tds\$1ssl\$1encrypt=0 | rds.force\$1ssl=1 | No, conexión cerrada | ENCRYPT\$1NOT\$1SUP |
| ENCRYPT\$1CLIENT\$1CERT | Cualquiera | Cualquiera | No, conexión cerrada | No se admite |
# Comprensión de las intercalaciones de Babelfish para Aurora PostgreSQL
Cuando crea un clúster de base de datos de Aurora PostgreSQL con Babelfish, elige una intercalación para sus datos. Una *intercalación* especifica el orden de clasificación y los patrones de bits que producen el texto o los caracteres en un determinado lenguaje humano escrito. Una intercalación incluye reglas que comparan los datos para un conjunto determinado de patrones de bits. La intercalación está relacionada con la localización. Las diferentes configuraciones regionales afectan a la asignación de caracteres, el orden de clasificación y otros aspectos similares. Los atributos de intercalación se reflejan en los nombres de varias intercalaciones. Para obtener información sobre los atributos, consulte la [Babelfish collation attributes table](#bfish-collation-attributes-table).
Babelfish asigna las intercalaciones de SQL Server a intercalaciones comparables proporcionadas por Babelfish. Babelfish predefine las intercalaciones Unicode con comparaciones de cadenas y órdenes de clasificación sensibles a la cultura. Babelfish también proporciona una manera de traduce las intercalaciones de la base de datos de SQL Server a la intercalación de Babelfish más cercana. Se proporcionan intercalaciones específicas para cada configuración regional en diferentes idiomas y regiones.
Algunas intercalaciones especifican una página de códigos que corresponde a una codificación del lado del cliente. Babelfish traduce automáticamente de la codificación del servidor a la codificación del cliente en función de la intercalación de cada columna de salida.
Babelfish admite las intercalaciones indicadas en la [Babelfish supported collations table](#bfish-collations-table). Babelfish asigna las intercalaciones de SQL Server a intercalaciones comparables proporcionadas por Babelfish.
Babelfish utiliza la versión 153.80 de la biblioteca de intercalación de Componentes internacionales para Unicode (ICU). Para obtener más información sobre las intercalaciones de ICU, consulte [Collation](https://unicode-org.github.io/icu/userguide/collation/) (Intercalación) en la documentación de ICU. Para obtener más información sobre PostgreSQL y la intercalación, consulte [Collation Support](https://www.postgresql.org/docs/current/collation.html) (Compatibilidad con intercalación) en la documentación de PostgreSQL.
**Topics**
+ [Parámetros de clúster de base de datos que controlan la intercalación y la configuración regional](#babelfish-collations.parameters)
+ [Intercalaciones deterministas y no deterministas en Babelfish](#babelfish-collations.deterministic-nondeterministic)
+ [Intercalaciones admitidas por Babelfish en el nivel de base de datos](#babelfish-collations.database-level)
+ [Intercalaciones de servidores y objetos en Babelfish](#babelfish-collations.reference-tables-supported-collations)
+ [Comportamiento predeterminado de las intercalaciones en Babelfish](#babelfish-collations-default)
+ [Administración de intercalaciones](collation.managing.md)
+ [Limitaciones de intercalación y diferencias de comportamiento](collation.limitations.md)
## Parámetros de clúster de base de datos que controlan la intercalación y la configuración regional
Los siguientes parámetros afectan al comportamiento de intercalación.
**babelfishpg\$1tsql.default\$1locale**
Este parámetro especifica la configuración regional predeterminada que usa la intercalación. Este parámetro se utiliza en combinación con los atributos enumerados en la [Babelfish collation attributes table](#bfish-collation-attributes-table) para personalizar las intercalaciones de un idioma y una región específicos. El valor predeterminado para este parámetro es `en-US`.
La configuración regional predeterminada se aplica a todos los nombres de intercalación de Babelfish que empiezan por "BBF" y a todas las intercalaciones de SQL Server asignadas a intercalaciones de Babelfish. El cambio de la configuración de este parámetro en un clúster de base de datos de Babelfish existente no afecta a la configuración regional de las intercalaciones existentes. Para ver la lista de intercalaciones, consulte la [Babelfish supported collations table](#bfish-collations-table).
**babelfishpg\$1tsql.server\$1collation\$1name**
Este parámetro especifica la intercalación predeterminada para el servidor (instancia de clúster de base de datos de Aurora PostgreSQL) y la base de datos. El valor predeterminado es `sql_latin1_general_cp1_ci_as`. `server_collation_name` tiene que ser una intercalación `CI_AS` porque en T-SQL, la intercalación del servidor determina cómo se comparan los identificadores.
Al crear su clúster de base de datos Babelfish, puede elegir el valor de **Collation name** (Nombre de la intercalación) en la lista seleccionable. Se incluyen las intercalaciones enumeradas en la [Babelfish supported collations table](#bfish-collations-table). No modifique `server_collation_name` después de crear la base de datos de Babelfish.
La configuración que elija al crear el clúster de la base de datos de Babelfish para Aurora PostgreSQL se almacena en el grupo de parámetros del clúster de base de datos asociado con el clúster para estos parámetros y establece su comportamiento de intercalación.
## Intercalaciones deterministas y no deterministas en Babelfish
Babelfish admite las combinaciones deterministas y no deterministas:
+ Una *intercalación determinista* evalúa como iguales los caracteres que tienen secuencias de bytes idénticas. Eso significa que `x` y `X` no son iguales en una intercalación determinista. Las intercalaciones deterministas pueden distinguir mayúsculas de minúsculas (CS) y acentos (AS).
+ Una *intercalación no determinista* no necesita una coincidencia idéntica. Una intercalación no determinista evalúa `x` y `X` como iguales. Las intercalaciones no deterministas no distinguen mayúsculas de minúsculas (IC) ni acentos (IA).
En la siguiente tabla puede encontrar algunas diferencias de comportamiento entre Babelfish y PostgreSQL cuando se utilizan intercalaciones no deterministas.
| Babelfish | PostgreSQL |
| --- | --- |
| Admite la cláusula LIKE para las intercalaciones CI\$1AS. | No admite la cláusula LIKE en las intercalaciones no deterministas. |
| Solo admite la cláusula LIKE en las siguientes intercalaciones de IA y a partir de la versión 4.2.0 de Babelfish: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/babelfish-collations.html) | No admite la cláusula LIKE en las intercalaciones no deterministas. |
Para obtener una lista de otras limitaciones y diferencias de comportamiento de Babelfish en comparación con SQL Server y PostgreSQL, consulte [Limitaciones de intercalación y diferencias de comportamiento](collation.limitations.md).
Babelfish y SQL Server siguen una convención de nomenclatura para las intercalaciones que describen los atributos de intercalación, como se muestra en la tabla siguiente.
| Atributo | Descripción |
| --- | --- |
| IA | No distingue acentos. |
| AS | Distingue acentos. |
| BIN2 | BIN2 solicita que los datos se clasifiquen en orden de puntos de código. El orden de puntos de código Unicode es el mismo orden de caracteres para las codificaciones UTF-8, UTF-16 y UCS-2. El orden de los puntos de código es una intercalación determinista rápida. |
| CI | No distingue mayúsculas de minúsculas. |
| CS | Distingue mayúsculas de minúsculas. |
| PREF | Para ordenar las letras mayúsculas antes que las minúsculas, utilice una intercalación de PREF. Si la comparación no distingue mayúsculas de minúsculas, la versión en mayúscula de una letra se ordena antes que la versión en minúscula, si no hay otra distinción. La biblioteca de ICU admite preferencias en mayúsculas con `colCaseFirst=upper`, pero no para las intercalaciones CI\$1AS. PREF solo se puede aplicar a las intercalaciones `CS_AS` deterministas. |
## Intercalaciones admitidas por Babelfish en el nivel de base de datos
Babelfish admite las siguientes intercalaciones en el nivel de base de datos:
+ bbf\$1unicode\$1bin2
+ bbf\$1unicode\$1cp1\$1ci\$1ai
+ bbf\$1unicode\$1cp1\$1ci\$1as
+ bbf\$1unicode\$1cp1250\$1ci\$1ai
+ bbf\$1unicode\$1cp1250\$1ci\$1as
+ bbf\$1unicode\$1cp1257\$1ci\$1ai
+ bbf\$1unicode\$1cp1257\$1ci\$1as
+ estonian\$1ci\$1ai
+ estonian\$1ci\$1as
+ finnish\$1swedish\$1ci\$1ai
+ finnish\$1swedish\$1ci\$1as
+ french\$1ci\$1ai
+ french\$1ci\$1as
+ latin1\$1general\$1bin2
+ latin1\$1general\$1ci\$1ai
+ latin1\$1general\$1ci\$1as
+ latin1\$1general\$190\$1bin2
+ latin1\$1general\$1100\$1bin2
+ latin1\$1general\$1140\$1bin2
+ modern\$1spanish\$1ci\$1ai
+ modern\$1spanish\$1ci\$1as
+ polish\$1ci\$1ai
+ polish\$1ci\$1as
+ sql\$1latin1\$1general\$1cp1\$1ci\$1ai
+ sql\$1latin1\$1general\$1cp1\$1ci\$1as
+ sql\$1latin1\$1general\$1cp1250\$1ci\$1as
+ sql\$1latin1\$1general\$1cp1251\$1ci\$1as
+ sql\$1latin1\$1general\$1cp1257\$1ci\$1as
+ traditional\$1spanish\$1ci\$1ai
+ traditional\$1spanish\$1ci\$1as
**nota**
Para usar una intercalación diferente en el nivel de base de datos, asegúrese de que coincida con la intercalación del nivel de servidor. Para obtener más información, consulte [Intercalaciones de servidores y objetos en Babelfish](#babelfish-collations.reference-tables-supported-collations)
## Intercalaciones de servidores y objetos en Babelfish
Utilice las siguientes intercalaciones como intercalación de servidores o intercalación de objetos.
| ID de intercalación | Notas |
| --- | --- |
| bbf\$1unicode\$1general\$1ci\$1as | Admite la comparación sin distinción de mayúsculas y minúsculas y el operador LIKE. |
| bbf\$1unicode\$1cp1\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt) también conocido como CP1252. |
| bbf\$1unicode\$1CP1250\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1250.txt) utilizada para representar textos en idiomas de Europa Central y Europa del Este que utilizan escritura latina. |
| bbf\$1unicode\$1CP1251\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1251.txt) para los idiomas que utilizan el alfabeto cirílico. |
| bbf\$1unicode\$1cp1253\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1253.txt) utilizada para representar el griego moderno. |
| bbf\$1unicode\$1cp1254\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1254.txt) que admite el turco. |
| bbf\$1unicode\$1cp1255\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1255.txt) que admite el hebreo. |
| bbf\$1unicode\$1cp1256\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1256.txt) utilizada para escribir idiomas que utilizan escritura árabe. |
| bbf\$1unicode\$1cp1257\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1257.txt) utilizada para admitir los idiomas estonio, letón y lituano. |
| bbf\$1unicode\$1cp1258\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1258.txt) utilizada para escribir caracteres vietnamitas. |
| bbf\$1unicode\$1cp874\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit874.txt) utilizada para escribir caracteres tailandeses. |
| sql\$1latin1\$1general\$1cp1250\$1ci\$1as | [Codificación de caracteres de un solo byte no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1250.txt) utilizada para representar caracteres latinos. |
| sql\$1latin1\$1general\$1cp1251\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1251.txt) que admite caracteres latinos. |
| sql\$1latin1\$1general\$1cp1\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt) que admite caracteres latinos. |
| sql\$1latin1\$1general\$1cp1253\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1253.txt) que admite caracteres latinos. |
| sql\$1latin1\$1general\$1cp1254\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1254.txt) que admite caracteres latinos. |
| sql\$1latin1\$1general\$1cp1255\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1255.txt) que admite caracteres latinos. |
| sql\$1latin1\$1general\$1cp1256\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1256.txt) que admite caracteres latinos. |
| sql\$1latin1\$1general\$1cp1257\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1257.txt) que admite caracteres latinos. |
| sql\$1latin1\$1general\$1cp1258\$1ci\$1as | [Intercalación no determinista](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1258.txt) que admite caracteres latinos. |
| chinese\$1prc\$1ci\$1as | Intercalación no determinista que admite chino (RPC). |
| cyrillic\$1general\$1ci\$1as | Intercalación no determinista que admite el cirílico. |
| finnish\$1swedish\$1ci\$1as | Intercalación no determinista que admite el finlandés. |
| french\$1ci\$1as | Intercalación no determinista que admite el francés. |
| Japanese\$1CI\$1AS | Intercalación no determinista que admite japonés. Se admite en Babelfish 2.1.0 y versiones posteriores. |
| korean\$1wansung\$1ci\$1as | Intercalación no determinista que admite el coreano (con clasificación de diccionario). |
| latin1\$1general\$1ci\$1as | Intercalación no determinista que admite caracteres latinos. |
| modern\$1spanish\$1ci\$1as | Intercalación no determinista que admite el español moderno. |
| polish\$1ci\$1as | Intercalación no determinista que admite el polaco. |
| thai\$1ci\$1as | Intercalación no determinista que admite el tailandés. |
| traditional\$1spanish\$1ci\$1as | Intercalación no determinista que admite el español (clasificación tradicional). |
| turkish\$1ci\$1as | Intercalación no determinista que admite el turco. |
| ukrainian\$1ci\$1as | Intercalación no determinista que admite el ucraniano. |
| vietnamese\$1ci\$1as | Intercalación no determinista que admite el vietnamita. |
Puede utilizar las siguientes intercalaciones como intercalaciones de objetos.
| Dialecto | Opciones deterministas | Opciones no deterministas |
| --- | --- | --- |
| Árabe | Arabic\$1CS\$1AS | Arabic\$1CI\$1AS Arabic\$1CI\$1AI |
| Alfabeto árabe | BBF\$1Unicode\$1CP1256\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1256\$1CS\$1AS | BBF\$1Unicode\$1CP1256\$1CI\$1AI BBF\$1Unicode\$1CP1256\$1CS\$1AI |
| Binario | latin1\$1general\$1bin2 BBF\$1Unicode\$1BIN2 | – |
| Idiomas de Europa Central y Europa del Este que utilizan escritura latina | BBF\$1Unicode\$1CP1250\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1250\$1CS\$1AS | BBF\$1Unicode\$1CP1250\$1CI\$1AI BBF\$1Unicode\$1CP1250\$1CS\$1AI |
| Chino | Chinese\$1PRC\$1CS\$1AS | Chinese\$1PRC\$1CI\$1AS Chinese\$1PRC\$1CI\$1AI |
| Cyrillic\$1General | Cyrillic\$1General\$1CS\$1AS | Cyrillic\$1General\$1CI\$1AS Cyrillic\$1General\$1CI\$1AI |
| Alfabeto cirílico | BBF\$1Unicode\$1CP1251\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1251\$1CS\$1AS | BBF\$1Unicode\$1CP1251\$1CI\$1AI BBF\$1Unicode\$1CP1251\$1CS\$1AI |
| Estonio | Estonian\$1CS\$1AS | Estonian\$1CI\$1AS Estonian\$1CI\$1AI |
| Estonio, letón y lituano | BBF\$1Unicode\$1CP1257\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1257\$1CS\$1AS | BBF\$1Unicode\$1CP1257\$1CI\$1AI BBF\$1Unicode\$1CP1257\$1CS\$1AI |
| Finnish\$1Swedish | Finnish\$1Swedish\$1CS\$1AS | Finnish\$1Swedish\$1CI\$1AS Finnish\$1Swedish\$1CI\$1AI |
| Francés | French\$1CS\$1AS | French\$1CI\$1AS French\$1CI\$1AI |
| Griego | Greek\$1CS\$1AS | Greek\$1CI\$1AS Greek\$1CI\$1AI |
| Hebreo | BBF\$1Unicode\$1CP1255\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1255\$1CS\$1AS Hebrew\$1CS\$1AS | BBF\$1Unicode\$1CP1255\$1CI\$1AI BBF\$1Unicode\$1CP1255\$1CS\$1AI Hebrew\$1CI\$1AS Hebrew\$1CI\$1AI |
| Japonés (Babelfish 2.1.0 y posterior) | Japanese\$1CS\$1AS | Japanese\$1CI\$1AI Japanese\$1CI\$1AS |
| Korean\$1Wamsung | Korean\$1Wamsung\$1CS\$1AS | Korean\$1Wamsung\$1CI\$1AS Korean\$1Wamsung\$1CI\$1AI |
| Caracteres latinos para la página de códigos CP1252 | latin1\$1general\$1cs\$1as BBF\$1Unicode\$1General\$1CS\$1AS BBF\$1Unicode\$1General\$1Pref\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1\$1CS\$1AS BBF\$1Unicode\$1CP1\$1CS\$1AS | latin1\$1general\$1ci\$1as latin1\$1general\$1ci\$1ai latin1\$1general\$1cs\$1ai BBF\$1Unicode\$1General\$1CI\$1AI BBF\$1Unicode\$1General\$1CS\$1AI BBF\$1Unicode\$1CP1\$1CI\$1AI BBF\$1Unicode\$1CP1\$1CS\$1AI |
| Griego moderno | BBF\$1Unicode\$1CP1253\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1253\$1CS\$1AS | BBF\$1Unicode\$1CP1253\$1CI\$1AI BBF\$1Unicode\$1CP1253\$1CS\$1AI |
| Modern\$1Spanish | Modern\$1Spanish\$1CS\$1AS | Modern\$1Spanish\$1CI\$1AS Modern\$1Spanish\$1CI\$1AI |
| Mongol | Mongolian\$1cs\$1as | Mongolian\$1CI\$1AS Mongolian\$1CI\$1AI |
| Polaco | Polish\$1CS\$1AS | Polish\$1CI\$1AS Polish\$1CI\$1AI |
| Tailandés | BBF\$1Unicode\$1CP874\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP874\$1CS\$1AS Thai\$1cs\$1as | BBF\$1Unicode\$1CP874\$1CI\$1AI BBF\$1Unicode\$1CP874\$1CS\$1AI Thai\$1ci\$1as, Thai\$1ci\$1ai |
| Traditional\$1Spanish | Traditional\$1Spanish\$1CS\$1AS | Traditional\$1Spanish\$1CI\$1AS Traditional\$1Spanish\$1CI\$1AI |
| Turco | BBF\$1Unicode\$1CP1254\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1254\$1CS\$1AS Turkish\$1CS\$1AS | BBF\$1Unicode\$1CP1254\$1CI\$1AI BBF\$1Unicode\$1CP1254\$1CS\$1AI Turkish\$1ci\$1as, turco\$1ci\$1ai |
| Ucraniano | Ukranian\$1CS\$1AS | Ukranian\$1CI\$1AS Ukranian\$1CI\$1AI |
| Vietnamita | BBF\$1Unicode\$1CP1258\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1258\$1CS\$1AS Vietnamese\$1CS\$1AS | BBF\$1Unicode\$1CP1258\$1CI\$1AI BBF\$1Unicode\$1CP1258\$1CS\$1AI Vietnamese\$1CI\$1AS Vietnamese\$1CI\$1AI |
## Comportamiento predeterminado de las intercalaciones en Babelfish
Anteriormente, la intercalación predeterminada de los tipos de datos recopilables era `pg_catalog.default`. Los tipos de datos y los objetos que dependen de estos tipos de datos siguen una intercalación que distingue entre mayúsculas y minúsculas. Esta condición puede afectar a los objetos T-SQL del conjunto de datos, ya que la intercalación no distingue entre mayúsculas y minúsculas. A partir de Babelfish 2.3.0, la intercalación predeterminada para los tipos de datos recopilables (excepto TEXT y NTEXT) es la misma que la intercalación en el parámetro `babelfishpg_tsql.server_collation_name`. Al actualizar a Babelfish 2.3.0, la intercalación predeterminada se selecciona automáticamente en el momento de la creación del clúster de base de datos, lo que no tiene ningún impacto visible.
# Administración de intercalaciones
La biblioteca de ICU proporciona seguimiento de versiones de intercalación para garantizar que los índices que dependen de las intercalaciones se puedan volver a indexar cuando esté disponible una nueva versión de ICU. Para comprobar si su base de datos actual tiene intercalaciones que se deban actualizar, puede utilizar la siguiente consulta después de conectarse mediante `psql` o `pgAdmin`:
```
SELECT pg_describe_object(refclassid, refobjid,
refobjsubid) AS "Collation",
pg_describe_object(classid, objid, objsubid) AS "Object"
FROM pg_depend d JOIN pg_collation c ON refclassid = 'pg_collation'::regclass
AND refobjid = c.oid WHERE c.collversion <> pg_collation_actual_version(c.oid)
ORDER BY 1, 2;
```
Esta consulta devuelve resultados como los siguientes:
```
Collation | Object
-----------+--------
(0 rows)
```
En este ejemplo, no es necesario actualizar ninguna intercalación.
Para obtener un listado de las intercalaciones predefinidas en su base de datos Babelfish, puede utilizar `psql` o `pgAdmin` con la siguiente consulta:
```
SELECT * FROM pg_collation;
```
Las intercalaciones predefinidas se almacenan en la tabla `sys.fn_helpcollations`. Puede utilizar el siguiente comando para mostrar información sobre una intercalación (como sus indicadores lcid, estilo y marcas de collate). Para obtener un listado de todas las intercalaciones mediante `sqlcmd`, conéctese al puerto T-SQL (1433, de forma predeterminada) y ejecute la siguiente consulta:
```
1> :setvar SQLCMDMAXVARTYPEWIDTH 40
2> :setvar SQLCMDMAXFIXEDTYPEWIDTH 40
3> SELECT * FROM fn_helpcollations()
4> GO
name description
---------------------------------------- ----------------------------------------
arabic_cs_as Arabic, case-sensitive, accent-sensitive
arabic_ci_ai Arabic, case-insensitive, accent-insensi
arabic_ci_as Arabic, case-insensitive, accent-sensiti
bbf_unicode_bin2 Unicode-General, case-sensitive, accent-
bbf_unicode_cp1250_ci_ai Default locale, code page 1250, case-ins
bbf_unicode_cp1250_ci_as Default locale, code page 1250, case-ins
bbf_unicode_cp1250_cs_ai Default locale, code page 1250, case-sen
bbf_unicode_cp1250_cs_as Default locale, code page 1250, case-sen
bbf_unicode_pref_cp1250_cs_as Default locale, code page 1250, case-sen
bbf_unicode_cp1251_ci_ai Default locale, code page 1251, case-ins
bbf_unicode_cp1251_ci_as Default locale, code page 1251, case-ins
bbf_unicode_cp1254_ci_ai Default locale, code page 1254, case-ins
...
(124 rows affected)
```
Las líneas 1 y 2 que aparecen en el ejemplo reducen la salida solo a efectos de legibilidad de la documentación.
```
1> SELECT SERVERPROPERTY('COLLATION')
2> GO
serverproperty
---------------------------------------------------------------------------
sql_latin1_general_cp1_ci_as
(1 rows affected)
1>
```
# Limitaciones de intercalación y diferencias de comportamiento
Babelfish utiliza la biblioteca de ICU para admitir la intercalación. PostgreSQL se creó con una versión específica de ICU y puede coincidir como máximo con una versión de una intercalación. Las variaciones entre versiones son inevitables, al igual que las variaciones menores en el tiempo a medida que evolucionan los lenguajes. En la siguiente lista puede encontrar las limitaciones conocidas y las variaciones de comportamiento de las intercalaciones de Babelfish:
+ **Índices y dependencia del tipo de intercalación**: un índice de un tipo definido por el usuario que depende de la biblioteca de intercalación de Componentes internacionales para Unicode (ICU), la biblioteca utilizada por Babelfish, no se invalida cuando se cambia la versión de la biblioteca.
+ **Función COLLATIONPROPERTY**: las propiedades de intercalación solo se implementan para las intercalaciones de BBF admitidas de Babelfish. Para obtener más información, consulte [Babelfish supported collations table](babelfish-collations.md#bfish-collations-table).
+ **Diferencias de las reglas de orden de Unicode**: las intercalaciones de SQL Server ordenan los datos codificados en Unicode (`nchar` y `nvarchar`) de una manera distinta a los datos que no están codificados en Unicode (`char` y `varchar`). Las bases de datos de Babelfish siempre están codificadas en UTF-8 y siempre aplican reglas de orden Unicode de manera coherente, independientemente del tipo de datos, por lo que el orden de clasificación para `char` o `varchar` es el mismo que para `nchar` o `nvarchar`.
+ **Intercalaciones secundarias iguales y comportamiento de orden**: la intercalación secundaria de igualdad Unicode de ICU predeterminada (`CI_AS`) ordena los signos de puntuación y otros caracteres no alfanuméricos antes que los caracteres numéricos y los caracteres numéricos antes que los caracteres alfabéticos. Sin embargo, el orden de puntuación y otros caracteres especiales son diferentes.
+ **Intercalaciones terciarias, solución para ORDER BY**: las intercalaciones de SQL, tales como `SQL_Latin1_General_Pref_CP1_CI_AS`, admiten la función `TERTIARY_WEIGHTS` y la capacidad de ordenar cadenas que se comparan por igual en una intercalación `CI_AS` que debe ordenarse en mayúsculas primero: `ABC`, `ABc`, `AbC`, `Abc`, `aBC`, `aBc`, `abC` y, por último, `abc`. Por lo tanto, la función de análisis `DENSE_RANK OVER (ORDER BY column)` evalúa estas cadenas como del mismo rango, pero las ordena en mayúscula primero en una partición.
Puede obtener un resultado similar con Babelfish mediante la adición de una cláusula `COLLATE` a la cláusula `ORDER BY` que especifica una intercalación terciaria `CS_AS` que especifica `@colCaseFirst=upper`. Sin embargo, el modificador `colCaseFirst` se aplica solo a cadenas terciarias iguales (en lugar de secundarias iguales, como sucede con una intercalación `CI_AS`). Por lo tanto, no se pueden emular las intercalaciones de SQL terciarias mediante una única intercalación de ICU.
Como solución alternativa, le recomendamos que modifique las aplicaciones que utilizan la intercalación `SQL_Latin1_General_Pref_CP1_CI_AS` para utilizar la intercalación `BBF_SQL_Latin1_General_CP1_CI_AS` en primer lugar. A continuación, agregue `COLLATE BBF_SQL_Latin1_General_Pref_CP1_CS_AS` a cualquier cláusula `ORDER BY` de esta columna.
+ **Expansión de caracteres**: una expansión de caracteres trata a un solo carácter igual que a una secuencia de caracteres del nivel principal. La intercalación `CI_AS` predeterminada de SQL Server admite la expansión de caracteres. Las intercalaciones de UCI admiten la expansión de caracteres solo en las intercalaciones que no distinguen los acentos.
Cuando sea necesaria la expansión de caracteres, utilice una intercalación `AI` para obtener comparaciones. Sin embargo, el operador LIKE no admite actualmente estas intercalaciones.
+ **Codificación char y varchar**: cuando se utilizan intercalaciones SQL para los tipos de datos `char` o `varchar`, el orden de clasificación de los caracteres anteriores a ASCII 127 viene determinado por la página de códigos específica para esa intercalación de SQL. Para las intercalaciones SQL, las cadenas declaradas como `char` o `varchar` pueden ordenarse de forma diferente a las cadenas declaradas como `nchar` o `nvarchar`.
PostgreSQL codifica todas las cadenas con la codificación de la base de datos, de modo que se convierten todos los caracteres a UTF-8 y se ordenan mediante reglas Unicode.
Dado que las intercalaciones de SQL ordenan los tipos de datos nchar y nvarchar mediante reglas Unicode, Babelfish codifica todas las cadenas del servidor mediante UTF-8. Babelfish ordena las cadenas nchar y nvarchar de la misma manera que ordena las cadenas char y varchar mediante las reglas Unicode.
+ **Carácter suplementario**: las funciones `NCHAR`, `UNICODE` y `LEN` de SQL Server admiten caracteres para puntos de código fuera del Plano Básico Multilingüe (BMP) de Unicode. Por el contrario, las intercalaciones que no son SC utilizan caracteres pares sustitutos para gestionar caracteres complementarios. Para los tipos de datos Unicode, SQL Server puede representar hasta 65 535 caracteres mediante UCS-2 o el rango Unicode completo (1,114,114 caracteres) si se utilizan caracteres complementarios.
+ **Intercalaciones con distinción de los tipos de kana (KS)**: una intercalación con distinción de los tipos de kana (KS) trata los caracteres kana japoneses `Hiragana` y `Katakana` de forma diferente. ICU admite el estándar de intercalación japonés `JIS X 4061`. El ahora obsoleto modificador `colhiraganaQ [on | off]` de configuración regional podría proporcionar la misma funcionalidad que las intercalaciones de KS. Sin embargo, Babelfish no admite actualmente las intercalaciones de KS del mismo nombre que SQL Server.
+ **Intercalaciones de distinción de ancho (WS)**: cuando un carácter de un byte (ancho medio) y el mismo carácter representado como un carácter de doble byte (ancho completo) se tratan de forma diferente, la intercalación se denomina de *distinción de ancho (WS)*. Sin embargo, Babelfish no admite actualmente las intercalaciones de WS del mismo nombre que SQL Server.
+ **Intercalaciones de distinción de selector de variaciones (VSS)**: las intercalaciones de distinción de selector de variaciones (VSS) distinguen entre los selectores de variaciones ideográficas en las intercalaciones en japonés `Japanese_Bushu_Kakusu_140` y `Japanese_XJIS_140`. Una secuencia de variaciones se compone de un carácter base más un selector de variaciones adicional. Si no selecciona la opción `_VSS`, el selector de variaciones no se tiene en cuenta en la comparación.
Babelfish no admite las intercalaciones de VSS.
+ **Intercalaciones BIN y BIN2**: una intercalación BIN2 ordena los caracteres según el orden de los puntos de código. El orden binario byte a byte de UTF-8 conserva el orden de puntos de código Unicode, por lo que también es probable que esta sea la intercalación de mejor rendimiento. Si el orden de puntos de código Unicode funciona para una aplicación, considere utilizar una intercalación BIN2. Sin embargo, el uso de una intercalación BIN2 puede provocar que los datos se muestren en el cliente en un orden inesperado culturalmente. Las nuevas asignaciones a caracteres en minúscula se agregan a Unicode a medida que avanza el tiempo, por lo que la función `LOWER` puede funcionar de manera diferente en distintas versiones de ICU. Este es un caso especial del problema de control de versiones de intercalación más general, en lugar de como algo específico de la intercalación BIN2.
Babelfish proporciona la intercalación de `BBF_Latin1_General_BIN2` con la distribución de Babelfish para intercalar en el orden de puntos de código Unicode. En una intercalación BIN, solo el primer carácter se ordena como wchar. Los caracteres restantes se ordenan byte a byte, efectivamente en orden de puntos de código según su codificación. Este enfoque no sigue las reglas de intercalación Unicode y Babelfish no lo admite.
+ **Intercalaciones no deterministas y limitación de CHARINDEX**: en las versiones de Babelfish anteriores a la 2.1.0, no puede utilizar CHARINDEX con intercalaciones no deterministas. De forma predeterminada, Babelfish utiliza una intercalación sin distinción de mayúsculas y minúsculas (no determinista). El uso de CHARINDEX para las versiones más antiguas de Babelfish genera el siguiente error de ejecución:
```
nondeterministic collations are not supported for substring searches
```
**nota**
Esta limitación y esta solución alternativa se aplican solo a la versión 1.x de Babelfish (versiones Aurora PostgreSQL 13.x). Las versiones 2.1.0 y posteriores de Babelfish no tienen este problema.
Puede solucionar este problema de una de las siguientes maneras:
+ Convierta explícitamente la expresión en una intercalación distinta entre mayúsculas y minúsculas y doble ambos argumentos aplicando LOWER o UPPER. Por ejemplo, `SELECT charindex('x', a) FROM t1` se convertiría en lo siguiente:
```
SELECT charindex(LOWER('x'), LOWER(a COLLATE sql_latin1_general_cp1_cs_as)) FROM t1
```
+ Cree una función SQL f\$1charindex y reemplace las llamadas de CHARINDEX por llamadas a la siguiente función:
```
CREATE function f_charindex(@s1 varchar(max), @s2 varchar(max)) RETURNS int
AS
BEGIN
declare @i int = 1
WHILE len(@s2) >= len(@s1)
BEGIN
if LOWER(@s1) = LOWER(substring(@s2,1,len(@s1))) return @i
set @i += 1
set @s2 = substring(@s2,2,999999999)
END
return 0
END
go
```
# Administración de la gestión de errores de Babelfish con escotillas de escape
Babelfish imita el comportamiento de SQL en el flujo de control y el estado de transacción siempre que sea posible. Cuando Babelfish encuentra un error, devuelve un código de error similar al código de error de SQL Server. Si Babelfish no puede asignar el error a un código de SQL Server, devuelve un código de error fijo (`33557097`) y realiza acciones específicas en función del tipo de error, como se indica a continuación:
+ En el caso de los errores de tiempo de compilación, Babelfish revierte la transacción.
+ En el caso de los errores de tiempo de ejecución, Babelfish finaliza el lote y revierte la transacción.
+ En el caso de los errores de protocolo entre el cliente y el servidor, la transacción no se revierte.
Si un código de error no se puede asignar a un código equivalente y el código de un error similar está disponible, el código de error se asigna al código alternativo. Por ejemplo, los comportamientos que provocan los códigos `8143` y `8144` de SQL Server se asignan a `8143`.
Los errores que no se pueden asignar no respetan una construcción de `TRY... CATCH`.
Puede usar `@@ERROR` para devolver un código de error de SQL Server o la función `@@PGERROR` para devolver un código de error de PostgreSQL. También puede utilizar la función `fn_mapped_system_error_list` para devolver una lista de códigos de error asignados. Para obtener información sobre los códigos de error de PostgreSQL, consulte [el sitio web de PostgreSQL](https://www.postgresql.org/docs/current/errcodes-appendix.html).
## Modificación de la configuración de escotilla de escape Babelfish
Para gestionar mejor las instrucciones que podrían producir errores, Babelfish define ciertas opciones llamadas “escotillas de escape”. Una *escotilla de escape* es una opción que especifica el comportamiento de Babelfish cuando encuentra una característica o sintaxis no admitidas.
Puede utilizar el procedimiento almacenado `sp_babelfish_configure` para controlar la configuración de una escotilla de escape. Utilice el script para establecer la escotilla de escape en `ignore` o `strict`. Si está configurado en `strict`, Babelfish devuelve un error que debe corregir antes de continuar.
Incluya la palabra clave `server` para aplicar los cambios a la sesión actual y a nivel de clúster.
El uso es como se indica a continuación:
+ Para enumerar todas las escotillas de escape y su estado, además de la información de uso, ejecute `sp_babelfish_configure`.
+ Para enumerar las escotillas de escape con nombre y sus valores, en la sesión actual o en todo el clúster, ejecute el comando `sp_babelfish_configure 'hatch_name'` en el que `hatch_name` es el identificador de una o más escotillas de escape. *hatch\$1name*puede utilizar comodines de SQL, como '%'.
+ Para establecer uno o más escotillas de escape en el valor especificado, ejecute `sp_babelfish_configure ['hatch_name' [, 'strict'|'ignore' [, 'server']]`. Para que la configuración sea permanente a nivel de todo el clúster, incluya la palabra clave `server`, como se muestra a continuación:
```
EXECUTE sp_babelfish_configure 'escape_hatch_unique_constraint', 'ignore', 'server'
```
Para configurarlos solo para la sesión actual, no utilice `server`.
+ Para restablecer todas las escotillas de escape a sus valores predeterminados, ejecute`sp_babelfish_configure 'default'` (Babelfish 1.2.0 y posteriores).
La cadena que identifica la escotilla (o escotillas) podría contener comodines de SQL. Por ejemplo, a continuación, se establecen todas las escotillas de escape de sintaxis en `ignore` para el clúster de Aurora PostgreSQL.
```
EXECUTE sp_babelfish_configure '%', 'ignore', 'server'
```
En la tabla siguiente encontrará descripciones y valores predeterminados para las escotillas de escape predefinidas Babelfish.
| Escotilla de escape | Descripción | Predeterminado |
| --- | --- | --- |
| escape\$1hatch\$1checkpoint | Permite el uso de la instrucción CHECKPOINT en el código de procedimiento, pero la instrucción CHECKPOINT no está implementada actualmente. | ignore |
| escape\$1hatch\$1constraint\$1name\$1for\$1default | Controla el comportamiento de Babelfish relacionado con los nombres de restricciones predeterminados. | ignore |
| escape\$1hatch\$1database\$1misc\$1options | Controla el comportamiento de Babelfish relacionado con las siguientes opciones de CREATE DATABASE: CONTAINMENT, DB\$1CHAINING, TRUSTWORTHY, PERSISTENT\$1LOG\$1BUFFER. | ignore |
| escape\$1hatch\$1for\$1replication | Controla el comportamiento de Babelfish relacionado con la cláusula [NOT] FOR REPLICATION cuando se crea o modifica una tabla. | strict |
| escape\$1hatch\$1fulltext | Controla el comportamiento de Babelfish relacionado con las características de FULLTEXT, como DEFAULT\$1FULLTEXT\$1LANGUAGE en CREATE/ALTER DATABASE, CREATE FULLTEXT INDEX o sp\$1fulltext\$1database. | ignore |
| escape\$1hatch\$1ignore\$1dup\$1key | Controla el comportamiento de Babelfish relacionado con CREATE/ALTER TABLE y CREATE INDEX. Cuando IGNORE\$1DUP\$1KEY=ON genera un error cuando se establece en`strict` (el valor predeterminado) o ignora el error cuando se establece en`ignore` (versión de Babelfish 1.2.0 y posteriores). | strict |
| escape\$1hatch\$1index\$1clustering | Controla el comportamiento de Babelfish relacionado con las palabras clave clústerED o NONclústerED para índices y restricciones PRIMARY KEY o UNIQUE. Cuando se ignora clústerED, el índice o la restricción se siguen creando como si se hubiera especificado NONclústerED. | ignore |
| escape\$1hatch\$1index\$1columnstore | Controla el comportamiento de Babelfish relacionado con la cláusula COLUMNSTORE. Si se especifica `ignore`, Babelfish crea un índice de árbol B. regular. | strict |
| escape\$1hatch\$1join\$1hints | Controla el comportamiento de las palabras clave en un operador JOIN: LOOP, HASH, MERGE, REMOTE, REDUCE, REDISTRIBUTE, REPLICATE. | ignore |
| escape\$1hatch\$1language\$1non\$1english | Controla el comportamiento de Babelfish relacionado con idiomas distintos del inglés para los mensajes en pantalla. Babelfish actualmente solo admite `us_english` para mensajes en pantalla. SET LANGUAGE puede utilizar una variable que contiene el nombre del idioma, por lo que el idioma que se esté configurando solo se puede detectar en tiempo de ejecución. | strict |
| escape\$1hatch\$1login\$1hashed\$1password | Cuando se ignora, suprime el error de la palabra clave `HASHED` para `CREATE LOGIN` y `ALTER LOGIN`. | strict |
| escape\$1hatch\$1login\$1misc\$1options | Cuando se ignora, suprime el error de otras palabras clave además de `HASHED`, `MUST_CHANGE`, `OLD_PASSWORD` y `UNLOCK` para `CREATE LOGIN` y `ALTER LOGIN`. | strict |
| escape\$1hatch\$1login\$1old\$1password | Cuando se ignora, suprime el error de la palabra clave `OLD_PASSWORD` para `CREATE LOGIN` y `ALTER LOGIN`. | strict |
| escape\$1hatch\$1login\$1password\$1must\$1change | Cuando se ignora, suprime el error de la palabra clave `MUST_CHANGE` para `CREATE LOGIN` y `ALTER LOGIN`. | strict |
| escape\$1hatch\$1login\$1password\$1unlock | Cuando se ignora, suprime el error de la palabra clave `UNLOCK` para `CREATE LOGIN` y `ALTER LOGIN`. | strict |
| escape\$1hatch\$1nocheck\$1add\$1constraint | Controla el comportamiento de Babelfish relacionado con la cláusula WITH CHECK o NOCHECK para las restricciones. | strict |
| escape\$1hatch\$1nocheck\$1existing\$1constraint | Controla el comportamiento de Babelfish relacionado con las restricciones FOREIGN KEY o CHECK. | strict |
| escape\$1hatch\$1query\$1hints | Controla el comportamiento de Babelfish relacionado con sugerencias de consulta. Cuando esta opción está configurada para ignorar, el servidor ignora las sugerencias que utilizan la cláusula OPTION (...) para especificar los aspectos del procesamiento de consultas. Algunos ejemplos incluyen SELECT FROM ... OPTION(MERGE JOIN HASH, MAXRECURSION 10)). | ignore |
| escape\$1hatch\$1rowversion | Controla el comportamiento de los tipos de datos ROWVERSION y TIMESTAMP. Para obtener más información, consulte [Uso de las características de Babelfish con implementación limitada](babelfish-compatibility.tsql.limited-implementation.md). | strict |
| escape\$1hatch\$1schemabinding\$1function | Controla el comportamiento de Babelfish relacionado con la cláusula WITH SCHEMABINDING. De forma predeterminada, la cláusula WITH SCHEMABINDING se ignora cuando se especifica con los comandos CREATE o ALTER FUNCTION. | ignore |
| escape\$1hatch\$1schemabinding\$1procedure | Controla el comportamiento de Babelfish relacionado con la cláusula WITH SCHEMABINDING. De forma predeterminada, la cláusula WITH SCHEMABINDING se ignora cuando se especifica con los comandos CREATE o ALTER PROCEDURE. | ignore |
| escape\$1hatch\$1rowguidcol\$1column | Controla el comportamiento de Babelfish relacionado con la cláusula ROWGUIDCOL cuando se crea o modifica una tabla. | strict |
| escape\$1hatch\$1schemabinding\$1trigger | Controla el comportamiento de Babelfish relacionado con la cláusula WITH SCHEMABINDING. De forma predeterminada, la cláusula WITH SCHEMABINDING se ignora cuando se especifica con los comandos CREATE o ALTER TRIGGER. | ignore |
| escape\$1hatch\$1schemabinding\$1view | Controla el comportamiento de Babelfish relacionado con la cláusula WITH SCHEMABINDING. De forma predeterminada, la cláusula WITH SCHEMABINDING se ignora cuando se especifica con los comandos CREATE o ALTER VIEW. | ignore |
| escape\$1hatch\$1session\$1settings | Controla el comportamiento de Babelfish en relación con las instrucciones SET de nivel de sesión no admitidas. | ignore |
| escape\$1hatch\$1showplan\$1all | Controla el comportamiento de Babelfish relacionado con SET SHOWPLAN\$1ALL y SET STATISTICS PROFILE. Cuando se configuran en ignore, se comportan como SET BABELFISH\$1SHOWPLAN\$1ALL y SET BABELFISH\$1STATISTICS PROFILE; cuando se configuran en strict, se ignoran silenciosamente. | strict |
| escape\$1hatch\$1storage\$1on\$1partition | Controla el comportamiento de Babelfish relacionado con la cláusula `ON partition_scheme column ` cuando se define la partición. Babelfish actualmente no implementa particiones. | strict |
| escape\$1hatch\$1storage\$1options | Escotilla de escape en cualquier opción de almacenamiento utilizada en CREATE, ALTER DATABASE, TABLE, INDEX. Esto incluye las cláusulas (LOG) ON, TEXTIMAGE\$1ON, FILESTREAM\$1ON que definen las ubicaciones de almacenamiento (particiones, grupos de archivos) para tablas, índices y restricciones, así como para una base de datos. Esta configuración de escotilla de escape se aplica a todas estas cláusulas (incluidas ON [PRIMARY] y ON "DEFAULT"). La excepción se produce cuando se especifica una partición para una tabla o índice con ON partition\$1scheme (columna). | ignore |
| escape\$1hatch\$1table\$1hints | Controla el comportamiento de las sugerencias de tabla especificadas mediante la cláusula WITH (...). | ignore |
| escape\$1hatch\$1unique\$1constraint | Cuando se establece en un nivel estricto, una diferencia semántica desconocida entre SQL Server y PostgreSQL en el manejo de valores NULL en columnas indexadas puede generar errores. La diferencia semántica solo surge en casos de uso poco realistas, por lo que puede configurar esta escotilla de escape para que se «ignore» y evitar ver el error. Obsoleto a partir de las siguientes versiones: 3.6.0 y versiones superiores, 4.2.0 y versiones superiores | strict |