Свертка большой SQL базы (40 гб) #419631

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CREATE TABLE ##ID (IDDOC char primary key clustered) Go INSERT INTO ##ID SELECT DISTINCT IDDOC BEGIN TRANSACTION DECLARE Mycur cursor for SELECT sysobjects.name,syscolumns.name FROM syscolumns INNER JOIN sysobjects ON syscolumns.id = sysobjects.id FETCH NEXT FROM MyCur INTO @TableName, @ColName BEGIN EXEC ('Delete from '+@TableName+' with (tablock) where '+@ColName+' IN (Select IDDOC FROM ##ID)') FETCH NEXT FROM MyCur INTO @TableName, @ColName END

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

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

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

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

krda(немяю)ramble.ru

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

rambler.ru

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

отправил

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

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

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

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

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

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

я сворачиваю базу Торговли с урбд так: 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.    загрузить выгрузку из центральной и выгрузить в центральную вообщем ни много загадочно половина модно выкиунть но я вот так делал для своей.

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

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

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

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

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

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

+1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

да )

Фот блин...

черт!

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

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

Недавно резал базу 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) Выгрузил и загрузил данные. Все.

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

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

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

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

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

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

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

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

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

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

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

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

?

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

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

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

1c++: select $графаотбора.контрагент контрагент и эта.. там не только графы отбора ;-)

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

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

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

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

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

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