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

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

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

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

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

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

ANB   (12.02.10 15:13) [40]


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


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


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


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


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


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

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


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

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

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


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

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

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

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

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

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

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


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

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

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


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

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

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

ANB   (15.02.10 14:05) [47]

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

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

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

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

???

ANB   (15.02.10 16:55) [49]

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


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


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

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

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

ANB   (15.02.10 17:24) [51]

Слив защитан

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

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

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

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

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

> ANB   (16.02.10 12:56) [54]


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

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

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

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

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

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


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


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

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

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

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

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

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