27.02.2013 17:15
orekhov
 
Коллеги, доброго времени суток!

Прошу помощи у коллективного разума... )
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.
Может, кто-то уже натыкался на похожие грабли?
27.02.2013 17:38
OlegON
 
Куча направлений, куда копать (а неплохо было бы пояснить, что именно делаешь, т.е. чем)
1. 11.2.0.3 - самая ранняя версия, на которой можно пробовать работать
2. Не надо останавливать службу, shutdown immediate вполне достаточно
3. Не надо пользоваться автоматическим холодным бекапом :)

присмотрись, в свое время, когда я делал бекапер, я обходил эти грабли тем, что останавливал и запускал сервис дважды. За десять минут до бекапа - в первый раз и непосредственно перед ним - второй. Виндовс вещь в себе, поэтому на сервисы ее полагаться не сто́ит, стопь БД, этого более чем достаточно. Можно поставить в реестре, чтобы остановка сервиса соответствовала shutdown abort, но тут ты начинаешь двигаться в сторону ССЗБ, шаг в сторону которого ты сделал, начав пользоваться холодными бекапами без контроля человека.
27.02.2013 18:39
orekhov
 
За информацию спасибо.
Бэкап делается от имени пользователя с административными правами таким скриптом:
Вложения
Тип файла: 7z backup11.7z (1.6 Кб, 107 просмотров)
27.02.2013 19:18
OlegON
 
ну вот,
Цитата:
net stop OracleService%oracle_sid%
sleep 10
выкинь вообще, а
Цитата:
net start OracleService%oracle_sid%
sleep 30
замени на скрипт со startup force
28.02.2013 09:53
YuraZ
 
Цитата:
OlegON замени на скрипт со startup force
Да, но startup force предварительно делает shutdown abort. Надо ли это нормально работающей базе?
28.02.2013 09:55
Troll
 
а почему она должна быть нормально работающей, если до этого ей сказали shutdown immediate и дождались остановки? Зато стартует она из любого состояния, если сможет, конечно.
28.02.2013 10:40
YuraZ
 
Цитата:
Troll а почему она должна быть нормально работающей, если до этого ей сказали shutdown immediate и дождались остановки? Зато стартует она из любого состояния, если сможет, конечно.
Потому что shutdown immediate работает несколько иначе и после его работы база остается в согласованном сосотоянии. Зато если по каким-то причинам база не закрылась и был выполнен shutdown abort получим базу в несогласованном состоянии, требующую дальнейшего, пусть и автоматического, но все же восстановления. А зачем подвергать базу таким испытаниям, если она нормально функционирует?
28.02.2013 10:49
Troll
 
Предлагаю для начала определиться совпадает ли завершение shutdown immediate с вашим пониманием "база не закрылась". скрипт-то дальше работать не будет, пока она не отработает, не так ли? Есть, конечно, вариант с падением команды в какую-нибудь 600 или 7445, но как уже было сказано выше, испытание - это игра в рулетку с автоматическим холодным резервным копированием. Никогда не угадаете, что же скрипт в итоге скопировал. Предлагаю так же почитать на тему что же такое abort и чем он отличается, например, от прибивания процесса в системе. Никакой несогласованности в БД там нет, просто быстрая остановка без отката текущих транзакций. При старте они откатятся. Кролики не пострадают. Все равно хоть чуть значимые базы без архивлога не должны работать. У кого работают, тому они, значит, не нужны.
28.02.2013 11:29
YuraZ
 
Цитата:
Troll Предлагаю для начала определиться совпадает ли завершение shutdown immediate с вашим пониманием "база не закрылась". скрипт-то дальше работать не будет, пока она не отработает, не так ли? Есть, конечно, вариант с падением команды в какую-нибудь 600 или 7445, но как уже было сказано выше, испытание - это игра в рулетку с автоматическим холодным резервным копированием. Никогда не угадаете, что же скрипт в итоге скопировал.
Давайте определяться. Да, Вы все логично описываете, но забываете, что точно так же, при старте службы, база должна была открыться или хотя бы попытаться это сделать. Но судя по журналу этого не происходит. В журнале нет ни строчки. Можно сделать вывод, что если эта операция не отрабатывает нужным образом или отрабатывает не всегда, то точно так же мы не можем гарантировать, что база была закрыта по комманде shutdown immediate.
Цитата:
Предлагаю так же почитать на тему что же такое abort и чем он отличается, например, от прибивания процесса в системе. Никакой несогласованности в БД там нет, просто быстрая остановка без отката текущих транзакций. При старте они откатятся. Кролики не пострадают.
Вот выдержки из документации:

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.

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

Цитата:
Все равно хоть чуть значимые базы без архивлога не должны работать. У кого работают, тому они, значит, не нужны.
Полностью согласен. Но это не зависит от наших желаний.
28.02.2013 12:22
Troll
 
Цитата:
YuraZ Давайте определяться. Да, Вы все логично описываете, но забываете, что точно так же, при старте службы, база должна была открыться или хотя бы попытаться это сделать. Но судя по журналу этого не происходит. В журнале нет ни строчки. Можно сделать вывод, что если эта операция не отрабатывает нужным образом или отрабатывает не всегда, то точно так же мы не можем гарантировать, что база была закрыта по комманде shutdown immediate.
Именно тут кроется корень заблуждения. Что должна или не должна Windows - понятие весьма относительное и кроется в массе параметров, в том числе общесервисных. Команду shutdown дали напрямую, поэтому ее гарантированно получили, дайте startup, тоже увидите какие-то следы ее выполнения/невыполнения.

Цитата:
YuraZ -The database or one of its applications is functioning irregularly and none of the other types of shutdown works.
-You experience problems when starting a database instance.
Разве эти пункты расходятся с тем, что нам требуется? Если база не была остановлена нормальным shutdown immediate, то это первый случай. Если она застряла в каком-то промежуточном статусе - второй. Что касается слова recovery, то тут игра слов, скорее, вводит в заблуждение. Речь идет не о восстановлении из бекапа, а об откате незавершенных транзакций. Не будете же, надеюсь, настаивать, что все транзакции должны заканчиваться commit? А это как раз тоже самое. Подчеркиваю еще раз, это штатное завершение работы БД. Тем более той, которая не остановилась на shutdown immediate. А если она не остановилась, но уже получила команду останова, то никак больше, кроме abort, штатно ее вы уже не остановите. И работать не сможете. Зато, если кто-то не очень умелый смастерит запрос, отъедающий TEMP и UNDO, выставленные другим не очень умелым в unlimited, то хоть на излете суток его abort прибьет и, может быть, пересоздавать ничего не придется. Нюансы abort проявятся, если часть файлов бекапа потеряете, но это уже совсем другая история.
Часовой пояс GMT +3, время: 12:03.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.