Рациональное использование резервной базы данных DB2 HADR

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

Функциональность DB2® High Availability Disaster Recovery (HADR) представляет собой простой в использовании механизм репликации данных IBM® DB2 для Linux®, UNIX® и Windows®, обеспечивающий высокую готовность (high availability – HA) данных при частичном или полном выходе из строя одной из площадок. Начиная с пакета исправлений DB2 V9.7 Fix Pack 1 к резервной базе данных разрешен доступ по чтению из пользовательских приложений. В данной статье рассказывается, как использовать эту функциональность в приложениях и каковы ее ограничения. Кроме того, в статье даются рекомендации по использованию возможностей резервной базы данных.

Самир Катти, специалист по тестированию ПО, IBM

Самир Катти (Samir Katti) – фотографияСамир Катти (Samir Katti) последние 3,5 года работает инженером по функциональному тестированию реляционных баз данных DB2. Является активным участником группы тестирования функциональности доступа по чтению в HADR. Получил степень магистра по вычислительной технике в университете штата Орегон.



Цзин Сюй, разработчик программного обеспечения, IBM

Цзин Сюй (Jing Xu) – фотографияЦзин Сюй (Jing Xu) последние 4 года является разработчиком программного обеспечения и занимается созданием и тестированием DB2 для Linux, UNIX и Windows в IBM China Lab. Принимал участие в тестировании функциональности доступа по чтению в HADR; в настоящее время занимается разработкой HADR.



08.10.2012

Введение и предварительные сведения

Функциональность High Availability Disaster Recovery (HADR) СУБД DB2 для Linux, UNIX и Windows представляет собой механизм репликации базы данных, обеспечивающий высокую готовность данных при частичном или полном выходе из строя одной из площадок. HADR предотвращает потерю данных путем репликации их изменений из исходной базы данных, называемой основной (primary), в целевую базу данных, называемую резервной (standby).

Функциональность HADR была реализована в DB2 V8.2. До появления пакета исправлений DB2 V9.7 Fix Pack 1 резервный сервер выполнял только повтор завершенных транзакций по log-файлам, полученным с основного сервера, и был недоступен для пользователей. Подключение пользователей к резервной базе данных было запрещено.

Начиная с пакета исправлений DB2 V9.7 Fix Pack 1 функциональность доступа по чтению (HADR RoS) разрешает пользовательским приложениям выполнять операции чтения резервной базы данных. Это возможно только после включения функциональности доступа по чтению. Используя эту функциональность, приложения могут обращаться к основной базе данных HADR по чтению и записи, а к резервной базе данных только по чтению. Это позволяет перенести рабочую нагрузку, связанную с операциями чтения, с основной базы данных на резервную. Приложения, подключающиеся к резервной базе данных, не влияют на доступность резервного сервера при аварийном переключении на резерв.

В данной статье объясняется, как настроить операции чтения на резервной базе данных, а также обсуждаются ограничения этой функциональности. Также даются рекомендации по использованию возможностей резервной базы данных. Предполагается, что читатели знакомы с основами настройки пары баз данных HADR.

Настройка операций чтения на резервной базе данных

Функциональность доступа по чтению к резервной базе данных позволяет пользовательским приложениям использовать резервную базу данных из пары HADR для выполнения операций чтения. Резервную базу данных можно перевести в режим по чтению, установив значение переменной реестра DB2_HADR_ROS. Для включения данной функциональности переменная реестра устанавливается в значение ON. Эта настройка не является динамической. Иначе говоря, для активизации изменений переменной реестра необходимо перезапустить резервный сервер. В ситуациях, когда резервная база данных становится основной после операции передачи ей управления, указанная переменная реестра никак не влияет на новую основную базу данных. Функциональность чтения поддерживается для следующих режимов синхронизации HADR: ASYNC, NEARSYNC, SYNC и SUPERASYNC. Функциональность чтения не поддерживается, если резервная база данных находится в режиме локального наверстывания (local catch-up).

Для настройки DB2_HADR_ROS выполните следующие действия:

  1. После настройки пары HADR убедитесь, что переменная DB2_HADR_ROS установлена.
    db2 => !db2set
  2. При подключении к резервной базе данных должна отобразиться информация SQL1776 rc=1, как показано в листинге 1.
    Листинг 1. Подключение к резервной базе данных
    db2 => connect to hadrdb
    SQL1776N  The command is not supported on an HADR standby database or on an
    HADR standby database with the current configuration or state.  Reason code =
    "1".
  3. Установите переменную DB2_HADR_ROS так, как показано в листинге 2.
    Листинг 2. Установка переменной
    db2 => !db2set DB2_HADR_ROS=ON
    db2 => !db2set
    DB2_HADR_ROS=ON
  4. Перезагрузите сервер для активизации переменной реестра, как показано в листинге 3.
    Листинг 3. Перезагрузка сервера
     db2 => deactivate db hadrdb
    DB20000I  The DEACTIVATE DATABASE command completed successfully.
    db2 => !db2stop
    SQL1064N  DB2STOP processing was successful.
    db2 => !db2start
    SQL1063N  DB2START processing was successful.
  5. Активизируйте и подключитесь к резервной базе данных, как показано в листинге 4.
    Листинг 4. Активизация и подключение
    db2 => activate db hadrdb
    DB20000I  The ACTIVATE DATABASE command completed successfully.
    db2 => connect to hadrdb
    
       Database Connection Information
    
     Database server        = DB2/LINUXX8664 9.7.5
     SQL authorization ID   = KATTI
     Local database alias   = HADRDB

Тестирование настройки HADR с использованием RoS

Обычно пользователи хотят убедиться в правильности работы HADR и отсутствии потерь данных после настройки пары HADR. До DB2 V9.7 FP1 нужно было использовать операцию TAKEOVER, чтобы сделать резервный сервер основным и проверить правильность настройки HADR. Подключиться к резервному серверу было невозможно, так как он был недоступен для пользователей. Таким образом, проверить данные на резервном сервере было трудно. Единственным способом перевода резервного сервера в интерактивный режим была операция TAKEOVER.

До появления функциональности RoS для тестирования HADR необходимо было выполнить следующие действия:

  1. Изменить данные на основном сервере, например, создать таблицу и вставить в нее какие-либо значения, как показано в листинге 5.
    Листинг 5. Изменения на основном сервере
    [1049] [xjcd@db2eng63] /home/xjcd
    => db2 connect to hadrdb
    
       Database Connection Information
    
     Database server        = DB2/LINUXX8664 9.7.5
     SQL authorization ID   = XJCD
     Local database alias   = HADRDB
    
    [1050] [xjcd@db2eng63] /home/xjcd
    => db2 "create table t1(c1 int)"
    DB20000I  The SQL command completed successfully.
    
    [1051] [xjcd@db2eng63] /home/xjcd
    => db2 "insert into t1 values(123)"
    DB20000I  The SQL command completed successfully.
    
    [1052] [xjcd@db2eng63] /home/xjcd
    => db2 connect reset
    DB20000I  The SQL command completed successfully.
  2. На резервном сервере выполнить команду TAKEOVER HADR и проверить наличие изменений на основном сервере, как показано в листинге 6.
    Листинг 6. Проверка наличия изменений на резервном сервере
    [898] [xjcd@db2eng64] /home/xjcd
    
    => db2 takeover hadr on db hadrdb 
    DB20000I  The TAKEOVER HADR ON DATABASE command completed successfully.
    
    [899] [xjcd@db2eng64] /home/xjcd
    
    => db2 connect to hadrdb
    
       Database Connection Information
    
     Database server        = DB2/LINUXX8664 9.7.5
     SQL authorization ID   = XJCD
     Local database alias   = HADRDB
    
    [900] [xjcd@db2eng64] /home/xjcd
    
    => db2 "select * from t1"
    
    C1         
    -----------
            123
    
      1 record(s) selected.

После появления в DB2 V97 FP1 функциональности чтения резервной базы данных тестирование настройки HADR значительно упростилось. Стали возможны прямые подключения к резервному серверу без выполнения операции takeover.

Для тестирования HADR с использованием RoS выполните следующие действия.

  1. На основном сервере выполните изменения в базе данных, как показано в листинге 7.
    Листинг 7. Выполнение изменений в основной базе данных
    [1049] [xjcd@db2eng63] /home/xjcd
    => db2 connect to hadrdb
    
       Database Connection Information
    
     Database server        = DB2/LINUXX8664 9.7.5
     SQL authorization ID   = XJCD
     Local database alias   = HADRDB
    
    [1050] [xjcd@db2eng63] /home/xjcd
    => db2 "create table t1(c1 int)"
    DB20000I  The SQL command completed successfully.
    
    [1051] [xjcd@db2eng63] /home/xjcd
    => db2 "insert into t1 values(123)"
    DB20000I  The SQL command completed successfully.
    
    [1052] [xjcd@db2eng63] /home/xjcd
    => db2 connect reset
    DB20000I  The SQL command completed successfully.
  2. После включения RoS подключитесь к резервному серверу и проверьте наличие изменений, выполненных в основной базе данных, как показано в листинге 8.
    Листинг 8. Проверка наличия изменений в резервной базе данных
    [910] [xjcd@db2eng64] /home/xjcd
    => db2 connect to hadrdb
    
       Database Connection Information
    
     Database server        = DB2/LINUXX8664 9.7.5
     SQL authorization ID   = XJCD
     Local database alias   = HADRDB
    
    [911] [xjcd@db2eng64] /home/xjcd
    
    => db2 "select * from t1"
    
    C1         
    -----------
            123
    
      1 record(s) selected.

Режим монопольного воспроизведения резервной базы данных

Когда активная резервная база данных HADR воспроизводит DDL-операции log-файлов или операции по обслуживанию базы данных, резервный сервер переводится в режим монопольного воспроизведения (replay-only window). Если резервная база данных находится в этом режиме, все существующие подключения к ней завершаются, а новые подключения блокируются (SQL1776N Reason Code 4). Новые подключения к резервному серверу разрешаются только после завершения всех DDL-транзакций и операций по обслуживанию. При переходе в режиме монопольного воспроизведения существующие приложения отключаются и им возвращается ошибка (SQL1224N). Состояние режима монопольного воспроизведения можно узнать, выполнив команду db2pd -db db_name -hadr на резервной базе данных.

Выполните следующие действия:

  1. После настройки пары HADR и установки соединения с резервной базой данных выполните команду, приведенную в листинге 9, для получения информации о текущих активных приложениях.
    Листинг 9. Получение информации о текущих активных приложениях на резервной базе данных
    db2 => list applications
    Auth Id  Application    Appl.      Application Id            DB       # of
             Name           Handle                               Name     Agents
    -------- -------------- ---------- --------------            -------- -----
    KATTI    db2bp          13         *LOCAL.katti.120305194800 HADRDB   1
  2. Проверьте, активен или нет режим монопольного воспроизведения на резервной базе данных, как показано в листинге 10.
    Листинг 10. Проверка режима монопольного воспроизведения
    db2 => !db2pd -db hadrdb -hadr
    
    Database Partition 0 -- Database HADRDB -- Active Standby -- Up 0 days 00:05:37 – 
    Date 03/05/2012 11:50:58
    
    HADR Information:
    Role    State                SyncMode   HeartBeatsMissed   LogGapRunAvg (bytes)
    Standby Peer                 Sync     0                  3298
    
    ConnectStatus ConnectTime                           Timeout
    Connected     Mon Mar  5 11:45:26 2012 (1330976726) 120
    
    ReplayOnlyWindowStatus ReplayOnlyWindowStartTime             MaintenanceTxCount
    Inactive                       N/A                                   0
    
    LocalHost                                LocalService
    grebe                                    DB2_katti
    
    RemoteHost                               RemoteService      RemoteInstance
    petrel                                   xkatti             katti
    
    PrimaryFile  PrimaryPg  PrimaryLSN
    S0000001.LOG 13         0x000000000235DFB6
    
    StandByFile  StandByPg  StandByLSN         StandByRcvBufUsed
    S0000001.LOG 13         0x000000000235DFB6 0%
  3. Выполните незавершенные транзакции, содержащие DDL, на резервной базе данных, как показано в листинге 11.
    Листинг 11. Выполнение незавершенных транзакций
    db2 => update command options using c off
    DB20000I  The UPDATE COMMAND OPTIONS command completed successfully.
    
    db2 => create table t1(c1 int, c2 int)
    DB20000I  The SQL command completed successfully.
  4. Проверьте, активен ли режим монопольного воспроизведения, как показано в листинге 12.
    Листинг 12. Проверка режима монопольного воспроизведения
    db2 => !db2pd -db hadrdb -hadr
    
    Database Partition 0 -- Database HADRDB -- Active Standby -- Up 0 days 00:10:26 
    -- Date 03/05/2012 11:55:47
             
    HADR Information:
    Role    State                SyncMode   HeartBeatsMissed   LogGapRunAvg (bytes)
    Standby Peer                 Sync       0                  1441
    
    ConnectStatus ConnectTime                           Timeout
    Connected     Mon Mar  5 11:45:26 2012 (1330976726) 120
    
    ReplayOnlyWindowStatus  ReplayOnlyWindowStartTime             MaintenanceTxCount
    Active                          Mon Mar  5 11:54:09 2012 (1330977249) 1
    
    LocalHost                                LocalService
    grebe                                    DB2_katti
    
    RemoteHost                               RemoteService      RemoteInstance
    
    petrel                                   xkatti             katti
    
    PrimaryFile  PrimaryPg  PrimaryLSN
    S0000001.LOG 15         0x000000000235FCFC
    
    StandByFile  StandByPg  StandByLSN         StandByRcvBufUsed
    S0000001.LOG 14         0x000000000235EE8A 0%
  5. Проверьте, отключились ли существующие приложения, как показано в листинге 13.
    Листинг 13. Существующие приложения
    db2 => list applications
    SQL1611W  No data was returned by Database System Monitor.
  6. Проверьте, блокируются ли новые подключения, как показано в листинге 14.
    Листинг 14. Новые подключения
     db2 => connect to hadrdb
    SQL1776N  The command is not supported on an HADR standby database or on an
    HADR standby database with the current configuration or state.  Reason code =
    "4".

Очевидно, что режим монопольного воспроизведения оказывает влияние на работу пользователей с резервной базой данных. Если на резервном сервере включена функциональность RoS, не забудьте выполнить следующие действия:

  • Запланируйте на основном сервере совместное выполнение за короткое время всех операций режима монопольного воспроизведения.
  • Разрешите на основном сервере автоматическое завершение транзакций, чтобы режим монопольного воспроизведения был как можно более коротким.
  • Отключите функциональность автоматического обслуживания на основном и резервном серверах, как показано в листинге 15.
    Листинг 15. Отключение функциональности автоматического обслуживания на основной и резервной базах данных
    => db2 UPDATE DATABASE CFG FOR hadrdb USING AUTO_MAINT OFF AUTO_RUNSTATS OFF 
           AUTO_REORG OFF 
    DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.

Полный список DDL-выражений и операций обслуживания содержится в DB2 Information Center, ссылка на который приведена в разделе Ресурсы.


Связывание пакетов с резервной базой данных

Обычно приложения, содержащие встроенные SQL-выражения, необходимо предварительно скомпилировать при помощи интерфейсов DB2 API в исходный файл на языке хост-системы, а затем связать с соответствующей базой данных. Для предварительной компиляции приложений со встроенными SQL-выражениями можно использовать команду PREP процессора db2 CLP. По умолчанию пакет будет создаваться автоматически во время предварительной компиляции. При желании в команде PREP можно указать параметр BINDFILE для генерирования файла связывания (.bnd), а после завершения предварительной компиляции можно применить программу BIND для создания в базе данных пакета для данного приложения с использованием файла связывания. При изменении структуры или статистики таблиц, к которым обращается данное приложение, необходимо явно или неявно выполнить его повторное связывание.

Для предварительной компиляции и связывания выполните следующие действия:

  1. Выполните команду PREP с параметром BINDFILE для генерирования файла связывания (sample.bnd), как показано в листинге 16.
    Листинг 16. Команда PREP с параметром BINDFILE
    => db2 prep sample.sqc bindfile
    
    LINE    MESSAGES FOR sample.sqc
    ------  --------------------------------------------------------------------
            SQL0060W  The "C" precompiler is in progress.
            SQL0091W  Precompilation or binding was ended with "0" 
                      errors and "0" warnings.
  2. С помощью утилиты BIND создайте пакет в базе данных, как показано в листинге 17.
    Листинг 17. Использование утилиты BIND
     => db2 bind sample.bnd
    
    LINE    MESSAGES FOR sample.bnd
    ------  --------------------------------------------------------------------
            SQL0061W  The binder is in progress.
            SQL0091N  Binding was ended with "0" errors and "0" warnings.

Обратите внимание, что предварительная компиляция и связывание требуют подключения к базе данных.

Как уже говорилось, операции записи в резервной базе данных HADR запрещены. Поэтому в резервной базе данных запрещены связывание и повторное связывание, поскольку они выполняют запись в базу данных. При попытке связать пакет с резервной базой данных возвращается ошибка SQL1773N reason code 5, как показано в листинге 18.

Листинг 18. Ошибки при связывании с резервной базой данных
=> db2 bind sample.bnd 

LINE    MESSAGES FOR sample.bnd
------  --------------------------------------------------------------------
        SQL0061W  The binder is in progress.
        SQL1773N  The statement or command requires functionality 
                  that is not supported on a read-enabled HADR standby 
                  database. Reason code = "5".
        SQL0082C  An error has occurred which has terminated 
                  processing.
        SQL0092N  No package was created because of previous errors.
        SQL0091N  Binding was ended with "3" errors and "0" warnings.

При необходимости выполнения связывания или повторного связывания пакета на резервной базе данных следует выполнить эти операции на основной базе данных. Операции связывания и повторного связывания будут переданы и воспроизведены на резервном сервере, поскольку они фиксируются в log-файле.

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


Уровень изоляции на резервном сервере

Читающие процессы на резервной базе данных могут работать только на уровне изоляции транзакций Uncommitted Reads (UR). Причиной такого ограничения является то, что функциональность DB2 HADR основана на передаче log-файлов. Как вам известно, транзакции на основном сервере записываются в log-файлы и передаются в резервную базу данных. Резервная база данных выполняет эти записи аналогично восстановлению базы данных с повтором завершенных транзакций, гарантируя согласованность данных с основной базой данных. Но блокировки, необходимые для более высоких, чем UR, уровней изоляции, не передаются в резервную базу данных, поэтому читающими процессами не будут запрашиваться какие-либо блокировки во время воспроизведения log-записей. Одним словом, данные в резервной базе данных не защищены какими-либо блокировками, поэтому приложения на резервном сервере могут выполнять чтение только на уровне изоляции UR.

Листинг 19. Ошибка при чтении на более высоком, чем UR, уровне изоляции
=> db2 "select * from t1 with RR"

C1         
-----------
SQL1773N  The statement or command requires functionality that is not 
supported on a read-enabled HADR standby database. Reason code = "1".

Если какие-либо приложения, выполняющие операции чтения, реализованы с более высокими, чем UR, уровнями изоляции, и вы не хотите, чтобы их работа была нарушена из-за ошибки уровня изоляции, можно принудительно перевести их в режим работы с уровнем изоляции UR, установив переменную реестра DB2_STANDBY_ISO, как показано в листинге 20.

Листинг 20. Ошибка при чтении на более высоком, чем UR, уровне изоляции
=> db2set DB2_STANDBY_ISO=UR
# We need to restart DB2 instance here so that this registry variable take effect
=> db2 connect to testdb

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.5
 SQL authorization ID   = XJCD
 Local database alias   = TESTDB

=> db2 "select * from t1 with RR"

C1         
-----------
          1
          2
          3

  3 record(s) selected.

Приложения, выполняющие операции чтения и требующие более высокого, чем UR, уровня изоляции, можно выполнять только на основной базе данных.


Статистика на резервной базе данных

Статистическая информация по объектам базы данных необходима для SQL-оптимизатора при подготовке планов доступа к данным. При отсутствии точной статистики оптимизатор может выбрать неэффективный план доступа, что отрицательно скажется на производительности запроса.

Для сбора статистической информации в DB2 используется утилита RUNSTATS. Она анализирует указанный объект (таблицы или индексы) и вычисляет статистические данные, которые записывает в таблицы системного каталога со схемой SYSSTAT. Поскольку операции записи в резервной базе данных HADR запрещены, программа RUNSTATS тоже недоступна на резервном сервере.

Если вы хотите обновить статистику на резервной базе данных для улучшения производительности запросов для приложений на резервной базе данных, существуют следующие альтернативы:

  • Выполнение RUNSTATS на основной базе данных. Да, самым естественным и простым методом является выполнение RUNSTATS на основной базе данных. Поскольку RUNSTATS записывает результаты в таблицы системного каталога, сгенерируются соответствующие log-записи, которые будут переданы и воспроизведены на резервном сервере. Следовательно, статистика на резервной базе данных будет обновлена.
  • Прямое обновление таблицы каталога статистики вручную. Очевидно, что выполнение RUNSTATS в предыдущем методе определенным образом скажется на производительности резервной базы данных. Некоторые поля в таблицах каталога статистики можно при необходимости обновлять вручную. Однако существует определенный риск обновления таблиц каталога, поэтому при выборе данного метода необходимо быть осторожным.
  • Использование профиля оптимизатора для указания оптимизатору плана доступа к данным. Однако существует вероятность, что некоторые условия на основной и резервной базах данных не идентичны, даже если это не рекомендуется. Например, если одна табличная область в основной базе данных имеет контейнер с большей производительностью, чем в резервной, статистика основной базы данных будет неприменима на резервной. В этом случае для одного и того же запроса необходимы разные планы доступа к данным в основной и резервной базах данных.

Для запросов можно указать рекомендации по оптимизации, либо встроенные, либо в профилях оптимизации. Обычно профили оптимизации (XML-файлы) вставляются в таблицу SYSTOOLS.OPT_PROFILE, а затем эти профили включаются перед запросами. Оптимизатор DB2 будет генерировать и выбирать план доступа к данным в соответствии с профилями оптимизации. Более подробная информация по использованию профилей оптимизации содержится в статье "Оптимизация запросов при помощи профилей оптимизации и статистических представлений в DB2 9", ссылка на которую приведена в разделе Ресурсы.

Поскольку операции записи в резервных базах данных заблокированы, вы не сможете вставить профили оптимизации в таблицу SYSTOOLS.OPT_PROFILE резервной базы данных. Обойти это ограничение можно путем вставки профилей в основную базу данных и передачи соответствующих log-записей в резервную базу данных. После воспроизведения log-записей профили оптимизации появятся в резервной базе данных и будут готовы для использования.


Обработка LOB-объектов на резервных серверах

До появления пакета исправлений V9.7 Fix Pack 5 чтение больших объектов (LOB), таких как BLOB, CLOB или DBCLOB, из резервных баз данных было невозможно. До DB2 V9.7 все LOB-объекты хранились в специальной табличной области отдельно от неLOB-столбцов. При попытке чтения LOB-объекта возвращалась ошибка SQL1773N, reason code 1, как показано в листинге 21.

Листинг 21. Невстроенные LOB-объекты в резервной базе данных блокируются
=> db2 "select C2 from T"  

C2
-----------------------
SQL1773N  The statement or command requires functionality that is not 
supported on a read-enabled HADR standby database. Reason code = "1".

В DB2 V9.7 реализованы встроенные (inline) LOB-объекты. Эти LOB-объекты хранятся в тех же табличных областях, что и неLOB-столбцы. В V9.7 Fix Pack 5 и последующих версиях в резервных базах данных поддерживаются встроенные LOB-объекты. Таким образом, небольшие LOB-объекты следует делать по возможности встроенными. Для проверки того, является ли LOB-столбец встроенным, можно использовать табличную функцию ADMIN_IS_INLINED, как показано в листинге 22.

Листинг 22. Проверка того, является ли LOB-столбец встроенным
=> db2 "select ADMIN_IS_INLINED(c1) from t2"

1     
------
     1

  1 record(s) selected.

Если результат запроса равен 1, данный столбец данной строки является встроенным, а если 0 – нет.


Заключение

Начиная с пакета исправлений DB2 V9.7 Fix Pack 1 DB2 предоставляет возможность доступа в режиме чтения к резервной базе данных в конфигурации HADR. С резервной базой данных могут работать приложения, выполняющие только операции чтения. Такая возможность помогает сбалансировать рабочую нагрузку на основной сервер. Механизмы передачи и воспроизведения log-записей накладывают определенные ограничения на приложения, выполняющие чтение данных с резервного сервера. В данной статье были рассмотрены эти ограничения и обсуждены вопросы эффективного выполнения приложений на резервной базе данных, такие как:

  • Настройка переменной реестра DB2_HADR_ROS=on для включения функциональности RoS.
  • Максимальное сокращение транзакций, содержащих DDL-выражения, на основном сервере для уменьшения влияния режима монопольного воспроизведения на производительность резервного сервера.
  • Связывание пакетов на основном сервере и выполнение соответствующих приложений на резервном сервере.
  • Использование уровня изоляции Uncommitted Read (UR) для приложений на резервном сервере.
  • Создание коротких, по возможности встроенных, LOB-объектов для обращения к ним на резервной базе данных.

Мы надеемся, что после прочтения данной статьи вы сможете эффективнее использовать функциональность RoS.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=839355
ArticleTitle=Рациональное использование резервной базы данных DB2 HADR
publish-date=10082012