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

Тут нет никакого корня :) То что Windows должна, она сделала - запустила службу. А вот уже по этому факту запустить базу - задача Оракла. И он ее не выполняет. И опять же, нет никаких гарантий, что мы гарантировано получили команду shutdown. Мы этого не знаем.

Безусловно речь не идет о восстановлении из бэкапа. Речь идет о том, что при открытии базы будет запущен механизм восстановления, который в том числе, сделает откат незавершенных транзакций. Но в данном случае я не вижу необходимости в столь крайних мерах. Я исхожу из того, что при рестарте службы, база нормально стартует. На сколько я знаю, по умолчанию, при останове службы выполняется именно shutdown immediate, а это значит, что в выполнении shutdown abort нет никакой необходимости. Кроме того, если помните, речь шла о том, что при подключении к такой "незапущенной" базе она находится все же в закрытом статусе. Т.е. мы подключаемся к простаивающему инстансу. Тогда тем более делать abort нет смысла. Хотя вероятно это и не повредит базе. Но опять же, исходя из опыта, нет гарантии, что так будет всегда. По моей логике, сначала нужно воспользоваться более "щадащими" процедурами. И если они не помогут, тогда уже думать что делать. Нет смысла подвергать базу дополнительному риску ради создания бэкапа. Так можно получить неработающими и базу и бэкап. Вы видимо уже догадываетесь, что ни о каких архивлогах и бэкапе на-лету речь не идет, и указанная Вами ситуация с потерей части бэкапа, тут вполне возможна :)

Немного подолью масла в огонь.

Сегодня утром не запустилась база на одном из магазинов. Вчера, позавчера и N дней тому назад всё было хорошо. Предыстория та же - ночной "холодный" бэкап без признаков каких-то аномалий.


В системном журнале Windows:

3:31:31 Служба "OracleServiceDBNAME" успешно отправила управляющий элемент "остановить".
3:31:32 Служба "OracleServiceDBNAME" перешла в состояние "Остановлена".
3:36:30 Служба "OracleServiceDBNAME" успешно отправила управляющий элемент "запустить".
3:41:30 Служба "OracleServiceDBNAME" перешла в состояние "Работает".


В журнале приложений:

.............
3:31:22 Audit trail: LENGTH : '157' ACTION :[8] 'SHUTDOWN' DATABASE USER:[3] 'sys' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[8] 'SMBackup' CLIENT TERMINAL:[9] 'SM-25SENT' STATUS:[1] '0' DBID:[0] '' .
3:31:22 Shutdown normal performed on instance DBname.
3:31:23 All process in instance DBname stopped
3:31:32 Audit trail: LENGTH : '152' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'SYSTEM' CLIENT TERMINAL:[9] 'SM-25SENT' STATUS:[1] '0' DBID:[0] '' .

3:36:31 Audit trail: LENGTH : '152' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'SYSTEM' CLIENT TERMINAL:[9] 'SM-25SENT' STATUS:[1] '0' DBID:[0] '' .
3:36:35 Initializing SGA for instance DBname.


9:14:23 "Не найдено описание для события с кодом ( 0 ) в источнике ( OracleServiceDBname ). Возможно, на локальном компьютере нет нужных данных в реестре или файлов DLL сообщений для отображения сообщений удаленного компьютера. Попробуйте использовать ключ /AUXSOURCE= для получения этого описания, - дополнительные сведения об этом содержатся в справке. В записи события содержится следующая информация: OracleServiceDBname error: 5; CreateMutex."
9:14:37 Audit trail: LENGTH : '152' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'SYSTEM' CLIENT TERMINAL:[9] 'SM-25SENT' STATUS:[1] '0' DBID:[0] '' .
9:14:38 Initializing SGA for instance DBname.
9:14:38 Initializing PGA for process PMON in instance DBname.
9:14:38 Initializing PGA for process VKTM in instance DBname.
9:14:38 Initializing PGA for process GEN0 in instance DBname.
9:14:39 Initializing PGA for process DIAG in instance DBname.
9:14:39 Initializing PGA for process DBRM in instance DBname.
9:14:39 Initializing PGA for process PSP0 in instance DBname.
9:14:39 Initializing PGA for process DIA0 in instance DBname.
9:14:39 Initializing PGA for process MMAN in instance DBname.
9:14:39 Initializing PGA for process DBW0 in instance DBname.
9:14:39 Initializing PGA for process LGWR in instance DBname.
9:14:39 Initializing PGA for process CKPT in instance DBname.
9:14:39 Initializing PGA for process SMON in instance DBname.
9:14:39 Initializing PGA for process RECO in instance DBname.
9:14:39 Initializing PGA for process MMON in instance DBname.
9:14:39 Initializing PGA for process MMNL in instance DBname.
...............

Наконец, alert.log самого Оракла:

Thu Feb 28 03:31:13 2013
Shutting down instance (immediate)
Stopping background process SMCO
Shutting down instance: further logons disabled
Stopping background process QMNC
Thu Feb 28 03:31:14 2013
Stopping background process CJQ0
Stopping background process MMNL
Stopping background process MMON
License high water mark = 43
ALTER DATABASE CLOSE NORMAL
Thu Feb 28 03:31:21 2013
SMON: disabling tx recovery
SMON: disabling cache recovery
Thu Feb 28 03:31:22 2013
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Thread 1 closed at log sequence 5337
Successful close of redo thread 1
Completed: ALTER DATABASE CLOSE NORMAL
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Thu Feb 28 03:31:23 2013
Stopping background process VKTM:
Thu Feb 28 03:31:25 2013
Instance shutdown complete


Thu Feb 28 03:36:32 2013
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_1 parameter default value as D:\oracle\ora112\RDBMS
Autotune of undo retention is turned on.
IMODE=BR
ILAT =27
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Release 11.2.0.1.0 - Production.
Using parameter settings in server-side spfile D:\ORACLE\ORA112\DATABASE\SPFILEDBNAME.ORA
System parameters with non-default values:
processes = 150
memory_target = 1704M
control_files = "D:\ORACLE\ORADATA\DBNAME\CONTROL01.CTL"
control_files = "D:\ORACLE\ORADATA\DBNAME\CONTROL02.CTL"
db_block_size = 8192
compatible = "11.2.0.0.0"
undo_tablespace = "UNDOTBS1"
O7_DICTIONARY_ACCESSIBILITY= TRUE
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
audit_file_dest = "D:\ORACLE\ADMIN\DBNAME\ADUMP"
audit_trail = "DB"
db_name = "DBNAME"
open_cursors = 300
diagnostic_dest = "D:\ORACLE"
Thu Feb 28 03:36:35 2013
ksuapc : ORA-1033 foreground process starts before PMON

Thu Feb 28 09:14:38 2013
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_1 parameter default value as D:\oracle\ora112\RDBMS
Autotune of undo retention is turned on.
IMODE=BR
ILAT =27
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Release 11.2.0.1.0 - Production.
Using parameter settings in server-side spfile D:\ORACLE\ORA112\DATABASE\SPFILEDBNAME.ORA
System parameters with non-default values:
processes = 150
memory_target = 1704M
control_files = "D:\ORACLE\ORADATA\DBNAME\CONTROL01.CTL"
control_files = "D:\ORACLE\ORADATA\DBNAME\CONTROL02.CTL"
db_block_size = 8192
compatible = "11.2.0.0.0"
undo_tablespace = "UNDOTBS1"
O7_DICTIONARY_ACCESSIBILITY= TRUE
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
audit_file_dest = "D:\ORACLE\ADMIN\DBNAME\ADUMP"
audit_trail = "DB"
db_name = "DBNAME"
open_cursors = 300
diagnostic_dest = "D:\ORACLE"
Thu Feb 28 09:14:38 2013
PMON started with pid=2, OS id=9912
Thu Feb 28 09:14:38 2013
ksuapc : ORA-1033 foreground process starts before PMON
Thu Feb 28 09:14:38 2013
VKTM started with pid=3, OS id=13256 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Thu Feb 28 09:14:38 2013
GEN0 started with pid=4, OS id=8092
Thu Feb 28 09:14:39 2013
DIAG started with pid=5, OS id=16540
Thu Feb 28 09:14:39 2013
DBRM started with pid=6, OS id=16952
Thu Feb 28 09:14:39 2013
PSP0 started with pid=7, OS id=16212
Thu Feb 28 09:14:39 2013
DIA0 started with pid=8, OS id=13016
Thu Feb 28 09:14:39 2013
MMAN started with pid=9, OS id=4020
Thu Feb 28 09:14:39 2013
DBW0 started with pid=10, OS id=11664
Thu Feb 28 09:14:39 2013
LGWR started with pid=11, OS id=7244
Thu Feb 28 09:14:39 2013
CKPT started with pid=12, OS id=16828
Thu Feb 28 09:14:39 2013
SMON started with pid=13, OS id=3324
Thu Feb 28 09:14:39 2013
RECO started with pid=14, OS id=9176
Thu Feb 28 09:14:39 2013
MMON started with pid=15, OS id=10644
Thu Feb 28 09:14:39 2013
MMNL started with pid=16, OS id=2412
ORACLE_BASE from environment = D:\oracle
Thu Feb 28 09:14:41 2013
alter database mount exclusive
Successful mount of redo thread 1, with mount id 3159427073
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: alter database mount exclusive
alter database open
Thread 1 opened at log sequence 5337
Current log# 3 seq# 5337 mem# 0: D:\ORACLE\ORADATA\DBNAME\REDO03.LOG
Successful open of redo thread 1
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is CL8MSWIN1251
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Thu Feb 28 09:14:52 2013
Starting background process QMNC
Thu Feb 28 09:14:52 2013
QMNC started with pid=18, OS id=6860
Completed: alter database open


Как видно, на сей раз старт инстанса начинается, но обрывается в 03:36:35 сообщением ksuapc : ORA-1033 foreground process starts before PMON
В это же время журнал приложений "радует" нас записью Initializing SGA for instance DBname.
А дальше - тишина вплоть до утра, когда в 09:14 делают рестарт сервиса.

Вот такая история ))

Вот и не надо из этого исходить :) Исходить надо из того, что база нормально отрабатывает передаваемые ей команды. А сервис для RDBMS - неродное и чуждое. По умолчанию передается то, что прописано в реестре, а в реестре, да, прописано immediate. Прошу еще раз вчитаться в то, что я писал выше. Внимательно. Особенно про пункт, касающийся влияния Windows на работу сервисов (WaitToKillServiceTimeout и прочая гадость, например, или работа машин в домене). Настаиваю, что пользоваться сервисом в Windows следует только в случаях, когда надо остановить БД вмертвую и чтобы никто не дергался запускать базу, когда она должна лежать.
Что касается журнала, то мне очень нравится термин ССЗБ, раскрывающий суть ваших действий. Прошу без обид, рекомендую ознакомиться с багом [ 8991997 ], поправленным в 11.2.0.2. Это еще безобидный баг, по сравнению с теми, которые вы можете огрести, непонятно зачем устанавливая 11.2.0.1. Неоднократно уже писалось, 11g ставить можно в лучшем случае с 11.2.0.3. Но зачем-то народ усиленно раскладывает грабли для последующего бега по ним.

Базы создавались давно, "во времена 11.2.0.1". Повторюсь - более полугода всё работало как часы.
Попробуем проапгрейдить до 11.2.0.3 в надежде, что проблема исчезнет. О результатах отпишусь.
Если у кого-то есть другие идеи или предложения - выслушаю с благодарностью.

Предложение делать бэкап RMAN чем не понравилось?

11.2.0.1 - это 2009 год. Не знаю, кто вас заставил ставить неработоспособную версию. Это времена 10.2.0.5, нормально работающей до сих пор. А 11.2.0.1 никто не ставил, только поиграть...

Не будем вдаваться в исторические подробности. Цитируя классику, сейчас вопрос в том, "что делать", а не "кто виноват".
RMAN - прекрасный инструмент, только вот о его существовании знают немногие клиенты. Я даже не говорю об умении этим инструментом пользоваться. При отсутствии средств удалённого доступа зачастую проще по телефону объяснить, как "подсунуть" файлы из холодного бэкапа, нежели сеять разумное и вечное, рассказывая, что такое командная строка и на какой кнопке какая латинская буква нарисована.

Подведу итог. Проблема исчезла после замены версии Оракла с 11.2.0.1 на 11.2.0.3. Что собственно помогло - новая версия или процедура экспорта-импорта базы данных - неизвестно. Но факт остаётся фактом, "проблемные" базы снова стартуют нормально.