Не удалось получить стабильный набор строк в исходных таблицах оракула

Обновлено: 21.11.2024

Предположим, что необходимо создать резервную базу данных, исключающую некоторые подключаемые базы данных основной базы данных, например PDB не должны восстанавливаться во время создания резервной базы данных, и резервная база данных будет игнорировать любой повтор, связанный с ними.
Известно, что команда DUPLICATE этого не позволяет: Справочник по резервному копированию и восстановлению

Примечание: RMAN не поддерживает частичное дублирование PDB. Поэтому вы не можете использовать параметры SKIP TABLESPACE , TABLESPACE , SKIP PLUGGABLE DATABASE и PLUGGABLE DATABASE при создании резервной базы данных.

Пропустить табличные пространства подключаемых баз данных, которые не должны быть защищены Data Guard: можно использовать условие SKIP [FOREVER] TABLESPACE команды RESTORE
Перетащите исключенные файлы данных на резервный.
Установите параметр ENABLED_PDBS_ON_STANDBY, чтобы применять повтор только к определенным PDB.

Настройка

Основной и резервный

Основной

Имя хоста: servera
db_unique_name: orcla
имя_экземпляра: orcla1
Подключаемые базы данных: PDB1–3

В режиме ожидания

Имя хоста: serverb
db_unique_name: orclb
имя_экземпляра: orclb1
Подключаемая база данных: PDB1

Создание основного

Первичная база данных была создана с помощью следующей команды DBCA: Фактические выходные данные терминала: Созданы три подключаемые базы данных: PDB1-3 . PDB1 следует реплицировать как обычно. И PDB2, и PDB3 не должны быть доступны в режиме ожидания.

Создание режима ожидания

Добавление статической службы в прослушиватель

Я отредактировал /u01/app/19.3.0/grid/network/admin/listener.ora и добавил статическую регистрацию для моего резервного экземпляра:

Копирование файла паролей

Загрузка init.ora

Запуск резервного экземпляра

Восстановление резервного управляющего файла и подключение резервной базы данных

Восстановление резервной базы данных

Вот первичные файлы данных: Все файлы данных подключаемых баз данных PDB2 и PDB3 не должны восстанавливаться на резервном сайте, поэтому я хотел бы пропустить файлы данных 12-19.
Команда для восстановления резервной базы данных и ее вывод следующие: Видно, что файлы данных 12-19 не были восстановлены.

Обновление резервного управляющего файла

Удаление исключенных файлов данных

Создание конфигурации Data Guard

Выполнение тестов

Открытие резервной базы данных только для чтения

Давайте откроем резервную базу данных: в то время как PDB1 может быть открыта нормально, подключаемая база данных PDB2 не может быть открыта должным образом. Так же как и PDB3 .

Включение резервного восстановления:

Тестирование репликации Data Guard

Добавление новой подключаемой базы данных

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

Заключение

Oracle уже имеет достаточно функций для создания резервной базы данных, включающей в себя подмножество PDB основной базы данных. Хотя можно создать клон (не резервный), исключающий определенные PDB, с помощью команды DUPLICATE, предложение SKIP PLUGGABLE DATABASE нельзя использовать при дублировании для резервного. Вместо этого в этом сообщении в блоге предлагается альтернативное решение. Другой вариант — использовать Refreshable Clone PDB — их можно рассматривать как резервную замену с некоторыми ограничениями.

Сама ситуация напоминает мне функцию Snapshot Standby. Я использовал его еще до того, как Oracle представила эту функцию с большой суетой. В зависимости от требований клиентов Oracle может расширить DUPLICATE DATABASE FOR STANDBY, чтобы начать поддержку предложения SKIP PLUGGABLE DATABASE.

среда, 24 февраля 2021 г.

Предупреждение CHA CHA_DBWR_CKPT_IO_COMPLETE в OEM-производителе

Клиент получал следующие предупреждения от Oracle Enterprise Manager (OEM): я заметил в журнале предупреждений некоторые печально известные сообщения о незавершенных контрольных точках, поэтому я подозревал, что они могут быть реальной причиной.
Таким образом, я создал довольно маленькие лог-файлы размером 20 МБ: Затем я написал скрипт, который генерирует много повторов: Я запустил скрипт и вот выдержка из журнала предупреждений, показывающая сообщения о неполных контрольных точках: Вскоре после этого , я получил новое оповещение CHA в OEM-производителе:

CHA тесно интегрирован с репозиторием управления грид-инфраструктурой (GIMR). На самом деле, большинство команд chactl не могут работать без него. Однако я не использую GIMR, и кажется, что некоторые функции CHA все еще доступны, по крайней мере, часть из них, которые могут публиковать события, связанные с базой данных, в OEM.Это объясняется в следующем техническом документе: Oracle Database 12c Rel. 2 Cluster Health Advisor: подробное описание работы и использования

Заключение

Я не думаю, что сообщение, созданное предупреждением CHA_DBWR_CKPT_IO_COMPLETE, имеет подходящие решения:

Производительность контрольной точки БД на хосте rac1 База данных/кластер racdba Экземпляр racdba1. Советник по работоспособности кластера (CHA) обнаружил, что контрольные точки средства записи базы данных (DBW) выполняются медленно, поскольку для завершения записи в базу данных требуется больше времени, чем ожидалось. Увеличьте количество процессов DBWR. Добавьте дополнительные диски в группу дисков для базы данных. Переместите файлы базы данных на более быстрые диски или твердотельные устройства. Если подсистема хранения поддерживает кэш обратной записи хранилища, убедитесь, что кэш хранилища работает правильно.

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

При наличии предупреждений CHA в OEM имеет смысл проверить журнал CHA: /u01/app/grid/crsdata/rac1/trace/chad/ochad.trc.0 . В нем содержится бесценная информация, которая может точно указать причину.

вторник, 23 февраля 2021 г.

SU пропущен: более 1 столбца в состоянии подключения

Заключение

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

Различные возможности.
a) Корпорация Oracle поняла, что в этом шаблоне есть граничное условие, которое может привести к неправильным результатам и заблокировать преобразование (например, либо lastmoddate, либо lastmodtime объявлены не нулевыми - в противном случае невложенность должна быть недопустимой) < br />b) Корпорация Oracle изменила код оптимизатора, чтобы создавать более эффективные планы почти во всех случаях, но это изменение вводит определенные ограничения, которым теперь соответствует ваш SQL (например, даже если и lastmoddate, и lastmodetime, код теперь может предполагать, что to_char( ) или to_date() может создать нулевое значение из ненулевого.
c) Некоторое относительно простое изменение кода привело к ошибке

Несмотря на то, что, к сожалению, нет контроля исправлений или любого другого переключения на отмену, возвращающего старое поведение (насколько мне известно), Oracle фактически представила исправление для проблемы с неправильными результатами. Возможно, это меньшее из двух зол.
Скрипт для этого поста доступен в моем репозитории GitHub.

пятница, 12 февраля 2021 г.

Отслеживание блокировок библиотечного кэша с помощью _kgl_debug

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

Немного повозившись, я обнаружил, что фактическая трассировка блокировки библиотечного кэша управляется параметром _kgl_debug.

Вот небольшой пример кода, чтобы продемонстрировать это — я позаимствовал часть его из отличного сообщения в блоге Ненада: В двух словах, _kgl_debug=32, по-видимому, приводит к записи информации о блокировках библиотечного кэша в файл трассировки. Вот как это выглядит: Очень удобно, что данные трассировки предоставляются в формате XML — их легко разобрать: Выглядит хорошо. 275 строк во внешней таблице для 550 тегов KGLTRACE — это и открывающие, и закрывающие теги, поэтому количество строк точно соответствует количеству элементов XML в файле трассировки.

Наконец, мы можем получить информацию о вызовах kgllkal для интересных объектов:

Заключение

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

Обычный отказ от ответственности

Это сообщение в блоге является чистой спекуляцией. Хотя результаты могут быть разумными и наводящими на размышления, я понятия не имею, охватывает ли _kgl_debug=32 все или большинство блокировок библиотечного кэша.

Диагностика ошибок утилиты проверки кластера (CVU)

Выполнение команды утилиты проверки кластера (CVU) завершилось со следующей ошибкой: видно, что команда уже имела параметр verbose, который не давал никаких подсказок о причине ошибки.
В документации сказано, что CVU генерирует данные трассировки по умолчанию, если это не было отключено. Расположение файла трассировки по умолчанию — $ORACLE_BASE/crsdata/host_name/cvu . Расположение не по умолчанию можно указать с помощью переменной среды CV_TRACELOC.

Вот что я получил в вышеупомянутом каталоге: cvutrace.log.0 содержал фактические данные трассировки, в которых мое внимание привлекли следующие строки: Как видно из приведенного выше вывода, CVU вызвал kfod, который дал сбой. Таким образом, я решил запустить его сам и получил те же ошибки LRM: LRM вроде бы является менеджером параметров, но это еще не звоночек: kfod — это просто сценарий оболочки, который вызывает свой бинарный аналог kfod.bin аналогично тому, что делают многие другие утилиты Grid Infrastructure (GI).
Очевидно, что они взаимодействуют с операционной системой, поэтому мы можем отслеживать вызываемые системные вызовы. Вот что я сделал: в двух словах процесс открыл /u01/app/19.3.0/grid/dbs/init+ASM1.ora . Затем он перешел в /u01/app/19.3.0/grid/rdbms/mesg/kfodus.msb, который представляет собой двоичный файл сообщений. После этого он выводит ошибку KFOD на стандартный вывод.
Поэтому имело смысл проверить этот файл параметров: Стало очевидно, что файл параметров является основным виновником этих ошибок LRM: Чтобы убедиться в этом, я переименовал файл и успешно перезапустил команды kfod и cluvfy: не знаю, зачем был создан этот файл параметров, но это отличный пример того, как можно отлаживать инструменты Oracle.

суббота, 6 февраля 2021 г.

Использование функций SEHA в EE

Я установил базу данных не RAC Enterprise Edition 19.10 дома в своем кластере. Затем я создал новую базу данных в ACFS: Предположим, я хочу использовать в этой базе данных некоторые функции Standard Edition High Availability (SEHA): Как и ожидалось, srvctl запрещает такие операции. Однако проверка выпуска использует файл $ORACLE_HOME/lib/libedtn19.a, который я описал в следующем посте: Определение выпуска базы данных Oracle.
Оказывается, достаточно скопировать стандартную библиотеку, чтобы заставить эти команды srvctl работать: Мои ресурсы кластерного ПО перед выполнением команды relocate: Запуск relocate: Clusterware также перезапускает эту базу данных на рабочем узле, если узел был запустить не удается. Чтобы проверить это, я инициировал панику ядра на узле rac1, где работала моя база данных: через некоторое время база данных была запущена на другом узле: я не уверен в точных последствиях этого изменения библиотеки. Очевидно, что srvctl использует libedtn19.a, как было показано выше. Может ли это вызвать какие-то неблагоприятные последствия - я не знаю.

Очевидно, что такая конфигурация никак не поддерживается Oracle. Официально поддерживаемый способ их создания в средах, отличных от RAC, использует пользовательские ресурсы Clusterware, которые я лично считаю неуклюжими. Я бы хотел, чтобы эти функции SEHA были доступны в EE, но в настоящее время это не так.

среда, 3 февраля 2021 г.

Обновление таблицы без сохранения ключа

Раньше существовала подсказка BYPASS_UJVC, которая позволяла обновить таблицу без сохранения ключа. Он все еще там, но, должно быть, перестал работать примерно в 11.2. Оказывается, Oracle представила элемент управления исправлениями, который, похоже, делает то же самое в версии 19.10.

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

Я запустил таблицу_1, в которой есть данные, а также запустил внутренний запрос ( src ), в котором также есть данные.

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

7 ответов 7

Обычно это вызвано дубликатами в запросе, указанном в предложении USING. Вероятно, это означает, что TABLE_A является родительской таблицей и один и тот же ROWID возвращается несколько раз.

Вы можете быстро решить проблему, используя DISTINCT в своем запросе (на самом деле, если 'Y' является постоянным значением, вам даже не нужно указывать его в запросе).

Предполагая, что ваш запрос верен (не знаете свои таблицы), вы можете сделать что-то вроде этого:

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

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

+1, спасибо, это только что случилось со мной на целевой таблице с небольшим количеством дубликатов (по крайней мере, на основе ключей, используемых при слиянии).

Как устранить ошибки ORA-30926? (ID документа 471956.1)

1) Определите неверное утверждение

изменить набор событий сеанса ‘30926 имя трассировки errorstack level 3’;

изменить системный набор событий ‘30926 errorstack name трассировки выключен’;

и следите за файлами .trc в UDUMP, когда это происходит.

2) Найдя оператор SQL, проверьте его правильность (возможно, используя план объяснения или tkprof для проверки плана выполнения запроса) и проанализируйте или вычислите статистику по соответствующим таблицам, если это не было сделано в последнее время. Также может помочь перестроение (или удаление/воссоздание) индексов.

3.1) Является ли оператор SQL MERGE? оцените данные, возвращаемые предложением USING, чтобы убедиться, что в соединении нет повторяющихся значений. Измените оператор слияния, чтобы включить в него детерминированное предложение where

3.2) Является ли это оператором UPDATE через представление? Если это так, попробуйте заполнить результат представления в таблице и попробуйте обновить таблицу напрямую.

3.3) Есть ли на столе триггер? Попробуйте отключить его, чтобы убедиться, что он по-прежнему не работает.

3.4) Содержит ли инструкция не объединяемое представление в «IN-Subquery»? Это может привести к возврату повторяющихся строк, если в запросе есть предложение FOR UPDATE. См. ошибку 2681037

3.5) Есть ли в таблице неиспользуемые столбцы? Их удаление может предотвратить ошибку.

4) Если изменение SQL не устраняет ошибку, проблема может быть связана с таблицей, особенно если есть цепочки строк. 4.1) Запустите оператор «ANALYZE TABLE VALIDATE STRUCTURE CASCADE» для всех таблиц, используемых в SQL, чтобы увидеть, есть ли какие-либо повреждения в таблице или ее индексах. 4.2) Проверьте и устраните любые ЦЕПОЧНЫЕ или перенесенные ROWS в таблице. Есть способы свести это к минимуму, например правильная настройка PCTFREE. Используйте примечание 122020.1 — Цепочка строк и миграция 4.3) Если таблица дополнительно организована по индексу, см.: Примечание 102932.1 — Мониторинг связанных строк в IOT

Причина: не удалось получить стабильный набор строк из-за большой активности dml или недетерминированного предложения where.

Следующий вопрос был задан относительно SQL пользователя и его конфронтации с ORA-30926.

Если я удалю строки 7 и 15. SQL не будет проблемой.
Если я сначала запускаю подзапрос (строки 4-16), поместите результат в строку 3 в качестве предложения where. С SQL тоже проблем нет.

Ответчик Oracle предложил следующую информацию об ORA-30926:

ORA – 30926 Ошибка возникает, когда строки стабильного набора не найдены для большого действия dml или недетерминированного предложения Where.

Они также предложили пользователю попробовать написать "запрос, используя предложение where в 15-й строке, и обновить поток. Это может быть недетерминированным".

Бурлесон — американская команда

Примечание. Эта документация по Oracle была создана в качестве справочника по поддержке и обучению Oracle для использования нашими специалистами-консультантами по настройке производительности администраторов баз данных. Не стесняйтесь задавать вопросы на нашем форуме Oracle.

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

Ошибки? Технология Oracle меняется, и мы стараемся обновлять нашу информацию о поддержке BC Oracle. Если вы обнаружите ошибку или у вас есть предложение по улучшению нашего контента, мы будем признательны за ваш отзыв. Просто электронная почта:

и укажите URL-адрес страницы.

Burleson Consulting

Оракул поддержки баз данных

Таблица транзакций выдает одинаковое условие (т.е. общая строка предложения, а не любая) недоступна, что я могу сделать _+ в этом операторе слияния CORM_IRT_INV_RESOURCE_Tmp и PEG6_WRDT_RES_DTS_TMP (обе временные таблицы/таблицы транзакций).

отображается ошибка оракула - ORA-30926: невозможно получить стабильный набор строк в источнике

Я прошу обе таблицы использовать любую вещь, ДОСТУПНУЮ ИСПОЛЬЗОВАНИЕ в предложении

ДАЙТЕ МНЕ ЛЮБОЕ РЕШЕНИЕ

ОБЪЕДИНЕНИЕ В CORM_IRT_INV_RESOURCE_Tmp A
ИСПОЛЬЗОВАНИЕ (ВЫБЕРИТЕ ОТЛИЧНЫЕ * ИЗ PEG6_WRDT_RES_DTS_TMP) B
ON ( B.WRDT_GUID = A.IRT_GUID
AND B.WRDT_DOCUMENT_NO = A.IRT_ORDER_NO < br />И B.WRDT_DOCUMENT_OU = A.IRT_ORDER_OU
И B.WRDT_REF_LINE_NO = A.IRT_REF_LINE_NO
И B.WRDT_TASK_LINE_NO = A.IRT_LINE_NO
И B.WRDT_RESOURCE_NO = A.IRT_RESOURCE_CODE
>И B.WRDT_RES_TYPE = A.IRT_RESOUCE_TYPE
И A.IRT_GUID = v_Guid_Tmp
И A.IRT_ORDER_NO = v_cusorderno_Tmp
И A.IRT_ORDER_OU = v_COrderOU_Tmp)
КОГДА СООТВЕТСТВУЕТ, ТОГДА ОБНОВЛЯЕТ НАБОР A .IRT_NORMALRATE_PERHR = B.WRDT_RATE_PER_HR,
A.IRT_OTRATE_PERHR = B.WRDT_OVERTIME_RATE_PER_HR,
A.irt_facilityrate_perhr = b.wrdt_std_fac_rate,
A.irt_resource_price = --sqlserver_utilities.round_(NVL(HR_,BILLNOABLE0) ) * NVL(B.WRDT_RATE_PER_HR, 0), v_pamt_tmp) + sqlserver_utilities.round_(NVL(IRT_BILLABLE_HR_OT, 0) * NVL(B.WRDT_OVERTIME_RATE_PER_HR, 0), v_pamt_tmp),
раунд(NVL(IRT_BILLABLE_HR_NO, 0) * NVL(B.WRDT_RATE_PER_HR, 0), v_pamt_tmp) + round(NVL(IRT_BILLABLE_HR_OT, 0) * NVL(B.WRDT_OVERTIME_RATE_PER_HR, 0) , v_pamt_tmp),
A.IRT_SERVICE_PRICELIST = B.WRDT_SER_PRLIST,
A.IRT_REVISION_NO = B.WRDT_SER_PRL_REVNO,
A.IRT_EFFECTIVE_TILLDATE = B.WRDT_SER_PRL_EFF_DATE,
A.IRT_BILLABLE_MISCPRICE = B.WRDT_BILLABLE_MISCPRICE wrdt_misc_cost;
ИСКЛЮЧЕНИЕ, КОГДА ДРУГИЕ ЗАТЕМ НОЛЬ;*/

Отредактировано: 956403, 21 февраля 2013 г., 5:55

Лучший ответ

Я воспроизвел ваш пример в «Согласовано», это выглядит сомнительно. По крайней мере, я не могу найти никакого разумного объяснения.

Кто-то сообщил о чем-то похожем в ошибке 8923964. Нет общедоступных подробностей, поэтому актуальность неизвестна.

Но, возможно, стоит обратиться в службу поддержки Oracle. Если, конечно, другие участники не придумают разумное объяснение.

Ответы

Добро пожаловать на форум!

Из документа

ORA-30926: невозможно получить стабильный набор строк в исходных таблицах

Причина: не удалось получить стабильный набор строк из-за большой активности dml
или недетерминированного предложения where.

Действие: удалите все недетерминированные операторы where и повторно выпустите dml.

Эта ошибка возникает, когда запрос в предложении using возвращает более одной строки для условия соединения
в предложении on.

Следующий пример демонстрирует это.
поможет вам лучше задавать вопросы на этом форуме. Пожалуйста, прочтите.

Клиенты Reactive SQL имеют простой API, ориентированный на масштабируемость и низкие накладные расходы. В настоящее время поддерживаются следующие серверы баз данных:

Майкрософт SQL Server

Клиент Reactive SQL для Oracle считается предварительной версией.

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

В этом руководстве вы узнаете, как реализовать простое приложение CRUD, предоставляющее доступ к данным, хранящимся в PostgreSQL, через RESTful API.

Имена классов расширений и пулов соединений для каждого клиента можно найти внизу этого документа.

Если вы не знакомы с расширением Quarkus Vert.x, рекомендуем сначала прочитать руководство Использование Eclipse Vert.x.

Приложение должно управлять фруктовыми объектами:

Нужен ли вам готовый сервер PostgreSQL, чтобы опробовать примеры?

Установка

Расширение реактивного клиента PostgreSQL

Во-первых, убедитесь, что в вашем проекте включено расширение quarkus-reactive-pg-client. Если вы создаете новый проект, используйте следующую команду:

Чтобы создать проект Gradle, добавьте параметр --gradle или --gradle-kotlin-dsl.

Дополнительную информацию об установке и использовании Quarkus CLI см. в руководстве Quarkus CLI.

Чтобы создать проект Gradle, добавьте параметр -DbuildTool=gradle или -DbuildTool=gradle-kotlin-dsl.

Если у вас есть уже созданный проект, расширение reactive-pg-client можно добавить в существующий проект Quarkus с помощью команды add-extension:

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

Мятеж

Реактивные конечные точки REST в вашем приложении, которые возвращают Uni или Multi, нуждаются в поддержке Mutiny для правильной работы расширения RESTEasy ( io.quarkus:quarkus-resteasy-mutiny ):

В этом руководстве мы будем использовать Mutiny API клиента Reactive PostgreSQL. Если вы не знакомы с Mutiny, посмотрите Mutiny — интуитивно понятную библиотеку реактивного программирования.

Привязка JSON

Если вы предпочитаете не использовать командную строку, вручную добавьте зависимость в файл сборки:

Конечно, это требование только для данного руководства, а не для любого приложения, использующего Reactive PostgreSQL Client.

Настройка

Reactive PostgreSQL Client можно настроить со стандартными свойствами источника данных Quarkus и реактивным URL-адресом:

При этом вы можете создать свой скелет FruitResource и @Inject экземпляр io.vertx.mutiny.pgclient.PgPool:

Схема базы данных и исходные данные

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

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

Вы можете переопределить значение свойства myapp.schema.create по умолчанию в файле application.properties.

Почти готов! Для инициализации БД в режиме разработки воспользуемся методом клиентского простого запроса.Он возвращает Uni и, таким образом, может быть составлен для последовательного выполнения запросов:

Интересно, зачем нам блокировка до завершения последнего запроса? Этот код является частью метода @PostConstruct, и Quarkus вызывает его синхронно. Как следствие, преждевременный возврат может привести к обслуживанию запросов, когда база данных еще не готова.

Вот оно! До сих пор мы видели, как настроить клиент из пула и выполнять простые запросы. Теперь мы готовы разработать код управления данными и внедрить конечную точку RESTful.

Использование

Обход результатов запроса

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

Когда операция завершится, мы получим RowSet, в котором все строки буферизованы в памяти. RowSet — это java.lang.Iterable, поэтому его можно преобразовать в Multi :

В совокупности метод Fruit.findAll выглядит следующим образом:

И конечная точка для получения всех результатов от серверной части:

Теперь запустите Quarkus в режиме разработки с помощью:

Подготовленные запросы

Клиент Reactive PostgreSQL также может подготавливать запросы и принимать параметры, которые заменяются в операторе SQL во время выполнения:

Для PostgreSQL строка SQL может ссылаться на параметры по позиции, используя $1 , $2 , …и т. д. Информацию о других базах данных см. в разделе сведений о клиентах баз данных.

Подобно простому методу запроса, prepareQuery возвращает экземпляр PreparedQuery> . С помощью этого инструмента мы можем безопасно использовать идентификатор, предоставленный пользователем, для получения сведений о конкретном фрукте:

И в ресурсе JAX-RS:

1	Создайте кортеж для хранения подготовленных параметров запроса.
2	Получить итератор для результата RowSet.
3	Создать экземпляр Fruit из строки, если объект был найден.

1	Подготовьте ответ JAX-RS либо с экземпляром Fruit, если он найден, либо с кодом состояния 404.
2	Построить и отправить ответ.

Та же логика применяется при сохранении фруктов:

А в веб-ресурсе мы обрабатываем POST-запрос:

Метаданные результатов

Набор строк не только хранит данные в памяти, но и предоставляет некоторую информацию о самих данных, например:

количество строк, затронутых запросом (вставленных/удаленных/обновленных/полученных в зависимости от типа запроса),

имена столбцов.

Используем это для поддержки удаления фруктов из базы данных:

1	Проверить метаданные, чтобы определить, действительно ли фрукт был удален.

Благодаря реализованным методам GET , POST и DELETE мы теперь можем создать минимальную веб-страницу, чтобы опробовать приложение RESTful. Мы будем использовать jQuery для упрощения взаимодействия с серверной частью:

В коде Javascript нам нужна функция для обновления списка фруктов, когда:

страница загружена или

добавлен фрукт или

фрукт удален.

1	Параметр fruit не определен, когда база данных пуста.

Сведения о клиентах базы данных

Майкрософт SQL Server

Транзакции

connection.begin() возвращает Uni

В следующем фрагменте показано, как выполнить две вставки в одной транзакции:

В этом примере транзакция автоматически фиксируется в случае успеха или откатывается в случае сбоя.

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

Работа с результатами пакетного запроса

Допустим, вы хотите обновить некоторые строки и вычислить общее количество затронутых строк. Вы должны проверить каждый RowSet :

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

Несколько источников данных

Клиенты реактивного SQL поддерживают определение нескольких источников данных.

Типичная конфигурация с несколькими источниками данных будет выглядеть следующим образом:

1	Источник данных по умолчанию — использование PostgreSQL.
2	Именованный источник данных, называемый дополнительный1 — с использованием PostgreSQL.
3	Именованный источник данных, называемый дополнительным2 — с использованием MySQL.

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

< td>Для именованного источника данных вы используете квалификатор CDI @ReactiveDataSource с именем источника данных в качестве его значения.

1	Внедрение клиента для источника данных по умолчанию не требует ничего особенного.
2

Подключения к сокету домена UNIX

Клиенты PostgreSQL и MariaDB/MySQL можно настроить для подключения к серверу через сокет домена UNIX.

Сначала убедитесь, что включена собственная поддержка транспорта.

Затем настройте URL-адрес подключения к базе данных.Этот шаг зависит от типа базы данных.

PostgreSQL

Пути сокетов домена PostgresSQL имеют следующую форму: /.s.PGSQL.

URL-адрес подключения к базе данных должен быть настроен таким образом, чтобы:

хост — это каталог в пути к сокету

порт — это порт в пути к сокету

Рассмотрите следующий путь сокета: /var/run/postgresql/.s.PGSQL.5432 .

В application.properties добавьте:

MariaDB/MySQL

URL-адрес подключения к базе данных должен быть настроен так, чтобы хост был путем к сокету.

Рассмотрите следующий путь к сокету: /var/run/mysqld/mysqld.sock .

В application.properties добавьте:

Тайм-аут простоя соединения в пуле

Для реактивных источников данных можно настроить время простоя (в миллисекундах). Это максимальное время, в течение которого соединение остается неиспользованным в пуле, прежде чем оно будет закрыто.

Читайте также: