powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Распределённая транзакция между 2-я DB2.
4 сообщений из 4, страница 1 из 1
Распределённая транзакция между 2-я DB2.
    #38284112
Дмитрий_413
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем привет!

Суть в следующем: есть таблица в одной БД, есть архивная таблица в другой БД. Соответственно, требуется периодически отбрасывать данные в архивную таблицу.

Текущая ошибка:

SQL30090N Operation invalid for application execution environment. Reason code = reason-code.
Explanation
The operation is invalid for the application execution environment. For example, an operation might be invalid for applications that have special restrictions on statements or APIs - applications such as those that operate in an XA Distributed Transaction Processing environment, such as CICS; those that operate with CONNECT type 2 connection settings; or those that use federated system functionality to update multiple heterogeneous data sources. The operation was rejected.
Possible reason codes are:
18
An update request (or, a DDL operation that results in the update of a system catalog table) has been issued that would result in multiple data sources being updated when one or more of the data sources in the unit of work only supports one-phase commit. Possible causes are:
An attempt was made to update a data source that only supports one-phase commit, but a different data source has already been updated in the same unit of work.
An attempt was made to update a data source that supports two-phase commit, but a different data source that only supports one-phase commit has already been updated in the same unit of work.
An attempt was made to update a local federated server table, but a data source that only supports one-phase commit has already been updated in the same unit of work.
An attempt was made to update a data source that only supports one-phase commit when the application is operating with a CONNECT type 2 connection setting.

Из неё понятно, что не настроен протокол двухфазного коммита.

Погуглив, пришёл к выводу, что для соединения БД необходимо использовать команду CONNECT (2) с ключом SYNCPOINT, равным TWOPHASE .

На что получил ответ "администратора": Сейчас связь между БД устанавливается в рамках федерации и в её объектах (алисах, определяениях серверов и др.) я не нашёл возможности настроек транзакций. Каким образом мы можем использовать такие параметры коннекта в рамках федерации я пока тоже не представляю.

Помогите разобраться, сам разработчик Oracle, не понимаю что такое федерация и т.п.
Версия DB2 v9.7.
...
Рейтинг: 0 / 0
Распределённая транзакция между 2-я DB2.
    #38284156
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дмитрий_413,

Опция объекта SERVER - DB2_TWO_PHASE_COMMIT ( DB2 database options reference ).

Код: sql
1.
ALTER SERVER servername OPTIONS (ADD DB2_TWO_PHASE_COMMIT 'Y');



Но разумней эти операции производить в рамках обслуживания БД силами самих админов - вы задаёте "откусываемые" промежутки, они переносят их в другую базу наиболее эффективным способом.
...
Рейтинг: 0 / 0
Распределённая транзакция между 2-я DB2.
    #38284189
Дмитрий_413
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
CawaSPb,

Дело в том, что норм админа нет.

О таком ключе не слышал - посмотрю, спасибо, но неужели нужно включать данную функциональность глобально во всей БД?
В рамках коннекта между базами никак не обойтись (CONNECT (2))?
...
Рейтинг: 0 / 0
Распределённая транзакция между 2-я DB2.
    #38284317
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дмитрий_413,

Объекты типа SERVER (в рамках конкретной БД таких может быть много) - описание удалённого источника данных, работа с которым происходит прозрачно для приложений (грубо - dblink в терминах Oracle).
Код: sql
1.
select * from syscat.servers



На основе созданного объекта server строятся NICKNAMEs - закаталогизированные локально удалённые таблицы/вью.
Код: sql
1.
select * from syscat.nicknames


или
Код: sql
1.
select * from syscat.tables where type='N'



Обращение к NICKNAME инициирует обращение к удалённой базе со стороны СУБД.
Поскольку это происходит неявно, то никаких опций для соединения мы указать не можем (кроме как прописанных в атрибутах объекта типа SERVER и общего для всех никнеймов, построенных на основе данного сервера).
Таким образом - да, включение опции имеет глобальный эффект для этой базы и удалённого источника.

Надо, чтобы к разным таблицам удалённой базы оно ходило по-разному - нет проблем, заводим два (или более) объекта типа SERVER со своими опциями, на их основе строим никнеймы к соответствующим группам удалённых таблиц.
Можем одну и туже таблицу определить двумя способами - завести дополнительный "сервер" с опцией DB2_TWO_PHASE_COMMIT 'Y' и через него сделать ещё один никнейм на нужную таблицу (на тот случай, если не хотите, чтобы изменение опций как-то повлияло глобально на систему в целом).

Но лучше через EXPORT/IMPORT (LOAD, если научитесь с ним аккуратно работать, что, впрочем, дело нехитрое).


PS Нормального админа так или иначе всё же лучше иметь.
...
Рейтинг: 0 / 0
4 сообщений из 4, страница 1 из 1
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Распределённая транзакция между 2-я DB2.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]