Comments 9
Прочитал статью и, честно говоря, даже не понял, какую задачу решал автор.
Стоит пожалуй в самом верху сделать постановку задачи и только потом уж по шагам рассказывать решение.
Стоит пожалуй в самом верху сделать постановку задачи и только потом уж по шагам рассказывать решение.
Я кажется понял, автор AndyBW разработал сложную систему обновления серверов Оракл командами DDL/DML. Не понял только чем не устраивает вариант натравить sqlplus`ы на папку со скриптами?
Не готов комментировать созданное решение как таковое, но вот пара замечаний по архитектуре:
- динамический SQL — зло
- DBMS_JOB очень не рекомендуется к использованию — DBMS_SCHEDULER же; хотя проверил только что по документации 11.2 — DBMS_JOB все еще supported, хоть и для обратной совместимости только, но тем не менее не deprecated и не obsolete
- работать с X$-представлениями — это, конечно, «круто», но система останется только для Вас; вы себе представляете, чтобы эти скрипты Вы решили поставить где-то еще, что скажет ихний DBA? я бы послал, даже не разговаривая. и вообще, есть ли реальное преимущество в Вашей текущей задаче от использования столь низкоуровневых вещей?
- ну и триггера уровня базы — на нагруженной (по-настоящему) системе — я бы постарался избегать
• В данном случае он только выполняет уже выполненный DDL.
• Как бы то ни было это мне больше всего и не нравится.
• Удаленный сервер должен иметь лишь один компонент — обратный dblink. Кстати можно обойтись и без dblink, но тогда размер блока обновления ограничен.
• Решение предназначено для использования (установки) на сервере разработки.
• Как бы то ни было это мне больше всего и не нравится.
• Удаленный сервер должен иметь лишь один компонент — обратный dblink. Кстати можно обойтись и без dblink, но тогда размер блока обновления ограничен.
• Решение предназначено для использования (установки) на сервере разработки.
100% нужно описать в аннотации о чем эта статья, что она решает!
Очень круто, узнал для себя несколько новых вещей. За одно это огромное спасибо. Думаю это здравая мысль, работая в IDE с ораклом сразу в нем сохранять и коммитить код, без необходимости использовать файлы. Направление верное, но сам лично я бы побоялся применять такое решение в продакшен. В сохранении в файл есть свой плюс: лишний раз задумываешься, все ли верно. Кроме того, в нашей системе мы активно используем переменные sqlplus при накате скриптов, так как имена схем на средах DEV, TST и продуктива отличаются префиксом. Плюс файлы можно сохранить в VCS для истории и теоретически использовать для восстановления системы.
Спасибо maovrn за отзыв. Приведенный материал достаточно объемный и дополнительные аспекты могут остаться незамеченными.
Вот смотрите: приведенное решение не нужно установить на серверах кроме одного DEV; dblink который создается использует соединение с базой от имени указанного пользователя и его права доступа; код без явного указания схемы, создается в схеме внешнего пользователя (в настройке dblink); скрипт сначала реально выполняется на DEV и тут никакой магии, а если нет ошибок дублируется на TST; все ходы записываются и им присваивается ревизия; пользователь upd изолирован, а доступ к dblink на прямую он не предоставляет.
Теперь, немного о правах доступа, вот пример (предположим что «test» будет вашей рабочей схемой на сервере TST):
Почему это произошло? dblink не позволяет управлять привилегиями (т.е. выполнять grant, revoke) и разрешает только те права, которые пользователь имеет явно. Для выполнения этого обновления нужно выдать права:
Указанные Вами опасения — не влияют на управляемость работой этого решения.
Вот смотрите: приведенное решение не нужно установить на серверах кроме одного DEV; dblink который создается использует соединение с базой от имени указанного пользователя и его права доступа; код без явного указания схемы, создается в схеме внешнего пользователя (в настройке dblink); скрипт сначала реально выполняется на DEV и тут никакой магии, а если нет ошибок дублируется на TST; все ходы записываются и им присваивается ревизия; пользователь upd изолирован, а доступ к dblink на прямую он не предоставляет.
Теперь, немного о правах доступа, вот пример (предположим что «test» будет вашей рабочей схемой на сервере TST):
SQL> connect system/***@TST
Connected.
SQL> create user test identified by ***;
User created.
SQL> grant dba to test;
Grant succeeded.
SQL> connect test/***@TST
Connected.
SQL> create database link back_dev connect to developer identified by *** using 'DEV';
Database link created.
SQL> select * from dual@back_dev;
D
-
X
SQL> connect upd/***@DEV
Connected.
create database link db_test connect to test identified by *** using 'TST';
Database link created.
--Разрешу developer используя алиас test_server попадать на сервер DEV к пользователю TEST
insert into upd$servers values ('test_server', 'db_test', 'developer', 'back_dev');
1 row inserted.
SQL> connect developer/***@DEV
Connected.
--я авторизован как developer и пакет будет создаваться в этой схеме
begin
upd.ChannelUpdate('test_server');
end;
--сначала в схеме developer успешно скомпилируется пакет
create or replace package test1 as
procedure proc1;
end;
/
begin
upd.ChannelPrepare;
--произойдет компиляция пакета на сервере TST для пользователя test, который имеет права DBA
upd.ChannelApply;
end;
ORA-01031: insufficient privileges
Почему это произошло? dblink не позволяет управлять привилегиями (т.е. выполнять grant, revoke) и разрешает только те права, которые пользователь имеет явно. Для выполнения этого обновления нужно выдать права:
grant create procedure to test;Указанные Вами опасения — не влияют на управляемость работой этого решения.
Sign up to leave a comment.
PL/SQL через dblink