Производительность Oracle ужасна после изменения полей Varchar2 на NVarchar2

Question

Любая помощь или предложения приветствуются.Я разрабатывал проект DotNet для oracle (Версия 10.2) в течение последних нескольких месяцев и использовал Varchar2 для своих полей строковых данных.Это было хорошо, и при навигации по страницам проекта обновления никогда не превышали полсекунды, если даже (это тихий проект с интенсивным использованием данных).На данные ссылаются две разные схемы: одна - централизованное хранилище данных, а другая - моя.Теперь централизованная схема изменится на совместимость с юникодом (но пока еще нет), поэтому все поля Varchar2 станут NVarchar2, в процессе подготовки я изменил все поля в своей схеме на NVarchar2, и с тех пор производительность была ужаснойдо 30/40 секунд обновления страницы.

Возможно, это связано с тем, что поля Varchar2 в централизованной схеме будут объединены с полями NVarchar2 в моей схеме в некоторых хранимых процедурах.Я знаю, что NVarchar2 в два раза больше Varchar2, но это не объясняет внезапное массовое изменение.Как я уже сказал, любые советы о том, что нужно искать для улучшения, были бы хорошими, если бы я недостаточно хорошо объяснил сценарий, попросите дополнительную информацию.

С уважением

Answer 1

Во-первых, сделайте

select * from v$nls_parameters where parameter like '%SET%';

Наборы символов могут быть сложными. Вы можете иметь однобайтовые наборы символов, многобайтовые наборы символов фиксированного размера и многобайтовые наборы символов переменного размера. См. Описания Unicode здесь

Во-вторых, если вы соединяете строку в однобайтовом наборе символов со строкой в ​​двухбайтовом наборе символов, у вас есть выбор. Вы можете выполнить двоичное / байтовое сравнение (которое, как правило, не будет совпадать, если вы сравните между однобайтовым набором символов и двухбайтовым набором символов). Или вы можете провести лингвистическое сравнение, которое, как правило, будет означать некоторую стоимость ЦП, поскольку одно значение преобразуется в другое, и часто не удается использовать индекс.

Упорядочены индексы, A, B, C и т. Д. Но такие символы, как Ä, могут попадать в разные места в зависимости от языкового порядка. Скажем, структура индекса ставит Ä между A и B. Но тогда вы делаете лингвистическое сравнение. Язык этого сравнения может поставить Ä после Z, и в этом случае индекс не может быть использован. (Помните, что ваше состояние может быть МЕЖДУ, а не =).

Короче говоря, вам потребуется много подготовки, как в вашей схеме, так и в центральном хранилище, чтобы обеспечить эффективное соединение между различными наборами символов.

Answer 2

Скорее всего, он больше не сможет использовать индексы, которые раньше могли.Как Нарендра предлагает проверить план объяснения, чтобы увидеть, что изменилось.Возможно, что после изменения централизованного хранилища индексы снова станут пригодными для использования.Я предлагаю проверить этот путь.

Answer 3

Israfel,

Трудно сказать что-либо на основании того, что вы предоставили. Удалось ли вам проверить, изменились ли предполагаемые количества элементов и / или план объяснения, когда вы изменили тип данных на NVARCHAR2? Возможно, вы захотите прочитать следующий пост в блоге, чтобы увидеть, если вы можете найти лидерство http://joze -senegacnik.blogspot.com / 2009/12 / ООТ-курьезы-в-определивших-selectivity.html

Answer 4

Правильная установка параметра инициализации NLS_LANG необходима для правильного преобразования данных.Набор символов, указанный параметром инициализации NLS_LANG, должен отражать настройки для клиентской операционной системы.Правильная настройка NLS_LANG позволяет правильно преобразовать кодовую страницу операционной системы клиента в набор символов базы данных.Когда эти параметры совпадают, Oracle предполагает, что отправляемые или получаемые данные кодируются в том же наборе символов, что и набор символов базы данных, поэтому проверка или преобразование не выполняется.Это может привести к повреждению данных, если необходимы преобразования.