Стоит задача свернуть SQL-базу 1с 7.7 (сильно переписанная ПУБ)  размером 15 гг, базе 11 лет. Идеальный вариант собрать все итоги на определенный момент и отрезать все что было до. Справочники проверить на вхождение в документы и те, которые никуда не войдут тоже отрезать.
Сисадмины с работы подсказывают мол сделать свертку средствами SQL, мало представляя структуры хранения данных в 1с, чем повергли в сомнения, реально ли можно как-то так сделать. По инету бегло пробежался нашел примерно вот такую статейку http://infostart.ru/public/94040/  , но это скорее оптимизация, чем свертка. Так вот вопрос в том, реально ли провернуть такую задачу? Не пойму одного: даже если есть такой способ, то каким образом SQL создаст объект куда поместит итоги по регистрам и счетам, как проведет отрезку документов?

Честно говоря, мусор за 11 лет тащить не комильфо. Сисадминов слушать - хуже чем уборщиц, потому что они уверены что в компьютерах шарят. 15 гигов и задача встала за 4 дня до НГ - беги срочно отсель.

(1) Чего человека пугаешь? Свертку написать за неделю можно, выходные длинные) Главное бонус себе неплохой не забыдь выбить)

ну почему же за 4 дня, задача вообще глобальная, например до следующего нг

Нет ребята, за неделю такой объем работ не поднять, минимум пару месяцев

Лучше свертку делать специальной обработкой в 1С. там и контроль получше.

Нахрена сворачивать SQL-ную базу???

На этой базе ещё лет 15 можно работать и не париться

(4) Да ну, правда чтоли? УПП в 150 гиг за неделю свернуть - нормуль, а семерину в 15 гиг нет?)

(7) +1

(6) Такой вариант ответа - за год сменяется номенклатура полностью 4 раза (одежка зима-весна-лето-осень). Зачем в справочнике 100 тыщ наименований неиспользуемой номенклатуры? Людям просто неудобно - достаточно оставить последний год про запас и все почикать.

(8) ТС готовиться к начальству идти, премию выбивать. не мешай ему заниматься автотренингом.  шоб в чём-то убедить требовательного начальника, нужно самому в это поверить! :)

(10)Поскольку это бухгалтерия, то лучше хранить3 года.

не вижу проблем (все зависит от квалификации)

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

далее удяляются все доки, кот не являются обектами аналитики
удаляются движения

проводятся доки (или генерируются записи регистров , проводки напрямую sql)

почисть аналитику (посмотреть в архивной копии, какая аналитика давно не использовалась )

чтоб с чуством с тактом с расстановкой - дня на 3 работы.


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

(12) Об уничтожении первички и исходной базы речь вроде не шла

(10) 100к наименований товара - не о чем, скидываем в папку Я и живем дальше.

Ребята, период - это навскидку, Сколько времени будут висеть задачи, где-то минимизировать объем чтобы не забивалась оп. память, в базе очень много всего дописано. Много Схем за эти годы.
Мне нужен ответ реально ли средствами SQL, а не 1совскими, а не то за сколько, времени все равно предостаточно.

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

Посмотри http://infostart.ru/public/14216/

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

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

(0) 15? Мы тут как-то 100 резали. По времени ушло примерно 36 часов. Запустили - ушли. Пришли, проверили, дальше запустили.

(16) Ну ты сам подумай - это ж 7.7, ПУБ, там и регистры и бухгалтерия, насколько я помню. Ты сможешь средствами скуля вытащить движения по бухгалтерии и средствами же скуля создать док по начальным остаткам по бухии и шоб он корректным был? Если сможешь - давай делай, скажешь потом, сколько на это времени убил.

(14)А бухам по взаиморасчётам каждый раз в старые базы лазить или первичку шерстить? Пока срок давности не истёк, лучше не резать.

сворачивал базу где договоров было под лям... штатная сворачивалка падала по памяти...

делал в несколько проходов, лишние договора убивал непосредствено в SQL

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

ТС - вопрос-то в чем? Создать документы ввода остатков не можешь? Или не хочется помечать документы на удаление долго и нудно?

+20. Обрезку делали так
1. Взяли какую-то стандартную обрезалку. Оптимизировали получение данных на прямые запросы).2
2. Документы, операции, и прочую лабуду за прошлые периоды удаляли прямыми запросами "delete * from _1sjourn where...".
3. После всех действий пересчитали итоги.

(0) пробуй штатной, если не упадет - сворачивай ей и не парься

(25) Если ссылочная целостность не интересует (а также периодика) - пуркуа па?

два дня на разработку сворачивалки, пол-дня на сворачивание. О чем трем-то?

(21) Особых поблем нет. Бухгалтерская подсистема давно и подробно расписана...

(0) я сворачивал базу 7.7 14 гигов средствамя SQL, потратил одни выходные...

насколько помню, последовательность была следующая:
1. сформирвоал документы остатков
2. удалил напрямую через SQL все движения (документы, БУ проводки, период. регистры)
3. сделал реиндексацию и обрезание средствами SQL
4. сделал ТиИ

нифига не понимаю, это подвиг, чтоль, "обрезть SQL-базу"?
у меня каждый месяц "автообрезалка" автоматом "отчикивает" очередной месяц от базы... оставляя 38 месяцев. При этом операторы работают себе в базе, другие задачки крутятся....

24) прочитай внимательно поставленный вопрос. Явно расписал, проблема не в том могу или нет. Средствами 1с могу, и всё сделаю, хоть перенести итоги и данные в другую базу чистую, хоть обрезать в существующую. И вопрос не во времени, во времени я неограничен, года точно хватит.
Вопрос в том, что спрашиваю есть ли возможность чисто средствами sql свернуть более быстро и грамотно, спрашиваю о возможном существовании тех приемов, которых пока незнаю.

27) штатной обработкой падает, забивается память и процесс 1с вырубается, добирая 2 до двух гигов. Точно так же как расписал 23й планирую делать в несколько подходов.

31) как именно делал средствами sql, расскажи подробнее?

нельзя

32) снова повторяю как и 24му, дело не в skl, а в том какими средствами. Могу написать сами сворачивалки на 1с++, это все ускорится. У тебя что за автообрезалка?

(35) хранимка на серваке которая запускается агентом по расписанию вестимо.

(35) напиши мне на мыло, я приду домой и попробую тебе даже скинуть пример обработки.

(35) можешь - напиши? в чем проблема-то?
(36) Не, обычная 1совская обработка, которая стртуется обычным 1совским шедулером, после завершения роботом всяких традиционных действий (днем он заявки с КПК принимает, вечером песчитывает партионку и выгружает кубики). Но внутри все на прямых запросах, да...