Помимо ста тысяч пятисот иных причин, почему 10 или 11 лучше предыдущих версий, есть еще одна. Это то, что 10 и 11 стали гораздо более снисходительны к идиоту.
История.
Один, отнюдь не маленький банк, решил, что держать у себя DBA это как-то расточительно. Примерно 10 месяцев базами данных рулил непонятно кто. К чести непонятно кого, базы ни разу за это время не перезапускали. Но ничто хорошее не может длиться вечно, поэтому в один прекрасный день какую-то из бд передёрнули. 9i после такого продемонстрировал весьма крутой норов: 1-2 минуты работы -- ступор (все транзакции останавливаются, подключиться можно только sqlplus " / as sysdba"); перезапуск - 1-2 минуты работы -- ступор, и так далее. Буквально за мгновение до того, как был написан скрипт для крона, перезапускающий базу каждые две минуты (я не шучу), к разбирательству подключили меня. Выяснилось вот что: база работала в ARCHIVE_LOG MODE ON, значит, отработавшие свое редо логи обязаны были архивироваться. Но вот незадача -- параметр ARCHIVE_LOG_START был равен FALSE. Это значит, что redo архивироваться автоматически не будут (!). Развязка древнегреческой трагедии: текущий редо не может переключиться (потому, что они переключаются только на лог, в состоянии ARCHIVED) в тоже время они не архивируются потому, что это не разрешено. При остановке экземпляра, один из журналов повтора все-таки откладывался в архив, поэтому после рестарта база какое-то время могла работать (пока не наступало время redo log switch).
В десятке понятное дело ARCHIVE_LOG_START уже в состоянии deprecated.
Если вы планируете в ближайшее время уволить своего дба, попросите его предварительно, мигрировать ваши базы на что-нибудь по-новее чем 7-8-9, продумать и реализовать стратегию бэкапирования, разработать сценарии действий в пяти-шести нештатных ситуациях, сделать какой-никакой DR. Если админ все это сделает подумайте еще раз сколько стоит пятичасовой (sic!) простой вашего бизнес-критичного-ынтырпрайз приложения и все-таки не увольняйте.
Комментариев нет:
Отправить комментарий