v7: Можно ли как-то свернуть SQL-базу 7.7 средствами SQL??? #587221

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

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

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

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

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

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

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

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

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

+1

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

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

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

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

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

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

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

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

Посмотри

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

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

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

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

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

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

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

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

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

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

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

я сворачивал базу 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с++, это все ускорится. У тебя что за автообрезалка?

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

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

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