Oracle - Хадсон Джобс: схема против пользователя - PullRequest
0 голосов
/ 17 марта 2011

у нас есть разные задания hudson, которые взаимодействуют с базой данных. Поскольку все они записывают в базу данных и удаляют данные, мы не можем запустить 2 задания одновременно, опасаясь возможного состояния гонки.

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

Будут ли у моих заданий hudson такие же проблемы, связанные с состоянием гонки, или создание нового пользователя для каждого задания решит проблему?

Любая помощь будет оценена.

Ответы [ 2 ]

2 голосов
/ 18 марта 2011

Для пояснения терминов.

База данных - это набор пользователей, каждый из которых может владеть объектами (например, таблицами).

Пользователь может ссылаться на объекты, принадлежащие другому пользователю.

Например, FRED может иметь таблицу BLUE.Пользователь BARNEY может написать инструкцию SELECT * FROM FRED.BLUE.Оператор будет работать, только если BARNEY предоставлена ​​привилегия SELECT для FRED.BLUE или есть привилегия SELECT ANY TABLE.

Если пользователь (например, WILMA) делает SELECT * FROM RED, тогда RED разрешается какво-первых, это объект в их схеме по умолчанию, или сбой в качестве публичного синонима.Схема пользователя по умолчанию, как правило, является собственной, но ее можно изменить с помощью команды ALTER SESSION SET CURRENT_SCHEMA

Так что, если ваши задания Hudson сталкиваются друг с другом в одной и той же базе данных, они могут использовать полностью определенные обозначениячтобы ссылаться на объект в конкретной схеме, или они могут использовать PUBLIC SYNONYM, который ссылается на объект в конкретной схеме, или они выполняют ALTER SESSION для той же схемы.

1 голос
/ 17 марта 2011

Вот как вы должны это сделать:

create user jobOneRunner identified by test;

- на этом этапе они не должны иметь никаких привилегий, даже не создавать сеанс.

Чтобы убедиться в этом, выполните следующееSQL:

select
  lpad(' ', 2*level) || granted_role "User, his roles and privileges"
from
  (
  /* THE USERS */
    select 
      null     grantee, 
      username granted_role
    from 
      dba_users
    where
      username like upper('%&enter_username%')
  /* THE ROLES TO ROLES RELATIONS */ 
  union
    select 
      grantee,
      granted_role
    from
      dba_role_privs
  /* THE ROLES TO PRIVILEGE RELATIONS */ 
  union
    select
      grantee,
      privilege
    from
      dba_sys_privs
  )
start with grantee is null
connect by grantee = prior granted_role;

Если у пользователя JobOneRunner есть привилегии, отмените их.Затем предоставьте им выбор / обновление / удаление и т. Д. Доступ к любым объектам, к которым им нужно получить доступ.Вам также нужно будет предоставить им сеанс создания, чтобы они могли подключаться.

Чтобы предоставить выбор / обновить / удалить объекту, принадлежащему другой схеме, сделайте следующее:

grant select on SCHEMA.object to jobOneRunner;

Чтобы ответить на второйвопрос, да, это решит вашу проблему.Тем не менее, вы точно определили, что состояние гонки возможно?

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