Спасибо за статью.
Маловато написано про параметры. По моему опыту обычно ставится:
LOG_CHECKPOINT_INTERVAL=0
LOG_CHECKPOINT_TIMEOUT=0
LOG_CHECKPOINTS_TO_ALERT=true
И основным параметром для настройки активности dbwr является:
FAST_START_MTTR_TARGET
Изначально можно поставить в 0 или 1800 и плавно уменьшать при наличии checkpoint not complete или желании более быстрого recover при crash.
Для скорости работы dbwr также критично наличие возможности асинхрнного ввода-вывода, определяется комбинацией операционной системы и используемого способа хранения datafiles (фс,raw,asm).
На практике в oracle все несколько иначе.
Oracle будет использовать обычный b-tree индекс без проблем (если, конечно, статистика по таблице актуальна). Ведь план строится не из абстрактных предположений, а просто по подсчету cost операции. Количество чтений для full scan таблицы будет значительно больше количества чтений для доступа по индексу, если кол-во записей в индексе заметно менее общего количества записей в таблице, т.е как раз в нашем случае, когда null-значения в индексе не хранятся.
Что касается bitmap-индексов, то их использования в OLTP лучше избегать, они предназначены для OLAP-систем с практически «read only» таблицами. Это связано как с тем, что update bit-map индекса более ресурсоемок, так и с тем, что механизм блокировок отличен и мы получим низкое быстродействие при множестве одновременно изменяющих данных сесссий.
Спасибо большое, статья очень понравилась.
Что касается индексов и null — для меня самый важный фактор это то, что null значения не хранятся в индексах.
На этом строится эффективная обработка больших объемов данных. Если в таблице есть поле, которое обозначает, обработана ли эта запись, то до обработки надо туда чего-то поставить отличное от null, а после успешной обработки сделать update этого поля в null. Ну и не забыть проиндексировать таблицу по этому полю, естественно.
Еще, наверное, можно упомянуть, что если поле is null и находится в конце строки, то оно не занимает место. За счет этого операция по добавлению нового столбца проходит практически мгновенно.
Статья, да, не совсем точная, но все же полезная.
По неточностям — чтение далеко не всегда идет через кэш. В 10g при параллелизации запроса параллельные сервера читают напрямую из датафайлов миную кэш. В 11g все еще как-то кручу в плане выбора, грузить в кэш или нет.
Про логирование индексов — это все играет роль только в момент построения индекса либо direct insert (insert с хинтом append либо параллельный insert). Для одиночных вставок всегда все логируется.
Про потерю данных и nologging — при обычном крэше данные потерять невозможно, только если придется по какой-то причине восстанавливать файл из бэкапа на момент до начала nologging операции и накатываться…
PA-RISC уже практически умер, посдение два-три года HP-UX на Itanium продается.
Но и на Itanium у HP-UX нерадужные перспективы в связи с отказом Oracle поддерживать эту платформу :(
В основном работаю с историческими таблицами, секционированными по дате.
Очень удобно, когда в имени секции соответствует хранимым в ней данным. Как для написания запросов с использованием from ...partiotion (...), так и для оценки размеров сегментов по вьюхам *_segments, так и для операций truncate, drop, split, exchange partition…
Есть еще одна мысль по поводу select count(1) из максимальной секции — на моей системе (vldb) это будет работать, возможно, более суток для всех таблиц и неприятно скажется на содержимом db_cache. Добавление же хинта parallel решит проблему, но создаст заметную нагрузку на систему.
Мне кажется более интересным вариант — обеспечить актуальную статистику и брать количество строк из поля dba_tab_partitions.num_rows :)
Я сам 3-ий выпуск ФТШ.
Мои дети в этом году заканчивают 4-ый класс. Вот, задумался о дальнейших вариантах…
Маловато написано про параметры. По моему опыту обычно ставится:
LOG_CHECKPOINT_INTERVAL=0
LOG_CHECKPOINT_TIMEOUT=0
LOG_CHECKPOINTS_TO_ALERT=true
И основным параметром для настройки активности dbwr является:
FAST_START_MTTR_TARGET
Изначально можно поставить в 0 или 1800 и плавно уменьшать при наличии checkpoint not complete или желании более быстрого recover при crash.
Для скорости работы dbwr также критично наличие возможности асинхрнного ввода-вывода, определяется комбинацией операционной системы и используемого способа хранения datafiles (фс,raw,asm).
еще group by не сортирует — это тоже частое заблуждение.
Oracle будет использовать обычный b-tree индекс без проблем (если, конечно, статистика по таблице актуальна). Ведь план строится не из абстрактных предположений, а просто по подсчету cost операции. Количество чтений для full scan таблицы будет значительно больше количества чтений для доступа по индексу, если кол-во записей в индексе заметно менее общего количества записей в таблице, т.е как раз в нашем случае, когда null-значения в индексе не хранятся.
Что касается bitmap-индексов, то их использования в OLTP лучше избегать, они предназначены для OLAP-систем с практически «read only» таблицами. Это связано как с тем, что update bit-map индекса более ресурсоемок, так и с тем, что механизм блокировок отличен и мы получим низкое быстродействие при множестве одновременно изменяющих данных сесссий.
Что касается индексов и null — для меня самый важный фактор это то, что null значения не хранятся в индексах.
На этом строится эффективная обработка больших объемов данных. Если в таблице есть поле, которое обозначает, обработана ли эта запись, то до обработки надо туда чего-то поставить отличное от null, а после успешной обработки сделать update этого поля в null. Ну и не забыть проиндексировать таблицу по этому полю, естественно.
Еще, наверное, можно упомянуть, что если поле is null и находится в конце строки, то оно не занимает место. За счет этого операция по добавлению нового столбца проходит практически мгновенно.
2:5030/389
Держал тогда ноду на работе с двумя круглосуточными линиями, около 30-ти пойнтов :)
Из минусов — сложнее выполняется профилирование запросов, подмена аутлайнов и т.п
По неточностям — чтение далеко не всегда идет через кэш. В 10g при параллелизации запроса параллельные сервера читают напрямую из датафайлов миную кэш. В 11g все еще как-то кручу в плане выбора, грузить в кэш или нет.
Про логирование индексов — это все играет роль только в момент построения индекса либо direct insert (insert с хинтом append либо параллельный insert). Для одиночных вставок всегда все логируется.
Про потерю данных и nologging — при обычном крэше данные потерять невозможно, только если придется по какой-то причине восстанавливать файл из бэкапа на момент до начала nologging операции и накатываться…
В Окее рядом с м.Электросила лежат пять журналов, разбирайте!
ru.wikisource.org/wiki/%D0%A2%D0%BE%D0%BB%D0%BA%D0%BE%D0%B2%D1%8B%D0%B9_%D1%81%D0%BB%D0%BE%D0%B2%D0%B0%D1%80%D1%8C_%D0%92._%D0%94%D0%B0%D0%BB%D1%8F/%D0%9A%D0%B0%D0%B7%D0%B0%D1%82%D1%8C_%E2%80%94_%D0%9A%D0%B0%D0%BA%D1%88%D0%B0
в данном котексте я его упортебил, чтобы подчеркнуть, что данная связка у меня работает уже давно.
Жаль, если Вы этого не поняли.
сколько тетрадок было исписано PDP-кодом самодельных игр… :)
Но и на Itanium у HP-UX нерадужные перспективы в связи с отказом Oracle поддерживать эту платформу :(
Очень удобно, когда в имени секции соответствует хранимым в ней данным. Как для написания запросов с использованием from ...partiotion (...), так и для оценки размеров сегментов по вьюхам *_segments, так и для операций truncate, drop, split, exchange partition…
Есть еще одна мысль по поводу select count(1) из максимальной секции — на моей системе (vldb) это будет работать, возможно, более суток для всех таблиц и неприятно скажется на содержимом db_cache. Добавление же хинта parallel решит проблему, но создаст заметную нагрузку на систему.
Мне кажется более интересным вариант — обеспечить актуальную статистику и брать количество строк из поля dba_tab_partitions.num_rows :)
Надо помнить, что в sequnce, по которому формируется id легко могут быть пропуски.
Например, из-за rollback-ов или, чаще, cache > 0.
Вообще большой незачет oracle за то, что не придумали механизм формирования нормального имени новой автоматически добавляемой партиции.