Меню

Oracle кто занял таблицу

Oracle кто занял таблицу

Пытаюсь найти связь между таблицами и если если, то какая.

Условно у меня есть первая таблица, я хочу понять связана ли она как то с какой то другой таблицей:

Для этого попытался сделать так: зашел d PLSQL Debeloper`е в other_Users —> далее нашел Юзера у кого есть эта таблица, открыл эту таблицу —> в ней открыл вкладку «Constraints». Скриншот:

И далее не очень понимаю, если есть возможность подскажите пожалуйста.

Вот что, как мне показалось понял и что не понял:

1)В таблице есть главный и внешний ключ. Правда при самом запросе SELECT* from Table — название указанных ключей RTPL_PK и RTPL_RTPB_FK — не выгружается.
2)В Столбец R_TABLE_NAME — указано название таблицы на какую ссылается «данная» таблица то есть ссылается на таблицу ICE_TABLES. Такая таблица сущесвует.

В столбце R_CONSTRAINT_NAME указано наименование столбца PRTB_PK в таблице ICE_TABLES на которую ссылается «данная» таблица. Вот только проблема в том, что в таблице ICE_TABLES — нет столбца с названием PRTB_PK, а есть с названием PRTB_ID. И как это понимать, что то я не очень понимаю.

3)Не понял, что такое R_OWNER. Нагуглил, что это некая «схема», но что это значит не понятно. Единственно, что понятно, что название в столбце R_OWNER — «TC» — совпадает с названием Users в котором две эти таблицы находятся.

4)Так же меня смущают столбцы DELETE_RULE и STATUS — в которых напротив строки с «внешним ключом» стоит наименование NO_ACTION и DISABLED.
Это значит, внешний ключ не работает или что ?

5)И непонятно для чего столбца INDEX_ONWER и INDEX_NAME — что за информация в них указана и как ее нужно или можно использовать?

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Источник



АУДИТ ПОЛЬЗОВАТЕЛЕЙ ORACLE БАЗЫ ДАННЫХ ШТАТНЫМИ СРЕДСТВАМИ

12.01.2021 | Иван Огурцов, г. Санкт-Петербург |

Добрый день! Сегодняшняя статья посвящена аудиту пользователей в БД. Все примеры работают на БД Oracle, но используемые алгоритмы и срезы проверок, вероятно, есть во всех распространенных базах, просто немного иначе реализуются.

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

Из желаемых ограничений задачи было решение опираться на готовые системные представления БД Oracle, чтобы максимально избавить себя от работы по обновлению данных. Здесь и далее постараюсь избегать сложных терминов администрирования — для максимального понимания происходящего. Детали можно почитать в официальной документации к Oracle.

Читайте также:  Церковные реформы 1653 года таблица

Итак, какие задачи мы поставили перед собой (сразу отмечу, что в качестве уникального ключа мы выбрали логин пользователя в Oracle, и далее обогащали логины различными системными атрибутами, при этом сохраняя его уникальность):

  1. Установить связь «пользователь Oracle – ПК», с которых производилась авторизация в Oracle конкретными пользователями;
  2. Обозначить период активности пользователя в БД, в т.ч. флаг активности в текущем году;
  3. Проверить привилегии пользователя – в Oracle это звучит как Role privileges и System privileges.

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

Итак, начну с последнего и наиболее простого с точки зрения реализации пункта – мониторинга привилегий пользователей на каждый объект БД. Для создания этого представления хватило системной таблицы dba_tab_privs, в которой содержатся все пользователи и их полномочия, а также те, кто выдал эти полномочия. Итак, запустим следующий код:

Результат этого кода показывает, к каким объектам БД (OWNER, TABLE_NAME, TYPE) имеет доступ конкретный пользователь (GRANTEE), и какие полномочия у него есть для работы с каждым объектом БД (PRIVS_TO_OBJECT_BD):

Иными словами, суть представления – показать доступные действия пользователя для каждого объекта БД (в данном случае связка Пользователь БД + Объект БД – уникальна).

Отлично, двигаемся дальше. Теперь рассмотрим код для сбора различных системных атрибутов по каждому пользователю БД. Ввиду сложности кода разобьём его на составные части (для удобства выделим связанные атрибуты в SQL-блоки “with”). Так, сначала определимся с перечнем пользователей, по которым будем собирать аналитику. В нашем случае мы исключили пользователей, которые в качестве default_tablespace используют системные пространства БД:

Данный код использует системное представление dba_users и собирает некоторые атрибуты, например, текущий статус пользователя (открыт/заблокирован/…), дату блокировки пользователя, а также профайл пользователя (администратор/пользователь/технологическая учетная запись):

Так, список ключей уникален, теперь будем обогащать эту таблицу атрибутами из других системных таблиц, исходя из задачи. О них далее.

Добавим данные по авторизациям пользователей в БД. Для этого немного преобразуем системное представление dba_audit_session. Ввиду того, что изначально в представлении перечень пользователей БД неуникален, воспользуемся функцией listagg для сбора однотипных метрик пользователя в один кортеж. Для справки: функция listagg таблицу вида:

Преобразует в вид:

С помощью этой функции получаем уникальность пользователей БД, а значит готовы обогащать этими данными первоначальный список пользователей. Исходный код по авторизациям пользователей в БД выглядит так:

Результат исполнения кода:

Читайте также:  Энергия заряженного конденсатора таблица

Обратите внимание, дополнительно оконная sql-функция считает количество ПК, с которых осуществлялся вход под выбранным пользователем (атрибут PC_CNT).

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

Результат исполнения запроса:

Обратите внимание, атрибут ACTIVE_IN_CURRENT_YEAR использует не статичный год, а год из системной даты (to_char(TIMESTAMP, ‘YYYY’)). Столбец LOGONS_CNT – количество успешных авторизаций пользователя на сервере.

Далее, выделим права каждого пользователя, для этого используем 2 таблицы Oracle DB: dba_role_privs и dba_tab_privs:

И второй код, для dba_tab_privs:

В столбце CNT_ROLE_PRIVELEGES – количество ролей каждого пользователя. Здесь можно отследить критичные. Например, для нас возможность пользователя просматривать содержимое всех таблиц на сервере – недопустима, поэтому все роли “select any table” были заменены на “select table”, что позволяет выводить содержимое только созданных пользователем таблиц. В принципе готово, осталось собрать все блоки “with” в одно представление с помощью конструкции JOIN:

Результат итогового представления (для наглядности показан в виде single record view):

Таким образом созданы 2 представления, которые показывают наглядную картину по аудиту пользователей, а также доступы к критичным объектам БД. В дальнейшем можно настроить систему алертов, которая бы при наступлении определённого события оповещала заинтересованных сотрудников любым доступным в вашей организации способом, например:

  1. Вход пользователя с нового ПК;
  2. Попытка получить доступ ко всем объектам БД;
  3. Различные манипуляции с ролями/привилегиями БД;
  4. Несанкционированный перевод пользователя в несоответствующий ролевой модели профайл пользователя с целью получения расширенных прав;
  5. И т.д.

Да и в целом, инструменты, представленные в статье, частично готовы решать задачу оптимизации места на сервере за счет оценки активности пользователей. То есть, если у вас есть логины, которые последний раз заходили в БД несколько лет назад – то, вероятно, можно очищать их персональное пространство. Тема оценки активности использования объектов БД – уже совсем другая задача.

2021 год

Источник

APPS-ORACLE.RU

Сбор статистики

Для сбора статистики используем процедуру

Если в базе данных имеются таблицы, которые часто обновляются, то частый сбор статистики может негативно повлиять на производительность базы данных. Для того, чтоб исключить объекты из автоматического или любого другого сбора статистики можно «закрепить» ее статистику:

Теперь, по этой таблице невозможно будет собрать статистику ни автоматически, ни вручную:

Снять блокировку статистики:

Посмотреть данные о сборе статистики можно в таблице DBA_TAB_STATISTICS

Собрать статистику для индекса

Статистика на секцию

Похожие записи:

  • Убрать пустые блоки из таблицы
  • Регулярные выражения. Удаление последней буквы или цифры в строке.
  • SQL Склонение количества ошибок
  • Удаление управляющих символов из строки
  • Список параметров процедуры SQL запросом
Читайте также:  Время сказок осваиваем таблицу умножения

Данное утверждение — «Если в базе данных имеются таблицы, которые часто обновляются, то частый сбор статистики может негативно повлиять на производительность базы данных.» — вообще говоря, неверно. Именно для таких таблиц важно поддерживать статистику в актуальном состоянии. Если, разумеется, запросы не используют RBO — что в современных версиях невозможно ввиду отсутствия RBO (вместо него начиная с 10g стоит заглушка).

Блокировку сбора статистики целесообразно выполнять в приложениях типа OEBS — с большим (реально большим) количеством неизменных справочников. И при этом не стоит забывать про существующие в БД по умолчанию задания автоматического обновления статистики.

Источник

Как найти связь между таблицами Oracle

Пытаюсь найти связь между таблицами и если если, то какая.

Условно у меня есть первая таблица, я хочу понять связана ли она как то с какой то другой таблицей:

Для этого попытался сделать так: зашел d PLSQL Debeloper`е в other_Users —> далее нашел Юзера у кого есть эта таблица, открыл эту таблицу —> в ней открыл вкладку «Constraints». Скриншот:

И далее не очень понимаю, если есть возможность подскажите пожалуйста.

Вот что, как мне показалось понял и что не понял:

1)В таблице есть главный и внешний ключ. Правда при самом запросе SELECT* from Table — название указанных ключей RTPL_PK и RTPL_RTPB_FK — не выгружается.
2)В Столбец R_TABLE_NAME — указано название таблицы на какую ссылается «данная» таблица то есть ссылается на таблицу ICE_TABLES. Такая таблица сущесвует.

В столбце R_CONSTRAINT_NAME указано наименование столбца PRTB_PK в таблице ICE_TABLES на которую ссылается «данная» таблица. Вот только проблема в том, что в таблице ICE_TABLES — нет столбца с названием PRTB_PK, а есть с названием PRTB_ID. И как это понимать, что то я не очень понимаю.

3)Не понял, что такое R_OWNER. Нагуглил, что это некая «схема», но что это значит не понятно. Единственно, что понятно, что название в столбце R_OWNER — «TC» — совпадает с названием Users в котором две эти таблицы находятся.

4)Так же меня смущают столбцы DELETE_RULE и STATUS — в которых напротив строки с «внешним ключом» стоит наименование NO_ACTION и DISABLED.
Это значит, внешний ключ не работает или что ?

5)И непонятно для чего столбца INDEX_ONWER и INDEX_NAME — что за информация в них указана и как ее нужно или можно использовать?

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Источник

Adblock
detector