При использовании HDB/RAIMA — RDB Parallel в системе аварийного восстановления (DRS) необходимо записать данные полевых систем в первичной серверной системе (PSS) и вторичной серверной системе (SSS) системы управления. В связи с тем, что большинству соединений между полевой системой и системой управления не хватает скорости передачи, пропускной способности и, может быть, даже доступности, используется альтернатива прямому подключению к обеим базам данных. Данные сохраняются только в одной базе данных (по умолчанию: PSS), и база данных пересылает полученные данные на вторую базу данных (SSS) (см. Рисунок 1). Для передачи данных между базой данных PSS и базой данных SSS используется функция «КАСКАД Цифра» Исторической синхронизации. Преимущество состоит в том, что полевая система должна отправлять данные только одной системе, что приводит к снижению трафика примерно на 50% между полевой системой и системой управления.
ВНИМАНИЕ
Каждая схема БД можете использовать либо историческую синхронизацию, либо избыточность 2×2. Обе функции одновременно не поддерживаются!
Рисунок 1: Историческая синхронизация RDB
Конфигурация
Для использования Oracle Streaming должны быть применены следующие конфигурации:
ПРИМЕЧАНИЕ
Все пути и файлы относятся к пути <путь_kaskad>\3.15\data\RDBSetup\ora\
- Должна быть настроена схема базы данных для БД PSS и БД SSS (см. Конфигурация схемы базы данных RDB)
- Настройте RDB_config.sql для Исторической синхронизации и скопируйте в папку /sync/ *
- Установите историческую синхронизацию для обеих схем баз данных
- Установите конфигурационный параметр Db=»host1,host2″ **
- Установите опцию пересылки для событий и алармов ArchiveGroups и (опционально) ***
- Создайте дополнительные RDBArchiveGroups ****
- Настройте параметры резервного копирования и счетчик Online-Tablespace ***
- Настройте RDBCompression (опционально)
ПРИМЕЧАНИЕ
* = Следующие изменения должны быть сделаны в файле RDB_config.sql:
| Whatpackage = fwd, whatinstall= 3, sync_intval_len = 3 connect_second = <Имя партнера БД> |
sync_intval_len = 3 означает, что каждые 3 минуты сохраненные значения из локальной базы данных отправляются в базу данных «connect_second».
connect_second представляет собой партнера избыточности для базы данных.
** = Для RDBManager требуется второе имя хоста для конфигурационного параметра Db = «host1,host2». В случае ошибки в базе данных PSS RDBManager подключается к базе данных 2 (SSS) хоста. Параметр должен быть установлен в разделе [ValueArchiveRDB].
*** = Настройки находятся в «КАСКАД Цифра» по адресу: System Management > Database > Database Configuration > Parametrize
**** = Настройки находятся в «КАСКАД Цифра» по адресу: System Management > Database > Database Configuration
ВНИМАНИЕ
Когда создается новая архивная группа, «путь к БД серверу» на втором dbhost для этой группы устанавливается в каталог по умолчанию. Он может быть изменен, если это необходимо.
ВНИМАНИЕ
При использовании Linux, переключение между двумя базами данных Oracle может занять довольно много времени. Для увеличения производительности следует изменить sysctl.conf. Файл расположен по адресу /etc/sysctl.conf . Значение для параметра net.ipv4.tcp_retries2 должно быть изменено на 2. После этого необходимо вызвать команду «sysctl -p».
Автоматический перенос
Следующие конфигурации автоматически переносятся из dbhost1 в dbhost2:
- создание архивных групп
- установка флажка переадресации (вкл/выкл)
- удаление архивных групп
- Сжатие RDB
- изменения в конфигурации архивных групп, за исключением изменений пути
- создание шаблонов архивных групп
Ручной перенос
Следующие конфигурации не переносятся автоматически и должны быть перенесены вручную:
- Резервное копирование / восстановление
Рисунок 2: Архивные группы RDB
ПРИМЕЧАНИЕ
С помощью выпадающего списка на панели архивных групп RDB можно изменить dbhost, чтобы установить конфигурации, которые не переносятся автоматически. Если открыта одна из панелей конфигурации RDB и выполняется исторический запрос, например, в AES, для запроса используется только фактически выбранный dbhost (с выпадающим списком). Это связано с тем, что пользовательский интерфейс может иметь только одно соединение с базой данных одновременно.
Аналогичный выпадающий список можно найти в панели конфигурации сжатия RDB.
Рисунок 3: Конфигурация архивной группы RDB
ПРИМЕЧАНИЕ
При использовании «Перенаправления», значения, которые хранятся внутри архивной группы, автоматически отправляются из dbhost1 в dbhost2
Несколько полевых систем
Если существуют несколько полевых систем и используется историческая синхронизация, рекомендуется сгруппировать их в одной схеме базы данных, и различать их используя различные архивные группы, например:
| FieldSystem1: DbScheme ‚FS’, Archivgroup ‚RegionA’ FieldSystem2: DbScheme ,FS’, Archivgroup ‚RegionB’ …. FieldSystem 10: DBScheme ‚FX’, Archivgroup ,RegionY’ FieldSystem 11: DBScheme ‚FX’, Archivgroup ,RegionZ’ |
Ограничение сжатия RDB
Если необходимо использовать сжатие RDB для одиночных полевых систем в одной схеме БД, следует учитывать следующие условия:
Интервалы сжатия устанавливаются не для системы, а для схемы БД. То есть, если деактивируется один интервал сжатия, затрагивается не только сама система, но и все системы в схеме БД.
Преимущества: Настройка интервалов сжатия для каждой системы не является необходимой, и количество необходимых работ с базой данных, таким образом, сводится к минимуму.
Поведение при потере соединения
В случае потери соединения (прерывание сети, нет доступа к БД, ..) RDBManager пытается записать значения в буферный блока 5 раз (другое значение может быть установлено с помощью _RDBArchive.dbConfig.writeMisses). Если повторные попытки окончатся неудачей, подключение к dbhost1 закрывается, и открывается подключение к dbhost2. Перед началом процесса записи для dbhost2, RDBManager ожидает в течение настроенного интервала синхронизации (= syncjob_intval в RDB_Config.sql, по умолчанию = 3 минуты), чтобы позволить завершить работающие в настоящее время процессы слияния.
В то время как RDBManager соединен с dbhost2, совершается попытка установить повторное соединение с dbhost1 каждые 20 секунд (можно настроить с помощью _RDBArchive.dbConfig.dbWriteDelayError).
ПРИМЕЧАНИЕ
С помощью внутренней точки данных _RDBArchive.dbConnection.usedHost можно прочитать, с каким хостом БД в данный момент соединен RDB-менеджер или пытается соединиться.
Если нет доступного dbhost, RDBManager буферизирует значения локально (используя BufferToDisk). Как только соединение с базой данных будет установлено, все буферизированные значения записываются в этой базе данных.
Если происходит потеря соединения между dbhost 1 и dbhost 2, данные синхронизируются (см. Историческая синхронизация) в момент восстановления соединения. Это предохраняет от потери данных.
Рисунок 4: Поведение при потере соединения
Доступ к чтению
По умолчанию доступ к чтению всегда отправляется на dbhost1. Если dbhost1 не доступен и queryRDBDirect активен (=1), открывается соединение с dbhost2. Если запрос выполняется с использованием dbhost2, данные могут отсутствовать из-за возможной неоконченной исторической синхронизации между PSS и SSS. Таким образом, доступны только данные до последней синхронизации.
Если параметр queryRDBdirect не активен (=0), доступ к данным осуществляется посредством RDBManager. При использовании RDBManager изменения между dbhost1 и dbhost2 выполняются только в случае неправильного доступа к записи, т. е. доступ к чтению не возвращает никакого значения в dbhost1 в случае сбоя соединения, если не было никаких изменений в dbhost2, из-за неправильного доступа к записи.
Для установления соединения с конкретным dbhost, например, для интерфейса пользователя, может использоваться Ctrl-функция setUseOnlyThisDbName. Эта настройка действует до тех пор, пока интерфейс не будет закрыт, или настройка не изменится еще раз, используя setUseOnlyThisDbName).
Обслуживание
Чтобы правильно закрыть соединение с базой данных Oracle для обслуживания, необходимо выполнить следующие действия:
- Установить внутреннюю точку данных _RDBArchive.dbConnection.closeDbConnection в значении TRUE (ИСТИНА), или, альтернативно, установить внутреннюю точку данных _RDBArchive.dbConnection.openDBConnection в значении FALSE (ЛОЖЬ) для закрытия соединения между менеджером RDB и базой данных.
- Выполнить работы по обслуживанию.
- Чтобы открыть соединение с базой данных между Oracle и RDBManager снова, установить внутреннюю точку данных _RDBArchive.dbConnection.closeDbConnection в значении FALSE (ЛОЖЬ), или, альтернативно, установить внутреннюю точку данных _RDBArchive.dbConnection.openDBConnection в значении TRUE (ИСТИНА).
Сжатие RDB
Конфигурация сжатия RDB выполняется на обеих системах (PSS и SSS). Применяются архивные группы и DBJobs. Данные для расчета будут задержаны из-за интервала синхронизации. Рекомендуется определить задержку для интервала сжатия.
Ручная историческая синхронизация
Панель «Historical Synchronization» (историческая синхронизация) может быть открыта на панели конфигурации RDB. Панель «Historical Synchronization» (историческая синхронизация) предоставляет обзор открытых или неудачных процессов синхронизации. Кроме того, может быть определен диапазон времени для синхронизации или запущена синхронизация вручную.
Рисунок 5: Ручная историческая синхронизация
Предупреждения
Обновление ЭТД
В отличие от создания элементов ТД, обновления ЭТД (= изменения псевдонима, комментарий и единица измерения) не буферизируются. Менеджер RDB посылает обновления на активный и подключенный dbhost, а потом на пассивный dbhost. Если пассивный узел (хост) недоступен, обновления будут потеряны. Чтобы применить обновления, изменения должны быть выполнены снова.
Обновление алармов
Следующая последовательность приводит к потере обновленных значений алармов:
- Аларм X записывается менеджером RDB в dbhost1
- Соединение между dbhost1 и dbhost2 пропадает до выполнения синхронизации (т.е. аларм Х известен только dbhost1)
- Соединение между менеджером RDB и dbhost1 пропадает, и менеджер RDB подключается к dbhost2.
- RDBManager отправляет обновление аларма X на dbhost2
Обновление для аларма X будет удалено, так как dbhost2 не знает об аларме. Если синхронизация осуществляется впоследствии, синхронизация отправляет аларм Х на dbhost2 со значением, известным dbhost1, что приводит к потере информации об обновлении, отправленной только на dbhost2. Обычно потеря данных ограничивается временным интервалом синхронизации (см. sync_intval_len at the RDB_config.sql file).