Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Проблема с контрольником бывшего праймери  [new]
micis
Member

Откуда:
Сообщений: 79
Имеем праймери+3 стендбая (все 12.1.0.2.0).
Недавно сделали плановый switchover без ошибок и проблем (базы ролями поменялись, накат логов пошёл на старый праймери).

После этого начались проблемы:
Если сделать контрольник с базы бывшего праймери командой
RMAN> backup current controlfile for standby format '/oradata/%d_control.bak';
то при разворачивании новой тестовой базы с этим контролом не применяется опция db_file_name_convert из инит-файла.
Но если сделать контрольник с любого другого хоста (новый праймери или другие стендбаи), то db_file_name_convert применяется как и надо.

При чём, и с того проблемного хоста ДО переключения switchover всё работало.

Что надо посмотреть/исправить?
7 ноя 16, 04:34    [19863916]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
Не знаю как 12, но до этого настройка DB_FILE_NAME_CONVERT применялась ТОЛЬКО при команде DUPLICATE (в том числе и при создании стендбая). При обычниых командах RECOVER/RESTORE оно игнорируется
7 ноя 16, 08:01    [19864001]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
Vadim Lejnin
Member

Откуда:
Сообщений: 7134
micis,

1) Покаж значение DB_FILE_NAME_CONVERT какое пытаешься используешь
2) Посмотри какие конкретно пути прописаны в этом control
strings -a *_control.bak | grep oradata
7 ноя 16, 09:07    [19864148]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
Q.Tarantino
Member [заблокирован]

Откуда: Где-то рядом...
Сообщений: 12015
Вячеслав Любомудров
Не знаю как 12, но до этого настройка DB_FILE_NAME_CONVERT применялась ТОЛЬКО при команде DUPLICATE (в том числе и при создании стендбая). При обычниых командах RECOVER/RESTORE оно игнорируется

если ресторить БД как стендбай - то работает.
7 ноя 16, 10:21    [19864393]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
micis
Member

Откуда:
Сообщений: 79
Q.Tarantino
если ресторить БД как стендбай - то работает.
Да, именно так и делаем обычно тестовые БД. Т.к. бекапы уже есть, вот с них и разворачиваем (да и нагрузку лишнюю не создаём):
- монтируем на тестовом сервере nfs-шару с бекапом (там же лежит и контрольник для стендбая)
- стартуем инстанс, восстанавливаем контрольник (инит-файлы уже готовы от предыдущей тестовой базы), монтируем
- в rman-е делаем CATALOG START WITH '/mnt/backups/...', затем restore + recover
- ну и затем активируем стендбай базу.


Vadim Lejnin,
SQL> select value from v$parameter where name='db_file_name_convert';

VALUE
----------------------------------------------------------------------------------------------------------------------------------------------------------
/oradata/crm03, /oradata/dbtest

$ strings -a crm03_control.bak | grep oradata
/oradata/crm03/T_USR36.dbf
/oradata/crm03/T_AUD11.dbf
/oradata/crm03/T_USR35.dbf
/oradata/crm03/I_USR37.dbf
/oradata/crm03/I_USR36.dbf
/oradata/crm03/I_USR35.dbf
/oradata/crm03/T_USR34.dbf
/oradata/crm03/T_USR33.dbf
/oradata/crm03/T_AUD10.dbf
/oradata/crm03/I_AUD04.dbf
...

Проверял уже пути на 10 раз. Не в них дело, видимо.
7 ноя 16, 12:07    [19865120]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
Q.Tarantino
Member [заблокирован]

Откуда: Где-то рядом...
Сообщений: 12015
micis
монтируем

не уверен, но все же... монтируете через 'alter database mount standby database'?
7 ноя 16, 12:41    [19865261]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
micis
Member

Откуда:
Сообщений: 79
Q.Tarantino
не уверен, но все же... монтируете через 'alter database mount standby database'?
Нет, просто mount. Но проверил сейчас и с данной командой - тот же результат. Да и документация говорит о том же:
The keywords STANDBY DATABASE are optional, because Oracle Database determines automatically whether the database to be mounted is a primary or standby database

Проверил уже все шаги по этой инструкции Creating a Physical Standby Database

При чём, если взять контрольник с "нормального" стендбая, восстановить на тесте и смонтировать БД, то
RMAN> select name from v$datafile where file#=1;



NAME                                                                            
--------------------------------------------------------------------------------

/oradata/dbtest/system01.dbf
показывает сконвертированный путь, хотя в контрольнике исходные пути
$ strings -a control01.ctl | grep oradata | grep system01.dbf 
/oradata/crm03/system01.dbf
/oradata/crm03/system01.dbf


Куда ещё смотреть?
8 ноя 16, 06:35    [19868560]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
micis
Member

Откуда:
Сообщений: 79
Попробовал на тестовом стенде повторить проблему - всё аналогично проду.

Видимо придётся переходить на команду DUPLICATE (архивлоги не бекапятся у нас, поэтому DUPLICATE идёт без опции DORECOVER):
$ rman CONNECT AUXILIARY /
RMAN> DUPLICATE DATABASE FOR STANDBY BACKUP LOCATION '/mnt/backups/' NOFILENAMECHECK;
RMAN> RECOVER CLONE DATABASE UNTIL SCN ...;
Только опять же, теперь не переименовываются автоматом редологи (может из-за отсутствия DORECOVER?). Но их проще пересоздать...
16 ноя 16, 10:21    [19898920]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
А для логов нужно LOG_FILE_NAME_CONVERT
17 ноя 16, 02:13    [19901950]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
micis
Member

Откуда:
Сообщений: 79
Вячеслав Любомудров
А для логов нужно LOG_FILE_NAME_CONVERT
Так в том-то и дело, что стоял этот параметр. Да и сейчас задан, автоматом перейдя в spfile.
17 ноя 16, 08:28    [19902064]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
Q.Tarantino
Member [заблокирован]

Откуда: Где-то рядом...
Сообщений: 12015
micis
NOFILENAMECHECK

если файлы переименовываются, зачем тут это?
17 ноя 16, 09:00    [19902119]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
А он сначала проверяется
17 ноя 16, 09:02    [19902122]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
Q.Tarantino
Member [заблокирован]

Откуда: Где-то рядом...
Сообщений: 12015
Вячеслав Любомудров
А он сначала проверяется

расшифруй?
я когда создавал тестовые БД по другим путям всегда убирал данный параметр - сразу видно если что-то забыл прописать в CONVERT.
17 ноя 16, 09:04    [19902130]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
Забей, я прогнал
17 ноя 16, 09:19    [19902158]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
micis
Member

Откуда:
Сообщений: 79
Q.Tarantino
если файлы переименовываются, зачем тут это?
А иначе получаю ошибку RMAN-05001. У меня все базы на одном хосте.
Хотя рман пишет, что конфликт с именем уже по сконвертированному пути:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 11/17/2016 17:04:41
RMAN-05501: aborting duplication of target database
RMAN-05001: auxiliary file name /oradata/test/test_convert_filename.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /oradata/test/users01.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /oradata/test/undo01.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /oradata/test/sysaux01.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /oradata/test/system01.dbf conflicts with a file used by the target database
А на самом деле этих файлов ещё нет. Он смотрит в /oradata/prod, где лежит исходная база.
18 ноя 16, 03:17    [19906086]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
micis
Member

Откуда:
Сообщений: 79
А сейчас вылезло вообще не пойми что:
+

$ rlwrap rman auxiliary /

Recovery Manager: Release 12.1.0.2.0 - Production on Fri Nov 18 16:20:22 2016

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

connected to auxiliary database: PROD (not mounted)

RMAN> DUPLICATE DATABASE FOR STANDBY BACKUP LOCATION '/oradata/test/backup' NOFILENAMECHECK dorecover;

Starting Duplicate Db at 18.11.2016 16:20:53

contents of Memory Script:
{
   restore clone standby controlfile from  '/oradata/test/backup/PROD_43_928235945_1brl7gd9_1_1';
}
executing Memory Script

Starting restore at 18.11.2016 16:20:53
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=162 device type=DISK

channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/oradata/test/control1.ctl
Finished restore at 18.11.2016 16:20:56

contents of Memory Script:
{
   sql clone 'alter database mount standby database';
}
executing Memory Script

sql statement: alter database mount standby database
released channel: ORA_AUX_DISK_1
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=162 device type=DISK
allocated channel: ORA_AUX_DISK_2
channel ORA_AUX_DISK_2: SID=475 device type=DISK

contents of Memory Script:
{
   set until scn  2196101;
   set newname for tempfile  1 to 
 "/oradata/test/temp01.dbf";
   switch clone tempfile all;
   set newname for datafile  1 to 
 "/oradata/test/system01.dbf";
   set newname for datafile  2 to 
 "/oradata/test/sysaux01.dbf";
   set newname for datafile  3 to 
 "/oradata/test/undo01.dbf";
   set newname for datafile  4 to 
 "/oradata/test/users01.dbf";
   set newname for datafile  5 to 
 "/oradata/test/test_convert_filename.dbf";
   restore
   clone database
   ;
}
executing Memory Script

executing command: SET until clause

executing command: SET NEWNAME

renamed tempfile 1 to /oradata/test/temp01.dbf in control file

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

Starting restore at 18.11.2016 16:21:04
using channel ORA_AUX_DISK_1
using channel ORA_AUX_DISK_2

creating datafile file number=1 name=/oradata/test/system01.dbf
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 11/18/2016 16:21:05
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: ORACLE error from auxiliary database: ORA-01180: can not create datafile 1
ORA-01110: data file 1: '/oradata/prod/system01.dbf'

После переименования датафайлов, рман пытается восстановить в старый каталог!
18 ноя 16, 10:35    [19906582]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с контрольником бывшего праймери  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
Нет, восстановиться он пытается в новый, а в последней строчке он тебе пишет информацию из контрола (там, естественно, путь старый)
18 ноя 16, 15:41    [19908548]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить