Gilev.Vyacheslav
Вячеслав Гилёв

Нормальные люди начинают с того, что проверяют отработку действий при выходе из строя оборудования или проблем с софтом. Работает ли как ожидается. Объем допустимых потерь данных и время восстановления приемлемы. И так далее. Только после этого принимается стратегическое решение.
Тут же классика жанра - сначала ввяжемся, а там посмотрим...

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

(8) поддержу, экспертом делает опыт и практика, а у коллеги хоть и много опыта но в смежной части
да и человек честно говорит что цель зарабатывать деньги
хотя конечно своим подходим к проверке знаний фирма 1с обесценила имхо сертификат, больше похоже на "орден лояльных специалистов политике 1с с базовыми знаниями" :)

(7) "При запросе Истина, ответ через 0,7 сек, при Ложь 700 сек."
1. план ваш не смотрел, много времени копаться нет
2. Ну если у вас большое количество записей, а нужного индекса нет, то предпложу что происходит сканирование таблицы
для ИСТИНЫ записи быстро находятся, видимо их немного, а остальные записи с ложью и перебирается вся таблица
тут время будет пропорционально размеру
в более поздних версиях платформы изменился механизм "AQO — адаптивная оптимизация запросов", можете попробовать его тупо выключить , подробнее https://postgrespro.ru/docs/postgrespro/14/aqo
DROP EXTENSION aqo;
SELECT aqo_reset();
и возможно удалить строчку
shared_preload_libraries = 'aqo'
из файла postgresql.conf.
3. Также появился "параллелизм". Посмотрите его внимательней. Если там настроено на многопоточку, то настройте ради эксперимента на один поток. Хотя кажется что маловероятно дело в этом, визуально в плане не многопоточка не бросается сходу в глаза.
ALTER SYSTEM SET max_parallel_workers_per_gather TO 1; --2 это дефолтовое значение
-- значение 0 означает что не будет параллелизма, чем больше конкуренции за ресусры, больше блокировок,
-- ем выше загруженность процессора, тем меньше это значение. При одном пользователи значение будет максимальным.
-- Можно также пробовать при закрытии месяца, реструкторизации, загрузке dt в один поток 1с разрешать большие значения.
-- При многопоточной загрузке dt 1С наоборот отключать ставя 0.
ALTER SYSTEM SET max_parallel_workers TO 1;--8 - дефолтовое значение
-- рекомендуется подбирать настройку смотря на загруженность процессора, при загруженности меньше 30%
--пробуйте добавить пару ядер, перечитать настройки и оценить новую загруженность
ALTER SYSTEM SET max_worker_processes TO 1;--8 - дефолтовое значение
--обычно совпадает max_parallel_workers
ALTER SYSTEM SET parallel_leader_participation TO off;-- поумолчанию включен
-- есть смысл отключать только по указанию программиста, степень положительного или отрицательного влияния
-- ведущего зависит от типа плана запроса, числа рабочих процессов и длительности запроса.

чего испытывать, и так понятно, всё как на последней картинке - преимущественно "плохо" )))
в попытке универсально автоматизировать всё в одной базе получилось как обычно универсально посредственно

(4)

Цитата
PITR тоже нужен не всем, а с тем что в postgres он работает только при копировании кластера целиком - ещё и не всем удобен.

так сразу бы и сказали что вы из лагеря "отрицателей RPO/RTO"
какие блин "удобно-не удобно", таких горе-специалистов надо сразу увольнять
основная задача админа - обеспечить работоспособность компании и не потерять информацию в случае сбоя или свести к минимуму потери.

я уж не говорю частичной неработоспособности дампов - https://forum.infostart.ru/forum34/topic205091/

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

Цитата
А вот у MSSQL действительно можно получить дамп (с поврежденной базы) который потом не восстановится.

двоишнику на заметку:
- DBCC CHECKDB
- контроль целостности бэкапа
- мониторинг логов скуля на ошибки записи
- мониторинг ssd на износ и температуту
- исторические копии на глубину последние 7 дней, месячной, кватральной и годовой давности - на удаленную площадку без сквозной авторизации (например по фтп)
решают полностью вопрос

отвечать ничего не надо, говорить "а у меня только демо-база" тоже, с вами всё понятно

(2)

Цитата
подключение идёт через unix-сокет

в статье идет подключении по tcp/ip , если сервер 1с на другом сервере, то ни какого юникс-сокета

Цитата
в trust

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

Цитата
PG_PASSWORD=пароль

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

Цитата
пароль к серверу в pgpass.conf

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

а pg_dump типа полностью консистентную базу делает? pg_dump НЕ может использоваться как для восстановления на определенный момент времени. Пока делается бэкап, а на большой базе это может занимать существенное время, то даже если по окончанию бэкапа вы начнете делать новый, но в этот момент произойдет сбой, и второй не успеет к этому моменту завершиться, то вы потеряете много данных.
Кроме того, не получится откатиться к нужному моменту времени, вы сможете выбирать только из времен создания дампов.
Таким образом, такой метод применим, если у вас базе работает пара пользователей и забивает в день пару документов, и их проще руками восстановить. Для большинства такой метод логического резервного копирования не годится — объем потерянных данных неприемлем. Ну разве что вы в отсутствии пользователей сделаете дапм и перенесете на новое место, например на новый сервер. Но и тут скорее надо делать бэкап всего «кластера PG» целиком командой pg_dumpall, а при полностью идентичных средах просто каталог кластера скопировать.
Dump не содержит информации для дальнейшего воспроизведения журнала транзакций и потому не подходит для решения задачи восстановления на момент времени (Point-in-Time Recovery, PITR).
И это ещё не говоря о том что не сбрасываются на из кэша на диск данные, и вообще могут жить в кэше ОС, что не добавляет гарантий 100% работоспособности бэкапа. В очень редких случаях бэкап может оказаться не пригоден для восстановления базы из него. Т.е. в силу особенностей механизмо работы субд DUMP это не полный аналог полного бэкапа скуля!

уж не говорю о том что каждую неделю в тематических чатах и форумах вижу "не подымается dump, что делать?"

похоже на проблему https://forum.mista.ru/topic.php?id=827102&page=2 связанную с тем что на скуле максимальный размер данных в поле - 2 Гб, а на pg 1 гб
найти по размеру проблемную таблицу и строку
если пользовательские данные, то удалить
а если в каком-нибудь config, то разве что снять с поддержки попробовать

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

зачем эта штука нужна, если есть Пуск и из клиента можно сервер открыть?

Прикрепленные файлы:

tcadm (2).png
unix (1).png