Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 26   вперед  Ctrl
 Re: Провал операции Yukon  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32912
Я бы ужесточил вопрос. Кто из квалифицированных разработчиков... Ну а дальше, по тексту.
14 май 04, 14:55    [679221]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
use-se
Вопрос можно. Я не за белых и не за красных, но интересно. Кто то из разработчиков, кто работал с Oracle (у меня вер. 9.2) добровольно перешел на другую СУБД? Если да то основная причина.
Нет смысла ни куда переходить. Работаете с oracle, вас и ваших клиентов/заказчиков устраивает -> работайте и дальше - ни куда он, в обозримом будущем, не денется. С выходом Yukon, может еще немного потестнится, но вряд ли существенно.
Для тех кто пишет или собирается писать под .NET, стоит как минимум приглядется к Yukon. Судя по всему, уж очень Yukon и .NET хорошо будут интегрироваться.
14 май 04, 15:04    [679256]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
bushmen
Member

Откуда: г. Москва
Сообщений: 828
Я бы сказал так, что если работающая система удовлетворяет требованиям, то для чего нужно переходить на другую СУБД?
14 май 04, 15:06    [679263]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32912
Leonid
Судя по всему, уж очень Yukon и .NET хорошо будут интегрироваться.

Миф из серии "Delphi специально заточен под InterBase"
14 май 04, 15:10    [679277]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
Квалифицированному разработчику в сущности по барабану. Если его мнение спросят - он обоснует свой выбор конечно (причём квалифицированно, с учётом специфики задачи, требований заказчика, скилзов членов команды, ценовых рамок и пр. и др.). А если не спросят - будет делать на чём скажут. Или не будет. :)

Мне приходилось делать проекты и на том и на другом. Плевался везде. Привыкать к Ораклу после МС было иногда сложно, идеология всё же сильно отличается. Сейчас привык. Если будет надо - без проблем перейду на МС.

Не помню говорил или нет.. Мне Оракл и МС 2000 напоминают вертолёт и танк. Две боевые машины для решения разных боевых задач. Знатные танкисты смеются над колёсами и винтом, а вертолётчики говорят со знанием дела "Эта штука не взлетит!"
14 май 04, 15:10    [679279]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
Мимопроходящий
Миф из серии "Delphi специально заточен под InterBase"
Да какой тут миф, когда хранимые процедуры на "дот-нетовых" языках.
oracle же пока .NET не собирается поддерживать - у него "жаба". Или уже собрался?
14 май 04, 15:17    [679312]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
А зачем Oracle-у dot Net ? у него Java есть
14 май 04, 15:28    [679361]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 use-se
А недобровольно - это как? Под пытками? :)
Переходят все туда где больше платят, всегда добровольно и обычно без особого желания (безотносительно с какого продукта на какой).
14 май 04, 16:40    [679694]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
c127
Guest
2 locky
>а в Sybase, по моему, ограничение на кол-во табличек в join - 50, а не то, что Вы сказали :-)

Разве что только по-вашему.

2 SergSuper

>оракловый оптимизатор в данной ситуации выбирает не лучший план.
(прим: по сравнению с MSSQLвским)


Во-первых не совсем понятно, какие запросы там сравнивались, может что разные, а во-вторых, даже если и одинаковые, то сравнивался MSSQL2000 и оракл8i. Так надо не мелочиться, а сразу взять оракл самой первой версии, сравнить планы с MSSQL2000 и закопать оракл раз и навсегда.
16 май 04, 03:52    [680789]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
Во-первых не совсем понятно, какие запросы там сравнивались, может что разные, а во-вторых, даже если и одинаковые, то сравнивался MSSQL2000 и оракл8i.
Запрос простой
SELECT * from t where a = (select min(a) from t)
И не только 8i, но 9i и 10i тоже выдают план хуже, чем MS2000.
16 май 04, 12:01    [680832]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gt.
Guest
автор

Запрос простой
SELECT * from t where a = (select min(a) from t)
И не только 8i, но 9i и 10i тоже выдают план хуже, чем MS2000.


для этого запроса оракл выбирает лучший план, который делает МС в 4 раза как по времени так и по косту. из лидеров (МС, ИБМ, Оракл) оптимизатор МС самый ущербный - нет ни аналога Fined Grained Access, нет возможностей ограничения ресурсов, убогий набор хинтов.
16 май 04, 13:42    [680851]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
Oracle SQL Hints (documented+undocumented)
16 май 04, 19:09    [680965]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
Gluk (Kazan)
А зачем Oracle-у dot Net ? у него Java есть
Вам как милиционеру, два раза повторять что ли ;)
Для "дот-нет" програмистов Yukon ближе, чем oracle. Для java программеров, наоборот. Что еще Вас смущает?

Gt
оптимизатор МС самый ущербный
Да Вам ни как не успокоится, неугомонный Вы наш ((с) "Гараж").
Для вас погрехи oracle - как личное оскорбление? ;)
Странный феномен, но болельщики "против спартака" готовы скорее застрелиться, чем признать, что MS "не веники вяжет" Странные люди однако...
16 май 04, 23:52    [681046]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
для этого запроса оракл выбирает лучший план, который делает МС в 4 раза как по времени так и по косту.
Эти "в 4 раза" - цена огурцов на стамбульском базаре в прошлом году.
И для MS, и для Oracle наиболее оптимальный план для данного запроса, при условии уникальности (а), будет состоять из одного сканирования таблицы и одной сортировки. MS до этого додумывается, Oracle - нет.
К слову, для MS, этот же план применим и без уникальности (а), про Оракл - не знаю.

оптимизатор МС самый ущербный - нет ни аналога Fined Grained Access, нет возможностей ограничения ресурсов, убогий набор хинтов
Ты хоть один аргумент к месту можешь приплести? Какое отношение к оптимизатору имеют FGA и ограничение ресурсов?
А так же расскажи зачем нужны хинты при хорошем оптимизаторе. Я уже говорил, что главным признаком того, что у MS один из лучших оптимизаторов в индустрии, является тот факт, что соотношение, для достижения нормальной работы хинт/запрос одно из самых низких и уж всяко ниже Оракла.
17 май 04, 00:58    [681068]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
xz321
Guest
2Merle: Расскажи пожалуйста, если не влом, как работает Hash partitioning в Yukon и что под этим подразумевается?
17 май 04, 10:43    [681428]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gt.
Guest
автор
И для MS, и для Oracle наиболее оптимальный план для данного запроса, при условии уникальности (а), будет состоять из одного сканирования таблицы и одной сортировки. MS до этого додумывается, Oracle - нет.


кто это сказал ? оптимальный план слава богу определяет кост, который учитывает не только сканирование, имено поэтому оракл нивкакую не хочет выбирать план в 4 раза дороже.

автор
Какое отношение к оптимизатору имеют FGA и ограничение ресурсов?


RTFM. например для FGA нужно включать опцию query_rewrite

автор
является тот факт, что соотношение, для достижения нормальной работы хинт/запрос одно из самых низких и уж всяко ниже Оракла.


ущербность все таки тяжело представить фичей - фокспро и mysql имеют бОльшое соотношение хинт/запрос (их там нет) :)
17 май 04, 10:50    [681450]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
use-se
Member

Откуда: Москва
Сообщений: 449
Тему надо закрывать, Вы столько сил тратите на спор....
Может введете мораторий на 1 неделю? Поймите меня правильно, моя квалификация меньше чем Ваша и так много хочется еще узнать :))
17 май 04, 11:01    [681471]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2c127
а вот разработчики Sybase 12.5.1. говорят
Tables in a query...................................................50
так что не только по моему, но и по ихнему.
17 май 04, 12:41    [681795]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
кто это сказал ?
Оракл сказал.

оптимальный план слава богу определяет кост, который учитывает не только сканирование, имено поэтому оракл нивкакую не хочет выбирать план в 4 раза дороже.
А посмотреть план запроса SELECT * from t where a = (select min(a) from t) и сравнить его с планом select * from t where rownum<2 order by a - религия не позволяет?
Если стоимость второго запроса окажется выше, то оптимизатор оракла вообще на помойку выкидывать надо.

RTFM. например для FGA нужно включать опцию query_rewrite
Не надо путать теплое с мягким. то, что для работы FGA нужен оптимизатор совсем не означает, что FGA это часть оптимизатора.

ущербность все таки тяжело представить фичей
Хватит уже пургу нести.

Пример можно ? А то я с детства туповат :(
Допустим есть таблица T, c примерно такими записями:
x, y
1,2
1,3
1,4
1,5
1,6
Параллельно выполняются два запроса из разных транзакций:
1. UPDATE T SET y=10 WHERE x=1;
2. UPDATE T SET x=2 WHERE y=5;
Первый запрос поменял записи с y=1,2,3 и 4, в этот момент второй запрос поменял запись y=5 и транзакция запустившая этот запрос зафиксировалась.
При уровне изоляции Read Committed, Оракл откатит первый запрос, удерживая эксклюзивные блокировки на всех ранее обработанных записях, а затем выполнит запрос снова. Хотя с формальной точки зрения в откате нет необходимости.
При этом, если во время отката и повторного выполнения придет третья транзакция и успеет поменять запись y=6, то все пойдет по новой - откат и новое выполнение запроса.
17 май 04, 13:25    [681977]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Merle
Хотя с формальной точки зрения в откате нет необходимости.

Как раз с формальной точки зрения, он помоему необходим
Введение в управление транзакциями Лилия Козленко
21.11.2002 Открытые системы, #11/2002 Часть третья

Вводится следующее ограничение видимости версий: транзакция T видит или ту версию объекта данных Vnew, которую она сама породила, или фиксированную версию объекта данных Vfixed, которая удовлетворяет ограничению: транзакция, породившая Vfixed, должна быть зафиксирована раньше, чем транзакция T выполнила первый запрос, в результате выполнения которого считывается Vfixed.
Очевидно, что основная сложность проверки этого ограничения связана, во-первых, <skipped> , во-вторых, с проблемами актуализации операций чтения (чтобы транзакцией T считывались актуальные данные).
<skipped>
Вторая же проблема характерна только для многоверсионности. Проблемы актуализации данных при использовании блокирования не возникают, так как отсутствует несколько версий одного объекта данных. Решается она путем ужесточения протокола отката транзакции — при фиксации транзакции происходит проверка наличия фиксированных более старых версий объектов данных, которые модифицирует данная транзакция, чем те версии, которые данная транзакция считала, естественно «слепая запись» также запрещается (каждая операция записи предваряется неявной операцией чтения). Если есть такая фиксированная более поздняя версия (изменение данных «под транзакцией») — то это означает, что считанная транзакцией версия не актуальна и транзакция принудительно откатывается.

Т.е. на уровне RC встает проблема актуализации на уровне оператора,если есть версия данных зафиксированная после начала оператора. У Oracle остается 2-пути откатить всю транзакцию и перестаровать её, или откатить оператор и перенести начало "актуализации" на новое время и перстартовать только оператор, второй путь мне кажется дешевле.
17 май 04, 17:19    [682927]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
Как раз с формальной точки зрения, он помоему необходим
Да нет, при RC в этом нет никакой необходимости, необходимость есть только при SnapShot, (при котором Оракл по-честному откатывает всю транзакцию).

Т.е. на уровне RC встает проблема актуализации на уровне оператора
Формально, при RC такой проблемы нет... Перед RC не стоит проблема согласованности одного оператора, там требуется лишь проводить операции над зафиксированными данными.
Хотя Оракловский вариант более согласован, чем классический RC, зато и более дорог в реализации, да к тому же и не очень корректно соптимизирован.
При классическом RC даже версионнику достаточно либо проигнорировать измененную запись, если она перестала попадать в предикат, либо спокойно поменять ее, если она по преднему удовлетворяет предикату после фиксации вражеской транзакции, и это будет совершенно полноценный RC.
17 май 04, 19:04    [683164]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Антилох
Guest
Merle
Параллельно выполняются два запроса из разных транзакций:
1. UPDATE T SET y=10 WHERE x=1;
2. UPDATE T SET x=2 WHERE y=5;
...
При уровне изоляции Read Committed, Оракл откатит первый запрос удерживая эксклюзивные блокировки на всех ранее обработанных записях, а затем выполнит запрос снова.


Не откатит тут ничего Оракл, при уровне Read Committed. Можете проверить. Вот при serialize-уровне , возможна ошибка - ora 08177 : cannot serialize access for this transaction.
17 май 04, 20:22    [683243]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Yo!
Guest
автор
А посмотреть план запроса SELECT * from t where a = (select min(a) from t) и сравнить его с планом select * from t where rownum<2 order by a - религия не позволяет?


я так понимаю у сиквела это фича давать на разные запросы с разными результами один план ... наверно именно поэтому он занимает последнее место из субд в tpc-h на Ad Hoc Queries :)

автор
Не надо путать теплое с мягким. то, что для работы FGA нужен оптимизатор совсем не означает, что FGA это часть оптимизатора.


RTFM
18 май 04, 01:00    [683408]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
c127
Guest
2 locky

>а вот разработчики Sybase 12.5.1. говорят
Tables in a query...................................................50
так что не только по моему, но и по ихнему.


А вот locky не читает оппонентов, так что по-прежнему все без изменений: только "по-Вашему".

Что же касается ограничений в 12.5.1., то это как раз говорит о том, что и MSSQL7-2000 и ASE по-прежнему используют общее ядро компилятора и всякое "переписывание с нуля" есть сказочки от мелкософта для доверчивых. Все задержки и кастрации Юкона ИМХО говорят о том, что мелкософт в начале действительно собирался все переделать, да не рассчитал силы, маленько надорвался и теперь сбрасывает груз, чтоб сделать хоть что-то. Так что скорее всего ничего действительно нового мы не увидим и в ядре Юкона будет тот же сайбейз. К GUI это не относится, GUI будет сверкать никому не нужными красками.

2 Merle

>...наиболее оптимальный план для данного запроса, при условии уникальности (а), будет состоять...

А что это за уникальность такая, это что, первичный ключ? Второй раз как минимум Вы это повторяете. Откуда уникальность следует, откуда сервер узнает, что поле уникально? Вы ему ничего не сказали, а он сам не может разобраться, что вы когда-то давно забивали записи из таблицы, где это "a" было первичным ключом ( insert into Departments (dept,name,salary) select id%10,name,id from sysobjects ).

Для того чтоб эту ункальность выяснить (доказать) по крайней мере нужно просканировать таблицу. Я вообще подозреваю, что уникальность выяснится где-то за O(N)*log2(N) операций, где N- количество записей в таблице а это для больших N (N>16) получается гораздо больше, чем четыре сканирования (4*N), которые Вам так не нравятся. Так что чтобы условие уникальности "a" использовать нужно вначале потратить гораздо больше, чем потом будет сэкономлено. Не могли такую глупость сделать даже в мелкософте, по-моему Вы просто неверно интерпретируете их план.
18 май 04, 03:55    [683432]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Zaxx
Guest
Merle
Параллельно выполняются два запроса из разных транзакций:
1. UPDATE T SET y=10 WHERE x=1;
2. UPDATE T SET x=2 WHERE y=5;
При уровне изоляции Read Committed, Оракл откатит первый запрос


Как он откатит первый запрос ? Явно (с exception) или "где-то там у себя внутри" ?
18 май 04, 09:20    [683601]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 26   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить