Не работает автостарт базы 11.2.0.1 : Oracle

Коллеги, доброго времени суток!

Прошу помощи у коллективного разума... )
Oracle 11.2.0.1. Неожиданно на нескольких магазинах начала проявляться такая проблема.
Утром, после ночного "холодного" бэкапа, пользователи не могут подключиться к Супермагу. Причина банальна - не стартует база данных. То есть - подключение sqlplus'ом показывает "connected to an idle instance". Команда startup ставит всё на свои места. Возраст проблемы - пара недель, по времени совпало с обновлением СМ+ с 1.029.2 до 1.029.3. Ранее в течение более чем полугода всё работало как часы.
Трагизм ситуации заключается в том, что проблема не является системной, т.е. появляется спонтанно и на разных магазинах. Может - на одном, может - на нескольких сразу. Ночной бэкап останавливает службы Супермага, потом делает базе shutdown immediate (смотрю по журналу бэкапа - отрабатывает корректно), далее останавливает службу OracleServiceИмяБД, копирует файлы базы и вновь запускает службу.
В системном журнале Windows видно, как служба останавливается и запускается вновь, причём успешно. А вот в оракловом alert.log есть "Instance shutdown complete", но ни малейшего намёка на попытку старта инстанса. Утром админы перезапускают руками службу OracleServiceИмяБД - и всё работает.
В реестре параметр ORA_ИМЯБД_AUTOSTART установлен в TRUE.
Может, кто-то уже натыкался на похожие грабли?

Куча направлений, куда копать (а неплохо было бы пояснить, что именно делаешь, т.е. чем)
1. 11.2.0.3 - самая ранняя версия, на которой можно пробовать работать
2. Не надо останавливать службу, shutdown immediate вполне достаточно
3. Не надо пользоваться автоматическим холодным бекапом :)

присмотрись, в свое время, когда я делал бекапер, я обходил эти грабли тем, что останавливал и запускал сервис дважды. За десять минут до бекапа - в первый раз и непосредственно перед ним - второй. Виндовс вещь в себе, поэтому на сервисы ее полагаться не сто́ит, стопь БД, этого более чем достаточно. Можно поставить в реестре, чтобы остановка сервиса соответствовала shutdown abort, но тут ты начинаешь двигаться в сторону ССЗБ, шаг в сторону которого ты сделал, начав пользоваться холодными бекапами без контроля человека.

За информацию спасибо.
Бэкап делается от имени пользователя с административными правами таким скриптом:

Вложения

backup11.7z (1.6 Кб, 114 просмотров)

ну вот,
выкинь вообще, а
замени на скрипт со startup force

Да, но startup force предварительно делает shutdown abort. Надо ли это нормально работающей базе?

а почему она должна быть нормально работающей, если до этого ей сказали shutdown immediate и дождались остановки? Зато стартует она из любого состояния, если сможет, конечно.

Потому что shutdown immediate работает несколько иначе и после его работы база остается в согласованном сосотоянии. Зато если по каким-то причинам база не закрылась и был выполнен shutdown abort получим базу в несогласованном состоянии, требующую дальнейшего, пусть и автоматического, но все же восстановления. А зачем подвергать базу таким испытаниям, если она нормально функционирует?

Предлагаю для начала определиться совпадает ли завершение shutdown immediate с вашим пониманием "база не закрылась". скрипт-то дальше работать не будет, пока она не отработает, не так ли? Есть, конечно, вариант с падением команды в какую-нибудь 600 или 7445, но как уже было сказано выше, испытание - это игра в рулетку с автоматическим холодным резервным копированием. Никогда не угадаете, что же скрипт в итоге скопировал. Предлагаю так же почитать на тему что же такое abort и чем он отличается, например, от прибивания процесса в системе. Никакой несогласованности в БД там нет, просто быстрая остановка без отката текущих транзакций. При старте они откатятся. Кролики не пострадают. Все равно хоть чуть значимые базы без архивлога не должны работать. У кого работают, тому они, значит, не нужны.

Давайте определяться. Да, Вы все логично описываете, но забываете, что точно так же, при старте службы, база должна была открыться или хотя бы попытаться это сделать. Но судя по журналу этого не происходит. В журнале нет ни строчки. Можно сделать вывод, что если эта операция не отрабатывает нужным образом или отрабатывает не всегда, то точно так же мы не можем гарантировать, что база была закрыта по комманде shutdown immediate.
Вот выдержки из документации:

You can shut down a database instantaneously by aborting the database's instance. If possible, perform this type of shutdown only in the following situations:
-The database or one of its applications is functioning irregularly and none of the other types of shutdown works.
-You need to shut down the database instantaneously (for example, if you know a power shutdown is going to occur in one minute).
-You experience problems when starting a database instance.

The next startup of the database will require instance recovery procedures.

Лично мне этого достаточно, что бы не использовать эту комманду для элементарной и штатной остановки базы с которой нет никаких проблем. Возможно Вы считаете иначе. Но тут мы с Вами в мнениях врядли сойдемся.

Полностью согласен. Но это не зависит от наших желаний.

Именно тут кроется корень заблуждения. Что должна или не должна Windows - понятие весьма относительное и кроется в массе параметров, в том числе общесервисных. Команду shutdown дали напрямую, поэтому ее гарантированно получили, дайте startup, тоже увидите какие-то следы ее выполнения/невыполнения.

Разве эти пункты расходятся с тем, что нам требуется? Если база не была остановлена нормальным shutdown immediate, то это первый случай. Если она застряла в каком-то промежуточном статусе - второй. Что касается слова recovery, то тут игра слов, скорее, вводит в заблуждение. Речь идет не о восстановлении из бекапа, а об откате незавершенных транзакций. Не будете же, надеюсь, настаивать, что все транзакции должны заканчиваться commit? А это как раз тоже самое. Подчеркиваю еще раз, это штатное завершение работы БД. Тем более той, которая не остановилась на shutdown immediate. А если она не остановилась, но уже получила команду останова, то никак больше, кроме abort, штатно ее вы уже не остановите. И работать не сможете. Зато, если кто-то не очень умелый смастерит запрос, отъедающий TEMP и UNDO, выставленные другим не очень умелым в unlimited, то хоть на излете суток его abort прибьет и, может быть, пересоздавать ничего не придется. Нюансы abort проявятся, если часть файлов бекапа потеряете, но это уже совсем другая история.