2gardenman

1. вы похоже путаете DDL и DML :)
2. судя по всему ибм как и я запутался в своих субд (я их уже 4 насчитал). похоже блокорока ставится в какой-то db2 everyplace, а db2 udb то же самый IL работает с точностью до наоборот. круто :)
3. тогда получается действительно ничего не блокируется и селект в начале читает данные на одно время а ближе к концу на другое и на выходе х@ня какя-то получается, очень полезная фишка :)

а для МФ и AS/400 один и тот же дб2 ?
и еще у ибм есть informix.

ggv
Во бред....
Тот же обсосаный со всех сторон TPC-C - полностью документированная бизнес-логика - и прекрасные результаты у блокировочника.
TPC-C конечно лучше чем ничего но где вы в ральной жизни видели настолько примитивную БЛ ?
к стате, у МС вроде появилось еще 2 результата в tpc-c нет ли у кого идей как вычисить в каком они режиме - snapshot или read commited ?

ggvYo!!
Я в реальной жизни вижу реальные работающие на DB2 системы.
Будем перечислять, или как?
По мне, так это бесполезное занятие.
Так что результаты совсем не ничего. А очень даже неплохие.
нет-нет, спасибо. на чистых OLPT задачах я вполне допускаю что у дб2 могут быть неплохие результаты :)

2Калина
борьба с дедлогами + читатели побыстрей проходят ... а небольшой +/- в отчетах - издержки производства :)

ggvи что интересно, в биллинговых системах отчеты делаются абсолютно точные, а не +/-
конечно делают, но на отдельном сервере, на OLPT серевере или с некислым +/- или с ущербом в скорости.

ggvкстати, по поводу отчетов и билинга - стандартная, можно сказать, обкатанная ситуация.
Бывают юизнес-запросы похуже, которые приходится разруливать, и вполне софт IBM справляется.
так давайте один раз разберемся а то парит по 3 раза одно и тоже обсасывать. давайте конкретную задачу - билинг, билинг чего там у вас ? давайте возьмем и посмотрим конкретно ваш билинг и посмотрим как надо проэктировать транзакции, а то я действительно не умею :(
итак ваше "решение" с IL cursor stability - сразу в сад, вы не получите консистентный отчет на этом уровне, merge и skip ункомитед в тот же сад т.к. проблему консистентности они не помогут решить. с нетерплением хочу услышать как я могу получить отчет в вашем билинге на момент запуска отчета, причем так чтоб OLPT транзакции не остановились на это время.

ЗЫ. только не надо велосипедов с timestamp в итоговых табличках, уже с ASCRUS их проходили.

2ggv
вы 3 дня что-то рассказывали про merge, scip uncommited и превосходство db2 перед mssql. теперь оказывается вся соль в проэкстировании, мы не могли бы хоть немного медленней менять позицию, а то я теряю мысл с такими переходами :(
мы вполне можем упростить билинг до минимума, пусть будет крупный сотовик с 3 табличками: звонки, клиент, платежи
как я могу получить консистентный отчет по этим табличкам в то время как идет непрерывный поток OLPT транзакций ?

в дагонку:
большинство транзакций в финансовой сфере делают мэйнфремы и кобол, кажется gartner не так давно утверждал. поэтому было бы глупо утверждать, что в банках только оракл.
в банке все достаточно просто - есть банковский день (как рассказывал ASCRUS) и это позволяет не гонять отчеты по OLPT системе. но мне все равно удивляет когда банковская система может окло часа переводить деньги на соседний счет в пределах одного банка ...