Dblink oracle как посмотреть
Обновлено: 01.07.2024
В среде Linux база данных Oracle подключается к базе данных MySQL удаленно через DBLink.
1、Oracle
① Операционная система: Linux X86-64
② Версия базы данных: 11.2.0.4.0
③Набор символов: УПРОЩЕННЫЙ КИТАЙСКИЙ_КИТАЙA.AL32UTF8
2、MySQL
① Операционная система: Linux i686
②Версия базы данных: 5.7.21
③Набор символов: UTF8
1. Загрузите установочный пакет UnixODBC.
2. Установка
①Исполняется пользователем root
cd /usr/local
tar zxvf unixODBC-2.3.0.tar.gz
② Скомпилировать и установить
cd unixODBC-2.3.0/
./configure --prefix=/usr/local/unixODBC-2.3.0 --includedir=/usr/include --libdir=/usr/lib64 --bindir=/usr/bin --sysconfdir=/etc
make
make install
3. Тест
Выполните команду: odbcinst -j, если установка прошла успешно, отобразится:
Заголовочные файлы, необходимые для unixODBC, устанавливаются в / usr / inlucde, файлы скомпилированной библиотеки устанавливаются в / usr / lib64, исполняемые файлы, связанные с unixODBC, устанавливаются в / usr / bin, а файлы конфигурации помещаются в / etc под.
1. Загрузите файл
2. установка оборотов
3. Настройте файл odbc.ini.
4. Протестируйте odbc для подключения к MySQL.
Выполните команду: isql testdb -v // testdb - это содержимое в скобках в файле odbc.ini
odbc успешно подключился к MySQL!
1. Измените переменные среды
2. Настройте монитор Oracle.
①cd $ORACLE_HOME/network/admin
Официальный документ объясняет следующее:
②Изменить tnsnames.ora
Официальный документ объясняет следующее:
③ Настроить мониторинг ODBC
④Перезапустите конфигурацию тестового монитора.
Пользователь оракула выполняет:
Если отображается вышеуказанная информация, настройка мониторинга выполнена успешно!
3. Создайте DBLink.
①su - oracle
②select * from "a2"@myodbc1;
Причина: некоторое содержимое не отображается полностью, проверьте файл прослушивания odbc, проверьте параметр HS_LANGUAGE и настройте его в соответствии с набором символов базы данных.
Причина: типы данных NVARCHAR / NCHAR и graphics обычно хранят данные в формате Unicode. Набор символов Юникода варьируется от базы данных к базе данных, и HS_NLS_NCHAR = UCS2 необходимо изменить.
Причина: данные MySQL чувствительны к регистру, а таблицы необходимо заключать в двойные кавычки.
Ссылка базы данных dblink (ссылка на базу данных), как следует из названия, является ссылкой на базу данных. Когда мы хотим получить доступ к данным в другой таблице базы данных в локальной базе данных, мы должны создать dblink удаленной базы данных в локальной базе данных. • Через dblink локальная база данных может получить доступ к локальной базе данных. База данных получает доступ к данным в таблице удаленной базы данных. Короче говоря, это доступ к данным в таблице в другой базе данных в текущей базе данных.
2. Краткое описание dblinkКак создать
① Пройдено pl/sql developer Графическое создание
② Передать sql Создание заявления
создать ссылку на базу данных имя ссылки
подключиться к имени пользователя базы данных другой стороны, идентифицированному паролем пользователя базы данных другой стороны
using 'ORCL'
Примечания: ORCL - это имя базы данных, которое обычно настраивается в tnsnames.ora в папке C: \ DevSuiteHome1 \ network \ ADMIN.
③ Создано оператором sql (аналогично методу ②, но этот метод лучше, избегая локальной конфигурации)
создать ссылку на базу данных имя ссылки
подключиться к имени пользователя базы данных другой стороны, идентифицированному паролем пользователя базы данных другой стороны
using '(DESCRIPTION =(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP) (HOST = IP-адрес сервера, на котором расположена база данных, которая будет подключена) (PORT = 1521)))
(CONNECT_DATA =
(SERVICE_NAME = имя локальной службы подключаемой базы данных (то есть SID подключаемой базы данных)))) ';
Примечания: После использования содержимое файла tnsnames.ora находится в папке C: \ DevSuiteHome1 \ network \ ADMIN. Получается конкретное содержимое внутри, а не используемый псевдоним. Этот метод лучше, чем описанный выше, и не требует локальных имен tns. файл ora и поместите базу данных напрямую, что более гибко.
3. Подробная авторизация
① Сначала определите, есть ли у пользователя разрешение на создание dblink:
select * from user_sys_privs where privilege like upper('%DATABASE LINK%');
Разрешения для пользователя моих приложений:
объяснять:
CREATE PUBLIC DATABASE LINK: указывает, что все пользователи созданной dblink могут использовать
CREATE DATABASE LINK: указывает, что созданная dblink может использоваться только создателем, а другие пользователи не могут ее использовать
DROP PUBLIC DATABASE LINK: указывает, что всех пользователей созданной dblink можно удалить
② Если указанный пользователь не имеет нескольких вышеперечисленных разрешений, вам необходимо предоставить разрешения через пользователя sys (он действует как администратор и имеет большие разрешения). Вам необходимо войти в систему под пользователем sys и выполнить следующую инструкцию под sys пользователь:
grant CREATE PUBLIC DATABASE LINK , DROP PUBLIC DATABASE LINK to apps;
4. Некоторые рутинные операции.
1. Метод получения данных из подключенной базы данных после успешного подключения
выберите * from table_name (имя таблицы) @dblink (имя dblink);
Примечание: просто добавьте "@DBLINK name" после имени таблицы. .
2. Просмотрите все файлы в текущей базе данных. DBLINK Методы
3. Удалить указанный в текущей базе данных DBLINK Методы
① Если вы создаете общедоступный DBLINK, вам необходимо использовать его при удалении
Удалить ссылку на общедоступную базу данных dblink (имя dblink)
② Если вы создаете частный DBLINK, вам нужно использовать его при удалении
Удаление ссылки на базу данных dblink (имя dblink)
4. На заметку
Учетная запись, которая создает ссылку на базу данных, должна иметь системные полномочия CREATE DATABASE LINK или CREATE PUBLIC DATABASE LINK;
Учетная запись, используемая для входа в удаленную базу данных, должна иметь разрешение CREATE SESSION.
V. Конкретный рабочий процесс
1. Требуются две учетные записи
пользователь приложений, пароль: apps
основной пользователь, пароль: 1234
2. Пользовательские приложения (существующие пользователи), создайте основного пользователя (необходимо создать в sys user) пользователя
create user core identified by 1234
3. Предоставьте основные разрешения на вход в систему (вам необходимо назначить разрешения в sys user)
grant create session to core
4. Проверьте, есть ли у пользователя приложения разрешение на создание dblink.
select * from user_sys_privs where privilege like upper('%DATABASE LINK%') ;
Получите следующие разрешения:
5. Сначала создайте таблицу в основной таблице и вставьте данные.
Создайте студенческий стол:
create table student
( STUDENT_NO VARCHAR2(10) not null,
STUDENT_NAME VARCHAR2(20),
STUDENT_AGE NUMBER(2),
STUDENT_GENDER VARCHAR2(5));
Вставьте данные в таблицу учеников:
Вставить в значения учеников ('s001', ' ', 23, ' ');
Вставить в значения NT ученика ('s002', ' ', 23, ' ');
Вставить в значения учеников ('s003', ' ', 25, ' ');
Вставить в значения учеников ('s004', ' ', 20, ' ');
6. Просмотрите таблицу учеников в основном пользователе.
7. Создайте dblink в приложениях и выполните
8. Просмотрите таблицу учеников в основном пользователе в приложении пользователя.
Пока dblink установлен. Пожалуйста, укажите на любые ошибки. Спасибо! ! !
Связь базы данных Oracle (database link) — это одностороннее соединение локальной базы данных с удаленной базой данных. Связь всегда односторонняя. Пользователи удаленной базы не могут применять ее для подключения к локальной базе — вместо этого они должны создать отдельную связь базы данных.
Create database link - создание связей на примерах
Создавать можно приватные и общедоступные связи баз данных. Далее мы рассмотрим соответствующие примеры.
Создание приватной связи базы данных
Приватная связь базы данных принадлежит пользователю, который ее создал. В следующем операторе пользователь SYSTEM создает приватную связь базы данных. Связь базы данных позволяет устанавливать соединение с удаленной базой, используя имя и пароль пользователя hr этой удаленной базы.
После создания связи пользователь SYSTEM может выполнять запросы к таблице hr.employees в удаленной базе данных.
На заметку! Для создания связи базы данных пользователь должен иметь привилегию CREATE PRIVATE DATABASE LINK или CREATE PUBLIC DATABASE LINK в локальной базе данных
Обратите внимание, что в предыдущем операторе имя связи удаленной базы данных — MONITOR — совпадает с TNS-псевдонимом удаленной базы (псевдонимом Oracle Net Service), но вообще может быть любым, по вашему усмотрению. Конструкция CONNECT TO. IDENTIFIED BY означает, что пользователь этой связи базы данных применяет указанное имя и пароль для входа на удаленную базу данных. Конструкция USING 'monitor' просто специфицирует TNS-псевдоним удаленной базы данных.
Поскольку это приватная связь базы данных, только пользователь SYSTEM может использовать ее. Когда пользователь hr попытается воспользоваться этой связью удаленной базы данных, произойдет следующее:
Создание общедоступной связи базы данных
Общедоступная связь базы данных позволяет любому пользователю или любому модулю программы PL/SQL обращаться к объектам удаленной базы данных. Оператор создания такой связи очень похож на оператор создания приватной связи. К оператору CREATE DATABASE LINK просто добавляется ключевое слово PUBLIC :
Совет. Если нескольким пользователям требуется доступ к удаленной базе данных Oracle из локальной, можно создать общедоступную связь. В противном случае создавайте приватную связь базы данных, которая позволяет обращаться к объектам удаленной базы данных только владельцу.
Как только общедоступная связь MONITOR создана, любой пользователь может с ее помощью входить в удаленную базу. В следующем примере пользователь tester применяет общедоступную связь для выполнения запросов к удаленной базе MONITOR .
Использование Database Control для создания связей баз данных
С помощью OEM Database Control очень легко создать связь базы данных. Для этого на домашней странице Database Control нужно щелкнуть на вкладке Administration (Администрирование), а затем на ссылке Database Links (Связи базы данных) в группе Schema (Схема). На этой странице можно создать связь базы данных, ответив на несколько простых вопросов.
Приходилось ли Вам реализовывать нестандартные решения? А в Oracle? Мне бы хотелось рассмотреть использование техник, позволяющих лучше узнать принципы работы СУБД, а в совокупности предоставляющие удобство для разработчика.
Намного удобнее, выполнять разработку приложений баз данных в едином пространстве, а результаты переносить по ландшафту системы в фоновом режиме, автоматически регистрируя производимые изменения.
Пример выполнения обновления на сервере разработки
Пролог
Вы встречали вредных DBA? А работали с такими? На самом деле, обе стороны (Developer vs. DBA), добиваются одного результата, работоспособности системы, но с разных сторон. Впрочем, когда система расширяется, децентрализуется, но сохраняет целостность в реализации, то поддержка консистентного состояния программной оснастки может начать доставлять серьезные неудобства. Появляются серверы разработки, тестирования, «продуктива» — и все это замечательно, но всех их нужно обновлять.
В Oracle есть инструменты казалось бы похожие на рассматриваемый:
• Audit
• Oracle Streams
• Alert
Но все они выполняют другие функции. Одни, обеспечивают аудит изменений, другие синхронизируют данные. А мне бы хотелось действовать более прозрачно, вот например:
Теперь все мои действия продублированы на сервере ‘prod’. А может быть, даже так:
И, скажем, семь серверов создали таблицу «A». Здорово? Тогда – поехали.
Подготовка
Выполним соединение с базой данных от имени пользователя имеющего достаточные привилегии для последующих действий:
Предполагается что пользователь, выполняющий обновления, не должен иметь доступа к самой системе обновления, впрочем, как и сама система не привязывается к целевой схеме, следовательно, может использоваться универсально. Поэтому создадим нового пользователя:
Поскольку статья не об ограничении прав новых пользователей:
Опустив рассуждения о проводимых изысканиях, скажу, что самым сложным оказалось получение анонимного PL/SQL блока, который приводился в примере выше. Естественно, одни действия в конечном итоге порождают другие, так например, всё тот же блок из примера, выполнит insert, но на самом деле может быть и не выполнит! Ведь выполняться он будет на другом сервере. Поэтому нас будет интересовать именно анонимный PL/SQL блок, а не последствия. Паблик синоним V$SQL или представление V_$SQL на которое он ссылается, хранит все запросы, выполнявшиеся на сервере. Попробуем найти в нём нашу цель:
Действительно, именно мой анонимный блок находится там где положено. Конечно же, SQL_ID выполняя мой пример, будет другой, но принадлежит ли он мне? Проверим:
Выполнившийся блок, удалось найти, но мне бы хотелось узнать, кем он выполнен, а точнее узнать, что именно я выполнял его в определенный момент времени. Другое представление V_$SESSION, сможет мне в этом помочь:
select sql_id, prev_sql_id from v$session;
Тут нужно пояснить, что синоним v$session предоставляет доступ к VIEW, а доступ для пользователя организуется командой:
grant select on v_$session to upd;
Дело тут в том, что тип представление v_$session является FIXED VIEW, поэтому давать права на его синоним – запрещено. Впрочем, если выдавать права на синоним, скажем таблицы, сами права выдаются на таблицу, а НЕ на синоним.
Так что же там с запросом? Ах да, нужно ограничить выборку текущей сессией:
Как это у Вас, не получается? Ни SQL_ID ни PREV_SQL_ID – не содержат найденного ранее идентификатора 753c9f808k8hh? Естественно! SQL_ID содержит идентификатор только что выполненного запроса, а PREV_SQL_ID скорее всего хранит идентификатор запроса:
Я надеюсь, что читатель последовательно выполнял запросы, как я их приводил и поэтому сразу не нашел того что ожидалось. Для того что бы убедиться, что результат будет как и указано, нужно выполнить последовательно анонимный блок и запрос к представлению. Как бы то ни было, считаю, что еще один этап изысканий пройден. Теперь мы имеем исходный текст анонимного блока, и знаем, что он был выполнен именно нами.
К сожалению, решение, которое автоматизирует связывание, мне не нравится, ведь необходимо после определенного момента, запомнить все возможные анонимные блоки выполняющиеся пользователем, а представления хранящего историю сессии пользователя не существует? Или существует? Впрочем я не нашел и на данный момент, предлагаю следующий подход. Создадим таблицу, которая будет хранить идентификатор сессии, которая заинтересована в прослушивании и джоб, опрашивающий эту таблицу и сохраняющий историю сессии.
«Что за названия полей второй таблицы?» — спросил бы я. Несмотря на то, что это не имеет веского оправдания, но пытавшись минимизировать нагрузку создаваемую джобом, я добрался до представления более высокого уровня sys.x_$ksuse которое содержит достаточную информацию о целевой сессии. Делая закладку на будущее, в таблицу будут сохраняться еще несколько полезных полей, помимо необходимых: KSUSENUM (SID) и KSUSESQI (SQL_ID). Хорошо будет вынести тело джоба во внешнюю процедуру, и не добавлять ее в пакет, дабы избежать ошибок, если пакет будет не валиден:
Идея обработки, заключается в том, что бы записывать в историю сессии только тогда, и только то что выполняется пользователем в режиме обновления. Теперь можно создать джоб, прослушать сессию пользователя и проверить результат:
Как видно из результата запроса к V$SQL анонимный блок попал в таблицу лога записанный туда джобом. Для теста, я обращался к столбцу KSUSEPSI лога (предыдущему запросу) ввиду того, что мне приходилось выполнять команды очистки таблицы сессии в момент прослушивания. В дальнейшем, это так же окажется некоторым недостатком, но «обрывание» прослушивания мы исключим из результирующего набора выполняемого на удаленном сервере.
Теперь необходимо собрать DLL команды, которые так же могут выполняться при обновлении. Но здесь происходит противоречие, зачем собирать DDL – если их соберет джоб? К сожалению, он их не соберет, так как DDL не является запросом, а следовательно в v$session не отразится. Для этих целей Oracle предоставляет триггеры уровня СУБД, которыми можно воспользоваться. Выполняемые DDL, запишем в новую таблицу, а по аналогии с джобом, создадим процедуру и триггер выполняющей её:
Дополнительная таблица, и её тип (GLOBAL TEMPORARY хранить данные до дисконнекта), выбраны из следующих соображений: джоб собирающий информацию о сессии, работает в сессии отличной от той, которая выполняет скрипты обновления, следовательно запросы записанные в нее стали бы недоступны сессии исполнителя; предоставить Oracle очистку таблицы после обновления; DDL триггер, срабатывает в той же сессии, в которой выполняется DDL, следовательно в этом случае записывать можно сразу в таблицу буфера; сохранение данных таблицы после коммита обусловлено тем, что DDL выполняет молчаливый коммит.
Важно обратить внимание на то, что процедура объявлена с директивой AUTHID DEFINER, которая позволит записывать действия с правами пользователя UPD, которые могут быть большими, чем у вызывающего. Далее производится определение длинны DDL и сохранение буферов в поле CLOB.
Триггер выполняется после (AFTER) DDL, что подразумевает успешное выполнение команды, до записи в буфер.
Подводя итоги изысканий, теперь имеются все возможные типы операций, подлежащие выполнению на обновляемой базе и можно приступить к завершающему этапу – инструменту выполнения обновлений.
Реализация
Мне не нравятся публикации, которые после длительного рассуждения и подготовки заканчиваются чем то вроде: «А теперь, (если не дурак) тебе должно быть ясно как доделать оставшуюся фигню». Конечно же тут дураков – нет, все давно поняли что нужно сделать дальше. Но я приведу свою текущую реализацию, несмотря на то, что её можно считать бета версией. Теперь много кода, а затем пояснения:
К ранее созданным таблицам, добавились еще две, одна из которых используется для визирования успешно выполненных обновлений, а вторая для настройки соединения с удаленной базой Oracle.
Пакет объявлен с директивой AUTHID CURRENT_USER – что приведет к выполнению процедур пакета, с правами пользователя вызывающего пакет. Теперь, о всех процедурах пакета:
procedure SetSession(u_sid number, u_remove boolean default false) – используя автономную транзакцию, записывает текущий идентификатор сессии в таблицу инициирующую прослушивание.
function JobNumber return number – получает идентификатор джоба прослушивателя.
procedure JobRun – проверяет существование джоба.
procedure SetChannel(u_alias varchar2) – получает настройки удаленного соединения и записывает их в локальные переменные пакета.
procedure CancelUpdate – стирает настройки и очищает временные таблицы.
procedure BeginUpdateChannel(u_alias varchar2) – объединяет вызовы подготовительных процедур и начинает прослушивание.
procedure PrepareUpdateChannel – завершает прослушивание и дописывает в таблицу буфер собранные джобом запросы сессии. Я для собственных нужд, не слишком стараясь, отбрасываю при этом DML, select и встреченные в процессе тестирования служебные команды, а так же вызов процедуры PrepareUpdateChannel который тоже записывается в лог сессии.
procedure DropObject – вспомогательная процедура для очистки.
procedure ExecRemote – выполнение блока на удаленном сервере. Эта процедура реализует один из ключевых моментов механизма. Тут пакет dbms_sql вызывается на удаленном сервере.
procedure EndUpdateChannel – применение обновления. И об этом отдельно.
Для конечного пользователя можно создать процедуры обертки, с директивой AUTHID DEFINER и раздать права вызывать их нужным пользователям:
Читайте также: