Выпуск 44

Уважаемые подписчики рассылки!

Этот выпуск посвящен некоторым аспектам практического использования срредств тщательного контроля доступа. По мотивам ответа Тома Кайта на вопрос, заданный 25 мая 2003 года.

Практическое использование средств тщательного контроля доступа

Том,

Мы собираемся использовать возможности создания виртуальной приватной базы данных (VPD) сервера Oracle для уже работающей производственной системы оперативной обработки транзакций (ООТ). Идея в том, чтобы возможности системы могли одновременно использовать примерно 40-50 разных компаний. В каждую таблицу приложения добавляется новый столбец, например, COMP_ID.

Теперь вопрос: (я знаю о твоем мнении в отношении использования индексов на основе битовых карт в системах ООТ) Не стоит ли использовать индексы на основе битовых карт по столбцам COMP_ID (VPD), просто потому, что количество различных значений в них весьма невелико?

Ответ Тома Кайта

НЕТ!

Индексы на основе битовых карт никогда, ни при каких обстоятельствах не подходят для систем ООТ.

Столбец COMP_ID станет атрибутом, который будет добавлен к существующим индексам -- сам столбец COMP_ID индексировать не нужно.

Пусть имеется таблица emp:

create table emp ( empno   number,
                   ename   varchar2(30),
                   job     varchar2(10) );

И выполнены следующие операторы:

alter table emp add constraint emp_pk primary key(empno);
create index emp_ename_idx on emp( ename );

Теперь, вы добавляете столбец comp_id и выполняете операторы:

alter table emp add constraint emp_pk primary key(EMPNO,COMP_ID);
create index emp_ename_idx on emp(ename, COMP_ID);

поскольку запрос, который имел вид:

select * from emp where empno = :x;

теперь будет эквивалентен:

select * from emp where empno = :x and comp_id = sys_context(...);

Запрос:

select * from emp where ename = :x 

будет изменен аналогично...

Вопрос читателя от 26 мая 2003 года

Нет ли смысла фрагментировать таблицу по столбцу COMP_ID?

Ответ Тома Кайта

Конечно, можно и фрагментировать. Особенно если количество разных значений comp_id фиксировано. Будет сложнее (потребует больше действий от администратора), если придется добавлять фрагменты на ходу.

А как насчет сжатия?

Не будет ли лучше создать индекс со сжатием, например, по столбцам comp_id, empno и сжать по столбцу 1?

Ответ Тома Кайта

Да, это сработает...

Условие, генерируемое при добавлении FGAC

Перечитал на выходных главу, посвященную средствам тщательного контроля доступа, в твоей книге...

Вопросы:

1. Нет ли способа получить либо условие, генерируемое функциями защиты, либо полный текст SQL-оператора?
2. Когда реально выполняются функции защиты?

Я попытался сделать следующее:

• Добавил вызовы dbms_output в функции: ничего выдано не было, так что момент вызова определить не удалось.
• Представления v$sqlarea/v$sqltext содержат только SQL-операторы виртальной приватной базы данных ("select * from emp")
• Утилита tkprof также показывает только "select * from emp"

Как получить реальный текст оператора - я привык видеть при программировании все операторы SQL.

Ответ Тома Кайта

1) См. это обсуждение

2) При анализе оператора. Вызовы dbms_output в функциях FGAC выполняются в другом сеансе - вот почему вы никогда не увидите их результаты.

Оригинал обсуждения этого вопроса можно найти здесь.

Copyright © 2003 Oracle Corporation

В следующем выпуске

Про ключевое слово USING... Следуем опубликованной программе развития рассылки.

С наилучшими пожеланиями,

  В.К.