Oracle 10.2

Что-то разладилось на стэндбай 06-MAR-2017, я не заметила.
29-MAR-2017 на стэндбае произошло переполнение диска с архивлогами.
Я руками удаляла архивлоги, руками ликвидировала дыры.
Запустился процесс RedoApply, архвлоги начали передаваться и накатываться.
Я спокойно ушла в отпуск,
а после отпуска обнаружилось, что на праймари после бэкапа перестали удаляться архивлоги по команде DELETE OBSOLETE.
На стэндбай архвлоги передаваться и накатываться.
Вот что обнаружила:

на праймари:
авторSELECT 'Last Applied: ' Logs, to_char(next_time, 'DD-MON-YYYY:HH24:MI:SS') Time
FROM v$archived_log
WHERE sequence# = (select max(sequence#) FROM v$archived_log where applied='YES')
UNION
SELECT 'Last Received: ' Logs, to_char(next_time, 'DD-MON-YYYY:HH24:MI:SS') Time
FROM v$archived_log
WHERE sequence# = (select max(sequence#) FROM v$archived_log);
авторLast Applied: ,29-MAR-2017:03:07:51
Last Received: ,13-APR-2017:15:58:22

на стэндбай:
авторSELECT 'Last Applied: ' Logs, to_char(next_time, 'DD-MON-YYYY:HH24:MI:SS') Time
FROM v$archived_log
WHERE sequence# = (select max(sequence#) FROM v$archived_log where applied='YES' and dest_id=3 ) ;

авторLast Applied:
06-MAR-2017:19:25:45

Как этому горю можно помочь?

Andrew123456а что в алерт.логе стендбая и прода?
В алертах сейсас всё распрекрасно, а алертов от 06.03.17 уже нет.

Nobody1111Это dataguard или скриптовый стендбай?

RMAN> SHOW ALL;

?Oracle 10.2 EE.
Естественно DG.

6 марта я настраивала стэндбай в Cloud Control 12.1, это была моя "роковая" ошибка, потом пришлось остановить DG broker на стэндбай, потому что он обрезает один длинный init-параметр.
Cloud Control 12.1 - сырая версия, но другой нет, раньше я работала с СС 12.5 или 12.4, таких мелких пакостей не замечала.

Так вот с 6 марта и появилась проблема,
на стэндбай: Last Applied: 06-MAR-2017:19:25:45

на прамари и стэндбай:

авторRMAN> show all;

using target database control file instead of recovery catalog
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/mnt/nfs/sunset/%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/mnt/nfs/sunset/%U' MAXOPENFILES 10 MAXPIECESIZE 1 G;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/oracle/product/10gr2/dbs/snapcf_sunset.f'; # default

Nobody1111Nobody1111> Я руками удаляла архивлоги, руками ликвидировала дыры.

После этого delete expired делала?

В смысле,
crosscheck и delete expired

делала.

Nobody1111А, Data Guard.

При delete obsolete что выводит, почему не удаляет?


В протоколе все предсказуемо. Если архивлог not APPLIED на стэндбай, то он не удаляется на праймари и он не считается OBSOLETE:

авторStarting backup at 14-APR-17

current log archived
using channel ORA_DISK_1
skipping archive log file /uxx/oracle/oradata/sunset/arch/1_493527_560367377.dbf; already backed up 1 time(s)
skipping archive log file /uxx/oracle/oradata/sunset/arch/1_493528_560367377.dbf; already backed up 1 time(s)
...
channel ORA_DISK_1: starting compressed archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=493692 recid=457091 stamp=941243738
input archive log thread=1 sequence=493693 recid=457094 stamp=941244102
input archive log thread=1 sequence=493694 recid=457095 stamp=941244353
input archive log thread=1 sequence=493695 recid=457098 stamp=941244712
input archive log thread=1 sequence=493696 recid=457101 stamp=941245269
input archive log thread=1 sequence=493697 recid=457106 stamp=941245711
channel ORA_DISK_1: starting piece 1 at 14-APR-17
channel ORA_DISK_1: finished piece 1 at 14-APR-17
piece handle=/mnt/nfs/sunset/nvs1kjum_1_1 tag=TAG20170414T015415 comment=NONE
channel ORA_DISK_1: starting piece 2 at 14-APR-17
channel ORA_DISK_1: finished piece 2 at 14-APR-17
piece handle=/mnt/nfs/sunset/nvs1kjum_2_1 tag=TAG20170414T015415 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:10:02
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/uxx/oracle/oradata/sunset/arch/1_493692_560367377.dbf thread=1 sequence=493692
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/uxx/oracle/oradata/sunset/arch/1_493693_560367377.dbf thread=1 sequence=493693
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/uxx/oracle/oradata/sunset/arch/1_493694_560367377.dbf thread=1 sequence=493694
...

Q.TarantinoавторCONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
на праймари я бы поставил shipped to all standby

Это из oracle 11.2

авторSpecify when archived logs can be deleted with the CONFIGURE ARCHIVELOG DELETION POLICY command. For example, if you want to delete logs after ensuring that they shipped to all destinations, use the following configuration:

CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;

If you want to delete logs after ensuring that they were applied on all standby destinations, use the following configuration:

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

В 10.2 такого нет, есть только :

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

я это на прамари только вчера убрала, но не помогло.

Если мне память ни с кем не изменяет эти параметры работают с FRA, а у меня сейчас FRA не используется.

Q.Tarantinoа журнал 493692 уже имеется на стендбае?
может сперва синхронизировать стендбай с праймари и потом разбираться?
Вы невнимательно читали мою проблему.

архивные журналы передаются и применяются, в alrt.log на праймари и стэндбай всё красиво,
Праймари и оба стэндбая синхронизированы.
Но одном на стэндбае
Last Applied: 06-MAR-2017:19:25:45

Nobody1111То есть все работает, только показывает в applied ерунду? Контролфайл можно попробовать пересоздать. И с нуля конфигурацию DG до кучи.

Что-то не понимаю, почему это называется горем... Глюк это, а не горе, если правильно понял.
Именно так.
А горе - это "горе".
Пересоздать контрольник была такая мысль, но я такого на стэндбае ещё никогда не делала,. методики не знаю, а времени уже нет на эксперименты.
В понедельник стэндбай пересоздаю.


Подскажите, как контрольник пересоздать и DG до кучи, потом на тесте попробую.

д0kХ
1. провелить значение log_archive_dest_N_ state.

Если включить enable ести там другое значение.

2.
отресторить все дырки с бекапа на прймари,
скопировать, можно только первый мегабайт каждого лога, на стендбай.
alter database register logfile '....."; для всех дырок на стендбае
вкюлчить гардовский транспорт и применение.

3. Дождаться пока датагард приведет все сам в порядок.

1. log_archive_dest_N_ state все ENABLE, иначе бы арзивлоги бы не передавались на стэндбай.
2. Сейчас дырок никаких нет.
Возможно, надо было выполнить alter database register logfile '....."; для всех дырок на стендбае
когда я дырки ликвидировала, 29.03.2017.
Вчера у меня тоже была такая мысль, что надо было зарегистрировать архивлоги, которые я руками копировала, чтобы заткнуть дырки.
А теперь те архивлоги, уже удалены давным-давно и с дисков, и из бэкапов.

Q.TarantinoAliona,

А что говорит dgmgrl?
show configuration;
show database <standby>;
Вы опять невнимательно читали.

DВАЕсли стендбай нормально накатывается, то зачем его пересоздавать?
Пересоздай контрольник командой
alter database create standby controlfile as '....'
и подложи его вместо текущего на стендбай
Проверь сетевую взаимодоступность по алиасам или по брокерским конфигам прода и всех стендбаев межу собой, все должны друг друга видеть
Проверь log_archive_config - везде должен быть однаков
Можно ссылку на документацию.
Как персоздать контролькик для однрой БД, я знаю,
А как это делать в DG пробовала.
Экспериментировать на промышленные базах не охота.

Aliona[
А как это делать в DG пробовала.

НЕ пробовала.

Q.TarantinoAlionaпропущено...

Вы опять невнимательно читали.
Алиона, я перелистал все с начала - не нашел ответа. Подскажи, что я пропустил?

ранее было написано:
6 марта я настраивала стэндбай в Cloud Control 12.1, это была моя "роковая" ошибка, потом пришлось остановить DG broker на стэндбай, потому что он обрезает один длинный init-параметр.
Cloud Control 12.1 - сырая версия, но другой нет, раньше я работала с СС 12.5 или 12.4, таких мелких пакостей не замечала.

Q.Tarantinoа разве CC не использует брокер? не знаю насчет 12.1, но если конфигурять из CC той версии, что имею, он как раз и создает конфигурацию брокера...
Вот именно из-за этого это "горе" и произошло.

Вы 2 раза прочитали и не поняли.

СС создал конфигурацию Brokere, а этот брокер имеет баг, я брокер выключила.
И решила что СС версии 1 в серьёзных вещах больше использовать не буду, только картинки смотреть.

Вячеслав ЛюбомудровИ еще -- 10-ка не гарантировала правильную информацию V$ARHIVED_LOG.APPLIED на боевом.
Поэтому, проверяй эту информацию со стендбая и делай DELETE ARCHIVELOG UNTIL SEQUENCE

10-ка не гарантировала, но у меня работало на праймари DELETE OBSOLETE. :(