Не стартует Oracle

Ernest

Ernest

Гуру форума
Регистрация
25 Сен 2006
Сообщения
270
Реакции
71
Ситуация следующая, некоторое время назад поменяли пароль у пользователя под которым делал бекапы Oracle и он их естественно делать перестал, поэтому откатится можно только на базу недельной давности что очень не устраивает.
17.01, в среду, Oracle не стартанул, в алерте ругается на db_recovery_file_dest_size насколько я понял

Код: 
Instance terminated by USER, pid = 2256
Thu Jan 18 15:57:26 2018
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Initial number of CPU is 24
Number of processor cores in the system is 12
Number of processor sockets in the system is 2
Picked latch-free SCN scheme 3
Thu Jan 18 15:57:37 2018
Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =60
LICENSE_MAX_USERS = 0
SYS auditing is disabled
NUMA system with 2 nodes detected
Starting up:
Oracle Database 11g Release 11.2.0.4.0 - 64bit Production.
Windows NT Version V6.2
CPU                 : 24 - type 8664, 12 Physical Cores
Process Affinity    : 0x0x0000000000000000
Memory (Avail/Total): Ph:34539M/65501M, Ph+PgF:44220M/75229M
Using parameter settings in server-side spfile D:\APP\PRODUCT\11.2.0\DBHOME_1\DATABASE\SPFILEPLAN.ORA
System parameters with non-default values:
  processes                = 350
  sessions                 = 552
  nls_language             = "RUSSIAN"
  nls_territory            = "RUSSIA"
  memory_target            = 48000M
  control_files            = "D:\APP\ORADATA\PLAN\CONTROL01.CTL"
  control_files            = "D:\APP\FAST_RECOVERY_AREA\PLAN\CONTROL02.CTL"
  db_block_size            = 8192
  compatible               = "11.2.0.4.0"
  db_recovery_file_dest    = "D:\app\fast_recovery_area"
  db_recovery_file_dest_size= 200G
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=PLANXDB)"
  audit_file_dest          = "D:\APP\ADMIN\PLAN\ADUMP"
  audit_trail              = "DB"
  db_name                  = "PLAN"
  open_cursors             = 300
  diagnostic_dest          = "D:\APP"
Thu Jan 18 15:57:37 2018
PMON started with pid=2, OS id=4304
Thu Jan 18 15:57:37 2018
PSP0 started with pid=3, OS id=1616
Thu Jan 18 15:57:38 2018
VKTM started with pid=4, OS id=4508 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Thu Jan 18 15:57:38 2018
GEN0 started with pid=5, OS id=2492
Thu Jan 18 15:57:38 2018
DIAG started with pid=6, OS id=1564
Thu Jan 18 15:57:38 2018
DBRM started with pid=7, OS id=1588
Thu Jan 18 15:57:38 2018
DIA0 started with pid=8, OS id=4244
Thu Jan 18 15:57:38 2018
MMAN started with pid=9, OS id=5084
Thu Jan 18 15:57:38 2018
DBW0 started with pid=10, OS id=4232
Thu Jan 18 15:57:38 2018
DBW1 started with pid=11, OS id=2456
Thu Jan 18 15:57:38 2018
DBW2 started with pid=12, OS id=2388
Thu Jan 18 15:57:39 2018
LGWR started with pid=13, OS id=4084
Thu Jan 18 15:57:39 2018
CKPT started with pid=14, OS id=2000
Thu Jan 18 15:57:39 2018
SMON started with pid=15, OS id=4000
Thu Jan 18 15:57:39 2018
RECO started with pid=16, OS id=3996
Thu Jan 18 15:57:39 2018
MMON started with pid=17, OS id=3368
Thu Jan 18 15:57:39 2018
MMNL started with pid=18, OS id=4416
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = D:\app
Thu Jan 18 15:57:39 2018
ALTER DATABASE   MOUNT
Successful mount of redo thread 1, with mount id 3560201203
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Thu Jan 18 15:57:43 2018
ALTER DATABASE OPEN
LGWR: STARTING ARCH PROCESSES
Thu Jan 18 15:57:44 2018
ARC0 started with pid=22, OS id=4988
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thu Jan 18 15:57:45 2018
ARC1 started with pid=23, OS id=4380
Thu Jan 18 15:57:45 2018
ARC2 started with pid=24, OS id=2448
Thu Jan 18 15:57:45 2018
ARC3 started with pid=25, OS id=3732
Errors in file D:\APP\diag\rdbms\plan\plan\trace\plan_ora_4772.trc:
ORA-19815: ПРЕДУПРЕЖДЕНИЕ. db_recovery_file_dest_size из 214748364800 байт 100.00% используется, и 0 байт остаются доступными.
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
ARCH: Error 19809 Creating archive log file to 'D:\APP\FAST_RECOVERY_AREA\PLAN\ARCHIVELOG\2018_01_18\O1_MF_1_13364_%U_.ARC'
Errors in file D:\APP\diag\rdbms\plan\plan\trace\plan_ora_4772.trc:
ORA-16038: журнал 2 с номером последовательности 13364 не может быть архивирован
ORA-19809: достигнут предел для файлов восстановления
ORA-00312: оперативный протокол 2 процесса 1: 'D:\APP\ORADATA\PLAN\REDO02.LOG'
USER (ospid: 4772): terminating the instance due to error 16038
System state dump requested by (instance=1, osid=4772), summary=[abnormal instance termination].
System State dumped to trace file D:\APP\diag\rdbms\plan\plan\trace\plan_diag_1564_20180118155745.trc
Dumping diagnostic data in directory=[cdmp_20180118155745], requested by (instance=1, osid=4772), summary=[abnormal instance termination].
ARC1: Archival started
ARC2: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
ARC0: Archival disabled due to shutdown: 1092
Shutting down archive processes
Archiving is disabled
Instance terminated by USER, pid = 4772

При попытке зайти в sqlplus он перестает отвечать на моменте ввода пароля. Пробовал почистить ARCHIVELOG через rman, но он у меня выводит сообщение 2> и все, возможно просто дело в моих кривых руках.

Моих знаний для решения вопроса не хватает.
Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.
 
Последнее редактирование:
Место есть свободное для тех операций?
 
metsys написал(а):
Место есть свободное для тех операций?
Нажмите для раскрытия...
места на диске полно, а вот в db_recovery_file_dest_size его нет, там задан размер
db_recovery_file_dest_size= 200G, вот сейчас я и хочу выяснить как его там увеличить или почистить архивлоги. Способами которые я нашел не получается.

крутится на винде 2012
 
metsys написал(а):
чёт я сомневаюсь в вашем утверждении, либо вы чужой лог показали, т.к. вы говорите:
а в логе
Нажмите для раскрытия...
17.01 - это дата, то бишь среда


Если изменить в SPFILE значение db_recovery_file_dest_size с 200G на 300G то есть вероятность что oracle стартанет?
Но встает вопрос как это сделать, если sqlplus не дает войти.
 
Последнее редактирование:
Вообщем базу удалось запустить с помощью временного pfile с увеличенным db_recovery_file_dest_size, но логи через rman не удаляются, он просит сначала отключить архивирование. Может я не правильно делаю?

upd Решено
 
Последнее редактирование:
Войдите или зарегистрируйтесь для ответа.
Назад
Сверху