| 0
- 05.06.2013 - 09:22
|
Прошу помощи у 1с сообщества. Суть вопроса база много переписанная УТ 10,3. В файловом варианте при выгрузке натолкнулись на ошибку: Ошибка СУБД: Превышен максимально допустимый размер внутреннего файла 'G:\base/1Cv8.1CD' по причине: Превышен максимально допустимый размер внутреннего файла 'G:\base/1Cv8.1CD' Начали копать. Средствами Tool_1CD.exe выяснили что 99% занимает индексная таблицы нашего РС (переодичный не подчиненный регистратору) причем сами данные этого регистра занимают 70мб, а Индексный файл >4 гб. Не могу понять из-за чего это получилось и как оптимизировать... Тестирование исправление (переиндексация, сжатие, реструктуризация) не уменьшает таблицу эту... Сам РС таков (периодичность- в пределах секунды, режим записи независимый) Измерения: Изм1 - тип перечисление, ведущее-ложь, основной отбор-истина, не индексировать; Изм2 - тип Строка 100, ведущее-ложь, основной отбор-истина, не индексировать; Изм3 - тип Строка 200, ведущее-ложь, основной отбор-истина, не индексировать; Изм4 - тип Строка 100, ведущее-ложь, основной отбор-истина, не индексировать; Ресурсы: Рес1 - тип Строка 100, не индексировать; Рес2 - тип Строка 100, не индексировать; Рес3 - тип Булево, не индексировать; Рес4 - тип Строка 100, не индексировать; Рес5 - тип Дата+Время, не индексировать; Реквизиты Коментарий - Строка неограниченной длины. Думали все из-за Коментария, но сколько не читаю о том как индексируются таблицы нигде подтверждения этому не нашел. Подскажите, что можно еще сделать чтобы таблица индексов была меньше кроме удаления записей этого регистра? Если еще нужно что-то прояснить пишите. Заранее спасибо за помощь...     | | |
| 1
- 05.06.2013 - 09:58
| (0) Как мне кажется, нужно просто правильно определить индексы по измерениям. У тебя сейчас РС не индексирует измерения, соответственно индексная таблица и пухнет. | | |
| 2
- 05.06.2013 - 10:03
| в данном случае в таблице индексов должны присутствовать индексы по измерениям и периоду, как я понимаю | | |
| 3
- 05.06.2013 - 10:06
| (2) Естественно, для 2,3,4 измерения. Для первого я смысла не вижу. | | |
| 4
- 05.06.2013 - 10:08
| ну да пишут что таблица индексируется в нашем случае как период + Изм1+изм2+изм3+изм4.... Если на каком то измерении поставить индексировать то просто оно на 1 место сдвинется по идее. Но откуда блин 4гб О_о если таблица данных 70мб... Странно как то это все... | | |
| 5
- 05.06.2013 - 10:11
|
строки в 100, 200 символов индексировать? я понимаю ещё в 10-20 | | |
| 6
- 05.06.2013 - 10:12
| (4) Ничего тут странного нет. | | |
| 7
- 05.06.2013 - 10:22
| Немного не понимаю как вы предлагаете установить признаки индексации? На одном из измерении (самом точно характеризующем запись...Допустим это будет Изм2)? Тогда индекс разве будет Изм2+Период? или Изм2+Период+Изм1+Изм3+Изм4? я просто сколько читал понял что таким образом произойдет... | | |
| 8
- 05.06.2013 - 10:33
| ниче себе конфа! строки в справочник вынести не ? | | |
| 9
- 05.06.2013 - 10:52
| 8-Jimbo >На это были свои причины и содержимое этого регистра с данным набором полей и измерений нужно (возможно есть вариант убрать поле неограниченной длинны в комментарии, если дело именно в нем, в чем я сильно сомневаюсь и никаких подтверждений не найдено этому). | | |
| 10
- 05.06.2013 - 10:53
| 2(8) +1 | | |
| 11
- 05.06.2013 - 11:25
|
Уникальность записей Система обеспечивает контроль уникальности записей, хранящихся в регистре сведений. Таким образом, в регистре сведений не может находиться двух одинаковых записей. Одинаковыми считаются записи, у которых совпадает ключ записи. Ключ записи формируется системой автоматически, на основании значений, содержащихся в полях записи, и зависит от вида регистра сведений. В общем случае в формировании ключа записи будут участвовать значения регистратора, периода и значения измерений. Таким образом, например, в непериодическом регистре сведений ЦеныКомпании с независимым режимом записи не может существовать двух записей о розничной цене конфет ассорти. Точно так же, как в периодическом регистре сведений ЦеныКомпании, подчиненном регистратору, не может существовать двух записей о розничной цене конфет ассорти, внесенных одной и той же датой, одним и тем же документом ИзменениеЦенКомпании. http://v8.1c.ru/overview/InformationReg.htm | | |
| 12
- 05.06.2013 - 11:32
| Цитата:
| | |
| 13
- 05.06.2013 - 11:33
| 12-bma1 > регистратор один и тот же? и как это? и зачем? | | |
| 14
- 05.06.2013 - 11:43
| 2(13) регистратор тот же, а периоды разные (а если периодичность до секунды - то и в пределах одних суток). В принципе мне надо было переделать документ установки цен так, чтоб иногда в нем было две даты - на одну дату цена устанавливалась новая, а на вторую - возвращалась прежняя. | | |
| 15
- 05.06.2013 - 11:48
| Погодите. или я че-то не понимаю или не о том речь уже. При чем тут Уникальность? Вопрос у меня почему таблица данных регистра занимает 70 мб а его индексов 4гб? И что может так адски влиять на размер таблицы индексов в моем случае? | | |
| 16
- 05.06.2013 - 11:49
| 14-bma1 > извращенец ))) | | |
| 17
- 05.06.2013 - 12:29
| попробуй на копии одному из измерений установить длину в 1000 символов например. увидишь. | | |
| 18
- 05.06.2013 - 13:01
| Цитата:
| | |
| 19
- 05.06.2013 - 13:01
| Цитата:
| | |
| 20
- 05.06.2013 - 13:43
|
19-bma1 > фиксированная - максимальная длина до 100, далее переменная - до 536. файловую смотрю 8.2.18.61 автор. ТИИ полное делал? | | |
| 21
- 05.06.2013 - 13:45
| хотя что я глупые вопросы задаю... | | |
| 22
- 05.06.2013 - 13:56
|
20-Зелёный тролль > + нагнал я на длину строковых измерений. то есть немножко по другому сохранить не даёт. тут при построении индекса влияет суммарная длина всех измерений + периодичность и видимо регистратор. | | |
| 23
- 05.06.2013 - 13:58
| предельная суммарная длина для только строковых измерений в районе 640 символов. | | |
| 24
- 05.06.2013 - 14:15
| неверная архитектура - 4 измерения никогда шибко быстро то и так не работали, а тут строки еще. Переводите на SQL - проживет чуть-чуть еще ваша конфа | | |
| 25
- 05.06.2013 - 14:41
| Несколько тестов на копии. Уменьшил размер строки одного из измерений с 100 до 80. Выигрыша в размере после Сжатия таблиц не было. Я так думаю из-за того что Строки переменной длины и просто не было значений больше 80. А вот когда уменьшил все измерения 50 тогда база после ТИИ сжалась до 1.5Гб... Не могу все равно понять почему так АДСКИ влияет на размер длина измерений... | | |
| 26
- 05.06.2013 - 14:44
| 24-Jimbo > в СКЮЭЛЕ все вообще отлично. проблем с этим регистром нет абсолютно. А вот именно на файловой такая ерунда имеет место быть. И к сожалению sql в данном варианте не выход. Надо думать что-то с оптимизацией этих данных... | | |
| 27
- 05.06.2013 - 16:47
|
SQL видимо не Express? а то и там были бы проблемы. в SQL проблем нет в каком плане: не ругается или размер таблиц меньше? | | |
| 28
- 05.06.2013 - 18:09
|
(3,6) Ух какой вымахал!9-MiniMuk23 > ;) 7-MiniMuk23 > Не было ни одной причины. Все твои измерения должны быть справочниками. Если строка может повторять свое содержимое - значит индекс имеет смысл, и имеет смысл сделать справочник со значением. Если строка не повторяется - индексирование ее не имеет значения и помещать ее в измерения нет смысла. | | |
| 29
- 05.06.2013 - 18:10
|
Правильно так: Цитата:
| | |
| 30
- 06.06.2013 - 09:34
|
27-Зелёный тролль > смотрели утилитами сколько занимает эта таблица в sql - очень мало. А вот в Файловом неадекватно много. То что в sql ошибки нет это ясное дело :) 29-Reaper >Справочник вести не хотим, тк суть этого регистра информативная и должна сохраняться после сверток очисток и прочих подобных операций. База глюкнула ссылки поломались а строки нет. В общем суть вашего предложения понял и учел на будущее. :) Понимаем, что наш способ не оптимален и все такое, но осознано пошли на такой вариант и не предвидели подобных проблем. В общем спасибо всем за ответы и помощь. Вчерашние тесты на копии привели меня к интересным фактам которые могут помочь в дальнейшем кому-нибудь... Значит так неоднократные попытки изменить размер длины строки у измерений регистра показал следующие вещи. Если мы Делаем строчные измерения Изм1=100,Изм2=200,Изм3=100 Размер базы 5,5Гб Изм1=100,Изм2=200,Изм3=40 Размер базы 5,5Гб Изм1=60, Изм2=200,Изм3=100 Размер базы 5,5Гб Изм1=60 ,Изм2=200,Изм3=80 Размер базы 5,5Гб Изм1=60, Изм2=200,Изм3=70 Размер базы 5,5Гб Изм1=60, Изм2=200,Изм3=60 Размер базы 1,8Гб Изм1=60, Изм2=200,Изм3=70 Размер базы 1,8Гб Изм1=100,Изм2=160,Изм3=60 Размер базы 1,8Гб В общем суть если уменьшить в любом сочетании размер строк на 80- происходит снижение размера индексной таблицы до адекватного. При этом мы проверяли что фактически данные никакие на пострадают т.к размеры были выбранны с запасом. Поэтому размер индексной таблицы меняется нелинейно, а резким скачком при достижение некого порогового значения... В общем такая ерунда. Т.к данной информации я не находил думаю может эти наблюдения помогут кому-нибудь. | | |
| 31
- 06.06.2013 - 10:24
| Цитата:
| | |
| 32
- 06.06.2013 - 10:39
| 31-bma1 >К сожелению если перенести в ресурсы информацию о измерениях мы не добьемся уникальности записей :( и не обеспечим то что надо. | | |
| 33
- 06.06.2013 - 10:58
| 2(32) Уникальность может быть достигнута массой иных способов. Менее затратных и более гибких. | | |
| 34
- 06.06.2013 - 13:09
| Зелёный тролль Вам отдельное спасибо, т.к. именно ваши советы помогли понять суть проблемы и разобраться с ней. | |
Интернет-форум Краснодарского края и Краснодара |
