Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 8 9 10 [11] 12   вперед  Ctrl      все
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
Favn
оторванность данных от логики приводит к невозможности полноценно сопровождать код
Т.е. если static используется в PL/SQL - это великое благо, а если в Java/C - откат в 80-е? [/quot]
именно, вы поняли совершенно верно
при компиляции pl/sql со статик sql план по моему даже не создается, он создается лишь во время вызова процедуры и тогда он попадает в кеш планов, где он будет пересмотрен при итзменениях в статистике. оракл не отличает откуда попал этот план в кеш, из pl/sql или от клиента. это координально отличается от зашитого плана в пакет db2 который как глосит документация без RUNSTATS пересмотрен не будет.

Favn

3. По пакаджу строится план запроса на базе текущей схемы и статистики, кот. может быть впоследствии пересмотрен, в т.ч. автоматически.

документация и помнится garderman утверждают обратное:

Over time a database schema and data might change rendering the run time access plans sub-optimal. This can lead to degradation in application performance.

Favn
И я повторяю то же самое (fence - огораживать, ограждать, загораживать) :) Не огороженные - not fenced. Для C они работают, уговорили, в одном из процессов ядра, для Java - на той же JVM, кот. использует сервер. И в Оракле, думаю, они обращаются к буферам памяти, как и в DB2, а никак не к i/o процессам, например.

почитайте, что такое shared memory в linux, не нужно ничего придумывать ;)

Favn
О как - пришлось-таки бедненьким. А я-то всегда считал, что тред-архитектура прогрессивнее многопроцессной - как минимум за счет отсутствия переключений контекста :)

в теории, на практике *nix процессы по прежнему быстрей, а в линухе они еще и откровенно не доделаны.

Favn

Я уверен, что официально для Express-C фикспаков нет вообще - она unsupported. Но от Express она отличается только файлом лицензии, и фиксы от Express на нее прекрасно встают. И это не хак - Express-C продолжает работать под собственной лицензией (что подтверждает IBM License Manager), Express-ом она от этого не становится, и я не видел в тексте лицензий прямого запрета эти фикпаки накатывать.

а помоему типичный хак. урл все таки можно, фикс там точно на express ?
6 июн 08, 14:35    [5770794]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
именно, вы поняли совершенно верно
при компиляции pl/sql со статик sql план по моему даже не создается, он создается лишь во время вызова процедуры и тогда он попадает в кеш планов, где он будет пересмотрен при итзменениях в статистике. оракл не отличает откуда попал этот план в кеш, из pl/sql или от клиента. это координально отличается от зашитого плана в пакет db2 который как глосит документация без RUNSTATS пересмотрен не будет.
Без runstat, т.е. до очередного обновления статистики, планы не пересматривает никто, ибо незачем :) Runstat в DB2 при автоуправлении, на минуточку, выполняется автоматически в фоновом режиме, серверу можно просто рекомендовать делать это в нужное время с нужной периодичностью. Кстати, в DB2 кеш планов для динамического SQL используется как в Оракле. А вот поведением планов static SQL можно управлять:

REOPT
Specifies whether to have DB2 determine an access path at run time using values for host variables, parameter markers, and special registers. Valid values are:
NONE
The access path for a given SQL statement containing host variables, parameter markers, or special registers will not be optimized using real values. The default estimates for the these variables is used, and the plan is cached and will be used subsequently. This is the default value.
ONCE
The access path for a given SQL statement will be optimized using the real values of the host variables, parameter markers, or special registers when the query is first executed. This plan is cached and used subsequently.
ALWAYS
The access path for a given SQL statement will always be compiled and reoptimized using the values of the host variables, parameter markers, or special registers that are known each time the query is executed.

Т.к. special registers в т.ч. отображают и сбор статистики, можно сделать план пакаджа неизменным до следующего rebind (ручного или периодического по шедулеру), создать его при 1-м вызове программы или сделать динамическим, точно как в Оракл. И где тут 80-е? :)

Yo.!
Over time a database schema and data might change rendering the run time access plans sub-optimal. This can lead to degradation in application performance.
Сие есть просто рекомендация не забывать о runstat, если он не в автомате или если автомат настроен его делать редко, и пересоздавать пакаджи после runstat, если необходимо (они не с reop always). Кстати, обновить ВСЕ пакаджи можно всего одним словом - db2rbind. То же можно делать (хоть все, хоть часть, выбрав их и их зависимости из системных таблиц) из SQL процедурой или из C через API.

Yo.!
процессы обращаются напрямую в один кусок памяти SGA через shared memory (в Linux)
почитайте, что такое shared memory в linux, не нужно ничего придумывать ;)
Я в курсе, что такое shared memory, но не знаю, что именно входит в Oracle System Global Area. :) В любом случае, даже если DB2 not fenced добавляют лишние копирование небольшого куска памяти - результата выборки (что врядли, т.к. иначе они не могли бы портить data buffers, опасность чего есть согласно документации), это не сильно повлиет на производительность.

Favn
в теории, на практике *nix процессы по прежнему быстрей, а в линухе они еще и откровенно не доделаны.
Думаю, раз IBM ими воспользовалась, с ее-то опытом поддержки Linux на всем, что движется - они таки наконец доделаны :) Кстати, одним из плюсов 9.5. отн. 9.1 IBM называет лучшую производительность и использование памяти именно под Linux и именно за счет тредов.

Favn
а помоему типичный хак. урл все таки можно, фикс там точно на express ?

вот тут 32bit под Win, например, файл v9fp5_win_exp.exe, именно под Express 9, 30/05/2008.
6 июн 08, 16:26    [5771893]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
У меня есть смутные воспоминания, что перестройка package блокирует что-то - т.е. её нельзя сделать пока кто-то этот пкет использует. Я прав?

Есть ещё у меня ИМХО по поводу оптимизатора DB2 - он до такой степени мудрый, что очень тормозной и его лишний раз стараются не дёргать. У Оракла более быстрая реализация оптимизатора и он может себе позволить дёргать его по любому поводу. Они его обкатывают с версии 7.0, а в DB2 он относительно недавно.

Кстати, до сих пор в DB2/400 нет полной реализации оптимизатора по стоимости. Я помню он сваливался в rule-based , если ему всетречался оператор UNION. Они, конечно, исправляются, но я считаю, что это является очень показательным индикатором ещё некоторой сырости их кода. Потому и медленный ещё.

--
Per rectum ad astrum
6 июн 08, 20:41    [5773366]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
Favn

Т.к. special registers в т.ч. отображают и сбор статистики, можно сделать план пакаджа неизменным до следующего rebind (ручного или периодического по шедулеру), создать его при 1-м вызове программы или сделать динамическим, точно как в Оракл. И где тут 80-е? :)

значит runstat ранстат только собирает статистику, а чтоб пересмотрелся план я должен сам запускать ребинд. у меня тысячи процедур, десятки тысяч запросов с какой переодичностью я должен настроить шедулер, чтоб иметь актуальные планы ? что произойдет с потреблением CPU на сервере который пересматривает десятки тысяч планов ? при ребинде процедура доступна пользователю ?

Favn

Я в курсе, что такое shared memory, но не знаю, что именно входит в Oracle System Global Area. :) В любом случае, даже если DB2 not fenced добавляют лишние копирование небольшого куска памяти - результата выборки (что врядли, т.к. иначе они не могли бы портить data buffers, опасность чего есть согласно документации), это не сильно повлиет на производительность.


если бы not fenced могла бы лазить в область ядра и его буфера, это была бы чудовищная дыра в безопасности, выходит, что юзерский код на С мог бы портачить в области других баз данных запущенных на сервере. вот нашел чуть больше пояснения

These risky stored procedures are those created as not fenced. For a not-fenced stored procedure, nothing separates the stored procedure from the database control structures that the database agent uses. If a DBA wants to ensure that the stored procedure operations will not accidentally or maliciously damage the database control structures, the not fenced option is omitted. Because of the risk of damaging your database, use not fenced stored procedures only when you need the maximum possible performance benefits. In addition, make absolutely sure that the procedure is well coded and has been thoroughly tested before allowing it to run as a not-fenced stored procedure. If a fatal error occurs while running a not-fenced stored procedure, the database manager determines whether the error occurred in the application or database manager code and performs the appropriate recovery.

...

During the execution of a procedure, every time control flows from the procedural logic to an SQL statement, there is a ″context switch″ between the DLL and the DB2 engine. As of DB2 Version 8.1, SQL procedures run in ″unfenced mode″. That is they run in the same addressing space as the DB2 engine. Therefore the context switch we refer to here is not a full context switch at the operating system level, but rather a change of layer within DB2. Reducing the number of context switches in procedures that are invoked very often, such as procedures in an OLTP application, or that process large numbers of rows, such as procedures that perform data cleansing, can have a noticeable impact on their performance.

ftp://ftp.software.ibm.com/ps/products/db2/info/vr95/pdf/en_US/db2d3e951.pdf

у меня так и остается стойкое ощущение инородности этих процедур, и до боли напоминает оракл до появления PL/SQL, у него тоже процедуры были на С, Cobol и т.п. аналоги not fenced их точно также приходилось бэкапить отдельно, там тоже была борьба с опасным кодом, котрый валил весь сервер и прочие прелести. со стороны выглядит что SQL-PL и был введен для решения этих проблем.
к стате на счет java - если у нас для процедуры запускаются отдельные процессы, не получится ли что для каждой сессии стартует своя jvm ?
7 июн 08, 13:28    [5775566]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
Anton Demidov
У меня есть смутные воспоминания, что перестройка package блокирует что-то - т.е. её нельзя сделать пока кто-то этот пкет использует. Я прав?

Перестройка блокирует записи системных таблиц, в которых сам пакдж и его связи описаны.

...performance of REBIND is significantly better than that of BIND...
REBIND does not automatically commit the transaction following a successful rebind. The user must explicitly commit the transaction.
If REBIND is executed on a package that is in use by another user, the rebind will not occur until the other user's logical unit of work ends, because an exclusive lock is held on the package's record in the SYSCAT.PACKAGES system catalog table during the rebind.
When REBIND is executed, the database manager recreates the package from the SQL statements stored in the SYSCAT.STATEMENTS system catalog table.

Обычная блокировка, REBIND выполняется внутри тразакции, можно откатить. Если пакадж используется, rebind подождет завершения транзакций, выполнится, следующие после его commit пойдут с обновленным pakage. Я на лету запускал, проблем не видел.

Anton Demidov
Есть ещё у меня ИМХО по поводу оптимизатора DB2 - он до такой степени мудрый, что очень тормозной и его лишний раз стараются не дёргать. У Оракла более быстрая реализация оптимизатора и он может себе позволить дёргать его по любому поводу. Они его обкатывают с версии 7.0, а в DB2 он относительно недавно.
Кстати, до сих пор в DB2/400 нет полной реализации оптимизатора по стоимости.
Относительно недавно - это сколько? Точных данных у меня нет, но в 7-ке LUW cost-based точно был, такой же настраиваемый, лет 8-10 назад. И как это можно не дергать оптимизатор, выполняя SQL? :)
По скорости - оптимизатор такой мудрый, что настраиваемый :) По умоланию используется 5-й левел из 10, вполне быстрый. 10-й пытается полностью переписать исходный SQL, что дольше, поэтому удобно, например, использовать например 5-й для dinamic и 10-й для static SQL.
По поводу DB2/400 не скажу ничего - работал только с LUW.
7 июн 08, 14:37    [5776075]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
значит runstat ранстат только собирает статистику, а чтоб пересмотрелся план я должен сам запускать ребинд. у меня тысячи процедур, десятки тысяч запросов с какой переодичностью я должен настроить шедулер, чтоб иметь актуальные планы ? что произойдет с потреблением CPU на сервере который пересматривает десятки тысяч планов ? при ребинде процедура доступна пользователю?
Тысячи процедур, выполняющих внешние отн. БД дейсвтия?! Вроде уже договорились, что для остальных Java не нужна, SQL-PL для бизнес-логики (не логики приложений) волне достаточно.
С потреблением CPU произойдет то же, что и в Оракле, и в DB2 при динамической оптимизации, смысл действия тот же. Но статическую можно выполнить во время низкой загрузки, можно написать reopt ones - оптимизатор сработает при первом выполнении SP в ее транзакции, а можно - reopt always (в т.ч. при очередном rebind) и о rebind забыть совсем, как в dinamic SQL.
По поводу пользователей - уже написал, это простое обновление ситемной таблицы, выполняется внутри обычной транзакции.

Yo.!
если бы not fenced могла бы лазить в область ядра и его буфера, это была бы чудовищная дыра в безопасности, выходит, что юзерский код на С мог бы портачить в области других баз данных запущенных на сервере.
nothing separates the stored procedure from the database control structures that the database agent uses
у меня так и остается стойкое ощущение инородности этих процедур, и до боли напоминает оракл до появления PL/SQL, у него тоже процедуры были на С, Cobol и т.п. аналоги not fenced их точно также приходилось бэкапить отдельно, там тоже была борьба с опасным кодом, котрый валил весь сервер и прочие прелести. со стороны выглядит что SQL-PL и был введен для решения этих проблем.
Как следует из этого текста, к самой БД и тем более к другим БД not fenced никакого отношения не имеет. "database agent" - модуль работы с коннектами к БД, на целостность самой БД не влияет никак, а для SP на Java и он не доступен. Срашно его загубить (или прибить JVM сервера в случае Java, что куда сложнее) - используй fenced, в чем проблема? Нужна макс. производительность - пиши/отлаживай тщательнее. Мне DB2 нравиться как раз за богатство выбора способов работы с ней.
PL-SQL, как я понимаю, был введен для простой реализации как раз бизнес-логики, а не логики приложений. Его функциональности для этого вполне достаточно. А "стойкое ощущение инородности" по отн. к DB2 естественно для сторонника Oracle :)
Отдельный бэкап - да, но опять-таки, мы говорим о внешних отн. БД действиях, на целостность БД они не влияют. А к процедуре бэкапа можно прикрутить внешние действия.

Yo.!
к стате на счет java - если у нас для процедуры запускаются отдельные процессы, не получится ли что для каждой сессии стартует своя jvm?
Not fenced Java работают на JVM, c кот. работает сервер, и напортачить в самом сервере у них шансов никаких (он все-таки не на яве работает :) ). Под fenced Java запукается отдельная JVM, по-моему одна на всех, могу ошибаться, но уж точно не по JVM на процедуру. :)
7 июн 08, 15:10    [5776315]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
Favn
Not fenced Java работают на JVM, c кот. работает сервер, и напортачить в самом сервере у них шансов никаких (он все-таки не на яве работает :) ). Под fenced Java запукается отдельная JVM, по-моему одна на всех, могу ошибаться, но уж точно не по JVM на процедуру. :)

и снова вы что-то путаете:
NOT FENCED Java routines are currently not supported. A Java routine defined as NOT FENCED will be invoked as if it had been defined as FENCED THREADSAFE.

Favn
Вроде уже договорились, что для остальных Java не нужна, SQL-PL для бизнес-логики (не логики приложений) волне достаточно.

ну раз договорились

Favn

С потреблением CPU произойдет то же, что и в Оракле, и в DB2 при динамической оптимизации, смысл действия тот же. Но статическую можно выполнить во время низкой загрузки, можно написать reopt ones - оптимизатор сработает при первом выполнении SP в ее транзакции, а можно - reopt always (в т.ч. при очередном rebind) и о rebind забыть совсем, как в dinamic SQL.

с точки зрения ребинда различий, как я выснил, внешних процедур и SQL-PL нет. но на оракл, совсем не похоже, в где при изменении данных от которых зависит план (читай статистики), такой план выкидывается из кеша и соответсвенно будет обновлен. в дб2 reopt alweys (на OLTP убьет производительность) и ребинд по шедулеру ВСЕХ запросов - звучат не очень заманчиво.
8 июн 08, 20:32    [5779094]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
Favn
Not fenced Java работают на JVM, c кот. работает сервер, и напортачить в самом сервере у них шансов никаких (он все-таки не на яве работает :) ). Под fenced Java запукается отдельная JVM, по-моему одна на всех, могу ошибаться, но уж точно не по JVM на процедуру. :)

и снова вы что-то путаете:
NOT FENCED Java routines are currently not supported. A Java routine defined as NOT FENCED will be invoked as if it had been defined as FENCED THREADSAFE.
Да нет, "снова" что-то напутали Вы. В переводе сие означает, что NOT FENCED и FENCED THREADSAFE для LANGUAGE JAVA просто синонимы. Там же несколькими строками выше:
Multiple invocations of FENCED THREADSAFE routines share resources, and therefore incur less system overhead than FENCED NOT THREADSAFE routines, which each run in their own dedicated process.
Т.е. если принять NOT FENCED как FENCED THREADSAFE, что то же самое, а FENCED как FENCED NOT THREADSAFE, получится ровно то , о чем писал я, не вдаваясь в такие подробности - первые выполняются на общей JVM, вторые - нет.
Favn
ну раз договорились
Я не прав? Можно придумать жизненный пример, для которого для бизнес-логики SQL + SQL-PL недостаточно?
Yo.!
с точки зрения ребинда различий, как я выснил, внешних процедур и SQL-PL нет. но на оракл, совсем не похоже, в где при изменении данных от которых зависит план (читай статистики), такой план выкидывается из кеша и соответсвенно будет обновлен. в дб2 reopt alweys (на OLTP убьет производительность) и ребинд по шедулеру ВСЕХ запросов - звучат не очень заманчиво.
Почему это reopt alweys на OLTP убьет производительность? Не следует считать оптимизатор DB2 тупее Оракловского. Зачем пересчитывать план от вызова к вызову, если статистика не менялась? А если изменилась - план пересчитает любая СУБД.
Наоборот, при OLTP reopt none/ones позволяет переместить нагрузку по пересчету планов на время простоя или первой активности, а не грузить сервер в час пик.
9 июн 08, 14:19    [5782123]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
Favn
Да нет, "снова" что-то напутали Вы. В переводе сие означает, что NOT FENCED и FENCED THREADSAFE для LANGUAGE JAVA просто синонимы. Там же несколькими строками выше:
Multiple invocations of FENCED THREADSAFE routines share resources, and therefore incur less system overhead than FENCED NOT THREADSAFE routines, which each run in their own dedicated process.
Т.е. если принять NOT FENCED как FENCED THREADSAFE, что то же самое, а FENCED как FENCED NOT THREADSAFE, получится ровно то , о чем писал я, не вдаваясь в такие подробности - первые выполняются на общей JVM, вторые - нет.

давайте я вам переведу, что там написано на самом деле. NOT FENCED не супортиться в принципе, т.е. jvm запустить в адресном пространстве даже агента не возможно. NOT FENCED интерпритируется как FENCED THREADSAFE и запускается как отгороженный от агента и естественно ядра db2 процесс.

Favn

Почему это reopt alweys на OLTP убьет производительность? Не следует считать оптимизатор DB2 тупее Оракловского. Зачем пересчитывать план от вызова к вызову, если статистика не менялась? А если изменилась - план пересчитает любая СУБД.

можно поитересоватся как вы перевели эту фразу "will always be compiled and reoptimized using the values of the host variables" ?


Наоборот, при OLTP reopt none/ones позволяет переместить нагрузку по пересчету планов на время простоя или первой активности, а не грузить сервер в час пик.[/quot]
9 июн 08, 14:45    [5782317]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
давайте я вам переведу, что там написано на самом деле. NOT FENCED не супортиться в принципе, т.е. jvm запустить в адресном пространстве даже агента не возможно. NOT FENCED интерпритируется как FENCED THREADSAFE и запускается как отгороженный от агента и естественно ядра db2 процесс.
Большое человеческое спасибо за перевод! :) И я писал то же самое, в каждом посте разделяя SP на Java и на C:
"Для C они работают, уговорили, в одном из процессов ядра, для Java - на той же JVM, кот. использует сервер."
"Not fenced Java работают на JVM, c кот. работает сервер, и напортачить в самом сервере у них шансов никаких (он все-таки не на яве работает :) )."
И как вообще Java может работать в том же процессе, что и ядро? Естественно, что байт-код Java отгорожен от исполняемого кода сервера, как иначе? Но - все Java FENCED THREADSAFE выполняются на одной JVM, накладных расходов на ее запуск нет.

Yo.!
можно поитересоватся как вы перевели эту фразу "will always be compiled and reoptimized using the values of the host variables" ?
В данном контексте - план может быть персчитан при каждом вызове в зависимости в т.ч. от входных параметров, т.е. при каждом вызове проверяется такая необходимость. А может и не быть пересчитан, что естественно - как для любого dynamic запроса. А Оракл не может по необходимости пересчитывать план в зависимости от параметров? Не следует по куску фразы из раздела не связанного с собственно оптимизацией судить о работе сложной системы.
9 июн 08, 16:02    [5783013]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
Favn
Большое человеческое спасибо за перевод! :) И я писал то же самое, в каждом посте разделяя SP на Java и на C

ну ... например тут вы утверждаете, что Java работает в ядре:
Favn
Yo.!
не понял, с каких пор процедуры на C++ и Java начали работать внутри ядра db2 ?? для C только пару лет назад компилятор в поставку начали класть. и некий db2 magazine утверждал обратное (в чудо-документации мне ничего на эту тему найти не удалось).
Для C как минимум с тех пор, как я стал с DB2 работать (v. 7 лет так с 10 назад), для Java - когда ее native поддержку включили в DB2.


по оптимизатору
Favn
В данном контексте - план может быть персчитан при каждом вызове в зависимости в т.ч. от входных параметров, т.е. при каждом вызове проверяется такая необходимость. А может и не быть пересчитан, что естественно - как для любого dynamic запроса.

url можно ? а то как я не полезу за подробностями, выясняется ровно обратное ;)
9 июн 08, 18:33    [5784255]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
2 Yo!
А теперь попробуйте сосредоточиться Вы, а то после "разжувывания" получилась полная каша. Отделяю мух от котлет.

Yo.!
я бы хотел посмотрел как бы вы процедуры собраные компилятором AIX собрали бы GCC под виндой
Из приведенного мной текста (см. ниже) видно, что до 11g, то есть до недавнего времени, в Оракл при native compilation было то же самое. 7-8 лет - большой срок, давайте смотреть на текущие версии.

Yo.!
not fenced исполняются в адресном пространстве агента, а не ядра субд db2.
not fenced процедура db2 из процесса агента, судя по документации общается с ядром через некий API
Полный бред. Исполняются, а не получают данные там же. Про "некий API" там не слова. Более того:
Memory allocation in DB2
"Database global memory is used across all applications that connect to the database:
- Buffer pools (using the ALTER BUFFERPOOL DDL statement)
- Database heap (including log buffers)
- Utility heap
- Package cache..."
Database manager shared memory
Не стоит считать, что о shared memory знают только в Оракл.
Кстати, о якобы не кешируемом embedded SQL
Package cache
"This parameter is allocated out of the database shared memory, and is used for caching of sections for static and dynamic SQL and XQuery statements on a database." Т.е. static, dinamic и даже XML кешируются одинаково.

Yo.!
а вот в DB2 этот дедовские способ написания по прежнему используется в большинстве проэктов
Ваши любимые слова - "а ссылку можно?" Как можно говорить о проектах DB2, не зная ни одного?
Я на своем опыте могу сказать, что бизнес-логика имплементируется по возможности в триггеры и UDF, которые в DB2 просто подставляются inline в запросы и оптимизируются в рамках единого текста, который, кстати, может быть переписан оптимизатором. А в Оракл, оказывается, они компилячаться при создании A trigger is fully compiled when the CREATE TRIGGER statement executes. И какой подход является прошлым веком? :)
Опять-таки, SQL PL есть уже давно и если нужна поцедурность (которой чем меньше, тем лучше), то для бизнес-логики его более чем достаточно.

Yo.!
когда-то наверно c начала 80х и у оракла и у db2 были примерно одинаковые технологии написания бизнес логики, в оракле они звались PRO*C и PRO*COBOL, в конце 80х, начала 90х эту технологию в оракле (и остальных субд) вытеснил язык (интерпритатор) 4го поколения PL/SQL, а вот в DB2 этот дедовские способ написания по прежнему используется в большинстве проэктов, т.к. аналог SQL/PL появился всего 7-8 лет назад и по прежнему сильно уступает PL/SQL. PL/SQL это интерпритатор, к которому в последних версиях прикрутили возможность компилировать в нативный байт-код.
Да, и до 11g это делалось внешним, покпаемом за отдельные деньги C-компилятором.
PL/SQL Enhancements in Oracle Database 11g
"This scheme worked perfectly well from a technical viewpoint but suffered from some serious usability drawbacks: some customers’ religion simply forbids the installation of a C compiler on a production machine (and you can’t argue with that); other customers were reluctant to pay to license a C compiler (and for some reason mistrusted gcc); and other customers found the DBA setup tasks (installing the C compiler, checking the spnc_commands file on the plsql directory under Oracle Home, and setting the Plsql_Native_Library_Dir and Plsql_Native_Library_Subdir_Count parameters) too daunting."
Начало 80-х, говорите?

Yo.!
процедура PL/SQL в отличии от not fenced процедуры DB2 исполняется в адресном пространстве юзерского процесса, лезет в shared memory SGA и выполняет защищенный код. т.е. от того, что теперь можно скомпилить в нативный байт код, он не стал больше походить на низкоуровневые процедуры С у db2, нативный байт код PL/SQL по прежнему защищен и в отличии от not fenced процедур db2, ошибки в них при всем желании не могут завалить весь сервер.

Конечно, "исполняется в адресном пространстве юзерского процесса" в корне отличается от "исполняются в адресном пространстве агента" (цитаты) В DB2 он так же "лезет в shared memory" за данными и "завалить весь сервер" у него шансов никаких - только агента, связанного с эти коннектом (см. схему Database manager shared memory выше). Как и в Оракл, судя по Вашим словам.

Кстати, о старых технологиях. В том же документе очень умилило нововведение
"PERFORMANCE LANGUAGE FEATURE: THE PL/SQL FUNCTION RESULT CACHE"
Круто! Аналог давно существующий в DB2 Package cache наконец-то и в Оракл! Правда, чтобы его использовать, опять нужны хинты (ну куда в Оракл без них!)
"function f(p1 in Typ_1, p2 in Typ_2,...) return Typ_R
result_cache relies_on(Tab_1, Tab_2, Tab_3,...)..."
Сам он понять какие таблицы использует функция, видимо, не способен.

2All, not 2 Yo!
Прошу понять правильно - я ни коим образом не охаиваю Оракл, в котором не разбираюсь (как и Yo! в DB2). Я показываю Yo!, как можно использовать его же полемические приемы.
26 июн 08, 17:56    [5854444]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
ОК, продолжим тут
Favn

Из приведенного мной текста (см. ниже) видно, что до 11g, то есть до недавнего времени, в Оракл при native compilation было то же самое. 7-8 лет - большой срок, давайте смотреть на текущие версии.

ппц. написав C процедуру для db2 под виндой ее НЕ ВОЗМОЖНО перенести в продакшен на AIX, нужно тащить компилятор с винды на AIX и там компилировать. и только в последних версиях С компилятор начали поставлять вместе с db2.
PL/SQL это интерпритатор и компилирует в байткод который исполняет и контролирует виртуальная машина, я могу разрабатывать под виндой и без гемороя деплоить на zOS. я доступно объясняю ? ничего за собой таскать не нужно. теперь сосредоточесь - в последних версиях появилась дополнительная фича натив компилирования. если это так сложно для понимания, забудьте, считайте нет такой фичи и небыло. считайте весь PL/SQL компилируется в платформонезависимый байткод, а то мы никуда не продвинемся.

Favn

Полный бред. Исполняются, а не получают данные там же. Про "некий API" там не слова.

браво, после нескольких недель вам все же удалось разъясняющий документ, а мы все гадали. ;)
про API вычитал тут

A coordinator agent works on behalf of an application, and communicates to other agents, using private memory, interprocess communication (IPC), or remote communication protocols, as needed.

(к стате о чудной документации, я например, решил что IPC используется для общения агента с other agents т.е. субагентами)

Favn

Конечно, "исполняется в адресном пространстве юзерского процесса" в корне отличается от "исполняются в адресном пространстве агента" (цитаты) В DB2 он так же "лезет в shared memory" за данными и "завалить весь сервер" у него шансов никаких - только агента, связанного с эти коннектом (см. схему Database manager shared memory выше). Как и в Оракл, судя по Вашим словам.


чтож давайте подведем итог:
оракловый аналог not fenced процедур - PRO*COBOL, PRO*C и прочие технологии из 80х, уступили дорогу языкам сторед процедур, таким как T-SQL, PL/SQL (и только в db2 SQL/PL и не вытеснил C). почему из 80х вроде уже 2 раза объяснял.

оракловый аналог fenced процедур - наверно тупо внешнее приложение обращающее к субд через OCI. тут сразу вопрос это именно fenced используют remote communication protocols ?

остается молоденький SQL/PL против матерого PL/SQL.

Favn

Круто! Аналог давно существующий в DB2 Package cache наконец-то и в Оракл!

гы действительно созвучно!

ЗЫ. Россия вперед !
26 июн 08, 22:49    [5855283]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
ппм
Guest
agent использует remote communication protocol для связи с другими агентами в случае DPF, и в статье это указано.
27 июн 08, 12:35    [5857476]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
ппц. написав C процедуру для db2 под виндой ее НЕ ВОЗМОЖНО перенести в продакшен на AIX, нужно тащить компилятор с винды на AIX и там компилировать. и только в последних версиях С компилятор начали поставлять вместе с db2.
Вот именно, ппц. Насколько знаю я, C-компилер никогда не входил в поставку. Где Вы прочитали, что C компилятор поставляется вместе с DB2? Можно ссылку?
Но ппц не в этом, а вот в чем :)
Не надо сваливать в единый винегрет SP на C и Java и SP на SQL PL. Более того, не надо смешивать бизнес-логику и SP. В DB2 есть 2 SQL-PL:
1. Для триггеров и SQL UDF (подмножество SQL-PL). Отдельно он не компилируется, в отличие от Оракл, его тест - это синтаксически проверенная inline подстановка. Компилируется он вместе с использующим его запросом, как единый текст, соответственно лучше оптимизируется. К C и Java все это не имеет и никогда не имело никакого отношения.
2. Для SP. Он был и в 7-й версии, SP можно было писать. Но тогда он автоматически генерировался в C-ник и компилячился на сервере внешним платформозависимым C-компилером, который достаточно было просто поставить на сервер. Управлял этим пооцессом сервер, сборка шла автоматически. То есть точно так же, как в Оракле 9-10 для нативной компиляции. С 8-й версии появился интерпретоатор.

Yo.!
PL/SQL это интерпритатор и компилирует в байткод который исполняет и контролирует виртуальная машина
Да что вы? Какая неожиданность :) Цитирую повторно:
"PL/SQL is compiled in the ordinary way into machine code called M-Code. However, the target machine is virtual: the so-called PVM — for PL/SQL virtual machine. (In this way, it’s just like Java with its JVM.)... the number of context switches between PL/SQL’s execution environment and SQL’s execution environment"
Т.е PVM работает аналогично JVM, являсь для собственно "SQL’s execution environment" внешним процессом - выглядит как аналог JAVA FENCED THREADSAFE в DB2 :). Конечно, при высокой нагрузке это приводит к проблемам с производительностью.

Yo.!
я могу разрабатывать под виндой и без гемороя деплоить на zOS. я доступно объясняю ? теперь сосредоточесь - в последних версиях появилась дополнительная фича натив компилирования. если это так сложно для понимания, забудьте, считайте нет такой фичи и небыло. считайте весь PL/SQL компилируется в платформонезависимый байткод, а то мы никуда не продвинемся.
Теперь попробуйте сосредоточиться сами, объясню 2-й раз, для понимания не сложно. Или хотя бы попробуйте сменить тон в разговоре.
Считать можно что угодно, факты таковы.
1. inline SQL PL для собственно бизнес логики был всегда. Он ограничен из-за требований inline подстановки, по той же причине он максимально быстрый и оптимизируемый.
2. SQL PL для SP появился первоначально в виде native компиляции (до 8.2), сейчас он интерпретатор (точнее, псевдокомпилятор, как в Оракл). Замечу для галочки, что хотя он и беднее, он исполняется в ядре (EDU, engine dispatchable unit), а не в отдельном процессе (PVM). Разница в производительности понятна? :)
3. До 8.2 при переходе на новую платформу достаточно было автоматической перекомпиляции. 8 лет назад это стало не нужно. забудьте, считайте, что этого небыло :)
4. В Оракл PL/SQL появился как псевдокомпилятор. В связи с высокой на него нагрузкой в Оракл-разработках появились видимо проблемы с производительностью PVM, поэтому в 9-ке появилась native опция, до боли похожая на старую DB2 (тот же внешний C-компилятор). В 11-ке native компилятор сделали встоенным, что показывает таки его необходимость с точки зрения Оракл.

Yo.!
браво, после нескольких недель вам все же удалось разъясняющий документ...
(к стате о чудной документации, я например, решил что IPC используется для общения агента с other agents т.е. субагентами)
Просто я наконец этим озаботился. В "сложнейшей" документации оказалось достаточно набрать в поиске "shared memory" и прочитать страниц так 5.

Yo.!
чтож давайте подведем итог:
оракловый аналог not fenced процедур - PRO*COBOL, PRO*C и прочие технологии из 80х, уступили дорогу языкам сторед процедур, таким как T-SQL, PL/SQL (и только в db2 SQL/PL и не вытеснил C).
Опять мухи вместе с котлетами!
1. PRO*COBOL, PRO*C и "прочие технологии из 80х" - аналог embedded SQL, а совсем не not fenced. Или PRO*C-программы работали внутри серверного агента? :) Кстати, эти "технологии из 80х" зачем-то включили в новый Java в виде SQLJ. Отсталые люди, и ведь не из IBM...
2. Зачем SQL/PL вытеснять C? У них совершенно разные задачи! SQL-PL - для манипуляций с данными, C и Java - для внешних отн. БД действий, связанных с данными, посылка почты, например. Есть предложение вернуться из далекого прошлого - SP для бизнес-логики на C никто не пишет уже много лет, да и раньше, учитывая inline SQL-PL и богатый SQL, для внутренних задач БД они были практически не нужны.

Yo.!
оракловый аналог fenced процедур - наверно тупо внешнее приложение обращающее к субд через OCI. тут сразу вопрос это именно fenced используют remote communication protocols ?
Не надо предположений - аналогов-то нет. Fenced C работают под управлении отдельных процессов db2fmp (на той же схеме, слева от Firewall). Общаются без communication protocols, локально. Как, кстати, и любое приложение с локальным коннектом.

Yo.!
остается молоденький SQL/PL против матерого PL/SQL.
Да. Сравнительно молодой, быстрый, работающий inline или в ядре, заточенный под максимальную производительность SQL-PL против PL/SQL, ну просто матерого. :)

Yo.!
ЗЫ. Россия вперед !
Увы!
27 июн 08, 16:04    [5858959]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
Favn
Вот именно, ппц. Насколько знаю я, C-компилер никогда не входил в поставку. Где Вы прочитали, что C компилятор поставляется вместе с DB2? Можно ссылку?

тысячи извинений , действительно гемор с тасканием компилера (для не sql pl процедур) по прежнему актуален. меня ввел в заблуждение sql/pl, которому с 8.2 (2004 год) не нужен внешний компилер, я решил, что компилер класть начали.

Favn

1. Для триггеров и SQL UDF (подмножество SQL-PL). Отдельно он не компилируется, в отличие от Оракл, его тест - это синтаксически проверенная inline подстановка. Компилируется он вместе с использующим его запросом, как единый текст, соответственно лучше оптимизируется. К C и Java все это не имеет и никогда не имело никакого отношения.

неправда.
UDFs can be developed in high-level languages, such as C or Java. Starting with DB2 UDB 7.2, UDFs can also be developed in DB2 SQL. The primary advantage of the SQL-based UDFs is that, unlike their high-level language counterparts, they can contain regular SQL statements to read the tables. As of DB2 UDB 7.2, UDFs in the high-level languages cannot read tables.
http://www.ibm.com/developerworks/db2/library/techarticle/0203venigalla/0203venigalla.html
т.е. до 2002 года компиляция UDF на низкоуровневом языке и инсталяция внешнего компилера был вообще единственным вариантом. (повторюсь в оракле подобная бредятена отмерла в конце 80х, на 20 лет раньше).

Favn

2. Для SP. Он был и в 7-й версии, SP можно было писать. Но тогда он автоматически генерировался в C-ник и компилячился на сервере внешним платформозависимым C-компилером, который достаточно было просто поставить на сервер. Управлял этим пооцессом сервер, сборка шла автоматически. То есть точно так же, как в Оракле 9-10 для нативной компиляции. С 8-й версии появился интерпретоатор.

ничего похожего на нативную компиляцию pl/sql - в оракле с конца 80х никто не требует таскать за собой компилятор, с 80х UDF на pl/sql с одной платформы одним движением переносится на другую платформу. в db2 же надобность таскать за собой компилятор для sql/pl буквально пару лет назад (с версии 8.2 от 2004 года). нативная компиляция pl/sql - для маньков пытающихся выжать из процедурного кода еще 2-3% скорости.

Favn

Т.е PVM работает аналогично JVM, являсь для собственно "SQL’s execution environment" внешним процессом - выглядит как аналог JAVA FENCED THREADSAFE в DB2 :). Конечно, при высокой нагрузке это приводит к проблемам с производительностью.

fenced java в db2 запускается в своем процессе и по "remote communication protocol" общается с посредником agent который в свою очередь общяется уже с shared memory структурами db2. это нифига не похоже на java stored procedures, pl/sql и PRO*C/PRO*COBOL которые исполняются в "user process" оракла и минуя посредников работают с shared memory SGA:

oracle docs
Overview of User Processes
When a user runs an application program (such as a Pro*C program) or an Oracle tool (such as Enterprise Manager or SQL*Plus), Oracle creates a user process to run the user's application.

вот тут и картинка есть ;)
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/process.htm#i7241

Favn

Считать можно что угодно, факты таковы.
1. inline SQL PL для собственно бизнес логики был всегда.

снова неправда, sql/pl на фоне T-SQL и PL/SQL только, только появился (в районе 2000 года)
Procedural SQL constructs such as scalar variables, IF statements and WHILE loops were introduced in DB2 with the release of DB2 Version 7. These 7 constructs expanded into the set of SQL statements that makes up the SQL 7 Procedural Langauge (SQL PL) that we refer to today.
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/ad/c0011916.htm

Favn

2. SQL PL для SP появился первоначально в виде native компиляции (до 8.2), сейчас он интерпретатор (точнее, псевдокомпилятор, как в Оракл).

снова не совсем правда, интерпритатор он лишь в небольшой части - в db2 LUW, db2 for iSeries и zOS по прежнему натив компиляция.

Favn

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

неправда. 8.2 это 2004 год, т.е. еще и 4 года не прошло.

Favn

Не надо предположений - аналогов-то нет. Fenced C работают под управлении отдельных процессов db2fmp (на той же схеме, слева от Firewall). Общаются без communication protocols, локально. Как, кстати, и любое приложение с локальным коннектом.

неправда снова.
In general, a routine running as FENCED will not perform as fast as a similar one running as NOT FENCED. This is because NOT FENCED routines can take advantage of inter-process communications (IPCs) within the database engine.
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0510law/#trust
повторюсь fenced процедуры дб2 ничем не отличаются от обычного приложение дергающего оракловый "communication protocol", зовущийся OCI .
not fenced процедуры C или sql pl, которые общаются с ядром через IPC - это аналог именно dedicated сервера оракл, где user process работает с SGA через IPC. причем, кроме fenced java, у db2 нет аналога еще одной древней фиче oracle - shared server архитектуре, где на несколько пользовательских процессов терминами IBM один agent.
28 июн 08, 17:36    [5861062]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
mq
Guest
Yo.!
у db2 нет аналога еще одной древней фиче oracle - shared server архитектуре, где на несколько пользовательских процессов терминами IBM один agent.

Вы про это?
Enhance performance using connection concentrator in DB2
28 июн 08, 18:08    [5861115]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
mq
Yo.!
у db2 нет аналога еще одной древней фиче oracle - shared server архитектуре, где на несколько пользовательских процессов терминами IBM один agent.

Вы про это?
Enhance performance using connection concentrator in DB2

близко, но ...
Agent private memory is allocated for an agent when that agent is created. The agent private memory contains memory allocations that will be used only by this specific agent, such as the sort heap and the application heap.

при shared server оракла еще cильно перераспределяется память, приватная память "агента" уходит в shared memory SGA. причем сервер может работать в двух режимах одновременно, т.е. часть конекций имеют выделеного агента со всей приватной структурой памяти, часть "комуналку" в SGA (параметр конекции определяет).
28 июн 08, 19:04    [5861198]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
mq
Guest
Yo.!
mq
Yo.!
у db2 нет аналога еще одной древней фиче oracle - shared server архитектуре, где на несколько пользовательских процессов терминами IBM один agent.

Вы про это?
Enhance performance using connection concentrator in DB2

близко, но ...
Agent private memory is allocated for an agent when that agent is created. The agent private memory contains memory allocations that will be used only by this specific agent, such as the sort heap and the application heap.

при shared server оракла еще cильно перераспределяется память, приватная память "агента" уходит в shared memory SGA. причем сервер может работать в двух режимах одновременно, т.е. часть конекций имеют выделеного агента со всей приватной структурой памяти, часть "комуналку" в SGA (параметр конекции определяет).


И? Что это дает?

При thread-based модели (DB2 9.5) издержики на "игры" с памятью ничтожны..
Database agents
29 июн 08, 00:53    [5861506]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
ппм
Guest
Если верить Richard Stevens, то Shared Memory это как раз и есть вид inter-process communication.
Просто некоторые этого не знают
И посредством shared memory с агентами работают не только fenced процедуры, но и вообще все клиентские программы, выполнившие connect к локально каталогизированной инстанции.
Скока бреда написано, на всё и не ответить.
Во прёт
30 июн 08, 10:12    [5863353]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
ппм
Если верить Richard Stevens, то Shared Memory это как раз и есть вид inter-process communication.

надо же какой просвещенный муж ну собственно с этим еще ни кто не спорил ...
ппм

И посредством shared memory с агентами работают не только fenced процедуры, но и вообще все клиентские программы, выполнившие connect к локально каталогизированной инстанции.

fenced процедура не может прямо обратится через IPC к структурам ядра, он вынужден координировать свою работу через некий протокол читать кусками сначала в DB2_FMP_COMM_HEAPSZ буфер (ок, используя IPC), т.е. все то же самое, что и обычное внешнее приложение в оракловом OCI.
30 июн 08, 14:45    [5864966]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
гемор с тасканием компилера (для не sql pl процедур) по прежнему актуален. меня ввел в заблуждение sql/pl, которому с 8.2 (2004 год) не нужен внешний компилер, я решил, что компилер класть начали.
Компилятор нужен только для C-процедур (Java входит в поставку). Есть предложение вернуться в настоящее и сравнивать текущие версии продуктов.

Yo.!
неправда. т.е. до 2002 года компиляция UDF на низкоуровневом языке и инсталяция внешнего компилера был вообще единственным вариантом. (повторюсь в оракле подобная бредятена отмерла в конце 80х, на 20 лет раньше).
Сейчас - правда. ОК, ошибся насчет истории UDF. Я - не специалист по истории, готов обсуждать нынешнюю DB2 LUW, с которой работаю, и только. С 8-й не работал, с 7-й работал давно, причем SP тогда не использовал, в чем-то могу ошибаться, копаться в старой доке не намерен.

Yo.!

ничего похожего на нативную компиляцию pl/sql - в оракле с конца 80х никто не требует таскать за собой компилятор, с 80х UDF на pl/sql с одной платформы одним движением переносится на другую платформу. в db2 же надобность таскать за собой компилятор для sql/pl буквально пару лет назад (с версии 8.2 от 2004 года). нативная компиляция pl/sql - для маньков пытающихся выжать из процедурного кода еще 2-3% скорости.
Опять повторю:
""Oracle9i Database introduced native compilation. It did require some DBA setup...
...This scheme worked perfectly well from a technical viewpoint but suffered from some serious usability drawbacks: some customers’ religion simply forbids the installation of a C compiler on a production machine (and you can’t argue with that)." - из нововведений в 11g. То есть, в 9-10 внешний компилятор был нужен. Кажется, 11g вышел чуть позже 80-х :)
Сейчас SP на C в DB2 LUW - нужен для работы с SQL для точно таких же маньяков. Еще раз - не являясь историком, готов обсуждать только текущие версии, с 9-й.

Yo.!
fenced java в db2 запускается в своем процессе и по "remote communication protocol" общается с посредником agent который в свою очередь общяется уже с shared memory структурами db2. это нифига не похоже на java stored procedures, pl/sql и PRO*C/PRO*COBOL которые исполняются в "user process" оракла и минуя посредников работают с shared memory SGA:
When a user runs an application program (such as a Pro*C program) or an Oracle tool (such as Enterprise Manager or SQL*Plus), Oracle creates a user process to run the user's application.
И сколько можно про "remote communication protocol"? Они используются для удаленных instance. Повторяю, с локальными DB2 работает локально, без посредников.
Чем именно локальная работа JVM в DB2 отличается от локальной работы PVM в Оракл?
Чем работа SP unfenced C в пространстве "user agent" отличается от SP PRO*C в "user process"?

Yo.!
снова не совсем правда, интерпритатор он лишь в небольшой части - в db2 LUW, db2 for iSeries и zOS по прежнему натив компиляция.
Опять повторю - работаю только с LUW, могу судить только о ней. Кстати, и с Оракл имеет смысл сравнивать именно ее, т.к. именно LUW - зона их конкуренции.

Yo.!
неправда. 8.2 это 2004 год, т.е. еще и 4 года не прошло.
Да, с датами ошибся, т.к. с 8-й не работал. Смысл от этого не изменился.

Yo.!
In general, a routine running as FENCED will not perform as fast as a similar one running as NOT FENCED. This is because NOT FENCED routines can take advantage of inter-process communications (IPCs) within the database engine.
повторюсь fenced процедуры дб2 ничем не отличаются от обычного приложение дергающего оракловый "communication protocol", зовущийся OCI .
not fenced процедуры C или sql pl, которые общаются с ядром через IPC - это аналог именно dedicated сервера оракл, где user process работает с SGA через IPC. причем, кроме fenced java, у db2 нет аналога еще одной древней фиче oracle - shared server архитектуре, где на несколько пользовательских процессов терминами IBM один agent.
Явная путаница. Какая связь между IPC (Inter-Process Communication) и "remote communication protocol"? Между прочим, столь часто упоминаемая Вами "shared memory" - просто один из видов IPCs. Или Вы отказываете DB2 в праве использовать локальные IPCs? Если да, то на каком основании?
Кстати, в DB2 9.5 именно что "на несколько пользовательских процессов терминами IBM один agent".

Yo.!
fenced процедура не может прямо обратится через IPC к структурам ядра, он вынужден координировать свою работу через некий протокол читать кусками сначала в DB2_FMP_COMM_HEAPSZ буфер (ок, используя IPC), т.е. все то же самое, что и обычное внешнее приложение в оракловом OCI.
Уточню - fenced C. С этим никто не спорил, на то они и fenced. От обычного приложения отличаются работой под выделенными менеджерами - db2fmp. Если они fenced treadsafe, то могут не выгружаться из памяти по завершении и совместно использоваться разными коннектами, работая под одним db2fmp.

PS. Для меня не решенным остался принципиальный вопрос - в Оракле компилируемые (согласно документации) в момент создания триггеры и UDF на PL/SQL тоже под PVM живут, или под ней только SP?
30 июн 08, 15:23    [5865171]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
2Favn
все, задолбался одно и то же разными словами ...

Favn

PS. Для меня не решенным остался принципиальный вопрос - в Оракле компилируемые (согласно документации) в момент создания триггеры и UDF на PL/SQL тоже под PVM живут, или под ней только SP?

все просто: если в коде есть процедурный код (читай PL/SQL) - будет переключение контекста на PL/SQL виртуальную машину, если есть декларативный SQL - будет переключение контекста на SQL машину.
30 июн 08, 17:37    [5866077]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Favn
PS. Для меня не решенным остался принципиальный вопрос - в Оракле компилируемые (согласно документации) в момент создания триггеры и UDF на PL/SQL тоже под PVM живут, или под ней только SP?
Оракл не делает различий между триггерами, UDF и SP - это всё один тип (подразумевая, что это написано на PL/SQL).
Любой PL/SQL код выполняется PL/SQL виртуальной машиной.
3 июл 08, 00:17    [5879000]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
В плане производительности - достаточно печально. Понятно, зачем нужна native-компиляция в DLL.

В качестве итога - получается, что "бедность" SQL-PL в DB2 является скорее достоинством, особенно "совсем бедный" в триггерах и SQL UDF, оптимизирующийся и выполняющийся inline внутри запроса. Да и SP на SQL не требуют переключения контекста. А все задачи, требующие "богатого" языка, могут быть решены за счет вызова SP и UDF на внешних языках, тем более что Java-среда практически входит в поставку (бесплатно скачивается, на базе Eclipse). А взаимосвязи таких процедур с объектами БД, отслеживание изменений и разные варианты оптимизации поддерживаются концепцией pakage'ей.
Относительный минус (и возможный плюс в производительности) - SP в DB2, в т.ч. и на SQL-PL, могут требовать дополнительного администрирования для реоптимизации, решаемого несложными скриптами. А могут и не требовать при reop always :)
PL/SQL же, фактически, по модели работы ближе к внешней Java-машине, хотя, скорее всего, и быстрее ее за счет более тесной интеграции с сервером. Особенно меня впечатлили процессы при выполнении триггеров с SQL/PL - контексты выполнения туды-сюды для каждой записи, если я правильно понял... Жуть :)

ЗЫ Кстати, если кому интересно - в соседнем форуме увидел, что в DB2 9.5 добавили поддержку многих SQL-конструкций из Oracle:
DB2 Viper 2 compatibility features, Viper 2 - это пререлизное название 9.5
4 июл 08, 13:53    [5887001]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 8 9 10 [11] 12   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить