DB
Size: a a a
2021 June 24
AK
Всем привет! Подскажите, пожалуйста, как можно скрыть "чувствительные" данные (ключей, различных номеров и идентификаторов или произвольные параметры в целом) в логах?
AS
журналы проигрываются с позиции WAL REDO location ( 100% фиксированный checkpoint ) и у мастера в случае краха будет то же самое.
2021 June 25
RB
иногда лучше молчать, чем говорить (с). Если честно, не вспомнил, откуда я это взял (может постгрес-вторник или как там канал на youtube), т.к. в release notes не видно. Да и таблицы я перепутал и будет не очень удобно, но вот https://www.postgresql.org/docs/14/view-pg-locks.html (поле waitstart добавили)
ДИ
AL
Ради интереса, т.к. сам подобным занимался - а зачем переезжали?
Просто в моём случае, что-то стало лучше, а что-то хуже.
Просто в моём случае, что-то стало лучше, а что-то хуже.
ДИ
Переезжали так как было желание перевести движок на open source, я потратил много времени на анализ различных СУБД остановился на PostgreSQL о выборе не жалею. Что лучше что хуже написать можно но это был бы радикально длинный пост. даже не знаю...
AL
поста совсем не прошу, т.к. представляю, что могло быть )
пришлось переписать с T-SQL кучу кода несколько лет назад
интересны были именно причины
желание иметь open source вполне всё объясняет
пришлось переписать с T-SQL кучу кода несколько лет назад
интересны были именно причины
желание иметь open source вполне всё объясняет
ch
в моем случае были сложности с сертификацией oracle
UPD: увидел что речь шла не о нем
UPD: увидел что речь шла не о нем
AL
мало знаю про оракл, если честно
но слышал мнение, что 95% кода переносимо прямо копипастом
но слышал мнение, что 95% кода переносимо прямо копипастом
ДИ
Могу сказать что сильно помогло. Это гибкость, неограниченные практически возможности, открытость архитектуры, подробное описание системных таблиц. О чем пожалел больше всего. Не нашел никаких аналогов анализатора рабочей нагрузки с выдачей рекомендаций по настройке ядра СУБД как в MS SQl (во всяком случае бесплатного). Но зато погружение в EXPLAIN принесло больше понимания о том как там внутри живут ежики.
ch
в принципе да, однако дьявол кроется в деталях
ДИ
С копипастом я наткнулся на неадекватное падание производительности при использовании скалярных функция, которые в исходном решении меня не беспокоили в этом отношении. (ЗЫ: MS SQL)
AL
Мне тут повезло, т.к. был и Enterprise Edition и golden support (или как там его сейчас звать) от MS
но тем не менее, для себя сделал те же выводы
и поэтому и поражает скорость, с к которой можно добраться до core team в постгресе - критично нужные патчи мне делали часа за 4 от детекции проблемы
но тем не менее, для себя сделал те же выводы
и поэтому и поражает скорость, с к которой можно добраться до core team в постгресе - критично нужные патчи мне делали часа за 4 от детекции проблемы
AL
тут такая ещё штука, в которую стукнулся - линукс тюнить надо много больше
с MS SQL - скорее приходилось узнавать про СХД и файловые системы, т.к. упиралось, как правило, всё-таки в это, в олтп
постгрес тоже не лишён оного, но как-то, субъективно, всё-таки, поменьше
с MS SQL - скорее приходилось узнавать про СХД и файловые системы, т.к. упиралось, как правило, всё-таки в это, в олтп
постгрес тоже не лишён оного, но как-то, субъективно, всё-таки, поменьше
AL
на этом консалтеры и аутсорсеры и зарабатывают, имхо
ДИ
В данном конкретном случае проблема скорее была в неоптимальных планах выполнения при построчном вызове скалярных функций, но я обошел это просто полностью от них отказавшись в пользу представлений и составных запросов. Многоэтажные JOIN никогда не лезли мне в голову да и всякие неожиданные эффекты которые мало кто может предусмотреть ни к чему.
AL
тут тоже соглашусь - чем прямее (как рельс), тем проще, что дебажить, что разбираться, где именно проблема
OS
OS
прикол в том что я беру по определенному периоду, и записи может не быть в одном из таблиц, поэтому нулл