Что такое прослушиватель группы доступности?
Прослушиватель группы доступности ― это виртуальное сетевое имя (VNN), к которому могут подключаться клиенты, чтобы получить доступ к базе данных из первичной или вторичной реплики группы доступности Always On. Прослушиватель позволяет клиенту подключаться к реплике, не зная физического имени экземпляра SQL Server. Так как прослушиватель маршрутизирует трафик, строку подключения клиента не нужно изменять после отработки отказа.
Прослушиватель группы доступности состоит из службы доменных имен прослушивателя (DNS), обозначения порта прослушивателя, а также одного или нескольких IP-адресов. Для работы прослушивателя группы доступности поддерживается только протокол TCP. Имя DNS прослушивателя должно быть уникальным в домене и в NetBIOS. При создании прослушивателя он становится ресурсом кластера с соответствующим виртуальным сетевым именем (VNN), виртуальным IP-адресом (VIP) и зависимостью группы доступности. Клиент с помощью DNS разрешает VNN в несколько IP-адресов, а затем пытается подключаться по каждому адресу, пока запрос подключения не завершится успехом или не истечет время ожидания.
Если для одной или нескольких вторичных реплик для чтения настроена маршрутизация только для чтения, то клиентские соединения с прослушивателем с намерением чтения автоматически направляются во вторичную реплику для чтения.
В этой статье представлены общие сведения о прослушивателе группы доступности. Можно также настроить прослушиватель, а затем узнать, как подключиться к прослушивателю.
Параметры прослушивателя
Прослушиватель группы доступности использует следующие элементы:
Уникальное имя DNS
Оно известно также как имя виртуальной сети (VNN). Действуют правила именования Active Directory для DNS-имен узла. Дополнительные сведения см. в статье базы знаний Соглашения о наименовании в Active Directory для компьютеров, доменов, сайтов и подразделений .
Один или несколько виртуальных IP-адресов (VIP)
Виртуальные IP-адреса настраиваются для одной или нескольких подсетей, для которых группа доступности может выполнить отработку отказа.
Настройка IP-адресов
Для данного прослушивателя группы доступности IP-адрес может использовать протокол DHCP или один или несколько статических IP-адресов. Использование DHCP может привести к задержкам подключения во время отработки отказа, поэтому его не рекомендуется использовать в рабочих средах. Группы доступности, которые распространяются на несколько подсетей или используют конфигурации гибридной сети, должны использовать статический IP-адрес.
Порт прослушивателя
При настройке прослушивателя группы доступности необходимо назначить порт через SSMS. Для упрощения строки подключения клиента в качестве порта по умолчанию можно задать порт 1433. Это означает, что при использовании порта 1433 вам не понадобится включать номер порта в строку подключения приложения. Кроме того, поскольку каждый прослушиватель группы доступности будет иметь собственное имя виртуальной сети, каждый прослушиватель группы доступности, настроенный в одном кластере WSFC, может использовать один и тот же порт по умолчанию ― 1433.
Если для имен виртуальной сети прослушивателя группы доступности используется порт по умолчанию 1433, необходимо будет сделать так, чтобы никакая другая служба в узле кластера не использовала этот порт. В противном случае возникнет конфликт порта.
Если один из экземпляров SQL Server уже прослушивает TCP-порт 1433 через прослушиватель экземпляра и при этом на данном компьютере больше нет служб (включая дополнительные экземпляры SQL Server), прослушивающие порт 1433, это не приведет к конфликту порта с прослушивателем группы доступности. Обусловлено это тем, что прослушиватель группы доступности может совместно использовать один TCP-порт внутри одного процесса. Однако вы не должны настраивать несколько экземпляров SQL Server (параллельное использование) так, чтобы они прослушивали один порт, поскольку в этом случае одному из них не удастся прослушивать подключения.
Вы также можете назначить нестандартный порт прослушивателя группы доступности. Однако в этом случае при подключении к прослушивателю понадобится явно использовать целевой порт в строке подключения приложения. Кроме того, для этого порта придется создавать разрешение в брандмауэре.
Вы можете подключиться к прослушивателю, указав имя и порт (если не используется 1433). Таким портом может быть либо порт прослушивателя, либо базовый порт SQL Server, настроенный так, чтобы обеспечить прослушивание.
В следующих примерах демонстрируются некоторые функциональные возможности прослушивателя:
Настройка:
- IP-адрес, прослушиваемый SQL Server: 192.168.20.2
- Порт, который прослушивает SQL Server: 50254
- Настроенный IP-адрес прослушивателя: 192.168.20.15
- Настроенное имя прослушивателя: aglistener19
- Настроенный порт прослушивателя: 50123
sqlcmd -S 192.168.20.15,50123 1> sqlcmd -S aglistener19 sqlcmd -S aglistener19,50123 1> sqlcmd -S aglistener19,50254 1> Поведение клиентских подключений при отработке отказа
В случае отработки отказа группы доступности существующие постоянные подключения к группе доступности разрываются, при этом, чтобы продолжить работать с той же базой данных-источником или доступной только для чтения базой данных-получателем, клиент должен установить новое соединение. Пока на стороне сервера выполняется отработка отказа, связь с группой доступности может прерваться, что заставит клиентское приложение начать попытки установить новое подключение до тех пор, пока база данных-источник не будет переведена в режим «в сети».
Если группа доступности возвращается в режим «в сети» в то время, когда клиентское приложение пытается установить соединение, и до истечения времени ожидания подключения, то драйвер клиента может успешно выполнить одну из своих внутренних попыток установить соединение. В этом случае приложение не выдаст никакого сообщения об ошибке.
Дальнейшие действия
Теперь, когда вы знакомы с функциями прослушивателя группы доступности, создайте прослушиватель, а затем настройте приложение для подключения к прослушивателю. Вы также можете ознакомиться с различными стратегиями мониторинга группы доступности, чтобы обеспечить работоспособность группы доступности.
Дополнительные сведения о группах доступности см. в разделе Обзор групп доступности Always On (SQL Server).
Обратная связь
Были ли сведения на этой странице полезными?
Описание этапов запуска и остановки БД
Oracle рекомендует следующий порядок действий для запуска БД: запуск Database Control, запуск listener-а, запуск БД. Запуск БД также является составным процессом. При запуске более сложного окружения, такого как cluster system или любого другого управляемого Enterprise Manager Grid Control могут быть дополнительные этапы, однако для Single Instance архитектуры этой последовательности вполне достаточно.
Запуск и подключение к Database Control
Database Control это инстурмент для управления одной БД. Эта БД может быть кластеризирована и тогда для каждого экземпляра БД работающего с одинаковой домашней директорией ORACLE_HOME будет свой экземпляр Database Control. Этот инструмент написан на языках Perl и Java и доступен через браузер. Нет необходимости устанавливать JRE или интерпретатор Perl: они оба доступны в домашней директории Oracle и устанавливаются OUI. Все запросы к Database Control осуществляются с использованием протокола HTTPS. Единственная необходимая настройка это проверить доступность порта используемого для работы с Database Control. Настройка Database Control осуществляется в момент создания БД. Эта настройка содержит два важных блока информации: имя сервера и номер порта. Если возникнет необходимость изменить эти значения – необходимо перенастроить Database Control.
Для запуска Database Control необходимо запустить программу emctl, расположенную в папке $ORACLE_HOME/bin. Ниже перечислены команды для запуска, остановки и проверки состояния Database Control
emctl start dbconsole
emctl stop dbconsole
ecmtl status dbconsole
Для успешного выполнения этих команд должны быть установлены следующие системные переменные: PATH, ORACLE_HOME и ORACLE_SID. PATH используется операционной системой для поиска пути к программе emctl. ORACLE_HOME и ORACLE_SID используются для поиска командой emctl файлов конфигурации. Эти файлы расположены в трёх местах: папка ORACLE_HOME/sysman/config содержит общие настройки для всех экземпляров Database Control работающих с текущей домашней директорией Oracle. ORACLE_HOME/hostname_sid/sysman/config и ORACLE_HOME/oc4j/j2ee/ OC4J_DBConsole_ hostname_sid/config содержат дополнительные расширенные настройки для каждой БД(hostname – имя компьютера, sid – значение переменной ORACLE_SID).
На рисунке 3-3 показан результат выполнения команды запуска Database Control
Первая попытка запуска была неудачной так как не была установлена переменная ORACLE_SID. Без корректного значения этой переменной emctl не может найти необходимые файлы конфигурации (значение используется в названии папок). Команда проверки состояния ни что иное как запрос по адресу URL; доступность этого URL так же можно проверить в браузере
где hostname – это сетевое имя компьютера на котором запущен Database Control и port – это порт ответственный за входящие подключения. Если у вашего сервера несколько сетевых имён или несколько сетевых интерфейсов – можно использовть любой. Для определения порта можно использовать команду emctl либо посмотреть конфигурационный файл ORACLE_HOME/install/portlist.ini где указаны все порты настроенные OUI и DBCA. При незапущенном listener-е при подключении к Database Control вы увидите окно изображенное на рисунке 3-4.
Запуск listener-а БД
Listener – это процесс который следит за запросами к порту для подключения к базе данных. Запросы к БД (и весь остальной трафик после создания сессии) использует Oracle Net, закрытый протокол Oracle. Oracle Net – это прокотор который работает над любым низлежащим сетевым протоколом, обычно над TCP/IP. Управление listener-ом более детально расммотрим в главе 4, сейчас же рассмотрим как запустить listener. Это можно сделать двумя (в windows тремя) способами: используя программу lsnrctl, с помощью Database Control, запустить windows сервис.
Программа lsnrctl расположена в каталоге ORACLE_HOME/bin. Параметрами могут быть
lsnrctl start [listener name]
lsnrctl status [listener name]
Значение по умолчанию для названия listener-а — LISTENER и обычно так и называют. На рисунке 3-5 показан результат выполнения команды lsnrctl status при работающем listener-е
Обратите внимание на первую строчку – там указаны сетевое имя и порт listener-а, а также на пятую снизу строку, которая обозначает что listener будет принимать подключения для сервиса ocp11g который создан для экземпляра ocp11g. Это критически важная информация для подключения к БД. Если БД была успешна создана с помощью DBCA значит listener настроен и запущен. Если нет вы увидите другой ответ команды lsnrctl status, тогда используйте команду lsnrctl для запуска или нажмите кнопку START LISTENER в окне Database Control показанном на рисунке 3-4.
Запуск SQL *Plus
SQL *Plus — это простая клиент-серверная программа для запуска SQL команд. Единственный параметр который необходимо знать для запуска – это NOLOG. По умолчанию, SQL *Plus немедленно запрашивает имя и пароль пользователя и параметры подключения. Это корректно для обычных пользователей, но бессмысленно для DBA, так как база данных должна быть уже открыта. Для запуска SQL *Plus без подключения к БД используйте параметр /NOLOG
В результате выполнения команды вы подключитесь к командной строке SQL, откуда можно подключиться используя различные параметры.
Запуск и остановка БД
Если быть точным – нельзя запустить и остановить БД: только экземпляр может быть запущен и остановлен, а база данны может быть подключена, открыта, отключена и закрыта. Данные операции можно совершить с помощью SQL *Plus выполнив команды STARTUP и SHUTDOWN или используя Database Control. В Windows это можно сделать также с помощью управления сервисом созданным для экземпляра БД. Системный журнал содержит подробную информацию об этих операциях когда бы они не были вызваны. Запуск и остановка – очень важные операции, информация об их выполнении всегда записывается и они могут быть инициированы только пользователями с особым уровнем доступа.
Подключение с повышенными правами доступа
Обычный пользователь не может запустить или остановить БД – потому что он авторизуется используя словарь данных. Это логически невозможно поскольку в момент запуска словарь данных ещё не доступен. Таким образом для запуска необходимо подключаться к серверу используя механизм внешней авторизации: системная авторизация пользователя как члена группы Oracle, или авторизация с использованием файла паролей. Тип авторизации указывается при выполнении команды CONNECT. Ниже представлены различные комбинации команды CONNECT после подключения к серверу используя программу SQL *Plus с параметром /NOLOG
connect user/pwd[@connect_alias] as sysdba
connect user/pwd[@connect_alias] as sysoper
connect / as sysdba
connect / as sysoper
где user – имя пользователя, pwd – пароль, connect_alias – сетевой идентификатор (рассмотрим в главе 4). Первый пример использует авторизацию с помощью словаря данных, база данных должны быть открыта или команда вернёт ошибку. Любой пользователь после подключения к БД используя данный синтаксис не сможет выполнить команды запуска и остановки базы данных. Два следующих примеры указывают Oracle использовать авторизацию с помощью файла паролей. Последние команды используют авторизацию операционной системы: Oracle проверяет является ли текущий пользователь членом группы Oracle, и если проверка успешна – пользователь подключается к БД как SYSOPER или SYSDBA. Пользователь подключившийся к базе данных любым способом из последних четырёх может выполнить команды запуска и остановки БД вне зависимости от состояния базы данных – она может быть даже не создана на этом этапе.
Если Database Control обнаруживает запущенный listener – то он использует авторизацию через словарь данных или файл паролей (в зависимости от выбора пользователя – рисунок 3-6). Если же listener не запущен (рисунок 3-4) при нажатии на кнопку STARTUP Database Control запрашивает системные имя пользователя и пароль для подключения к серверу.
SYSOPER и SYSDBA
SYSOPER и SYSDBA – это уровни доступа с повышенными полномочиями. Они доступны только при системной авторизации или авторизации с помощью файла паролей. Уровень доступа SYSOPER может выполнять команды
ALTER DATABASE [MOUNT|OPEN|CLOSE|DISMOUNT]
ALTER [DATABASE|TABLESPACE][BEGIN|END] BACKUP
Уровень доступа SYSDBA также может выполнять эти команды, плюс возможность создавать БД, запускать неполное восстановление и давать полномочия SYSOPER и SYSDBA другим пользователям.
Вам может быть интерестно под каким пользователем вы подключаетесь к БД когда используется системная авторизация. Чтобы это выяснить, после подключения к базе данных выполните команду show user (эту команду можно вызвать набрав sho user – не стоит недооценивать сокращения, они могут ускорить время набора команд) – результат показан на рисунке 3-7.
Уровень доступа SYSDBA использует пользоватля SYS – суперпользователя в системе и владельца словаря данных. Уровень доступа SYSOPER подключается как пользователь PUBLIC. PUBLIC – не пользователь в нормальном смысле, это пользователь который используется для задач администрирования, но (по умолчанию) не может просматривать или изменять данные. Подключаться с данными уровнями доступа стоит только для выполнения задач, которые не могут быть выполнены обычными пользователями.
Запуск: NOMOUNT, MOUNT и OPEN
Необходимо помнить что экземпляр БД и база данных это два разных объекта которые могут существовать независимо друг от друга. Когда останавливается экземпляр БД то структуры в памяти и фоновые процессы перестают существовать, однако база данных (содержимое файлов) продолжает. В архитектуре RAC другие экземпляры могут продолжать работать с базой.
Процесс запуска базы данных разбит на шаги: вначале запускается экземпляр БД, затем база данных подключается (mount) и открывается (open) для использования. В любой момент времени база данных может быть в одном из следующих состояний
Когда база данных остановлена (SHUTDOWN) все файлы закрыты и экземпляр не существует. В отключенном состоянии (NOMOUNT) – экземпляр БД построен в памяти (SGA создана и фоновые процессы запущены согдасно файлу параметров), но база данных недоступна и может быть даже ещё не создана. В подключенном состоянии (MOUNT) экземпляр находит и читает файл контроля. В открытом состоянии (OPEN) все файлы найдены и открыты – т.е. база данных доступна для пользователей. Когды вы запускаете команду STARTUP – будут выполнены все шаги, однако команда может быть разбиты на этапы. Напирмер если файл контроля испорчен или копия недоступна – вы не сможете подключить базу данных. Однако вы можете запустить базу в неподключенном режиме (NOMOUNT) и восстановить файл контроля. Точно так же если у вас возникли проблемы с файлами данных или логовов, вы можете попробовать восстановить данные в MOUNT состоянии, перед тем как открывать БД.
Как же экземпляр находит файлы которые ему нужны на каждом из шагов? Начнём с NOMOUNT. Когда вы запускаете команду STARTUP, Oracle будет искать файл параметров в определённом порядке как отображено на рисунке 3-8.
Всего существует три пути и имени файла. На Unix подобных системах это
Во всех случаях – SID это имя экземпляра. Порядок поиска очень важен. Oracle будет использовать первый найденный файл вне зависимости от наличия остальных. Если ни одного файла не существует – экземпляр не будет запущен. В режиме NOMOUNT используются только файл параметров и системный журнал. Значения параметров из файла параметров используются для создания SGA в памяти и запуска фоновых процессов. В системный журнал записывается информация об этот процессе. Где находится системный журнал? Путь можно узнать посмотрев параметр BACKGROUND_DUMP_DEST в файле параметров или выполнив команду
sho parameter background_dump_dest
Если системный журнал существует во время выполнения команды STARTUP то новые данные будут добавляться, иначе будет созда новый файл. Если возникнут какие-либо проблемы во время выполнения команды – так же будут созданы файлы трассировки.
Когда экземпляр запущен в режиме NOMOUNT, переход в состояние MOUNT будет осуществляться путём чтения файла контроля. Oracle находит эти файлы используя параметр CONTROL_FILES, прочитанный во время запуска экземпляра. Если файл контроля (или хотя бы одна копия) не найдены или повреждены, база данных не будет подключена и вы обязаны восстановить их перед подключением. Все копии должны быть доступны и одинаковы для успешного подключения БД.
Как часть процесса подключения, все именя файлов данных и логов и пути к ним считываются из файла контроля, но Oracle просто запоминает эти значения, не пытаясь найти файлы. Поиск и чтение файлов происходит во время открытия базы данных (OPEN). Если какой-либо файл поврежден или отсутствует база данных останется в режиме MOUNT пока вы не исправите ошибки. Более того, все файлы должны быть синхронизированы перед тем как база данных будет открыта. Если последнее выключение было выполнено в определённом порядке, то все буферы из буфера кэша БД записаны на диск процессом DBWn и файлы синхронизированы, и Oracle будет знать при запуске что все подтверждённые транзакции сохранены в файлах данных и нет неподтвержденных транзакций ожидающих отмены. Если же последнее выключение было не запланированным (к примеру от потери питания или системной перезагрузке сервера без правильного выключения экземпляра) то Oracle должен синхроинизировать файлы данных и файлы логов (отменив неподтверждённые транзакции). Процесс который подключает и открывает БД (и синхронизирует данные) называется SMON. Только когда база данных успешно открыта будет возможно подключение пользователей. Процесс запуска графически представлен на рисунке 3-9.
Остановка процесс зеркальный запуску. Вначале закрывается БД (CLOSE), затем отключается (DISMOUNT) и далее останавливается экземпляр. Во время закрытия БД все сессии отключаются: текущие транзакции отменяются процессом PMON, подтверждённые транзакции записываются в файлы данных DBWn и файлы данных и логов закрываются. Во время отключения закрывается файл контроля. И экземпляр останавливается с освобождением памяти и остановкой фоновых процессов.
Выключение: NORMAL, TRANSACTIONAL, IMMEDIATE и ABORT
Существуют параметры которые используются с командой SHUTDOWN – вызов SHUTDOWN команды требует уровня доступа SYSDBA или SYSOPER
NORMAL: это значение по умолчанию. Новые подключения нельзя создать, но все текущие сессии могут работать до конца сессии. Когда все пользователю отключатся база данных будет выключена.
TRANSACTIONAL: новые подключения недоступны; существующие сессии которые не выполняют транзакции отключаются; сессии которые выполняют транзанкцию завершают транзакцию и отключаются. Когда все сессии будут отключены, база данных останавливается.
IMMEDIATE: новые подключения не разрешены. Все активные сессии отключаются. Все активные транзакции отменяются и база данных выключается.
ABORT: это эквивалент отключению питания. Экземпляр останавливается без записи чего либо на диск, закрытия файлов, отмены транзакций.
Параметры выключения «normal,» «immediate,» и «transactional» считаются «чистыми» выключениями (то есть выполненными в правильном порядке). После того как все сессии отключены, PMON отменяет все неподтверждённые транзакции. Создаётся контрольная точка процессом CKPT, которая заставляет DBWn записывать измененные данные из буфера кэша в файлы данных. LGWR записывает вектора изменений в файлы логов. Обновляются заголовки файлов и файлы закрываются. Это гарантирует что база в синхронизированном состоянии: все подверждённые транзакции в файлах данных и нет неподтверждённых транзакций требующих отмены.
Параметр “abort” оставляет базу данных в рассинхронизированном состоянии: возможно что подтверждённые транзакции не записаны в файлы данных, так как на момент выключения они были сохранены в памяти и DBWn не записал изменения из буфера в файлы. Также может быть и такое, что неподтверждённые транзакции записаны в файлы данных. Это определение испорченной БД: она содержит некорректные данные. Эти повреждения должны быть восстановлены используя instance recovery. Таким образом можно протестировать что произойдёт если к примерну непредвиденно обесточить сервер в процессе работы БД.
Так как выключение это пошаговый процесс, то возможно управлять этапами используя SQL *Plus и команды
alter database close;
alter database dismount;
Эти команды полная противоположность командам запуска. На практике SHUTDOWN это единственная команда которой пользуются DBA. Пошаговый процесс также недоступен из Database Control.
- Использование системного журнала (Alert Log) и файлов трассировки (Trace Files)
- Установка программ Oracle с использованием OUI
- Управление БД — Итоги
- Использование DBCA для создания БД
- Использование словаря данных и динамических представлений производительности
Настройка сети (Настройка слущающего процесса Listener)
2 конфигурационных файла отвечают за подключение к Oracle.
Один обязательный (listener.ora) и один скорее для удобства, но для работы некоторых программ, он также может быть обязательным (tnsnames.ora).
По умолчанию файлы хранятся:
listener.ora
LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = hostname.domain.com)(PORT = "port_number")) ) ) ) SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = SID1) (ORACLE_HOME = /u01/app/oracle/product/11.2) (SID_NAME = SID1) ) (SID_DESC = (GLOBAL_DBNAME = SID2) (ORACLE_HOME = /u01/app/oracle/product/11.2) (SID_NAME = SID2) ) ) tnsnames.ora
В данном файле описываются подробности подключения к базе данных. Т.о, становится возможным явно не указывать некоторые параметры. (Например, хост, порт и др.). И сразу обращаться по имени.
SID1 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = hostname.domain.com)(PORT = "port_number")) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = SID1) ) ) SID2 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = hostname.domain.com)(PORT = "port_number")) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = SID2) ) ) // Должен работать (Но это не точно) $ tnsping SID2 В следующем примере, происходит подключение к базе данных с использованием записи с именем orcl в файле tnsnames.ora.
Т.е. для подключения к базе, не приходится дополнительно вводить host, port, sid
Основные команды службы слушателя (Listener):
$ lsnrctl status $ lsnrctl stop $ lsnrctl start $ lsnrctl restart Информация о Listener из командной строки:
$ ps -edf | grep tns root 13 2 0 Aug09 ? 00:00:00 [netns] oracle12 6604 1 0 Aug09 ? 00:00:02 /u01/oracle/grid/12.1/bin/tnslsnr LISTENER -no_crs_notify -inherit oracle12 16991 14456 0 09:26 pts/1 00:00:00 grep tns $ lsnrctl services LSNRCTL for Linux: Version 12.1.0.2.0 - Production on 15-AUG-2015 15:09:04 Copyright (c) 1991, 2014, Oracle. All rights reserved. Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) Services Summary. Service "+ASM" has 1 instance(s). Instance "+ASM", status READY, has 1 handler(s) for this service. Handler(s): "DEDICATED" established:0 refused:0 state:ready LOCAL SERVER Service "orcl12XDB" has 1 instance(s). Instance "orcl12", status READY, has 1 handler(s) for this service. Handler(s): "D000" established:0 refused:0 current:0 max:1022 state:ready DISPATCHER (ADDRESS=(PROTOCOL=tcp)(HOST=piter.localdomain)(PORT=60254)) Service "slave" has 1 instance(s). Instance "orcl12", status READY, has 1 handler(s) for this service. Handler(s): "DEDICATED" established:0 refused:0 state:ready LOCAL SERVER Service "slave_DGB" has 1 instance(s). Instance "orcl12", status READY, has 1 handler(s) for this service. Handler(s): "DEDICATED" established:0 refused:0 state:ready LOCAL SERVER The command completed successfully Информация о Listener из консоли sqlplus:
SQL> show parameter local_listener; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ local_listener string LISTENER_ORCL12 SQL> show parameter listener NAME TYPE ------------------------------------ --------------------------------- VALUE ------------------------------ listener_networks string local_listener string remote_listener string SQL> alter system set local_listener='(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = moscow.localdomain)(PORT = 1521)))' scope=both; OFFTOPIC Listener для grid
$ srvctl status listener Listener LISTENER is enabled Listener LISTENER is running on node(s): piter $ srvctl config listener Name: LISTENER Type: Database Listener Home: /u01/oracle/grid/12.1 End points: TCP:1521 Listener is enabled. Способ настроить tnsnames, предложенный в чате:
connect / as sysdba alter session set container=pdb_a; alter system register; После этого она зарегается в листенере, если до этого её не было.
В tnsnames.ora: (ip адрес только поправь)
pdb_a = (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP) (HOST=10.1.1.14) (PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=pdb_a))) Tags: Oracle Database, Network, Listener
 |
 |
 |
Oracle DBA
Собираем также материалы по: SQL & PL/SQL
Лучше потратить какое-то количество времени, чтобы записать успешный опыт, чем потом повторно воспроизводить его по памяти.
Все материалы обновляются по мере нахождения лучших практик и апгрейда знаний. Если будут желающие добавлять свои знания или исправлять ошибки и неточности, пишите в телеграм чате. Если будет учавствовать больше людей, качество материалов будет улучшаться и обновляться быстрее. Ссылки на ваши профили в соц. сетях будут добавлены в статьях, в которых вы учавствуете.
Что такое листенер в бд
Entity Listeners предназначены для реакции на события жизненного цикла экземпляров сущностей на уровне Middleware.
Слушатель представляет собой класс, реализующий один или несколько интерфейсов пакета com.haulmont.cuba.core.listener . Слушатель будет реагировать на события типов, соответствующих реализуемым интерфейсам.
BeforeDetachEntityListener
Метод onBeforeDetach() вызывается перед отделением объекта от EntityManager при коммите транзакции.
Данный слушатель можно использовать, например, для заполнения неперсистентных атрибутов сущности перед отправкой ее на клиентский уровень.
BeforeAttachEntityListener
Метод onBeforeAttach() вызывается перед введением объекта в персистентный контекст при выполнении операции EntityManager.merge() .
Данный слушатель можно использовать, например, для заполнения персистентных атрибутов сущности перед сохранением ее в базе данных.
BeforeInsertEntityListener
Метод onBeforeInsert() вызывается перед выполнением вставки записи в БД. В данном методе возможны любые операции с текущим EntityManager .
Метод onAfterInsert() вызывается после выполнения вставки записи в БД, но до коммита транзакции. В данном методе нельзя модифицировать текущий персистентный контекст, однако можно производить изменения в БД с помощью QueryRunner.
Метод onBeforeUpdate() вызывается перед изменением записи в БД. В данном методе возможны любые операции с текущим EntityManager .
Метод onAfterUpdate() вызывается после изменения записи в БД, но до коммита транзакции. В данном методе нельзя модифицировать текущий персистентный контекст, однако можно производить изменения в БД с помощью QueryRunner .
Метод onBeforeDelete() вызывается перед удалением записи из БД (или в случае мягкого удаления — перед изменением записи). В данном методе возможны любые операции с текущим EntityManager .
Метод onAfterDelete() вызывается после удаления записи из БД (или в случае мягкого удаления — после изменения записи), но до коммита транзакции. В данном методе нельзя модифицировать текущий персистентный контекст, однако можно производить изменения в БД с помощью QueryRunner .
Entity Listener должен являться Spring-бином, поэтому в нем можно использовать инжекцию в поля и сеттеры. Для всех экземпляров некоторого класса сущности создается один экземпляр слушателя определенного типа, поэтому слушатель не должен иметь изменяемого состояния.
Следует иметь в виду, что для BeforeInsertEntityListener фреймворк гарантирует managed state только для корневой сущности, принимаемой слушателем. Ее ссылки, встречающиеся в графе объектов, могут быть в состоянии detached. Поэтому если вам необходимо изменять эти объекты, используйте метод EntityManager.merge() , а если только иметь возможность обращаться к любым их атрибутам, то метод EntityManager.find() . Например:
package com.company.sample.listener; import com.company.sample.core.DiscountCalculator; import com.company.sample.entity.*; import com.haulmont.cuba.core.EntityManager; import com.haulmont.cuba.core.listener.*; import org.springframework.stereotype.Component; import javax.inject.Inject; import java.math.BigDecimal; @Component("sample_OrderEntityListener") public class OrderEntityListener implements BeforeInsertEntityListener, BeforeUpdateEntityListener, BeforeDeleteEntityListener < @Inject private DiscountCalculator discountCalculator; // a managed bean of the middle tier @Override public void onBeforeInsert(Order entity, EntityManager entityManager) < calculateDiscount(entity.getCustomer(), entityManager); >@Override public void onBeforeUpdate(Order entity, EntityManager entityManager) < calculateDiscount(entity.getCustomer(), entityManager); >@Override public void onBeforeDelete(Order entity, EntityManager entityManager) < calculateDiscount(entity.getCustomer(), entityManager); >private void calculateDiscount(Customer customer, EntityManager entityManager) < if (customer == null) return; // Delegate calculation to a managed bean of the middle tier BigDecimal discount = discountCalculator.calculateDiscount(customer.getId()); // Merge customer instance because it comes to onBeforeInsert as part of another // entity's object graph and can be detached Customer managedCustomer = entityManager.merge(customer); // Set the discount for the customer. It will be saved on transaction commit. managedCustomer.setDiscount(discount); > >Все слушатели кроме BeforeAttachEntityListener выполняются внутри транзакции. Это значит, что если внутри слушателя выбрасывается исключение, текущая транзакция откатывается и все изменения в базе данных теряются.
Если вам необходимо выполнить некоторые действия после успешного завершения транзакции, используйте callback-интерфейс TransactionSynchronization фреймворка Spring для того чтобы отложить выполнение до нужной фазы транзакции. Например:
package com.company.sales.service; import com.company.sales.entity.Customer; import com.haulmont.cuba.core.EntityManager; import com.haulmont.cuba.core.listener.BeforeInsertEntityListener; import com.haulmont.cuba.core.listener.BeforeUpdateEntityListener; import org.springframework.stereotype.Component; import org.springframework.transaction.support.TransactionSynchronizationAdapter; import org.springframework.transaction.support.TransactionSynchronizationManager; @Component("sales_CustomerEntityListener") public class CustomerEntityListener implements BeforeInsertEntityListener, BeforeUpdateEntityListener < @Override public void onBeforeInsert(Customer entity, EntityManager entityManager) < printCustomer(entity); >@Override public void onBeforeUpdate(Customer entity, EntityManager entityManager) < printCustomer(entity); >private void printCustomer(Customer customer) < System.out.println("In transaction: " + customer); TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() < @Override public void afterCommit() < System.out.println("After transaction commit: " + customer); > >); > >Регистрация entity listeners
Entity Listener может быть задан двумя способами:
- Статически — имена бинов слушателей указываются в аннотации @Listeners на классе сущности:
@Entity(. ) @Table(. ) @Listeners("sample_MyEntityListener") public class MyEntity extends StandardEntity
package com.company.sample.core; import com.haulmont.cuba.core.global.Events; import com.haulmont.cuba.core.sys.events.AppContextInitializedEvent; import com.haulmont.cuba.core.sys.listener.EntityListenerManager; import com.haulmont.cuba.security.entity.User; import org.springframework.context.event.EventListener; import org.springframework.core.annotation.Order; import org.springframework.stereotype.Component; import javax.inject.Inject; @Component("sample_AppLifecycle") public class AppLifecycle < @Inject private EntityListenerManager entityListenerManager; @EventListener(AppContextInitializedEvent.class) // notify after AppContext is initialized @Order(Events.LOWEST_PLATFORM_PRECEDENCE + 100) // run after all framework listeners public void initEntityListeners() < entityListenerManager.addListener(User.class, "sample_UserEntityListener"); > >Если для сущности объявлены несколько слушателей одного типа (например, аннотациями класса сущности и его предков, плюс динамически), то их вызов будет выполняться в следующем порядке:
- Для каждого предка, начиная с самого дальнего, вызываются его динамически добавленные слушатели, затем статически назначенные.
- После всех предков вызываются динамически добавленные слушатели данного класса, затем статически назначенные.