Имеется база на 1с8, sql-трехзвенка, релиз 13. Релиз, на всякий случай уточню, менять совсем не вариант. В базе есть документ, на данный момент документов этого вида порядка 4 миллионов.

Понадобилось добавить этому документу реквизит. При добавлении прямо в лоб впечатались очень досадные грабли. При попытке сохранения в БД измененной конфигурации, 1С начинает что-то нудно и долго считать. Процесс аппликейшна во время этой черной мессы мило пухнет, распухая для критичных (для 8.0, со слов самой 1С) полутора гигов. После чего вся эта красота валится с предсмертным криком "Размер выборки превысил...". К этому моменту успевает обработаться 2.9 миллиона документов, что, разумеется, не радует. Резать базу - тоже, как ни печально, не вариант.

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

Вопросы:
- достаточно ли будет провести аналогичную описанной процедуру с таблицами ТЧ, чтобы получить на выходе исходные, но уже реструктуризированные документы
- если нет - какие еще таблицы в БД (типы объектов) могут быть связаны с процессом изменения таблицы документа. Профайлер пытать не хочется, он в случае 1с-а слишком много лишнего знает
- Назначение в таблицах timestamp поля _Version. То есть, умом я понимаю, что оно в данном случае не существенно, но шут его знает, что на него завязано в 1С-овской реализации.
- Профессионалам - может, существует какой-нибудь другой, простой и приятный выход из моей ситуации

Заранее спасибо

(0) Щас глянем, что там ресткуктуризируется...
P.S. Реально новые реквизиты в рег. сведений выносить?

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

(2) Почему еле шевелится?

(3) Потому что общий размер базы перевалил за 320 гигов при 480 средневзятых активных пользователях. И потому что во всей базе используется, по сути, три вида документов и два бухгалтерских регистра. Но это моя местечковая лирика, все-таки хотелось бы услышать, как проблему то решить ))

(0) Первичный анализ показал - надо экспортировать и табличные части

А если пойти таким путем:
сделать базу из пустого cf, добавить реквизит, добавить колонку (с получившимся именем) в таблицу рабочей базы, заменить в рабочей таблицу config и configsave.

(6) Точно не вариант - при создании новой базы все идентификаторы таблиц/полей слетают в нирану, то бишь - задуманное 1С-ом. Они у них, видите ли, генерятся онлайн. Расхождения, по крайней мере в моем случае, превышают все мыслимые - укокошусь исправлять ))

(7) Нифига не слетает

(8) Стучись в аську

Даже движения остаются

Только ТЧ удаляются

1С 8.1.10.50

(7) Сделать копию базы средством SQL, сделать truncate этой большой таблицы, добавить реквизит. Тогда ничего не слетит.

(13) Кроме config и configsave понадобится еще params (может и DBSchema ? тут точно не знаю, но на копии попробовал всё это скопировать - прокатило)

Короче:
Экспорт таблицы документа и таблиц ТЧ в другую базу SQL (можно в туже базу, в другие таблицы),
Truncate TABLE  таблицы документа и таблиц ТЧ, натягивание реквизита с датой в Пофигураторе, обновление конфы, заход в SQL, развешение на новую колонку Allows NULLS, импорт из резервных таблиц, UPDATE основной таблицы, новой колонки нулевой датой, запрещение Allows NULLS на новую колонку. Вроде все, счаст еще откатаю..