Эти материалы являются объектом авторского права и защищены законами РФ и международными соглашениями о защите авторских прав. Перед использованием материалов вы обязаны принять условия лицензионного договора на использование этих материалов, или же вы не имеете права использовать настоящие материалы

Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом

Отличия PgSQL и Oracle для администраторов Oracle

Заметки написаны после прохождения 2 из 4 базовых курсов, разработанных компанией PostgresPRO, по администрированию БД PostgreeSQL в учебном центре Форс в феврале 2024 года. Про импортозамещение, кстати честное в этом случае - именно российские разработчики прилично добавили в ядро СУБД и архитектуру. Пока самое основное, по верхам, что выделил для себя после начальных курсов. Отличие СУБД PostgreeSQL от СУБД Oracle для администраторов СУБД Oracle, мои "заметки на полях". Так, чтобы быстро войти в курс дела ...

архитектурные особенности В БД нет библиотечного кэша, поэтому разбор планов выполнения производится в масштабах каждой новой сессии независимо. Внутри сессии возможно программно подготовить и разобрать запрос, несколько раз после этого выполняя его с разными параметрами. Есть кэш буферов, есть ручки настройки отдельных областей памяти

UNDO нет, версионность реализована сохранением старых версий строк, но только до момента, пока они нужны текущим транзакциям, после чего очередной процесс вакуумизации удаляет их. По этой причине в БД архитектурно нет механизма получения старых данных на точку времени - flashback. Вообще нет, это не оракл

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

SCN сквозного 64 битного SCN также нет, признан тяжёлым, в отличие от Оракла. Вместо него есть идентификатор транзакции LSN, является 32-битным и изменяется циклически так, что для текущей транзакции половина значений от текущего является будущим, а половина до текущего значения - прошлым, при общем количестве тиков примерно в 4 млрд. Это позволяет понимать, в прошлом или будущем относительно определенного номера текущей транзакции находится та или иная версия строки для обеспечения непротиворечивого (версионности) чтения. Однако буфер тиков относительно небольшой, и поэтому давно не менявшиеся строки помечаются как замороженные, т.е. гарантированно находящиеся в прошлом. Да, не изменяющему (не FOR UPDATE) селекту выдаётся псевдономер транзакции, всегда есть транзакция. Чтение никогда не блокирует данные, по крайней мере это декларируется. Но думаю, как и в оракле, защёлки за "горячие блоки" в памяти буферного кэша никто не отменял

REDO оперативные журналы WAL, в оракле редо как таковые есть, но они не замкнуты в цикл, как у оракла. Вместо этого они создаются последовательно, а по мере появления контрольных точек не требующиеся для восстановление сбоя экземпляра WAL удаляются автоматически. ID WAL не увеличивается последовательно нарастающим итогом +1, а отражает размер изменений журнала в байтах от начала первого старта БД после создания

CKPT контрольные точки есть, реализованы, фактически тут работа в целом аналогична ораклу. Изменения всегда попадают в оперативный журнал WAL/редо, а само изменение в файл данных размазывается по времени в асинхронном режиме и реализовано отдельными процессами dbwrite. Оракловые инкрементальные точки записывают данные частично, чтобы размазать нагрузку, а полные - скидывают кэш буферов на диск полностью. У постгри данные скидываются так, что можно удалять оперативные журналы с данными до контрольной точки

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

BACKUP резервирование реализовано несколькими методами - командой COPY, выгружающей содержимое отдельных таблиц, выгрузкой дампа командой pg_dump в нескольких форматах, в т.ч. позволяющих многопоточность, а также копированием БД утилитой pg_backup, которая готовит полную копию БД вместе с журналами. По сути реализован старый механизм горячего резервирования оракла BEGIN/END BACKUP, когда запись журналов переключается в полноблочный формат вместо вектора, что позволяет копировать изменяющиеся файлы данных, с последующим накатом изменений журналами. Изменения при восстановлении можно подкатывать на указанную точку времени, выбирая ее произвольно. В "ванильной" версии нет инкрементального бэкапа, только полный и архивлоги, но он есть в версии от PostgresPRO. Параметры, которые стоит включить сразу в части бэкапов - проверка чексум блоков. Также важно регулярно делать выгрузку pg_dump - это единственный вариант проверить логическую целостность блоков, ведь RMAN с его поблочным чтением при бэкапе тут нет

PHYSICAL STANDBY, LOGICAL, REPLICATION репликационные возможности. Физическая репликация фактически реализует механизм стэндбаев, которые могут быть открыты на чтение для распределения нагрузки. Однако, в силу архитектурных особенностей реализации версионного чтения, долгие транзакции не приветствуются. В силу реализации версионности чтения аналог ошибки 1555 Snapshot too old выглядит как ошибка нахождения старой версии строки. Альтернативой является специальный режим репликации, при котором реализуется обратная связь с ведущей БД, и старые версии строк на ней не удаляются, пока работает транзакция на стэндбае, но инструктора говорили, что режим этот очень сказывается на производительности основной БД. Сделать подкат отложенным на какое то время, например час, тоже возможно. После fileover physical standby есть утилита, откатывающая прежния primary до состояния standby, если доступен архив архивлогов. DataGuard естественно нет - всё руками и кристально ясным пониманием инженера. Также реализована репликация отдельных таблиц. т.е. логическая репликация, называемая тут "публикация и подписка"

физическая структура хранения в БД представлена табличными пространствами - каталогами, подкаталогами журналов, файлов данных и т.п. Конструкции сегменты/екстенты нет. Поддерживается только работа с файловой системой операционной системы, сырых устройств нет, естественно, нет и ASM. В табличном пространстве хранятся данные всех баз (кластера БД) обслуживаемых экземпляром, причём сами файлы данных представлены файлами экстентов отдельных объектов небольшого размера в 16МБ, которые добавляются по мере роста таблиц. Размер экстента может быть задан только при компиляции исходного кода СУБД. По крайней мере для 13 версии, по которой шёл курс. Сейчас вышла 16, и тут нужно курить мануалы. Имена файлов соответствуют ID экстента каждого обьекта, которые ID экстентов могут быть получены из словаря БД. Большие объекты LOB хранятся в отдельных таблицах со своими индексами, связанных с основной таблицей, с такой же разбивкой на экстенты. В целом это удобно - в одном файле не смешиваются разные обьекты, но непривычно и есть вопросы к малому размеру экстента на современных крупных БД. Есть аналог параметра PCTFREE

логическая структура объектов содержит иерархию кластер баз данных, база данных, объекты БД, принадлежащие БД. Схема - владелец также есть, причём схема здесь является синонимом пользователя, она полностью логическая - изменение схемы никуда не перемещает объекты данных

АAA настраивается гибко и интегрирована в операционную систему, например можно использовать PAM или GSSAPI (Kerberos). Проверки для суперпользователя на обьектные и системные привелегии после авторизации и аутентификации не выпооняются. Аудит реализован, включается отдельно, выгрузка в журнал и/или syslog

права на объекты и системные выдаются в виде привелегий, на процедуры, как и в оракле - могут выполняться с правами запустившего или создавшего. Квотирования емкости нет

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

кластеризация БД метрокластеры и т.п. В самой ванильной БД кластеризации нет, она не развивается, но реализуется сторонними продуктами. Парадигма ванильной БД, перефразируя моими словами сказанное преподавателем на курсе - СУБД как UNIX сервис. Кластера, в т.ч. реализация брокера и проверки доступности нод - только сторонними продуктами, которые да - есть, и есть разные

в целом БД продумана, и реализует вполне UNIX way и ценности сообщества Open Source, почему и лежит в каждом дистрибутиве Linux. Однако в ванильной версии нет инкрементального бэкапа и удобоваримых инструментов энтерпрайз администрирования, а также инструментов сбора и анализа ретроспективных статистических данных, как это реализовано у Оракла как минимум с 8 версии сначала пакетом statspack, а потом и полноценным AWR

разное На курсе DBA2 преподаватель обмолвился, что процессы PGSQL умеют создавать в памяти междусобойчики, общие области, не контролирукемые централизовано. По этой причине отстрел серверных процессов по kill -9 может привести к краху экземпляра и порче целостности БД ... за что купил, как говорится. Контрольник тоже есть, он маленький, но был всегда и именно в него, кроме прочего, и пишется последняя контрольная точка для восстановления

Следующая статья цикла О пригодности общедоступной Postgree SQL к промышленной эксплуатации

Белонин С.С. (С), февраль 2024 года