Особый интерес представляют индексы таблиц регистров, включающие поля измерений или базовых измерений.

Из индексов, создаваемых в таблицах базы данных, которые непосредственно из запросов не доступны, важно отметить индексы, создаваемые в каждой из таблиц итогов регистра бухгалтерии. Таблиц итогов создается на 1 больше, чем максимальное количество субконто в назначенном данному регистру плане счетов. Причем, отличаются они количеством полей значений субконто. В индекс входят следующие поля:

Период + Счет + Измерение1 [+ Измерение2 …] + ЗначениеСубконто1 [+ ЗначениеСубконто2 + …]

Ограничения на индексы

Поскольку для хранения данных 1С:Предприятие использует СУБД (либо встроенную, либо Microsoft SQL Server), то и поддержка индексов таблиц базы данных целиком возложена на используемую СУБД. Поэтому достижение ограничений, накладываемых различными СУБД на создание и использование индексов, может привести к ошибкам при работе с 1С:Предприятием. Поэтому при разработке конфигураций эти ограничения важно иметь в виду.

Файловый вариант информационной базы

Единственным ограничением на использование индекса при использовании СУБД, встроенной в 1С:Предприятие, является максимально допустимая суммарная длина ключа в индексе, равная 1920 байт. При попытке создания индекса с длиной ключа, превышающей 1920 байт, будет выдано сообщение об ошибке.

Клиент-серверный вариант информационной базы

Клиент-серверный вариант информационной базы подразумевает использование Microsoft SQL Server в качестве СУБД. В Microsoft SQL Server определены следующие ограничения на использование индексов:

• максимальное количество полей, участвующих в индексе, равно 16.
• максимально допустимая суммарная длина ключа в индексе равна 900 байт.

Важно иметь в виду, что в процессе определения объектов метаданных 1С:Предприятие при попытке создания индекса, включающего более 16 полей, в клиент-серверном варианте ИБ индекс усекается справа до 16. Это повышает надежность работы системы, но может привести к некоторому снижению производительности операций над соответствующими таблицами из-за ухудшения качества усеченных индексов.

О вычислении длины ключа

Длина ключа в индексе не является столь определенным понятием, как количество участвующих в нем полей. В общем случае при создании индекса невозможно точно определить длину ключа в создаваемом индексе. На то есть две основные причины:

• Во-первых, способ построения индекса существенно зависит от используемой СУБД.
• Во-вторых, длина ключа каждой записи индекса может зависеть от содержащихся в ней данных. В частности, при использовании в индексе полей типа VARBINARY Microsoft SQL Server помещает в запись индекса данные фактической длины, которая может быть меньше, чем заданная максимальная длина поля. С другой стороны, при использовании в индексе данных типа NCHAR или NVARCHAR длина представления этих данных в записи индекса для некоторых СУБД может существенно превышать максимальное количество символов, отведенное на поле строкового типа, из-за использования ключей сравнения (Collation Key), построение которых зависит от национальных настроек базы данных.

По этим причинам 1С:Преприятие 8.1 не выполняет автоматической проверки длин ключей создаваемых индексов. Таким образом, если при создании или использовании индекса будет превышена максимальная для данной СУБД длина ключа, то 1С:Предприятие выдаст сообщение об ошибке, порожденное используемой СУБД.

Рекомендации по конфигурированию

Поскольку введение ограничений на длины ключей в создаваемых индексах в платформе 1С:Предприятия не может быть универсальным и в тоже время может создать дополнительные сложности, при разработке конфигураций необходимо эти ограничения учитывать. Следование ниже приведенным правилам не позволит длинам ключей в индексах подходить к «критической отметке».

• Не используйте индексирование по строковым полям, суммарная длина которых превышает 300 символов. Такой индекс может быть создан при выборе в значения «Индексирование» или «Индексировать с дополнительным упорядочиванием» свойства «Индексировать» реквизита или измерения. Кроме того, индекс по полю будет создан при вхождении этого поля в какой-нибудь критерий отбора.
• Не используйте в регистрах слишком много измерений, особенно, если среди них есть поля строковых типов. Для ориентировки можно считать, что поле типа число занимает 16 байт ключа индекса, строка — 3*n байт (где n — максимальная длина строки), дата — 8 байт, булево — 1 байт, ссылка на один объект — 16 байт, ссылка на несколько объектов — 20 байт.
• Избегайте использование измерений составных типов. Исключение может составлять комбинирование ссылок различных типов.
• Не задавайте в планах счетов слишком большое максимальное количество субконто (превышение числа 5 может быть оправдано только в случае более тщательного анализа опасности превышения максимальной длины ключа индекса, и эффективности работы самого регистра).
• Не рекомендуется в одном регистре бухгалтерии использовать субконто со значениями различных примитивных типов. См. также Назначение прикладного объекта «План видов характеристик».
• Не используйте в регистрах бухгалтерии слишком большое количество измерений в сочетании с большим максимальным количеством субконто.

Техническая часть:

В файловом варианте 1С:Предприятия длина индекса ограничена 1920 байт.
Для составного индекса его длина рассчитывается как сумма длин полей, входящих в индекс.
Для различных типов данных 1С:Предприятия длина поля в байтах может быть вычислена по следующим формулам:

Кроме этого, существует ограничение на количество полей, входящих в составной индекс. Для СУБД, отличных от файловой, максимальное количество полей в составном индексе – 16. Для файловой СУБД – 256. Если индекс содержит большее количество полей – они автоматически отбрасываются. Так работает модель информационной базы 1С:Предприятия.

Теперь об индексировании:

Рассмотрим самый простой случай непериодического независимого регистра сведений с тремя измерениями: Изм1, Изм2, Изм3.
Для него система всегда автоматически (независимо от того, указаны или нет свойства Индексировать для каждого измерения) строит основной индекс Изм1 + Изм2 + Изм3 , в который входят все измерения в том порядке, в котором они заданы при конфигурировании.
Если для Изм2, например, задается свойство Индексировать, то создается еще один дополнительный индекс: Изм2 + Изм1 + Изм3 .
Если для Изм3, например, задается свойство Индексировать, то создается еще один дополнительный индекс: Изм3 + Изм1 + Изм2 .

Таким образом, в вашем случае, для регистра создано 20 индексов: основной и 19 дополнительных. Каждый из индексов содержит 20 полей.

Подробнее обо всех основных и дополнительных индексах написано на ИТС:

Судя по вашему сообщению, все измерения строкового типа, значит, на каждое измерение может максимально приходиться 1920/20 = 96 байт .
Исходя из приведенной выше формулы можно заключить, что длина каждого строкового измерения не может быть больше (96-2)/3 = 31 символа .

Таким образом, в порядке возрастания полезности, можно посоветовать следующее:
— снять свойство Индексировать у всех измерений, это удалит 19 ненужных индексов.
— проанализировать длину измерений и уменьшить ее исходя из максимум 31 символа на одно измерение.
— перепроектировать регистр.

По поводу проектирования:
1. Регистр сведений с 20 измерениями уже вызывает сомнения. Каждое измерение – это разрез, в котором может быть получена информация, хранящаяся в регистре. Сложно представить информацию, которую нужно получать в 20 разных разрезах.

Проводя разработки в клиент-серверной версии СУБД, мы можем порой не задумываться, какое количество индексов у нас есть в таблице, какие поля входят в индекс и к чему это приводит.

Иногда бывает необходимо развернуть копию нашей базы на файловой базе, и мы вдруг получаем ошибку (см. скрин).

Как найти быстро все проблемные индексы, которые приводят к ошибке?

Как выйти на те поля и таблицы, где мы что-то натворили?

Известно, что имена таблиц в файловой СУБД при создании отличаются от клиент-серверной, и поиск индекса, который указан в ошибке, нам ничего не даст.

Есть, конечно, вариант: искать по совпадению слов в данных, полученных методом ПолучитьСтруктуруХраненияБазыДанных()

Но это не всегда нам поможет быстро найти проблему.

На помощь приходят системные представления SQL сервера.

• sys.index_columns – Содержит одну строку для каждого столбца, являющегося частью индекса.
• sys.columns – Возвращает строку для каждого столбца объекта, имеющего столбцы, например представления или таблицы. В данной таблице есть столбец » max_length » максимальная длинна в байтах. На него мы и будем ориентироваться.
• sys.indexes – Содержит строку для каждого индекса или кучи табличного объекта, такого как таблица, представление или функция с табличным значением.

sys.dm_db_index_usage_stats – Возвращает количество различных операций с индексами и время,
которое было затрачено в SQL Server на последнее выполнение операции каждого типа.

Отправной точкой для поиска проблемных мест будет ограничение на индекс для файловой базы 1920 байт.

Выполняя запросы SQL для своей базы, не забудьте указать в начале инструкции USE ;

1) Сделаем первый запрос с рейтингом по размеру и сравним его с контрольной цифрой.

На скрине мы видим три таблицы с именами столбцов и индексов, которые создают нам проблему.

Осталось дело техники, найти эти данные в 1С с помощью ПолучитьСтруктуруХраненияБазыДанных() и откорректировать настройки (уменьшить длину индекса, снять индексирование).

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

Как вариант решения: уменьшаем длину строки, или снимаем индексацию (если индексирование поставлено на всякий случай).

2) Что делать, если мы сделали все, как сказано, а ошибки при обновлении на файловую базу все равно есть, как на скрине?

Выполняем следующий запрос и получаем количество индексов на таблицу с рейтингом по убыванию.

Далее смотрим первые строки и анализируем:

В данном списке мы видим количество индексов на таблицу. Начинаем анализировать сверху.

Но могу сказать, что проблема бывает не столько от количество индексов, сколько от количества полей, которые проиндексированы с доп. упорядочиванием.

Т.е. нам необходимо расшифровать – какие основные поля и сколько раз поля входят в индекс.

На практике оказалось, что наш вариант под номером два.

Как решение: снятие индексации с тех полей, которые не участвуют в отборах, выборках, связях и которые проиндексированы на всякий случай.

3) Для анализа полей, которые входят в индекс, необходимо выполнить следующий запрос:

Аналогичный результат, но в другом представлении мы получим, выполнив хранимую процедуру sp_helpindex, передав в качестве параметра имя таблицы.

Данная методика позволила быстро выявить проблемные индексы, столбцы которые приводили к ошибке.

На основании накопленного опыта можно сказать, что не надо индексировать на всякий случай, на будущее.

Ответ на вопрос, какие поля индексировать, и условие создания индекса можно посмотреть в статье:

Теперь нам необходимо определить неиспользуемые индексы.

Это надо в том случае, когда были созданы лишние индексы, а мы не знаем, использует ли их оптимизатор запроса или нет.

Или мы нашли множество некластерных индексов в таблице, а не знаем, какие нам нужны, а какие нет.

В данном случае можно выполнить следующий запрос с выводом неиспользуемых индексов. Обратите внимание, что используются объекты DMO, а для них необходимо, чтобы сервер работал продолжительное время, и функционал по интересующей нас таблице использовался достаточно интенсивно.

Не рекомендуется использовать данных запрос после перезапуска сервера.

Каковы издержки строки при использовании сжатия страницы?

Если вы попытаетесь создать свою таблицу без кластерного ограничения PK, и вы получите немного другую ошибку:

Сообщение 1701, уровень 16, состояние 1, строка 1 Создание или изменение таблицы «Mytable» не удалось, так как минимальный размер строки составил бы 8067, включая 1530 байтов внутренних издержек. Это превышает максимально допустимый размер строки таблицы в 8060 байт.

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

Теперь вы можете сделать математику:

• 8 байтов для bigintMyTableID
• 4 байта для intLastColumn
• 9 байтов для каждого из 593 numeric(19,4)столбцов (всего 5337 байтов)
• 1530 байтов накладных расходов на сжатие

Итак, 8 + 4 + (593 * 9) + 1530 = 6879. Подождите секунду … Это все еще ниже 8060. Что с этим ?!

Алгоритм сжатия страниц фактически объединяет несколько алгоритмов сжатия. Первый шаг — применить сжатие ROW. Накладные расходы на сжатие строк не включаются в 1530 байтов служебных данных, перечисленных в этом сообщении об ошибке.

Вы можете узнать больше о том, как работает сжатие строк, здесь, в моем блоге и здесь, в BOL . В статье BOL вы заметите, что она описывает numericхранилище как «Это хранилище точно такое же, как формат хранения vardecimal», но не объясняет vardecimal. Этот пост охватывает vardecimalнемного больше — по сути, он добавляет 2 байта служебной информации на столбец для хранения фактической длины (аналогично тому, что varcharделает).

Сжатие строки потребует дополнительных 2 байтов для каждого из 593 numericстолбцов, а также bigintи intпотребуется 1 байт служебной информации каждый.

В строках сжатых требований к хранению будут:

• 8 байтов + 1 байт для bigintMyTableID
• 4 байта + 1 байт для intLastColumn
• 9 байтов + 2 байта для каждого из 593 numeric(19,4)столбцов
• 1188 байтов накладных расходов на сжатие ROW

8 + 4 + (593 * 9) = 5349 байт данных

1 + 1 + (593 * 2) = 1188 байт для сжатия строки

Всего 6537 байт для схемы со сжатием строк

Теперь, когда у нас есть размер строки для схемы со сжатием строк, мы можем вернуться к нашей математике. Размер строки со сжатием страницы будет равен размеру данных + накладные расходы на сжатие строк + накладные расходы на сжатие страниц:

• 8 байтов для bigintMyTableID
• 4 байта для intLastColumn
• 9 байтов для каждого из 593 numeric(19,4)столбцов
• 1188 байтов накладных расходов на сжатие ROW
• 1530 байтов служебных данных сжатия PAGE

  5349 байт данных 
+ 1188 байтов на сжатие строк 
+ 1530 байтов на сжатие страницы 

Всего 8067 байт

Основы криптографии — тест 5

Какие операции применяются обычно в современных блочных алгоритмах симметричного шифрования?

&nbsp(1) возведение в степень&nbsp

&nbsp(2) замена бит по таблице замен&nbsp

&nbsp(3) нахождение остатка от деления на большое простое число&nbsp

&nbsp(4) перестановка бит&nbsp

&nbsp(5) сложение по модулю 2&nbsp

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

&nbsp(1) асимметричный шифр&nbsp

&nbsp(2) последовательный шифр&nbsp

&nbsp(3) композиционный шифр&nbsp

&nbsp(4) сложный шифр&nbsp

Алгоритм ГОСТ 28147-89 является

&nbsp(1) блочным алгоритмом симметричного шифрования&nbsp

&nbsp(2) алгоритмом формирования электронной цифровой подписи&nbsp

&nbsp(3) блочным алгоритмом асимметричного шифрования&nbsp

&nbsp(4) алгоритмом вычисления функции хеширования&nbsp

Каков размер входного блока обрабатываемой информации при использовании алгоритма ГОСТ 28147-89?

&nbsp(1) 48 бит&nbsp

&nbsp(2) 48 байт&nbsp

&nbsp(3) 56 бит&nbsp

&nbsp(4) 56 байт&nbsp

&nbsp(5) 64 бита&nbsp

&nbsp(6) 64 байта&nbsp

&nbsp(7) 128 бит&nbsp

&nbsp(8) 128 байт&nbsp

Какие операции применяются в шифре, определяемом ГОСТ 28147-89?

&nbsp(1) нахождение остатка от деления на большое простое число&nbsp

&nbsp(2) циклический сдвиг&nbsp

&nbsp(3) сложение по модулю 2&nbsp

&nbsp(4) возведение в степень&nbsp

&nbsp(5) замена бит по таблице замен&nbsp

Какова длина ключа в алгоритме, определяемом ГОСТ 28147-89?

&nbsp(1) 48 бит&nbsp

&nbsp(2) 48 байт&nbsp

&nbsp(3) 56 бит&nbsp

&nbsp(4) 56 байт&nbsp

&nbsp(5) 64 бита&nbsp

&nbsp(6) 64 байта&nbsp

&nbsp(7) 256 бит&nbsp

&nbsp(8) Длина ключа может быть переменной в зависимости от используемого количества раундов&nbsp

Какие шифры из перечисленных ниже относятся к композиционным шифрам?

&nbsp(1) ГОСТ 28147-89&nbsp

&nbsp(2) DES&nbsp

&nbsp(3) шифр Вижинера&nbsp

&nbsp(4) шифр Цезаря&nbsp

Алгоритм, определяемый стандартом ГОСТ 28147-89, является

&nbsp(1) алгоритмом вычисления функции хеширования&nbsp

&nbsp(2) алгоритмом формирования электронной цифровой подписи&nbsp

&nbsp(3) блочным алгоритмом асимметричного шифрования&nbsp

&nbsp(4) блочным алгоритмом симметричного шифрования&nbsp

Для решения задачи обнаружения искажений в зашифрованном массиве данных предусмотрен режим

&nbsp(1) гаммирования&nbsp

&nbsp(2) операции сложения по модулю 2&nbsp

&nbsp(3) простой замены&nbsp

&nbsp(4) подстановки&nbsp

&nbsp(5) выработки имитовставки&nbsp

Как называется комбинация бит, получаемая в одном из режимов использования ГОСТ 28147-89 и служащая для контроля изменений в зашифрованном сообщении?

&nbsp(1) имитовставка&nbsp

&nbsp(2) гамма&nbsp

&nbsp(3) цифровая подпись&nbsp

&nbsp(4) подстановка&nbsp

В каких режимах использования алгоритма ГОСТ 28147-89 возможно шифрование неполных блоков исходного текста?

&nbsp(1) в режиме простой поблочной замены&nbsp

&nbsp(2) в режиме гаммирования&nbsp

&nbsp(3) в режиме гаммирования с обратной связью&nbsp

&nbsp(4) в режиме создания хеш-кода&nbsp

Как называется режим использования блочного шифра, определяемого стандартом ГОСТ 28147-89, в котором каждый блок исходных данных шифруется независимо от остальных блоков с применением одного и того же ключа шифрования?

&nbsp(1) режим простой замены&nbsp

&nbsp(2) режим гаммирования&nbsp

&nbsp(3) режим гаммирования с обратной связью&nbsp

&nbsp(4) режим создания хеш-кода&nbsp

Что является особенностью использования режима простой замены блочного шифра, определяемого ГОСТ 28147-89?

&nbsp(1) одинаковые блоки исходного текста преобразуются в одинаковый шифротекст&nbsp

&nbsp(2) одинаковые сообщения, состоящие из нескольких блоков, преобразуются в разный шифротекст&nbsp

&nbsp(3) сообщение, зашифрованное в данном режиме, можно расшифровать только последовательно, начиная с первого блока&nbsp

&nbsp(4) сообщение, зашифрованное в данном режиме, можно расшифровать, выбирая блоки шифротекста в произвольном порядке&nbsp

&nbsp(5) этот режим рекомендуется использовать для шифрования данных с размером, не кратным размеру блока (64 битам)&nbsp

Что является особенностью использования режима гаммирования блочного шифра, определяемого ГОСТ 28147-89?

&nbsp(1) одинаковые блоки исходного текста преобразуются в одинаковый шифротекст&nbsp

&nbsp(2) одинаковые сообщения при использовании разных векторов инициализации преобразуются в одинаковый шифротекст&nbsp

&nbsp(3) сообщение, зашифрованное в данном режиме, можно расшифровать только последовательно, начиная с первого блока&nbsp

&nbsp(4) этот режим можно использовать для шифрования данных с размером, не кратным размеру блока (64 битам)&nbsp

&nbsp(5) этот режим работает очень медленно, что практически не позволяет использовать его для обработки больших (> 1 Кбайт) исходных сообщений&nbsp

Что является особенностью использования режима простой замены блочного шифра, определяемого ГОСТ 28147-89?

&nbsp(1) этот режим позволяет создать комбинацию бит, служащую для контроля изменений в зашифрованном сообщении&nbsp

&nbsp(2) одинаковые сообщения, даже состоящие из нескольких блоков, преобразуются в одинаковый шифротекст&nbsp

&nbsp(3) сообщение, зашифрованное в данном режиме, можно расшифровать только последовательно, начиная с первого блока&nbsp

&nbsp(4) сообщение, зашифрованное в данном режиме, можно расшифровать, выбирая блоки шифротекста в произвольном порядке&nbsp

&nbsp(5) этот режим рекомендуется использовать для шифрования данных с размером, не кратным размеру блока (64 битам)&nbsp

На сколько блоков будет разбито сообщение размером 1 Кбайт для шифрования алгоритмом по ГОСТ 28147-89?Ответ запишите в виде одного числа

&nbsp128&nbsp

На сколько блоков будет разбито сообщение размером 2 Кбайт для шифрования алгоритмом по ГОСТ 28147-89?Ответ запишите в виде одного числа

&nbsp256&nbsp

На сколько блоков будет разбито сообщение размером 4 Кбайт для шифрования алгоритмом по ГОСТ 28147-89?Ответ запишите в виде одного числа

&nbsp512&nbsp

На сколько блоков будет разбито сообщение размером 512 байт для шифрования алгоритмом по ГОСТ 28147-89?Ответ запишите в виде одного числа

&nbsp64&nbsp

Какая операция наиболее быстро выполняется при программной реализации алгоритмов шифрования?

&nbsp(1) сложения по модулю 2&nbsp

&nbsp(2) возведения в степень&nbsp

&nbsp(3) вычисления дискретных логарифмов&nbsp

&nbsp(4) нахождения остатка от деления на большое простое число&nbsp

&nbsp(5) умножения по модулю 2³²&nbsp

&nbsp(6) перестановки бит&nbsp

Какой способ реализации криптографических методов обладает максимальной скоростью обработки данных?

&nbsp(1) программный&nbsp

&nbsp(2) ручной&nbsp

&nbsp(3) аппаратный&nbsp

Какие факторы влияют на стойкость блочного алгоритма шифрования?

&nbsp(1) используемые операции&nbsp

&nbsp(2) длина ключа&nbsp

&nbsp(3) количество раундов&nbsp

&nbsp(4) год разработки&nbsp

Что является основным недостатком программной реализации криптографических методов?

&nbsp(1) небольшое быстродействие&nbsp

&nbsp(2) высокая стоимость разработки&nbsp

&nbsp(3) небольшая разрядность&nbsp

&nbsp(4) невозможность использования в современных беспроводных сетях&nbsp

Каков российский стандарт на блочный алгоритм симметричного шифрования?

&nbsp(1) ГОСТ 28147-89&nbsp

&nbsp(2) ГОСТ Р3410-94&nbsp

&nbsp(3) ГОСТ 3411-94&nbsp

&nbsp(4) DES&nbsp

&nbsp(5) AES&nbsp

Что общего имеют все методы шифрования с закрытым ключом?

&nbsp(1) в них для шифрования информации используется один ключ, а для расшифрования – другой ключ&nbsp

&nbsp(2) в них для шифрования и расшифрования информации используется один и тот же ключ&nbsp

&nbsp(3) в них входной поток исходного текста делится на блоки, в каждом из которых выполняется перестановка символов&nbsp

&nbsp(4) в них производится сложение символов исходного текста и ключа по модулю, равному числу букв в алфавите&nbsp

максимальная длина ключа (строка) превышена советы

Вопрос: Я создаю индекс и получаю это ошибка: «ORA-01450: превышена максимальная длина ключа (строка)». Я знаю, что максимальная длина ключа зависит от размера блока. и мне интересно, стоит ли мне снова попытаться создать индекс с большим размером блока?

Ответ: Ошибка ORA-01450 связана с вашим db_block_size , а максимальная длина ключа для вашей базы данных составляет примерно 40% размера блока базы данных минус несколько накладные расходы.

Однако у вас есть более серьезная проблема: CBO использовать индекс с большим значением ключа!

Индексы с длинными индексными ключами используются редко!

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

И нет, я бы не рекомендовал перестраивать этот индекс в более крупном размер блока.Пока построение индексов в более крупном блоке имеет некоторые маргинальные преимущества для сверхмощных баз данных (более плоская древовидная структура, и более высокая пропускная способность для индекса сканирование диапазона), Oracle CBO почти всегда выбирает сканирование всей таблицы по индексу с очень большим ключом.

Я бы подумал о поиске индексов контекста Oracle, если база данных доступна только для чтения во время окна запроса, и вы хотите искать в длинных текстовых значениях:

В документах Oracle есть эти примечания об ошибке ORA-01450:

ORA-01450: максимальная длина ключа (строка) превышена

Причина: Суммарная длина всех столбцов указанный в операторе CREATE INDEX превысил максимальный индекс длина.Максимальная длина индекса зависит от операционной системы.

общая длина индекса вычисляется как сумма ширины всех проиндексированные столбцы плюс количество проиндексированных столбцов.

Поля даты имеют длину 7, символьные поля имеют определенную длину, а числовые поля имеют длину 22. Числовая длина = (точность / 2) +1. Если отрицательное, добавьте +1.

Действие: Выберите столбцы для индексации, чтобы общая длина индекса не превышает максимальную длину индекса для операционная система.

См. Также, зависит от вашей операционной системы. Документация Oracle.

У Jmodic есть эти наблюдения о взаимосвязи между ошибка ORA-01450 и размер блока базы данных:

Максимально допустимая длина ключа индекса зависит от размера вашего блока. Таким образом, минимально допустимый размер, указанный в ORA-01450, варьируется, в зависимости от того, какой размер блока использует ваш индекс:

ORA-01450 превышена максимальная длина ключа (758) -> (блок 2K)

ORA-01450 превышена максимальная длина ключа (1578) -> (блок 4K)

ORA-01450 превышена максимальная длина ключа (3218) -> (блок 8K)

ORA-01450 превышена максимальная длина ключа (6498) -> (блок 16K)

MySQL :: Справочное руководство MySQL 8.0 :: 15.22 Ограничения InnoDB

  ОШИБКА 1070 (42000): указано слишком много ключевых частей; макс.16 частей допускается  

ORA-01450: Превышена максимальная длина ключа — возможные причины и исправление

ORA-01450 может возникнуть при создании индекса таблицы в базе данных.

 ORA-01450: превышена максимальная длина ключа (6398) 

говорится об ошибке:

Причина: Суммарная длина всех столбцов, указанных в операторе CREATE INDEX, превышает максимальную длину индекса. Максимальная длина индекса зависит от операционной системы.

Общая длина индекса вычисляется как сумма ширины всех проиндексированных столбцов плюс количество проиндексированных столбцов.

Поля даты имеют длину 7, символьные поля имеют определенную длину, а числовые поля имеют длину 22. Числовая длина = (точность / 2) + 1. Если отрицательное значение, добавьте +1.

Действие: Выберите столбцы для индексации, чтобы общая длина индекса не превышала максимальную длину индекса для операционной системы.

Действие предлагает выбрать столбцы индекса иначе, чтобы не выходить за пределы длины индекса.

Но не всегда все так просто. Столкнувшись с этой ошибкой при установке стандартных продуктов Oracle, таких как компоненты FMW или OBIEE, никто не может следовать этому совету и возиться со столбцами индекса.

Как же тогда исправить эту ошибку? В этом сообщении предлагаются возможные основные причины и решение для ORA-01450, когда изменение самого индекса не является жизнеспособным вариантом.

1. Размер блока DB

Распространенной причиной ошибки ORA-01450 является недостаточный размер блока БД для индекса.

Чтобы проверить размер блока БД, войдите в систему как системный пользователь и покажите значение параметра db_block_size.

 SQL> показать параметр DB_BLOCK_SIZE

ИМЯ ТИП ЗНАЧЕНИЕ
------------------------------------ ----------- --- -
db_block_size целое число 8192
 

Oracle ограничивает ключ индекса примерно до 3/4 размера блока БД. Таким образом, с db_block_size равным 8192 (кстати, это значение по умолчанию) вы можете иметь максимальную длину ключа 6398. Если у вас ДОЛЖНА быть длина ключа, превышающая этот предел, увеличение db_block_size для размещения индекса может устранить ошибку.

2. Кодировка символов

Продукты Oracle обычно рекомендуют AL32UTF8 в качестве набора символов для базы данных Oracle, используемой в качестве их репозитория (пример).

Если вы запустите Oracle RCU (Repository Creation Utility) в базе данных, отличной от AL32UTF8, появится предупреждение:

База данных, которую вы подключаете, имеет набор символов, отличный от AL32UTF8. Oracle настоятельно рекомендует использовать AL32UTF8 в качестве набора символов базы данных.

Хотя в документации указано, что

Вы можете проигнорировать это предупреждение и продолжить использование RCU

, известно, что набор символов, отличный от AL32UTF8, вызывает ошибку «ORA-01450: максимальная длина ключа превышена».

Если вы видите ORA-01450 в базе данных, отличной от AL32UTF8, подумайте об изменении набора символов на AL32UTF8.

Чтобы узнать текущий набор символов, выберите из nls_database_parameters.

 SQL> выберите * из nls_database_parameters
2, где параметр = 'NLS_CHARACTERSET';

ПАРАМЕТР ЗНАЧЕНИЕ
------------------------------ -------------
NLS_CHARACTERSET WE8MSWIN1252
 

Внимание! Важно проанализировать и устранить влияние, если вы решите изменить набор символов базы данных после создания базы данных.См. Подробности в Руководстве по поддержке Oracle Globalization [изменение набора символов базы данных (12.1)].

3. Семантика длины NLS

NLS Length Semantics может иметь значение BYTE (по умолчанию) или CHAR (дополнительные сведения см. В этой статье Oracle или в Руководстве по поддержке глобализации Oracle), но многие продукты Oracle FMW говорят примерно так:

Oracle Fusion Middleware поддерживает схемы только в базе данных с байтовым режимом. Параметр инициализации nls_length_semantics в базе данных, где находятся схемы, должен иметь значение BYTE; установка для этого параметра значения CHAR не поддерживается.

(источник: руководство по установке GoldenGate Monitor v12)

Несовместимая настройка семантики длины NLS является частой причиной появления сообщения «ORA-01450: превышена максимальная длина ключа» в установках продукта Oracle.

Чтобы проверить семантику длины NLS в вашей базе данных, войдите в систему как системный пользователь и покажите значение параметра nls_length_semantics.

 SQL> показать параметры nls_length_semantics
ИМЯ ТИП ЗНАЧЕНИЕ
------------------------------------ ----------- --- -
nls_length_semantics строка BYTE
 

Изменение параметра инициализации с CHAR на BYTE и перезапуск базы данных могут устранить ошибку.

Примечание: После изменения параметра базы данных не забудьте вернуть базу данных, чтобы измененный параметр вступил в силу, а затем снова попытайтесь создать индекс.

Сводка

В этой статье описываются три вероятные причины и их исправления для ошибки Oracle ORA-01450: максимальная длина ключа превышает , когда изменение самого ключа индекса не является жизнеспособным вариантом. Он рекомендует проверять следующие значения в базе данных Oracle:

1. Размер блока DB
2. Кодировка символов
3. Семантика длины NLS

Дополнительные сведения о классических ошибках Oracle см. В статьях в категории «Ошибки ORA».

Характеристики максимальной емкости для SQL Server — SQL Server

предупреждение, максимальная длина ключа составляет 900 байт

Привет, друзья,

Сегодня я просто хочу сосредоточиться на предупреждении «Предупреждение: максимальная длина ключа составляет 900 байт…»

На самом деле, иногда мы создаем индекс с переменной длиной ключа больше 900 байт.При создании таких индексов sql server выдает нам предупреждение. Мы должны серьезно отнестись к такому виду предупреждения. Позвольте мне объяснить это на примере:

Создайте таблицу с помощью следующего скрипта:

 СОЗДАТЬ ТАБЛИЦУ [dbo]. [XtTest] (
    [id] [int] НЕ ПУСТО,
    [имя] [varchar] (50) НЕ ПУСТО,
    [город] [varchar] (400) НЕ ПУСТО,
    [описание] [varchar] (500) NOT NULL
) НА [ОСНОВНОЙ] 

Теперь просто создайте индекс со скриптом ниже:

 создать индекс IX_xtTest на xtTest (название, город, описание) 

, но на момент создания такого индекса SQL Server дает нам потепление:

Предупреждение! Максимальная длина ключа составляет 900 байт.Индекс IX_xtTest имеет максимальную длину 950 байт. Для некоторой комбинации больших значений операция вставки / обновления завершится ошибкой.

Здесь мы сталкиваемся с предупреждением, потому что тип данных ключевого столбца — это тип переменной длины. Теперь мы просто хотим вставить данные в таблицу xtTest:

 вставить в значения xtTest (1, 'prince', 'gurgaon', 'gurgaon is in haryana state') 

вышеуказанный запрос выполняется успешно и вставляет одну строку в таблицу xtTest, поскольку общая длина данных для ключевого столбца индекса меньше 900 байт.Предположим, что по прошествии многих дней мы хотим вставить строку, длина ключа индекса которой превышает 900 байт. Что произойдет, если мы вставим данные ключа длиной не более 900 байт. Вставьте другую строку с указанным ниже запросом, но сначала замените строки длиной 400 и 500 символов

 вставить в значения xtTest (2, 'kamal', 'вставить любую строку, содержащую 400 символов', 'вставить любую строку, содержащую 500 символов') 

, когда мы запускаем вышеуказанный запрос, появляется ошибка

Операция не удалась.Запись индекса длиной 905 байтов для индекса «IX_xtTest» превышает максимальную длину 900 байтов.

Эта ошибка возникает из-за того, что мы игнорируем предупреждение, появившееся ранее при создании индекса IX_xtTest. Так что моя цель здесь: «Никогда не игнорировать подобные предупреждения».

При создании индекса всегда учитывайте тот факт, что «длина ключевых столбцов индекса не должна превышать 900 байт».

Если вы действительно хотите добавить столбцы такого типа в индекс, используйте опцию включения.Это означает, что вы можете создать вышеуказанный индекс, как показано ниже:

 создать индекс IX_xtTest на xtTest (название, город)
включить (описание) 

Здесь ключевыми столбцами индекса являются только имя и город.

С уважением

Князь Растоги

Поставьте нам лайк на FaceBook | Следуйте за нами в Twitter | Присоединяйтесь к самой быстрорастущей группе SQL Server на FaceBook

Следуйте за мной в Twitter | Следуй за мной на FaceBook

Пределы Db2 в Db2 12 — Программное обеспечение BMC

Длина ключа строковых столбцов MySQL — Веллинг Гусман

После переключения кодировки по умолчанию с utf8 на utf8mb4 для поддержки смайлов в Directus мы начали получать ошибки о том, что ключ слишком длинный.Мне интересно, как изменение кодировки влияет на длину ключа. Ниже можно увидеть примеры ошибок:

 # 1071 - Указанный ключ слишком длинный; максимальная длина ключа 767 байт
# 1071 - Указанный ключ был слишком длинным; максимальная длина ключа составляет 1000 байт
# 1071 - Указанный ключ был слишком длинным; максимальная длина ключа 3072 байта
 

Это может быть любая из предыдущих ошибок в зависимости от механизма хранения таблицы. MySIAM, InnoDb или InnoDb с включенным innodb_large_prefix имеют разные ограничения длины ключа.

TL; DR №

Разница между кодировкой utf8 и utf8mb4 заключается в количестве байтов, необходимых для хранения каждого символа. utf8 требует 3 байта, а utf8mb4 требует 4 байта. Это означает использование кодировки utf8mb4 в таблице с механизмом innodb с отключенным innodb_large_prefix , необходимо использовать не более 191 символа в строковом столбце.

191 символ × 4 байта = 764 байта, что меньше максимальной длины в 767 байтов, разрешенной при отключении innodb_large_prefix .Начиная с MySQL 5.7 innodb_large_prefix включен по умолчанию, разрешая до 3072 байтов.

Хранение строк #

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

Например, CHAR имеет фиксированную длину, а VARCHAR и TEXT — переменную длину.

Все типы данных фиксированной длины используют все байты, которые были объявлены.Например, CHAR (16) , независимо от его значения, оно заполняется справа пробелами для заполнения до определенной длины. С другой стороны, VARCHAR использует только 1 байт + размер содержимого.

VARCHAR требует, чтобы значение префикса равнялось 1 байту, чтобы сохранить длину строки, если размер меньше 256, в противном случае будет использоваться 2 байта.

Один совет — не использовать CHAR, если вы не собираетесь использовать все символы почти все время, потому что размер может накапливаться с пустыми столбцами строк.

Набор символов #

Набор символов UTF8 использует максимум 3 байта на символ и содержит только символы базовой многоязычной плоскости (BMP), которые являются домом для 65 536 символов (16 бит) от U + 0000 до U + FFFF .

Набор символов UTF8mb4 использует максимум 4 байта на символ, включая все символы BMP и дополнительную многоязычную плоскость (SMP), что включает еще одну возможность 65 536 новых символов от U + 10000 до U + 1FFFF .

Emojis (символы Unicode) #

UTF8 может поддерживать смайлики, но не все из них. Все новые смайлы являются частью SMP, поэтому для поддержки как базовой, так и дополнительной многоязычной плоскости необходимо использовать UTF8mb4 .

Значение яркого эмодзи (✨ U + 2728 ) находится в диапазоне от U + 0000 до U + FFFF , тогда его можно использовать в кодировке utf8 , но медработник-женщина (👩 U + 1F469 ) значение, которое не находится между U + 0000 и U + FFFF , должно использовать кодировку utf8mb4 , которая находится в диапазоне от U + 10000 до U + 1FFFF .

Длина индекса #

Теперь после использования utf8mb4 все символы используют 4 байта вместо 3, поэтому все столбцы, содержащие более 191 символа, теперь используют более 767 байтов, потому что 192 x 4 байта составляют 768 байтов.

Имейте в виду, что ограничение в 768 байт действует только при использовании движка innodb, а innodb_large_prefix отключено. Начиная с MySQL 5.7 innodb_large_prefix включен по умолчанию, разрешая до 3072 байтов. MySIAM имеет максимальную длину 1000 байт.

Решения №

Решение будет зависеть от того, что нам действительно нужно: это может быть удаление индекса, продолжение использования utf8 , добавление длины к ключу индекса или уменьшение длины столбца.

Уменьшить длину #

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

Длина индекса #

Если изменение длины невозможно или желательно, изменение индекса столбца только на кусок из n символов — еще один возможный вариант.