Всем привет!
У нас рабочая базу УПП, очень большая, бэкап SQL занимает 4 Тб.
Пытаюсь разобраться что да как (админ уволился на меня повесили), есть такие таблицы, как анпример регстар сведений Графики работ по видам времени на 22 млн.записей и прочие регистры с таким же количеством записей. Хочу их сократить, о свертке не может быть и речи (бухам нужны документы за прошлые периоды в режиме реального времени(копия отпадает), да и по словам тех же бухгалтеров предыдущие попытки не дали больших результатов). Никто не подскажет что делать?
У нас рабочая базу УПП, очень большая, бэкап SQL занимает 4 Тб.
Пытаюсь разобраться что да как (админ уволился на меня повесили), есть такие таблицы, как анпример регстар сведений Графики работ по видам времени на 22 млн.записей и прочие регистры с таким же количеством записей. Хочу их сократить, о свертке не может быть и речи (бухам нужны документы за прошлые периоды в режиме реального времени(копия отпадает), да и по словам тех же бухгалтеров предыдущие попытки не дали больших результатов). Никто не подскажет что делать?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
1) ТИИ не проканает, ради такой базы тебе от недели до месяца компанию нужно останавливать.
2) в SQL менеджере посмотри отчет по верхним таблицам. найди или сделай обработку, которая подскажет тебе связь имен этих таблиц с твоими метаданными.
3) Ищи регистры сведений ненужные, которые не используются. Может, логи какие-то кто-то делал и забыл автоочистку поставить.
4) Ищи какие индексы можно убрать. Иногда самопальные метаданные идексируют тупо по всем полям.
5) Посмотри есть ли в базе версионирование. Если включено, то отключай нафиг и удаляй все эти копии объектов нафиг.
6) Посмотри есть ли всякие замеры времени. Их тоже можно почистить.
7) Посмотри как настроено хранение файлов. Если не на внешних томах, то тогда у тебя пол базы - это всякие сканы накладных, договоров и счетов. Переноси на отдельные тома штатными средствами.
8) если все это не помогло снести лишние 3 терабайта, то ищи новую работу =)
1) ТИИ не проканает, ради такой базы тебе от недели до месяца компанию нужно останавливать.
2) в SQL менеджере посмотри отчет по верхним таблицам. найди или сделай обработку, которая подскажет тебе связь имен этих таблиц с твоими метаданными.
3) Ищи регистры сведений ненужные, которые не используются. Может, логи какие-то кто-то делал и забыл автоочистку поставить.
4) Ищи какие индексы можно убрать. Иногда самопальные метаданные идексируют тупо по всем полям.
5) Посмотри есть ли в базе версионирование. Если включено, то отключай нафиг и удаляй все эти копии объектов нафиг.
6) Посмотри есть ли всякие замеры времени. Их тоже можно почистить.
7) Посмотри как настроено хранение файлов. Если не на внешних томах, то тогда у тебя пол базы - это всякие сканы накладных, договоров и счетов. Переноси на отдельные тома штатными средствами.
8) если все это не помогло снести лишние 3 терабайта, то ищи новую работу =)
(1)Недавно были такие же проблемы, но чуть в меньшем обьеме.
База с 2,2 Тб стала 950 Гб.
1) по SQL запрос на размер "верхних" таблиц и сравниваешь их с метаданными в 1С. Таким образом я нашел регистры по которым не закрывались итоги.
2) удаление с умом старых версий документов ( например документ 100 раз просто перепроводился но разными пользователями, зачем таких 100 версий? ) или удаление версий в принципе если это по этому объекту были включены "случайно"
3) удаление помеченных на удаление элементов с их версиями
4) чистка "задач пользователя", бизнес процессов и регистра "Рецензий" если он присутствует, но как и во 2м пункте с умом ( никому не нужны задачи более 2х летней давности, а вот рецензии по ним необходимы, или наоборот )
5) Поиск не нужных регистров ( да, такие у меня имелись - "оставили как было т.к не хватило времени убрать их проводки" )
База с 2,2 Тб стала 950 Гб.
1) по SQL запрос на размер "верхних" таблиц и сравниваешь их с метаданными в 1С. Таким образом я нашел регистры по которым не закрывались итоги.
2) удаление с умом старых версий документов ( например документ 100 раз просто перепроводился но разными пользователями, зачем таких 100 версий? ) или удаление версий в принципе если это по этому объекту были включены "случайно"
3) удаление помеченных на удаление элементов с их версиями
4) чистка "задач пользователя", бизнес процессов и регистра "Рецензий" если он присутствует, но как и во 2м пункте с умом ( никому не нужны задачи более 2х летней давности, а вот рецензии по ним необходимы, или наоборот )
5) Поиск не нужных регистров ( да, такие у меня имелись - "оставили как было т.к не хватило времени убрать их проводки" )
так бухам за какой период нужны сведения ?
от начала работы системы или за 25предыдущих лет ?
************
и по словам тех же бухгалтеров предыдущие попытки не дали больших результатов
************
это еще большой вопрос как и кто делал и понимает ли бухгалтерия о чем речь :)
я так понял MSSQL
от начала работы системы или за 25предыдущих лет ?
************
и по словам тех же бухгалтеров предыдущие попытки не дали больших результатов
************
это еще большой вопрос как и кто делал и понимает ли бухгалтерия о чем речь :)
я так понял MSSQL
так поговорите с бухами, что и за какие периоды им нужно
может отдельно сохранить именно эти данные ,
не понятно , смотря чего они захотят
свертку базы я бы не делал...неизвестно как они ведут учет ,
а еще если сегодня-вчера отмена проведения и всякие вкусности :)
может отдельно сохранить именно эти данные ,
не понятно , смотря чего они захотят
свертку базы я бы не делал...неизвестно как они ведут учет ,
а еще если сегодня-вчера отмена проведения и всякие вкусности :)
Причем я сейчас вывел количество записей по метаданным - там в целом только в 2-х регистрах записей больше 25 млн, еще в одном 8 млн и третий по количеству на 4 млн, остальные цифры терпимые.
Я не понимаю откуда объем такой - из-за этимх 2-х регистров на 25+млн?
Причем если делать полный бэкап то получается меньше Тб, а разнстные накидывают по пол ТБ за день, эт нормально?
Я не понимаю откуда объем такой - из-за этимх 2-х регистров на 25+млн?
Причем если делать полный бэкап то получается меньше Тб, а разнстные накидывают по пол ТБ за день, эт нормально?
я бы делал так:
1) узнал бы размер внутренних таблиц. В больших таблицах проверил бы все реквизиты на тип данных и длину.
Мне один раз попался строкой тип длинною 1000.
2) дальше думать как уменьшить эти таблицы.
бэкап SQL занимает 4 Тб, у нас 8 .
1) узнал бы размер внутренних таблиц. В больших таблицах проверил бы все реквизиты на тип данных и длину.
Мне один раз попался строкой тип длинною 1000.
2) дальше думать как уменьшить эти таблицы.
бэкап SQL занимает 4 Тб, у нас 8 .
Графики работы по видам времени за старые периоды бухам ни к чему - можно чистить.
Но на 4 Тб архив раздули не они. Скорее всего, у вас в базе хранятся двоичные данные - сканы документов и т.д. Посмотрите размер справочника ХранилищеДополнительнойИнформациии. Если включено версионирование, то посмотрите регистр ВерсииОбъектов. Его тоже можно почистить, оставив данные за этот год, например.
Вообще, посмотрите размер таблиц (не количество строк в них).
Если дело в ХранилищеДополнительнойИнформациии, то можно почистить (естественно, предварительно согласовав это) прикрепленные файлы старых документов (отбирая по Объект.Дата для Объектов - документов).
В некоторых таблицах двоичные данные хранятся в самой таблице, например Справочник.Номенклатура.ОсновноеИзображение. Они тоже могут давать вес, если, допустим, туда заливают какие-то фото с безумным разрешением. Но это все менее вероятно, скорее всего дело в ХранилищеДополнительнойИнформациии
Но на 4 Тб архив раздули не они. Скорее всего, у вас в базе хранятся двоичные данные - сканы документов и т.д. Посмотрите размер справочника ХранилищеДополнительнойИнформациии. Если включено версионирование, то посмотрите регистр ВерсииОбъектов. Его тоже можно почистить, оставив данные за этот год, например.
Вообще, посмотрите размер таблиц (не количество строк в них).
Если дело в ХранилищеДополнительнойИнформациии, то можно почистить (естественно, предварительно согласовав это) прикрепленные файлы старых документов (отбирая по Объект.Дата для Объектов - документов).
В некоторых таблицах двоичные данные хранятся в самой таблице, например Справочник.Номенклатура.ОсновноеИзображение. Они тоже могут давать вес, если, допустим, туда заливают какие-то фото с безумным разрешением. Но это все менее вероятно, скорее всего дело в ХранилищеДополнительнойИнформациии
Если известно, что сканы много места занимают. Возможно есть смысл пережать сканы.
В нашей базе мы прикладывали к каждой серии сканы алко справок А и Б. В итоге я пережимал на лету при загрузке сканов.
Также неплохо сэкономило места объединение JPG в PDF.
В нашей базе мы прикладывали к каждой серии сканы алко справок А и Б. В итоге я пережимал на лету при загрузке сканов.
Также неплохо сэкономило места объединение JPG в PDF.
(35)
один из фрагментов, основной интерес convert -density 300 -colorspace Gray.
один из фрагментов, основной интерес convert -density 300 -colorspace Gray.
Если Размер > 1048576 ИЛИ Сред(СвойстваФайла.Получить("Bit depth"),1,2)="24" Тогда
dpi = Сред(СвойстваФайла.Получить("Horizontal resolution"),2,3);
Если dpi = "300" Тогда
СтрокаКоманды = """"+ПутьКВнешнейКомпоненте + ИмяВнешнейКомпоненты +""" convert "+
ИмяВременногоФайла +" -colorspace Gray -despeckle -quality 7 "+ИмяВременногоФайлаПолученного;
КонецЕсли;
Если dpi = "400" Тогда
СтрокаКоманды = """"+ПутьКВнешнейКомпоненте + ИмяВнешнейКомпоненты +""" convert "+
ИмяВременногоФайла +" -density 300 -resize 75%% -colorspace Gray -despeckle -quality 7 "+ИмяВременногоФайлаПолученного;
КонецЕсли;
WshShell=Новый COMОбъект("Wscript.Shell");
sReturn = WshShell.run(СтрокаКоманды ,1,True);
ЗаменаФайлаВХранилище(ИмяВременногоФайлаПолученного, АдресПриложенногоСкана);
УдалитьФайлы(ИмяВременногоФайлаПолученного);
КонецЕсли;
Показать
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот