Задача:
Свернуть базу за ночь (часов за 10)
Проблемы:
1. Пометка на удаление документов (с переносом ТА на начало базы) ~ 4 часа
2. Удаление помеченных документов 2,7 млн ~ уже больше 8-ми часов идет
Есть у кого готовые нароботки?
--
Видел статью Шемякина для dbf баз, может есть посвежее наработки на скульных запросах? Есть 1с++
ЗЫ Сворачивать не сегодня, а вообще )

конфига какая?

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

переделанная ТиС, без бух. итогов

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

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

пометка на удаление через
update _1sjourn set ismark = 1 where набор условий
а уже потом
delete from dt/dh
возможно и уложишься в 10 часов

а создание документа ввод остатков сколько занимает?
и сворачивать на какую дату будешь?

(4) вот и спрашиваю, есть у кого опыт и наработки

(6) забыл регистры и переодику

(6) с урбд не взлелит. вообще здесь самое узкое место урбд. Сюда Майка надо. он в этом гуру

(7) обычно 10-20 минут, выгрузить итоги и скинуть в документ

(9) регистры и периодика пропадает в момент пометки на удаление (= распроведение документа)

(10) а в чем проблемы с урбд? ни разу в семерке не сталкивался с рбд

(7) еще не тестировал )
надо с размерами после свертки определиться, либо оставлю 2008-й, либо только 2009-й

40 гигов порезать стандартными средствами за 10 часов? о_О реально?

(13) весь этот объем помеченных документов и справочника партий пойдет обменом. а еще после свертки (если допустим на начало года) - нужно перепроводить документы, а это еще один объем для полета в РБД. вообщем шило.

(15) Стандартными, да при наличии урбд - нет

(12) я про (6) говорил, вряд ли там триггеры настроены )

1. отрубаю урбд
2. режу
3. настраиваю новые периферийки

(18) а я чет не вгляделся. я думал он уже таблицы чистит

(19) вот это вариант :)

Это элементарно, Ватсон©!
Во-первых, на инфостарте кастратор от Вадимко лежит.
во-вторых, можешь сам - фиксируй регистры, удаляй движения и итоги до фиксации, ищи ссылки на документы до фиксации, если ссылок не нашел - удаляй.

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

а вот и тяжелая артиллерия (22) подтянулась

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

я дважды резал базу прямыми запросами, но без рбд...

(15) А какая разница, за сколько часов? Запустил, и пусть сворачивает себе. Это же не мешает работать :-)

(22) Вроде на инфостарте видел, но на прямых ли он запросах? или вообще для дбф

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

USE work
Go
CREATE TABLE ##ID
(IDDOC char(9) primary key clustered)
Go
INSERT INTO ##ID
SELECT DISTINCT IDDOC
FROM _1SJOURN
WHERE (DATE_TIME_IDDOC < '20060101')
Go
BEGIN TRANSACTION
DECLARE Mycur cursor for
SELECT sysobjects.name,syscolumns.name
FROM syscolumns INNER JOIN
sysobjects ON syscolumns.id = sysobjects.id
WHERE (syscolumns.name = N'iddoc') OR
(syscolumns.name = N'docid')
OPEN MyCur
DECLARE @TableName varchar(20)
DECLARE @ColName varchar(20)
FETCH NEXT FROM MyCur INTO @TableName, @ColName
WHILE @@FETCH_STATUS = 0
BEGIN
EXEC ('Delete from '+@TableName+' with (tablock) where '+@ColName+' IN (Select IDDOC FROM ##ID)')
FETCH NEXT FROM MyCur INTO @TableName, @ColName
END
CLOSE MyCur
DEALLOCATE MyCur
COMMIT TRANSACTION

(27) У Вадимко  запросы - прямые:-)
А в чем у тебя проблема-то? У тебя ж тоже руки нормально растут...
Если что - стучись в ваську :-)

Автор, дай мыло я тебе вышлю статью по свертке базы средствами СКЛ

(29) спасибо
это джорнал + дт + дн грохают? Или ра тоже?
т.е. без регистров и периодики?

движения тоже естетсвенно, после урезание надо выгрузит бд и загрузить с 20 гб у меня 200 мб стало

(31) krda(немяю)ramble.ru

(29) ограничений на период не заметил

rambler.ru

FROM _1SJOURN
WHERE (DATE_TIME_IDDOC < '20060101')

после обеда подниму тему

отправил

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

(36) глянь в почту, отправил пример, может чем поможет...

(33) Анахуа, собснно, выгружать-загружать? Шринкни базу. Ну, переиндексируйся еще...

(42) собсно для тестирования, точно щас не помню но один из шагов был.

(19)
>>3. настраиваю новые периферийки
- если удаление прямыми запросами, то надо бы не забыть о регистрации изменений
- а если есть миграция "Только место создания" как получить эти объекты для прф в центре?

имхо работать только с центром не получится

(44) Если регистрировать изменения, то загрузка обмена завесит периферийку очень надолго. А вообще, надо смотреть по миграции..
я вообще периферийки клонированием размножаю :-) обленился нафиг...

(0) я сворачиваю базу Торговли с урбд так:
1) создаю вводы остатков
2) делаю непроведенными доки за прошлый год
3) удаляю непроведенные доки за прошлый год в течение недели
(удалять миллион доков за ночь не успевает)

Инструкция по урезанию базы 1С “Торговля”

1.    Делаем полную копию базы торговли
2.    Обработкой переноса делаем “выгрузить все” и “выгрузить справочник цен” на дату 01.01.2006
3.    Удаляем в копии все документы по 01.01.2006
4.    Заходим в конфигуратор и делаем пересчет служебных данных и пересчет итогов , очищать ссылки, удалять объекты.
5.    Делаем выгрузку базы
6.    Делаем загрузку базы
7.    Обработкой удаляем справочник цен , удаляем справочник партий.
8.    Монопольно удаляем помеченные объекты
9.    В конфигураторе создаем новую основную последовательность.
10.    Обработкой загружаем “справочник цен”, “загрузить все”
11.    Обработкой правим возвраты.
12.    Создаем документ инвентаризации адресного склада №2.
13.    Устанавливаем ГП на 01.01.06
14.    Делаем полную проверку (лог)и пересчет итогов и служебных данных еще раз
15.    Запускаем робота обработчика
16.    После каждого запуска делаем удаления помеченных объектов
17.     Делаем сверку остатков по складу, кассе, банку и долгов контрагентов.

Инструкция по созданию периферийных баз

1.    Удалить в конфигураторе периферийную базу и создать новую и выгрузить
2.    В центральной базе выгрузить периферийную базу
3.    Создать пустую новую базу и загрузить туда выгрузку периферийной базы
4.    Выгрузить из периферийной базы  в центральную и там загрузить
5.    Скопировать центральную базу sql и подменить периферийную sql
6.    Поправить периферийную sql базу файлы таблицы
7.    загрузить выгрузку из центральной и выгрузить в центральную

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

(47) зачем так длинно?
1. Пишем обработку.
2. Ставим в регламентное задание на начало месяца.

чоб не забыть в суете потомучто надо последовательно было все делать мог запарить

1. Создать остатки (документ)
2. Прямым запросом удалить движения, по документам из регистров и бух.
3. Удаление документов (без движения это происходит быстро, но можно шмальныть прямым запросом)
4. Пересчет итогов.

База 10гб, сворачивалась порядка часа.

(49) Ты не понимаешь.... Написать надо всего лишь одно - обработку по обрезке на -37 месяцев. И все.
зы. еще регулярное событие в аутглюке - проверить почту с результатами.

да все я понимаю

(0) а нахрена её вообще резать ?

(53) +1

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

(55) "некоторые регистры не закрываются" - так, может, есть смысл сделать так, что бы эти регистры все-таки закрывались?

(55) гыыыыы.... выслал :)))

Я как-то резал базу за год, объем базы около 20 Гб. Стандартными средствами пометка на удаления в тестовой базе часов 10 занимала, это было недопустимо.

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

(56) смысл минимален
1. базу все равно не перепровести
2. месяца через 2 .. 6 будет переход на 8-ку, но как-то дотянуть надо

(59) Вот всегда мне интересно было - а зачем на восьмерку переходите?
Тока это... Давайте холивар не будем разводить?

(60) так это... интересно ее поизучать и все такое :))

(60) нач-во - дураки.. это и ежу понятно.

(60) я тут с полгода работаю
все еще переходим ) но свет в конце тоннеля таки виден

(63) А причина перехода-то какая?
(61), (62) :))

хз, до меня начали

(65) так спросил бы, может и не будут переходить :)) меня возьмете на поддержку семерки и все такое...

(66)
А сколько ты хочешь получать за поддержку, если будешь работать в москве?

(67) я не могу поехать в Москву

Все не читал. Садовников уже сказал, что эта база крохотная, и резать нет смысла? ;-)

да )

Фот блин...

черт!

(71),(72) это вы типа ветку поднимаете? автор будет благодарен :)

прибил таки доки (с контролем)
удалил признак УРБД - надо было сразу сделать
прибил самые большие RG
запустил ТиИ - поглядим )

(0) Недавно резал базу 40 гб. 2,5 года. Несколько млн. документов. Обрезал на 1.01.09. Вся процедура заняла часов 6. Все прямыми запросами.
Этапы:
1) формирование документов, переносящих остатки и периодические реквизиты на 1.01.09. Здесь все просто.
2) Поиск ссылок на документы до 1.01.09 - в данных после 1.01.09. Через метаданные нашел все реквизиты типа "Документ" и сформировал готовый скрипт, который ищет IDDOC таких документов, пишет их в отдельную таблицу, а сами эти документы помечает на удаление. Добавил в эту же таблицу IDDOC документов после 1.01.09 и документы из п.1.
3) Одним скриптом удалил строки из всех таблиц, где присутствуют реквизиты IDDOC и DOCID, значение которых нет в списке из п.2. В этом скрипта использовал таблицы SYSOBJECTS и SYSCOLUMNS.
4) Выгрузил и загрузил данные.
Все.

(75) делись скриптами )
--
так-то есть еще документы неопределенного вида и реквизиты неопределенного типа )

(76) "и реквизиты неопределенного типа " - а вот это зря... Ой зря...

(77) я про вообще, а не конкретно )

(76) Скрипты вечером поищу, выложу.
Неопределенные - придется ручками добавлять в скрипты

(78) Будем считать, что слив засчитан :)

ТиИ еще продолжается - 18 часов чистого проц. времени (

Я здесь резал базу в 15 Гигов. Где-то порядка 2 млн. документов.
В случае, если помечать на удаление документы средствами 1С (даже с переносом ТА на первый документ), то за 1 сутки удавалось пометить на удаление порядка 50 тыс документов. В результате удалял прямыми запросами к SQL. Расклад по времени примерно следующий.
1. Формирование документов переноса остатков по регистрам - 5 мин
2. Формирование документов переноса периодических реквизитов - 2 мин
3. Помечение документов на удаление (с использованием прямых запросов) с очисткой движений по регистрам - 30 мин
4. Полный пересчет итогов - 40 мин.
5. Удаление помеченных документов без ссылок (порциями по 10 тыс документов) - 5 часов. Но это можно делать и в разделенном режиме.
  Так что твою базу вполне можно обрезать за 2 часа.

(82) делись скриптами по 3.  )

(83) а че, то что в обработке не помогло что ли?

еще не смотрел )
я запасливый, а база пока все равно занята

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

:)
сам-то резал такие базы )

?

(87) не-а :)))) на вас потренируюсь

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

Продолжим, пока все тестируется
---
Оказалось, что основной объем занимает _1SCRDOC (16gb таблица + 5 gb индексы)
лежат там графы отбора - около 30 шт !!!!
хочу отключить самые здоровые
как определить название графы по MDID?

(91) 1c++:

select $графаотбора.контрагент контрагент

и эта.. там не только графы отбора ;-)

(0) За ночь свернуть можно. При определенной сноровке может и за 2 часа получиться.
Просто метод надо знать правильный.

(93) Ну дык, говори )
Я внимательно читаю

(94) Даю подсказку: через УРБД.

(91) Соотношение странное. У меня индексы больше, нежели сами данные. Правда, отборов поменьше...

(92) спасибо
вроде заработало через
Сообщить(СокрЛП(ВыбСтрока)+"="+Мета.ИДОбъекта(Метаданные.ГрафаОтбора(ВыбСтрока)));
--
(95) ох, что-то не верится )
перезагрузить 5 млн. документов через урбд )

(95) А смысл делать через распределенку, если свертка может проводиться даже в разделенном режиме?

(83)
       //-- по документам из интервала очищаем регистры
       Если ЕстьРегистры=1 Тогда
           ДЛя х=1 По Метаданные.Регистр() Цикл
               ТекРегистр=Метаданные.Регистр(х);
                 Вид = ТекРегистр.Идентификатор;
                 ТаблицаБазы = Строка(Мета.ИмяТаблицыДвижений(Вид));  // покажем движения по регистам за день
                 ТекстЗапроса="
                 |DELETE
                 |FROM
                 |   "+ТаблицаБазы+"
                 |WHERE
                 |   "+ТаблицаБазы+".iddoc IN ( SELECT Iddoc FROM _1SJourn WHERE Date_TIME_IDDOC  BETWEEN :НачДата AND :КонДата~ )
                 |";

               Записи.УстановитьТекстовыйПараметр("НачДата",НачДата);
               Записи.УстановитьТекстовыйПараметр("КонДата",КонДата);
               Записи.ВыполнитьИнструкцию(ТекстЗапроса);
           КонецЦикла;
         КонецЕСли;

(83)
       //---Помечаем на удаление документы из интервала
       ТекстЗапроса="
       |UPDATE
       |    _1SJourn
       |SET
       |    ismark=1, closed=0
       |FROM
       |   _1SJourn            
       |WHERE
       |    (NOT _1SJourn.ISMARK = 1 ) AND
       |    (_1SJourn.Date_TIME_IDDOC  BETWEEN :НачДата AND :КонДата~ )
       |";

       Записи.УстановитьТекстовыйПараметр("НачДата",НачДата);
       Записи.УстановитьТекстовыйПараметр("КонДата",КонДата);
       Записи.ВыполнитьИнструкцию(ТекстЗапроса);

//--- удаляем Ручные операции из интервала");
       Если ЕстьПроводки=1 Тогда
           ТекстЗапроса="
             |DELETE
             |FROM
             |   _1SENTRY
             |WHERE
             |  ( _1SENTRY.Date_TIME_IDDOC  BETWEEN :НачДата AND :КонДата~ )
             |";

           Записи.УстановитьТекстовыйПараметр("НачДата",НачДата);
           Записи.УстановитьТекстовыйПараметр("КонДата",КонДата);
           Записи.ВыполнитьИнструкцию(ТекстЗапроса);
         КонецЕСли;

//-- по документам из интервала удаляем периодические реквизиты
       ТекстЗапроса="
         |DELETE
         |FROM
         |   _1SCONST
         |WHERE
         |   _1SCONST.docid IN ( SELECT Iddoc FROM _1SJourn WHERE Date_TIME_IDDOC  BETWEEN :НачДата AND :КонДата~ )
         |";

       Записи.УстановитьТекстовыйПараметр("НачДата",НачДата);
       Записи.УстановитьТекстовыйПараметр("КонДата",КонДата);
       Записи.ВыполнитьИнструкцию(ТекстЗапроса);

(97) если в рабочем периоде 5 млн. доков, то идеалогия свертки не правильная. В таких сложных случаях обычно делают свертку в начале периода даты свертки.
(98) Смысл не в этом. Вся беда типовой свертки - это удаление  документов закрываемого периода.

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

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

2(ProxyInspector) спасибо - пригодится

если есть необходимость удалить большое количество документов без ссылок, то это проще делать порциями по 10 тыс документов.
//-------------------------------------------------------
Процедура УдалитьПомеченныеДокументы()
   СписокНаУдаление=СоздатьОбъект("СписокЗначений");
   ВывестиТекстСостояния("*** Поиск помеченных на удаление документов");
   //Удаляем помеченные документы по 10000 документов
   Дкт=СоздатьОбъект("Документ");
   Дкт.ВыбратьДокументы();
   Пока Дкт.ПолучитьДокумент()<>0 Цикл
       Если Дкт.ПометкаУдаления()<>1 Тогда
           Продолжить;
       КонецЕСли;
       ТекДокумент=Дкт.ТекущийДокумент();
       ТекДата=Дкт.ДатаДок;
       СписокНаУдаление.ДобавитьЗначение(ТекДокумент);
       Если СписокНаУдаление.РазмерСписка() > 10000 Тогда
           ВывестиТекстСостояния("*** Удаление части помеченных на удаление документов без ссылок по: "+ТекДата);
           //НачатьТранзакцию();
           УдалитьОбъекты(СписокНаУдаление,1);
           //ЗафиксироватьТранзакцию();
           СписокНаУдаление.УдалитьВсе();
       КонецЕСли;
   КонецЦикла;
КонецПроцедуры

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

(108) на прямых запросах сворачиваешь? или хотя бы удаляешь?
если не в лом, кинь ссылку

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

http://infostart.ru/projects/1340

(109) тако

(110) пройденный этап )

еще раз (0) перечитал, (110) проблемы не решит.

(103) "если в рабочем периоде 5 млн. доков, то идеалогия свертки не правильная. В таких сложных случаях обычно делают свертку в начале периода даты свертки." - что означает сия "глубокомысленная мысль"?

разрешите встрять
както писал обработку, которая собирала текст запроса типа
delete from ra where iddoc in ...;
go;
по регистрам метаданных... однако данный скрипт при запуске просто повесил одноэс и не выполнил никаких действий. Запускал через 1с++
тот же запрос в анализере пошел на ура
это в рамках офф

(115) Ну, значит, что-то не так делал...

(116) думаю да... вот только времени на тот момент не было на выяснение обстоятельств, а потом вообще в восьмерку подался

(114) Иногда проще перенести в новую базу "маленький" рабочий период, чем парится, отрезая "огромный" период до даты свертки.

Есть обработки для СКЛ и ДБФ
Резал и напрямую, но как показывает практика ТиИ после такого вмешательства также занимает долгие часы (у меня выходило 8 часов примерно на 10 Гиг на старом сервере)
Вот ссылки на обработки:
http://infostart.ru/profile/2140/projects/2172/
http://infostart.ru/projects/1021/

(118) В принципе да, тоже имеет право быть :)

всем спасибо, скоро резать не большую базу SQL ))

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

Итого, оставить 2008-й год не получилось
максимум обрезалась база до 16 гб
ТиИ больше суток - такой вариант не катит

(123) Нахрена тебе ТиИ?

дык, я же скулем доки и еще некоторые таблички режу

(125) Ну, это я понимаю... Но ТиИ -то нафига?

почистить мусор за собой

(127) А ты его не оставляй:-)

Ну, как вариант, делай ТиИ в копии после обрезки. Хвосты увидиль,в рабочей почистишь :-)

Оставил только 2009-й - база 3,5 гб шататно выгрузилась / загрузилась - счастье )
Поставил еще раз на ТиИ на всякий пожарный

ТиИ сутки хде-то фигачило, часов 8-переиндексация, 13-часов логическая целостность. забыл почистить 1с конст и несколько лишних документов удалил :)
но уже виден свет в конце тоннеля )

(131) Ну ты тяжелый....
Переиндексацию делай скриптом, а не через ТиИ - быстрее будет. Логическая целостность - это да. Хотя хвосты особо мешать не будут - главное, чтоб лишнего не отрезать...

(0)Напиши бота, который будет сворачивать базу в фоновом режиме :)

(129) Не факт что она будет работоспособной
Мне, например, проще было провести ТиИ чем трахать неоткрывающийся док (вылет был вроде)

Ну ты мазохист. Столько времени режешь такую маленькую базу. Ты бы меня попросил и я бы тебе обрезал за 8 часов. С учетом доработки конфигурации. А судя по "я же скулем доки и еще некоторые таблички режу" вполне возможно, что база будет работать мягко говоря плохо.

(132) Если после обрезания база весит 3 гига, то проблем с логической целостностью и ТИИ нет. А распределенку надо первым делом удалять.

(135) Температуришь? То есть мысль возникла штатно порезать за 2-3 часа?

Штатно конечно не порежешь. Штатно в 1С вообще работают только мазохисты. За 2-3 часа можно порезать только если все делать прямыми запросами: помечать на удаление документы, удалять без ссылок и пересчитывать итоги.