Мина замедленного действия при нетиповой обрезке базы
Добрый день!
Стояла задача урезать относительно небольших размеров (30 ГБ) базу, клиент-сервер + MS SQL. Типовая обработка в тестах делала это за неделю, да и не все гладко было. Написал обработку-генератор скрипта SQL, усекающую регистры и удаляющую ненужные документы. Урезал, пересчитал итоги, все в норме, полет нормальный. До тех пор, пока не возникла необходимость подправить одно предопределенное субконто (добавить признак Количественный). При реструктуризации таблица Хозрасчетный.Субконто полностью очищается. От релиза не зависит, проверял в т.ч. на последнем совместимом из 8.3.5.
Предположил также, что могут мешаться неприбитые по дате записи из таблицы субконто (зачищалась только основная таблица). Дочистил все записи, более не имеющие прародителей в основной таблице, типа:
delete fr om _AccRgED22127
where _RecorderRRef in (
sel ect distinct t._RecorderRRef
fr om _AccRgED22127 t
left outer join _AccRg22129 tt
on tt._RecorderRRef = t._RecorderRRef
wh ere tt._RecorderRRef is NULL)
- не помогает.
Никто не имел такого удовольствия?
Стояла задача урезать относительно небольших размеров (30 ГБ) базу, клиент-сервер + MS SQL. Типовая обработка в тестах делала это за неделю, да и не все гладко было. Написал обработку-генератор скрипта SQL, усекающую регистры и удаляющую ненужные документы. Урезал, пересчитал итоги, все в норме, полет нормальный. До тех пор, пока не возникла необходимость подправить одно предопределенное субконто (добавить признак Количественный). При реструктуризации таблица Хозрасчетный.Субконто полностью очищается. От релиза не зависит, проверял в т.ч. на последнем совместимом из 8.3.5.
Предположил также, что могут мешаться неприбитые по дате записи из таблицы субконто (зачищалась только основная таблица). Дочистил все записи, более не имеющие прародителей в основной таблице, типа:
delete fr om _AccRgED22127
where _RecorderRRef in (
sel ect distinct t._RecorderRRef
fr om _AccRgED22127 t
left outer join _AccRg22129 tt
on tt._RecorderRRef = t._RecorderRRef
wh ere tt._RecorderRRef is NULL)
- не помогает.
Никто не имел такого удовольствия?
По теме из базы знаний
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Задача "урезать" может быть решена переносом данных в новую базу.
Что-то мне подсказывает, что удалить надо большую часть данных.
Следовательно, Перенос актуальных данных может занять гораздо меньшее время.
При грамотно настроенном обмене можно сделать так, что будут некоторое время существовать обе базы.
А после окончательного переноса данных и ввода остатков на начало периода - первую базу можно будет просто отключить.
Что-то мне подсказывает, что удалить надо большую часть данных.
Следовательно, Перенос актуальных данных может занять гораздо меньшее время.
При грамотно настроенном обмене можно сделать так, что будут некоторое время существовать обе базы.
А после окончательного переноса данных и ввода остатков на начало периода - первую базу можно будет просто отключить.
смотрите , к каким таблицам обращается 1с8 пред очисткой .
и попытайтесь проанализировать, почему 1с8 решает очистить. как вариант сделайте копию таблицы. после реструктуризации и очистки пре заполните с учетом количественного субконто.
и попытайтесь проанализировать, почему 1с8 решает очистить. как вариант сделайте копию таблицы. после реструктуризации и очистки пре заполните с учетом количественного субконто.
Решение было то, же что и в начале: просто в скрипте очистки бесхозных записей субконто перепутал таблицу налогового к проводкам хозрасчетного - они вязались, но понятно, что движения одних регистраторов есть и по БУ и по НУ. После исправления скрипта все прокатило. Вознаграждение - в ответ (2), потому что после него запустил профайлер, и увидел, что за скрипты гонит ТИИ, и увидел несоответствие).
Остальное - лицензия, ТИИ, типовщина, выгрузки - хорошо, но слишком долго.
(7) Придумайте сами ну, например, пару причин, зачем. Наверняка найдете)
Остальное - лицензия, ТИИ, типовщина, выгрузки - хорошо, но слишком долго.
(7) Придумайте сами ну, например, пару причин, зачем. Наверняка найдете)
(8) irreal, я понимаю вы написали скрипт котрый систит некоторые балицы и документы, потом у это удаляете? Причем средствами SQL.
Геройский поступок. А не проще было воспользоваться стандартной обработкой по сверке базы, создать правило по которому сворачивается тот или иной документи вперед. Просто при усечении средствами SQL можно не учесть связанных движений и можно нарушить целостность данных в системе.
Геройский поступок. А не проще было воспользоваться стандартной обработкой по сверке базы, создать правило по которому сворачивается тот или иной документи вперед. Просто при усечении средствами SQL можно не учесть связанных движений и можно нарушить целостность данных в системе.
Как я писал, та самая стандартная обработка возится слишком долго, сколько мне дать не могут. Это еще одна из самых маленьких баз, есть еще базенка под 300 гигов. "Целостность базы" - очень лелеемое людьми из 1С понятие. Если целостность ограничивается "объект не найден", то это не проблема, к тому же в скрипте зачистки генерировалась таблица по поиску ссылок тех документов, что фигурируют в остатках, введенных той самой обработкой. Воздействие на данные - не фатальное действие, вот когда конфигуратор вылетит в середине обновления и скажет, что в предыдущем обновлении произошла ошибка, а потом "Нарушена целостность ИБ" и закроется - это да... ищи небитую _Config.)))
А так - ничего страшного - просто поленился зачистить таблицу субконто, а реструктуризация, как заправский хирург, оттяпала руку из-за пальца)
А так - ничего страшного - просто поленился зачистить таблицу субконто, а реструктуризация, как заправский хирург, оттяпала руку из-за пальца)
(12) Мысль не плохая. Только создание, корректно работающей много-поточной свертки потребует прилично времени.
В принципе вот статья как это можно сделать:
Но мне кажется, что лучше использовать уже проверенные механизмы.
Перенос данных, как вариант свертки, мне кажется самым простым и надежным при такой огромной базе.
Данные из базы 1 в базу 2 могут перетекать хоть месяц не мешая работе.
И всегда будет возможность вернуться к прежнему состоянию.
В принципе вот статья как это можно сделать:
Но мне кажется, что лучше использовать уже проверенные механизмы.
Перенос данных, как вариант свертки, мне кажется самым простым и надежным при такой огромной базе.
Данные из базы 1 в базу 2 могут перетекать хоть месяц не мешая работе.
И всегда будет возможность вернуться к прежнему состоянию.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот