1 2 3
█ 15.10.2020 21:54
UPS два стоит и оба как на зло не выдержали. Остановка в 5-55 в логе никак не отображена, бэкапер отработал в 3-23 дальше перезагрузка, ну и работали до 11-50 примерно:
SQL код:
Thu Oct 15 03:23:22 2020
alter database mount exclusive
PMON started with pid=2, OS id=4980
Thu Oct 15 03:23:26 2020
Setting recovery target incarnation to 2
Thu Oct 15 03:23:26 2020
Successful mount of redo thread 1, with mount id 442541418
Thu Oct 15 03:23:26 2020
Database mounted in Exclusive Mode
Completed: alter database mount exclusive
Thu Oct 15 03:23:26 2020
alter database open
Thu Oct 15 03:23:26 2020
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=34, OS id=4120
Thu Oct 15 03:23:26 2020
ARC0: Archival started
ARC1 started with pid=36, OS id=4252
Thu Oct 15 03:23:26 2020
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
Thread 1 opened at log sequence 213702
  Current log# 4 seq# 213702 mem# 0: D:\ORACLE\ORADATA\KAMAVTO\REDO01.LOG4+.DBF
Successful open of redo thread 1
Thu Oct 15 03:23:26 2020
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
Thu Oct 15 03:23:26 2020
ARC1: Becoming the heartbeat ARCH
Thu Oct 15 03:23:26 2020
SMON: enabling cache recovery
Thu Oct 15 03:23:27 2020
Successfully onlined Undo Tablespace 1.
Thu Oct 15 03:23:27 2020
SMON: enabling tx recovery
Thu Oct 15 03:23:27 2020
Database Characterset is CL8MSWIN1251
Opening with internal Resource Manager plan
where NUMA PG = 2, CPUs = 8
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=38, OS id=9736
Thu Oct 15 03:23:29 2020
Errors in file d:\oracle\admin\kamavto\bdump\kamavto_mmon_8724.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 620688670720 bytes is 96.85% used, and has 19578023936 remaining bytes available.

Thu Oct 15 03:23:29 2020
************************************************************************
You have following choices to free up space from flash 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.
************************************************************************
Thu Oct 15 03:23:29 2020
Completed: alter database open
Dump file d:\oracle\admin\kamavto\bdump\alert_kamavto.log
Thu Oct 15 05:58:25 2020
ORACLE V10.2.0.4.0 - 64bit Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows NT Version V5.2 Service Pack 2
CPU                 : 16 - type 8664, 8 Physical Cores
Process Affinity    : 0x0000000000000000
Memory (Avail/Total): Ph:22998M/24514M, Ph+PgF:23754M/24754M
Thu Oct 15 05:58:25 2020
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =48
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.4.0.
System parameters with non-default values:
  processes                = 400
  sessions                 = 445
  timed_statistics         = TRUE
  sga_max_size             = 12834570240
  __shared_pool_size       = 2147483648
  shared_pool_size         = 2147483648
  __large_pool_size        = 2147483648
  large_pool_size          = 2147483648
  __java_pool_size         = 2147483648
  java_pool_size           = 2147483648
  __streams_pool_size      = 0
  shared_pool_reserved_size= 16777216
  trace_enabled            = FALSE
  resource_manager_plan    = 
  control_files            = D:\ORACLE\ORADATA\KAMAVTO\CONTROL01.CTL, D:\ORACLE\ORADATA\KAMAVTO\CONTROL02.CTL, D:\ORACLE\ORADATA\KAMAVTO\CONTROL03.CTL
  db_block_size            = 8192
  __db_cache_size          = 2147483648
  db_cache_size            = 2147483648
  db_cache_advice          = OFF
  compatible               = 10.2.0.4.0
  log_archive_start        = TRUE
  db_recovery_file_dest    = E:\backup_log
  db_recovery_file_dest_size= 620688670720
  fast_start_mttr_target   = 600
  transactions_per_rollback_segment= 1
  undo_management          = AUTO
  undo_tablespace          = UNDOTBS1
  undo_retention           = 10800
  recyclebin               = off
  O7_DICTIONARY_ACCESSIBILITY= TRUE
  remote_login_passwordfile= EXCLUSIVE
  audit_sys_operations     = FALSE
  db_domain                = 
  instance_name            = KAMAVTO
  session_cached_cursors   = 500
  job_queue_processes      = 10
  background_dump_dest     = D:\ORACLE\ADMIN\KAMAVTO\BDUMP
  user_dump_dest           = D:\ORACLE\ADMIN\KAMAVTO\UDUMP
  max_dump_file_size       = 5000000
  core_dump_dest           = D:\ORACLE\ADMIN\KAMAVTO\CDUMP
  commit_write             = batch,nowait
  optimizer_features_enable= 10.2.0.4
  audit_trail              = DB
  sort_area_size           = 4194304
  db_name                  = KAMAVTO
  open_cursors             = 300
  star_transformation_enabled= FALSE
  query_rewrite_enabled    = FALSE
  query_rewrite_integrity  = stale_tolerated
  pga_aggregate_target     = 34217728
  optimizer_dynamic_sampling= 2
Deprecated system parameters with specified values:
  log_archive_start        
End of deprecated system parameter listing
MMAN started with pid=6, OS id=3320
DBW0 started with pid=8, OS id=3324
DBW1 started with pid=10, OS id=3328
LGWR started with pid=12, OS id=3332
CKPT started with pid=14, OS id=3336
SMON started with pid=16, OS id=3340
RECO started with pid=18, OS id=3344
CJQ0 started with pid=20, OS id=3348
MMON started with pid=22, OS id=3352
MMNL started with pid=24, OS id=3356
Thu Oct 15 05:58:28 2020
alter database mount exclusive
PMON started with pid=2, OS id=3312
PSP0 started with pid=4, OS id=3316
Thu Oct 15 05:58:32 2020
Setting recovery target incarnation to 2
Thu Oct 15 05:58:32 2020
Successful mount of redo thread 1, with mount id 442543044
Thu Oct 15 05:58:32 2020
Database mounted in Exclusive Mode
Completed: alter database mount exclusive
Thu Oct 15 05:58:32 2020
alter database open
Thu Oct 15 05:58:32 2020
Beginning crash recovery of 1 threads
 parallel recovery started with 15 processes
Thu Oct 15 05:58:32 2020
Started redo scan
Thu Oct 15 05:58:33 2020
Completed redo scan
 10052 redo blocks read, 580 data blocks need recovery
Thu Oct 15 05:58:33 2020
Started redo application at
 Thread 1: logseq 213702, block 2042789
Thu Oct 15 05:58:33 2020
Recovery of Online Redo Log: Thread 1 Group 4 Seq 213702 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\KAMAVTO\REDO01.LOG4+.DBF
Thu Oct 15 05:58:34 2020
Completed redo application
Thu Oct 15 05:58:34 2020
Completed crash recovery at
 Thread 1: logseq 213702, block 2052841, scn 7028057328
 580 data blocks read, 580 data blocks written, 10052 redo blocks read
Thu Oct 15 05:58:34 2020
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=72, OS id=3680
ARC1 started with pid=74, OS id=3684
Thu Oct 15 05:58:34 2020
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
Thu Oct 15 05:58:34 2020
Thread 1 advanced to log sequence 213703 (thread open)
Thread 1 opened at log sequence 213703
  Current log# 5 seq# 213703 mem# 0: D:\ORACLE\ORADATA\KAMAVTO\REDO02.LOG5+.DBF
Successful open of redo thread 1
Thu Oct 15 05:58:34 2020
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
Thu Oct 15 05:58:34 2020
ARC0: Becoming the heartbeat ARCH
Thu Oct 15 05:58:34 2020
SMON: enabling cache recovery
Thu Oct 15 05:58:34 2020
Errors in file d:\oracle\admin\kamavto\bdump\kamavto_arc1_3684.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 620688670720 bytes is 97.02% used, and has 18526969856 remaining bytes available.

Thu Oct 15 05:58:34 2020
************************************************************************
You have following choices to free up space from flash 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.
************************************************************************
Thu Oct 15 05:58:36 2020
Successfully onlined Undo Tablespace 1.
Thu Oct 15 05:58:36 2020
SMON: enabling tx recovery
Thu Oct 15 05:58:36 2020
Database Characterset is CL8MSWIN1251
Opening with internal Resource Manager plan
where NUMA PG = 2, CPUs = 8
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=76, OS id=3704
Thu Oct 15 05:58:41 2020
Completed: alter database open
Thu Oct 15 05:59:29 2020
WARNING: inbound connection timed out (ORA-3136)
Thu Oct 15 07:19:19 2020
Thread 1 advanced to log sequence 213704 (LGWR switch)
  Current log# 6 seq# 213704 mem# 0: D:\ORACLE\ORADATA\KAMAVTO\REDO03.LOG6+.DBF
Thu Oct 15 09:00:17 2020
Thread 1 advanced to log sequence 213705 (LGWR switch)
  Current log# 3 seq# 213705 mem# 0: D:\ORACLE\ORADATA\KAMAVTO\REDO03.LOG
Thu Oct 15 10:30:22 2020
Thread 1 advanced to log sequence 213706 (LGWR switch)
  Current log# 1 seq# 213706 mem# 0: D:\ORACLE\ORADATA\KAMAVTO\REDO01.LOG
Thu Oct 15 11:17:36 2020
Thread 1 advanced to log sequence 213707 (LGWR switch)
  Current log# 2 seq# 213707 mem# 0: D:\ORACLE\ORADATA\KAMAVTO\REDO02.LOG
Dump file d:\oracle\admin\kamavto\bdump\alert_kamavto.log
Thu Oct 15 11:55:05 2020
ORACLE V10.2.0.4.0 - 64bit Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows NT Version V5.2 Service Pack 2
CPU                 : 16 - type 8664, 8 Physical Cores
Process Affinity    : 0x0000000000000000
Memory (Avail/Total): Ph:22693M/24514M, Ph+PgF:23761M/24754M
Thu Oct 15 11:55:05 2020
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =48
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.4.0.
System parameters with non-default values:
  processes                = 400
  sessions                 = 445
  timed_statistics         = TRUE
  sga_max_size             = 12834570240
  __shared_pool_size       = 2147483648
  shared_pool_size         = 2147483648
  __large_pool_size        = 2147483648
  large_pool_size          = 2147483648
  __java_pool_size         = 2147483648
  java_pool_size           = 2147483648
  __streams_pool_size      = 0
  shared_pool_reserved_size= 16777216
  trace_enabled            = FALSE
  resource_manager_plan    = 
  control_files            = D:\ORACLE\ORADATA\KAMAVTO\CONTROL01.CTL, D:\ORACLE\ORADATA\KAMAVTO\CONTROL02.CTL, D:\ORACLE\ORADATA\KAMAVTO\CONTROL03.CTL
  db_block_size            = 8192
  __db_cache_size          = 2147483648
  db_cache_size            = 2147483648
  db_cache_advice          = OFF
  compatible               = 10.2.0.4.0
  log_archive_start        = TRUE
  db_recovery_file_dest    = E:\backup_log
  db_recovery_file_dest_size= 620688670720
  fast_start_mttr_target   = 600
  transactions_per_rollback_segment= 1
  undo_management          = AUTO
  undo_tablespace          = UNDOTBS1
  undo_retention           = 10800
  recyclebin               = off
  O7_DICTIONARY_ACCESSIBILITY= TRUE
  remote_login_passwordfile= EXCLUSIVE
  audit_sys_operations     = FALSE
  db_domain                = 
  instance_name            = KAMAVTO
  session_cached_cursors   = 500
  job_queue_processes      = 10
  background_dump_dest     = D:\ORACLE\ADMIN\KAMAVTO\BDUMP
  user_dump_dest           = D:\ORACLE\ADMIN\KAMAVTO\UDUMP
  max_dump_file_size       = 5000000
  core_dump_dest           = D:\ORACLE\ADMIN\KAMAVTO\CDUMP
  commit_write             = batch,nowait
  optimizer_features_enable= 10.2.0.4
  audit_trail              = DB
  sort_area_size           = 4194304
  db_name                  = KAMAVTO
  open_cursors             = 300
  star_transformation_enabled= FALSE
  query_rewrite_enabled    = FALSE
  query_rewrite_integrity  = stale_tolerated
  pga_aggregate_target     = 34217728
  optimizer_dynamic_sampling= 2
Deprecated system parameters with specified values:
  log_archive_start        
End of deprecated system parameter listing
PMON started with pid=2, OS id=3340
MMAN started with pid=6, OS id=3348
DBW0 started with pid=10, OS id=3400
DBW1 started with pid=12, OS id=3404
LGWR started with pid=16, OS id=3408
CKPT started with pid=18, OS id=3412
SMON started with pid=20, OS id=3416
RECO started with pid=22, OS id=3420
CJQ0 started with pid=24, OS id=3424
MMON started with pid=26, OS id=3428
MMNL started with pid=28, OS id=3432
Thu Oct 15 11:55:10 2020
alter database mount exclusive
PSP0 started with pid=4, OS id=3344
Informational message:
Control file 1 has seq# 8710623, lowest 8710622 file 0 
Setting recovery target incarnation to 2
Thu Oct 15 11:55:14 2020
Successful mount of redo thread 1, with mount id 442509406
Thu Oct 15 11:55:14 2020
Database mounted in Exclusive Mode
Completed: alter database mount exclusive
Thu Oct 15 11:55:14 2020
alter database open
Thu Oct 15 11:55:14 2020
Beginning crash recovery of 1 threads
 parallel recovery started with 15 processes
Thu Oct 15 11:55:14 2020
Started redo scan
Thu Oct 15 11:55:14 2020
Completed redo scan
 13947 redo blocks read, 1335 data blocks need recovery
Thu Oct 15 11:55:16 2020
Started redo application at
 Thread 1: logseq 213707, block 118867
Thu Oct 15 11:55:16 2020
Recovery of Online Redo Log: Thread 1 Group 2 Seq 213707 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\KAMAVTO\REDO02.LOG
Thu Oct 15 11:55:17 2020
Completed redo application
Thu Oct 15 11:55:18 2020
Completed crash recovery at
 Thread 1: logseq 213707, block 132814, scn 7028867801
 1335 data blocks read, 1334 data blocks written, 13947 redo blocks read
Thu Oct 15 11:55:18 2020
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=74, OS id=3700
ARC1 started with pid=76, OS id=3704
Thu Oct 15 11:55:18 2020
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
Thu Oct 15 11:55:19 2020
Thread 1 advanced to log sequence 213708 (thread open)
Thread 1 opened at log sequence 213708
  Current log# 4 seq# 213708 mem# 0: D:\ORACLE\ORADATA\KAMAVTO\REDO01.LOG4+.DBF
Successful open of redo thread 1
Thu Oct 15 11:55:19 2020
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
Thu Oct 15 11:55:19 2020
ARC0: Becoming the heartbeat ARCH
Thu Oct 15 11:55:19 2020
SMON: enabling cache recovery
Thu Oct 15 11:55:19 2020
Errors in file d:\oracle\admin\kamavto\bdump\kamavto_arc0_3700.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 620688670720 bytes is 97.71% used, and has 14185178624 remaining bytes available.

Thu Oct 15 11:55:19 2020
************************************************************************
You have following choices to free up space from flash 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.
************************************************************************
Thu Oct 15 11:55:20 2020
Successfully onlined Undo Tablespace 1.
Thu Oct 15 11:55:20 2020
SMON: enabling tx recovery
Thu Oct 15 11:55:20 2020
Database Characterset is CL8MSWIN1251
Opening with internal Resource Manager plan
where NUMA PG = 2, CPUs = 8
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=80, OS id=3724
Thu Oct 15 11:55:26 2020
Completed: alter database open
Thu Oct 15 11:55:49 2020
Errors in file d:\oracle\admin\kamavto\bdump\kamavto_smon_3416.trc:
ORA-00600: internal error code, arguments: [4194], [65], [28], [], [], [], [], []

Thu Oct 15 11:55:59 2020
Errors in file d:\oracle\admin\kamavto\bdump\kamavto_j000_3936.trc:
ORA-00600: internal error code, arguments: [4193], [54658], [54691], [], [], [], [], []
█ 15.10.2020 21:55
Цитата:
OlegON ➤ А сейчас восстанавливай до битого журнала.
Пробую восстановить пол дня работы, если база монтируется можно пробовать экспорт сделать?
█ 15.10.2020 21:59
Цитата:
OlegON ➤ Поставь оптимизатор, рекомендую же.
Стоит, только запускаю днем, ночью не хватает времени, работают до допоздна, а утром хотят и товародвижение посчитанное и бэкап и в шесть утра начать работать опять.
ClientNum : 339
█ 15.10.2020 22:04
Цитата:
kamres ➤ Пробую восстановить пол дня работы, если база монтируется можно пробовать экспорт сделать?
погоди, открывается? посмотри статейку про битые редо и анду в ручном режиме запусти, я писал здесь где-то.
оптимизатор может работать при круглосуточной работе пользователей, для его бекапа останавливать базу не надо.
█ 16.10.2020 01:20
Помогло пересоздание undo. Все остальное целое.

SQL код:
SQL> select * from v$database_block_corruption;
no rows selected
█ 16.10.2020 08:39
Цитата:
kamres ➤ v$database_block_corruption
а ты базу-то проверял, чтобы там что-то появилось?
и, еще раз, не пользуйся бекапером... пользуйся бекапом опта, он базу проверяет... не останавливай базу...
█ 16.10.2020 09:12
Запускал оптимайзер, потом это: https://olegon.ru/showpost.php?p=44729&postcount=4
скрытое

Понял что сначала нужно:
SQL код:
RMAN> VALIDATE DATABASE;
но получаю ответ:
SQL код:
RMAN> VALIDATE DATABASE;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "database": expecting one of: "backupset"
RMAN-01007: at line 1 column 10 file: standard input

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found ";": expecting one of: "allocate, alter, backup,
RMAN-01007: at line 1 column 18 file: standard input
Сейчас при переносе для товародвижения останавливается на этом:
SQL код:
Fri Oct 16 09:06:04 2020
Errors in file d:\oracle\admin\kamavto\bdump\kamavto_j001_9188.trc:
ORA-00600: код внутр. ошибки, аргументы: [kdsgrp1], [], [], [], [], [], [], []

Fri Oct 16 09:06:25 2020
Errors in file d:\oracle\admin\kamavto\bdump\kamavto_j001_9188.trc:
ORA-00600: код внутр. ошибки, аргументы: [kdsgrp1], [], [], [], [], [], [], []
ORA-06512: на  "SUPERMAG.SCHEDULE", line 292
ORA-06512: на  line 1
█ 16.10.2020 09:23
Для начала перед ремонтом ребутни недоос. Я после того, как целый вечер сношался с базой только из-за глюка винды, теперь взял за правило, любая оценка базы только после свежего ребута винды (линукс это не требует).
Потом, если повторяется, посмотри в trc, на каком именно запросе падает. Возможно, что повезло, и побился только индекс. Всем перечисленным в запросе таблицам сделай validate structure cascade и найдешь, какая битая.
Оптимизатор надо запускать не просто так, а дать ему сбекапить базу и RMAN-опции должны быть включены, в т.ч. RMANVerify.
█ 16.10.2020 10:12
RMAN-опции установлены такие :
RMANDefDev=1
RMANDelArch=0
RMANDelArchO=0
RMANDelArchX=0
RMANDelBefore=0
RMANForceAfter=2
RMANMaxPiece=5
RMANValidate=1

Target=F:\backup_RMAN

Бэкап при таких опциях должен сделаться?
█ 16.10.2020 10:13
Цитата:
OlegON ➤ Для начала перед ремонтом ребутни недоос. Я после того, как целый вечер сношался с базой только из-за глюка винды, теперь взял за правило, любая оценка базы только после свежего ребута винды (линукс это не требует).
Не перезагружал.
Перезагрузил Windows, в алерте хотя базу вчера стопил ничего такого не было:
Код:
Fri Oct 16 09:51:09 2020
alter database mount exclusive
PSP0 started with pid=4, OS id=3340
PMON started with pid=2, OS id=3336
Fri Oct 16 09:51:13 2020
Setting recovery target incarnation to 3
Fri Oct 16 09:51:13 2020
Successful mount of redo thread 1, with mount id 442620109
Fri Oct 16 09:51:13 2020
Database mounted in Exclusive Mode
Completed: alter database mount exclusive
Fri Oct 16 09:51:13 2020
alter database open
Fri Oct 16 09:51:13 2020
Beginning crash recovery of 1 threads
 parallel recovery started with 15 processes
Fri Oct 16 09:51:13 2020
Started redo scan
Fri Oct 16 09:51:13 2020
Completed redo scan
 13271 redo blocks read, 894 data blocks need recovery
Fri Oct 16 09:51:14 2020
Started redo application at
 Thread 1: logseq 16, block 904652
Fri Oct 16 09:51:14 2020
Recovery of Online Redo Log: Thread 1 Group 4 Seq 16 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\KAMAVTO\REDO01.LOG4+.DBF
Fri Oct 16 09:51:15 2020
Completed redo application
Fri Oct 16 09:51:16 2020
Completed crash recovery at
 Thread 1: logseq 16, block 917923, scn 7030682745
894 data blocks read, 894 data blocks written, 13271 redo blocks read
Fri Oct 16 09:51:16 2020
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=72, OS id=3708
ARC1 started with pid=74, OS id=3712
Fri Oct 16 09:51:16 2020
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
Fri Oct 16 09:51:16 2020
Thread 1 advanced to log sequence 17 (thread open)
Thread 1 opened at log sequence 17
  Current log# 5 seq# 17 mem# 0: D:\ORACLE\ORADATA\KAMAVTO\REDO02.LOG5+.DBF
Successful open of redo thread 1
Fri Oct 16 09:51:16 2020
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
Fri Oct 16 09:51:16 2020
ARC0: Becoming the heartbeat ARCH
Fri Oct 16 09:51:16 2020
SMON: enabling cache recovery
Fri Oct 16 09:51:16 2020
db_recovery_file_dest_size of 2048000 MB is 5.21% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Fri Oct 16 09:51:18 2020
Successfully onlined Undo Tablespace 10.
Fri Oct 16 09:51:18 2020
SMON: enabling tx recovery
Fri Oct 16 09:51:18 2020
Database Characterset is CL8MSWIN1251
Opening with internal Resource Manager plan
where NUMA PG = 2, CPUs = 8
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=78, OS id=3752
Fri Oct 16 09:51:22 2020
Completed: alter database open
Часовой пояс GMT +3, время: 02:41.

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