Не стартует Oracle

Тема в разделе "Базы данных", создана пользователем Ernest, 19 янв 2018.

Модераторы: latteo
  1. Ernest

    Ernest

    Регистр.:
    26 сен 2006
    Сообщения:
    262
    Симпатии:
    60
    Ситуация следующая, некоторое время назад поменяли пароль у пользователя под которым делал бекапы 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> и все, возможно просто дело в моих кривых руках.

    Моих знаний для решения вопроса не хватает.
     
    Последнее редактирование: 19 янв 2018
  2. metsys

    metsys

    Регистр.:
    27 апр 2014
    Сообщения:
    515
    Симпатии:
    507
    Место есть свободное для тех операций?
     
  3. Ernest

    Ernest

    Регистр.:
    26 сен 2006
    Сообщения:
    262
    Симпатии:
    60
    места на диске полно, а вот в db_recovery_file_dest_size его нет, там задан размер
    db_recovery_file_dest_size= 200G, вот сейчас я и хочу выяснить как его там увеличить или почистить архивлоги. Способами которые я нашел не получается.

    крутится на винде 2012
     
  4. metsys

    metsys

    Регистр.:
    27 апр 2014
    Сообщения:
    515
    Симпатии:
    507
    чёт я сомневаюсь в вашем утверждении, либо вы чужой лог показали, т.к. вы говорите:
    а в логе
     
  5. Ernest

    Ernest

    Регистр.:
    26 сен 2006
    Сообщения:
    262
    Симпатии:
    60
    17.01 - это дата, то бишь среда


    Если изменить в SPFILE значение db_recovery_file_dest_size с 200G на 300G то есть вероятность что oracle стартанет?
    Но встает вопрос как это сделать, если sqlplus не дает войти.
     
    Последнее редактирование: 19 янв 2018
  6. Ernest

    Ernest

    Регистр.:
    26 сен 2006
    Сообщения:
    262
    Симпатии:
    60
    Вообщем базу удалось запустить с помощью временного pfile с увеличенным db_recovery_file_dest_size, но логи через rman не удаляются, он просит сначала отключить архивирование. Может я не правильно делаю?

    upd Решено
     
    Последнее редактирование: 23 янв 2018