Длина ключа индекса превышает допустимую длину
По теме из базы знаний
- Методы борьбы с ошибками загрузки .DT в файловом варианте
- Длина ключа индекса превышает максимально допустимую. Решение и рекомендации
- Длина ключа индекса превышает максимально допустимую. Решение с использованием технологического журнала
- Поддержка пользователей [Alt+S] (подключаемое расширение)
- Опыт неудачной сдачи Эксперт по технологическим вопросам
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Подскажите, или дайте ссыль на литературу. Инересует такой вопрос: почему не стоит в регистрах использовать измерения базовых типов? Т.е. можно но не нужно. Ответ я примерно понимаю, но мне нужен вразумительный, однозначный и главное единственно верный. Такой, что бы у преподавателя на спеце по платформе не возникло желания задавать доп. вопросы по этой теме (ну и самому бы окончательно в этом разобраться хотелось бы).
(9) 1985Alex1985, если отсебятина, то я бы объяснил следующим образом:
1) во-первых, все упирается в длину Строки/Числа: при больших значениях замедляется работа с регистром.
2) во-вторых, возрастает вероятность ошибки, если приходится задавать значения такого измерения вручную (и чем длинее Строка/Число, тем вероятность, логично предположить, возрастает). Т.е., например, записывали на предприятии в некий регистр некоторое текстовое измерение, а потом руководство подумало и решило, что надо бы по-другому значение этого измерения записывать: было, например, "Вася", а стало "Василий Петрович"... И тут уже возникает проблемка со сбором, например, оборотов по этому Васе/Василию Петровичу. Другое дело, если это элемент справочника: наименование поменял и у всех записей поменялось представление, ибо ссылка осталась прежней.
Я считаю эти доводы довольно весомыми, чтобы поменьше использовать примитивные типы в качестве измерений. И мне интересно: действительно где-то аж 12мерный регистр используется или народ забывает, что у регистров есть еще и реквизиты для детализации?)
1) во-первых, все упирается в длину Строки/Числа: при больших значениях замедляется работа с регистром.
2) во-вторых, возрастает вероятность ошибки, если приходится задавать значения такого измерения вручную (и чем длинее Строка/Число, тем вероятность, логично предположить, возрастает). Т.е., например, записывали на предприятии в некий регистр некоторое текстовое измерение, а потом руководство подумало и решило, что надо бы по-другому значение этого измерения записывать: было, например, "Вася", а стало "Василий Петрович"... И тут уже возникает проблемка со сбором, например, оборотов по этому Васе/Василию Петровичу. Другое дело, если это элемент справочника: наименование поменял и у всех записей поменялось представление, ибо ссылка осталась прежней.
Я считаю эти доводы довольно весомыми, чтобы поменьше использовать примитивные типы в качестве измерений. И мне интересно: действительно где-то аж 12мерный регистр используется или народ забывает, что у регистров есть еще и реквизиты для детализации?)
Подниму немного тему :-))
Есть файловая БД. Есть РС. 2 измерения на строку 1024 и 1 ресурс на 1024. Ругалось на индексы.
Сделал для теста по 150 и конфа обновилась.
Вспомнилось что когда-то пытался вычислить максимальное значение. Это было на строковом регистре у которых сумма всех длин строк была меньше 1024.
Есть файловая БД. Есть РС. 2 измерения на строку 1024 и 1 ресурс на 1024. Ругалось на индексы.
Сделал для теста по 150 и конфа обновилась.
Вспомнилось что когда-то пытался вычислить максимальное значение. Это было на строковом регистре у которых сумма всех длин строк была меньше 1024.
У клиента стоит 8.0. Переходить на 8.1 не хочет. Внес изменения в конфу. Пытаюсь обновить базу данных. Пишет, что не станет обновлять :( (см. скрин)
Кто такое видел, и что делать?
Появилось после того, как добавил регистр сведений с 12-ю измерениями, типа Строка, длина 100 (переменная).
Кто такое видел, и что делать?
Появилось после того, как добавил регистр сведений с 12-ю измерениями, типа Строка, длина 100 (переменная).
Прикрепленные файлы:
Диск ИТС
Ограничения на индексы
Поскольку для хранения данных 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.0 не выполняет автоматической проверки длин ключей создаваемых индексов. Таким образом, если при создании или использовании индекса будет превышена максимальная для данной СУБД длина ключа, то 1С:Предприятие выдаст сообщение об ошибке, порожденное используемой СУБД.
Рекомендации по конфигурированию
Поскольку введение ограничений на длины ключей в создаваемых индексах в платформе 1С:Предприятия не может быть универсальным и в тоже время может создать дополнительные сложности, при разработке конфигураций необходимо эти ограничения учитывать. Следование ниже приведенным правилам не позволит длинам ключей в индексах подходить к "критической отметке".
Не используйте индексирование по строковым полям, суммарная длина которых превышает 300 символов. Такой индекс может быть создан при выборе в значения "Индексирование" или "Индексировать с дополнительным упорядочиванием" свойства "Индексировать" реквизита или измерения. Кроме того, индекс по полю будет создан при вхождении этого поля в какой-нибудь критерий отбора.
Не используйте в регистрах слишком много измерений, особенно, если среди них есть поля строковых типов. Для ориентировки можно считать, что поле типа число занимает 16 байт ключа индекса, строка - 3*n байт (где n - максимальная длина строки), дата - 8 байт, булево - 1 байт, ссылка на один объект - 16 байт, ссылка на несколько объектов - 20 байт.
Избегайте использование измерений составных типов. Исключение может составлять комбинирование ссылок различных типов.
Не задавайте в планах счетов слишком большое максимальное количество субконто (превышение числа 5 может быть оправдано только в случае более тщательного анализа опасности превышения максимальной длины ключа индекса, и эффективности работы самого регистра).
Не рекомендуется в одном регистре бухгалтерии использовать субконто со значениями различных примитивных типов. См. также Назначение прикладного объекта "План видов характеристик".
Не используйте в регистрах бухгалтерии слишком большое количество измерений в сочетании с большим максимальным количеством субконто.
ПоказатьПоскольку для хранения данных 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.0 не выполняет автоматической проверки длин ключей создаваемых индексов. Таким образом, если при создании или использовании индекса будет превышена максимальная для данной СУБД длина ключа, то 1С:Предприятие выдаст сообщение об ошибке, порожденное используемой СУБД.
Рекомендации по конфигурированию
Поскольку введение ограничений на длины ключей в создаваемых индексах в платформе 1С:Предприятия не может быть универсальным и в тоже время может создать дополнительные сложности, при разработке конфигураций необходимо эти ограничения учитывать. Следование ниже приведенным правилам не позволит длинам ключей в индексах подходить к "критической отметке".
Не используйте индексирование по строковым полям, суммарная длина которых превышает 300 символов. Такой индекс может быть создан при выборе в значения "Индексирование" или "Индексировать с дополнительным упорядочиванием" свойства "Индексировать" реквизита или измерения. Кроме того, индекс по полю будет создан при вхождении этого поля в какой-нибудь критерий отбора.
Не используйте в регистрах слишком много измерений, особенно, если среди них есть поля строковых типов. Для ориентировки можно считать, что поле типа число занимает 16 байт ключа индекса, строка - 3*n байт (где n - максимальная длина строки), дата - 8 байт, булево - 1 байт, ссылка на один объект - 16 байт, ссылка на несколько объектов - 20 байт.
Избегайте использование измерений составных типов. Исключение может составлять комбинирование ссылок различных типов.
Не задавайте в планах счетов слишком большое максимальное количество субконто (превышение числа 5 может быть оправдано только в случае более тщательного анализа опасности превышения максимальной длины ключа индекса, и эффективности работы самого регистра).
Не рекомендуется в одном регистре бухгалтерии использовать субконто со значениями различных примитивных типов. См. также Назначение прикладного объекта "План видов характеристик".
Не используйте в регистрах бухгалтерии слишком большое количество измерений в сочетании с большим максимальным количеством субконто.
Я так понял, что индекс формируется в совокупности по длине всех измерений. Попробуйте уменьшить длину строки в каком-нибудь измерении.
У меня была на файловой базе такая беда.
Было несколько измерений с длинами строки по 150. Добавил еще одно измерение с длиной 3. После этого ошибка стала вылетать.
Уменьшил у одного из измерений длину с 150 до 100. Все нормально обновилось.
В клиент-серверном варианте проблема не наблюдалась
У меня была на файловой базе такая беда.
Было несколько измерений с длинами строки по 150. Добавил еще одно измерение с длиной 3. После этого ошибка стала вылетать.
Уменьшил у одного из измерений длину с 150 до 100. Все нормально обновилось.
В клиент-серверном варианте проблема не наблюдалась
Ключ индекса таблицы msSQL до версии 2016 использует 16 полей (или 900 байт). Для физической таблицы итогов регистра бухгалтерии с тремя субконто, (так как они составные), только по субконто используется по 3 поля, и это в сумме уже 9 полей для ключа индекса + 1 поле на служебный разделитель = 10. А еще период и остальные измерения, признаки учета.... вот и все 15 ... 16 полей.
В SQL Server 2016 и в Azure SQL Database увеличен максимальный размер ключа в некластерном индексе с 900 до 1700 байт. Максимальный размер ключа для кластерного индекса по-прежнему остается 900 байт. Знающие люди по 1С - уточните, какие индексы он создает как кластерные, а какие как обычные
PS: Если субконто будет примитивного типа, а не ссылочного, то на каждое субконто будет по 4 поля на индексирование. В результате на три субконто ключ уже будет использовать 12 полей а не 9. Поэтому для субконто НЕ НАДО ИСПОЛЬЗОВАТЬ ПРИМИТИВНЫЕ ТИПЫ.
Для регистров сведений или накопления - можно экстраполировать эти рассуждения, касательно их физических таблиц движений и итогов. Но там конечно все менее жестко.
В SQL Server 2016 и в Azure SQL Database увеличен максимальный размер ключа в некластерном индексе с 900 до 1700 байт. Максимальный размер ключа для кластерного индекса по-прежнему остается 900 байт. Знающие люди по 1С - уточните, какие индексы он создает как кластерные, а какие как обычные
PS: Если субконто будет примитивного типа, а не ссылочного, то на каждое субконто будет по 4 поля на индексирование. В результате на три субконто ключ уже будет использовать 12 полей а не 9. Поэтому для субконто НЕ НАДО ИСПОЛЬЗОВАТЬ ПРИМИТИВНЫЕ ТИПЫ.
Для регистров сведений или накопления - можно экстраполировать эти рассуждения, касательно их физических таблиц движений и итогов. Но там конечно все менее жестко.
Тема старая, но кому-то будет интересно и сегодня. В случае с индексами для регистра сведений, связанного со значениями для плана характеристик, всегда создаются дополнительные поля для всех возможных типов, даже если в типе плана характеристик указан только один тип "строка". На всё, кроме строки выделяется всегда 64 байта. Остаётся 836 байт для строки. Поскольку строки 1С - это UTF-8 строки, то резервируется двойной объем, поэтому для вычисления максимальной длины строки 836 делим на 2, получаем 418 символов максимальная длина строки. Я столкнулся с проблемой, когда в нескольких свойствах нужна длина строки в символах свыше 590 символов, и пришлось отключить этот индекс, чтобы обновить базу данных. В последних версиях 1С плюётся на отключенный индекс в регистре, даже если непосредственно сам регистр не подлежит реструктуризации. Например, в поле "объект" в составном типе присутствует справочник, в который я решил добавить ещё одно поле, и обновление не производится. Более того, из-за отключенного индекса программа аварийно завершает обновление и больше зайти в конфигуратор не получится - попытка обновления всегда будет неудачной, а без удачного обновления не сможете изменить тип в плане видов характеристик. Об этом ограничении в материалах 1С никогда не видел, и потому вляпался...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот