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

1. я не говорил, что не надо пользоваться разграничением доступа. Система логирования - это в дополнение, а не вместо
2. по поводу обхода защиты (а пользование другим инструментом - один из них) я уже тоже говорил

egorych
- вот с какого, интересно? если логирование производится в момент, когда возникли подозрения, то проще смотреть permissions пользователя/группы пользователей, чем запускать логирование, неизвестно, как долго придётся ждать, когда в следующий раз будет вызвана хранимая процедура именно тем пользователем, которому вызывать её не положено, и остальные будут испытывать неудобства всё это время совершенно незаслуженно. Потом, если уж человек добрался до базы через другой инструмент, то уж наверное он сообразит сделать SELECT напрямую, не используя хранимую процедуру, то есть этот инструмент защиты будет обойдён. Так в чём же смысл, я вас спрашиваю?

1. одними permissions сыт не будешь, тем паче, что на них уже смотрели раньше
2. возможность SELECT-а напрямую опять же зависит от прав
3. использование хранимых процедур в том числе для целей логирования декларировал не я, а другой оратор. Я говорил про системные средства Oracle. Они либо не требуют программирования (стандартный аудит), либо требуют некоторого программирования (FGA), но это накладывается на таблицу, а не пихается в каждую процедуру

egorych
- имхо, в несильно нагруженных системах тем более нет необходимости логировать селекты в хранимках, там и так можно разобраться.

1. Хм-м-м... Т.е. если система сильно нагружена (скажем, несколько сот одновременно работающих), то нам разбираться некогда, а если несколько десятков - то есть куча времени на разборы? Ор-р-ригинально...
2. про логирование именно в хранимках смотри выше...

egorych
- не видите здесь противоречия? чтобы отловить тяжёлый SQL мы добавляем в систему средство, которое заведомо утяжелит всю систему?

Абсолютно не вижу. А как его отлавливать, не запускаю доп. функциональность? А доп. функциональность в любом случае создает нагрузку (то же декларируемое логирование DML).
За все надо платить (см. пред. посты)

egorych
знаете зачем? чтобы поменьше было велосипедов.
Моё имхо в том, что подобное средство встроено в СУБД скорее для наладки производительности в помощь DBA, а не для реализации мифических дополнительных уровней защиты.
Ну и маркетинговый ход, само собой: "вона чего мы умеем, ни у кого такого нет!" В этом смысле Oracle не сильно отличается от Microsoft.

1. на самом деле возможных уровней защиты в Oracle значительно больше, включая "шифрование на лету". Видимо, все они мифические, если вполне достаточно системы грантов.
2. логирование SELECT не может (или редко может) помочь в настройке производительности, ибо там отсутствуют планы выполнения, временные характеристики запроса
3. Ну разумеется. Все, что МНЕ кажется ненужным, это маркетинговые ходы и не более того.

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

1. как раз выборки в гриды (если мы под этим понимаем одно и то же) чаще всего НЕ являются тяжелыми выборками, ибо для визуального наблюдения больших объемов не нужно. Самыми тяжелыми выборками, как правило, являются некоторые отчеты
2. если выборка тяжелая, она занимает кучу времени и пользователь просто не станет по долгу ждать ее вывода на экран (отчеты - это другое дело). Кроме того, тяжелые выборки выполняются от десятков минут до нескольких часов и пользователь тысячу раз в день просто не сможет ее запустить
3. может мы по разному понимаем лог? Если выборка тяжелая, то время ее выполнения значительно превышает время разбора SQL и в этом случае запись текста SQL в какую-то табличку (один из вариантов логирования) добавит даже не копейки, а доли копеек к общему времени

iscrafmtru55Если выборка тяжелая, то время ее выполнения значительно превышает время разбора SQL и в этом случае запись текста SQL в какую-то табличку (один из вариантов логирования) добавит даже не копейки, а доли копеек к общему времени
Вы не знаете этот текст и пишете для того, чтобы посмотреть что в нем?

1. если доступ не через приложение, то не знаю
2. есть такое понятие, как dynamic SQL, когда текст формируется налету в зависимости от конкретных условий
3. время и место посылки

egorychtru55,
я вам улыбаюсь ))

Да на здоровье

egorych
я говорю об отсутствии необходимости логирования селектов в хранимых процедурах, а вы про системные возможности Оракла, хоть в этом вы противоречие видите?

Первый вопрос прозвучал здесь
/topic/713143&pg=1#7969162
Фраза была о необходимости логировать SELECT вообще, а не конкретно в хранимых процедурах.
То, что в Oracle есть функциональность, позволяющая избежать кодирования этого в каждой процедуре, всего лишь упрощает разработку, но принцип необходимости логирования от этого не меняется

egorych
Мне не интересно, честно говоря, зачем в Оракл прикрутили такую функциональность, это дело компании Оракл. Мне даже не интересно, зачем вы проводите в топике рекламную компанию определённого вендора, хотя разговор ведётся "в общем виде".

Рекламой я не занимаюсь, не зачем мне это. Я привожу пример Oracle всего лишь потому, что знаю эту СУБД лучше других. Или мы отрицаем опыт других и доверяем только своему "чутью"?

egorych
Причём тут отчёты и запросы, выполняющиеся от десятков минут до нескольких часов? Они вообще не рассматриваются в этой теме. Вы уж простите, может вам топик перечитать с самого начала, чтобы понять о чём речь в треде ведётся?

Да ну? А кто упомянул про тяжелые запросы, да еще выдаваемые по "тыще в день"?
По поводу "прочитать с начала" - не имею привычки читать несколько последних сообщений.

iscrafmtru551. если доступ не через приложение, то не знаю
2. есть такое понятие, как dynamic SQL, когда текст формируется налету в зависимости от конкретных условий
3. время и место посылки
1. чуть выше шла речь о серьезных конторах...
2. DSQL от балды не формируется. Или имеется софт, где пользователь может написать любой текст запроса и отправить его на исполнение?
3. увидел что пользователь А делал select tr from whlog 10 раз, последний - 15 минут назад. И что? У него есть право этим заниматься.

1. и что? Тем паче, что "серьезная контора" - понятие растяжимое
2. DSQL формируется не от балды, но в некоторых случаях без него просто не обойтись. Поэтому как правило, в серьезных (:) ) системах он присутствует, вопрос только в количестве
3. про достаточность этих самых прав я уже говорил неоднократно

iscrafmtru551. и что? Тем паче, что "серьезная контора" - понятие растяжимое
2. DSQL формируется не от балды, но в некоторых случаях без него просто не обойтись. Поэтому как правило, в серьезных (:) ) системах он присутствует, вопрос только в количестве
3. про достаточность этих самых прав я уже говорил неоднократно
2. Если он не от балды формируется, то каким образом получается что его текст не известен. (у нас наверное разные понимание DSQL. Я под этим термином понимаю запрос, который получает СУБД извне)
3. Не знаю кому и что говорили, но они достаточны.

2a) разумеется неизвестен, и что?
2б) причем здесь извне? Можно и статический SQL получать извне (с клиента) и динамический формировать в ХП
3) в таких случаях принято добавлять ИМХО, поскольку мысль спорна

egorychtru55По поводу "прочитать с начала" - не имею привычки читать несколько последних сообщений.Да ну? А чего же вы даёте ссылки из середины треда, и без учёта контекста, который был задан цитатой в этом сообщении?

1. тогда надо точнее формулировать
2. я уже сказал выше, что логирование из своей процедуры или системными средствами - вопрос удобства, на принцип необходимости (хотя бы иногда) не влияет

TOAD здесь ни причем.
Есть разные случаи, когда без динамического SQL (вызываемого на выполнение через EXECUTE IMMEDIATE) не обойтись. Приведу один пример.
В OeBS есть так называемые гибкие поля. Эта вещь предназначена для настройки системы без участия программиста. Реализовано это так: в таблицах, где эта настройка позволяется, заведена куча доп. полей с именами ATTRIBUTE1..ATTRIBUTE30 (или SEGMENT1...). При настройке аттрибута в системных таблицах прописывается его контекст (что означает, приглашение в форме и проч.).
Если серверов несколько, то существует 2 подхода к таким настройкам (работал с обоими): либо эта настройка прописывается в какой-то доке и на всех серверах настраивается на 1 поле (например, attribute5), либо указывается только необходимость настройки, а на какое поле - пользователь (привилегированный пользователь) решает при выполнении этой настройки.
Выбор способа зависит от заказчика, поэтому не обсуждается.
Так вот, во втором случае когда я пишу SELECT, я заранее не знаю, на какое поле настройка (программа, разумеется, должна работать на всех серверах). Поэтому я сначала SELECT-ом по системным таблицам вытаскиваю имя поля, а потом формирую динамический SELECT, подставляя в него полученное имя.