Руководство администратора: Реализация

Конфигурация автоматического перенаправления клиента |(DB2_MAX_CLIENT_CONNRETRIES и DB2_CONNRETRIES_INTERVAL)

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

|
• DB2_MAX_CLIENT_CONNRETRIES: Максимальное число попыток соединения для |функции автоматического перенаправления клиента.
|
• DB2_CONNRETRIES_INTERVAL: Интервал в секундах между последовательными |попытками соединения.

Если задать DB2_MAX_CLIENT_CONNRETRIES, но не задать |DB2_CONNRETRIES_INTERVAL, значение DB2_CONNRETRIES_INTERVAL по умолчанию равно 30.

Если не задать DB2_MAX_CLIENT_CONNRETRIES, но задать |DB2_CONNRETRIES_INTERVAL, значение DB2_MAX_CLIENT_CONNRETRIES по умолчанию равно 10.

Если DB2_MAX_CLIENT_CONNRETRIES и DB2_CONNRETRIES_INTERVAL не заданы, |функция автоматического перенаправления клиента по умолчанию работает, как описано выше.

Примечание:

Пользователи соединений типа 4 универсального драйвера JDBC DB2^(R) |должны конфигурировать автоматическое перенаправление клиента при помощи |следующих двух свойств источника данных:

|
• maxRetriesForClientReroute: Это свойство позволяет ограничить число |повторных попыток при неудаче первичного соединения с сервером. Свойство используется, только если задано свойство retryIntervalForClientReroute.
|
• retryIntervalForClientReroute: Это свойство задает время задержки (в секундах) перед повторной попыткой соединения. Свойство используется, только если задано свойство maxRetriesForClientReroute.

Пояснение относительно переменной реестра DB2TIMEOUT

Переменная реестра DB2TIMEOUT более не поддерживается. Этот параметр использовался для управления сроком ожидания при долгих запросах SQL для |клиентов Windows^(R) 3.x и клиентов Macintosh. По умолчанию эта возможность была выключена.

Каталоги, создаваемые при создании контейнера табличных пространств

При создании контейнеров табличных пространств DB2 UDB создает все уровни каталогов, если они еще не существуют.

Например, если задан контейнер /project/user_data/container1, а |каталог /project не существует, DB2 UDB создаст каталоги |/project и /project/user_data.

Начиная с DB2 UDB Версии 8.2 FixPak 4, все каталоги, создаваемые DB2 UDB, создаются с маской разрешений 700. Это значит, что только у владельца есть доступ на чтение, запись и выполнение.

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

|
1. Используя ту же структуру каталогов, что в предыдущем примере, предположим, |что уровни каталогов /project/user_data не существуют.
|
2. Пользователь user1 создает экземпляр, который по умолчанию называется |user1, затем создает базу данных, а затем - табличное пространство, |один из контейнеров которого - /project/user_data/container1.
|
3. Пользователь user2 создает экземпляр, который по умолчанию называется |user2, затем создает базу данных, а затем пытается создать табличное |пространство, один из контейнеров которого - /project/user_data/container2.

Поскольку при первом требовании DB2 UDB создала уровни каталогов |/project/user_data с маской разрешений 700, у пользователя user2 нет |доступа к этим уровням каталогов, и он не может создать в этих каталогах |container2. | В этом случае операция CREATE TABLESPACE завершается неудачно.

Есть два способа разрешить этот конфликт:

|
1. Создать каталог /project/user_data до создания табличных |пространств и задать разрешения, позволяющие создать табличные пространства и |пользователю user1, и пользователю user2. Если все уровни каталога табличного пространства существуют, DB2 UDB не изменяет доступа к ним.
|
2. Когда пользователь user1 создаст /project/user_data/container1, |задать для /project/user_data разрешения, позволяющие создать |табличное пространство пользователю user2.

Автоматическое хранение

Формат имен контейнеров изменен; при этом изменены также ID табличных пространств и ID контейнеров. Новый формат:

<путь хранения>/<экземпляр>/NODE####
/T#######
/C#######.<EXT>

где:

• /T####### - ID табличного пространства. Например: T0000003.
• /C####### ID контейнера. Например: C0000012.

Определение генерируемого столбца для существующей таблицы

Начиная с DB2^(R) Universal Database Версии 8.2.2 (эквивалентной Версии 8.1 FixPak 9), генерируемые столбцы можно использовать в индексах уникальности.

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

Групповые переменные реестра

Если задать DB2WORKLOAD=SAP, пользовательское табличное пространство SYSTOOLSPACE и пользовательское временное табличное пространство SYSTOOLSTEMPSPACE не будут создаваться автоматически. Эти табличные пространства используются для таблиц, автоматически создаваемых следующими мастерами, утилитами или функциями:

• Автоматическое обслуживание
• Советчик по структуре
• Информационная панель базы данных Центра управления
• Хранимая процедура SYSINSTALLOBJECTS (если не задан входной параметр табличного пространства)
• Хранимая процедура GET_DBSIZE_INFO

Без табличных пространств SYSTOOLSPACE и SYSTOOLSTEMPSPACE нельзя использовать эти мастера, утилиты или функции.

Чтобы можно было использовать эти мастера, утилиты или функции, выполните одно из следующих действий:

• Вручную создайте SYSTOOLSPACE (только на узле каталога, если используется DPF). Например:

     CREATE REGULAR TABLESPACE SYSTOOLSPACE 
        IN IBMCATGROUP 
        MANAGED BY SYSTEM 
        USING ('SYSTOOLSPACE')

• При вызове SYSINSTALLOBJECTS для создания объектов задавайте правильное табличное пространство для каждого из следующих имен инструментов: "DB2AC", "POLICY" и "STMG_DBSIZE_INFO"

Выполнив одно из этих действий, создайте пользовательское временное табличное пространство (также только на узле каталога, если используется DPF). Например:

   CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE 
      IN IBMCATGROUP 
      MANAGED BY SYSTEM 
      USING ('SYSTOOLSTMPSPACE')

Когда табличное пространство SYSTOOLSPACE и временное табличное пространство SYSTOOLSTEMPSPACE созданы, можно использовать указанные выше мастера, утилиты или функции.

Особенности аутентификации удаленных клиентов

Тип аутентификации DATA_ENCRYPT_CMP позволяет клиентам из предыдущих выпусков, не поддерживающим шифрование данных, соединяться с сервером, используя аутентификацию SERVER_ENCRYPT вместо DATA_ENCRYPT. Этот тип аутентификации не работает, если выполняются три следующих условия:

• Уровень клиента - Версия 7.2.
• Уровень шлюза - Версия 8 FixPak 7 или новее.
• Уровень сервера - Версия 8 FixPak 7 или новее.

В этом случае клиент не сможет соединяться с сервером. Чтобы он мог соединяться с сервером, нужно либо обновить клиент до Версии 8, либо использовать шлюз Версии 8 FixPak 6 или более ранней.

Поддержка прямого ввода-вывода (DIO) и параллельного ввода-вывода (CIO)

Прямой ввод-вывод (DIO) повышает производительность памяти, поскольку при нем не используется кэширование на уровне файловой системы. Это уменьшает затраты времени процессора и увеличивает объем памяти, доступной для экземпляра базы данных.

При параллельном вводе-выводе (CIO) используются преимущества DIO, а также упрощается преобразование в последовательную форму при операциях записи данных.

DB2 Universal Database (UDB) поддерживает DIO и CIO в AIX и поддерживает DIO в HP-UX, операционной среде Solaris, Linux и Windows.

Ключевые слова NO FILE SYSTEM CACHING и FILE SYSTEM CACHING в операторах SQL CREATE TABLESPACE и ALTER TABLESPACE позволяют задать, нужно ли использовать DIO или CIO для табличного пространства. Если задано ключевое слово NO FILE SYSTEM CACHING, DB2 UDB пытается, если это возможно, использовать CIO. В случаях, когда CIO не поддерживается (например, если используется JFS), вместо него используется DIO.

Дополнительную информацию смотрите в статье "Improve database performance on file system containers in IBM DB2 UDB Stinger using Concurrent I/O on AIX", которую можно найти по адресу:

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408lee/

Технология диспетчера связи и автоматическое перенаправление клиентов

Следующая информация входит в книгу Руководство администратора: Реализация Приложение B "Использование автоматического перенаправления клиентов":

Возможность автоматического перенаправление клиента DB2 Universal Database для Linux, UNIX, и Windows позволяет клиентским прикладным программам восстанавливать работоспособность после потери связи с сервером, автоматически восстанавливая соединение клиента с сервером, благодаря чему они могут продолжать работу после минимального перерыва.

При обрыве соединения клиента с сервером, приходящие от клиента требования повторного соединения направляются диспетчером связи (например, WebSphere EdgeServer) на заданный набор систем

Технологию диспетчера связи можно использовать в средах такого типа:

Клиент -> Диспетчер связи -> (сервер 1 DB2 Connect или сервер 2 DB2 Connect) -> DB2 z/OS

где:

• Имя хоста TCP/IP компонента диспетчера связи - DThostname
• Имя хоста TCP/IP сервера 1 DB2 Connect - GWYhostname1
• Имя хоста TCP/IP сервера 2 DB2 Connect - GWYhostname2
• Имя хоста TCP/IP сервера DB2 z/OS - zOShostname

Клиент вносится в каталог с использованием диспетчера связи DThostname, чтобы применить технологию диспетчера связи для доступа к одному из серверов DB2 Connect. Промежуточный диспетчер связи решает, какой сервер использовать - GWYhostname1 или GWYhostname2. Когда это решение принято, клиенту предоставляется прямое соединение с одним из этих двух шлюзов DB2 Connect. Когда установлено соединение гнезда с выбранным сервером DB2 Connect, получается обычное соединение клиента с сервером DB2 Connect и затем с DB2 z/OS.

Например, пусть диспетчер связи выбрал сервер GWYhostname2. Получается следующая среда связи:

Клиент -> Сервер 2 DB2 Connect -> DB2 z/OS

При сбоях связи диспетчер связи не восстанавливает соединение. Если вы хотите включить для базы данных функцию автоматического перенаправления клиентов в такой среде, нужно сконфигурировать в качестве диспетчера связи (DThostname) альтернативный сервер для соответствующих баз данных на сервере DB2 Connect (сервер 1 DB2 Connect или сервер 2 DB2 Connect). Теперь если сервер 1 DB2 Connect по какой-либо причине станет недоступен, запустится автоматическое перенаправление клиентов и соединение клиента будет устанавливаться заново с использованием диспетчера связи в качестве и первичного, и альтернативного сервера. Это позволяет совместно использовать возможности диспетчера связи с функцией автоматического перенаправления клиентов DB2. Если в качестве альтернативного сервера задать другое имя хоста (не хост диспетчера связи), клиенты по-прежнему смогут использовать функцию автоматического перенаправления клиентов. Однако клиенты будут устанавливать соединения напрямую с заданным альтернативным сервером и не будут использовать технологию диспетчера связи и ее преимущества.

Функция автоматического перенаправления клиентов перехватывает следующие sqlcodes:

• sqlcode -20157
• sqlcode -1768 (код причины = 7)

Особенности автоматического перенаправления клиента при каталогизации на сервере DB2 Connect

Необходимо иметь в виду следующие два вопроса, касающихся связи с альтернативным сервером при помощи сервера DB2 Connect:

• Первый вопрос касается использования сервера DB2 Connect для доступа к базе данных хоста или iSeries от имени как удаленных, так и локальных клиентов. В таких ситуациях возможна неопределенность касательно информации о связи с альтернативным сервером в записи системного каталога баз данных. Для уменьшения неопределенности рассмотрите возможность внести в системный каталог баз данных две записи, представляющие одну и ту же базу данных хоста или iSeries. Добавьте в каталог одну запись для удаленных клиентов, а другую - для локальных.
• Второй вопрос - это то, что информация об альтернативном сервере, возвращаемая сервером назначения, сохраняется только в кэше. Если процесс DB2 завершит работу, информация кэша будет утрачена, а с ней и информация об альтернативном сервере.

Поддержка учетной записи локальной системы (Windows)

Прикладные программы, работающие в контексте учетной записи локальной системы (local system account, LSA), поддерживаются на всех платформах Windows, кроме Windows ME.

Поддержка двухчастного ID пользователя

Оператор CONNECT и команда ATTACH поддерживают двухчастные ID пользователей. Спецификатор ID пользователя, совместимого с SAM, - это имя в стиле NetBIOS, у которого максимальная длина - 15 символов. Эта возможность не поддерживается в Windows ME.

Подробности аутентификации Kerberos

Дополнительная информация для поддержки Kerberos