Добрый день,
не могли бы вы помочь с одной проблемой?
Отстал стендбай из-за того что потерялись архивлоги. Сделал инкрементальный бекап с примари.
накатился бекап с контрол файлом успешно, но при рестарте стендбайной бд появились ошибки что не может увидеть локацию файлов , файлы я дал увидеть через ALTER DATABASE RENAME FILE, но такое видение что бекап накатился криво
т.к. БД просит старые ахивлоги которых нет
Fri Jun 14 16:32:57 2019
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 137291-137390
DBID 412706198 branch 884424854
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.

собственно вот , версия оракла 10g R2

проходил мимо...Честно, не очень понял вашу схему с накатом инкрементального бэкапа и сменой положения файлов. Вы и контролфайл новый, что ли, положили с примари?

yalkun87 FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 137291-137390

На 10-ках бывает. Просто перезапустите вручную накат без disconnect и current logfile, если пойдёт - подождите переключения накатываемого лога - и можно запускать обычным способом. Больше требовать старых логов не будет. Если не пойдёт - пересоздайте с примари контролфайл.

вот ссылка по которой я работал
https://docs.oracle.com/cd/B19306_01/server.102/b14239/scenarios.htm#CIHEGFEG

Не совсем вас понял про ручной режим? Дело в том что у нас стоит standart edition
т.е. мне нужно на стендбае набрать
recover standby database;
recover cancel; ?

проходил мимо...yalkun87Не совсем вас понял про ручной режим? Дело в том что у нас стоит standart edition
т.е. мне нужно на стендбае набрать
recover standby database;
recover cancel; ?
С опытом на Стандарте не очень, но, в целом, должно быть примерно так :)

yalkun87вот ссылка по которой я работал
https://docs.oracle.com/cd/B19306_01/server.102/b14239/scenarios.htm#CIHEGFEG
Там же, вроде, про Ынтерпрайз, но зато всё объясняет.
Мне кажется (спросоня), что там вполне можно было бы остановиться на 6-м пункте и сразу идти на 16-й.

к сожалению не работает( Все равно просит старый архивлог и почему то думает что system01 неправильный

alter database recover managed standby database cancel;

Database altered.

SQL> recover standby database;
ORA-00279: change 64240423121 generated at 10/06/2018 05:29:00 needed for
thread 1
ORA-00289: suggestion : /bd/log/trcard/t_884424854_0001_0000137291.dbf
ORA-00280: change 64240423121 for thread 1 is in sequence #137291


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/bd/trcard/system01.dbf'


ORA-01112: media recovery not started

проходил мимо...,

псмотрел другим путем, но ваши селекты показывают более подробную информация) заранее благодарю. Кажется что бекап не накатился, хотя он прошел успешно. Вся соль в том что у меня нет требуемого лога

и так мой scn
SELECT to_char(CURRENT_SCN) FROM V$DATABASE;

TO_CHAR(CURRENT_SCN)
----------------------------------------
72875065642

в V$DATAFILE_HEADER; ниже 72875065642

SELECT to_char(CHECKPOINT_CHANGE#) FROM V$DATAFILE_HEADER;

TO_CHAR(CHECKPOINT_CHANGE#)
----------------------------------------
71884627805
72806892417
72842850315
72840916691
72842850315
72842850315
72806242703
72842850315
72842850315
72842850315
72842850315

TO_CHAR(CHECKPOINT_CHANGE#)
----------------------------------------
72806892417
72806927761
72806965495
72806983088
72806985330
72806991934
72806997463
72807005255
72807066037
72806927761
72807135461

TO_CHAR(CHECKPOINT_CHANGE#)
----------------------------------------
72807272040
72806615825
72807438301
72806965495
72807518164
72807736638
72808444212
72808920734
72809762170
72810421922
72811702641

TO_CHAR(CHECKPOINT_CHANGE#)
----------------------------------------
72806983088
72812608636
72813972018
72815575584
72817221344
72818090124
72819560882
72820869950
72821782257
72806985330
72822872382

TO_CHAR(CHECKPOINT_CHANGE#)
----------------------------------------
72824962033
72825821668
72827207436
72828413092
72829645199
72842850315
72830607603
72831909857
72833214443
72806991934
72835787587

TO_CHAR(CHECKPOINT_CHANGE#)
----------------------------------------
72838448526
72840916691
72802113945
72802113945
72803499493
72803499493
72806997463
72807005255
72805115426
72805115426
72807066037

TO_CHAR(CHECKPOINT_CHANGE#)
----------------------------------------
72796388241
72807135461
72796388241
72798750189
72807272040
72798750189
72800414541
72807438301
72800414541
72806840027
72807518164

TO_CHAR(CHECKPOINT_CHANGE#)
----------------------------------------
72806840027
72806242703
72806242703
72807736638
72808444212
72808920734
72809762170
72810421922
72842850315
72811702641
72812608636

TO_CHAR(CHECKPOINT_CHANGE#)
----------------------------------------
72845424945
64240423121
72815575584
72817221344
72818090124
72842850315
72819560882
72820869950
72798750189
72800414541
72806242703

TO_CHAR(CHECKPOINT_CHANGE#)
----------------------------------------
72821782257
72822872382
72824962033
72825821668
72802113945
72805115426
72827207436
72803499493
72806615825
72828413092
72829645199

TO_CHAR(CHECKPOINT_CHANGE#)
----------------------------------------
72806615825
72798750189
72830607603
72845424945
72831909857
72833214443
72806615825
72805115426
72835787587
72796388241
72838448526

TO_CHAR(CHECKPOINT_CHANGE#)
----------------------------------------
72803499493
72796388241
72806840027
72800414541
72796388241
72858214916

Расскажите, пожалуйста,
1 как Вы бэкапите праймари БД,
у нас вообще не бэкапится бд, был только инкрементальный бекап чтобы догнать примари
2 как создали ручной стэндбай,
стендбай создавал не я
3 как передаёте и накатываете архивлоги на стэндбай.Aliona,
передаем через rsync и накат лога идет через скрипт


if [ $# -ne 1 ]; then
echo "usage: $0 SID"
exit
fi

. $HOME/profile_${1}
ORACLE_SID=$1

sqlplus "/ as sysdba" << EOF
set autorecovery on;
recover standby database;
recover cancel;
@$HOME/scr/arch.sql $1;
EOF
cat $HOME/scr/arch.sql
SET ECHO OFF VERIFY OFF FEEDBACK OFF HEADING OFF TRIMOUT ON TRIMSPOOL ON TERMOUT OFF NEWPAGE NONE;
SET PAGESIZE 1000 LINESIZE 150;
SPOOL $HOME/scr/tmp/seq&&1..txt;
COLUMN seq FORMAT FM999999999999;
SELECT MAX(sequence#) seq FROM v$log_history;
SPOOL OFF;
EXIT;

Aliona,

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

Aliona,

вы невнимательно кажется читали сообщения)
такое ощущение что вы хвастаетесь знаниями)

вы не думали что люди сюда приходят с разными уровнями знаний ?
я же дал вам ответы на ваши вопросы

1 как Вы бэкапите праймари БД,
у нас вообще не бэкапится бд, был только инкрементальный бекап чтобы догнать примари , и который кажется криво накатился
2 как создали ручной стэндбай,
стендбай создавал не я
3 как передаёте и накатываете архивлоги на стэндбай.Aliona,
передаем через rsync и накат лога идет через скрипт


if [ $# -ne 1 ]; then
echo "usage: $0 SID"
exit
fi

. $HOME/profile_${1}
ORACLE_SID=$1

sqlplus "/ as sysdba" << EOF
set autorecovery on;
recover standby database;
recover cancel;
@$HOME/scr/arch.sql $1;
EOF
cat $HOME/scr/arch.sql
SET ECHO OFF VERIFY OFF FEEDBACK OFF HEADING OFF TRIMOUT ON TRIMSPOOL ON TERMOUT OFF NEWPAGE NONE;
SET PAGESIZE 1000 LINESIZE 150;
SPOOL $HOME/scr/tmp/seq&&1..txt;
COLUMN seq FORMAT FM999999999999;
SELECT MAX(sequence#) seq FROM v$log_history;
SPOOL OFF;
EXIT;

Вячеслав Любомудров,

пишу логи
1) инкрементальный бекап прошел успешно (BACKUP INCREMENTAL FROM SCN 72678659749 DATABASE FORMAT )
и самого контрол файла через backup CURRENT CONTROLFILE for standby FORMAT

2) после наката бекапа и контрол файла я рестартанул бд и получил такие сообщения
ORA-01157: cannot identify/lock data file 19 - see DBWR trace file
ORA-01110: data file 19: '/bd/trcard/users03.dbf'
ORA-27037: unable to obtain file status
Solaris-AMD64 Error: 2: No such file or directory
Additional information: 3
ORA-01157: cannot identify/lock data file 22 - see DBWR trace file
ORA-01110: data file 22: '/bd/trcard/users04.dbf'
ORA-27037: unable to obtain file status
Solaris-AMD64 Error: 2: No such file or directory
Additional information: 3
ORA-01157: cannot identify/lock data file 24 - see DBWR trace file
ORA-01110: data file 24: '/bd/trcard/users05.dbf'
ORA-27037: unable to obtain file status
Solaris-AMD64 Error: 2: No such file or directory
Additional information: 3
ORA-01157: cannot identify/lock data file 25 - see DBWR trace file
ORA-01110: data file 25: '/bd/trcard/users06.dbf'
ORA-27037: unable to obtain file status
Solaris-AMD64 Error: 2: No such file or directory
Additional information: 3
ORA-01157: cannot identify/lock data file 27 - see DBWR trace file
ORA-01110: data file 27: '/bd/trcard/users08.dbf'
ORA-27037: unable to obtain file status
Solaris-AMD64 Error: 2: No such file or directory
Additional information: 3
ORA-01157: cannot identify/lock data file 28 - see DBWR trace file
ORA-01110: data file 28: '/bd/trcard/USERS09.dbf'
ORA-27037: unable to obtain file status
Solaris-AMD64 Error: 2: No such file or directory
Additional information: 3
ORA-01157: cannot identify/lock data file 32 - see DBWR trace file
ORA-01110: data file 32: '/bd/trcard/users10.dbf'
ORA-27037: unable to obtain file status
Solaris-AMD64 Error: 2: No such file or directory

в БД я переименовал пути к файлам ALTER DATABASE RENAME FILE

попытался снова накатить бекап , накатился успешно но я вижу что бд не соответствует консистентности так как просит старый архив лог
Fri Jun 14 16:32:57 2019
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 137291-137390
DBID 412706198 branch 884424854
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.


Media Recovery Log /bd/log/t_884424854_0001_0000137291.dbf
Errors with log /bd/log/t_884424854_0001_0000137291.dbf

то что бекап накатился не так как надо, подтверждаются моими сообщениями
21909572

Вячеслав ЛюбомудровЕсли бы чувак кроме "ля-ля" предоставил что-то конкретное (логи, команды) еще можно было бы о чем-то говорить

PS. Накат этого бэкапа можно повторить (при текущих контролах) и привести логи (и alert.log)
А только затем пересоздать и подменить контролы
уже пытался, безрезультатно

Вячеслав Любомудров,

накат бекапа был так
RECOVER DATABASE NOREDO;

сообщения все одинаковые
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
channel ORA_DISK_1: starting incremental datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00003: /bd/sysaux01.dbf
destination for restore of datafile 00005: /bd/xdb01.dbf
destination for restore of datafile 00006: /bd/idx01.dbf
destination for restore of datafile 00008: /bd/tools01.dbf
destination for restore of datafile 00009: /bd/scripts01.dbf
destination for restore of datafile 00010: /bd/mview.dbf
destination for restore of datafile 00011: /bd/tran01.dbf
destination for restore of datafile 00050: /bd/perfstat.dbf
destination for restore of datafile 00086: /bd/tran_idxold03.dbf
destination for restore of datafile 00094: /oracle/tran_idxold04.dbf
channel ORA_DISK_1: reading from backup piece /oradata/trcard_Standby_rku4188m_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/oradata/Standby_rku4188m_1_1 tag=TAG20190612T200409
channel ORA_DISK_1: restore complete, elapsed time: 00:02:36
Finished recover at 14-06-2019 01:34:07

потом ресторе контрол файла
RESTORE STANDBY CONTROLFILE FROM '/oradata/ForStandbyCTRL.bck';


channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output filename=/bd/control01.ctl
output filename=/bd/control02.ctl
Finished restore at 14-06-2019 09:04:32

такой вопрос при восстановлении контрол файла старые перезаписываются?

восстановил стендбай из полного бекапа, всем спасибо за помощь