Привет!

такая тема, кто знает?

В центральной базе
"РегистрНакопления.ВзаиморасчетыСКонтрагентами"
_AccumRg7026
76 338     - Количество записей
14 448 KB  - всего под таблицу (reserved)
10 368 KB  - занято данными
2 880 KB  - индексы
1 200 KB  - свободно

в РИБ при создании начального образа
"РегистрНакопления.ВзаиморасчетыСКонтрагентами"
_AccumRg7807 (другой ИД таблицы, кстати)
51 025       - Количество записей
3 080 464 KB - всего под таблицу (reserved)
  385 120 KB - занято данными
       16 KB - индексы (не построены, ибо я прервал эту якуляцию)
2 695 328 KB - свободно

В какой-то момент при создании этого гиганта SQL исчерпывает и без того небольшое месть на дике.

Исходная БД: 16 Гигабайт в SQL таблицах, самая большая таблица - партии на 13 лимонов записей, индексы перестроены через ТиИ без ошибок.

Получающаяся почка РИБ: 50 Гиг незавершенки, по количеству записей в завершенных таблицах ровно, но занимаемое место растет на порядок, построение не выходит.

"Не хватает памяти" (С)
bcdedit  /Set IncreaseUserVa 9216 не помогает.

УТ 10.3
Платформы 8.2 последняя, 8.3.5.какая-то..
результат один и тот же.
Когда-то (пару лет как) базу сворачивали стандартной обработкой.

Спасибо.

(0) посмотреть, нет ли логической ошибки в регистре.

Создай начальный образ файловый, потом загрузи.

А в дочернем узле какое смещение дат? у базы СКЛ?

(0) Так вопрос в чем? Как создать почку? Есть альтернативный способ
Или хочешь докопаться до первопричины и обязательно выгрузить типовыми средствами?

(1) Что с чем сравнивать? Таких таблиц - на каждый регистр почитай кратное увеличение размера.
(2) С этого я и начинал. Получал ошибку "не хватает памяти" и потом уже нашел сервак SQL и залил её туда, чтобы докопаться. (3) 2000 и там и там
(4) что за способ?

70 и 50 тыщ записей - это гигантские таблицы?

Кстати, пересчет итогов делается вообще? При использовании разделителей - это !обязательно!

(6) В центральной базе объемы адекватные.
Пересчет итогов в файловом варианте вылетает с ошибкой памяти. В SQL сейчас запустить не могу, если на рабочем серваке будет отожрано все место, люди пострадают.

Есть кое-что интересное:
4012-07-18 12:08:22.000
вот такой период в регистре в почке
4011-12-31 23:59:59.000
и в центральной ИБ тоже такой же чудесный период.
Поэтому, отталкиваясь от сегодняшней даты резервируется место для итогов. Так что-ли?
Но как же это сделали ...

(5) Книга знаний: Альтернативное создание начального образа в УРБД

Смещение дат -2000, но вот возможно ли это ...

(9) Стоит галка смещение даты

(12) Я читаю это через SQL прямые запросы к базе. Галка в сервисе в клиенте к 1С?

нет, 4012 - это нормально. Короче, сделай в файловой, потом загрузит в СКЛ

(14) Она изначально файловая. Я в файловой ничего не могу сделать - ибо ошибка "не хватает памяти". Я потому в SQL и залил, что она дает себя посмотреть.

(0) создай начальный образ из копии, получишь те же 16Гиг и быстрее в тыщу раз

(16) по методу (10)? Штатно не создается.

(17) да

(18) А штатно никак? А разобраться?
Мне с ночи идеи в голову лезут тяжело ...

(19+) И "быстрее" - это не так. Заказ я получил на свертку базы из-за тормозов.

Что ты хочешь? 1c8 рассчитана на ларьки, а у тебя уже уже объем (16GB) небольшой фирмы :) А если серьезно, то выгрузка идет в формате XML, а это значит, что объем такого файла будет очень большим.
  Ты не расстраивайся. Даже если ты выгрузишь файл обмена загрузить ты его не сможешь.

Почкование надо делать под 64-битной ОС. У меня штатными средствами на 32-битной получалось только на базах меньше 1 GB

64 битная ОС не поможет.

(22) Все 64-битное с кучей памяти, только дисковая подсистема пока не готова 200 Гиг выделить для образа 16-ти Гиговой базы.
(21) Твое бы мнение да на собрании директоров 1С :)))
Вообще, РИБ это не КД и начальный образ заливается не из отдельного файла сериализованных данных. Потом - да, но там и размеры фалов децельные.

2(24) 1С еще не выходила на IPO и поэтому и никакого собрания директоров нет...

(25) Думаешь Он один скучает в своем кабинете?

нет, он может вызывать других спрашивать их мнения, а потом говорить им: да манал я ваше мнение в рот, никакие вы не держатели акций, идите вкалывать за ваши гроши назад

С SQL ру:
"Таже лажа и таже система... Shrink непомогает... нашол выход следующий экспорт таблиц в чистую бд затем их удаление и обратно импорт после этого unused ушол что позволило потом шринком обрезать файл"
(имеется ввиду галактика)
но видимо нет принципиальной разницы

Прочитал "в РИБ при создании начального образа... _AccumRg7807 (другой ИД таблицы, кстати)..." - далее не читал - нет смысла. Это уже не проблемы РИБ. Это проблемы на уровне конфигураций.

(29) Это не баг, это все в порядке. Не поверишь.

Ты прав,  я "Не верю!"(с)