Уникальная идентификация исходного процесса JDBC в базе данных Oracle - PullRequest
Новая
       7

Уникальная идентификация исходного процесса JDBC в базе данных Oracle

0 голосов
/ 30 апреля 2018

Мы разрабатываем микросервисы с использованием Java (Spring и Spring Boot), и доступ к нашей базе данных Oracle осуществляется через драйвер Oracle JDBC.

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

Есть ли способ изменить строку идентификации, чтобы она представляла четкую идентификацию исходного приложения / процесса?

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

Спасибо

Ответы [ 4 ]

0 голосов
/ 07 мая 2018

Спасибо всем за ваши предложения, Я перепробовал их все, и, к сожалению, они не сработали.

Вероятно, это связано с тем, что я использую Spring Data и пул соединений Hikari по умолчанию.

Потратив на это часы, окончательное решение было найдено здесь: Spring Boot 1.3.5 с Hikari Connection Pool не смог установить имя программы в v $ session 

spring:
  datasource:
    hikari:
      data-source-properties:
         v$session.program: AppName

Просто, без изменений кода, и это работает!

0 голосов
/ 30 апреля 2018

В зависимости от вашей версии Oracle, функция реализована в методе setEndToEndMetrics (устарело с 12.1 в пользу setClientInfo ()) или setClientInfo

Вот небольшой пример использования. Клиент (ваш сервис) после получения соединения (обычно из пула соединений) устанавливает свойства action, clientId и module

String[] metrics = new String[OracleConnection.END_TO_END_STATE_INDEX_MAX];
 metrics[OracleConnection.END_TO_END_ACTION_INDEX] = 'myAction1';
 metrics[OracleConnection.END_TO_END_CLIENTID_INDEX] = 'myClient';
 metrics[OracleConnection.END_TO_END_MODULE_INDEX] = 'myModule1';
 con.setEndToEndMetrics(metrics, (short) 0);

и сбрасывает их перед восстановлением соединения.

DBA может наблюдать настройку в V$SESSION с помощью следующего запроса 

select sid,  client_info, module, action from v$session

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

Три вещи, которые необходимо учитывать:

Это работает, только если все службы устанавливают определенную дисциплину при установке значений. При повторном использовании сеансов из пула соединений легко «унаследовать» неправильную настройку от предшествующей службы. Я бы рекомендовал реализовать это как аспект обработки ресурсов пула соединений.

Кроме того, версия Java, драйвер JDBC и сервер Oracle должны иметь совместимых версий , поэтому рекомендуется проверять функциональность простым скриптом.

Окончательно НЕ использовать для установки PL / SQL API (что естественно делает разработчик PL / SQL). Большая разница заключается в том, что PL / SQL API запускает обратную передачу в базу данных, а JDBC API - нет (значения отправляются при следующем запросе).

0 голосов
/ 01 мая 2018

Для свойства соединения JDBC "oracle.jdbc.v$session.process" можно установить (в качестве системного пропелла -D) значение, которое уникальным образом идентифицирует ваш микросервис и которое затем может быть получено в представлении V $ SESSION (столбец "process").

0 голосов
/ 30 апреля 2018

пользователей базы данных

Если вы называете пользователей Базы данных, используемых для подключения, такими как Микросервис, администратор БД должен иметь возможность сопоставлять соединения с микросервисами.

IP-адреса

Для базы данных соединение также содержит входящий IP-адрес. Используя таблицу ip-адресов для микросервисов, администратор баз данных может сопоставить соединения с микросервисом.

1009 * почтение * Для администратора баз данных может быть интересной работой по поиску неисправностей Программистов. Если отношения между программистами и администраторами баз данных будут гармонизированы, разговор может решить проблему, где они происходят (в коде). Если в ближайшее время гармонизация невозможна, решением может быть более подробный контракт или спецификация. Это выглядит как обходной путь. Ошибка в коде, давайте найдем ее в коде. Дисквалификация API

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

...