Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 3 4 >
Гость © (2010-02-03 10:40:00)
Доброго дня!
Есть программа, которая выполняет в одной транзакции delete, insert, update. Есть триггер:

create or replace trigger SAMPLE_AUD
before insert or delete or update on SAMPLE_TABLE
for each row

, задача которого отловить все изменения и записать в таблицу аудита. Проблема в том, что отлавливается только insert. Можно ли сделать так, чтобы триггер отрабатывал на каждую команду в транзакции?

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

Petr V. Abramov (2010-02-25 22:31:00) [2]

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

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

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

ANB (2010-02-18 17:21:00) [3]

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

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

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

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

Кщд (2010-02-18 14:24:00) [4]
>А практика говорит наоборот.
>Прикрутил хэш джойн и получил значительное ускорение.
возможно, оптимизатор сошел с ума?)
или баг
даже не заглядывая в план и не высчитывая стоимость запроса понятно, что эффективнее произвести 50 000 index unique scan
на 10.2.0.4 мне воспроизвести указанного Вами не удалось

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

Игорь Шевченко (2010-02-18 12:20:00) [5]
Кщд (18.02.10 11:51) [58]

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

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

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

ANB (2010-02-18 12:19:00) [6]

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

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

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

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

Игорь Шевченко (2010-02-17 15:06:00) [8]
Кщд (17.02.10 12:20) [56]

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

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

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

Кщд (2010-02-17 12:20:00) [9]
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 имеет к данному тест-кейсу?

Petr V. Abramov (2010-02-16 23:06:00) [10]

> ANB (16.02.10 12:56) [54]

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

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

ANB (2010-02-16 12:56:00) [11]
Блин, нигде не могу скачать тома кайта нужную книжку.
Может ссылку кто кинет ?

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

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

Petr V. Abramov (2010-02-16 03:13:00) [12]

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

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

Игорь Шевченко (2010-02-15 18:14:00) [13]
ANB (15.02.10 17:24) [51]

Слив защитан

ANB (2010-02-15 17:24:00) [14]

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

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

Игорь Шевченко (2010-02-15 17:10:00) [15]
ANB (15.02.10 16:55) [49]

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

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

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

ANB (2010-02-15 16:55:00) [16]

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

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

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

???

Игорь Шевченко (2010-02-15 14:07:00) [17]
ANB (15.02.10 14:05) [47]

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

ANB (2010-02-15 14:05:00) [18]

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

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

Игорь Шевченко (2010-02-15 12:45:00) [19]

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

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

ANB (2010-02-15 11:38:00) [20]

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

Имеем 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

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

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

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

Страницы: 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »