Oracle DataGuard не работает должным образом, потому что FAL[клиент]
У меня было две базы данных, первичная и вторичная, и настроенный пакет данных между ними, я перезапустил suse linux, но при запуске баз данных репликация не выполняется, я думаю, что выбрал неправильный способ запуска резервной базы данных.... нет, он просто смонтирован, у меня есть пробел, который невозможно обнаружить в резервной таблице пробелов, и проблема "не указан FAL сервер" в резервной базе данных, что может быть не так?
From Primary:
System parameters with non-default values:
processes = 1200
nls_date_format = "MM/DD/YYYY HH24:MI:SS"
memory_target = 8000M
memory_max_target = 8G
control_files = "/oracle/app/oradata/ora11g/control01.ctl"
control_files = "/oracle/app/oradata/ora11g/control02.ctl"
control_files = "/oracle/app/oradata/ora11g/control03.ctl"
db_block_size = 8192
compatible = "11.1.0.0.0"
log_archive_start = TRUE
log_archive_dest_1 = "LOCATION=/home/oracle/archive"
log_archive_format = "%t_%s_%r.dbf"
db_recovery_file_dest = "/oracle/app/flash_recovery_area"
db_recovery_file_dest_size= 2G
undo_tablespace = "UNDOTBS1"
sec_case_sensitive_logon = FALSE
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
dispatchers = "(PROTOCOL=TCP) (SERVICE=ora11gXDB)"
local_listener = ""
remote_listener = ""
session_cached_cursors = 450
cursor_sharing = "FORCE"
audit_file_dest = "/oracle/app/admin/ora11g/adump"
audit_trail = "NONE"
db_name = "ora11g"
open_cursors = 300
diagnostic_dest = "/oracle/app"
Из журнала оповещений в резервной базе данных:
Thu Feb 13 17:16:02 2014
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =145
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 11.1.0.7.0.
Using parameter settings in server-side spfile
/oracle/app/product/11g/db/dbs/spfileora11g.ora
System parameters with non-default values:
processes = 1200
nls_date_format = "MM/DD/YYYY HH24:MI:SS"
memory_target = 8000M
memory_max_target = 8G
control_files = "/oracle/app/oradata/ora11g/control01.ctl"
control_files = "/oracle/app/oradata/ora11g/control02.ctl"
control_files = "/oracle/app/oradata/ora11g/control03.ctl"
db_block_size = 8192
compatible = "11.1.0.0.0"
log_archive_start = TRUE
log_archive_dest_1 = "LOCATION=/home/oracle/archive"
log_archive_format = "%t_%s_%r.dbf"
db_recovery_file_dest = "/oracle/app/flash_recovery_area"
db_recovery_file_dest_size= 2G
undo_tablespace = "UNDOTBS1"
sec_case_sensitive_logon = FALSE
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
dispatchers = "(PROTOCOL=TCP) (SERVICE=ora11gXDB)"
local_listener = ""
remote_listener = ""
session_cached_cursors = 450
cursor_sharing = "FORCE"
audit_file_dest = "/oracle/app/admin/ora11g/adump"
audit_trail = "NONE"
db_name = "ora11g"
open_cursors = 300
diagnostic_dest = "/oracle/app"
Deprecated system parameters with specified values:
log_archive_start
End of deprecated system parameter listing
Thu Feb 13 17:16:04 2014
.
.
.
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES) (PROTOCOL=TCP))'...
Thu Feb 13 17:16:04 2014
MMNL started with pid=15, OS id=10039
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /oracle/app
Thu Feb 13 17:16:04 2014
ALTER DATABASE MOUNT
Setting recovery target incarnation to 2
ARCH: STARTING ARCH PROCESSES
Thu Feb 13 17:16:09 2014
ARC0 started with pid=19, OS id=10272
Thu Feb 13 17:16:09 2014
ARC1 started with pid=20, OS id=10274
Thu Feb 13 17:16:09 2014
ARC2 started with pid=21, OS id=10276
ARC0: Archival started
ARC1: Archival started
ARC2: Archival started
Thu Feb 13 17:16:09 2014
ARC3 started with pid=22, OS id=10278
ARC3: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
ARC0: Thread not mounted
ARC1: Becoming the heartbeat ARCH
ARC2: Thread not mounted
ARC1: Thread not mounted
ARC3: Thread not mounted
Successful mount of redo thread 1, with mount id 4235628820
Physical Standby Database mounted.
Lost write protection disabled
Completed: ALTER DATABASE MOUNT
FAL[client]: Error fetching gap sequence, no FAL server specified
первичный
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
--------------
1606
SQL> SELECT name FROM v$archived_log WHERE thread# = 1 AND dest_id = 1 AND sequence# BETWEEN 1591 and 1606;
/home/oracle/archive/1_1606_792822090.dbf
16 rows selected.
SQL> SELECT GROUP#, BYTES FROM V$LOG;
GROUP# BYTES
---------- ----------
1 52428800
2 52428800
3 52428800
второстепенный
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
--------------
1591
SQL>select process, thread#, sequence#, status from v$managed_standby where process='MRP0';
no rows selected
SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;
no rows selected
1 ответ
Вам необходимо установить параметры в файле инициализации или spfile(sqlplus)
В первичной базе данных:
FAL_SERVER='standby_database'
FAL_CLIENT='primary_database'
В резервной базе данных:
FAL_SERVER='primary_database'
FAL_CLIENT='standby_database'
Эти два параметра необходимы для выборки архивных файлов журнала (FAL означает Fetch ArchiveLog).
Надеюсь, что я помогу тебе.
Добрый
Этому вопросу 5 лет, но я думаю, что на него еще нет полного ответа.
Во-первых, как Oracle устраняет пробел:
Процесс MRP запускает запрос на GAP. Этот процесс включается следующим образом: Без резервных журналов повтора: изменить базу данных восстановить отключение управляемой резервной базы данных; С резервным повтором: изменить базу данных, восстановить управляемую резервную базу данных с использованием отключения текущего файла журнала;
Если у вас есть только одна резервная база данных для вашей основной базы данных, тогда параметры fal_server и fal_client настраивать не нужно.
Если fal_server отсутствует, oracle получит эту информацию из log_archive_dest_n.
Это означает, что log_archive_dest_2 необходимо настроить также в резервной базе данных.
Итак, как решить проблему с разрешением GAP:
- Убедитесь, что log_archive_dest_n настроен как в основном, так и в резервном
- Убедитесь, что в "служебном" значении log_archive_dest_n нет опечаток.
- Убедитесь, что значение службы ссылается на допустимую запись tns в tnsnames.ora
- Убедитесь, что на всех узлах основного и резервного кластера используется один и тот же файл паролей.
- Убедитесь, что вы можете подключиться к sqlplus "sys/syspassword@primary as sysdba" и sqlplus "sys/syspassword@standby as sysdba" как из основного, так и из резервного. Элемент списка
Процесс MRP время от времени отправляет запросы разрешения GAP. Если вы хотите получить его немедленно, чтобы убедиться, что он работает: SQL> изменить базу данных восстановить управляемую резервную базу данных отменить; SQL> изменить базу данных, восстановить управляемую резервную базу данных с использованием текущего файла журнала; (используйте резервные журналы повторов, в режиме ожидания журналы применяются быстрее)
Параметры fal_server и fal_client действительно существуют, если вы хотите настроить каскадную настройку режима ожидания.
Первичная БД A отправляет архивные журналы в резервный B Если резервный B становится основным, отправляйте архивные журналы в резервный C.
Поведение FAL в версии 11.2 (идентификатор документа 1394472.1)
Начиная с 11.2 нет необходимости упоминать, что первичный FAL_CLIENT будет брать его из службы log_archive_dest_n (удаленный резервный пункт назначения, откуда он получил запрос FAL).
Параметры FAL_SERVER и FAL_CLIENT для каскадного режима ожидания (идентификатор документа 358767.1)