По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Была такая же проблема, в скуле база весит 50 гигов, а при выгрузке в dt всего 2,5 гига.
Если в скуле посмотреть размер базы то сама база весит окло 3 гиг, а журнал транзакций все оставшееся.
Потом себя долго материл что не до конца настроил бэкап (с начала зделал только быкап самой базы).
после того как настроил бекап журнала транзакций, через пару дней, все пришло в порядок, т.е. база весить стала около 3 гиг и журнал транзакций от 1 мб до больше.
Если в скуле посмотреть размер базы то сама база весит окло 3 гиг, а журнал транзакций все оставшееся.
Потом себя долго материл что не до конца настроил бэкап (с начала зделал только быкап самой базы).
после того как настроил бекап журнала транзакций, через пару дней, все пришло в порядок, т.е. база весить стала около 3 гиг и журнал транзакций от 1 мб до больше.
дополню. Сначала тоже делал переиндексацию, резултат был не существенный.
выгрузка-загрузка непомогала а усугубляло дело.
так что настраивай бекап. и все будет хорошо.
я настроил так:
- В 24 часа делается полный бекап базы с полной перезаписью файла бекапа.
- Втечении дня с 7:00 до 19:00 каждые полчаса делается бекап журнала транзакций в файл (из пункта выше)с до записью
итог: после первого пункта бекап будет весить чуть больше чем вес реальной базы.
во время второго он будет каждые пол часа расти по мере работы пользователей.
на следующий день все повториться.
выгрузка-загрузка непомогала а усугубляло дело.
так что настраивай бекап. и все будет хорошо.
я настроил так:
- В 24 часа делается полный бекап базы с полной перезаписью файла бекапа.
- Втечении дня с 7:00 до 19:00 каждые полчаса делается бекап журнала транзакций в файл (из пункта выше)с до записью
итог: после первого пункта бекап будет весить чуть больше чем вес реальной базы.
во время второго он будет каждые пол часа расти по мере работы пользователей.
на следующий день все повториться.
Для ПостГри не знаю, но лучше прописать регламенты, к примеру Ребилт базы (можно использовать и СКУЛЬ разницы как таковой между 1с-ким нет), шринк базы обязательный (раз в неделю), если заканчивается место разнести на разные диски БД.
В типовой конфигурации такая ситуация может быть следствием:
1. Большого количества документов (более 2-3 тысяч документов в день)
2. Или хранение данных в хранилище, яркий пример большое количества фотографий для каждой номенклатуры например под тристо тысяч позиций ))).
Р Е Ш Е Н И Е:
1. В первом случае сворачиваю базу каждый год... база за год достигает у клиента 100 - 120 гигов)... при этом каждый квартал выгружаем и загружаем базу база уменьшается от 5 до 20 гигов. или очищать временный и ненужные таблицы в SQL нужно смотреть
(также есть готовое решение свертки документов по месяцам документы сворачиваются в разрезе контрагентов и договоров! т.е. например вместо двадцати документов одного контрагента сформированные в течении одного месяца преобразуются в один в начале месяца или в конце как следствие уменьшение количество партий правда делал под УПП если нужно обращайтесь сделаю для УТ – база уменьшается как минимум в 10 раз а то и в 100 раз).
2. Во втором случае некуда деться боремся только уменьшением данных если нужно напишу обработку по свертке например фотографий (т.е. например конвертация в jpeg уменьшение разрешения (размера) фотографий)
***
В нетиповой конфигурации такая ситуация может быть следствием ошибок разработчика (не корректная работа например с регистрами сведений и накопления или партий как следствие разрастание базы) приходилось править… ))) короче нужно смотреть...
1. Большого количества документов (более 2-3 тысяч документов в день)
2. Или хранение данных в хранилище, яркий пример большое количества фотографий для каждой номенклатуры например под тристо тысяч позиций ))).
Р Е Ш Е Н И Е:
1. В первом случае сворачиваю базу каждый год... база за год достигает у клиента 100 - 120 гигов)... при этом каждый квартал выгружаем и загружаем базу база уменьшается от 5 до 20 гигов. или очищать временный и ненужные таблицы в SQL нужно смотреть
(также есть готовое решение свертки документов по месяцам документы сворачиваются в разрезе контрагентов и договоров! т.е. например вместо двадцати документов одного контрагента сформированные в течении одного месяца преобразуются в один в начале месяца или в конце как следствие уменьшение количество партий правда делал под УПП если нужно обращайтесь сделаю для УТ – база уменьшается как минимум в 10 раз а то и в 100 раз).
2. Во втором случае некуда деться боремся только уменьшением данных если нужно напишу обработку по свертке например фотографий (т.е. например конвертация в jpeg уменьшение разрешения (размера) фотографий)
***
В нетиповой конфигурации такая ситуация может быть следствием ошибок разработчика (не корректная работа например с регистрами сведений и накопления или партий как следствие разрастание базы) приходилось править… ))) короче нужно смотреть...
ок не буду но чем дальше тем еще веселее тема перед тем как уезжать с работы заглянул в диспетчер задач где напротив процессов по имени pgAdmin написано не отвечает....запускал Vacuum из под него что дальше делать я х.з...
А на счет еще один сервак поднять это как??? у меня то база одна я чего то этого не допонял...
А на счет еще один сервак поднять это как??? у меня то база одна я чего то этого не допонял...
Я не специалист по Postgre. Лучше помолчу про его поведение.
В любой конторе можно найти запасной сервер где поднять базы из копии. На крайний случай можно поднять файловые копии. Чтобы люди завтра утром смогли работать.
В любой конторе можно найти запасной сервер где поднять базы из копии. На крайний случай можно поднять файловые копии. Чтобы люди завтра утром смогли работать.
24 25 хмммм не могу сказать что он отработал но вакуум в какой то момент то ли отключился то ли что я в общем х.з в понедельник утром уже все нормально смогли работать да и база стала вроде двигаться по быстрее.... просто насколько я въехал из факов и форумов, после того как вакуум заканчивается он выводит время сколько он шел, а у меня времени в отчете не было в общем х.з в эти выходные снова буду пробовать... по крайней мере удалось вычитать что vacuum analyze можно запускать и момент када работаю в базе так он не блокирует таблицы...вот он кста после выполнения выводит время сколько эта басня длилась, да и и на кнопке вместо Ок написано Завершено в PGadmin'e....
поменела где то метров на 300 вообще у мну такое ощущение что нормальный результат будит виден в том случае если после vacuum full следом запустить и reindex вот тогда база должна нормально раздуплиться...
Тут еще очень интересный момент возник, что для postgresql лучше windows или linux анализирую те статьи которые я смог нарыть в инете и сообщения на многих форум я пришел к выводу что postgresql под linux будит лучше работать плюс к тому же его хотя бы мона будит пропатчить теми патчами которые на своем сайте выложила 1С. Потому как под винды их никто не смог скомпилить и проставить.
Тут еще очень интересный момент возник, что для postgresql лучше windows или linux анализирую те статьи которые я смог нарыть в инете и сообщения на многих форум я пришел к выводу что postgresql под linux будит лучше работать плюс к тому же его хотя бы мона будит пропатчить теми патчами которые на своем сайте выложила 1С. Потому как под винды их никто не смог скомпилить и проставить.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот