Дек 122014
 

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

Авг 052014
 

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

Мар 252014
 

О том, что делать в случае переполнения файловой системы и как определить, какой каталог занимает много места, я уже писал.
Но бывают и ситуации поинтереснее. Например, есть некий процесс, непрерывно пишущий огромный лог. Кто-то этот самый лог удаляет командой rm, и мы наблюдаем странные вещи: свободное место на разделе уменьшается, а файла, занимающего кучу места, нет! Дело в том, что даже после удаления файла из файловой системы, в структурах памяти ОС остаётся открытым т.н. дескриптор файла. А пока у файла остаётся хотя бы один дескриптор (и не важно, в памяти он или на файловой системе), место на диске не освобождается. Continue reading »

Янв 152014
 

С точки зрения usability незаменимая утилита SQL*Plus представляет собой насилие над пользователем, и к использованию человеком, хоть раз увидившим нормальный софт, написанный с использованием библиотеки readline, совершенно непригодна.
К счастью, существует великолепная утилита rlwrap. Она создаёт обёртку из readline для SQL*Plus, что позволяет нормально редактировать команды, искать по истории команд, и даже использовать автодополнение!
Просто установить rlwrap мало, его надо правильно приготовить. Об этом и будет статья.

Готовим rlwrap для SQL*Plus.

Continue reading »

Ноя 142013
 

Обнаружил, что по какой-то причине агент Enterprise Manager Cloud Control 12c на одном из серверов БД не запускается. При попытке запуска командой

emctl start agent

в логе видим такие строки (выделил красным интересное): Continue reading »

Сен 272013
 

Режим block change tracking в ORACLE 10g и выше позволяет уменьшить время инкрементального бэкапа за счёт ведения лога изменённых блоков с момента бэкапа предыдущего уровня.

Как это работает?

Continue reading »

Авг 232013
 

Распаковывал тут tar-архив на IBM AIX 7.1 и словил такую ошибку:

tar: 0511-169 A directory checksum error on media; -260707784 not equal to 33314.

Гуглением обнаружился интересный баг: Оказывается, стандартный IBM-овский tar имеет проблемы с длинными именами файлов, и поэтому IBM рекомендует (sic!) использовать GNU tar.
Т.е. заменяем при распаковке вот это:

tar -xf db3.tar

На

gtar -xf db3.tar

И всё прекрасно работает!

Адский ад, конечно.

Авг 062013
 

Роль по умолчанию для пользователя - это роль, которая применяется сразу в момент соединения. Т.е. возможна ситуация, когда пользователю дана некая роль, но она не указана как DEFAULT ROLE. В таком случае он часто не может самостоятельно ею воспользоваться, звонит и задаёт неудобные вопросы.
Рассмотрим ситуацию чуть более подробно, проведём небольшой эксперимент: Continue reading »

Апр 182013
 

В силу некоторых неприятностей с дисками оказалась испорчена база и бэкап (да, я знаю, что это epic fail, но база не очень важная и когда её потерю заметили, бэкап уже устарел и его удалил скрипт).
Чудом сохранился только дамп, сделанный утилитой exp. Всё было бы неплохо, но этот дамп тоже оказался побитым. На импорте одной из таблиц сессия импорта зависала навечно. К счастью, эта таблица содержала маловажные данные (лог неких операций), от которых можно было безболезненно отказаться.
Итак, попробуем починить файл дампа.

Как мы знаем, классический exp сохраняет данные в полутекстовом формате. Поэтому ничто нам не помешает найти определение испорченной таблицы в файле и вырезать его и все данные этой таблицы из дампа, используя стандартные утилиты linux. Определение таблицы предваряется строкой:

TABLE "ACT_HIST"

Здесь ACT_HIST - имя нашей испорченной таблицы.

Итак, найдём номер строки в файле, где начинается наша таблица ACT_HIST: Continue reading »