Новое имя "The Daily WTF"

Мне нравится эта идея.

Что может быть хуже провала? Выставление его в качестве успеха.

Теперь это Worse Than Failure.

Апгрейд наоборот

Это когда вопрос "что теперь мы можем ускорить?" задаётся после того, как был произведён апгрейд.

Результатом действительно может быть "апгрейд наоборот".

Где пароли?

Самолёт без крыльев

Я всегда говорил, что спроектировать OLTP-систему без bind-переменных - это всё равно, что построить самолёт без крыльев. В том смысле, что построившие самолёт без крыльев инженеры знают о самолётостроении столько же, сколько такие разработчики знают о СУБД Oracle.

Конечно, можно приклеить крылья. К сожалению, нельзя точно так же "приклеить" дизайн. Летать, скорее всего, всё равно ничего не будет.

Вы уже поняли - я не буду ожидать от такой системы ничего хорошего.

Можно не шифровать?

Среди прочего, в ссылке чуть выше, я упоминаю, что они использовали фиксированный ключ DES для шифрования пароля, который можно легко достать просто сделав rewrap пакета.

Оказалось, что даже такое шифрование скорее выглядит как пустая потеря времени.

Последний раз я видел нечто подобное, когда последний раз был в Екатеринбурге. Разработчики (или я должен называть их кодерами?) забыли использовать bind-переменные в функциях аутентификации. В итоге, все имена пользователей с соответсвующими паролями были просто видны в v$sql.

Пришло время для очередной вариации. Заглянув в v$sql, я обнаружил там следующее:

select CHR(98)||CHR(117)||CHR(108)||CHR(107)||CHR(105)||
CHR(110)||CHR(97) from dual
select CHR(112)||CHR(111)||CHR(122)||CHR(100)||CHR(110)||
CHR(101)||CHR(118) from dual
select CHR(74)||CHR(117)||CHR(107)||CHR(111)||CHR(118)||
CHR(97) from dual

и так далее... Угадайте что это. Это пароли.

Не выглядят ли все попытки обеспечить безопасность на фоне таких систем как бронирование парадной двери, в то время как с чёрного хода к вам уже ломятся мародёры?

Бесконечная история, часть IV

Был там, делал это

Описанный в предыдущей части "конвейер" представлял собой наиболее критичный бизнес-процесс во всей системе - он был ответственен за предоставление квантов времени для абонентов.

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

Реализованные идеи были довольно просты и прямолинейны. Первостепенно - необходимо было избавиться от излишнего LIO у каждого процесса-переносчика, таким образом, снизив нагрузку на CBC latches и предоставив возможность каждому переносчику работать более эффективно. Исходные таблицы были секционированы (list partitioning) по shadow-колонке, в которую записывался результат mod(key, 16). Каждый процесс теперь работал со своей собственной секцией. Переход на простое число в качестве аргумента mod был оставлен на факультатив местным DBA.

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

"Row by row is slow by slow" © Tom Kyte

Поэтому они были переписаны на bulk-обработку через forall. В результате этих действий, общее LIO системы сразу снизилось на 40% и она ожила.