Здравствуйте!

Есть вопрос про NickName, который используется в функции. Имеем СУБД (9.7). Есть функция, которая используется во многих местах. В этой функции используется через union несколько select - ов, как обычные таблицы , так и NickName. Функция возвращает таблицу (Return table). Из-за этой функции периодически возникают блокировки, дабы их не было. Хочется в функции прописать with ur (грязное чтение). В документации сказано, что это возможно:
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=%2Fcom.ibm.db2.udb.rn.doc%2Fdoc%2Fc0023718.htm

Переписать, то я переписал, но идёт ругачка, типа в данном контексте with ur запрещён.
Пробовал обернуть функцию в другую функцию, дабы в ней вызвать первую функцию with ur.
Может кто нить что нибудь посоветовать? Переписать все вызовы функции в коде , нереально - их штук 150, что оооочень бы не хотелось!
Спасибо!

Забыл уточнить, удаленный источник для NICKNAME находится на том же инстансе в другой базе DB2. Тоесть база та же DB2 (9.7).

medoed,
Потролю немножко, походу Марк в отпуске

Кстати в процедурах такое возможно:




.Но мне нужна именно функция, так как потом она используется как select id from table (FUNCK_NICKNAME).
Есть какой то обходной путь?

Марк, не выручите? Я выдохся - всё пробовал и исчерпал по данному вопросу свои силы.
I need help!

Mark Barinsteinmedoed,

Здравствуйте.
Не нашел явного указания в документации, но, похоже, что нельзя в функциях, обращающихся к федеративным объектам, использовать isolation clause.
Либо используйте процедуры, либо можете устанавить UR по-умолчанию для соединения (с помощью процедуры и параметра базы CONNECT_PROC), если это вам подойдёт, и у вас действительно блокировки из-за этой функции в удаленной базе.

Кстати, как вы определили, что блокировки именно из-за этой функции?
Какие именно блокировки она накладывает и на какие ресурсы?


Спасибо за отклик, Марк!
Может зафиксите как баг для IBM от себя,(так точно быстрее должны поправить) было бы удобно уровни изоляции и к удаленным объектам применять!
Процедуры мне не подойдут - я потом фукнкцию в конструкции from использую. Процедуру я в конструкцию select from table не засуну!

>> либо можете устанавить UR по-умолчанию для соединения (с помощью процедуры и параметра базы CONNECT_PROC)

А как это мне поможет? Ведь у меня в одной функции куча union к обычным таблицам и 2-ва к MQT. Дык вот функция компилится нормально а при выполнении пишет, что в данном контексте clause wth isolation use and keep is not allowed. Тоесть как только она видит Nickname c опцией with - все полный пипец! Раздробить на 2-ве для обычных таблиц и для NickName а потом соединить в одной и оставить with ur только для обычных таблиц - тоже ругачка при выполнении!

>> Кстати, как вы определили, что блокировки именно из-за этой функции
Сделал в централе задачу, которая каждую минуту сканит базу на предмет блокировок (from SYSIBMADM.MON_LOCKWAITS) и если есть записывает в таблицу для лога, потом в интерфейсе отображается этот лог для разных баз.


>> Какие именно блокировки она накладывает и на какие ресурсы?
При одновременном обновлении тех таблиц, на которых она базируется!

Mark Barinsteinmedoed >> либо можете устанавить UR по-умолчанию для соединения (с помощью процедуры и параметра базы CONNECT_PROC)

А как это мне поможет? Ведь у меня в одной функции куча union к обычным таблицам и 2-ва к MQT. Дык вот функция компилится нормально а при выполнении пишет, что в данном контексте clause wth isolation use and keep is not allowed. Тоесть как только она видит Nickname c опцией with - все полный пипец! Раздробить на 2-ве для обычных таблиц и для NickName а потом соединить в одной и оставить with ur только для обычных таблиц - тоже ругачка при выполнении!
2-ва к MQT или к nickname?
Уровень изоляции сессии при соединении мапится на соответствующий уровень изоляции удалённого сервера.
Т.е. предположительно, если у вас будет UR по-умолчанию на федеративном сервере, то и запросы в удалённый будут идти тоже с UR, если вы явно в федеративном запросе не указываете уровень изоляции.

12 union к обычным таблицам и 2-ва к NickName конечно. Я понимаю, что если я укажу для всего федеративного сервера with ur -это мне поможет отчасти , но на 12 обычных таблиц в функции блокировки останутся!

Mark Barinstein,

Марк, у меня на справочной базе и на базе с данными стоит по умолчанию уровень изоляции CS. Для одной функции, которая массово выбирает данные, я хочу поставить UR. Но с этим источником,как справочной базой работаюи и MQT и триггеры, я не хочу для баз прописывать UR. Или я чего то не понимаю и можно только для конкретных коннекций, к конкретным таблицам прописывать уровень изоляции UR и при этом на функцию, которая использует двенадцать обычных таблиц и 2-ва Nickname тоже уровень изоляции накатится UR, я не совсем понимаю, как это так?

Mark Barinsteinmedoed,

Уровень изоляции по-умолчанию можно задавать и менять на уровне приложения.
С федеративными источниками правило такое: уровень изоляции соединения с источником по-умолчанию берётся с федеративного сервера, и потом в этой сессии его нет возможности изменить.
Вы можете задавать уровень изоляции федеративного запроса явно, но там есть ограничения.
Statement level isolation in a federated system
В вашем случае, когда оно не разрешает WITH в функции, это, скорее всего, есть ограничение на WITH в подзапросе (subquery).

Что вы можете попытаться сделать в этой выбранной вами архитектуре.
Выше я неправильно указал, что можно попытаться установить уровень изоляции по-умолчанию (в процедуре, которая будет вызываться при connect) - оно не реагирует на это.
Вы можете, в зависимости от типа соединения, устанавливать уровень по-умолчанию:
jdbc - свойство defaultIsolationLevel=1
cli/odbc - свойство TxnIsolation =1 в db2cli.ini

После установки соединения можно пнуть какой-нибудь федеративный запрос (цель - установить соединение с источником на текущем уровне изоляции - UR).
Затем в сессии можно выдать команду типа:
В итоге все обращения к локальным таблицам будут с CS, а к удалённым - с UR.

Спасибо, Марк!
Боюсь это мне не поможет, в качестве интерфейса - у меня есть толстый клиент в виде конструктора, в нём я не могу менять свойство коннекта, в толстом клиенте, я наверное могу прописать команду set isolation level - но мне получается надо будет прописывать во многих местах.

>> В итоге все обращения к локальным таблицам будут с CS, а к удалённым - с UR
Спасибо , Марк! Но это не решение проблемы, потому как:

Мне не надо ко всем обращениям к федеративному серверу читать по грязному (ведь я могу insert и в NickName сделать - c with ur - это плохо), мне надо только в рамках одной функции прописать для всех select - ов with ur (грязное чтение).
Да хрен с ним уже с 2-мя union для NickName.
Пусть хотя бы для 12 union - ов в функции к обычным таблицам будет грязное чтение, а для остальных 2-х union -ов с NickName - останется CS. Было бы логично разработчикам IBM - делать именно так, не можете в рамках функции менять уровень изоляции для NickName - не меняйте, но остальные то сущности почему должны страдать...

P.S. После таких подстав от IBM - сильно ностальгируется по MSSQL, там nolock (грязное чтение) можно писать к каждой таблице и view.

Mark Barinsteinmedoed,

тогда у вас есть 2 выбора:
- переписать вызов этих функций
- реплицировать информацию из nickname-ов и обращаться только к локальным таблицам

P.S.:
Обычно, сначала разбираются с функциональностью продукта, а потом пишут много кода.
А не наоборот...


>> - переписать вызов этих функций
Это на крайняк, но мы думаем об этом!

>> - реплицировать информацию из nickname-ов и обращаться только к локальным таблицам
Это опять MQT - и потом на многомиллионных таблицах ловить deadlock по 5-ть минут - нет спасибо, лучше с NickName остаться имхо!

>>P.S.: Обычно, сначала разбираются с функциональностью продукта, а потом пишут много кода.
Текущей системе лет -5 ть, я с ней только 2 месяца работаю и начал как раз с оптимизации, так получилось.
А так то да - задним умом мы все крепки !

Марк, у меня уже было предложение к Вам - заявить это как баг в IBM
(невозможность вызова NickName в функциях c определенным уровнем изоляции)
Это же в любом случае улучшение системы СУБД DB2, если такие просьбы о доработках игнорировать, будет как с Sybase:
http://www.sql.ru/forum/actualthread.aspx?tid=980507
Имхо.

>>Почитайте про cache tables.
>>Кроме того, вы можете не связываться с MQT на nickname и кэшированием (это та же репликация), а просто выкинуть nickname и >>настроить репликацию удаленного справочника.
>>В обоих случаях не надо делать постоянно делать полный refresh.
Оба Ваши варианта базируются на репликации, она пусть редко, но падает - это значит надо привлекать админа, как следствие накладывать на себя ограничения, админ может быть в отпуске или приболеть и всё- вся система встанет раком без репликации! У меня такое было в первом моём банке, причем репликационный сервер показывал, что все гут, а проводки на бэк- офис не проливались с фронта. Я бы понял ещё если бы был другой инстанс, находящийся где нибудь в другой стороне города, тогда возможно и репликация была бы нужна. Но если базы находятся на одном инстансе, делать репликацию - как то не логично. Для MSSQL это вообще не вопрос считать данные с другой базы select * from BASE2.dbo.table2 (nolock) в любой функции без проблем!

>>Такие предложения (DCR - Design Change Request) инициируются клиентами.
>>Пишите в IBM - мол, вот, хочу, чтоб можно было делать так.
>>В IBM посмотрят на экономическую целесообразность, на похожие требования других клиентов.
Sybase тоже все подсчитывало экономическую целесообразность (там менеджмент), правда патчи частенько выпускало. Пару лет назад их купил SAP)) . Мою заявку IBM будет мурыжить годами, Вашу как VIP- персоны - возможно рассмотрят за пару месяцев.

>>Приходит больной к доктору, крутит руками и говорит:
>>- Доктор, мне больно когда я так делаю!
>>- Ну не делайте так!

Если мне нужно руками крутить, так же как и соседу для того чтобы выполнять упражнение на турнике, например и допустимые махи руками вызывают боль я, впрочем как и другие пациенты рано или поздно выберут другого врача (хирурга или невролога), который назначит физио процедуры , снимки плечевого сустава, выпишет что нибудь аля диклофенака, назначит ЛФК))
И рано или поздно такой врач, который относится пофигистически к пациентам, к сожалению окажется без работы, рынок есть рынок.

За 2 месяца работы с DB2 я наткнулся, как мне кажется на немало ограничений:
1) Триггеры нельзя disable/enable.
2) На одном инстансе нельзя напрямую обращаться к сущностям разных баз DB2.
3) Уровень изоляции ставится на блок, вместо того, чтобы применяться к каждой сущности.
4) Нет нормального монитора блокировок (аналог функции sp_lock), как на MSSQL или sp_showplan (план текущего выполнения процесса), как в Sybase.
5) Нет нормального профайлера (родного от IBM), который бы логину или по имени машины - показывал полный лог, до мельчайшей команды в realtime
6) При массовой вставке в IDENTITY поле, функция IDENTITY_VAL_LOCAL() - функция возвращает NULL, scope_identity() - в MSSQL так себя не ведёт.
7) В табличной функции DB2 (RETURN TABLE ) нельзя объявить табличную переменную, заполнить её и вернуть declare @t table и вернуть без всякого SET (только в процедуре).
8) Нельзя стандартными функциями DB2, работающими со строками - вернуть varchar(max), VARCHAR(32000). CLOB - все такми немного другое, имхо!
9) В интернете нет online базы для DB2, для тестов, а для других распотранённых субд есть sqlfiddle.com

КАК то ТАК...
Начальный вопрос темы вполне освещён, спасибо Марку !
Змоциональный выброс - прошу прощения, немного накипело ...

>> Не всё так плохо.
Ну конечно есть плюсы, например к функции, можно обратиться в конструкции from, в MSSQL если мне не изменяет память, функцию, возвращающую таблицу можно join -ить только в cross aply. Есть в DB2 функция listagg для что собирает строку для столбца таблицы - в MSSQL через XML.
Но по сравнению с Sybase/MS SQL плюсов честно говоря у DB2 меньше.
Это я не стал вспоминать облачные технологии (у DB2 только тесты ещё идут), DTS => SSIS, RSIS, SSAS от MSSQL - тогда снова DB2 немного просядет в сравнении
>>

>>Все эти федеративные базы на одном узле

Эта система внешняя с открытым кодом и федеративные базы появились не от меня, мне как MSSQL - щику эти федеративные базы кажутся лишними, но длительные ночные расчеты и стоимость железа - сделали свое дело, опять же решение не я принимал, это наследие...

>> табличные функции, которым к тому же непременно надо куда-то что-то записать

Я обошёлся без этого (без записи в доп. таблицу), но все почему - из-за ограничений DB2 - java функция для DB2 не умеет работать с NIckName (а мы хотим уйти от MQT), поэтому и пришлось переписать java- функцию, которая из строки указанного столбца таблицы - собирает строку - на SQL.


>> Такое чувство, что вы пытаетесь воспрооизвести 1:1 подход, который вы обычно применяете на Sybase/MS SQL, и наверняка так оно и есть.

Вы ошибаетесь, я полнокровно изучаю возможности DB2 (тем более, что пол года работы с Oracle есть за плечами тоже), часами читаю литературу и смотрю форумы по всему миру, дабы не изобретать велосипеды! К тому же часто устраиваю мозговой штурм с коллегами и начальством, дабы покритиковали мои решения.
К тому же меня контролируют по производительности админы и начальство, например из-за моего монитора блокировок, который логирует каждую минуту состояние базы на предмет блокировок - увеличилось число дисковых операций, процентов на 10, но пока это терпимо (зато теперь знаем актуальных виновников ). Уйдём от блокировок, буду запускать монитор реже!

>> На DB2 мне он кажется вредительством - то бишь,
>>вы делаете лишнюю работу, с тем, чтобы получилось хуже (по производительности, как минимум)

Пока результаты обнадёживают, процентов 20% блокировок с системы ушло, есть мысли как ещё 60% убрать.
Скорость при этом тоже высчитывается и пока не падает.
Буду мешать системе - мою работу прикроют, так что не беспокойтесь!

lockListmedoedПока результаты обнадёживают, процентов 20% блокировок с системы ушло, есть мысли как ещё 60% убрать.

интересно, а какой объем памяти (от доступной субд) занимал lock list на пике ?

Мы не смотрели оперативку, заюзанную под lock list (я не админ, сорри).
Мы разбирали по сущностям, смотрели на гигантские MQT, refresh которых вызывал блокировки.
Пока мы смогли одну 10- ти миллионую MQT заменить на NickName (c ежедневным обновлением статистики по NickName). Время запросов особо не увеличилось (где то уменьшилось, где то увеличилось по сравнению с MQT), а вот 5-ти минутного зависания (блокировок) из-за обновления той большой MQT не стало. Как то так...

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

На сайте должна отображаться информация по клиентам которые зарегистрировались потом по ключу делается поиск и подтягивается информация. Как и куда обратиться?

Что бы на сайт (база на MSQL) информация вытягивалось с другого сервера ( база на ДБ2).
Вопросы:
С чего начать
или писать программу для передачи данныхх с базы DB2 в MSQL. Где почитать и с чего начать?
или есть другой способ?
Если таблицы небольшие, с которой идут запросы из DB2 и все происходит в рамках одного домена - Сделайте Linked Server на севере MSSQL для базы DB2 и тягайте информацию прямыми запросами.
Если сервера не в одном домене или есть какой нить хитрый DMZ - используйте web services.
В рамках 3-х звенной архитектуры web services более правильное решение...

Шаман, а вы случайно не на Динамо учились эдак с 2008 по 2003 год например, что то в Вашем Нике мне кажется знакомым))

>> CAWASPB
>>Присоединюсь к Виктору.
>>Вы разбираетесь с плохим архитектурным решением и накручиваете сверху невесть что. Результат будет заведомо плохим.
Этой системе 5-ть лет, то что она подтормаживает – это факт, мне как раз и поставлена задача по её оптимизации, малыми силами и в сжатые сроки. Результаты уже есть))

>>Различные базы в DB2 by design независимы. У них свои выделенные блоки памяти, свои агенты (работающие в данный >>момент с конкретной базой), свой scope >>транзакций . Агент не может взять и полезть в "соседнюю" базу за данными, >>весь обмен идёт по DRDA протоколу.
>>Это
>>а) идеологически правильно (за что лично я люблю DB2, и из этого самым >>неожиданным образом вдруг вырастают всякие >>вкусные вещи)
>>б) позволяет изолированно управлять разными базами.
При нормальном написании кода никаких проблем не возникает в MSSQL и Sybase, если базы лежат на одном сервере, даже при параллельных расчетах. Зато не надо гемороиться с MQT и NickName…

>>Из рассказываемого Вами следует то, что всё это должно быть одной базой.
>>Ну так слейте всё вместе, в чём проблема? На уровне БД более чем достаточно механизмов разделения ресурсов, которые позволят отделять решение одних задач от других.
>>Если вы всё же не хотите, или есть веские причины этого не делать, то ПОЧЕМУ НУЖНО ОТКАЗЫВАТЬСЯ ОТ РОДНОГО >>МЕХАНИЗМА, специально предназначенного для инкрементального продуцирования изменений из базы в базу???
Так устроена архитектура, считается что ночные паралельные расчеты лучше пустить по разным базам и агентам соответственно, мне пока это не ставилось в задачу менять существующую архитектуру.
Лично я считаю, что MQT на большие таблицы для любой СУБД зло!

>>Репликации нуждаются в дополнительном maintenance?
>>А кто обещал, что будет легко?! :)
>>У вас нет бэкапа для админа (это, вообще, админская работа, настраивать, мониторить и поддерживать репликации; мониторинг >>состояния репликаций отлично >>автоматизируется) на продуктиве на время болезней/отпусков??? :O Ну... срочно >>растите у >>себя ещё одного админа или совместителя. Мне непонятно, как можно жить >>з такого бэкапа.
>>и ищите, кому можно отдать эту задачу на откуп (типа >>rl=http://www.triton.co.uk/]Triton). Хороший вопрос, кстати, >>созрел ли у нас народ я подобных услуг (или, может, уже есть кто, такие услуги представляющий?).
Повторюсь при такой же архитектуре для MSSQL или Sybase не надо было бы никаких разных баз и репликации тем более. Вторая причина – не хочется загружать админов, пусть делают и накатывают при необходимости бэкапы.
Пока что тесты показывают в сторону NickName, возможно мы обойдемся ими без репликации и в DB2.

>>По претензиям (ограничениям):
>> 1) Триггеры нельзя disable/enable.

>>Да, неудобно. Но, возможно, свой смысл в этом есть.
>>Триггеры в DB2 "inlined" (с 9.7 для некоторых случаев можно сделать "compiled"), что означает, что тело триггера выполняется не как код в PVM (Procedure Virtual Machine), >>а встраивается непосредственно в запросы (и уже после компилируется и >>оптимизируются как единое целое).
>>"Выключение" триггера сразу инвалидирует пакеты и планы запросов в кеше, с ним >>связанные, т.е. может иметь достаточно большой impact.
>>При удалении, к примеру, view - это очевидно. "Выключении" триггера - не очень.
>>С другой стороны, если мы хотя бы чуть-чуть "в теме", дело, вроде, нехитрое:
>>

>>(но надо ещё помнить про то, кто owner триггера, тут могут быть дыры в безопасности, >>как и с механизмом включения/выключения).

Ключевая фраза здесь - Да, неудобно.
Все остальное домыслы! В MSSQL,Oracle,Sybase – есть отключение триггеров, если мы считаем DB2 – современной базой, то и в ней должно быть – остальное лирика!

> 3) Уровень изоляции ставится на блок, вместо того, чтобы применяться к каждой сущности.
>Не могу прокомментировать, пропустил часть обсуждения.
>Что именно Вам нужно (кроме как избавиться от блокировок на конкретном statement'е)?

Я хочу чтобы DB2 умело вот так (как в MSSQL или Syabase)



> 4) Нет нормального монитора блокировок (аналог функции sp_lock), как на MSSQL или
>Не хватает мощности > MON_GET_LOCKS table function , > MON_LOCKWAITS administrative view , > MON_GET_APPL_LOCKWAIT table function , > LOCKS_HELD administrative view , > LOCKWAITS administrative view , их deprecated snapshot monitoring >версий, > locking event monitor'ов , диагностики в diagpath, > db2pd ... -locks ... -wlocks ... ???
> sp_showplan (план текущего выполнения процесса), как в Sybase.
>Картина примерно такая же как с блокировками.

Я хочу простое визуальное отображение блокировок, самых тяжелых и долгих запросов из стандартизированной среды IBM (IBM MON), а не юзать 15 разных скриптов и программ , пусть даже и полезных. Хорошо если сделают так как это сделано в Management Studio от Майкрософта, там все это встроено, пусть тупо скопируют – и народ к ним потянется))


> 5) Нет нормального профайлера (родного от IBM), который бы логину или по имени машины - показывал полный лог, до
> мельчайшей команды в realtime
>Вы хотите сказать, что не нашли "on-line" визуализатора?
>Вообще говоря
>а) есть такие вещи как tracing (CLI/ODBC, JDBC), statement monitoring, event monitoring >для activities и т.п.
>б) если мы говорим о взрослой серьёзной системе, то сотни/тысячи запросов, >выплёвываемые в realtime вряд ли вам нужны.
Я пользовался СТАНДАРТНЫМ РОДНЫМ PROFILER от MSSQL, в стандартной поставке по умолчанию. С помощью него я могу любую сессию отловить, что она делает.
ООООЧЕНЬ удобно именно порой в realtime и ничему это не мешает!!!
Дайте мне такую же простую, понятную и родную визуальную утилиту от IBM, чтобы можно было просматривать сессию, по любым параметрам, в том числе и по Application Name. Нету – значит НЕУДОБНО НИ РАЗУ!

> 6) При массовой вставке в IDENTITY поле, функция IDENTITY_VAL_LOCAL() - >функция возвращает NULL,
> scope_identity() - в MSSQL так себя не ведёт.

>Ну, identity - это вообще отдельная песня. Я не уверен, что это хорошо, что IBM пошла >на поводу у пользователей и ввела эту сущность в DB2. Разве что для облегчения >миграций.
Нет это нужно для разноплановости, простоты и элегантности разработки, для ”акклиматизации” разработчиков SYBASE и MSSQL.

>Identity плохо вписываются (точнее - никак) в транзакционные механизмы, служат >источником многих проблем в долго живущих системах ("А-а-а-ааа!!! У нас диапазон >идентификаторов заканчивается!!!!!"), создают ОГРОМНЫЕ проблемы при слиянии >информационных систем (например, нескольких баз, разделённых по регионам, в одну) и >т.п.
>GENERATE_UNIQUE() - вот идеологически правильный путь.
Бывает, что базы сливать не нужно, тогда Identity удобно и мало места занимает.
Да и при сливе заново Identity сгенерить через дополнительное поле таблицы, не судьба?
В MSSQL тоже есть NEWID() и что?
Хочешь через Identity поле нумеруй , хочешь через uniqueidentyfier (NEWID())

>В данном же случае (scope_identity() после массовой вставки) - вопрос, нахре... >зачем он нужен???
Последний вставленный идентификатор.


> 7) В табличной функции DB2 (RETURN TABLE ) нельзя объявить табличную >переменную,
> заполнить её и вернуть declare @t table и вернуть без всякого SET (только в процедуре).

>Это опять же определяется декларативной/функциональной природой, присущей inlined >compound statement'ам, а не императивной/процедурной, присущей compiled блокам.
>Только в этом случае ф-я может быть предметом для оптимизации в рамках более >общего выражения. Когда используемое выражение стоит во FROM это очень >важно.
>Наложенное ограничение может быть несколько искусственно, но оно не даёт скатиться в полный трэш при разработке:
> чаще разработчики почему-то не умеют мыслить функционально и оперировать set'ами, проще понаделать временных таблиц, >самостоятельно их заполнить, итеративно >перебирая строки, потом уже итеративно проходить по этим временным таблицам и >т.д. это мало того, что требует массовых и одновременно весьма дорогостоящих операций типа fetch (чаще - из случайных мест >таблицы, т.е. prefetch не работает), так ещё и >однозначно определяет план выполнения, который далеко не всегда оптимальный >(или >далеко не всегда будет оптимальный).

>Другой важный момент, для "compiled" табличных функций статистика была бы сильно >урезана. Для external можно указать >только предплолагаемую cardinality. Если можно >было бы указать какую другую, то стояла бы большая проблема поддержки её >актуальности.
>Для inlined табличных ф-ий статистика вычислима (хотя, зависит, конечно, от того, что >мы внутри накрутим).
Честно говоря не понял о чем тут вовсе… Мне нужно было просто для определенных сущностей внутри функции, анализировать уровень изоляции ну и динамический вопрос переварить.
Для меня это плохо (нельзя для отдельных сущностей уровень изоляции менять), я считаю это недостатком DB2 – весь эпос написанный в пункте 7-ом , возможно я пойму-переварю позже)).

>>PS Хотелось бы ко всему этому порекомендовать с осторожностью относиться ко всяким tips & tricks, встречаемым в сети.
>>Они далеко не всегда разумны, подчас давно потеряли свою актуальность, иногда представляют какие-то новые фичи, которые не всегда проверены временем.
Учту на будущее… Спасибо!

P.S. Еще один недостаток встретил, по сравнению с MSSQL и Sybase – процедурой нельзя вернуть select в DB2 .
В том же Oracle можно вернуть sys_refcursor, беглым взглядом я такого в DB2 не нашёл!
Имхо на Российском, да и на мировом рынке для РСУБД DB2 будет вытесняться(возможно и к сожалению) всё больше и больше (Oracle and MSSQL)...

shaman902можно же к примеру написать на делфи или на яве програмку которая будет автоматом с сервера или серверов на ДБ2 по ип-адресам собирать инфу с таблиц - запросами, и закидывать на веб сервер в мsql базу каждую ночь. на чем легче будет написать делфи или ява?
Есть разныемварианты синхронизпции, попробую перечеслить:
1. Через Linked Server Mssql, я в разных доменах не пробовал, но возможно прокатит по Ip подсоединиться, это можно попробовать, там все через визуальный конструктор делается, минут 10 потратьте, попробуйте.
2. Через репликацию, но это не очень просто имхо, реплицировать чужеродный сервер, я так понимаю вы не админ.
3. Через файлы, грузите из DB2в xml файл данные, потом импортите в mssql в нужные таблицы из xml. Формат файла ограничивает Ваша фантазия.
4. Через клиентскую часть (delphi или java) тут без разницы. Запихива для одного конекшинаете все в dataset и извлекая в msqql из того же дата set.
5. Есть красивое решение через ssis, типа визуальный загрузчик mssql, я в свое время на DTS красивые вещи ваял. Плюс в том, что все интуитивно понятно и просто! Я бы выбрал наверное 5 вариант.

Я хочу чтобы DB2 умело вот так (как в MSSQL или Syabase)
а) select * from table1 (nolock) , table2(nolock) where table1.id = table2.id
б) select * from table1, table2(nolock) where table1.id = table2.id
в) select * from table1 (nolock) , table2 where table1.id = table2.id
А не только так : select * from table1 , table2 where table1.id = table2.id with ur;В db2 можно указывать изоляцию на уровне subselect типа такого:

Получается немного длиннее mssql, но смысл будет тот же.
[/quot]

Марк, я забыл уточнить - такие возможности в MSSQl можно применять в рамках любых функций и процедур для отдельных сущностей выборочно! Как с этим в DB2?

Я правильно понимаю, что вы сравниваете, скажем, nickname N1 и MQT M1 с описанием типа (select * from N1).
И при каких-то обстоятельствах одни и те же запросы, но использующие N1 вместо M1 работают быстрее?
Если да, то на всякий случай спрошу - вы создаёте на M1 такие же индексы, как в удалённой базе на таблицу, на которую ссылается nickname?
Если ответ на все эти вопроса - да, то это явный нонсенс - я не могу в это поверить...


Вы неправильно меня поняли...
Тесты показывают, что можно обойтись без репликации - в сторону NickName, я это имел в виду.
Но NickName не сильно проигрывают MQT по скорости, но нет 5-ти минутных проблем при обновлении MQT. Ну да работает на 20% NickName медленнее, зато нет 5-ти минутных дедлоков. Мы потерпим 20% проигрышь...

Где-то вы ещё спрашивали про то, что для каждой удалённой таблицы надо обязательно заводить nickname - неудобно.
IBM здесь пошла навстречу пожеланиям, но в следующей версии - 10.1.
Federated three-part names


За это спасибо, хоть к чему то IBM прислушивается, может они сделают WITH UR для функций, для тех сущностей к которым уровень изоляции допустим для версии 10.1.

Mark BarinsteinmedoedМарк, я забыл уточнить - такие возможности в MSSQl можно применять в рамках любых функций и процедур для отдельных сущностей выборочно! Как с этим в DB2?

Мне как раз надо для NickName. Вот что за хрень - в доке от IBM про это нет ничего, про понижение уровня изоляции с NickName в функции.
Ну да ладно - я прошу просто сделать логично - для всех сущностей в функции измените уровень изоляции, как я хочу, не можете для NickName - для них не меняйте.
В итоге хрен - я не могу использовать всю функцию, если в ней есть with ur и NickName!
Обидно и не логично!!! ИМХО...

shaman902 medoed , Большое спасибо
Рад помочь, потом что получилось - опишите ради интереса))
Тема будет интереса многим...