Oracle mechanics

07.03.2014

Проблема использования standby db в качестве FAL-сервера в 11.2

Filed under: Active Data Guard,Диагностика системы (instance),Oracle — Игорь Усольцев @ 18:26
Tags:

Конфигурация

-------------- Log_Archive_Dest_1->       ----------------
|            |----------------------------|              |
| Primary db |              <- FAL_Server | Standby_1 db |
|            |\                          /|              |
-------------- \                        / ----------------
                \                      /
                 \                    /
                  \ <- FAL_Server -> /
Log_Arch_Dest_2-> --------------------
                  |                  |
                  |   Standby_2 db   |
                  |                  |
                  --------------------

— серверы primary и standby_1 работают в рамках стандартных switchover/failover, сервер бд standby_2 используется только для резервного копирования бд

Проблема

На standby_1 наблюдалось постоянно растущее кол-во клиентских соединений с сервера standby_2 в состоянии долгого SQL*Net message from client:

standby_1@ SQL> @inst

INSTANCE_NAME  HOST_NAME  VERSION    PLATFORM_NAME        DATABASE_STATUS DATABASE_ROLE    STATUS OPEN_MODE
-------------- ---------- ---------- -------------------- --------------- ---------------- ------ ----------
testinst        standby_1 11.2.0.3.0 Linux x86 64-bit     ACTIVE          PHYSICAL STANDBY OPEN   READ ONLY
                                                                                                  WITH APPLY

standby_1@ SQL> select count(*) from v$session s, v$process p where s.paddr = p.addr and s.program like '%standby_2%';

  COUNT(*)
----------
       443

В соответствии с конфигурацией это были FAL-client процессы, пришедшие на standby_1 со standby_2 для получения логов, однако из alert.log на standby_1 следовало, что периодически эти процессы сами архивировали логи на сервер standby_1*:

Control  0  08-NOV-2013 15:09:57  RFS[944]: Begin archive primary thread 1 sequence 57745
Informational  0  08-NOV-2013 15:09:57  RFS[944]: Assigned to RFS process 27770           -- **
Control  0  08-NOV-2013 15:10:27  RFS[944]: Completed archive log 0 thread 1 sequence 57745
Informational  0  08-NOV-2013 15:10:27  Committing creation of archivelog '.../thread_1_seq_57745.2282.830963397'
Informational  0  08-NOV-2013 15:10:27  Media Recovery Log .../thread_1_seq_57745.2282.830963397

v$archived_log в этом случае указывал на неизвестное происхождение таких логов:

standby_1@ SQL> select dest_id from v$archived_log where sequence# = 57745
  2  /

   DEST_ID
----------
         0 -- "0 if the destination identifier is not available"

**) процесс 27770 — это RFS process на standby_1, или FAL-клиент, реализуемый ARC процессом сервера standby_2:

standby_1@ SQL> select * from v$session join v$process on paddr = addr where spid = 27770
  2  /

SID SERIAL# USER# USERNAME MACHINE    PORT PROGRAM                      TYPE EVENT                       SECONDS_IN_WAIT STATE    PID SPID
--- ------- ----- -------- --------- ----- ---------------------------- ---- --------------------------- --------------- ------- ---- -----
994     889     1 PUBLIC   standby_2 20878 oracle@standby_2 (TNS V1-V3) USER SQL*Net message from client            1294 WAITING  183 27770

и кол-во таких процессов планомерно росло:

[root@standby_1 ]# lsof|grep "IPv6"|grep "standby_2"|grep "ESTABLISHED"|wc -l
560

, периодически создавая определённые проблемы для READ ONLY пользователей standby_1 в виде ORA-00020: maximum number of processes exceeded

В то же время на сервере standby_2 такие соединения мирно «висели» в статусах ESTABLISHED или CLOSE_WAIT:

-- для вышеуказанного процесса
[root@standby_2 ~]# lsof -i :20878
COMMAND   PID   USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
oracle  28187 oracle  131u  IPv4 525456828      0t0  TCP standby_2:20878->standby_1:ncube-lm (ESTABLISHED)

[root@standby_2 ~]# ps -ef | grep 28187
oracle   28187     1  1 Nov07 ?        00:21:03 ora_arc3_testinst

-- общая картина
[root@standby_2 ]# lsof|grep "standby_1"|grep "ESTABLISHED"|wc -l
13
[root@standby_2 ]# lsof|grep "standby_1"|grep "CLOSE_WAIT"|wc -l
568

Поскольку в соответствии с конфигурацией большая часть логов штатно доставлялась на standby_1 напрямую с primary, FAL клиентам с standby_2 удавалось архивировать на standby_1 далеко не все логи :)

[oracle@standby_2 trace]$ tail testinst_arc3_1389.trc
*** 2013-10-07 16:55:32.603
Resized overflow buffer to 15183K (for 15183K LWN)
Redo shipping client performing standby login
*** 2013-10-07 16:55:32.647 4645 krsu.c
Logged on to standby successfully
Client logon and security negotiation successful!

*** 2013-10-07 16:56:09.746
Error 16401 creating standby archive log file at host 'standby_1'
kcrrwkx: unknown error:16401

-- по причине
[oracle@standby_2 trace]$ oerr ora 16401
16401, 00000, "archive log rejected by Remote File Server (RFS)"
// *Cause:  An attempt was made to re-archive an existing archive log.

*) Конфигурация standby_2, естественно, не предполагала передачу логов на standby_1:

SQL> @inst

INSTANCE_NAME HOST_NAME VERSION    PLATFORM_NAME     DATABASE_STATUS DATABASE_ROLE    STATUS OPEN_MODE
------------- --------- ---------- ----------------- --------------- ---------------- ------ ---------
testinst      standby_2 11.2.0.3.0 Linux x86 64-bit  ACTIVE          PHYSICAL STANDBY MOUNTE MOUNTED

SQL> @param arch

NAME               VALUE
------------------ -----------------------------------------
archive_lag_target 0
log_archive_config
log_archive_dest
log_archive_dest_1 location=/local/backup/testinst/arclogs

Неочевидное работающее решение

, подсказанное Олегом Юхно, — прописать на standby_2:

LOG_ARCHIVE_DEST_2="SERVICE=standby_1 ARCH async VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE)"

— , таким образом принудительно ограничив/запретив архивацию логов FAL-клиентами в проблемном направлении!

3 комментария »

  1. А почему логи пересылались с 2 на 1?

    комментарий от Аноним — 07.03.2014 @ 19:53 | Ответить

  2. Удалось понять, почему именно пересылались логи?

    комментарий от Georgi Fofanov — 07.03.2014 @ 19:55 | Ответить

    • по моему мнению, наступили на некий баг
      к сожалению, воспользоваться поддержкой не удалось — специалисты Oracle указали на нестрогое соблюдение конфигурации нашего ADG, например, db_unique_name использовался не уникальный — однако, на других серверах это не приводило к описанным проблемам

      комментарий от Игорь Усольцев — 07.03.2014 @ 23:17 | Ответить


RSS feed for comments on this post. TrackBack URI

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Создайте бесплатный сайт или блог на WordPress.com.

%d такие блоггеры, как: