|
|
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
Есть связка primary - physical standby. Версия 12.2.0.1.0 standby открыта в режиме read only with apply все логи уходят на standby, но применяются не сразу, а только если на primary выполнить Код: plsql 1. например, на primary выполняю Код: plsql 1. 2. в archive log list на primary (остается также как было до insert'a): Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 13 Next log sequence to archive 15 Current log sequence 15 в standby новая запись не появляется если после этого в primary выполнить Код: plsql 1. , то все sequence увеличиваются и новая запись появляется на standby: Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 14 Next log sequence to archive 16 Current log sequence 16 Подскажите, почему так происходит и как сделать, чтобы изменения сразу появлялись на standby ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2018, 19:00 |
|
||
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
1) разберитесь как работает standby 2) Прочитайте информацию о разнице между real time apply redo apply ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2018, 19:07 |
|
||
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2018, 19:12 |
|
||
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
Vadim Lejnin, standby в режиме REAL TIME APPLY В момент фиксации commit, этот блок пишется в redo, и commit complete сессия получает только в момент, когда вектор измененния данных запишется на диск в файл redo. это не значит, что после commit'a новая запись должна появиться на STANDBY ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2018, 19:43 |
|
||
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
нет, не значит а значит, что будет применён файл с REDO записями на стенбай сервере, который будет отправлен на standby после переключения журнального файла => если сгорит основной сервер, то на стендбае потеря информации (отставание) будет составлять - один активный лог - CURRENT (в общем случае). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2018, 23:46 |
|
||
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
mikhail.aksenovнет, не значит а значит, что будет применён файл с REDO записями на стенбай сервере, который будет отправлен на standby после переключения журнального файла => если сгорит основной сервер, то на стендбае потеря информации (отставание) будет составлять - один активный лог - CURRENT (в общем случае). Мессир, не надо путать других, если не уверены что знаете прочитайте что такое real time apply ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2018, 00:09 |
|
||
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
quest_askerVadim Lejnin, standby в режиме REAL TIME APPLY В момент фиксации commit, этот блок пишется в redo, и commit complete сессия получает только в момент, когда вектор измененния данных запишется на диск в файл redo. это не значит, что после commit'a новая запись должна появиться на STANDBY ? Смотря что Вы понимаете > после commit'a новая запись должна появиться на STANDBY 1) Асинхронный накат (maximum perfomance) не гарантирует что после commit вектор окажется на standby то есть возможна потеря транзакций, если они не успели передаться на standby при аварии мастера 2) даже если у вас максимальная защита, то коммит завершится, когда вектор попадет в standby redo log, а не когда накат этого вектора произойдет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2018, 00:22 |
|
||
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
Vadim LejninСмотря что Вы понимаете > после commit'a новая запись должна появиться на STANDBY 1) Асинхронный накат (maximum perfomance) не гарантирует что после commit вектор окажется на standby то есть возможна потеря транзакций, если они не успели передаться на standby при аварии мастера 2) даже если у вас максимальная защита, то коммит завершится, когда вектор попадет в standby redo log, а не когда накат этого вектора произойдет. я имею в виду, что в режиме real-time apply после выполнения на primary insert'a записи: Код: sql 1. 2. я ожидаю увидеть эту запись на standby (при штатной работе, без сбоев в сети или чего-то подобного), но почему-то я не вижу её на standby пока не выполню switch logfile (что в моем понимании соответствует redo apply). Документацию читал, но безуспешно, physical standby настраивал не я, может в настройках что-то не так, но опять же по всяким статьям типа "HOW TO CHECK REAL TIME APPLY IS ENABLED" всё в порядке. Код: sql 1. На primary: PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE SWITCHOVER_STATUS OPEN_MODE GUARD_S -------------------- -------------------- ---------------- -------------------- -------------------- ------- MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PRIMARY TO STANDBY READ WRITE NONE На standby: PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE SWITCHOVER_STATUS OPEN_MODE GUARD_S -------------------- -------------------- ---------------- -------------------- -------------------- ------- MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PHYSICAL STANDBY NOT ALLOWED READ ONLY WITH APPLY NONE Код: sql 1. на standby: DEST_ID DEST_NAME STATUS TYPE SRL RECOVERY_MODE ---------- ------------------------------ --------- ---------------- --- ----------------------- 1 LOG_ARCHIVE_DEST_1 VALID LOCAL NO MANAGED REAL TIME APPLY Должны ли внесенные в таблицу изменения на primary сразу появляться на standby в режиме real-time apply или я это в корне не верно понимаю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2018, 00:50 |
|
||
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
На стендбае проверь SRL (v$standby_log), в частности, что их размер равен (в новых версиях не меньше) размера опреративных журналов (v$log) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2018, 06:42 |
|
||
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
автор4. Differents in the Log Apply Services when using Standby Redo Logs -------------------------------------------------------------------- In case you do not have Standby Redo Logs, an Archived Redo Log is created by the RFS process and when it has completed, this Archived Redo Log is appliedto the Standby Database by the MRP (Managed Recovery Process) or the Logical Apply in Oracle 10g when using Logical Standby. An open (not fully written) ArchiveLog file cannot be applied on the Standby Database and will not be used in a Failover situation. This causes a certain data loss. If you have Standby Redo Logs, the RFS process will write into the Standby Redo Log as mentioned above and when a log switch occurs, the Archiver Process of the Standby Database will archive this Standby Redo Log to an Archived Redo Log, while the MRP process applies the information to the Standby Database. In a Failover situation, you will also have access to the information already written in the Standby Redo Logs, so the information will not be lost. Starting with Oracle 10g you have also the Option to use Real-Time Apply with Physical and Logical Standby Apply. When using Real-Time Apply we directly apply Redo Data from Standby RedoLogs. Real-Time Apply is also not able to apply Redo from partial filled ArchiveLogs if there are no Standby RedoLogs. So Standby RedoLogs are mandatory for Real-Time Apply. NOTE : In 12c DEFAULT MRP will go to REAL TIME APPLY mode. Default Standby recovery in REAL time apply. SQL>alter database recover managed standby database disconnect; To Start MRP in non real time apply mode use,(in 12c) SQL>alter database recover managed standby database using archived logfile disconnect; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2018, 01:30 |
|
||
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
quest_asker... Подскажите, почему так происходит и как сделать, чтобы изменения сразу появлялись на standbyкакой lag? что показывает show configuration покажи, что у тебя real time apply, из чего это следует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2018, 11:41 |
|
||
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
Vivat!Sanавтор4. Differents in the Log Apply Services when using Standby Redo Logs -------------------------------------------------------------------- In case you do not have Standby Redo Logs, an Archived Redo Log is created by the RFS process and when it has completed, this Archived Redo Log is appliedto the Standby Database by the MRP (Managed Recovery Process) or the Logical Apply in Oracle 10g when using Logical Standby. An open (not fully written) ArchiveLog file cannot be applied on the Standby Database and will not be used in a Failover situation. This causes a certain data loss. If you have Standby Redo Logs, the RFS process will write into the Standby Redo Log as mentioned above and when a log switch occurs, the Archiver Process of the Standby Database will archive this Standby Redo Log to an Archived Redo Log, while the MRP process applies the information to the Standby Database. In a Failover situation, you will also have access to the information already written in the Standby Redo Logs, so the information will not be lost. Starting with Oracle 10g you have also the Option to use Real-Time Apply with Physical and Logical Standby Apply. When using Real-Time Apply we directly apply Redo Data from Standby RedoLogs. Real-Time Apply is also not able to apply Redo from partial filled ArchiveLogs if there are no Standby RedoLogs. So Standby RedoLogs are mandatory for Real-Time Apply. NOTE : In 12c DEFAULT MRP will go to REAL TIME APPLY mode. Default Standby recovery in REAL time apply. SQL>alter database recover managed standby database disconnect; To Start MRP in non real time apply mode use,(in 12c) SQL>alter database recover managed standby database using archived logfile disconnect;Спасибо, интересно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2018, 13:52 |
|
||
|
Почему на physical standby изменения применяются только после switch logfile
|
|||
|---|---|---|---|
|
#18+
stdioquest_asker... Подскажите, почему так происходит и как сделать, чтобы изменения сразу появлялись на standbyкакой lag? что показывает show configuration покажи, что у тебя real time apply, из чего это следует.Может DG Broker не настроен и не используется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2018, 13:55 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39723749&tid=1883277]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
162ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
| others: | 242ms |
| total: | 501ms |

| 0 / 0 |
