Дек 122014
 

Режим FORCE LOGGING нужно обязательно устанавливать на каждой вновь созданной базе, чтобы исключить проведение нелогируемых операций. Это абсолютно необходимо для нормальной работы DataGuard, репликации и успешного восстановления из резервных копий. Но бывают базы (обычно это хранилища данных), на которых ведётся обработка больших объёмов данных, потеря которых некритична (эти данные берутся, например, из других источников, и в случае потери их можно восстановить за приемлемое время, не прибегая к полному восстановлению из бэкапа). В таком случае было бы удобно отключить режим FORCE LOGGING на некоторых табличных пространствах, чтобы получить выигрыш в скорости обработки и уменьшить объём генерации redo-логов.
Проблема в том, что когда FORCE LOGGING включён на уровне всей БД, параметры логирования для отдельных табличных пространств игнорируются. Если же FORCE LOGGING на уровне базы отключить, чтобы создать табличное пространство для временных данных (не путать с temporary tablespace), то весьма велик риск при создании нового табличного пространства забыть явно включить для него FORCE LOGGING, и заметить это слишком поздно.
Решение - небольшой триггер, который не даст совершить подобную ошибку. Рассмотрим пример отключения FORCE LOGGING на одном из табличных пространств: Continue reading »

Фев 132013
 

При смене параметра optimizer_features_enable с 9.2.0.8 на 11.2.0.3, очевидно, могут сильно измениться планы запросов и их стоимость с точки зрения оптимизатора. Но есть и неочевидные следствия изменения поведения оптимизатора, об одном из которых и будет эта статья.

Начиная с версии Oracle 10g в запросах с группировкой вместо операции SORT GROUP BY при операциях сортировки может использоваться новый внутренний алгоритм сортировки, HASH GROUP BY. В общем случае (если не используется специфический хинт /*+ no_use_hash_aggregation */), предсказать, какой именно алгоритм выберет оптимизатор, нельзя. Для нас важно то, что в случае использования HASH GROUP BY поменяется порядок возвращаемых строк, т.е. результат будет неотсортированным!

Рассмотрим небольшой пример: Continue reading »

Мар 232012
 

Статья никоим образом не претендует на детальный мануал по настройке производительности UNIX-систем. Тут будет просто пара советов, как быстро найти проблему и попробовать понять, когда она началась. В целом, администратору баз данных этого будет достаточно. Continue reading »

Янв 272012
 

Обе утилиты экспорта данных, exp и expdp имеют параметр query, который позволяет экспортировать не все строки таблицы, а только те, которые попадают под условие. Беда в том, что в этом параметре допускается использовать только условие WHERE. Это может привести к тому, что план запроса, который будет использовать exp/expdp окажется крайне неоптимальным, и экспорт будет идти неприемлемо долго, хотя результирующий набор не такой уж большой.
Есть любопытный способ заставить утилиту использовать hint, тем самым выбирать оптимальный план выполнения. Continue reading »

Дек 232011
 

Про этот параметр писали уже много где, например, просто и толково на русском языке написано тут и тут. Причём много где утверждают, что установка данного параметра в значение FORCE или SIMILAR - априори хорошо и безвредно. В этой заметке я постараюсь разъяснить, почему это не совсем так. Continue reading »

Мар 282011
 

При анализе вывода утилиты vmstat в Solaris и HP-UX стоит обратить внимание на колонку sr (Scan Rate). Большие значения в этой колонке в течение продолжительного времени - признак того, что у системы начинаются проблемы с памятью. Такое бывает из-за неправильной конфигурации, утечек в приложениях, etc.

Что такое Scan Rate?

Continue reading »

Мар 152011
 

В Solaris и HP-UX есть утилита iostat, которая позволяет посмотреть статистику ввода-вывода по дискам. Но если используется Veritas Volume Manager, то удобнее будет воспользоваться утилитой /usr/sbin/vxstat, т.к. она показывает статистику не только по дискам, но и по томам, субдискам, плексам, и т.д.

Вот, например, как можно посмотреть статистику ввода-вывода в группе test с использованием мегабайт вместо блоков в качестве единицы измерения: Continue reading »

Фев 212011
 

Если на основном сервере в параметре log_archive_dest_n указана опция delay с ненулевым значением, то при выполнении операций, создающих большой объём redo (например, удаление или вставка большого количества данных в таблицы, импорт, пересекционирование крупных таблиц, etc.), возможна ситуация, при которой за этот временной промежуток нагенерится такое количество логов, что заполнится файловая система для их хранения и база остановится. Самое неприятное, что RMAN не бэкапит логи, которые ещё не были применены на standby-сервере.

Решение проблемы:

Continue reading »

Фев 102011
 

Впервые возможность быстрого секционирования (Fast Split Partitioning) появилась в 8 версии Oracle только для таблиц, секционированных стратегией range partitioning. В 9-й версии появилась возможность быстрого секционирования для стратегий LIST, RANGE-HASH и RANGE-LIST (о стратегиях секционирования я писал тут).
Чтобы был задействован механизм быстрого секционирования, нужно, чтобы выполнялись 3 условия: Continue reading »

Фев 032011
 

Секционирование таблиц и индексов в Oracle - неплохой способ повысить производительность базы данных и упростить администрирование. Все секции таблицы или индекса могут располагаться в разных табличных пространствах, что позволит, например, расположить их на разных дисках для увеличения производительности и степени параллелизма выполнения операций.
Oracle 10g поддерживает следующие виды секционирования: Continue reading »