Sql postgresql: The world’s most advanced open source database

PostgreSQL – как правильно работать OTUS

Для работы с таблицами и базами данных пользователям, а также системным администраторам требуется знать SQL. Это язык запросов, который открывает довольно широкий спектр возможностей. К примеру, если вы знакомы с SQL, вы сможете уверенно работать с такой популярной системой управления базами данных, как PostgreSQL. В данной статье будет рассказано об основах применения подобной «лексики», а также о ее subquery.

Краткое определение

PostgreSQL – свободная система управления реляционными БД с открытым исходным кодом. Имеет поддержку:

• транзакций;
• схем;
• внешние ключи.

Более строго соответствует требованиям SQL. Выступает в качестве безопасного средства составления подзапросов.

PostgreSQL – запрос, вложенный в другой. Работает с предложением Where. Представляет собой subquery для применения во время функционирования баз информации на устройствах.

С чем применяются

Для того, чтобы полноценно использовать таблицы и БД, программеру может потребоваться рассматриваемых подзапрос. Здесь предстоит запомнить следующую информацию:

• подзапрос нужен для возврата информации, которая задействована в основном запросе в качестве своеобразного ограничителя сведений, подлежащих извлечению;
• subquery применяется с select, insert, update, delete. In;
• может использоваться совместно с операторами =, >, <, >=, <=.

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

Правила составления

Подзапрос мало изучить – требуется уяснить несколько правил, которые помогут в конечном итоге грамотно составлять соответствующие «посылы». Обратить внимание необходимо на такие принципы:

• подзапрос составляется с круглыми скобками;
• в предложении select может быть только один столбец, если в ключевом запросе нет нескольких подобных элементов для сравнения;
• order by не используют в подзапросе – только в основном «обращении»;
• group by применяется точно так же, как и order by в основном запросе;
• подзапросы, которые возвращают больше одной строки, могут быть задействованы с операторами значений IN, Exists not in, any, some, all;
• between – оператор, который не используется с подзапросом.

Также стоит обратить внимание на то, что МЕЖДУ разрешено использовать в подзапросе. Эти правила помогут работать с базами данных и грамотно обращаться к таблицам через PostgreSQL.

Управляющие структуры

Управляющие структуры помогают работать с PS/pgSQL. Они помогают гибко и эффективно манипулировать информацией в имеющихся таблицах.

Возврат значения функции

Первое, на что стоит обратить внимание – команды, с помощью которых осуществляется возврат значения функции. Речь идет о return и return next.

Return

Самый простой запрос. Имеет вид «Return выражение»;. Прекращает выполнение функции и возвращает значение выражения в вызванную утилиту. Применяется для подзапросов, которые не возвращают набор строк.

Стоит отметить следующие моменты:

1. Функции, отвечающие за возврат скалярного типа, предусматривают автоматическое приведение результирующего выражения к типу возвращаемого значения. Но, если возвращаемый тип является составным (строка), возвращаемое выражение должно обязательно содержать необходимый набор столбцов. Здесь иногда нужно провести явное приведение типов.
2. Функции, которые имеют выходные параметры, спокойно используются с return. Для этого выражение не требуется. Это повлечет за собой возврат текущих значений выходных параметров.
3. Если происходит возврат void, return может быть поставлен в любом месте, но без выражения – только после return.
4. Возвращаемое значение функций не может быть неопределенным. Если конец верхнего блока достигнут, а return не встретился, появляется ошибка времени реализации. Соответствующий принцип не имеет никакого отношения к функциям с выходными параметрами или возвращающих void.

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

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

Return Next и Return Query

Обладает видом:

Return next выражение;

Return query запрос;

Return query execute строка-команды [using выражение, […]];

Применяется для операций подзапроса, которые возвращают setof некий_тип. Отдельные составляющие возвращаемого значения будут формироваться командами return next и return query. Итоговая команда return без аргументов отвечает за завершение функции.

Здесь стоит обратить внимание на такие данные:

1. Return next применяется со скалярными и составными типами информации.
2. Для того, чтобы использовать скалярный тип, результат будет возвращаться в виде таблицы.
3. Return next и query не будут осуществлять возврат из функции. Они лишь добавляют строки в результирующие множества, после чего работа продолжается со следующего оператора в функции.
4. Если return (next, query) прошел обработку успешно, будет сформировано множество строчек результатов.
5. Для того, чтобы выйти из функции, применяется return, но без аргументов.
6. У Return query есть return query executive, которая предназначается для динамической обработки сформированного пользователем запроса. В текст можно добавлять различные параметры при помощи using или execute.
7. Для подзапроса с выходными параметрами рекомендуется задействовать return next без аргументов. Тогда текущие значения оных сохранятся для последующего возврата в качестве результирующей строки.

Выше представлены примеры использования соответствующих структур.

Условные операторы

Подразделяются на if и case. Предназначены для того, чтобы выполнять те или иные команды в зависимости от заданных условий. В подзапросах можно увидеть три трипа if:

• If … then… end if;
• If… then… else…. End if;
• If … then… elsif … then…else…end if.

У Case две формы представления:

Первый if – самый простой. Операторы между then и end будут выполняться, если условие (логическое выражение) выступает в качестве истины. Когда подобный принцип не соблюден, оные будут пропускаться системой.

Второй тип подзапроса if добавляет к if-then возможность указания альтернативного набора операторов. Они обрабатываются, если прописанное требование – это ложь или null.

Третий тип подзапроса if позволяет проверять несколько альтернатив в порядке очереди. Условия в If будут последовательно проверяться до тех пор, пока не будет обнаружена «истина». После операторы, которые относятся к соответствующему условию, пройдут стадию обработки. Управление перейдет к следующей после end if команде. Если же if не истина во всех ситуациях, будет реализован блок else (при наличии).

А вот эти сведения помогут разобраться с case:

1. Первая форма подзапросов отвечает за реализацию условного выполнения на основе сравнивания операндов. Выражение поиска вычисляется всего один раз, после чего сравнивается с каждым выражением в when. При наличии совпадений начинается работа тех или иных операторов. Управление будет передано команде, идущей за «концом» подзапроса. При отсутствии совпадений начинается реализация условий из блока else. Когда таковой отсутствует, вызывается исключение case_not_found.
2. Case с перебором условий отвечает за условное выполнение на основе истинности логических условий. Каждое выражение в when вычисляется по порядку до тех пор, пока не обнаруживается истина. Далее происходит обработка соответствующих запросов и переход к следующей команде. В противном случае выполняется else или вызывается case_not_found.

Выше представлен пример if-then-elsif подзапроса. Исключение здесь только одно – при невыполнении заданных условий, а также отсутствии else, if-then-elsif ничего не будет делать. В случае с case на экране появится ошибка.

Продолжение статьи читайте здесь.

Интересует PostgreSQL? Обратите внимание на специализированный курс Otus!

Частые вопросы по миграции базы данных 1С с MS SQL на PostgreSQL

Основные рекомендации про то, как мигрировать базу данных 1С с MS SQL на PostgreSQL в одной статье.

6 октября  •  DataLine

Миграция базы данных 1С с MS SQL на PostgreSQL – по-прежнему насущная тема, особенно в контексте импортозамещения. На наших вебинарах и в беседах с клиентами мы получаем много вопросов по нюансам миграции. Решили собрать основные рекомендации в одну статью.

1. С чего начать подготовку к миграции?

Первая задача – это тюнинг параметров потребляемой памяти в Postgres.

Postgres активно взаимодействует с ОС и если не находит в своем кеше требуемой страницы, то обращается к кешу операционной системы. Поэтому параметр shared_buffers (буфер PostgreSQL) выставляется от 25 до 50% от общего объема памяти. Shared_buffers не должен равняться общему объему памяти, выделенному на сервер (~= ¼ от общего объема памяти, но не более 50%).

Параметр work_mem отвечает за объем памяти для операций сортировки и хеш-таблицы. Этот параметр индивидуален для каждой сессии, поэтому его не надо сильно увеличивать. Тестируйте свое решение в диапазоне от 32 до 128 Мб.

Если запросу не хватает текущего объема, work_mem обратится к временным таблицам, и здесь включится в игру следующий параметр – temp_buffers. Он отвечает за количество буферов для временных таблиц. По дефолту его значение составляет 8 Мб. Здесь тоже советуем его изменить и поставить  от 128 до 256 Мб, в зависимости от конфигурации.

Так выглядит наш конфиг с выставленными настройками

В современных ОС используется страничный способ организации виртуальной памяти. По умолчанию размер страницы составляет 4 Кб. Чем больше у вас памяти, тем больше накладных расходов потребуется на обработку ее объема.

Каждая страница памяти сопоставлена с таблицей в адресном пространстве, которое преобразует виртуальную адресацию в физическую. C увеличением размера страницы, мы сокращаем ее. Соответственно, если таблица умещается в буфер ассоциативной памяти, то ускорение и увеличение производительности нагруженных систем с точки зрения памяти будет ощутимо. ОС трансформирует физическую трансляцию в виртуальную и кеш – в TLB (буфер ассоциативной памяти).

Схема использования TLB

Параметр Huge pages позволяет заметно сократить потребление общей памяти Postgres, его фоновых процессов и повысить производительность. VmPeak /proc/1854/status VmPeak: 17480728 kB [root@pg01 ~]# echo $((17480728 / 2048 + 1)) 8536 [root@pg01 ~]# echo ‘vm.nr_hugepages = 8536’ >> /etc/sysctl.d/00-postgresql.conf [root@pg01 ~]# sysctl -p —system

2. Что нужно учесть при настройке ОС?

PostgreSQL, как и большинство приложений, зависит от параметров операционной системы. Для СУБД это особенно критично: производительность может ощутимо снизиться при некорректной настройке параметров.

Ключевыми являются следующие настройки:

1. vm.swappines:

   sysctl -w vm.swappines=2

   Так регулируется процент памяти, при котором система начинает использовать swap-файл – область на диске, которая может быть использована системой как очень медленная оперативная память.

2. vm.overcommit_memory / vm.overcommit_ratio

   sysctl -w vm.overcommit_memory=2

   Убираем перевыделение памяти по умолчанию: в значении vm.overcommit_memory=0 происходит эвристический анализ для определения выделяемой процессу памяти. Это дополнительная трата ресурсов, а острая нехватка памяти и большая конкуренция запустит процесс OOM Killer, при этом вы получите сообщения: “Out of Memory: Killed process 12345 (postgres)”.

   Избежать этого поможет контроль перевыделения. Рекомендуем установить значение vm.overcommit_memory=2. Имейте в виду, что после установки этого параметра большую роль начнет играть значение vm.overcommit_ratio (число будет определять процент памяти, доступный для перевыделения, например, 50 для 4 Гб = 6 Гб) и наличие SWAP-файла. Для

   vm.overcommit_ratio универсальных значений нет: его обычно вычисляют исходя из доступной памяти и объема SWAP — overcommit_ratio < (RAM — swap) / RAM * 100.

3. Как повысить производительность PostgreSQL?

1С не делит данные на “горячие” и “холодные” (архивные) и все содержит в одной базе. Со временем объем данных увеличивается до многомиллионных значений. И небольшое изменение в процентном соотношении с общим объемом данных приводит к тому, что воркеры “не заходят” в эти таблицы и не пересчитывают статистику. А иметь правильную статистику очень важно, так как она используется оптимизатором при построении запроса.

Для ускорения и улучшения производительности стоит настроить процесс автовакуума.

Параметр autovacuum_max_workers отвечает за количество воркеров. Его можно определить по простой формуле: общее кол-во ядер делите пополам (~ кол-во vCPU / 2). Можно варьировать, но формула рабочая.

Само по себе увеличение количества воркеров не даст нам кратное увеличение производительности, поскольку на поведение воркеров влияют еще такие характеристики, как Autovacuum_vacuum_scale_factor и autovacuum_analyze_scale_factor. Они отвечают за пороги, при которых автовакуум будет заходить в таблицы/индексы, очищать и пересчитывать статистику.

Значения по умолчанию для scale_factor равны 0,2 (20%). Чем больше объем данных, тем больше влияют эти 10–20% на то, как будут заходить воркеры в таблицы и индексы: в многомиллиардных таблицах небольшие изменения будут незаметны для воркеров автовакуума. Поэтому рекомендуем уменьшить значения, выставленные по умолчанию, например:

• 5% – для autovacuum_vacuum_scale_factor;
• 10% – для autovacuum_analyze_scale_factor
  .

Таким образом мы повлияем на два важных фактора: у нас будет происходить очистка, и воркеры будут знать, что произошли изменения данных и надо обновить статистику.

Но важно помнить, что все же эти настройки индивидуальны.

Autovacuum_vacuum_cost_limit следит за суммарным порогом стоимости всех воркеров автовакуума. Если увеличиваете количество воркеров автовакуума, увеличивайте значение autovacuum_vacuum_cost_limit примерно во столько же раз.

4. Реально ли сделать перенос, если мало опыта в 1С?

Существует два способа миграции стандартными средствами 1С. У каждого есть свои плюсы и минусы.

1. Миграция при помощи планов обмена. Этот способ дает возможность гибкой настройки, например: отфильтровывать данные, которые вы не хотите переносить, или переключаться на новую СУБД постепенно. Однако это трудозатратно, вы не сможете обойтись без квалифицированного программиста 1С.

2. Выгрузка-загрузка дампа базы в .dt-файл.

   Более простой метод миграции:

   • вам не потребуется разработчик 1С;
   • но нужна пауза в работе на время переноса базы.

Сравнили два способа миграции, зеленым выделили преимущества

Соответственно, если опыта мало, мы рекомендуем второй способ. Ниже разберем его подробнее.

5. Можно ли сотрудникам продолжать работу во время миграции?

Во время выгрузки база должна быть открыта в монопольном режиме. Работа пользователей или фоновые задания будут мешать процессу и завершат выгрузку дампа ошибкой. При многопоточной загрузке дампа в Postgres конфликт блокировок также даст ошибку загрузки. Подробно об этом можно прочитать здесь.

НО! Эти ограничения можно обойти при помощи штатной консольной утилиты ibcmd, которая создана для автономного управления сервером. Утилита существует как для Windows, так и для Linux, работает с СУБД напрямую, что значительно ускоряет процесс выгрузки и загрузки дампов. Дамп можно выгружать даже при работающих пользователях. Поэтому утилиту также используют для создания тестовых копий базы или для какой-нибудь отладки.

При использовании утилиты для миграции лучше отключать базу от сервера приложений, чтобы сохранить консистентность данных. Утилита устанавливается в папку \bin вместе c сервером 1С:Предприятие.

Подробные инструкции для ibcmd мы повторять не будем, их можно прочитать в этом руководстве.

6. Расскажите про миграцию БД по шагам

В нашем случае мы говорим про версию 1С:Предприятие 8.3.18.1334. Это важный момент, поскольку следующие версии имеют другой синтаксис.

Для начала вам понадобятся:

• Установленный сервер 1С:Предприятие 8.3.18.1334. Службу сервера запускать не нужно, нам нужна только утилита. Чем ближе к утилите вы расположите СУБД, тем быстрее будет происходить выгрузка и загрузка.
• Учетная запись к базе на сервере MS SQL.
• Учетная запись к серверу Postgres c правами SuperUser.

Шаг 1. Отключаем базу от сервера приложения, чтобы исключить изменения в базе во время выгрузки дампа.

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

Альтернативным решением можно запретить на стороне СУБД подключение к базе пользователя, под которым сервер приложения цепляется к базе.

Шаг 2. Переходим непосредственно к выгрузке базы в dt.

Запускаем ibcmd в режиме infobase и указываем:

• тип СУБД – в нашем случае это MS SQL;
• сетевое имя сервера и IP-адрес;
• имя базы на SQL;
• логин и пароль на SQL;
• команду для выгрузки dump;
• путь, куда будет выгружаться база.

Все вместе:

Ibcmd.exe infobase --dbms=MSSQLServer --db-Server=ИмяСервераSQL --db-name=ИмяБазыНаSQL --db-user=ПользовательSQL --db-pwd=ПарольSQL dump \\ПапкаДляВыгрузки\ИмяФайла.dt

Шаг 3.

Теперь загружаем.

Создаем базу на сервере Postgres и загружаем в нее дамп. Запускаем ibcmd в режиме infobase create. Указываем:

• тип СУБД – теперь это PostgreSQL;
• сетевое имя сервера;
• имя базы – как она будет называться на сервере;
• логин, пароль;
• команду create-database, которая создает СУБД, если ее нет;
• команду restore – указывает на файл дампа, который надо развернуть.

Ibcmd infobase create --dbms=PostgreSQL --db-server=ИмяСервераPostgres --db-name=ИмяБазыНаPostgres --db-user=ПользовательPostgres --db-pwd=ПарольPostgres --create-database --restore=\\ПапкаДляВыгрузки\ИмяФайла.dt

Шаг 4. По окончании загрузки регистрируем на кластере 1С развернутую базу.

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

Теперь можно считать нашу базу смигрированной.

7. А можно этот процесс упаковать в скрипт?

Поскольку утилита Ibcmd является консольной, все шаги выгрузки и загрузки дампа можно собрать в один скрипт. Ниже на скриншоте вы видите работу такого скрипта для загрузки базы 30 Гб.

Как видим, на процедуру ушло 17 минут

Если вы используете для управления сервером 1С Remote admin server, то шаги с удалением и регистрацией базы на кластере можно также упаковать в скрипт.

8. Как сравнить производительность MS SQL и PostgreSQL после миграции?

На слайде ниже показана конфигурация нашего стенда: RDP, кластер 1С из двух нод и сервер СУБД. Сервер MS SQL и PostgreSQL имеют одинаковые характеристики.

У нас был классический стенд из трех звеньев

Для сравнения использовали два теста.

1. Синтетический многопоточный тест производительности Fragster. Он создает множество фоновых сеансов и выполняет с их помощью операции с различными объектами базы.

Как видно из результатов, PostgreSQL проигрывает в работе с временными таблицами, однако показывает лучшую производительность при работе с объектами, что суммарно дает одинаковую производительность с 1С.

2. Тест по методике APDEX – симулирует работу пользователей 1С:Бухгалтерия типовой конфигурации. Здесь мы запускали одновременно 70 клиентов в тестовой базе, и каждый клиент проводил 500 операций, выбираемых из списка рандомно.

9. Какие инструменты администрирования в PostgreSQL аналогичны инструментам MS SQL?

• Резервное копирование. Аналогом встроенного средства MS SQL в Postgres является pg_basebackup + WAL (лог предварительной записи) archiving или pg_probackup. Централизованные решения РК, например, Commvault или Veeam B&R, поддерживают как MS SQL, так и Postgres. Из OpenSource решений используется Bareos.
• Репликация. В Postgres также есть встроенные средства. Для управления отказоустойчивостью можно использовать Patroni. Он позволит управлять кластером, добавлять новые реплики, производить автоматические контролируемые и аварийные переключения.
• Мониторинг. Здесь ничего не меняется: для алертинга и сбора также продолжаем использовать Zabbix, Nagios, Prometheus, VictoriaMetrics.
• Анализ. Используются встроенные средства, такие как log_statements и System View, и дополнительно можно использовать расширение pg_profile.

10. А как обстоят дела с HA? Раньше мы использовали MS SQL AlwaysOn

В PostgreSQL есть встроенная поддержка потоковой репликации. Архитектура этого процесса схожа с реализацией в MS SQL. В обеих СУБД репликация использует журналы транзакций, которые накатываются отдельными фоновыми процессами. В случае с Postgres для этого используются WAL sender, отправляющий изменения на реплику, и процесс WAL receiver, получающий данные.

Ключевым отличием от технологии AlwaysON в MS SQL является встроенная поддержка виртуального адреса (VIP) – listener в терминологии MS SQL AlwaysON. Она дает возможность “бегать” за главной репликой и тем самым позволяет клиентским приложениям быть подключенными к одному IP-адресу. В MS SQL это реализовано благодаря тесной интеграции со встроенной в Windows Server реализацией Failover Clustering (WSFC) – ставится как отдельный feature. Именно WSFC управляет сетевым стеком в данном случае и отвечает за переключение реплики с одного узла кластера на другой.

В случае Postgres VIP реализуется сторонними инструментами и решениями, например, pacemaker. Он, как и в случае с WSFC в Windows Server, управляет VIP и контролирует его по некоторым базовым метрикам.

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

11. Как изменятся механизмы бэкапа и репликации после переезда с MS SQL на PostgreSQL?

Особенности резервного копирования и восстановления для PostgreSQL продиктованы его архитектурой. Что важно понимать?

1. Есть несколько вариантов реализации РК:

   • дамп базы;
   • бэкап кластера (в терминологии MS SQL — бэкап инстанса).

   Дамп не позволяет восстановиться к конкретному времени, поэтому для бизнес-систем, с точки зрения RTO/RPO, не применим.

2. Встроенные средства Postgres позволяют создавать полный бэкап и бэкап WAL. Таким образом, восстановиться можно на заданную точку (Point-in-time-Recovery – PITR). Дифференциальные копии отсутствуют.
3. В Postgres выполняется бэкап всей директории с данными. Нет возможности указать конкретную базу для бэкапа. Это же касается и папки с WAL-файлами: она одна на весь кластер/инстанс. Таким образом, процедура и восстановление выполняется для всей инсталляции целиком.

12. Стоит разносить WAL и файлы базы на отдельные дисковые группы, если они на SSD?

Все зависит от многих факторов, например:

• это локальные диски на сервере или выделенная СХД, на которой запущены другие ресурсоемкие процессы;
• какая нагрузка ожидается в части Read/Write? Возможно, речь идет о постоянном чтении, при котором использование WAL минимально, и будет нелогичным выделение отдельного дискового пула для WAL.

Мы поделились ответами лишь на самые основные вопросы, возникающие при подготовке к переносу 1С на PostgreSQL. Если у вас есть другие вопросы или проблемы, обращайтесь! Расскажем-покажем, чем сможем – поможем. Удачи!

PostgreSQL для всех | Coursera

Чему вы научитесь

• Использование команд psql и SQL для реализации операций CRUD (создание, чтение, обновление и удаление) для таблиц в базе данных PostgreSQL.

• Определение и использование функций первичных, логических и внешних ключей в базе данных.

• Создавайте и различайте отношения «один ко многим» и «многие ко многим» в PostgreSQL.

• Вспомнить ключевых людей, организации и инновации, которые сыграли важную роль в создании стандарта SQL

---

Навыки. для использования базы данных PostgreSQL и изучения тем, начиная от дизайна базы данных и заканчивая ее архитектурой и развертыванием. Вы также сравните подходы SQL и NoSQL к проектированию баз данных. Навыки, полученные в этом курсе, будут полезны учащимся, занимающимся интеллектуальным анализом данных или разработкой приложений.

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

Совместно используемый сертификат

Совместно используемый сертификат

Получите сертификат по завершении

100 % онлайн-курсы

100 % онлайн-курсы

Начните немедленно и учитесь по собственному графику.

Coursera Labs

Coursera Labs

Включает практические учебные проекты.

Узнайте больше о Coursera Labs Внешняя ссылкаГибкое расписание

Гибкое расписание

Устанавливайте и соблюдайте гибкие сроки.

Промежуточный уровень

Промежуточный уровень

Часов для завершения

Приблизительно 4 месяца для завершения

Рекомендуемый темп 3 часа в неделю

Доступные языки

Английский

Субтитры: английский

Общий сертификат

Общий сертификат

Получите сертификат по завершении

100% онлайн-курсы

100% онлайн-курсы

Начните сразу и учитесь по собственному графику.

Coursera Labs

Coursera Labs

Включает практические учебные проекты.

Узнайте больше о Coursera Labs Внешняя ссылкаГибкое расписание

Гибкое расписание

Устанавливайте и соблюдайте гибкие сроки.

Средний уровень

Средний уровень

Часов для завершения

Приблизительно 4 месяца для завершения

Рекомендуемый темп 3 часа в неделю

Доступные языки

Английский

Субтитры: английский

Как работает специализация

Пройти курсы

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

Практический проект

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

Получение сертификата

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

Instructor

Charles Russell Severance

Clinical Professor

School of Information

3,778,611 Learners

56 Courses

Offered by

University of Michigan

The mission of the University of Мичиган должен служить народу Мичигана и всего мира благодаря превосходству в создании, общении, сохранении и применении знаний, искусства и академических ценностей, а также в развитии лидеров и граждан, которые бросят вызов настоящему и обогатят будущее.

Часто задаваемые вопросы

Есть еще вопросы? Посетите Справочный центр для учащихся.

pgAdmin — PostgreSQL Tools

Все видео

Настройка pgAgent

Автор: Khushboo Vashi, дата: 21 марта 2023 г.

сценарии и задачи SQL по сложным расписаниям, которыми можно управлять с помощью pgAdmin.
 
pgAgent поставляется как отдельное приложение. Этот блог предназначен для пользователей/разработчиков, которые хотят строить из исходников. Большинству пользователей следует использовать готовые пакеты из репозиториев PostgreSQL APT/YUM или StackBuilder.

Подробнее

pgAdmin с Kerberos и Active Directory

Автор: Khushboo Voshi, дата: 21 марта 2023 г. Kerberos — популярный метод проверки подлинности, но многим людям трудно его настроить, особенно в случае с Windows Active Directory. В этом блоге я расскажу о том, как настроить Kerberos с помощью pgAdmin и Active Directory.

Подробнее

Усовершенствования OAuth3 в pgAdmin

Автор: Khushboo Voshi, дата: 3 февраля 2023 г. Мы добавили поддержку OAuth3 в июле 2021 года. После этого команда разработчиков расширила функциональность OAuth3.

Подробнее

Все сообщения в блоге

09.03.2023 — pgAdmin 4 v6.21 Release

Команда разработчиков pgAdmin рада представить pgAdmin 4 версии 6.21. Этот выпуск pgAdmin 4 включает 19 исправлений ошибок и новые функции. Дополнительные сведения см. в примечаниях к выпуску.

Примечание:

Это последний выпуск pgAdmin, поддерживающий Python 3.6 и Psycopg2. Для будущих выпусков потребуется Python 3.7 или более поздней версии. Это означает, что это также последний выпуск, который будет поддерживаться в CentOS и RHEL 7.x

Заметные изменения в этом выпуске включают:

Особенности:

• Разрешить изменение обозначения количества элементов в ERD для использования обозначения Чена.
• Добавить дополнительное журналирование для успешных входов в систему и создания пользователей.

Ошибки/обслуживание:

• Исправлена ​​ошибка, из-за которой pgAdmin не мог подключиться, когда пароль Postgres содержал специальные символы.
• Убедитесь, что миграция базы данных не завершается ошибкой NoSuchTableError.
• Исправлена ​​ошибка, из-за которой сервер базы данных не подключался с помощью служебного файла.
• Обработка операции MERGE в объяснении инструмента запросов, представленного в PostgreSQL 15.
• Убедитесь, что инструмент сравнения схем улавливает изменения в предоставленных столбцах.
• Убедитесь, что разрешение «Предоставить столбец» для представления отображается на вкладке SQL.
• Убедитесь, что содержимое на панели сравнения DDL должно обновляться при выборе объекта с помощью клавиш со стрелками вверх и вниз.
• Исправлена ​​ошибка, из-за которой пользователь не мог создать триггер ПОСЛЕ ОБНОВЛЕНИЯ.
• Не разрешать сохранять неверный JSON в редакторе JSON инструмента запросов.

Загрузите копию прямо сейчас!

2023-02-09 — Выпущен pgAdmin 4 v6.20

Команда разработчиков pgAdmin рада представить pgAdmin 4 версии 6.20. Этот выпуск pgAdmin 4 включает 18 исправлений ошибок и новые функции. Дополнительные сведения см. в примечаниях к выпуску.

Примечание:

Хотя pgAdmin 4 формально не поддерживает понижение версии, обычно это работает, если вы удалите, а затем переустановите приложение. В этом выпуске pgAdmin внесены серьезные изменения в структуру базы данных конфигурации, которые НЕ являются обратно совместимыми, поэтому простой переход на более раннюю версию невозможен. Если вы используете базу данных SQLite по умолчанию для своей конфигурации (как и в случае подавляющего большинства пользователей), старая версия базы данных конфигурации будет сохранена в «pgadmin4.db.prev.bak» в вашем каталоге хранилища. . Если вы хотите перейти на pgAdmin v6.19или ранее, после запуска v6.20, вы должны восстановить этот файл в «pgadmin4. db» в том же каталоге, ПЕРЕД повторным запуском старой версии pgAdmin. Если вы храните свою конфигурацию во внешней базе данных PostgreSQL, вам потребуется восстановить резервную копию этой базы данных, сделанную до обновления до версии 6.20, если вы хотите вернуться к более ранней версии. Изменения, сделанные после миграции, такие как добавление новых серверов, не будут храниться в старой базе данных, и их придется создавать заново после перехода на более раннюю версию.

Заметные изменения в этом выпуске включают:

Особенности:

• Добавлена ​​поддержка настройки параметров соединения PostgreSQL.

С помощью этой функции пользователь может указать параметры подключения при подключении к серверу с помощью диалога сервера. В диалоговом окне сервера мы добавили новую вкладку «Параметры» и удалили вкладку «SSL». Вкладка «Параметры» теперь содержит все элементы управления вкладки SSL.

Ошибки/уборка:

• Используйте uplot для графиков Dashboard, чтобы снизить нагрузку на ЦП.
• Исправлена ​​ошибка, из-за которой местоположение сертификата клиента не сохранялось на общих серверах.
• Исправление бесхозных подключений к базам данных, приводящих к невозможности подключения к базам данных.
• Убедитесь, что системные столбцы не должны отображаться в данных импорта/экспорта.
• Увеличьте длину столбца значений таблицы настроек.
• Исправлена ​​ошибка, из-за которой перетаскивание имен объектов не работало.
• Исправлена ​​ошибка, из-за которой роль использовалась в качестве имени пользователя для вновь добавленных серверов при открытии инструмента запросов.
• Исправлена ​​ошибка, из-за которой история запросов не загружалась вместе с внешней базой данных.
• Исправить сбой интерфейса командной строки серверов импорта из-за исправления уязвимости

Загрузите копию прямо сейчас!

2023-01-17 — Выпущен pgAdmin 4 v6.19

Команда разработчиков pgAdmin рада представить pgAdmin 4 версии 6. 19. Этот выпуск pgAdmin 4 включает 20 исправлений ошибок и новые функции. Дополнительные сведения см. в примечаниях к выпуску.

Заметные изменения в этом выпуске включают:

Особенности:

• Добавлена ​​поддержка поставщика AWS для облачного развертывания BigAnimal.

Ошибки/обслуживание:

• Убедитесь, что пользователи, прошедшие проверку подлинности, не могут получить доступ к каталогам и файлам друг друга, указав относительные пути. (CVE-2023-0241).
• Разрешить добавление ссылок на демонстрационные видеоролики YouTube в соответствующую документацию pgAdmin.
• Исправлена ​​ошибка, из-за которой на общем сервере использовался неверный пароль.
• Убедитесь, что дерево браузера не зависает при рендеринге более 10 000 узлов/объектов.
• Исправлена ​​ошибка, из-за которой значение строки по умолчанию для столбцов должно заключаться в кавычки в сценарии создания.
• Исправлена ​​проблема с настройкой веб-сервера и внутренней аутентификации.
• Убедитесь, что пакет приложений имеет правильные разрешения, чтобы к pgAdmin могли получить доступ пользователи, отличные от владельца.
• Исправлена ​​отсутствующая ошибка «jwks_uri» в метаданных, возникающая при входе в систему с помощью поставщика oAuth3, такого как Azure или Google.
• Исправлена ​​ошибка, из-за которой средство просмотра геометрии не отображало всплывающее окно, если столбцов меньше 3.

Загрузите копию прямо сейчас!

20.12.2020 — Выпущен pgAdmin 4 v6.18

Команда разработчиков pgAdmin рада представить pgAdmin 4 версии 6.18. Этот выпуск pgAdmin 4 включает 13 исправлений ошибок и новые функции. Дополнительные сведения см. в примечаниях к выпуску.

Заметные изменения в этом выпуске включают:

Особенности:

• Добавлена ​​поддержка собственного меню в режиме рабочего стола.

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

• Усовершенствования ERD при выборе связи.

Ошибки/уборка:

• Исправлена ​​ошибка, из-за которой идентификаторы транзакций не были найдены в сеансе в инструменте запросов.
• Исправлена ​​ошибка, из-за которой табличное пространство отсутствовало в таблицах разделов в SQL.
• Исправлена ​​ошибка, из-за которой вкладка свойств обновлялась при смене вкладки, даже если выбран тот же узел.
• Исправлена ​​ошибка, из-за которой автозаполнение не работало должным образом с двойными кавычками.
• Убедитесь, что статистика таблицы отсортирована по размеру.
• Исправлена ​​ошибка, из-за которой при обновлении информации об узле сервера удалялось меню сброса сохраненного пароля.
• Исправлена ​​ошибка, из-за которой мастер-пароль не был правильно установлен для внешней базы данных конфигурации.
• Исправлена ​​ошибка в сценарии создания сортировки для PG-15.
• Исправлена ​​проблема с прерванной аутентификацией BigAnimal.

Загрузите копию прямо сейчас!

2022-12-02 — Выпущен pgAdmin 4 v6.17

Команда разработчиков pgAdmin рада представить pgAdmin 4 версии 6.17. Этот выпуск pgAdmin 4 включает 10 исправлений ошибок и новые функции. Дополнительные сведения см. в примечаниях к выпуску.

Выпуск системы безопасности

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

Эта проблема не затрагивает пользователей, работающих в режиме рабочего стола.

Заметные изменения в этом выпуске включают:

Ошибки/обслуживание:

• Убедитесь, что только авторизованные и аутентифицированные пользователи могут проверять двоичные пути (CVE-2022-4223).
• Обновите версию BigAnimal API до V2.
• Удалить все следы Backbone и Underscore.
• Исправлена ​​ошибка, из-за которой для внешнего ключа в инструменте сравнения схем отображалась неправильная схема.
• Убедитесь, что формат даты истории запросов в режиме рабочего стола соответствует формату локали сервера pgadmin.
• Исправлена ​​ошибка, из-за которой файл CSV не загружался, если длина символа цитаты CSV превышала 1.
• Убедитесь, что папки/файлы, зависящие от DATA_DIR, автоматически создаются внутри указанного DATA_DIR, если они не указаны отдельно в файле конфигурации.
• Исправлена ​​ошибка, из-за которой положение редактора было неправильным при редактировании данных из таблицы результатов.
• Убедитесь, что инструмент запросов успешно запущен для серверов, зарегистрированных в службе PostgreSQL.

Загрузите копию прямо сейчас!

21 сентября 2022 г. — Проект перемещен на GitHub

Проект pgAdmin теперь перемещен на GitHub!

Репозиторий исходного кода можно найти по адресу: https://github.com/pgadmin-org/pgadmin4.

Ошибки можно найти по адресу https://github.com/pgadmin-org/pgadmin4/issues. Все проблемы были перенесены со старых трекеров Redmine.

В нашей организации GitHub также есть ряд других репозиториев для pgAgent, веб-сайта и старых версий pgAdmin.

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

2022-07-11 — Опрос пользователей pgAdmin

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

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

https://forms.gle/62gzUPNbj4N1jNTB6

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

Спасибо!

12.07.2018 — Выпущен pgAgent v4.0.0

Команда разработчиков pgAdmin рада объявить о выпуске pgAgent v4.0.0.

pgAgent — планировщик заданий для PostgreSQL; для получения дополнительной информации см. документацию, входящую в состав документации pgAdmin, по адресу https://www.pgadmin.org/docs/pgadmin4/3.x/pgagent.html.

Загрузка (источник): https://www.pgadmin.org/download/pgagent-source-code/

Мы ожидаем, что в свое время пакеты DEB и RPM будут доступны в репозиториях PostgreSQL APT/YUM, а также обновленный установщик из EnterpriseDB, доступный через StackBuilder.