Аудит триггером составной транзакции

← →
ANB (2010-02-12 15:13) [40]

> Том Кайт - рулез фарева

И на солнце бывают пятна. Так что рулез, но ошибки в его книжке тоже есть.

Практика - вот рулез.

Поддерживаю Кщд. Многие встроенные вещи в оракл реализованы довольно громоздко, не всегда работоспособны и тяжеловаты в настройке. Частенько проще повесить простенький триггер и не мучится. Кстати, простенький триггер зачастую шустрее встроенных вещей.

Архив логи же - штука мощная, но не всегда удобная.
1) Они толстые, у нас их чистят каждый день, причем держат максимум 2 дня.
2) Разбираться в них повесишься.
3) Не всегда в них содержиться ВСЯ нужная информация хотя бы для того же логгирования.

И по поводу прав. Типичная ситуация. Есть 5 юзеров, которые отвечают за конкретный интерфейс. Никто другой вломиться туда не может. В какой то момент выясняется, что в системе сидят кривые данные, из-за того, что кто то что не так настроил или удалил. Первым делом начальство спрашивает - кого драть ? Тут простенькая таблица нам этого кого то вычисляет в течение минуты. Причем со всеми координатами - имя юзера ОС, IP, с какой машины в сети, под каким логином.

← →
Игорь Шевченко © (2010-02-12 19:31) [41]

ANB (12.02.10 15:13) [40]

> Практика - вот рулез.

Кривая практика - ни разу не рулез.

> Многие встроенные вещи в оракл реализованы довольно громоздко,
> не всегда работоспособны и тяжеловаты в настройке. Частенько
> проще повесить простенький триггер и не мучится. Кстати,
> простенький триггер зачастую шустрее встроенных вещей.

Как показывает, опять же, практика, попытки заменить встроенные в сервер средства оборачиваются велосипедом с квадратными колесами и смещенной осью.

> И на солнце бывают пятна. Так что рулез, но ошибки в его
> книжке тоже есть.

Тут нефигово бы привести примеры.

← →
Кщд (2010-02-13 12:33) [42]

>Игорь Шевченко © (12.02.10 19:31) [41]

> Как показывает, опять же, практика, попытки заменить встроенные
> в сервер средства оборачиваются велосипедом с квадратными
> колесами и смещенной осью.

повторюсь: своя система авторизации/аутентификации - это не попытка заменить встроенные средства.
отнюдь.

← →
Petr V. Abramov © (2010-02-14 16:48) [43]

> Игорь Шевченко © (12.02.10 19:31) [41]

> Как показывает, опять же, практика, попытки заменить встроенные
> в сервер средства оборачиваются велосипедом

тут есть важный частный случай - встроенные средства встроены в Enterprise Edition и не встроены в стандарт.

← →
Игорь Шевченко © (2010-02-15 01:19) [44]

Petr V. Abramov © (14.02.10 16:48) [43]

Безусловно. Но не все встроенные средства встроены только в Enterprise, audit,например, есть в стандарте. Кроме того, от версии к версии часть встроенных средств переносится из Enterprise в standard.

← →
ANB (2010-02-15 11:38) [45]

> Тут нефигово бы привести примеры.

Имеем 2 таблицы.

create table T1
(
Acc varchar2(20)
)

create table T2
(
Acc varchar2(20)
,AccName varchar2(2000)
)

create unique index T2 on T2(Acc)

В T1 50 тысяч записей, в T2 - 60 миллионов записей

запрос
select
T2.*
from
T1
,T2
where
T2.Acc = T1.Acc

Вопрос - по какому плану лучше пустить запрос ? Том Кайт утверждает, что лучше по индексу нестед лупсом.

> Как показывает, опять же, практика, попытки заменить встроенные
> в сервер средства оборачиваются велосипедом с квадратными
> колесами и смещенной осью.

Как показывает практика, все с точностью до наоборот.
Пример : писалась репликация клиентских реквизитов между головным офисом и филиалами. Есно, сначала были перепробованы стандартные средства (начали с двухсторонней адвансед репликации). Получилась такая тормозная и глючная ерунда, что просто ужас. Угрохана куча времени (и денег, есно). Когда понимаем, что в таком виде репликация никому не нужна, сажусь и за три дня пишу тупо все на триггерах. Третий год все работает без ошибок. Одну накопали - я про транкейт забыл. В течение часа поставили еще один триггер и не паримся.

← →
Игорь Шевченко © (2010-02-15 12:45) [46]

> Том Кайт утверждает, что лучше по индексу нестед лупсом.

в какой версии оракла ?

← →
ANB (2010-02-15 14:05) [47]

> в какой версии оракла ?

9 и 10. На обоих проверял.
Фулл скан шустрее намного. Нестед лупсом гонял 40 минут, не дождался - срубил. Фулл скан - 4 минуты и все отработало.

← →
Игорь Шевченко © (2010-02-15 14:07) [48]

ANB (15.02.10 14:05) [47]

А Кайт про какую версию писал ?

← →
ANB (2010-02-15 16:55) [49]

> А Кайт про какую версию писал ?

Значит уже для 9-ки его советы неприменимы ?
Тогда как понимать :

> Том Кайт - рулез фарева

???

← →
Игорь Шевченко © (2010-02-15 17:10) [50]

ANB (15.02.10 16:55) [49]

Так про какую версию Кайт писал ? Ты книгу-то назови, а можешь и главу со страницей назвать.

> Тогда как понимать :
>
> > Том Кайт - рулез фарева
>
> ???

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

← →
ANB (2010-02-15 17:24) [51]

> Так про какую версию Кайт писал ? Ты книгу-то назови, а
> можешь и главу со страницей назвать.

Лениво искать. Смотри Кайт Оптимизация.

← →
Игорь Шевченко © (2010-02-15 18:14) [52]

ANB (15.02.10 17:24) [51]

Слив защитан

← →
Petr V. Abramov © (2010-02-16 03:13) [53]

> Вопрос - по какому плану лучше пустить запрос ? Том Кайт
> утверждает, что лучше по индексу нестед лупсом.
>
>

да, ты покажи, где утверждает?
и неужто такой умный/добрый дядька про nv/ndv и про гистограммы забыл/незнал/скрывает
???

← →
ANB (2010-02-16 12:56) [54]

Блин, нигде не могу скачать тома кайта нужную книжку.
Может ссылку кто кинет ?

Леплю отсебятину - точно помню фразу в книжке по оптимизации
"Если отбирается более 10 процентов от всей таблицы, нужно смотреть в сторону фулл-скана".
Каюсь, обратной фразу (если меньше 10% - то индекс) я не видел. Вроде как подразумевалось.

Собственно, я и не спорю, что тома кайта читать не надо. Надо, но рекомендации (и домысливание рекомендаций) лучше проверять практикой.

← →
Petr V. Abramov © (2010-02-16 23:06) [55]

> ANB (16.02.10 12:56) [54]

> Каюсь, обратной фразу (если меньше 10% - то индекс)

индекс индексу рознь.
можно из-за 3% попасть в scattered read, что на хорошей таблице - длительный перекур, а можно и и 10% прочитать влет, например, по хрестоматийному индексу по дате.
пример из [45], судя всему, раз плохой случай, пусть в условие попадает 1%, но значения форина чаще всего размазаны по таблице.

← →
Кщд (2010-02-17 12:20) [56]

create table T1 ( Acc varchar2(20) ) create table T2 ( Acc varchar2(20) ,AccName varchar2(2000) ) create unique index T2 on T2(Acc) select T2.* from T1 ,T2 where T2.Acc = T1.Acc
здесь однозначно лучше full(t1) и nested loops с index unique scan по T2

>Petr V. Abramov © (16.02.10 23:06) [55]
scattered read вовсе не обязательное следствие FTS

>раз плохой случай, пусть в условие попадает 1%, но значения форина >чаще всего размазаны по таблице.
поясните, пожалуйста, подробнее, что имелось в виду?
что плохого в этом случае?
и если форин=FK, то какое отношение FK имеет к данному тест-кейсу?

← →
Игорь Шевченко © (2010-02-17 15:06) [57]

Кщд (17.02.10 12:20) [56]

> здесь однозначно лучше full(t1) и nested loops с index unique
> scan по T2

Почему (например) не hash join ?

Наиболее однозначный ответ даст трассировка события 10053 :)

← →
Кщд (2010-02-18 11:51) [58]

>Игорь Шевченко © (17.02.10 15:06) [57]
>Почему (например) не hash join ?
возможно, потому, что table access full хуже index unique scan в данном случае?)
конкретно: 50 000 индексных чтений с NL лучше hash join с шестидесятимиллионной таблицей

← →
ANB (2010-02-18 12:19) [59]

> конкретно: 50 000 индексных чтений с NL лучше hash join
> с шестидесятимиллионной таблицей

А практика говорит наоборот.

Прикрутил хэш джойн и получил значительное ускорение.

Кщд (18.02.10 11:51) [58]

> возможно, потому, что table access full хуже index unique
> scan в данном случае?)
> конкретно: 50 000 индексных чтений с NL лучше hash join
> с шестидесятимиллионной таблицей

прошу прощения, не соотнес твой пост с характеристиками таблиц из [45]

То есть, Кайт реабилитирован ?

← →
Кщд (2010-02-18 14:24) [61]

>А практика говорит наоборот.
>Прикрутил хэш джойн и получил значительное ускорение.
возможно, оптимизатор сошел с ума?)
или баг
даже не заглядывая в план и не высчитывая стоимость запроса понятно, что эффективнее произвести 50 000 index unique scan
на 10.2.0.4 мне воспроизвести указанного Вами не удалось

>То есть, Кайт реабилитирован?
Кайт - душка навсегда, в чем лично я ни разу не сомневался)

← →
ANB (2010-02-18 17:21) [62]

> возможно, оптимизатор сошел с ума?)

У нашего оптимизатора давно крыша съехала. Хинтим все запросы. Пробовали собирать статистику - стало еще хуже. :)

Но это не в оптимизаторе дело - он то как раз нестед лупс и предлагает.

Это опыт - если в первой таблице записей >= 30 тысяч, то на нашей базе надо пускать фулл-скан по обоим.
Если меньше - экспериментируем.

> Кщд (17.02.10 12:20) [56]

> >чаще всего размазаны по таблице.
> поясните, пожалуйста, подробнее, что имелось в виду?
> что плохого в этом случае?
> и если форин=FK, то какое отношение FK имеет к данному тест-
> кейсу?

тесткейс посмотрел невнимательно, припишем там where FK = :param
блок 8К допустим. запись - 80 байт допустим. В каждом блоке есть одна (ну несколько) запись(ей) с FK=условие (FK размазан по таблице). Вроде б "в индекс" попадает несколько процентов, клево все. Только один фиг прочитать надо ВСЮ таблицу, и не блок-за-блоком, в произвольном порядке.

← →
Кщд (2010-02-26 08:28) [64]

>Petr V. Abramov © (25.02.10 22:31) [63]
укажите, пожалуйста, запрос полностью?
из вышеприведенного логика выбора hash join вместо nested loops не видна...
не понял, зачем читать таблицу, если можно обойтись только чтением индекса?

Аудит триггером составной транзакции Найти похожие ветки