Прочитал про прекрасную заметку гражданки Mary Ann Davidson (удалена автором, копия для истории сохранена на seclists.org).

Вспомнилось, как я искал в программе на C++ ошибки с помощью valgrind. К изрядному неудобству, программа использовала клиентские библиотеки Oracle OCI, которые давали чудовищный объем срабатываний.

В итоге пришлось написать набор правил для подавления всех сообщений со стороны оракловых библиотек. В процессе изготовления правил поневоле пришлось смотреть и на сами сообщения - так вот чего там только не было, включая условные переходы, основанные на значениях неинициализированных переменных.

И ведь пипл блин хавает.
All database deadlocks fall into one of the following categories:
1. A row-level deadlock is always the application's bug
2. A table- or partiton-level deadlock caused by:
  (a) explicit application-controlled locking -
the application's bug
  (b) lock escalation - a configuration or application design issue
  (с) implicit operations at statement compilation stage - a DBMS bug
4. A deadlock involving any type of locks/latches on internal DBMS structures is always a DBMS bug

Навеяно работой.

UPDATE: В итоге оказалось, что 2(c) дискуссионно, поскольку настройки СУБД могут предписывать определенное поведение при компиляции запросов. В том числе и сбор статистик с блокировкой всей таблицы - хотя по моему скромному мнению, наличие таких настроек является дефектом дизайна СУБД.
Подправил руками программно сгенерированный запрос, попросил EXPLAIN PLAN.
Получил сообщение:
ORA-00600: internal error code, arguments: [kkqcscorcbk: correlated string not found.], [], [], [], [], [], [], [], [],
[], [], []

Долго думал.
Сегодня впервые после обновления Debian на рабочей машине со squeeze на wheezy попытался запустить Oracle.
И раз я об этом пишу, то, конечно же, оно не запустилось:
SQL> startup
ORA-00845: MEMORY_TARGET not supported on this system

Проверил shared memory. Все вроде как на месте:
$ df -m
Файловая система 1M-блоков Использовано Доступно Использовано% Cмонтировано в
rootfs 234452 144879 89573 62% /
udev 10 0 10 0% /dev
tmpfs 609 1 608 1% /run
/dev/disk/by-uuid/0e650596-b7ee-43a7-bd93-b3ecedd25599 234452 144879 89573 62% /
tmpfs 5 0 5 0% /run/lock
tmpfs 1979 313 1667 16% /run/shm
/dev/sda2 92 42 46 48% /boot
/dev/sdb1 240366 22306 205851 10% /cool

Насторожил переезд /dev/shm в /run/shm. Проверил, в /dev создана символьная ссылка shm -> /run/shm. Ага, подумал я.

Погуглил. Нашел вот это: http://wiki.debian.org/ReleaseGoals/RunDirectory

Ага. Типа теперь в /dev некошерно, и всё тащим в /run. И вот с таким типа комментарием:

"If you're using /dev/shm directly, then your package is broken. You should only be accessing it via the eglibc shm_* and sem_* functions implementing the POSIX SHM and SEM features."

Ну да, Oracle сломан, давно и надежно. А вы, ребята, при всём моём уважении, трогаете то, что работает.

Временно помог нехитрый рецепт:
mv /dev/shm /dev/shm.symlink
mkdir /dev/shm
mount --bind /run/shm /dev/shm

После этого Oracle соизволил запуститься.

Начал думать, как сделать то же самое автоматически при перезагрузке.
Пришел по почте бумажный сертификат OCP / 11g DBA. Интересные особенности:
  • На сертификате нет никакой идентицикационной информации, кроме моей ФИО и даты присвоения статуса. Никаких номеров, штрих-кодов и прочего - т.е. проверить подлинность выданного документа практически невозможно, по крайней мере, возможные методы проверки неочевидны.
  • Вместе с сертификатом пришла пластиковая карточка размером с кредитку. На карточке есть зачем-то полоска для личной подписи и опять-таки отсутствуют какие-либо идентификационные номера. Возможно, карточка чипованная, но это отнюдь не факт и даже IMHO маловероятно - слишком дорогое было бы удовольствие.
Возникает вопрос - а зачем карточка вообще нужна? Сертификат нужен, чтобы потешить самолюбие его владельца - глядишь, ещё на кого-нибудь сертифицироваться пойдёт, денежку заплатит. А вот зачем карточка-то?
Ну вот я и OCP / DBA 11g. С 22 июля, собственно. Бумажный сертификат ещё не пришел, но это дело времени.

С начала процедуры получения данного статуса прошел почти год - всё оказалось достаточно хлопотно, и в "фоновом режиме" (без отрыва от работы) на самом деле трудновыполнимо.

Последний шаг и вовсе оказался предельно хлопотным - без обучения по одному из одобренных курсов в авторизованном центре сертификация не подтверждается, сдай ты хоть сколько и хоть каких экзаменов. Минимальные затраты - три рабочих дня, 35 тыр и расходы на проезд в Москву и проживание в оной. Оплатил всё мой уважаемый работодатель, за что ему отдельное спасибо.
Сегодня мои усилия по формальному подтверждению квалификации дали некий пристойный результат - я успешно сдал IBM Exam 731 и теперь с полным правом могу именоваться "DB2 9 DBA for LUW".

Теперь ещё надобно аналогичную степень от Oracle получить. А потом ещё, наверное, пару разработческих сертификатов - и будет вчерне готов иконостас для введения работодателя в должное состояние. :)

Update: Чуть позже чисто по приколу без всякой подготовки прошел стартовый экзамен для получения статуса Ораклового DBA - 1Z0-051 "Oracle Database 11g: SQL Fundamentals I" (благо его можно проходить, не вставая из-за своего домашнего компьютера). Примерно к середине теста заподозрил, что, вероятно, выкинул $125 на помойку - вопросы стали касаться тонких деталей, которые лично моя память удерживать не привыкла. В итоге, по счастью, результат получился положительный, но больше такими экспромтами заниматься явно не стоит.
Чтоб не забыть в случае чего - а то каждый раз искать приходится.

В основном содрал отсюда.

1. SQL> CREATE PFILE=’/opt/oracle/admin/orcl/pfile/mypfile.ora’ FROM SPFILE;
2. Edit mypfile.ora for SGA_MAX_SIZE, SGA_TARGET, MEMORY_TARGET
3. SQL> STARTUP PFILE=’/opt/oracle/admin/orcl/pfile/mypfile.ora’
4. SQL>  CREATE SPFILE FROM PFILE=’/opt/oracle/admin/orcl/pfile/mypfile.ora’;
5. SQL> SHUTDOWN IMMEDIATE
6. SQL>STARTUP
Page generated Sep. 25th, 2017 09:46 am
Powered by Dreamwidth Studios