Параметры сортировки автономной базы данных
Область применения:
SQL Server Управляемый экземпляр SQL Azure
На порядок сортировки и семантику сравнения текстовых данных влияют различные свойства, в том числе учет регистра, учет диакритических знаков и используемый базовый язык. Эти качества выражаются в SQL Server с помощью выбора сортировки данных. Подробное обсуждение параметров сортировки см. в разделе Поддержка параметров сортировки и Юникода.
Параметры сортировки применяются не только к данным, хранящимся в пользовательских таблицах, но и ко всем текстам, обрабатываемым SQL Server, включая метаданные, временные объекты, имена переменных и т. д. Обработка этих баз данных отличается от содержащихся и не содержащихся баз данных. Это изменение коснется небольшого числа пользователей и обеспечит независимость и единообразие экземпляров. При этом возможны некоторые затруднения, а также проблемы в сеансах, которые обращаются и к автономным и к неавтономным базам данных.
Работа параметров сортировки в автономных базах данных несколько отличается от неавтономных баз данных. В целом эти изменения упрощают работу и обеспечивают независимость от экземпляра. У некоторых пользователей могут возникать проблемы, особенно если сеанс обращается и к автономным и к неавтономным базам данных.
В этой статье объясняется содержимое изменения и рассматриваются области, в которых изменение может вызвать проблемы.
Примечание.
Для База данных SQL Azure параметры сортировки для содержащихся баз данных отличаются. Параметры сортировки базы данных и параметры сортировки каталога могут быть установлены при создании базы данных и не могут быть обновлены. Укажите параметры сортировки для данных (COLLATE) и параметры сортировки каталога для системных метаданных и идентификаторов объектов (CATALOG_COLLATION). Дополнительные сведения см. в статье CREATE DATABASE (SQL Server Transact-SQL).
Не содержащиеся базы данных
Все базы данных имеют параметры сортировки по умолчанию (их можно задать во время создания или изменения базы данных). Эти параметры сортировки используются для всех метаданных в базе данных, а также по умолчанию для всех строковых столбцов в базе данных. Пользователи могут выбрать другие параметры сортировки для любого столбца с помощью предложения COLLATE.
Пример 1
Например, для работы в Пекине можно использовать параметры сортировки китайского языка:
ALTER DATABASE MyDB COLLATE Chinese_Simplified_Pinyin_100_CI_AS;
Теперь для создаваемого столбца по умолчанию будут применяться параметры сортировки китайского языка, но в случае необходимости можно выбрать другие параметры.
CREATE TABLE MyTable
(mycolumn1 nvarchar,
mycolumn2 nvarchar COLLATE Frisian_100_CS_AS);
GO
SELECT name, collation_name
FROM sys.columns
WHERE name LIKE 'mycolumn%' ;
GO
Вот результирующий набор.
name collation_name
--------------- ----------------------------------
mycolumn1 Chinese_Simplified_Pinyin_100_CI_AS
mycolumn2 Frisian_100_CS_AS
Это выглядит довольно простым, однако возникают некоторые проблемы. Так как параметры сортировки для столбца зависят от базы данных, в которой создается таблица, возникают проблемы с использованием временных таблиц, в которых хранятся tempdb. Параметры сортировки tempdb обычно соответствуют параметрам сортировки для экземпляра, который не должен соответствовать параметрам сортировки базы данных.
Пример 2
Например, пусть база данных с китайскими параметрами сортировки (упомянутая выше) используется в экземпляре с параметрами сортировки Latin1_General :
CREATE TABLE T1 (T1_txt nvarchar(max)) ;
GO
CREATE TABLE #T2 (T2_txt nvarchar(max)) ;
GO
На первый взгляд кажется, что две таблицы имеют одинаковую схему, однако из-за различия в параметрах сортировки баз данных значения оказываются несовместимыми.
SELECT T1_txt, T2_txt
FROM T1
JOIN #T2
ON T1.T1_txt = #T2.T2_txt
Вот результирующий набор.
Сообщение 468, уровень 16, состояние 9, строка 2
Не удается разрешить конфликт сортировки между "Latin1_General_100_CI_AS_KS_WS_SC" и "Chinese_Simplified_Pinyin_100_CI_AS" в операции, равной операции.
Чтобы исправить эту проблему, можно явно задать параметры сортировки временной таблицы. SQL Server делает это несколько проще, предоставив DATABASE_DEFAULT ключевое слово для COLLATE предложения.
CREATE TABLE T1 (T1_txt nvarchar(max)) ;
GO
CREATE TABLE #T2 (T2_txt nvarchar(max) COLLATE DATABASE_DEFAULT);
GO
SELECT T1_txt, T2_txt
FROM T1
JOIN #T2
ON T1.T1_txt = #T2.T2_txt ;
Теперь операция работает без ошибки.
Различия параметров сортировки также проявляются в обработке переменных. Рассмотрим следующую функцию:
CREATE FUNCTION f(@x INT) RETURNS INT
AS BEGIN
DECLARE @I INT = 1
DECLARE @İ INT = 2
RETURN @x * @i
END;
Это довольно необычная функция. В параметров сортировки с @i учетом регистра предложение return не может привязаться ни к одному @I или @İ. В нечувствительном регистре Latin1_General сортировки, @i привязывается к @Iфункции и возвращается 1функция. Но в нечувствительном турецком параметров сортировки, @i привязывается к @İ, а функция возвращает 2. Это может негативно отразиться на базе данных, которая перемещается между экземплярами с различными параметрами сортировки.
Автономные базы данных
Поскольку задачей проектирования автономных баз данных является обеспечение их независимости, необходимо исключить зависимость от параметров сортировки экземпляра и базы данных tempdb. Для этого в автономных базах данных реализовано основное понятие параметров сортировки каталога. Параметры сортировки каталога используются для метаданных системы и временных объектов. Далее даны подробности.
В автономной базе данных параметры сортировки каталога Latin1_General_100_CI_AS_WS_KS_SC. Этот параметр сортировки одинаков для всех содержащихся баз данных во всех экземплярах SQL Server и не может быть изменен.
Параметры сортировки базы данных сохраняются, но используются только в качестве параметров сортировки по умолчанию для пользовательских данных. По умолчанию параметры сортировки базы данных равны model параметрам сортировки базы данных, но могут быть изменены пользователем с помощью CREATE команды или ALTER DATABASE команды, как и не содержащиеся в ней базы данных.
В предложении CATALOG_DEFAULT доступно новое ключевое слово COLLATE. Оно служит ярлыком для текущих параметров сортировки метаданных и в автономных и в неавтономных базах данных. Это значит, что в неавтономной базе данных конструкция CATALOG_DEFAULT возвращает текущие параметры сортировки базы данных, поскольку в метаданных применяются параметры сортировки базы данных. В автономной базе данных эти два значения могут различаться, поскольку пользователь может изменить параметры сортировки базы данных так, чтобы они отличались от параметров сортировки каталога.
В данной таблице представлен порядок обработки различных объектов в автономных и неавтономных базах данных.
| Товар | Неавтономная база данных | Автономная база данных |
|---|---|---|
| Пользовательские данные (по умолчанию) | DATABASE_DEFAULT | DATABASE_DEFAULT |
| Временные данные (по умолчанию) | tempdb Параметры сортировки |
DATABASE_DEFAULT |
| Метаданные | DATABASE_DEFAULT / CATALOG_DEFAULT | CATALOG_DEFAULT |
| Временные метаданные | tempdb Параметры сортировки |
CATALOG_DEFAULT |
| Переменные | Параметры сортировки экземпляра | CATALOG_DEFAULT |
| Метки перехода | Параметры сортировки экземпляра | CATALOG_DEFAULT |
| Имена курсоров | Параметры сортировки экземпляра | CATALOG_DEFAULT |
В приведенном ранее примере временной таблицы видно, что это поведение сортировки устраняет необходимость явного COLLATE предложения в большинстве временных таблиц. В автономной базе данных этот код теперь работает без ошибок, даже в случае, когда параметры сортировки различаются для базы данных и для экземпляра.
CREATE TABLE T1 (T1_txt nvarchar(max)) ;
GO
CREATE TABLE #T2 (T2_txt nvarchar(max));
GO
SELECT T1_txt, T2_txt
FROM T1
JOIN #T2
ON T1.T1_txt = #T2.T2_txt ;
Так происходит потому, что для T1_txt и T2_txt используются параметры сортировки автономной базы данных.
Между содержащимися и не содержащимися контекстами
Пока сеанс в автономной базе данных остается автономным, он должен оставаться в пределах базы данных, с которой установлено соединение. В этом случае работа ведется очевидным образом. Однако если сеанс переходит между автономными и неавтономными контекстами, то его обработка усложняется, поскольку требуется организовать связь между двумя наборами правил. Такое может случаться в частично автономной базе данных, поскольку пользователь может передать команду USE в другую базу данных. В этом случае различия в правилах параметров сортировки обрабатываются следующим образом.
- Правило параметров сортировки для пакета определяется базой данных, в которой начинается пакет.
Заметьте, что это решение принимается до обработки команд, включая первоначальную команду USE. То есть, если пакет начинается в автономной базе данных, но первая команда — USE это несоверная база данных, то для пакета все равно будет использоваться поведение параметров сортировки. В отношении переменных это может приводить к различным результатам.
Ссылка может обнаружить ровно одно соответствие. В этом случае ссылка будет работать без ошибок.
Ссылка может не найти соответствия в текущих параметрах сортировки на прежней позиции. В этом случае происходит ошибка, показывающая, что переменная не существует, хотя очевидно, что она была создана.
Ссылка может обнаружить несколько соответствий, которые прежде были различными. В этом случае также происходит ошибка.
Это показано в следующих примерах. Пусть имеется частично автономная база данных с именем MyCDB , для которой используются параметры сортировки каталога Latin1_General_100_CI_AS_WS_KS_SC. Мы предполагаем, что используются следующие параметры сортировки экземпляра: Latin1_General_100_CS_AS_WS_KS_SC. Таким образом, два набора параметров сортировки различаются только учетом регистра.
Пример 1
В следующем примере показан вариант, где ссылка обнаруживает ровно одно совпадение.
USE MyCDB;
GO
CREATE TABLE #a(x int);
INSERT INTO #a VALUES(1);
GO
USE master;
GO
SELECT * FROM #a;
GO
Results:
Вот результирующий набор.
x
-----------
1
В данном случае конструкция #a привязывается к параметрам сортировки каталога (без учета регистра) и к параметрам сортировки экземпляра (с учетом регистра) и код работает.
Пример 2
В следующим примере показан вариант, где ссылка не обнаруживает соответствие в текущих параметрах сортировки на прежней позиции.
USE MyCDB;
GO
CREATE TABLE #a(x int);
INSERT INTO #A VALUES(1);
GO
#A Здесь привязка к #a нечувствительной сортировке регистра по умолчанию, а также работает вставка.
Вот результирующий набор.
(1 row(s) affected)
Однако если работа скрипта продолжается...
USE master;
GO
SELECT * FROM #A;
GO
Мы получаем ошибку, пытающуюся привязаться к #A параметрам сортировки экземпляра с учетом регистра;
Вот результирующий набор.
Сообщение 208, уровень 16, состояние 0, строка 2
Недопустимое имя объекта «#A».
Пример 3
В следующем примере показан вариант, где ссылка обнаруживает несколько соответствий, которые прежде были различными. Во-первых, мы начнем с tempdb (который имеет ту же параметры сортировки с учетом регистра, что и наш экземпляр) и выполните следующие инструкции.
USE tempdb;
GO
CREATE TABLE #a(x int);
GO
CREATE TABLE #A(x int);
GO
INSERT INTO #a VALUES(1);
GO
INSERT INTO #A VALUES(2);
GO
Он завершается успешно, поскольку в данных параметрах сортировки таблицы различны.
Вот результирующий набор.
(1 row(s) affected)
(1 row(s) affected)
Однако если перейти в автономную базу данных, то окажется, что привязка к этим таблицам уже невозможна.
USE MyCDB;
GO
SELECT * FROM #a;
GO
Вот результирующий набор.
Msg 12800, Level 16, State 1, Line 2
The reference to temp table name #a is ambiguous and cannot be resolved. Possible candidates are #a and #A.