Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Распределённая транзакция между 2-я DB2.
|
|||
|---|---|---|---|
|
#18+
Всем привет! Суть в следующем: есть таблица в одной БД, есть архивная таблица в другой БД. Соответственно, требуется периодически отбрасывать данные в архивную таблицу. Текущая ошибка: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2013, 17:46 |
|
||
|
Распределённая транзакция между 2-я DB2.
|
|||
|---|---|---|---|
|
#18+
Дмитрий_413, Опция объекта SERVER - DB2_TWO_PHASE_COMMIT ( DB2 database options reference ). Код: sql 1. Но разумней эти операции производить в рамках обслуживания БД силами самих админов - вы задаёте "откусываемые" промежутки, они переносят их в другую базу наиболее эффективным способом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2013, 18:07 |
|
||
|
Распределённая транзакция между 2-я DB2.
|
|||
|---|---|---|---|
|
#18+
CawaSPb, Дело в том, что норм админа нет. О таком ключе не слышал - посмотрю, спасибо, но неужели нужно включать данную функциональность глобально во всей БД? В рамках коннекта между базами никак не обойтись (CONNECT (2))? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2013, 18:22 |
|
||
|
Распределённая транзакция между 2-я DB2.
|
|||
|---|---|---|---|
|
#18+
Дмитрий_413, Объекты типа SERVER (в рамках конкретной БД таких может быть много) - описание удалённого источника данных, работа с которым происходит прозрачно для приложений (грубо - dblink в терминах Oracle). Код: sql 1. На основе созданного объекта server строятся NICKNAMEs - закаталогизированные локально удалённые таблицы/вью. Код: sql 1. или Код: sql 1. Обращение к NICKNAME инициирует обращение к удалённой базе со стороны СУБД. Поскольку это происходит неявно, то никаких опций для соединения мы указать не можем (кроме как прописанных в атрибутах объекта типа SERVER и общего для всех никнеймов, построенных на основе данного сервера). Таким образом - да, включение опции имеет глобальный эффект для этой базы и удалённого источника. Надо, чтобы к разным таблицам удалённой базы оно ходило по-разному - нет проблем, заводим два (или более) объекта типа SERVER со своими опциями, на их основе строим никнеймы к соответствующим группам удалённых таблиц. Можем одну и туже таблицу определить двумя способами - завести дополнительный "сервер" с опцией DB2_TWO_PHASE_COMMIT 'Y' и через него сделать ещё один никнейм на нужную таблицу (на тот случай, если не хотите, чтобы изменение опций как-то повлияло глобально на систему в целом). Но лучше через EXPORT/IMPORT (LOAD, если научитесь с ним аккуратно работать, что, впрочем, дело нехитрое). PS Нормального админа так или иначе всё же лучше иметь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2013, 19:58 |
|
||
|
|

start [/forum/topic.php?fid=43&tid=1601426]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
31ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 127ms |

| 0 / 0 |
