ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / ORA-10458: standby database requires recovery
32 сообщений из 32, показаны все 2 страниц
  все  
ORA-10458: standby database requires recovery
    #40091595
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01157: cannot identify/lock data file 44 - see DBWR trace file
ORA-01111: name for data file 44 is unknown - rename to correct file
ORA-01110: data file 44: '/oracle/dbbase/UNNAMED00044'


Пишет ошибку , поможет кто ? Спс
...
Рейтинг: 0 / 0
18.08.2021, 19:57
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091596
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Он же битами пор байтам пишет - протоптали 44-й датафайл
...
Рейтинг: 0 / 0
18.08.2021, 20:02
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091598
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
andrey_anonymous
Он же битами пор байтам пишет - протоптали 44-й датафайл


Все нужно восстанавлить standby через бэкап ?
...
Рейтинг: 0 / 0
18.08.2021, 20:04
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091599
flexgen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
flexgen
Участник
AleksRous
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01157: cannot identify/lock data file 44 - see DBWR trace file
ORA-01111: name for data file 44 is unknown - rename to correct file
ORA-01110: data file 44: '/oracle/dbbase/UNNAMED00044'


Пишет ошибку , поможет кто ? Спс


Есть такой документ -

How to resolve ORA-01111 ORA-01110 ORA-01157 in a physical standby database (Doc ID 1416554.1)

Доступ к MOS есть?
...
Рейтинг: 0 / 0
18.08.2021, 20:09
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091600
flexgen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
flexgen
Участник
Что вернет

Код: plsql
1.
show parameter standby_file_management
...
Рейтинг: 0 / 0
18.08.2021, 20:13
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091601
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
flexgen
Что вернет

Код: plsql
1.
show parameter standby_file_management




SQL> show parameter standby_file_management

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string MANUAL
...
Рейтинг: 0 / 0
18.08.2021, 20:14
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091602
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
flexgen
AleksRous
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01157: cannot identify/lock data file 44 - see DBWR trace file
ORA-01111: name for data file 44 is unknown - rename to correct file
ORA-01110: data file 44: '/oracle/dbbase/UNNAMED00044'


Пишет ошибку , поможет кто ? Спс


Есть такой документ -

How to resolve ORA-01111 ORA-01110 ORA-01157 in a physical standby database (Doc ID 1416554.1)

Доступ к MOS есть?



нет нету доступа
...
Рейтинг: 0 / 0
18.08.2021, 20:15
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091607
flexgen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
flexgen
Участник
AleksRous

SQL> show parameter standby_file_management

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string MANUAL


На будущее - когда строишь dataguard process этот параметр должен быть выставлен в AUTO.
Иначе после каждого добавления файла данных в существующий tablespace в базе PRIMARY будут вот такие проблемы. У тебя же dataguard встал и не накатывает archived log files, так? И ты попытался открыть базу, да?

Теперь будем пробовать починить твою базу.

Останавливаем DR process
Код: plsql
1.
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;


Переименовываем твой неизвестный файл 44, ты должен посмотреть как называется этот файл в базе PRIMARY
Код: plsql
1.
SQL> select * from dba_data_files where file_id = 44;



В базе STANDBY выполняешь

Код: plsql
1.
SQL> ALTER DATABASE RENAME FILE '/oracle/dbbase/UNNAMED00044' to '/oracle/dbbase/<real datafile name>';



Выставляем standby_file_management = auto
Код: plsql
1.
SQL>ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;


Запускаем managed recovery process
Код: plsql
1.
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
...
Рейтинг: 0 / 0
18.08.2021, 20:32
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091628
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
flexgen
AleksRous

SQL> show parameter standby_file_management

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string MANUAL


На будущее - когда строишь dataguard process этот параметр должен быть выставлен в AUTO.
Иначе после каждого добавления файла данных в существующий tablespace в базе PRIMARY будут вот такие проблемы. У тебя же dataguard встал и не накатывает archived log files, так? И ты попытался открыть базу, да?

Теперь будем пробовать починить твою базу.

Останавливаем DR process
Код: plsql
1.
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;


Переименовываем твой неизвестный файл 44, ты должен посмотреть как называется этот файл в базе PRIMARY
Код: plsql
1.
SQL> select * from dba_data_files where file_id = 44;



В базе STANDBY выполняешь

Код: plsql
1.
SQL> ALTER DATABASE RENAME FILE '/oracle/dbbase/UNNAMED00044' to '/oracle/dbbase/<real datafile name>';



Выставляем standby_file_management = auto
Код: plsql
1.
SQL>ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;


Запускаем managed recovery process
Код: plsql
1.
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;





Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
ALTER DATABASE RENAME FILE '/oracle/dbbase/dbhome/dbs/UNNAMED00044' to '+ORADATA/dbstand/data21.dbf'
*
ERROR at line 1:
ORA-01511: error in renaming log/data files
ORA-01141: error renaming data file 44 - new file
'+ORADATA/dbstand/data21.dbf' not found
ORA-01111: name for data file 44 is unknown - rename to correct file
ORA-01110: data file 44: '/oracle/dbbase/dbhome/dbs/UNNAMED00044'
ORA-17503: ksfdopn:2 Failed to open file +ORADATA/dbstand/data21.dbf
ORA-15173: entry 'data21.dbf' does not exist in directory 'datadbsb'





Вся проблема в том, в primary select * from dba_data_files where file_id = 44; показывает на data21.dbf , но standby нет такого файла
...
Рейтинг: 0 / 0
18.08.2021, 22:53
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091632
flexgen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
flexgen
Участник
Чего-то я не понял, сначала ты пишешь:
ORA-01110: data file 44: '/oracle/dbbase/UNNAMED00044'
Но при переименовании путь к файлу ты указываешь уже другой:
Код: plsql
1.
ALTER DATABASE RENAME FILE '/oracle/dbbase/dbhome/dbs/UNNAMED00044' to '+ORADATA/dbstand/data21.dbf'


И почему-то пытаешься переименовать в файл который должен быть на ASM.
Где у тебя файлы данных в базе STANDBY находятся, на диске ОС или на ASM? А на PRIMARY?
Вся проблема в том, в primary select * from dba_data_files where file_id = 44; показывает на data21.dbf , но standby нет такого файла
Понятное дело что нету, он создался с именем UNNAMED00044 из-за того что параметр standby_file_management был выставлен как MANUAL.
...
Рейтинг: 0 / 0
19.08.2021, 00:16
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091672
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
flexgen
Чего-то я не понял, сначала ты пишешь:
ORA-01110: data file 44: '/oracle/dbbase/UNNAMED00044'

Но при переименовании путь к файлу ты указываешь уже другой:
Код: plsql
1.
ALTER DATABASE RENAME FILE '/oracle/dbbase/dbhome/dbs/UNNAMED00044' to '+ORADATA/dbstand/data21.dbf'


И почему-то пытаешься переименовать в файл который должен быть на ASM.
Где у тебя файлы данных в базе STANDBY находятся, на диске ОС или на ASM? А на PRIMARY?
Вся проблема в том, в primary select * from dba_data_files where file_id = 44; показывает на data21.dbf , но standby нет такого файла
Понятное дело что нету, он создался с именем UNNAMED00044 из-за того что параметр standby_file_management был выставлен как MANUAL.


Создал датафайл все норм , теперь восстанавливаю

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
2021-08-19T10:15:27.704568+04:00
Media Recovery Start: Managed Standby Recovery (stbdbsb)
 Started logmerger process
2021-08-19T10:15:27.732956+04:00
PR00 (PID:48790): Managed Standby Recovery starting Real Time Apply
2021-08-19T10:15:27.920611+04:00
Parallel Media Recovery started with 4 slaves
2021-08-19T10:15:28.078753+04:00
stopping change tracking
2021-08-19T10:15:28.273878+04:00
Recovery of Online Redo Log: Thread 2 Group 32 Seq 75383 Reading mem 0
  Mem# 0: +ORADATA/stbdbsb/redologs/stbdbpr2_sbylog02a.log
  Mem# 1: /oracle/orafra/stbbsb/redologs/stbbpr2_sbylog02b.log




Но процесс длится долго или так и должно быть. Объясните чайнику пжт.
...
Рейтинг: 0 / 0
19.08.2021, 09:25
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091677
flexgen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
flexgen
Участник
AleksRous


Создал датафайл все норм , теперь восстанавливаю

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
2021-08-19T10:15:27.704568+04:00
Media Recovery Start: Managed Standby Recovery (stbdbsb)
 Started logmerger process
2021-08-19T10:15:27.732956+04:00
PR00 (PID:48790): Managed Standby Recovery starting Real Time Apply
2021-08-19T10:15:27.920611+04:00
Parallel Media Recovery started with 4 slaves
2021-08-19T10:15:28.078753+04:00
stopping change tracking
2021-08-19T10:15:28.273878+04:00
Recovery of Online Redo Log: Thread 2 Group 32 Seq 75383 Reading mem 0
  Mem# 0: +ORADATA/stbdbsb/redologs/stbdbpr2_sbylog02a.log
  Mem# 1: /oracle/orafra/stbbsb/redologs/stbbpr2_sbylog02b.log




Но процесс длится долго или так и должно быть. Объясните чайнику пжт.


Выполни на STANDBY
Код: plsql
1.
2.
SQL> select * from v$managed_standby;
SQL> select * from v$dataguard_stats;
...
Рейтинг: 0 / 0
19.08.2021, 09:35
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091678
Aleks Niches
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aleks Niches
Участник
...
Рейтинг: 0 / 0
19.08.2021, 09:40
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091679
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
...
Рейтинг: 0 / 0
19.08.2021, 09:41
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091681
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
Standby

SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)
--------------
105616

Primary


SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)
--------------
105661

SQL>
...
Рейтинг: 0 / 0
19.08.2021, 09:44
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091684
flexgen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
flexgen
Участник
Aleks Niches,

Если я правильно понимаю то параметр LOG_ARCHIVE_MAX_PROCESSES выставлен равным 4.
Попробуй увеличить до 8 и на Primary и на Standby.

Код: plsql
1.
alter system set LOG_ARCHIVE_MAX_PROCESSES=8;



В принципе, судя по этому не так уж и много файлов осталось накатить:
автор
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Standby 

SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)
--------------
105616

Primary 


SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)
--------------
105661
...
Рейтинг: 0 / 0
19.08.2021, 09:50
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091690
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
flexgen
Aleks Niches,

Если я правильно понимаю то параметр LOG_ARCHIVE_MAX_PROCESSES выставлен равным 4.
Попробуй увеличить до 8 и на Primary и на Standby.

Код: plsql
1.
alter system set LOG_ARCHIVE_MAX_PROCESSES=8;



В принципе, судя по этому не так уж и много файлов осталось накатить:
автор
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Standby 

SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)
--------------
105616

Primary 


SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)
--------------
105661




Поменял LOG_ARCHIVE_MAX_PROCESSES на 8

Запустил recovery

Код: xml
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
2021-08-19T10:58:35.660960+04:00
Media Recovery Start: Managed Standby Recovery (acbdbsb)
 Started logmerger process
2021-08-19T10:58:35.701223+04:00
PR00 (PID:51003): Managed Standby Recovery starting Real Time Apply
2021-08-19T10:58:35.876811+04:00
Parallel Media Recovery started with 4 slaves
2021-08-19T10:58:36.033243+04:00
stopping change tracking
2021-08-19T10:58:36.119445+04:00
Recovery of Online Redo Log: Thread 2 Group 32 Seq 75383 Reading mem 0
  Mem# 0: +ORADATDG/acbdbsb/redologs/stbbpr2_sbylog02a.log
  Mem# 1: /oracle/orafra/acbdbsb/redologs/stbbpr2_sbylog02b.log




Нужно ждать пока процесс закончится ?
...
Рейтинг: 0 / 0
19.08.2021, 10:01
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091697
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
Standby

Код: xml
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
SQL> show parameter log_archive_config;
show parameter log_archive_dest_1;
show parameter log_archive_dest_2;
show parameter log_archive_dest_state_1;
show parameter log_archive_dest_state_2;
show parameter FAL_CLIENT;
show parameter fal_server;
show parameter standby_file_management;
show parameter log_file_name_convert;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_config                   string      dg_config=(datadbpr,datadbsb)
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1                   string      LOCATION=USE_DB_RECOVERY_FILE_
                                                 DEST MANDATORY REOPEN=5
log_archive_dest_10                  string
log_archive_dest_11                  string
log_archive_dest_12                  string
log_archive_dest_13                  string
log_archive_dest_14                  string
log_archive_dest_15                  string
log_archive_dest_16                  string
log_archive_dest_17                  string
log_archive_dest_18                  string

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_19                  string
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2                   string      service=datadbpr1 LGWR ASYNC va
                                                 lid_for=(ONLINE_LOGFILES,PRIMA
                                                 RY_ROLE) db_unique_name=datadbp
                                                 r
log_archive_dest_20                  string
log_archive_dest_21                  string
log_archive_dest_22                  string
log_archive_dest_23                  string
log_archive_dest_24                  string
log_archive_dest_25                  string
log_archive_dest_26                  string

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_27                  string
log_archive_dest_28                  string
log_archive_dest_29                  string
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_1             string      enable
log_archive_dest_state_10            string      enable
log_archive_dest_state_11            string      enable
log_archive_dest_state_12            string      enable
log_archive_dest_state_13            string      enable
log_archive_dest_state_14            string      enable
log_archive_dest_state_15            string      enable
log_archive_dest_state_16            string      enable
log_archive_dest_state_17            string      enable
log_archive_dest_state_18            string      enable
log_archive_dest_state_19            string      enable
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2             string      enable
log_archive_dest_state_20            string      enable
log_archive_dest_state_21            string      enable
log_archive_dest_state_22            string      enable
log_archive_dest_state_23            string      enable
log_archive_dest_state_24            string      enable
log_archive_dest_state_25            string      enable
log_archive_dest_state_26            string      enable
log_archive_dest_state_27            string      enable
log_archive_dest_state_28            string      enable
log_archive_dest_state_29            string      enable
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
fal_client                           string      datadbsb
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
fal_server                           string      datadbpr1, datadbpr2
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
standby_file_management              string      AUTO




Prod


Код: xml
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
SQL> show parameter LOG_ARCHIVE_MAX_PROCESSES;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_max_processes            integer     8
SQL> show parameter log_archive_config;
show parameter log_archive_dest_1;
show parameter log_archive_dest_2;
show parameter log_archive_dest_state_1;
show parameter log_archive_dest_state_2;
show parameter FAL_CLIENT;
show parameter fal_server;
show parameter standby_file_management;
show parameter log_file_name_convert;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_config                   string      dg_config=(datadbpr,datadbsb)
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1                   string      LOCATION=USE_DB_RECOVERY_FILE_
                                                 DEST MANDATORY REOPEN=5
log_archive_dest_10                  string
log_archive_dest_11                  string
log_archive_dest_12                  string
log_archive_dest_13                  string
log_archive_dest_14                  string
log_archive_dest_15                  string
log_archive_dest_16                  string
log_archive_dest_17                  string
log_archive_dest_18                  string

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_19                  string
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2                   string      service=datadbpr1 LGWR ASYNC va
                                                 lid_for=ONLINE_LOGFILES,PRIMAR
                                                 Y_ROLE) db_unique_name=datadbpr
log_archive_dest_20                  string
log_archive_dest_21                  string
log_archive_dest_22                  string
log_archive_dest_23                  string
log_archive_dest_24                  string
log_archive_dest_25                  string
log_archive_dest_26                  string
log_archive_dest_27                  string

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_28                  string
log_archive_dest_29                  string
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_1             string      enable
log_archive_dest_state_10            string      enable
log_archive_dest_state_11            string      enable
log_archive_dest_state_12            string      enable
log_archive_dest_state_13            string      enable
log_archive_dest_state_14            string      enable
log_archive_dest_state_15            string      enable
log_archive_dest_state_16            string      enable
log_archive_dest_state_17            string      enable
log_archive_dest_state_18            string      enable
log_archive_dest_state_19            string      enable
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2             string      enable
log_archive_dest_state_20            string      enable
log_archive_dest_state_21            string      enable
log_archive_dest_state_22            string      enable
log_archive_dest_state_23            string      enable
log_archive_dest_state_24            string      enable
log_archive_dest_state_25            string      enable
log_archive_dest_state_26            string      enable
log_archive_dest_state_27            string      enable
log_archive_dest_state_28            string      enable
log_archive_dest_state_29            string      enable
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
fal_client                           string      datadbpr1
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
fal_server                           string      datadbsb
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
standby_file_management              string      MANUAL
SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_file_name_convert                string      +ORADATDG/datadbsb, +ORADATDATA/a
                                                 cbdbpr, /oracle/orafra/datadbsb
                                                 , +ORAFRADATA/datadbpr
...
Рейтинг: 0 / 0
19.08.2021, 10:19
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091993
flexgen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
flexgen
Участник
AleksRous

Нужно ждать пока процесс закончится ?


Да, периодически проверяй какой archived log file прошел процесс recovery.
...
Рейтинг: 0 / 0
19.08.2021, 19:05
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40091997
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
flexgen
AleksRous

Нужно ждать пока процесс закончится ?


Да, периодически проверяй какой archived log file прошел процесс recovery.



Все норм помогли, спс.

Последний вопрос если в PRIMARY нет нужных архивов, и STANDBY лежит уже 3-4 дня, а PRIMARY пометил архив как EXPIRED и удалил , тогда придется через восстанавливать бекап ?
...
Рейтинг: 0 / 0
19.08.2021, 19:28
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40092019
flexgen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
flexgen
Участник
AleksRous
Последний вопрос если в PRIMARY нет нужных архивов, и STANDBY лежит уже 3-4 дня, а PRIMARY пометил архив как EXPIRED и удалил , тогда придется через восстанавливать бекап ?


Прежде всего проверь наличие этих файлов на STANDBY, вдруг они там есть ;-).

Если же файлов нет то можно сделать следующее:
  • Выяснить текущий SCN базы STANDBY
  • Выполнить RMAN incremental backup from SCN на PRIMARY, используя SCN, полученный в предыдущем пункте
  • Выполнить RMAN restore на STANDBY.
...
Рейтинг: 0 / 0
19.08.2021, 20:27
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40092100
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
flexgen
AleksRous
Последний вопрос если в PRIMARY нет нужных архивов, и STANDBY лежит уже 3-4 дня, а PRIMARY пометил архив как EXPIRED и удалил , тогда придется через восстанавливать бекап ?


Прежде всего проверь наличие этих файлов на STANDBY, вдруг они там есть ;-).

Если же файлов нет то можно сделать следующее:
  • Выяснить текущий SCN базы STANDBY
  • Выполнить RMAN incremental backup from SCN на PRIMARY, используя SCN, полученный в предыдущем пункте
  • Выполнить RMAN restore на STANDBY.



Спасибо вам, все прекрасно объяснили
...
Рейтинг: 0 / 0
20.08.2021, 08:20
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40092105
Фотография shane54
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shane54
Участник
AleksRous

Последний вопрос если в PRIMARY нет нужных архивов, и STANDBY лежит уже 3-4 дня, а PRIMARY пометил архив как EXPIRED и удалил , тогда придется через восстанавливать бекап ?


(прищюрившись) Что-то тут не чисто. Вот прям само оно удалило необходимые (непримененные) архивлоги для Stand-By базы, да? В общем, версий придумать можно много, как это произошло, но Вам как бы видней.

В любом случае, это абсолютно ненормально, к тому же если база важная, и на Stand-By Вы расчитываете, и может у Вас даже SLA где-то прописано, за сколько на Stand-By необходимо гарантировано переключаться - то стоит подкрутить необходимые ручки.

Во-первых специально для Вашего случая у RMAN'есть настройка - как удалять (не удалять) архивлоги:

Код: plsql
1.
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY



https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/using-RMAN-in-oracle-data-guard-configurations.html#GUID-2AEB88E7-075F-47F4-BBCE-77B274A50683

Можно ещё добавить "... BACKED UP x TIMES ON DISK" (или ON TAPE) - суть мы говорим RMAN'у, что до тех пор пока архивлог не применился на необходимых Stand-By базах, и не был забекаплен необходимое количество раз - его стирать нельзя. Именно Ваш случай. Только нужно помнить, конечно, что если Stand-By стоит несколько дней, то архивлоги будут накапливаться, так что нужно поглядывать за местом.

И второе - вместо того чтобы целиком пересоздавть Stand-By, можно во-первых донакатить потерянные архивлоги методом инкрементального бекапа (BACKUP... FROM SCN) - как уже выше предложили, а во-вторых, если у Вас 12с и выше (версия базы вроде нигде в треде не упоминалось) - есть специально для такого случая новая фича:

Код: plsql
1.
RECOVER STANDY DATABASE FROM SERVICE...



https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/using-RMAN-in-oracle-data-guard-configurations.html#GUID-53AF8403-7ECC-4329-966E-965FDBFB4455

Под капотом там тоже создаётся инкрементальный бекап - просто Oracle сам вычисляет самый "нижний" SCN, с которого начинать инкрементальный бекап, сам его передаёт на Stand-By и сам его применяет. Получается восстановление поломанного Stand-By одной командой.
...
Рейтинг: 0 / 0
20.08.2021, 09:07
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40092373
AleksRous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AleksRous
Гость
[quot shane54#22362022]
AleksRous

архивлоги будут накапливаться, так что нужно поглядывать за местом.


Будут накапливаться на primary наверно имеете ввиду ?

Спасибо вам за развернутую инфу.
...
Рейтинг: 0 / 0
20.08.2021, 21:50
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40092378
Фотография shane54
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shane54
Участник
AleksRous
Будут накапливаться на primary наверно имеете ввиду ?


Очевидно, если Stand-By выключен - то и транспорт архивлогов до него не работает. Соответственно, да - архивлоги накапливаются во FRA на стороне Primary, но не стираются, так как они будут нужны когда Stand-By оживёт.

На самом деле там все ещё немного гибче. Так, для общего развития и расширения кругозора: по ссылке что я приводил на документацию, есть ещё второй вариант управления политикой стирания архивлогов - SHIPPED TO ALL STANDY (дополнительно к уже обговоренной политике APPLIED ON ALL STANDBY). Т.е. разрешается стирать архивлоги после их пересылки на сторону Stand-By, а применились они (apply) или нет - Primary уже не берет во внимание, и разрешает у себя стирать.
...
Рейтинг: 0 / 0
20.08.2021, 23:08
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40092381
Фотография shane54
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shane54
Участник
Для специалистов - пока собирал инфу, набрёл на интересный пост по теме:

https://blog.dbi-services.com/archivelog-deletion-policy-for-standby-database-in-oracle-data-guard/

Там автор, помимо прочего, обсуждает механизм работы FRA - если во FRA лежат архивлоги, и они уже не нужны, т.е. политики их удержания от стирания не нарушаются (суть они уже забекаплены и/или применены к Stand-By базе/ам), и при вызове из RMAN команды DELETE ARCHIVELOG...., они будут стёрты - то во вью V$RECOVERY_AREA_USAGE, в строке ARCHIVED LOG, в поле RECLAIMABLE, эти архивлоги будут отражены (их размер, в процентах). И в ситуации, когда во FRA начнётся нехватка места, Oracle сам начнёт стирать эти архивлоги, чтобы освободить место. Тут пока ничего интересного или нового, так все и работает, это всем известно.

Дальше - самое интересное, сама суть, чего я все это пишу (точнее, цитирую блог). Автор расковырял "устройство" вьюшки V$RECOVERY_AREA_USAGE (в смысле, какой запрос её формирует, достал из V$FIXED_VIEW_DEFINITION). И обнаружил, что используется X$-view и поле X$KCCAGF.RECTYPE. И дальше он решил "обогатить" вывод этой вью V$RECOVERY_AREA_USAGE (приджойнив ещё V$ARCHIVED_LOG), и добавить туда вывод списка конкретных архивлогов, которые и формируют значение RECLAIMABLE. Таким образом, вместо сухой цифры типа (просто пример) - "у вас тут архивлогов на 100 ГБ хранится во FRA, из них 50% не нужны и могут быть безопасно стерты (RECLAIMABLE)" - можно увидеть список конкретных архивлогов, файлов, которые формируют эти 50%.

Там потом он отдельный пост ещё сделал, уже только конкретно про этот запрос и про саму view:

https://blog.dbi-services.com/drilling-down-vrecoveryareausage/

От меня: на самом деле, из всех "FRA occupants" (термин этот наверно я сам придумал, по аналогии с "SYSAUX occupants" - на самом деле такого в документации нет) - из 7 типов файлов, что там хранятся - по опыту, архивлоги и flashback-логи - самые популярные, я бы сказал 99%. Так что если развить мысль автора блога - то нужно вью V$RECOVERY_AREA_USAGE ещё бы обогатить выводом конкретных файлов флешбеклогов, кого именно можно стирать, не боясь. Суть по той же логике - которые уже не нужны, но которые ещё на диске. И которые сам Oracle потрёт автоматом, как только возникнет FRA Free Space Pressure.
...
Рейтинг: 0 / 0
21.08.2021, 00:34
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40092404
KoTTT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KoTTT
Участник
shane54
конкретных файлов флешбеклогов, кого именно можно стирать, не боясь

А как конкретно вы собираетесь применять эту информацию и "стирать, не боясь"?
...
Рейтинг: 0 / 0
21.08.2021, 11:33
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40092405
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Спасибо
Очень хороший коментарий
...
Рейтинг: 0 / 0
21.08.2021, 12:22
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40092428
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Elic
Участник
Вячеслав Любомудров
Спасибо
Слава, ты сам должен понимать, что твой коммент выглядит безадресно. Неужели так сложно процитировать хоть маленький кусочек исходного сообщения, чтобы люди смогли понять контекст?
Сейчас же выглядит так, что ты поблагодарил кота.
...
Рейтинг: 0 / 0
21.08.2021, 19:09
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40092466
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Прошу прощения, действительно забываю про цитирование

И поблагодарил я действительно КоТТТа, поскольку flashback-логи полностью управляются ораклом и не предусмотрено никаких ручек чтоб "удалять лишнее"
...
Рейтинг: 0 / 0
22.08.2021, 06:37
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40092467
KoTTT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KoTTT
Участник
Elic
кота.

Выражаю спасибо обоим двум.
...
Рейтинг: 0 / 0
22.08.2021, 06:39
| Ответить | Цитировать | Написать  
ORA-10458: standby database requires recovery
    #40092485
Фотография shane54
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shane54
Участник
KoTTT
shane54
конкретных файлов флешбеклогов, кого именно можно стирать, не боясь

А как конкретно вы собираетесь применять эту информацию и "стирать, не боясь"?


Если это ко мне вопрос - то "стирать не боясь" я конечно оставляю право базе, руками стараюсь не лезть. Кроме ну совсем уж экстренных случаев. И я согласен, flashback-логами Oracle действительно хорошо управляет, как только изменился FLASHBACK_RETENTION_TARGET (в сторону уменьшения) или стёрли GRP - все ненужные flashback-логи тут же автоматом удаляются.

Вообще, есть костыль или хак, не знаю как назвать правильно, и не знаю, делает ли так кто-то в экстренных ситуациях. Если действительно нужно срочно освободить место, например размер FRA пусть будет 100 ГБ, и через вью V$RECOVERY_AREA_USAGE видно, допустим, что 50% его содержимого помечено как RECLAIMABLE. Тогда уменьшаем на минутку размер FRA на размер RECLAIMABLE объёма файлов :

Код: plsql
1.
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 50G;



(точнее 55G, с запасом небольшим, чтоб база не остановилась)
В соседнем окне открыт alert.log - в нем тут же появляется простыня на пару экранов сообщений типа:

Код: plsql
1.
2.
3.
4.
Deleted Oracle managed file +DATA1/orcl/archivelog/2010_04_26/thread_3_seq_90114.17125.717358729
Deleted Oracle managed file +DATA1/orcl/archivelog/2010_04_26/thread_3_seq_90115.17125.717358729
Deleted Oracle managed file +DATA1/orcl/archivelog/2010_04_26/thread_3_seq_90116.17125.717358729
...



И/или:

Код: plsql
1.
2.
3.
4.
Deleted Oracle managed file +DATA1/orcl/flashback/log_74.12659.717340839
Deleted Oracle managed file +DATA1/orcl/flashback/log_85.18441.717351679
Deleted Oracle managed file +DATA1/orcl/flashback/log_8.11194.717355103
...



И как только активность удаления "успокаивается" - обычно секунд 30-60 занимает удаление нескольких десятков файлов (с ASM), каждый по гигабайту или несколько - сразу же возвращаем обратно оригинальное значение:

Код: plsql
1.
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 100G;



Таким образом, подитожив: суть "метода" в том, чтобы на пару минут уменьшить размер FRA, как бы помогая базе "выдавить" из FRA файлы, которые можно удалять, как бы искусственно создавая Free Space Pressure ситуацию относительно FRA. При этом во FRA остаётся резерв места (5 ГБ в нашем примере), поэтому за минуту база точно не остановится, даже если запишет пару архивлогов в этот момент.

И все, дело сделано - Oracle сам удалил все что можно было безопасно удалить.
...
Рейтинг: 0 / 0
22.08.2021, 10:49
| Ответить | Цитировать | Написать  
32 сообщений из 32, показаны все 2 страниц
  все  
Форумы / Oracle [игнор отключен] [закрыт для гостей] / ORA-10458: standby database requires recovery
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=52&tid=1879964]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 135ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 63ms
get tp. blocked users:
 3ms
others: 12ms
total:  253ms
созд. / загр.: 253ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]