[ОТВЕТИТЬ]
Опции темы
28.02.2013 12:57  
YuraZ
Цитата:
Сообщение от Troll
Именно тут кроется корень заблуждения. Что должна или не должна Windows - понятие весьма относительное и кроется в массе параметров, в том числе общесервисных. Команду shutdown дали напрямую, поэтому ее гарантированно получили, дайте startup, тоже увидите какие-то следы ее выполнения/невыполнения.
Тут нет никакого корня :) То что Windows должна, она сделала - запустила службу. А вот уже по этому факту запустить базу - задача Оракла. И он ее не выполняет. И опять же, нет никаких гарантий, что мы гарантировано получили команду shutdown. Мы этого не знаем.

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

Сегодня утром не запустилась база на одном из магазинов. Вчера, позавчера и 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 делают рестарт сервиса.

Вот такая история ))
 
28.02.2013 13:45  
Troll
Цитата:
Сообщение от YuraZ
Я исхожу из того, что при рестарте службы, база нормально стартует. На сколько я знаю, по умолчанию, при останове службы выполняется именно shutdown immediate, а это значит, что в выполнении shutdown abort нет никакой необходимости.
Вот и не надо из этого исходить :) Исходить надо из того, что база нормально отрабатывает передаваемые ей команды. А сервис для RDBMS - неродное и чуждое. По умолчанию передается то, что прописано в реестре, а в реестре, да, прописано immediate. Прошу еще раз вчитаться в то, что я писал выше. Внимательно. Особенно про пункт, касающийся влияния Windows на работу сервисов (WaitToKillServiceTimeout и прочая гадость, например, или работа машин в домене). Настаиваю, что пользоваться сервисом в Windows следует только в случаях, когда надо остановить БД вмертвую и чтобы никто не дергался запускать базу, когда она должна лежать.
Что касается журнала, то мне очень нравится термин ССЗБ, раскрывающий суть ваших действий. Прошу без обид, рекомендую ознакомиться с багом 8991997, поправленным в 11.2.0.2. Это еще безобидный баг, по сравнению с теми, которые вы можете огрести, непонятно зачем устанавливая 11.2.0.1. Неоднократно уже писалось, 11g ставить можно в лучшем случае с 11.2.0.3. Но зачем-то народ усиленно раскладывает грабли для последующего бега по ним.
 
28.02.2013 16:31  
orekhov
Базы создавались давно, "во времена 11.2.0.1". Повторюсь - более полугода всё работало как часы.
Попробуем проапгрейдить до 11.2.0.3 в надежде, что проблема исчезнет. О результатах отпишусь.
Если у кого-то есть другие идеи или предложения - выслушаю с благодарностью.
 
28.02.2013 16:36  
Mtirt
Предложение делать бэкап RMAN чем не понравилось?
 
28.02.2013 16:45  
Troll
Цитата:
Сообщение от orekhov
Базы создавались давно, "во времена 11.2.0.1".
11.2.0.1 - это 2009 год. Не знаю, кто вас заставил ставить неработоспособную версию. Это времена 10.2.0.5, нормально работающей до сих пор. А 11.2.0.1 никто не ставил, только поиграть...
 
28.02.2013 17:18  
orekhov
Не будем вдаваться в исторические подробности. Цитируя классику, сейчас вопрос в том, "что делать", а не "кто виноват".
RMAN - прекрасный инструмент, только вот о его существовании знают немногие клиенты. Я даже не говорю об умении этим инструментом пользоваться. При отсутствии средств удалённого доступа зачастую проще по телефону объяснить, как "подсунуть" файлы из холодного бэкапа, нежели сеять разумное и вечное, рассказывая, что такое командная строка и на какой кнопке какая латинская буква нарисована.
 
05.04.2013 12:23  
orekhov
Подведу итог. Проблема исчезла после замены версии Оракла с 11.2.0.1 на 11.2.0.3. Что собственно помогло - новая версия или процедура экспорта-импорта базы данных - неизвестно. Но факт остаётся фактом, "проблемные" базы снова стартуют нормально.
 
 


Опции темы



Часовой пояс GMT +3, время: 19:06.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.