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

Откуда:
Сообщений: 5
Добрый день! Прошу консультации, возможно плохо искал, но совсем похожей ситуации не нашел.
Суть такая. Работает связка PROD-физ. STANDBY (dataguard) на 2008й r2 64х, oracle 10.2.0.5 ent . Возникла в общем со временем необходимость организации в другом городе зеркала базы,решено было для пущей надежности и актуальности организовать там 2й физ standby (на 2003 r2 64х), организовали вроде все по доке на PROD

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,STANDBY,STANDBY2)'
*.LOG_ARCHIVE_DEST_1='LOCATION=F:\ARCHIVE VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PROD'
*.LOG_ARCHIVE_DEST_2='SERVICE=STANDBY LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STANDBY'
*.LOG_ARCHIVE_DEST_3='SERVICE=STANDBY2 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STANDBY2'
*.LOG_ARCHIVE_DEST_STATE_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_dest_state_3='ENABLE'
*.FAL_CLIENT='PROD'
*.FAL_SERVER='STANDBY, STANDBY2'
*.STANDBY_FILE_MANAGEMENT='AUTO'


собственно аналогичным примерным образом на 1м и 2м стендбае

DB_UNIQUE_NAME=STANDBY2
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,STANDBY,STANDBY2)'
LOG_ARCHIVE_DEST_1='LOCATION=f:\archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=STANDBY2'
LOG_ARCHIVE_DEST_2='SERVICE=PROD LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PROD'
LOG_ARCHIVE_DEST_3='SERVICE=STANDBY LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STANDBY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE
LOG_FILE_NAME_CONVERT='f:\archive','f:\archive'
FAL_SERVER='PROD, STANDBY'
FAL_CLIENT=STANDBY2


DB_UNIQUE_NAME=STANDBY
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,STANDBY,STANDBY2)'
LOG_ARCHIVE_DEST_1='LOCATION=f:\archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=STANDBY'
LOG_ARCHIVE_DEST_2='SERVICE=PROD LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PROD'
LOG_ARCHIVE_DEST_3='SERVICE=STANDBY2 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STANDBY2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE
LOG_ARCHIVE_MAX_PROCESSES=10
LOG_FILE_NAME_CONVERT='f:\archive','f:\archive'
FAL_SERVER='PROD, STANDBY2'
FAL_CLIENT=STANDBY


но номер не удался, возникли проблемы с тем, что сервера физически находятся в разных доменах и разных подсети имеют, в общем перенастройкой днсов, маршрута на нужный контролер вроде частично решили проблему доступа, хоть они и попрежнему имеют разные подсети - все сервера друг друга запинговали и за тнспинговали. добавил разрешения для удаленных дисков, для разных групп пользователей и сетевых и уже просто всех, еще немного шаманств, и с любого из 3х серверов спокойно проходит подключение sqlplus к любому другому, все стендбаи знают что они стендбаи вроде все хорошо, но на проде падает ошибка доступa к внешнему стендбаю из другой сетки:

"ORA-01031: insufficient privileges
PING[ARC2]: Heartbeat failed to connect to standby 'STANDBY2'. Error is 1031."


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

соотвественно после открытия 2го стендбая

startup nomount pfile=c:\oracle\*\database\INITstandby2.ORA;
alter database mount standby database;
alter database recover managed standby database disconnect from session;


алерте стендбая

Wed Jul 02 09:01:05  2014
alter database recover managed standby database disconnect from session
MRP0 started with pid=26, OS id=3668
Wed Jul 02 09:01:06  2014
ARC7: Thread not mounted
Wed Jul 02 09:01:07  2014
ARC3: Thread not mounted
Wed Jul 02 09:01:08  2014
ARC8: Thread not mounted
Wed Jul 02 09:01:09  2014
ARC2: Thread not mounted
Wed Jul 02 09:01:10  2014
ARC5: Thread not mounted
Managed Standby Recovery not using Real Time Apply
 parallel recovery started with 7 processes
Wed Jul 02 09:01:11  2014
ARC4: Thread not mounted
Wed Jul 02 09:01:11  2014
Waiting for all non-current ORLs to be archived...
Media Recovery Waiting for thread 1 sequence 81736
Wed Jul 02 09:01:12  2014
ARC0: Thread not mounted
Wed Jul 02 09:01:12  2014
Completed: alter database recover managed standby database disconnect from session
Wed Jul 02 09:01:13  2014
ARC1: Thread not mounted
Wed Jul 02 09:01:14  2014
ARC9: Thread not mounted


пишет,что не включен режим авто-наката, и сидит себе спокойно, если смотреть archive log list то 0вые счетчики, ждет когда ему PROD скажет о том, что надо накатывать с какого там лога, тогда счетчики оживут, тк просто подложенные логи без единой связи с прод базой, ну естественно не накатываются (только если переводить на ручной накат, но тогда меняется немного смысл этой затеи )

При этом при всем проблем с 1м стенбаем, который изначально находился в одном домене с прод дб, не возникло он продолжает штатно работать. сильно подозреваю, что беда вся из-за разных доменов их настроек, но к сожалению особым доступом не обладаю к ним, а сетевые админы разводят руками, может у кого-то возникнут какие-то идеи или опыт подскажет подобного шаманства, что где упущено и куда б еще поглядеть, еще прописать? возможно можно как-то всех "обмануть" 2й стендбай, чтобы прод смог достучаться до него )
3 июл 14, 10:58    [16253475]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
BTM
Member

Откуда:
Сообщений: 139
Скопируйте с заменой файл пароля с прода на стендбай
3 июл 14, 11:20    [16253597]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
deny.chm
Member

Откуда:
Сообщений: 5
пересоздавал и копировал и заменял, и базу переподымал, ожидаемого эффекта не случилось
3 июл 14, 12:57    [16254296]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
Kamael
Member

Откуда: Алмата
Сообщений: 374
deny.chm
пересоздавал и копировал и заменял, и базу переподымал, ожидаемого эффекта не случилось

Показывайте, как пересоздавали?
3 июл 14, 13:53    [16254733]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
deny.chm
Member

Откуда:
Сообщений: 5
orapwd file=c:\oracle\pwdstandby.ora password=oracle;

его же и подсунул, собственно для первого работающего standby он абсолютно также создавался и работает
3 июл 14, 14:06    [16254875]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
Kamael
Member

Откуда: Алмата
Сообщений: 374
deny.chm
orapwd file=c:\oracle\pwdstandby.ora password=oracle;

его же и подсунул, собственно для первого работающего standby он абсолютно также создавался и работает

Не пойдёт.

Создай так
orapwd file=%ORACLE_HOME%\database\PWD%ORACLE_SID%.ORA password=oracle  entries=2 force=y

Скопировать его на все standby в %ORACLE_HOME%\database
3 июл 14, 14:14    [16254947]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
BTM
Member

Откуда:
Сообщений: 139
Кстати, что дает
select * from v$pwfile_users;
?
И параметр remote_login_passwordfile чему равен?
4 июл 14, 19:22    [16261936]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
deny.chm
Member

Откуда:
Сообщений: 5
BTM
Кстати, что дает
select * from v$pwfile_users;
?
И параметр remote_login_passwordfile чему равен?

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

USERNAME                       SYSDB SYSOP
------------------------------ ----- -----
SYS                            TRUE  TRUE

*.remote_login_passwordfile='EXCLUSIVE'
8 июл 14, 11:51    [16274091]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
deny.chm
Member

Откуда:
Сообщений: 5
orapwd file=%ORACLE_HOME%\database\PWD%ORACLE_SID%.ORA password=oracle  entries=2 force=y


спасибо, действительно после такого пересоздания произошло успешное подключение и определение стендбая, ну что же будем знать теперь :)
9 июл 14, 08:40    [16278953]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Второй внешний стендбай  [new]
stil
Member

Откуда: Кемерово
Сообщений: 1295
Имею ошибку:
автор
Thu Sep 08 08:55:25 2016
Error 1031 received logging on to the standby
PING[ARC2]: Heartbeat failed to connect to standby 'stbm'. Error is 1031.


Знаю, что на эту тему уже много написано на форуме - перепробовал все:

1) пересоздал файл паролей (пробовал и копировать с primary) командой
C:\Users\stil>orapwd file=%ORACLE_HOME%\database\PWD%ORACLE_SID%.ORA password=sys entries=2 force=y

Итог:
select * from v$pwfile_users
SYS	TRUE	TRUE	FALSE

Вроде нормально

2) sqlplus-ом с primary цепляюсь нормально
3)
*.remote_login_passwordfile='EXCLUSIVE'


P.S. На машине со стендбаем стоит другая ОС - Win 2008 Server (vs primary - Win 2003 server) - может это быть причиной??
8 сен 16, 05:05    [19640176]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
stil
2) sqlplus-ом с primary цепляюсь нормально
Под именем SYS и тем же паролем как на боевой и AS SYSOPER ?

show parameter log_archive_config
8 сен 16, 05:23    [19640182]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
stil
Member

Откуда: Кемерово
Сообщений: 1295
Вячеслав Любомудров
stil
2) sqlplus-ом с primary цепляюсь нормально
Под именем SYS и тем же паролем как на боевой и AS SYSOPER ?

Под SYSOPER не пробовал. Сейчас попробовал. Так же нормально законнектился
Вячеслав Любомудров
show parameter log_archive_config

SQL> show parameter log_archive_config

NAME                                 TYPE        VALUE
------------------------------------ ----------- ----------------------------
log_archive_config                   string      dg_config=(prim, stbr, stbm)

Этот параметр одинаков на primary и standby (standby есть еще один нормально функционирующий)

Сейчас заметил еще что на нормальном standby при коннекте sqlplus-ом OSUser определяется как stil, на новом как SDB1/stil. То есть добавляется имя машины. Я в настройках Win не силен - может быть проблема вообще не в оракловых настройках?
8 сен 16, 05:47    [19640189]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
stil
Member

Откуда: Кемерово
Сообщений: 1295
Правда с основной на этот стендбай на самом деле коннект проходит под любым паролем, не только SYS. Он его явно не проверяет
8 сен 16, 05:49    [19640191]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
stil
Этот параметр одинаков на primary и standby (standby есть еще один нормально функционирующий)
На всех трех?

stil
Сейчас заметил еще что на нормальном standby при коннекте sqlplus-ом OSUser определяется как stil, на новом как SDB1/stil. То есть добавляется имя машины. Я в настройках Win не силен - может быть проблема вообще не в оракловых настройках?
Как насчет домена и пользователя запускающего сервисы (на всех трех)
8 сен 16, 06:22    [19640204]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
stil
Member

Откуда: Кемерово
Сообщений: 1295
Вячеслав Любомудров
stil
Этот параметр одинаков на primary и standby (standby есть еще один нормально функционирующий)
На всех трех?

На функционирующем стендбае не было нового - stbm. Добавил. Но честно говоря не представляю что это мешало

Вячеслав Любомудров
stil
Сейчас заметил еще что на нормальном standby при коннекте sqlplus-ом OSUser определяется как stil, на новом как SDB1/stil. То есть добавляется имя машины. Я в настройках Win не силен - может быть проблема вообще не в оракловых настройках?
Как насчет домена и пользователя запускающего сервисы (на всех трех)

Пользователь запускающий сервисы - stil. Он входит в группу ora_dba. На первых двух серваках это нормально работает. Пользователя oracle я не стал создавать в свое время

Насчет домена - и вообще настроек Win новой чуть позже скажу как админ придет

Кстати, раз к слову пришлось - изза чего вообще пришлось делать еще один standby. Хотим перевезти оракловую ферму с
Win2003 32 на win2008 64.. Для этого хочу попробовать сделать функционирующий standby на win2008 64. А потом переехать постепенно. Вообще можно так делать?

Пока граблей, кроме вышеобсуждаемой ошибки коннекта не встретил.. Разве что кроме того, что софт отказался работать без oci.dll, которая есть только в клиенте 32х битном

Но подозреваю что многие грабли могут еще вылезти
8 сен 16, 06:48    [19640219]     Ответить | Цитировать Сообщить модератору
 Re: Второй внешний стендбай  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
stil
Вячеслав Любомудров
пропущено...
На всех трех?

На функционирующем стендбае не было нового - stbm. Добавил. Но честно говоря не представляю что это мешало
Насколько помню если этот параметр присутствует, то логи будут пересылаться только между перечисленными сервисами. Остальные будут игнорироваться. Т.е. либо он правильный, либо его нет. Наступал как-то

stil
Вячеслав Любомудров
пропущено...
Как насчет домена и пользователя запускающего сервисы (на всех трех)

Пользователь запускающий сервисы - stil. Он входит в группу ora_dba.
Пользователь доменный или локальный?
Группа доменная или локальная?
На всех трех
Это к тому, что "принимает любой пароль" -- похоже на доменную авторизацию
stil
Кстати, раз к слову пришлось - изза чего вообще пришлось делать еще один standby. Хотим перевезти оракловую ферму с
Win2003 32 на win2008 64.. Для этого хочу попробовать сделать функционирующий standby на win2008 64. А потом переехать постепенно. Вообще можно так делать?
Теоретически, говорят, возможно (нота 414043.1)
Но я ставил на 64-бинтую ось (Linux) 32-битный Oracle для стендбая и боевого и 64-битный для дальнейшей работы.
На нескольких хостах. Как все 32-битные стендбаи устаканились, в час "X" все останавливаем, переключаем все на 64 и выполняем миграцию (по ноте 341880.1 -- там дополнительные приседания для жабы). Простой был около 20 мин (на перекомпиляцию тоже никого не пущал).
Собственно, столько же было бы, если бы стендбай был поднят на 64-битном, а боевой на 32-битном.
Почему так не стал делать, не помню. Скорее всего, так казалось меньше возможных багов и ошибок
stil
Пока граблей, кроме вышеобсуждаемой ошибки коннекта не встретил.. Разве что кроме того, что софт отказался работать без oci.dll, которая есть только в клиенте 32х битном
Это что-то новенькое
Просто в 64-битном клиенте 64-битный oci.dll, в 32-битном -- соответственно, 32-битный
Похоже, что просто софт у тебя 32-битный, вот и просил соответсвующую библиотеку
8 сен 16, 08:19    [19640301]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить