Здравствуйте, Коллеги!
Возник вопрос по свертке базы данных Бухгалтерия 3.0. База большая, порядка 1 ТБ.
После удаления данных за 5 лет база не просто не уменьшилась, а еще и увеличилась в размерах.
Пробовал выгрузку в файл данных (DT) и последующая загрузка в новую базу SQL, размер уменьшается но очень мало.
Свертка производится с оставлением данных за текущий год 2023.
в итоге после всех манипуляций с данными база данных после удаление документов стала больше чем до удаления 1 110 560 Гб
Нашел отчеты в SQL server Management Studio (ssms) отчет по используемому месту на диске и используемому месту в таблицах.
отчет прикладываю к обращению. вопрос к сообществу каким образом можно уменьшить размер базы данных?
Мы делаем это для того чтобы уменьшить накладные расходы по обслуживанию базы данных, хранение резервных копий такой большой базы данных очень дорого (с точки зрения дискового пространства)
Возник вопрос по свертке базы данных Бухгалтерия 3.0. База большая, порядка 1 ТБ.
После удаления данных за 5 лет база не просто не уменьшилась, а еще и увеличилась в размерах.
Пробовал выгрузку в файл данных (DT) и последующая загрузка в новую базу SQL, размер уменьшается но очень мало.
Свертка производится с оставлением данных за текущий год 2023.
в итоге после всех манипуляций с данными база данных после удаление документов стала больше чем до удаления 1 110 560 Гб
Нашел отчеты в SQL server Management Studio (ssms) отчет по используемому месту на диске и используемому месту в таблицах.
отчет прикладываю к обращению. вопрос к сообществу каким образом можно уменьшить размер базы данных?
Мы делаем это для того чтобы уменьшить накладные расходы по обслуживанию базы данных, хранение резервных копий такой большой базы данных очень дорого (с точки зрения дискового пространства)
Прикрепленные файлы:
По теме из базы знаний
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
По первому скрину с размером таблиц видно что Зарезервировано 756 531 944 КБ. это ~756ГБ данных. я думаю что освободив зарезервированные данных можно существенно уменьшить объем самой базы, но как это сделать?
SHRINKDATABASE средствами SQL не помогает, пробовал перестраивать индексы, тоже нет результата
SHRINKDATABASE средствами SQL не помогает, пробовал перестраивать индексы, тоже нет результата
(1)разбирайтесь с регистром накопления accumRg21999. Вероятно, остатки не "схлопываются".
Узнать, что это за регистр в терминах 1с можно с помощью метода глобального контекста
ПолучитьСтруктуруХраненияИнформационнойБазы() (или как-то близко по смыслу в синтаксис-помощнике)
Узнать, что это за регистр в терминах 1с можно с помощью метода глобального контекста
ПолучитьСтруктуруХраненияИнформационнойБазы() (или как-то близко по смыслу в синтаксис-помощнике)
Нашел информацию по удалению данных итогов таблицы ИП МПЗ Отгруженные.
Для увеличения скорости удаления записей, я узнал название таблицы в базе MSSQL, зашел в базу и очистил данную таблицу, следующей командой
TRUNCATE TABLE accumRg21999
после этого можно удалять записи регистра, так как потом перепроведение сформирует новые движения по вводу остатков
Для увеличения скорости удаления записей, я узнал название таблицы в базе MSSQL, зашел в базу и очистил данную таблицу, следующей командой
TRUNCATE TABLE accumRg21999
после этого можно удалять записи регистра, так как потом перепроведение сформирует новые движения по вводу остатков
(7)Не так быстро, и внимательней, когда речь о работе с таблицами на уровне SQL.
accumRg21999 - это таблица самого регистра, т.е. вы не итоги удалили, а движения, по факту грохнули все, что было за все время в этот регистр записано.
accumRgT21999, которая и занимает у вас основное место - это таблица остатков. Ее, конечно, можно убить, но при пересчете итогов, вероятнее всего она снова станет такой же. Нужно подняться на уровень выше и проанализировать, почему остатки регистра не закрываются в ноль. Как только поймете - можно дальше думать.
accumRg21999 - это таблица самого регистра, т.е. вы не итоги удалили, а движения, по факту грохнули все, что было за все время в этот регистр записано.
accumRgT21999, которая и занимает у вас основное место - это таблица остатков. Ее, конечно, можно убить, но при пересчете итогов, вероятнее всего она снова станет такой же. Нужно подняться на уровень выше и проанализировать, почему остатки регистра не закрываются в ноль. Как только поймете - можно дальше думать.
(8)
Да, спасибо за наставление. я понимаю к чему приводит удаление записей регистра.
Но в моем случае я произвожу свертку базы данных Бухгалтерии, мне этот регистр явно мешает и не позволяет уменьшить объем базы.
я делаю новый ввод остатков на начало года и по этому регистру в том числе, после проведения периода текущего года записи там сформируется по новой.
Как только поймете - можно дальше думать.
Да, спасибо за наставление. я понимаю к чему приводит удаление записей регистра.
Но в моем случае я произвожу свертку базы данных Бухгалтерии, мне этот регистр явно мешает и не позволяет уменьшить объем базы.
я делаю новый ввод остатков на начало года и по этому регистру в том числе, после проведения периода текущего года записи там сформируется по новой.
(11)
ем больше там записей, тем медленнее она работает
Справедливо. Если архитектура плохая, то замедление линейно, если хорошая - логарифмично.
При достижении определенного размера регламенты по обслуживанию уже не успевают отработать за ночь и тогда произойдет остановка производственного процесса. вот за чем
Это повод задуматься, а все ли хорошо у Вас с железом. Ведь если железо не тянет производственную необходимость, то железо надо менять. Рано или поздно оно вообще перестанет справляться, т.к. решение развивается и все больше и больше в нем учитываемых аспектов. Так дойдет до того, что придется резать каждый день )))
(12)
Спасибо за ваши замечания, но в нашем железе я уверен, поэтому произвожу свертку раз в пятилетку.
Регламенты сейчас ночные все успевают, но вес базы уже настораживает и не хотелось бы тянуть с этим еще один год.
Почему я указываю именно 1 год, так как кто производит свертки Бухгалтерии знаю что отчетный период год и поквартальные отчеты.
Желаемый результат свертки ~300Гб.
по поводу архитектуры: в данной теме идет речь о почти типовой бухгалтерии. слово почти указывается что есть небольшие доработки в расширении не меняющие логику работы конфигурации кардинально. только удобство отображения или какой-то доп функционал.
Это больше камень в огород нашим 1с-никам. Мы работаем с чем приходится и адаптируемся к этому.
свертку производим уже не первый раз и с появлением в бухгалтерии этого регистра (ИП МПЗ) стало все гораздо проблематичнее. там на самом деле их целых 3 регистра связанных с друг другом.
Это повод задуматься, а все ли хорошо у Вас с железом. Ведь если железо не тянет производственную необходимость, то железо надо менять. Рано или поздно оно вообще перестанет справляться, т.к. решение развивается и все больше и больше в нем учитываемых аспектов. Так дойдет до того, что придется резать каждый день )))
Спасибо за ваши замечания, но в нашем железе я уверен, поэтому произвожу свертку раз в пятилетку.
Регламенты сейчас ночные все успевают, но вес базы уже настораживает и не хотелось бы тянуть с этим еще один год.
Почему я указываю именно 1 год, так как кто производит свертки Бухгалтерии знаю что отчетный период год и поквартальные отчеты.
Желаемый результат свертки ~300Гб.
по поводу архитектуры: в данной теме идет речь о почти типовой бухгалтерии. слово почти указывается что есть небольшие доработки в расширении не меняющие логику работы конфигурации кардинально. только удобство отображения или какой-то доп функционал.
Это больше камень в огород нашим 1с-никам. Мы работаем с чем приходится и адаптируемся к этому.
свертку производим уже не первый раз и с появлением в бухгалтерии этого регистра (ИП МПЗ) стало все гораздо проблематичнее. там на самом деле их целых 3 регистра связанных с друг другом.
(13)
На позапрошлой работе каждый год резали базу, но для этого сделали ежедневную автоматическую миграцию изменений из старой базы в новую в части изменений предыдущего периода. Тратили много ресурсов. Потом умные товарищи догадались резать базу в апреле по январь, чтобы избежать проблем переходного периода - первого квартала. И все стало очень даже хорошо.
ЗЫ: А резали просто - сгенерили скрипт, который транкейтил ненужные таблицы и делетил нужные по отбору "Период". Дальше из старой базы переезжали остатки в новую базу на час Ч. Таблицы с итогами грохались и при старте (первом запуске) пересчитывались.
по поводу архитектуры: в данной теме идет речь о почти типовой бухгалтери
Типовая бухгалтерия развивается без ваших местных 1С-негов, но 1С в нее регулярно что-то добавляет.
свертку производим уже не первый раз и с появлением в бухгалтерии этого регистра
Завтра в бухгалтерии вполне может появиться еще 10 таких регистров.
На позапрошлой работе каждый год резали базу, но для этого сделали ежедневную автоматическую миграцию изменений из старой базы в новую в части изменений предыдущего периода. Тратили много ресурсов. Потом умные товарищи догадались резать базу в апреле по январь, чтобы избежать проблем переходного периода - первого квартала. И все стало очень даже хорошо.
ЗЫ: А резали просто - сгенерили скрипт, который транкейтил ненужные таблицы и делетил нужные по отбору "Период". Дальше из старой базы переезжали остатки в новую базу на час Ч. Таблицы с итогами грохались и при старте (первом запуске) пересчитывались.
(14)
Ну такого уровня я еще не достиг, поэтому я пытаюсь делать удаление средствами 1С с последующим пересчетом итогов по регистрам.
всем спасибо, я примерно определился с тем что требуется сделать для достижения результата.
ЗЫ: А резали просто - сгенерили скрипт, который транкейтил ненужные таблицы и делетил нужные по отбору "Период". Дальше из старой базы переезжали остатки в новую базу на час Ч. Таблицы с итогами грохались и при старте (первом запуске) пересчитывались.
Ну такого уровня я еще не достиг, поэтому я пытаюсь делать удаление средствами 1С с последующим пересчетом итогов по регистрам.
всем спасибо, я примерно определился с тем что требуется сделать для достижения результата.
(15)
удаление средствами 1С
1С только регистры умеет удалять целиком быстро, все остальное - это запросы в цикле. Это не просто медленно, а очень медленно. Например, нафиг не нужны в новой базе табличные части старых документов. Да и большинство этих старых документов тоже не нужны, если остатки по ним уже "ушли".
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот