Загадка с индексами
 

Впервые с таким столкнулся. Платформа при при переиндексации базы вдруг стала "вылетать". Приложение просто закрывается и все, причем стабильно на одном и том же справочнике, в котором от силы 50 элементов, но куча полей(фдажков) с признаком - сортировка. Причем, база много лет работает. Если же все индексные удалить, то база успешно индексируется и успешно работает. Сама база после свертки зимой небольшпя, меньше 2 гигов. Файловый вариант, работа в терминале. В обсуждаемый файл недавно добавлял поле, но пробовал, удалял, все равно вылетает. Ерунда какая то. Разве при переиндесации платформа сама не удаляет индексные файлы. И почему вообще ей вылетать )

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

хм.. что-то там смутно припоминается такая фича, что если реквизит неограниченной длины, то надо его сделать последним в списке реквизитов.
ну мало ли, к примеру в той же ТиС наименование ограничено, а полное наименование - нет, вдруг и у тебя индекс типа по полному наименованию.
но это так мне смутно припоминается, щас гуру подтянутся, вспомнят про эту фичу подробнее. Или не про эту.

*********************************************************
ps: И эта, у тебя платформа часом не sql? Не база, понятно, что база файловая, а именно сама платформа? А то многие ставят многие ломаную не глядя. Нет, я ни на что не намекаю, просто ну а вдруг..

Ну и естественно, неплохо бы для очистки совести глянуть, нет ли у тебя в индексируемых полях какого-нибудь мусора, типа неотображаемых символов ("кракозябров"). А то при попытке "[em]построить индекс по кракозябрам[/em]" 1С-ина бывает впадает в кому.
Просто глянуть. Любым приличным dbf-редактором.

реквизит неограниченной длины - это не из той оперы, это про загрузку в SQL базу. У меня нет там таких строк.
Там код, наименование, пара периодических реквизитов (расценка работ) и флажки N(1) с признаком [x] - сортировка
У меня же 2 вопроса:
1 - почему ваще вылетает
2 - почему при удалении cdx успешно инлексирует
Завтра специально поэкспериментирую. А движок SQL, но база файловая

(0) Попробуй переместить базу. Выгрузка/загрузка. Как определил, что на этом справочнике рушится? Возможно, что на следующей таблице.

индексирование диска с базой отключено?

(5)Может конечно и не на нем, его последний выводит платформа перед падением. Может и следующий. Надо посмотреть что там за ним. Просто он последний из того, что недавно менял.Копия кстати по моему без проблем индексируется, причем горячая копия, с сидящими в базе пользователями
(6)я не админ, там другие этим занимаются. в свойствах диска галочка стоит. Где служба настраивается не знаю, в 2008 SERVER она где то в другом месте вроде, но сервак не меняли

нет, с копией тоже фигня. Взял базу, не требующую индексации, скопировал, зашел, ничего в ней не делал, процесс срубил. Переиндексирую - вылетает, но не видно было на чес слетает

Тестирование физической целостности ничего не выдало

Итак, докладываю. Базу выгрузил. Загружаю, не загружается, вылетает. Стал смотреть какой последний по времени файл создался - SC16757.CDX. После него по словарю (1СV7.DD) SC14986. Это не мой подозреваемый, решил проверить иначе. Удалил все индексы, переиндексировал и опа, за SC16757.CDX идет SC3992.CDX, это как раз мой голубчик, в который недавно добавил реквизит. Захожу, убираю с нового реквизита сортировку, пытаюсь сохранить, база индексируется (так как недоиндексировалась) и 1с вылетает. Удаляю индексы, переиндексирую, убираю флаг сортировки с реквизита, запускаю, снимаю процесс 1c, индексирую и ВСЕ ИНДЕКСИРУЕТСЯ. все снова работает. Это числовое поле N(1) с признаком сортировки. Просто есть куча флажков, идентифицирующих различные операции. Возвращаю флажок сортировки, запускаю, процесс 1с срубаю, индексирую и.. НЕ ИНДЕКСИРУЕТСЯ.Вот такая интересная штука. Куда ж теперь дальше копать ?)

Поставил сортировку на мой реквизит, но убрал с другого, все работает. То есть получается, что косяк с числом индексируемых полей. В 1cv7.dd насчитал 63 или 64 индекса, то есть всего порядка 30 индексируемых полей. Размер индексного файла примерно 100 килобайт, сама таблица - 15 килобайт. При таких размерах я и не задумывался о целесообразности использования моих индексируемых полей с типом N(1), но они реально нужны, либо надо много переделывать, эмулируя предопределенные элементы справочника. Интересная штука получается, у задачи наступил технологический затык ?)

Вернул все сортировки, но сделал справочник одноуровневым (число уровней 4 досталось от типовой ПУБ, справочник "Техоперации", на это никакого внимания не обращал), ВСЕ РАБОТАЕТ. Число индексов у справочника уменьшилось вдвое. Такая вот загогулина )))

[quote=USSR;44586071]получается, что косяк с числом индексируемых полей. В 1cv7.dd насчитал 63 или 64 индекса, то есть всего порядка 30 индексируемых полей.[/quote] насколько я помню, в dbase ограничение на количество символов в индексном выражении (cdx- не больше 254 символа).
А вот на количество самих индексов ограничения не помню.. хотя, у 1С же не стандартный dbase, у нее [em]свой xbase[/em], те же memo-поля они реализовали по-другому.

(13)Индексные выражения все короткие ) Не знаю какие ограничений у 1с, но вот ситуация такова, как описал. Самая то странность, почему при удаленных индексных файлах все индексируется? Но в тоже время загрузка базы не выполнялась. В Фохпро по моему просто ограничение на длину строки - 255. С dbase я плотно не работал, foxpro то уже почти забыл. Да, мемо поля совсем по другому, засунули все в один бедный файл )

Кстати, года 2 назад был фокус с числом панелей интерфейса, вот не помню только количество, вроде 10. После добавления очередной панели были косяки, не помню точно, но вроде весь интерфейс испарился )

есть проблемы с общей длиной ключа - не надо делать чтобы ключ был больше ~160 символов - что-то типа такого...

.. и для реиндексации и построения индексов с нуля - используются разные алгоритмы

..и есть ограничение на количество индексов

цитриую мастеров:
"Индексация с нуля делается в рабочих файлах путем "алгоритма слияния" последовательных упорядоченных груп записей. Условно говоря !!!.
А ренидексация - это непосредственная работа с деревом индекса."

итого: работа с деревом - существенно более зтаратная - надо вставлять/удалять/сдвингать/раздвигать...

..при работе с деревом всякие расщепления/слияния страниц и прочие лабутены.. поэтому и пухнет и напарывается на ограничения и бряк!

Создал пустую конфигурацию, добавил в нее объединением мой справочник (естественно с заменой ссылочных полей на строковые), получил чистую базу с одним справочником. Больше вообще ничего. Для чистоты эксперимента - справочник без элементов. Поведение тоже самое, как только делаю справочник многоуровневым платформа слетает при аварийном индексировании. При удалении всех индексов - индексируется. Если убрать сортировку с последнего реквизита типа N(1) то все работает и при многоуровневом справочнике. Вот индексы из DD:
#----Indexes------
# Name |Descr |Unique|Indexed fields |DBName
I=IDD |of ID |0 |ID |IDD
I=PCODE |of PARENT and |0 |PARENTID,ISFOLDER,CODE(UPPER) |PCODE
I=PDESCR |of PARENT and |0 |PARENTID,ISFOLDER,DESCR(UPPER) |PDESCR
I=CODE |of CODE |0 |CODE(UPPER) |CODE
I=DESCR |of DESCR |0 |DESCR(UPPER) |DESCR
I=VI19 |VI19 |0 |SP19 |VI19
I=VIP19 |VIP19 |0 |PARENTID,ISFOLDER,SP19 |VIP19
I=VI20 |VI20 |0 |SP20 |VI20
I=VIP20 |VIP20 |0 |PARENTID,ISFOLDER,SP20 |VIP20
I=VI21 |VI21 |0 |SP21 |VI21
I=VIP21 |VIP21 |0 |PARENTID,ISFOLDER,SP21 |VIP21
I=VI22 |VI22 |0 |SP22 |VI22
I=VIP22 |VIP22 |0 |PARENTID,ISFOLDER,SP22 |VIP22
I=VI23 |VI23 |0 |SP23 |VI23
I=VIP23 |VIP23 |0 |PARENTID,ISFOLDER,SP23 |VIP23
I=VI25 |VI25 |0 |SP25 |VI25
I=VIP25 |VIP25 |0 |PARENTID,ISFOLDER,SP25 |VIP25
I=VI26 |VI26 |0 |SP26 |VI26
I=VIP26 |VIP26 |0 |PARENTID,ISFOLDER,SP26 |VIP26
I=VI27 |VI27 |0 |SP27 |VI27
I=VIP27 |VIP27 |0 |PARENTID,ISFOLDER,SP27 |VIP27
I=VI31 |VI31 |0 |SP31 |VI31
I=VIP31 |VIP31 |0 |PARENTID,ISFOLDER,SP31 |VIP31
I=VI35 |VI35 |0 |SP35 |VI35
I=VIP35 |VIP35 |0 |PARENTID,ISFOLDER,SP35 |VIP35
I=VI38 |VI38 |0 |SP38(UPPER=128) |VI38
I=VIP38 |VIP38 |0 |PARENTID,ISFOLDER,SP38(UPPER=128) |VIP38
I=VI41 |VI41 |0 |SP41 |VI41
I=VIP41 |VIP41 |0 |PARENTID,ISFOLDER,SP41 |VIP41
I=VI42 |VI42 |0 |SP42 |VI42
I=VIP42 |VIP42 |0 |PARENTID,ISFOLDER,SP42 |VIP42
I=VI43 |VI43 |0 |SP43 |VI43
I=VIP43 |VIP43 |0 |PARENTID,ISFOLDER,SP43 |VIP43
I=VI44 |VI44 |0 |SP44,DESCR(UPPER) |VI44
I=VIP44 |VIP44 |0 |PARENTID,ISFOLDER,SP44,DESCR(UPPER) |VIP44
I=VI45 |VI45 |0 |SP45 |VI45
I=VIP45 |VIP45 |0 |PARENTID,ISFOLDER,SP45 |VIP45
I=VI46 |VI46 |0 |SP46 |VI46
I=VIP46 |VIP46 |0 |PARENTID,ISFOLDER,SP46 |VIP46
I=VI47 |VI47 |0 |SP47 |VI47
I=VIP47 |VIP47 |0 |PARENTID,ISFOLDER,SP47 |VIP47
I=VI48 |VI48 |0 |SP48 |VI48
I=VIP48 |VIP48 |0 |PARENTID,ISFOLDER,SP48 |VIP48
I=VI49 |VI49 |0 |SP49 |VI49
I=VIP49 |VIP49 |0 |PARENTID,ISFOLDER,SP49 |VIP49
I=VI50 |VI50 |0 |SP50 |VI50
I=VIP50 |VIP50 |0 |PARENTID,ISFOLDER,SP50 |VIP50
I=VI51 |VI51 |0 |SP51 |VI51
I=VIP51 |VIP51 |0 |PARENTID,ISFOLDER,SP51 |VIP51
I=VI52 |VI52 |0 |SP52 |VI52
I=VIP52 |VIP52 |0 |PARENTID,ISFOLDER,SP52 |VIP52
I=VI53 |VI53 |0 |SP53 |VI53
I=VIP53 |VIP53 |0 |PARENTID,ISFOLDER,SP53 |VIP53
I=VI55 |VI55 |0 |SP55 |VI55
I=VIP55 |VIP55 |0 |PARENTID,ISFOLDER,SP55 |VIP55
I=VI56 |VI56 |0 |SP56 |VI56
I=VIP56 |VIP56 |0 |PARENTID,ISFOLDER,SP56 |VIP56
I=VI57 |VI57 |0 |SP57 |VI57
I=VIP57 |VIP57 |0 |PARENTID,ISFOLDER,SP57 |VIP57
I=VI60 |VI60 |0 |SP60 |VI60
I=VIP60 |VIP60 |0 |PARENTID,ISFOLDER,SP60 |VIP60
I=VI68 |VI68 |0 |SP68 |VI68
I=VIP68 |VIP68 |0 |PARENTID,ISFOLDER,SP68 |VIP68

SP68 - это безобидный флажок, портящий кровь ) При количестве уровней = 1 все составные индексы по ISFOLDER (признаку группы) не строятся. Я грешу только на общее количество индексов. На досуге уберу уровни и просто навтыкаю полей с сортировками, их тут около 30

Создал дополнительно 40 простых полей с сортировкой - вылетает, 35 - вылетает)

При 3- дополнительных полях ошибка уходит, всего индексов по моему 63. Видимо ограничение 64 ))

Короче лень считать, но по строкам в dd выходит, что при 61 индексах работает, при 62 уже нет ) Так что не увлекайтесь полями с сортировкой, даже в пустом справочнике ))

25-USSR >Спасибо за исследование, принял к сведению... - тоже наталкивался на проблему сортировки.

21-USSR > "Поведение тоже самое, как только делаю справочник многоуровневым платформа слетает при аварийном индексировании. "
- помниторь расход памяти
?

(27)Памяти дофига и какой расход памяти при индексации базы, состоящего из одного пустого справочника. То есть в базе вообще ничего нет. Ни метаданных, ни данных ))

видеопамяти, например )))