stored procedure
Lilya A. Kozlenko
Имеет место простенькая процедурка (8i EE используется, NT)
CREATE OR REPLACE PROCEDURE PCT_M IS
cursor A_TABLES_1 is select /*rule*/ distinct owner, tablespace_name
from all_indexes
where pct_increase <>0 and owner not in ('SYS', 'SYSTEM', 'OUTLN')
order by owner;
begin
delete from MSG_M;
commit;
for X in A_TABLES_1 loop
insert into MSG_M values('execute pct(''' || X.TABLESPACE_NAME || ''',
'''
|| X.OWNER || ''');' );
end loop;
commit;
end PCT_M;
все простенько до нельзя, но тут то и начинается самое
интересное, а именно, результаты запроса
select /*rule*/ distinct owner, tablespace_name from all_indexes
where pct_increase <>0 and owner not in ('SYS', 'SYSTEM', 'OUTLN')
order by owner;
выполненного из sp и просто sqlplus-ом разные (короче "крыша в пути",
только вот у кого...).
Cтоит Oracle 8i (правда не патченый), релиз 1.
Кто сталкивался с подобными фокусами.
Может быть такое из-за объема системного каталога (а там где-то
5000 табли и 7000 индексов, ну чуть-чуть побольше) - это бред конечно,
imho не может.
Или это фокусы 7-го клиента? Hо вроде за ним такое не водилось...
Да и причем тут sp... По моему не причем.
Вот мои админовские автоматизации вот на такое непонятное
нарвались.
Короче, хелп, а то хана (крыше то есть :) ).
--
Regards, Lilya Kozlenko
Igor Guljaeff
Вполне допустимая ситуация.
Обзор ALL_INDEXES показывает все индексы доступные пользователю
(кстати функция userenv('SCHEMAID') не описана в моей документации).
В случае же процедуры обзор показывает все индексы доступные
владельцу процедуры , а не текущему пользователю.
Если я заблуждаюсь и дело в чем нибудь другом , то лучше попробовать
заменить конструкцию distinct на group by , и посмотреть на результат.
С Уважением И.Гуляев
Oleg Dolgih
15 May 28 17:46, Lilya A. Kozlenko wrote to All:
LK> 'OUTLN') order by owner; выполненного из sp и просто sqlplus-ом разные
LK> (короче "крыша в пути", только вот у кого...). Cтоит Oracle 8i (правда
Может пpосто кто-то создает индекс во вpемя пока ты пеpезаpускаешь запpос?
Сделай "левую" тестовую таблицу с огpаниченным кол-вом стpок (чтобы глазами
можно было увидеть, что веpнется) и посмотpи как твой запpос будет pаботать с
ней. Плюса нет чтобы пpовеpить у себя.
Всего наилучшего, Oleg
>> o...@voron.elektra.ru Delphi\Bridge\Jazz\KSP 09.04.69
Andrei Sokolik
15 May 00 17:46, Lilya A. Kozlenko wrote to All:
LAK> CREATE OR REPLACE PROCEDURE PCT_M IS
LAK> cursor A_TABLES_1 is select /*rule*/ distinct owner,
/*+rule*/
LAK> tablespace_name from all_indexes
LAK> where pct_increase <>0 and owner not in ('SYS', 'SYSTEM',
LAK> 'OUTLN') order by owner; begin
LAK> delete from MSG_M;
LAK> commit;
LAK> for X in A_TABLES_1 loop
LAK> insert into MSG_M values('execute pct(''' || X.TABLESPACE_NAME
LAK> || ''',
LAK> '''
LAK> || X.OWNER || ''');' );
LAK> end loop;
LAK> commit;
LAK> end PCT_M;
LAK> все простенько до нельзя, но тут то и начинается самое
LAK> интересное, а именно, результаты запроса
LAK> select /*rule*/ distinct owner, tablespace_name from all_indexes
LAK> where pct_increase <>0 and owner not in ('SYS', 'SYSTEM',
LAK> 'OUTLN') order by owner; выполненного из sp и просто sqlplus-ом разные
LAK> (короче "крыша в пути", только вот у кого...).
all_indexes это представление, из которого видно то, что положено видеть юзеру.
Hапример, если вы входите с привилегиями DBA, то увидите больше, чем обычный
юзер. Во избежание проблем используйте представления словаря, начинающиеся с
dba_%.
LAK> Cтоит Oracle 8i (правда
LAK> не патченый), релиз 1. Кто сталкивался с подобными фокусами. Может
LAK> быть такое из-за объема системного каталога (а там где-то 5000 табли и
LAK> 7000 индексов, ну чуть-чуть побольше) - это бред конечно, imho не
LAK> может. Или это фокусы 7-го клиента? Hо вроде за ним такое не
LAK> водилось... Да и причем тут sp... По моему не причем.
Скорее, привилегии доступа. В SQL*Plus входите как владелец pct_m или нет?
LAK> Вот мои админовские автоматизации вот на такое непонятное
LAK> нарвались.
LAK> Короче, хелп, а то хана (крыше то есть :) ).
LAK> --
LAK> Regards, Lilya Kozlenko
Andrei
Lilya A. Kozlenko
> Может пpосто кто-то создает индекс во вpемя пока ты пеpезаpускаешь запpос?
Исключено.
--
Regards, Lilya Kozlenko
Lilya A. Kozlenko
Andrei Sokolik <Andrei_...@p20.f2.n5022.z2.fidonet.org> wrote in message
> /*+rule*/
Это само собой, но это именно не хинт а коментарий. Я специально
всю статистику с sys и system убрала, а потому оптимизатору деваться
некуда, все равно он по rule пойдет, а не по cost, хинт /*+rule*/ в этом
случае излишний вобщем-то.
> all_indexes это представление, из которого видно то, что положено видеть
юзеру.
> Hапример, если вы входите с привилегиями DBA, то увидите больше, чем
обычный
> юзер. Во избежание проблем используйте представления словаря, начинающиеся
с
> dba_%.
Это все и так известно. Hо в том то и прикол, что и создание,
и выполнение sp и запроса производится под одним пользователем.
dba есть. Оно и под system так же работает, как описано - результат запросов
разный.
Именно различается all_all_tables и all_indexes. Если аналогичны запрос
писать для user_tables, user_indexes и запрашивать теже данные под
акаунтом конкретного пользователя для его схемы - то тут все нормально
(опять же и владелец sp и схемы один и тот же, и вызов sp и выполнение
запроса идет под его же правами).
> Скорее, привилегии доступа. В SQL*Plus входите как владелец pct_m или нет?
В том то и дело, что как владелец. Считай, как system, для определенности.
--
Regards, Lilya Kozlenko
Andrei Sokolik
17 May 00 11:43, Lilya A. Kozlenko wrote to All:
>> all_indexes это представление, из которого видно то, что положено
>> видеть юзеру.
>> Hапример, если вы входите с привилегиями DBA, то увидите больше, чем
>> обычный юзер. Во избежание проблем используйте представления словаря,
>> начинающиеся с dba_%.
LAK> Это все и так известно. Hо в том то и прикол, что и создание,
LAK> и выполнение sp и запроса производится под одним пользователем.
LAK> dba есть. Оно и под system так же работает, как описано - результат
LAK> запросов разный. Именно различается all_all_tables и all_indexes. Если
LAK> аналогичны запрос писать для user_tables, user_indexes и запрашивать
LAK> теже данные под акаунтом конкретного пользователя для его схемы - то
LAK> тут все нормально (опять же и владелец sp и схемы один и тот же, и
LAK> вызов sp и выполнение запроса идет под его же правами).
>> Скорее, привилегии доступа. В SQL*Plus входите как владелец pct_m
>> или нет?
LAK> В том то и дело, что как владелец. Считай, как system, для
LAK> определенности.
То есть вы порцедуру под system создаете? IMHO это не есть хорошо :). Там уже
есть системные объекты:
=== Cut ===
COUNT(*) OBJECT_TYPE
-+-------- ------------------
68 INDEX
13 LOB
1 PACKAGE
1 PACKAGE BODY
1 PROCEDURE
4 QUEUE
11 SEQUENCE
59 SYNONYM
48 TABLE
1 TRIGGER
3 VIEW
=== Cut ===
Создайте себе пользователя, дайте ему grant select any table и в нем создавайте
процедуры.
Сейчас у себя попробовал выборку из all_tables - Oracle 7.3.4 HP_UX, 8.1.6 NT.
Все одинаково :). С ними никогда проблем не было. А объектные привилегии и
триггера нормально только через dba_triggers, dba_tab_privs увидеть можно.
Так что одно из двух. Либо с привилегиями что-то намудрили, либо у вашего
Oracle действительно крыша поехала :). Посмотрите текст представления, там в
where есть про гранты:
select text from all_views where view_name = 'ALL_TABLES';
=== Cut ===
[skiped]
from sys.user$ u, sys.ts$ ts, sys.seg$ s, sys.obj$ co, sys.tab$ t, sys.obj$ o
where o.owner# = u.user#
and o.obj# = t.obj#
and bitand(t.property, 1) = 0
and t.bobj# = co.obj# (+)
and t.ts# = ts.ts#
and t.file# = s.file# (+)
and t.block# = s.block# (+)
and t.ts# = s.ts# (+)
and (o.owner# = userenv('SCHEMAID')
or o.obj# in
(select oa.obj#
from sys.objauth$ oa
where grantee# in ( select kzsrorol
from x$kzsro
)
)
or /* user has system privileges */
exists (select null from v$enabledprivs
where priv_number in (-45 /* LOCK ANY TABLE */,
-47 /* SELECT ANY TABLE */,
-48 /* INSERT ANY TABLE */,
-49 /* UPDATE ANY TABLE */,
-50 /* DELETE ANY TABLE */)
)
)
=== Cut ===
Только text имеет тип long, в параметры/конфигурация SQL*Plus установите для
long 4000. Hу и дальше копайте. Общее положение - хранимая оперирует
привилегиями, выданными владельцу явно, а не через роль.
Lilya A. Kozlenko
Andrei Sokolik <Andrei_...@p20.f2.n5022.z2.fidonet.org> wrote in message
> То есть вы порцедуру под system создаете? IMHO это не есть хорошо :). Там
уже
Hа самом деле не под system, а под юзером, у которого dba есть,
ну и select_any_table. Под system -это уже с горя.
> Сейчас у себя попробовал выборку из all_tables - Oracle 7.3.4 HP_UX, 8.1.6
NT.
У меня 8.1.5 nt. может у него крыша и поехала конечно... может
трапы то даром и не прошли в куче с 600-ми, но вроде
В конце концов пересоздам базу в чистую, если будут проблемы...
> long 4000. Hу и дальше копайте. Общее положение - хранимая оперирует
> привилегиями, выданными владельцу явно, а не через роль.
Это-то меня и достаточно сильно раздражает в oracle (явно отдавать
привилегии муторно довольно).
--
Regards, Lilya Kozlenko
Andrei Sokolik
19 May 00 13:29, Lilya A. Kozlenko wrote to All:
>> long 4000. Hу и дальше копайте. Общее положение - хранимая оперирует
>> привилегиями, выданными владельцу явно, а не через роль.
LAK> Это-то меня и достаточно сильно раздражает в oracle (явно отдавать
LAK> привилегии муторно довольно).
А как иначе? Роли можно и динамически раздавать, на сессию:
SET ROLE ...;
Так что иначе прав не проверить при компиляции. А откладывать проверку на
момент исполнения - накладно в плане производительности.
Andrei