|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
ApexНа проекте, где я сейчас работаю у нас 72-х нодный кластер на DB2. И я скажу так, различия весьма и весьма существеные, что бы там не говорил гражданин Метелица. А что он такого говорил? Возможно, у вас сложилось неверное впечатление. Я полагаю, что перевестись с Oracle на DB2 будет легче, чем на другую СУБД, потому что IBM-еры постарались перенести PL/SQL и кучу других вещей - но это совсем не значит, что будет легко. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 11:42 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!ну и второй большой косяк - отсутствие версионности, в 21 веке, где даже mysql выдает консистентный набор на момент старта запроса биться будет проблематично. изврат в виде хинтов аля skip_locked, last_committed девелоперы в своей массе не оценят, когда есть выбор Сферическим девелоперам в вакууме при решении задач о сферических конях в вакууме невозможно обойтись без ораклиной консистентности, ага. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 11:53 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!db2 до сих пор динозавр, повторяет то что прошел оракл 15-20 лет назад. 15-20 лет назад у оракла тоже был статический SQL который внедрялся в известные языки, типа C, но если на смену этому порно в оракле достаточно быстро пришел 4GL язык Кстати, по мне, (в сравнении с "4GL") статический SQL в DB2 как был великолепен в DB2 2.1 for OS/2, так и сейчас великолепен (разве что, могли бы добавить поддержку большего количества типов данных). Всякого рода PL/SQL-и нужны были для попытки переманивания с Oracle, но не сами по себе. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 12:02 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!мериться отмершими в мире оракла прекомпиляторами не готов, а вот по 4GL запросто. нука напишите мне аналог на любом вашем языке Код: plsql 1.
http://tkyte.blogspot.ru/2006/10/slow-by-slow.html Вот то, чем вы и сотни тысяч таких же, как вы, занимаетесь. Clipper умер, а клипперисты живее всех живых. предлагаете на каждый чих реавалидировать сотни мб кода всего проекта ? В нынешних версиях DB2 Oracle-подобное поведение. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 12:09 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Victor MetelitsaНе сочиняю. Undo tablespace у DB2 нет. В старые времена при попытке посмотреть на изменённую запись происходила блокировка (если не использовать уровень изоляции UR), теперь может заглянуть в лог ( http://www.ibm.com/developerworks/data/library/techarticle/dm-0907oracleappsondb2/index.html ). ну и где там двунаправленный лог ? я рад за db2, что он научился вместо грязного блока выдавать last committed. я понимаю, что это огромный шаг для db2, но к консистентному набору выдаваемому версионными субд этот костыль db2 не приближает. никому не нинтересен последняя закомиченная версия, всех интересует та, что была в момент старта запроса/транзакции. Victor Metelitsa C поры "IBM DB2 UDB 8.2" ситуация могла сильно поменяться. это не важно, важно, что есть пример, где хорошо видно, что оракл на одинаковом железе может писать в undo+redo быстрее чем db2 или mssql в один transaction log. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 12:18 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Victor Metelitsa http://tkyte.blogspot.ru/2006/10/slow-by-slow.html Вот то, чем вы и сотни тысяч таких же, как вы, занимаетесь. Clipper умер, а клипперисты живее всех живых. анекдот- Сивка Бурка вещая каурка, встань передо мной как лист перед травой. - Иван, вы бы поконкретнее выражались как вставать, а то у нас у лошадей короткий ассоциативный ряд. интересно, это у вас под влиянием db2 декларация процедуры ассоцируется с клипером ? Victor MetelitsaВ нынешних версиях DB2 Oracle-подобное поведение. это вам мерещется, ничего похожего на зависимости в db2 нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 12:30 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!ничего похожего на зависимости в db2 нет. А зачем они нужны, если всё равно не используются? Какая принципиальная разница между последовательностями "изменение объекта - инвалидация зависимых - попытка использования зависимого объекта - попытка компиляции - ошибка пользователю" и "изменение объекта - попытка использования зависимого объекта - ошибка - попытка компиляции - ошибка пользователю"? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 12:40 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!нука напишите мне аналог на любом вашем языке Код: plsql 1.
нуканаписал: Код: sql 1.
В режиме совместимоси с Ораклом - вообще без изменений. Yo.!или выдайте права на процедуры связанные с фин подсистемой (с пакаджем)Не уверен, что понял, что вы хотите. В db2 права на процедуры выдаются так же как и в Оракле - грантом на выполнение процедуры, а не на пакет. На пакет выдаются гранты, если вы написали программу на C, JAVA, например, с использованием статического SQL. Можно выдавать грант на выполнение модуля (пакета по-вашему), что даёт право на выполнение любой опубликованной процедуры. Вопрос: чего здесь не хватает по сравнению с Ораклом? Yo.!... если я снес таблицу, у меня процедуры обращающиеся к этой таблице должны пометиться как invalid и должен быть запрет на запуск заведомо не валидного кода. в db2 до сих пор даже этого базиса нет. ... это вам мерещется, ничего похожего на зависимости в db2 нет.Мне тоже что-то мерещится. Давайте на примере. В системном каталоге есть несколько представлений с именем DEP в конце. Вот их список CONSTDEP DATATYPEDEP FUNCDEP INDEXDEP INDEXEXTENSIONDEP PACKAGEDEP ROUTINEDEP TABDEP TABDETACHEDDEP TRIGDEP VARIABLEDEP VIEWDEP XSROBJECTDEP Во всех представлениях есть поля для описания объектов от которых есть зависимость: BTYPE, BSCHEMA, BNAME При DDL эти таблицы ведутся автоматически, и я могу проверить любые зависимости. Вот пример Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39.
... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 14:44 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!db2 до сих пор динозавр, повторяет то что прошел оракл 15-20 лет назад. 15-20 лет назад у оракла тоже был статический SQL который внедрялся в известные языки, типа C, но если на смену этому порно в оракле достаточно быстро пришел 4GL язык, то в db2 sqlpl до сих слишком куцый и глючной.Вы путаете SQL статический (db2: static), которого у Оракла никогда не было, и "встраиваемый" (db2: embedded). Про куцый и глючный: ОБС-news или на примере можете? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 14:54 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Mark Barinsteinнуканаписал: Код: sql 1.
В режиме совместимоси с Ораклом - вообще без изменений. блин, если уж встреваете в спор, ну проследите нить разговора: CawaSPbЭто потому что у Оракла никогда не было нормального статического SQL с нормальным менеджментом пакетов (bind, rebind и т.п.). А этот 4GL язык - один фиг бейсик для работы с датасетами толком не предназначенный. Да он стал популярен, но строго потому, что писать на нём идут люди недалеко ушедшие от VB. к чему тут пример на SQLPL, покажите аналог этой процедуры на прекомпиляторе + static SQL ! та же фигня с грантами. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 16:46 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Mark BarinsteinВы путаете SQL статический (db2: static), которого у Оракла никогда не было, и "встраиваемый" (db2: embedded). и там и там прекомпилятор, разница лишь в деталях. на мой взгляд статик SQL ублюдочен в своей концепции. план запроса должен меняться вместе с ростом и изменениями объектов субд, а не зашиваться вместе с процедурой. запрос в любых условиях должен исполняться с оптимальным планом, а не с тем, что был когда-то оптимальным. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 16:55 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!к чему тут пример на SQLPL, покажите аналог этой процедуры на прекомпиляторе + static SQL ! та же фигня с грантами.А какой смысл показывать, как на мотоцикле пару мешков картошки возить? Это на машине удобнее делать, примерно такой же, как и ваша. Yo.!и там и там прекомпилятор, разница лишь в деталях. на мой взгляд статик SQL ублюдочен в своей концепции. план запроса должен меняться вместе с ростом и изменениями объектов субд, а не зашиваться вместе с процедурой. запрос в любых условиях должен исполняться с оптимальным планом, а не с тем, что был когда-то оптимальным.Никому не интересно как мы код компилируем - с пре-, пост- или вместо-компилятором. Главное отличие в результате. Попробуйте расширить своё сознание (только без веществ, пожалуйста :), чтобы понять эту концепцию. Идея там примерно в следующем: Часто вы знаете, что план запроса не будет меняться с изменением статистики. Такие запросы характерны для OLTP систем - они простые, но их много. Для того, чтобы выполнить динамический запрос вы должны сделать: - распарсить запрос, проверить, есть ли он в кэше запросов - проверить права на каждую таблицу запроса - построить план и сохранить его в кеше запросов Понятно, что все шаги вы не делаете постоянно, если не закрываете стейтмент сразу после использования. Но накладные расходы есть, и они могут стать довольно значительными, особенно если запросов действительно много. В случае статических запросов вы только провеояете права на выполнение пакета, который управляет всеми запросами программы. У IBM есть даже такой продукт, как pureQuery , который может превращать динамические запросы вашей программы в статические без перепрограммирования. Говорят, что на некоторых нагрузках можно получить только из этого довольно неплохие результаты . В общем, это инструмент для своих нужд, его не надо пытаться использовать для решения всех задач. Если вы не хотите, то можете его не использовать. Но в Оракле этого просто нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 20:15 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Mark BarinsteinА какой смысл показывать, как на мотоцикле пару мешков картошки возить? Это на машине удобнее делать, примерно такой же, как и ваша. прекомпилер это не мотоцикл - это динозовр, на большинстве задач давно вымерший по объективным причинам. Mark BarinsteinЧасто вы знаете, что план запроса не будет меняться с изменением статистики. очнитесь, на дворе 21 век, cost based оптимизаторы. да наши предки грелись у костров, охотились на мамонтов и использовали прекомпиллеры, но сейчас то оптимизатор может посмотреть в буферный кеш и изменить план уже исходя из этого. прекомпиллер физически не может построить оптимальный план не имея даже базовой информации, какая часть таблицы в буферном кеше. опять же план может сильно зависеть от переменных, я не понимаю как прекомпилятор мог бы построить оптимальный план на каждый вариант. на все варианты не зашьешь ... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 20:46 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!прекомпиллер физически не может построить оптимальный план не имея даже базовой информации, какая часть таблицы в буферном кеше. опять же план может сильно зависеть от переменных, я не понимаю как прекомпилятор мог бы построить оптимальный план на каждый вариант. на все варианты не зашьешь ...Вы, похоже, так и не поняли, о чём я написал. Для построения плана запроса типа: Код: sql 1.
не надо знать ни статистики, ни значения параметра, ни то, какая там часть таблицы в кэше сидит. Какие тут могут быть варианты? Вариант плана здесь всегда будет один, и он же будет оптимальным. А главная идея в том, чтобы для такого запроса (которых, повторюсь, может быть очень много) убрать накладные расходы, которые в сумме вообще могут превысить расходы на выполнение этого запроса. А для 21-го века у DB2 есть тоже хитрый оптимизатор и т.п. P.S.: 1. Всё ли понятно теперь про зависимости в db2? Они все-таки есть, или их по-прежнему нет для вас? 2. Про куцый и глючный DB2 SQL/PL (или PL/SQL) будут примеры? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 21:16 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Mark Barinsteinselect ... from mytable where pk=:par [/src]не надо знать ни статистики, ни значения параметра, ни то, какая там часть таблицы в кэше сидит. Какие тут могут быть варианты? Вариант плана здесь всегда будет один, и он же будет оптимальным. если колонка pk не уникальна, даже на столь примитивном запросе будет полно вариантов. Mark BarinsteinА главная идея в том, чтобы для такого запроса (которых, повторюсь, может быть очень много) убрать накладные расходы, которые в сумме вообще могут превысить расходы на выполнение этого запроса. для прошлого века это может и была нормальной идеей, но в 21 веке, когда даже сортировка одного и того же объема с утра может иметь одну стоимость, а к вечеру уже другую из-за перераспределения структур памяти субд это не работает никак. Mark BarinsteinА для 21-го века у DB2 есть тоже хитрый оптимизатор и т.п. поэтому db2 и бросила все силы на копирование фич oracle, а не выносит мозг протухшими прекомпиляторами. Mark Barinstein1. Всё ли понятно теперь про зависимости в db2? Они все-таки есть, или их по-прежнему нет для вас? 2. Про куцый и глючный DB2 SQL/PL (или PL/SQL) будут примеры? 1. далеко не все, такие зависимости и в мсскл есть, а может db2 отследить если изменилась колонка с варчар на инт ? 2. попозжей будут ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 21:33 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!поэтому db2 и бросила все силы на копирование фич oracle, а не выносит мозг протухшими прекомпиляторами.Вы зациклились на прекомпиляторах. Считайте, что его нет в db2. В SQL процедуре статический код появляется без всяких прекомпиляторов, например. Yo.!Mark Barinstein1. Всё ли понятно теперь про зависимости в db2? Они все-таки есть, или их по-прежнему нет для вас? 1. далеко не все, такие зависимости и в мсскл есть, а может db2 отследить если изменилась колонка с варчар на инт ? Каких зависимостей не хватает? И при чём здесь MSSQL? Что значит "отслеживать"? Инвалидировать зависящие от объекты? Пример Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36.
Т.е. оно переводит таблицу в read-only режим после изменения типа до тех пор, пока я не сделаю реорганизацию таблицы. Процедура типа этой не инвалидируется. Код: sql 1. 2. 3. 4. 5.
Это нормально или нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 22:13 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!выносит мозг протухшими прекомпиляторамиСпасибо, поржал. И про вынос мозга очень к месту. Yo.!, любезный, "прекомпилятор" - это совсем не то, что Вы думаете :) Прекомпилятор - это тулза, запускаемая до компиляции/интерпретации, а не вместо :) И никакие исполняемые коды (планы исполнения для SQL) прекомпилятор генерить не может в принципе. Его задача - только подготовить исходный текст. В DB2 "прекомпилятором" можно назвать те фазы, которые запрос объединяют в один длинный текст, inline подставляя view и специально обученные UDF (нет такого в Oracle), парсят его, переформулируют (sql rewriting - есть ли он в Oracle?), объединяют группу запросов в пакет, проверяют права. Т.е. делают всю работу, для которой статистика и прочие cost based совсем не нужна. Получется полуфабрикат - пакет по-DB2'шному. Собственно "компиляция", при которой строятся планы выполнения, грубо говоря называется bind/rebind. И уже она может происходить в момент вызова, в момент первого обращения или постоянно при необходимости (как в интерпретаторах, но без подготовительных фаз "прекомпилятора") - как укажешь. И что лучше - интерпретатор, работающий только одним способом, или компиляция с возможностью выбора ее времени с экономией времени на предобработку? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 23:07 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Mark BarinsteinВы зациклились на прекомпиляторах. Считайте, что его нет в db2. В SQL процедуре статический код появляется без всяких прекомпиляторов, например. в SQLPL процедуре ? забавно, а там то такое на кой ? в оракле если уж так хочется зафиксировать план - есть отдельные инструменты, которые зафиксировать могут не только SQL из процедур но и то, что приходит от клиента или генерится на лету. Mark BarinsteinЧто значит "отслеживать"? Инвалидировать зависящие от объекты? да, инвалидировать код, заведомо не выполнимый. Mark BarinsteinЭто нормально или нет? на мой взгляд нет. po у вас объявлено как варчар, а таблица вернет инт, значит ваша процедура превратилась в инвалидную. зы. так на счет того, что оптимальность плана может измениться не только из-за изменений статистики я убедил ? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 23:11 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!po у вас объявлено как варчар, а таблица вернет инт, значит ваша процедура превратилась в инвалидную. А что, implicit cast числа в строку кто-то предал анафеме?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2013, 23:15 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
CawaSPb2 Apex, а что с ним не так??? Интересно. И ещё раз, в Oracle его попросту нет, так что в контексте темы это просто таки жирный плюс DB2. При этом технология более чем зрелая. На моей памяти (>15 лет) ей вовсю (в том числе в мире VLDB) пользуютя "и не жужжат" ;) Согласен, по сравнению с Ораклом - все прекрасно, тут у меня претензий никаких. На счет не жужжат - я бы так не сказал. Тут вот какое дело, как и Оракл РАК, так и DB2 DPF (ранее PE) они, что называется, кластерны не от природы, обе СУБД уходят корнями в некластерные СУБД для OLTP. Отсюда лишние сложности в администрировании: надо создавать какие-то партинш группы, партишн тейблспейсы, думать о том, в каком тейблспейсе у тебя таблица - в партиционированном или нет? и пр. Т.е. прозрачность для приложений вроде есть, а вот для администрирования как-то не очень. Теперь что касается функционала, в DB2 варехаузный ИМХО слабоват: набор аналитических функций куций по сравнению с тем же Ораклом, партиционирование только двухуровневое (хотелось бы еще минимум одного), truncate конкретной партиции просто так не сделаешь - надо сначала detach сделать, переливка данных из таблицы в таблицу а-ля INSERT /*+APPEND*/ INTO - это вообще песня, где простая операция превращаетя в серию каких-то приседаний и подпрыгиваний с курсорами и вызовами консольной утилиты LOAD через процедуру ADMIN_CMD. CTAS опять же ущербный... В общем, я конечно понимаю, что по сравнению с мировой революцией - это все мелочи и дело привычки, но сложно все как-то, не удобно и работать с DB2 в будущем у меня никакого желания нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2013, 05:33 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!Mark BarinsteinЧто значит "отслеживать"? Инвалидировать зависящие от объекты?да, инвалидировать код, заведомо не выполнимый. Mark BarinsteinЭто нормально или нет?на мой взгляд нет. po у вас объявлено как варчар, а таблица вернет инт, значит ваша процедура превратилась в инвалидную.Нет, процедура как работала, так и работает. Там будет делаться неявное преобразование типов. Еще есть претензии/вопросы к зависимостям в db2? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2013, 09:27 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!зы. так на счет того, что оптимальность плана может измениться не только из-за изменений статистики я убедил ?Вы даже не начали. Если это продолжение: Yo.!select ... from mytable where pk=:par если колонка pk не уникальна, даже на столь примитивном запросе будет полно вариантов.то давайте обсудим. Дано: "большая" таблица, поля в предикате проиндексированы, запрос возвращяет несколько записей (ну, не больше 20-30). Кардинальность индекса высокая. В общем, довольно часто встречающийся вариант в OLTP системе. Расскажите про "полно вариантов", кроме обычного IXSCAN-FETCH. Мы каждый обсудим и решим, много ли от перебора всех возможных вариантов мы выиграем. И много ли потеряем, если для такого случая оптимизатор при каждом из огромного потока таких запросов будет проявлять интеллект и решать, а надо ли поменять план. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2013, 09:42 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Apexпартиционирование только двухуровневое (хотелось бы еще минимум одного), truncate конкретной партиции просто так не сделаешь - надо сначала detach сделать, переливка данных из таблицы в таблицу а-ля INSERT /*+APPEND*/ INTO - это вообще песня, где простая операция превращаетя в серию каких-то приседаний и подпрыгиваний с курсорами и вызовами консольной утилиты LOAD через процедуру ADMIN_CMD. CTAS опять же ущербный... - партиционирование Вы можете использовать MDC для "субпартиционирования" (возможно указать несколько полей в ORGANIZE) типа такого: Код: sql 1. 2. 3. 4.
Вы не используете такой вариант? Если нет, то почему? - INSERT /*+APPEND*/ INTO Будет работать и в DB2 с той разницей, что в DB2 нет APPEND хинта, и чтобы добиться такого же поведения, надо выставить это свойство на уровне таблицы. LOAD from CURSOR же - это весьма скоростная альтернатива, позволяющая заметно быстрее, без жуналирования, вставлять в таблицу большие объёмы данных на основе другого запроса. Типа sql loader'а в режиме direct path, только входные данные - результат запроса. Не уверен, что в Оракле есть такая возможность, поэтому трудно сравнивать. - CTAS В DB2 есть процедура ADMIN_MOVE_TABLE, которая похожие вещи делает, если я правильно понял аббревиатуру CTAS. К ней надо привыкнуть, конечно, но с ней проблемы или неудобства какие-то? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2013, 10:11 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Mark BarinsteinНет, процедура как работала, так и работает. Там будет делаться неявное преобразование типов. Еще есть претензии/вопросы к зависимостям в db2? да, про неявную сглупил, но вы поняли в чем мой вопрос. в обратной ситуации - переменная инт, а в таблице на чар сменили Mark Barinsteinто давайте обсудим. Дано: "большая" таблица, поля в предикате проиндексированы, запрос возвращяет несколько записей (ну, не больше 20-30). Кардинальность индекса высокая. В общем, довольно часто встречающийся вариант в OLTP системе. по вашему олтп это лишь вытягивания по индексу ? я например столь примитивные запросы в реальных системах не встречал. если хотите совсем конкретики давайте возьмем TPC-E - реальная задача, реальные запросы. там, например, такого примитива нет. но даже на таком примитивном запросе если по значению 'shit' возвращается 99.9% записей, то вместо индекса эффективней фулскан применить. т.е. уже не один вариант. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2013, 12:36 |
|
Oracle vs DB2
|
|||
---|---|---|---|
#18+
Yo.!да, про неявную сглупил, но вы поняли в чем мой вопрос. в обратной ситуации - переменная инт, а в таблице на чар сменилиНет, я не понял разницы. DB2 мне не запрещает на Код: sql 1.
пытаться делать арифметические операции над v. Т.е. я могу в процедуре делать v + 1, например, и процедура создастся. То же самое будет, если я поменяю int на varchar в таблице, т.е. процедура использующая арифметику не будет инвалидироваться. Она в рантайме будет отваливаться, если неявное преобразование varchar -> int не пройдёт. А как это в Оракле происходит? Создастся ли на таблице выше процедура, где есть обращение v + 1 к полю? Будет ли процедура инвалидироваться при изменении varchar -> int? Yo.!по вашему олтп это лишь вытягивания по индексу ? я например столь примитивные запросы в реальных системах не встречал. если хотите совсем конкретики давайте возьмем TPC-E - реальная задача, реальные запросы. там, например, такого примитива нет. но даже на таком примитивном запросе если по значению 'shit' возвращается 99.9% записей, то вместо индекса эффективней фулскан применить. т.е. уже не один вариант.Да, по-моему OLTP - это преимущественно вытягивание по индексу. Я не говорю, что все, но значительная часть запросов - да. Давайте смотреть TPC-E, если хотите. Можете показать, где там будут фуллсканы встречаться, неравномерное распределение данных и т.п. Я уверен, что и там мы с вами найдем запросы, для которых не надо знать статистику и всё остальное, а можно будет только по существующим индексам сказать, какой будет оптимальный план запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2013, 15:53 |
|
|
start [/forum/topic.php?fid=35&msg=38433796&tid=1552422]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 254ms |
total: | 378ms |
0 / 0 |