Есть справочник на семерке номенклатуры. 300 тысяч элементов.
База досталось в наследство.
Итого в нем порядка 25 реквизитов, 6 из которых стоят галки отбор и сортировка.
Три имеют текстовые реквизиты 250 длиной.

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

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

Какие варианты есть изменить справочник чтобы это заняло 2-3 часа от силы.

Есть и поболя справочники в 700 тысяч элементов, но они простые. и реквизитов немного. За полчаса реконструируются. А тут прямо засада какая то.

отборы и сортировка по текстовым реквизитам в 250 длиной? кто-то явно хотел получить гвоздь в череп

на СКЛ это делается быстро...

скл нет и база файловая сетевая

(2) Маня давно нарывается :-)

(4) Тогда мучайся. Ссылку на ёпрста давать не буду.

(2) нет не по ним но по другим. например в базе 4 артикула по 21 символы - все с отборами и сортировками. хотя реально используется из них один.

(3)+1. Согласен. Напрямую максимум 15-ть минут.

(0) Периодические реквизиты есть?

Убрать отборы и сортировку. Изменить. Восстановить отборы и сортировку. Не?

(5) Ааа, это Маня! Тогда понял, на провокации не реагирую.:)

ладо попробую что нить придумать. может приехать к кому то в офис, на скл загрузить базе изменить и обратно.

(9) 5 цен, но кажется по ним пусто. периодические не хранятся все равно в таблице справочника.

(12) это по-любому будет быстрее 15-ти часов...

(10) любое изменение любой опции в реквизитах - реконструкция. уходит в аут.

Какой-нить редактор ДБФ тоже долго делает?

такое впечатление, что Женя 7.7 только сегодня открыл ;)...

блин чо я тормозу у нас 2008 куплен. скачаю 2000 поставлю - изменю и удалю.

(16) щас он тебе там наредактирует...

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

Есть еще 1 выход - завести подчиненный номенклатуре справочник доп. реквизиты. Таблицы меньше пухнуть будут.

(17) так он всю жизнь на 9.5 сидел.

там половина реквизитов вообще нафиг не нужна.

и отборы тоже все нафиг кроме одного

(22) ты посмотри внимательно, может и справочник нафиг не нужен? тогда будет значительно проще...

хех, чувствуется приближение пятницы )

(20) на третий день вынужденного простоя фирмы его убъют наемные киллеры

(0)у нас он и на 18тысячах тормозил с жутью..
не знаю способов, кроме посоветованных
одно успокаивает: все реквизиты - по-уму, используются во всех уголках учета
мусор в реквизитах.. что за прог был? за ним кто-нибудь присматривал? Еще кто-нибудь заботился о производительности?
в одно рыльце кроме каки в бд не будет ничего

(27) мне почему-то кажется, что это те мебельщики, где Женя начинал карьеру, попросили за долю малую подправить кое-что в конфигурации ;)...

Размер базы огласи...

(28) Может ему 146% обещали? От доли фирмы? Если меньше, то он не согласится же - мало..

(0) Не может такого быть что бы реструктуризация справочника даже на 300 000 элементов шла 15 часов .
По крайней мере при локальном запуске . Скока же тогда общая реиндексация идет  , двое суток что ли ?

(0) в общем переводи все на снеговика :)

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

сколько весит самый

Попробую вспомнить:
1. Скопируй MD и на копии поудаляй ненужные реквизиты/отборы.
2. Вручную удали индексные файлы и объедини MD-шники.

большой файл?

сам справочник 250 метров, сдх по нему 150. таблица констант 140.
всего то навсего. у меня справочник характеристик к номенклатуре 700 тысяч. и тот раотает на ура и рекоснтрукция 30 минут.

(36) самыйбольшой - один из регистров. файл итогов 130 метров, файл его движений 700 метров.

(31) на дбф, запросто...

(35) не уверен что это поможет) сразу пойдет переиндексация а потом только реконструкция. один фиг будет лопатить. вопрос снят в принципе - итак понятно что на скуль загнать.

(40) реструктуризация при наличии цдх и при его отсутствии происходит по-разному

(40) Ключевой момент - удаление индексов.

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

(41) ну прмя сейчас попробую

(0) Делать в транзакции. Разделить на куски по 500 элементов, например, и делать в блоках
НачатьТранзакцию()
..................
ЗафиксироватьТранзакцию()

(39) Если говорить только о справочнике без пересчета итогов по счетам или регистрам (то есть например без завязки на субконото) то удаление или изменение реквизита пусть и длинной 250 символов пускай с отбором или сортировкой , максимум 10 мин на приличной машине .
Если нужен пересчет итогов то дело другой

Сделал) удалил сдх) как я и говорил он пошел в переидексацию сразу) а не реконструкцию

(45) Насколько понятно ТС не заполнить реквизит справочника нужно , а реструктуризацию провести

(46) самое смешное что при изменении регистров все реконструируется за полчаса)

проблема именно в большом количестве реквизитов с отборами и строковыми с большим количеством символов. только так это объяснить.

(47)
Удалил индексы, что делал дальше?  Подробно.

и этот баян без Манька порвали в своё время...

(50) Ради прикола сейчас в тестовой базе dbf , изменил в спец справочнике (расширенный лог) длину поля с 200 символов на 150 (всего 18 реквизитов) , и включил отбор и сортировку , 400 000 элементов . 2 минуты реструктуризация , 3 минуты реиндексация

каждое строкове поле само по себе строит индекс на всю его длину.
4 реквизита с отборами по 21 символу...

предлагаю Ёпрсту сделать для мани за 10 тыс ;-) - халявные деньги...

(51) изменил справочник. нажал обновление. база сразу пошла переиндексировать.

(53) на самом деле, проблема имеет место быть. на файловой лечится согласно хитрого метода с удалением цдх

В принципе, можно (не трогая периодические реквизиты), провернуть вот такой финт:
1) Снимается копия базы (назовём её №1).
2) В ней 15 часов проводится реструктуризация (в рабочей базе в это время появляются новые элементы и изменяются старые).
3) В рабочей базе останавливается работа (все выгоняются).
4) Таблица SC справочника из рабочей базы копируется отдельно (№2), а в самой рабочей базе удаляется.
5) Проводится реструктуризация пустого справочника в рабочей базе.
6) Справочник из копии №1 копируется в рабочую базу поверх пустого.
7) Сравниваются таблицы SC справочников в рабочей базе и №2, новые записи из №2 (которых нет в рабочей) дописываются в таблицу в рабочей базе, все различия в старых записях также отражаются в таблице рабочей базы (на это должно хватить трёх часов).
8) Проводится реиндексация справочника в рабочей базе.
9) Продолжается работа пользователей в рабочей базе.

А если ещё и на 15 часов запретить менять справочник, то можно вообще обойтись без п. 7.

(56) Изменить нужно на копии в пустой базе. Потом объединить МД.

о еп!! эти все реквизиты еще и стоят для групп.....ааааа

(59) и что это даст? логически.

конфигуратор не лочит cdx/dbf файлы (пока не запустишь сохранение конфы)

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

(62) ну правильно. поэтому при алейшем отсутствии сдх он сразу кинется индексировать и ньюструткур загонять изменения.

Убрать базу с Целерона предлагали?

(61) Попробуй.
У меня когда-то была подобная проблема. Я помню, что нашел простое решение, но не помню подробностей. Прошло много лет с тех пор...

(63) нифига Ваня. затрагиваются тока файлы которые менял. они начинают в папку ньюструктур реконструироваться. по окончании нажатии кнопки принять из эой папки заменяют рабочие.

на копии: удали цдх, сними все отборы/сортировки, попробуй сохранить

(63) Угу , и если не завязано на регистры или субконто счетов делается быстро , минуты , ну десятки минут , если действительно реквизитов много и по многим отбор и сортировка стоит (особенно если десятки символов длинна реквизита) , лвиную долю времени занимает реиндекс (на DBF) . 15 не реально

(67) тебе говорят про один объект метаданных - конкретный справочник

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

(68) вообще то я на копии все и делаю) при удалении ндексов, изменении в конфигураторе чего надо изменить и сохранении идет ПЕРЕИНДЕКСАЦИЯ а потом только реконструкция. народ епт - уже пятый раз пишу одно и тоже.

Лет 7 не открывал я конфигуратор. Ностальгия накатила...

(72) а я тебе пятый раз пишу - перед сохранением убей все отборы/сортировки, и, по возможности, уменьши длину текстовых реквизитов

не будет он реконструировать пока не будет индексов.

(74) сейчас попробую

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

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

ну что досталось в наследство....) ничего страшного) но да - ностальгия еще та.

не, емнип, всё-таки, как в (68) сказал

ща. пока индексируется еще.

вот то что эти реквизиты на группах еще были (свойство) я тока ща увидел. это реально пипец

(82) думаешь, от этого ему так худо? это всё отборы/сортировки

Пошло!!! намного быстро!!!!! ура. по ньюструктур наблюдаю. уже 40 метров справочника отработалось. ! супер! спасибо братья!
Ща только когда назад буду ставить чтобы не ушло опять в аут) правда всего по 1 реквизиту

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

Прямым вмешательством можно произвести какие нужно изменения в любой таблице, аналогично и в словаре
Думаю что это займет несколько минут при условии что руки не из ЖПО

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

Кстати это проблема в 7.7 актуальна и для SQL-версии - реструктуризация таблиц выполняется не запросом а перебором - времени тоже занимает некисло.

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

)87)
Если сделать переиндексацию любой таблицы то все очень быстро.

Для sql если расписать более подробней то так :
Если в таблицу добавляеться ( и удаляется тоже самое ) новый реквизит то при смене
конфигурации  
1.Открывается транзакция
2.создается точно такая же таблица с окончанием New
3.построчно перегоняется все в таблицу New при этом все атрибуты (в том числе и новые ) всегда заполняются так как нет ни NULL  ни default
При этом после каждой единичной записи (insert) перестаиваются и индексы и все это идет еще и в журнал транзакций.
Если удалось перегнать всю таблицу то преж таблица удаляеся
а таблица с NEW переименовывается.
4.Фиксируется транзакция
Такой алгоритм и его неизменность по моему единственная причина почему не сделали внешние ключи на документах.

(88) DBF редактором тоже можно что-то добавить или внешним досутпом, запросом - заполнить

(86) а если прямым запросом удалять записи - индексный файл автоматом подстроится? или надо переиндексироваться?