to Я и ёжик

В общем случае транзакция производит чтение, делает некий анализ, на основе которого формирует данные для записи.


Это уже из области выбора оптимистической или пессимистической блокировок. В других СУБД для экономии ресурсов при выборке часто делают сразу commit


Так что приходим к такому же эффекту, выбранные данные могут быть изменены кем то другим.

авторТолько читающая транзакция вырожденный случай, но и здесь шедулер должен позаботится о целостности полученных данных

позаботится о целостности полученных данных позволяет версионированние.

, т.е наша транзакция только читает, но она ведь не одна в базе?

Не одна, но она ничего не изменяет. Заботятся о наложении нужных блокировок те транзакции которые данные изменяют.

to NewYaer

Опять вы предодностие все так, как будто в Oracle невозможно предварительно выбрать данные на редактирование. Как я уже писала такая возможность есть.

Рассматривайте неблокирующее чтение тогда как возможность например сгенерить отчет не мешая блокировками другим сеансам, если вам так удобнее. В некоторых СУБД это делается с помощью dirty read, в Oracle с пом. версионирования.

to riman

Violina. Вы меня постоянно неправильно понимаете.

А я увидела иронию:) Наверное потому что философии у нас разные.

to all

Для разрядки обстановки. Еще раз повторюсь что не ставила целью "показать" что Oracle rulez или типа этого. Мне интересны особенности, плюсы и минусы тех или иных подходов в сравнении с DB2 и примеры, о чем я задаю вопросы. Не рассматривайте такие вопросы как наезд - в штыки. Пока что более или менее дускуссия удается. За других я отвечать не могу, просто хочу попросить не надо провокаций. А то скатимся как в сравнении СУБД

- База X рулит, база Y ацтой
... наезды и оскорбления
- потом примирительное: все базы хороши выбирай на вкус
- потом философское: базы они не плохие или хорошие, они другие

to gvv

I'd say it's too narrow. For me at leats. I don't need a database itself. As for me it's a part of a system. But definitelly for me it is not to have DB2 only to make a system. I understand DBAs could, probably, compare databases.


То что IBM предоставляет целый спектр продуктов а не только базу я в курсе. Замахиваться шире слишком ... - слишком уж обширно. Это все равно что сравнивать Oracle Database versus MS SQL plus operation system Windows. Ограничусь все таки соспостовлением БД.

Про пулы, спасибо за примеры и удачную аналогию:)

It's like with C pointers - the humanity divided on thwo parts - who understand a concept of pointers, and who do not. Let say I do not understand a concept of oracle pools, that's why I prefer dedicated pools for tables/indexes. I just from another part of humanity.

Здесь тоже соглашусь. Указатели часто ругали за то, что используя их можно натворить много бед, множественное наследование за возникновение парадоксов. А кому то предпочтительнее ручное управление выделением и осовобождением памяти. Но ИМХО не стоит запрещать или критиковать что-то только за то, что кто нибудь неумелый может изспользовать это неправильно и нанести вред.

Sometime I calculate exactly what part of a table I want to keep in a pool, knowing how many concurrent transaction I have , and how many rows they need to access.

А how many concurrent transaction выставляется на уровне пула?

to Я и ёжик

Чистый версионный механизм не требует блокировок вообще.

Я приводила гипотетический пример здесь

Оракл не 100% версионник. В 100% версионнике можно было бы действительно работать со своей версией данных сколь угодно без учета что происходит "снаружи" а о сюпризах узнавать только при коммите. Но такая реализация имеет интерес чисто теоретический. Так что сюрпризы из-за одновременного изменяющего доступа в одной и той же строке не откладываются до коммита а проявляются немендленно при возникновении конфликта.


По большоиму счету транзакция должна быть едина и неделима и должен иметь место и жизнь только один уровень изолированности транзакций - "serializable" всё остальное компромисы

Тогда бы базы были точно похожи:) Возможно каждая отличалась бы тем, на каком этапе юзер должен был конфронтировать с сюрпризами из за невозможности сериализации. Длинные транзакции были бы вообще немыслисмы.

всё остальное компромисы

Ну так мы придем опять к филосовской проблеме - одновременный доступ и целостность данных. Еще раз подчеркну, ведь в Oracle не отсутсвует такая возможность - предварительно заблокировать данные на редактирование. И есть возможность прочитать данные не блокируя и получить консистентный результат благодаря версионированию.

О том и речь, планировщик заданий на основе механизма версионирования. А еще об этом моог бы позаботится планировщик на основе блокировок, или механизм валидации транзакций, ила планировщик на основе временных штампов или и.т.д.

Мог бы и каждый со своими последствиями и выигрышами. Каждая СУБД выбрала свой метод.

to riman (для разгрузки)

Ну и активность у вас на форуме. Я уже успела набрать 1.92% от форума DB2. В Oracle у меня 3.32% - прям TPC-C какой-то. Если так дальше пойдет, то глядишь спецом по DB2 стану

to riman

Вот так и догоняет DB2 Oracle

Из за использования английских слов не понятны падежы. В общем интерпретация на усмотрение читающего:)

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

to Я и ёжик

Не может быть!!! :)

И вы туда же? Я это сказала не потому что якобы вы это не знаете. А подчеркнуть то, что эта возможность есть и есть дополнительная возможность выполнить select без блокировок. См. также аналогию с указателями - не стоить запрещать некую фичу только потому, что кто то может принести вред используя ее не по назначению.

Невозможности сериализации не бывает, она может достаться слишком дорогой ценой.

Для всех одновременных транзакций нет, если они "сцепились" за одни и теже данные. Кто то должен обломаться, иначе - потерянные изменения или строго последовательные изменения с ожиданиями.

автородновременный доступ и целостность данных.
Это не филосовская проблема

Философская я имела в виду в смысле неразрешимая в такой категорической постановке как ваша.

to gvv

I always wonder why people having many radius servers world-wide are trying to use a _direct_ access to a single database for AAA.... It has no reason. It has disadvantages only... I don\'t like to have several replicated servers in a such environment, one for each radius location either.

Ну это вы взяли крайние случаи реализации системы. Конкретнее сказать ничего не могу, возможно.

gvv>И сама база, используеться как и для OLTP (теже CDR) так и для BI? Как вообще со временем отклика?
>Или у Вас жесткое разограничение?
And OLTP, and DSS. DSS is for now just a set of predefined stat reports and invoice issuing. MDC tables are in use.

One more - the funny shit happens when a salesman tells "Wow, shit, I have forgoten to change the prices!!!" - and we have to recalculate existing calls.
Sometime cisco people do their \'experiments\' with buggy IOS - and again we have to recalculate existing calls, and not only recalculate, but can be even worse... The shit happens, and the system has to be designed to handle it.

Both of them calculated when a leg come to the system.

По этому поводу я уже высказывалась. Обычный метод применения summary tables (materialized views) в вашем случае MDC tables для разгрузки "горячих" таблиц со соответсующими соображениями - тратить ресурсы на их постоянное поддержание uptodate или позволить delay.

PS
Можно было тогда дать эту ссылку на мои вопросы вместо - It\'s not first time I see oracle dba think there are no any other rdbms except their favorite.
Gt. как привел ссылку на проблематику, а ваша была бы примером как она решается.

to Я и ежик

Почему такое неверие в людей?


см. вашу предыдущую фразу:)

Такова "се ля ви" кто то обламывается, кто то ждёт.


Именно поэтому. ИМХО такие крайности не всегда приемлемы, их стоит использовать только если это действительно требуется.