Авг 052014
 

Dblink - интересный и в то же время неприятный объект. Дело в том, что в синтаксисе Oracle нет способа просто проверить, работает он или нет, если он находится в другой схеме. Доступ через точку, в отличие от других объектов, не работает, т.к. точка может являться частью имени dblink'а.
Возникла задача: проверить работоспособность всех линков в базе. Просто SQL-запрос сделать не удалось (это, на мой взгляд, всегда немного элегантнее и удобнее, чем блок PL/SQL), но нашлось отличное решение индийского коллеги: вот. Скрипт хороший, но он пишет текстовый лог, что неудобно, если у нас действительно много линков. Я немного его модифицировал, теперь он создаёт табличку, в которую пишет имя линка, его владельца и статус проверки. Так будет удобнее работать со списком, можно будет применять к нему любые фильтры и сортировки и использовать его для генерации скриптов, например, для удаления лишних dblink'ов.
Итак, скрипт: Continue reading »

Дек 292012
 

Начиная с версии 10g, в представлении v$session появилось поле blocking_session, которое содержит SID сессии, блокирующей исходную. В 11.2.0.3 всё стало ещё удобнее, ибо появилось поле final_blocking_session, в котором указан SID сессии, являющейся "корнем" дерева блокировок. Убиваем её и либо всё дерево блокировок разрешается, либо "корнем" становится другая сессия. Как говорится, в таком случае надо смыть, повторить.

Если поля final_blocking_session в v$session нет, то нам поможет иерархический запрос. Continue reading »

Окт 192012
 

Иногда бывает полезно сделать таблицу доступной только на чтение. В ORACLE 11g с этим проблем нет. Есть штатные команды:

ALTER TABLE cube_tab READ ONLY;
ALTER TABLE cube_tab READ WRITE;

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

Сен 202012
 

Наткнулся сегодня на интересное явление: после попытки завершения любой сессии путём убивания серверного процесса командой kill -9, PMON не вычищает эту сессию из v$session и не освобождает блокировки. Таким образом, не удаётся убить никакую сессию, даже сессию, не выполняющую никаких транзакций. При этом и "убитые" сессии и сам PMON висят с ожиданием latch free. Версия ORACLE - 9.2.0.8.

Решение найти удалось, но довольно странное. Continue reading »

Сен 072012
 

Начиная с ORACLE 10g появилась поддержка так называемых Bigfile tablespaces (далее - BFT). От обычных табличных пространств они отличаются тем, что состоят только из одного файла данных, но при этом файл может быть очень большого размера.
Раньше, например, в версии 9i, размер файла данных не мог превышать 4M - 1 блоков, т.е. для файла с размером блока 8K было ограничение 4 \cdot 8192 \cdot 1024^2 - 8192 = 34359730176 \approx 32G. Поэтому для действительно больших табличных пространств приходилось создавать несколько (иногда очень много) файлов, что усложняло администрирование базы. Continue reading »

Апр 282012
 

В ORACLE 11g все пароли по умолчанию стали чувствительными к регистру. В предыдущих релизах пароли были регистронезависимыми. Для управления чувствительностью появился специальный параметр sec_case_sensitive_logon. Вот так меняется настройки чувствительности:
Continue reading »

Мар 122012
 

При миграции БД с версии 10.2.0.4 на 11.2.0.3 вылез неприятнейший Bug 11074304, связанный с несовместимостью с пакетами, обработанными утилитой WRAP версии 9 с БД релиза 11.2.0.3. Патча для этого бага нет, а ставить старый релиз (в 11.2.0.1 этой проблемы почему-то нет) не хочется.
Решение вроде простое - обработать все пакеты WRAP'ом заново, но есть загвоздка: нет тривиального способа определить, какой версией WRAP'а пакет обработан.
Проведём небольшой эксперимент: обработаем какой-нибудь пакет 9 и 10 WRAP'ом и посмотрим его код, чтобы найти различия.
Итак, результат 9 WRAP: Continue reading »

Мар 072012
 

Роль DBA предоставляет пользователю все системные привилегии с опцией WITH ADMIN OPTION. Давать эту роль кому попало - не очень хорошо с точки зрения безопасности, да и ORACLE грозится в будущих релизах от неё отказаться. В документации к 11-й версии роль DBA описана как устаревшая.
Вместо неё предлагается создавать свои роли, "заточенные" под конкретные задачи.
Пусть нам надо создать пользователя, который будет создавать схемы и больше ничего. Сначала посмотрим, что может делать DBA: Continue reading »

Фев 222012
 

Если вдруг возникла необходимость быстро определить максимально отдалённый момент, на который можно восстановить базу, можно воспользоваться таким трюком (подразумевается использование Veritas NetBackup):

Определим имена всех backup pieces, относящихся к нашей базе: Continue reading »

Дек 162011
 

По просьбам трудящихся, оставленным в комментариях к этому посту, решил написать, как анализировать redo logs на другой базе. Здесь подразумевается, что база, с которой мы взяли логи (далее исходная) и та, на которой мы будем их анализировать (далее целевая) одной и той же версии и работают на железе одинаковой архитектуры и на одинаковых ОС.
Такой анализ немного осложняется тем, что на целевой базе скорее всего будут отсутствовать объекты, которые есть на основной и в результате этого в колонках sql_redo и sql_undo представления v$logmnr_contents вместо понятного sql-выражения будет нечто невразумительное, что-то вроде этого:

INSERT INTO Object#2581(col#1, col#2) VALUES (HEXTORAW('4a6f686e20446f65'), HEXTORAW('c306'));

Чтобы избежать подобного эффекта, создаётся так называемый LogMiner dictionary, который может находиться как в отдельном файле, так и быть частью redo log'а.
Итак, у нас есть 2 способа создать словарь: Continue reading »