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

Откуда: СПб
Сообщений: 1815
Merle

Да нет, при RC в этом нет никакой необходимости, необходимость есть только при SnapShot, (при котором Оракл по-честному откатывает всю транзакцию).

В этом смысле да, оракловский RС это скорее "изолированность образа" на уровне оператора.
Антилох
Не откатит тут ничего Оракл, при уровне Read Committed.

Откатит и перезапустит, просто вы этого не замитете поскольку дело происходит "за сценой". Почитать можно здесь "write "consistency"" http://asktom.oracle.com/
Zaxx

Как он откатит первый запрос ? Явно (с exception) или "где-то там у себя внутри" ?

"Где то там у себя внутри", и потом перезапустит с новой меткой времени, читать там же.
18 май 04, 09:57    [683685]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Павел Воронцов

Как-то это натянуто получилось (про танк и вертолет). Ведь по-сути сравниваются две DBMS для OLTP систем.

PS> Спор совершенно бестолковый по огромному количеству причин.

1) спорят люди разной квалификации и опыта
Это обычно - но и привыкнуть к этому сложно! Когда на одну интересную мысль всегда найдется 10 штук всяких глупостей

2) люди разной специализации (dba программисту не товарищ :))
Т.е. если архитектора в DBMS интересует прежде всего адекватность отображения используемой им методологии (т.е. структурной или объектно-ориентированной) на схему целевой DBMS то само собой ему будет недоставать например нормальных scheme и packages (которых нормальных, к стати, в природе не существует), а также возможностей Oracle как application server'а с java. С другой стороны DBA никогда всего этого не оценит. Кроме того найдется несколько фанатиков с теоретическим уклоном которые будут кричать что всему этому в СУБД не место ну и т.д.

3) люди-жертвы маркетинга
В конце концов большая доля наших предпочтений нам так или иначе навязана...
18 май 04, 10:53    [683868]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
Не откатит тут ничего Оракл, при уровне Read Committed. Можете проверить
Бегом, читать хоть Тома Кайта что ли... Или самому экспериментировать.

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

Откуда уникальность следует, откуда сервер узнает, что поле уникально?
Дело в том, что Сиквелу не нужно знать, что поле уникально. В случае необходимости он умеет выдавать одинаковые записи, он просто преобразует этот запрос к виду: select top 1 * with ties from t order by a, что будет полностью эквивалентно исходному запросу.
Насколько мне известно, явной команды, чтобы добиться похожего в Оракле нет, но это не должно служить препятствием оптимизатору, чтобы выполнить запрос по подобной же схеме.

Как он откатит первый запрос ? Явно (с exception) или "где-то там у себя внутри"
У себя внутри.

В этом смысле да, оракловский RС это скорее "изолированность образа" на уровне оператора
Во-во, об чем и речь, причем не всегда корректная.
18 май 04, 12:22    [684222]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Merle
...причем не всегда корректная.

Имеется ввиду "snapshot too old" или что то другое?
18 май 04, 14:55    [684893]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Drema
Member

Откуда: Москва
Сообщений: 249
Про Oracle и MSSQL

Там сравнивается немного старая версия Oracle, но с точки зрения конкретного программиста, выглядит все верно.
18 май 04, 16:04    [685189]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
Merle
Например ограничение на длинну записи в 8K, что соответствует размеру страницы, позволяет сиквелу в некоторых случаях сканировать индексы гораздо эффективнее, чем это делает тот же Оракл.


Например?
18 май 04, 17:28    [685501]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
Drema
Там сравнивается немного старая версия Oracle, но с точки зрения конкретного программиста, выглядит все верно.

С точки зрения конкретного туповатого программиста.
18 май 04, 17:37    [685530]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gt.
Guest
автор
Там сравнивается немного старая версия Oracle, но с точки зрения конкретного программиста, выглядит все верно.


не знаю на счет конкретных программистов, но автор выглядит ламером :)

SQL>  create global  temporary table tst(f1 varchar2(100))  on commit delete rows ;

Table created.

SQL> insert into tst select table_name from all_tables ;

1667 rows created.

SQL> select count(*) from tst ;

  COUNT(*)
----------

1667 SQL> commit ; Commit complete. SQL> select count(*) from tst ; COUNT(*) ----------
0
18 май 04, 17:39    [685539]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
Имеется ввиду "snapshot too old" или что то другое?
Другое, там не удачная оптимизация откатов при RC...

Например?
Из-за возможности наличия строк вылезающих за одну страницу, Оракл не может использовать упреждающее чтение при выдаче отсортированного набора при выборке диапазонов индекса, и вынужден читать страницы в их реальном физическом порядке, с последующей сортировкой в памяти, в то время как MS достаточно просто просканировать индекс.
18 май 04, 18:32    [685681]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
create global  temporary table tst(f1 varchar2(100))  on commit delete rows;
Одно это действие (необходимость явного создания) уже портит картину.
18 май 04, 20:21    [685851]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Что значит "неудачная реализация" или тем паче "неправильная" применительно к Ораклу? Оракл и Мелкий-мягкий-скуль это две различные СУБД. И конкурентный доступ к данным в них реализован по разному. Ибо мелкософт/сайбэйс блокирует данные при чтении а оракл и интербэйс используют различные версии данных. В стандарте это поведение жестко не оговаривается. Да даже если бы и оговаривалось, все обсуждаемые СУБД появились задолго до всяческих стандартов, и менять их поведение рискуя "поломать" совместимость с уже написанными приложениями ради какого-то стандарта никто не будет. Этот стандарт мало того что никому не нужн, он еще и дурно написан, ибо допускает двусмысленное толкование и различные реализации.

А масштабируется Оракл лучше чем мелкомягкий, именно потому, что Оркл ничего не блокирует при чтении (кроме случая когда есть "удаленный запрос" из другой СУБД). А в мелкософтном скуле нужно при join указывать nolock чтобы добиться хоть какой-то масштабируемости. Причем происходит эта масштабируемость в ущерб consistency данных. Почитайте умного дядьку Т. Кайта, у него все написано. А если не знаете Оракла - так не ругайте то, в чем не разбираетесь.

И "дешевизна" мелкософтная тоже обычно боком выходит, как только проект принимает сколько-нибудь серьезные размеры. Ибо поскольку мелкософтная СУБД не тянет большое количество одновременных транзакций, то приходится ставить сервер приложений с монитором транзакций (MS Transaction server или Tuxedo или что-то в этом роде). Возникает закономерный вопрос, а нафига нам такая СУБД, которая под серьезной нагрузкой ложится, так что приходится ставить TP monitor? Ведь при такой архитектуре можно и вообще без СУБД обойтись, индекс-организованными файлами например. На мэйнфреймах так и делали, кстати, в те времена когда реляционных СУБД еще не было.

А и еще забыл: Оракл рулит адназначна :)
18 май 04, 20:54    [685876]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
>Merle
Из-за возможности наличия строк вылезающих за одну страницу, Оракл не может использовать упреждающее чтение при выдаче отсортированного набора при выборке диапазонов индекса, и вынужден читать страницы в их реальном физическом порядке, с последующей сортировкой в памяти, в то время как MS достаточно просто просканировать индекс.

Вот я по большому счету ничего не смыслю в MS SQL, поэтому не берусь утверждать подобные вещи о том, в чем не разбираюсь.

1. Oracle не использует понятия страницы
2. Строка индекса в Oracle всегда располагается в одном блоке
3. Oracle не использует упреждающее чтение - это дело ОС
4. Oracle при доступе index_ss (index skip scan) читает блоки в том порядке, в котором они логически связаны. При этом выполняется мультиблочное чтение, после которого сортировка требуется только при параллельном доступе к индексу.

Т.е. Ваш пример неверен.
18 май 04, 21:31    [685907]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gt.
Guest
автор
Одно это действие (необходимость явного создания) уже портит картину.

это не необходимость, а признак ума. если ума нет - можно использовать конструкцию create as select
18 май 04, 23:05    [685941]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Merle
Например ограничение на длинну записи в 8K, что соответствует размеру страницы, позволяет сиквелу в некоторых случаях сканировать индексы гораздо эффективнее, чем это делает тот же Оракл.

Что-то мне непонятно как ограничение длинны записи данных в 8к может влиять на чтение индексов, общая длинна ключа которого ограничена 900 байтами.
А если бы в Оракле было ограничение длинны ключа(или оно есть?) - он бы так же эффективно работал с индексами?
19 май 04, 09:16    [686182]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Зл0й
Ибо поскольку мелкософтная СУБД не тянет большое количество одновременных транзакций, то приходится ставить сервер приложений с монитором транзакций (MS Transaction server или Tuxedo или что-то в этом роде). Возникает закономерный вопрос, а нафига нам такая СУБД, которая под серьезной нагрузкой ложится, так что приходится ставить TP monitor?


А большое количество - это сколько?
Я не для поспорить - чтобы понятно все было :)

-- Tygra's --
19 май 04, 10:01    [686279]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
Gt
это не необходимость, а признак ума. если ума нет - можно использовать конструкцию create as select
Чьего ума? :)
Вот и использовали бы в данном примере.
Или, как обычно, еще десять раз поправитесь ;)
19 май 04, 10:31    [686349]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32174
2Зл0й
автор
А если не знаете Оракла - так не ругайте то, в чем не разбираетесь.


А если не знаете MSSQL - так не ругайте то, в чем не разбираетесь. :-)

автор
Ибо поскольку мелкософтная СУБД не тянет большое количество одновременных транзакций, то приходится ставить сервер приложений с монитором транзакций (MS Transaction server или Tuxedo или что-то в этом роде).

Ну это-же полный бред! Это-же абсолютно не связанные вещи - большое количество одновременных транзакций и использование монитора транзакций! По крайней мере в данном случае - никакого распределения транзакций между серверами (как в случае типичного использования Tuxedo и мэйнфрэймов) не происходит. Напоминает статьи о ИТ-технологиях в МК или женском журнале :-)
Вы вот посмотрели-бы, как MS использует MS Transaction server в "рекордных", типа TPC-C тестов, приложениях - использутся-ли там вообще управление транзакциями из клиента (в данном случае MS Transaction server-а)? Короче, если в описании TPC-C теста написано монитор транзакций - MS Transaction server или COM+, не верьте глазам своим :-)

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

У вас есть какие-то аргументы? Скажем, статистика внедрений SAP - 100 инсталяций на MSSQL, 100 - на оракле (разумеется, при одинаковой нагрузке), и в среднем решение на MS требует на ХХХ процентов более дорогой аппаратуры для достижения того-же времени отклика?

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

Миф о хорошей нагрузочной способности оракла по сравнению MSSQL вызван простой вещью - на нём больше производительность при программировании в стиле классических процедурных языков. Программист, ранее писавший на С++, бэйсике или джаве, будет успешно ваять сложный код на PL/SQL, и этот код будет работать. И в большом проекте, кроме таких программистов, нужен бужет всего один спец по ораклу. Конечно, если все будут спецами, то работать будет лучьше, но и так будет, пусть медленнее и ненадёжнее.

А MSSQL такого не прощает. Разрабатывать приложение должны специалисты. Идеально, если они до этого процедурными языками не пользовались :-) Ну такое не реально, но для "ломки" процедурного программиста нужен хотя-бы год, а проекты у нас ведь как делаются? Кто есть, тот и делает.

автор
А и еще забыл: Оракл рулит адназначна :)

Ну наконец-то, хоть один аргумент!!!
19 май 04, 10:39    [686373]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6905
alexeyvg
Короче, если в описании TPC-C теста написано монитор транзакций - MS Transaction server или COM+, не верьте глазам своим :-)


А результатам такого теста верить можно?

alexeyvg
Миф о хорошей нагрузочной способности оракла по сравнению MSSQL вызван простой вещью - на нём больше производительность при программировании в стиле классических процедурных языков. Программист, ранее писавший на С++, бэйсике или джаве, будет успешно ваять сложный код на PL/SQL, и этот код будет работать. И в большом проекте, кроме таких программистов, нужен бужет всего один спец по ораклу. Конечно, если все будут спецами, то работать будет лучьше, но и так будет, пусть медленнее и ненадёжнее.

А MSSQL такого не прощает. Разрабатывать приложение должны специалисты. Идеально, если они до этого процедурными языками не пользовались :-) Ну такое не реально, но для "ломки" процедурного программиста нужен хотя-бы год, а проекты у нас ведь как делаются? Кто есть, тот и делает.


Ну и откуда Вы таких глупостей несусветных набрались? Вы видели когда-нибудь приложения, написанные для Oracle людьми, которые ничего не понимают в ём? Я видел, и видеть больше не хочу.
19 май 04, 10:52    [686413]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
c127
Guest
2 Merle

>Из факта наличия ограничений делать вывод об одинаковости ядра сервера можно только при очень бурной фантазии.. ;)

Объяснял же много раз, что не просто ограничений, а СПЕЦИФИЧЕСКИХ ограничений, т.е. уникальных, существующих только в MSSQL и сайбейз ASE (число таблиц в запросе). Вроде еще есть в SAP/DB, но это побочный продукт, никто всерьез не надеялся, что у него найдутся пользователи.

>На самом деле, ограничения позволяют в определенных ситуациях применять более эффективныые алгоритмы. Например ограничение на длинну записи в 8K, что соответствует размеру страницы, позволяет сиквелу в некоторых случаях сканировать индексы гораздо эффективнее, чем это делает тот же Оракл.

Этто несерьезно! (C) Других размеров страницы в MSSQL-е не бывает? В ASA например можно выбрать 1024,2048,4096,8192,16384,32768 байт. А если бывают, то все рассуждения ломаются. К тому же объявление varchar поля выглядит: varchar(N), где N - максимальная длина поля и это N можно было бы использовать при оптимизации запросов, если очень хочется. Но мне вообще не очень верится в наличие оптимизации такого типа.

А вот код писать с такими ограничениями немного проще. Сайбейз когда-то на заре базостроения написал, так до сих пор и тянется.

>Дело в том, что Сиквелу не нужно знать, что поле уникально.

Тогда не стоило об этом вспоминать, эта информация бесполезна в смысле оптимизации запроса.

>В случае необходимости он умеет выдавать одинаковые записи, он просто преобразует этот запрос к виду: select top 1 * with ties from t order by a, что будет полностью эквивалентно исходному запросу.

Из Ваших объяснений непонятно, какой запрос все-таки начинает выполнятся. Запрос не может меняться в процессе выполнения, а до начала сервер не знает, уникально поле или нет, т.е. не знает, нужно ли использовать "with ties".
19 май 04, 11:12    [686476]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Merle
Другое, там не удачная оптимизация откатов при RC...

Хотелось бы ссылочку или пояснение.
19 май 04, 11:12    [686479]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Mer
Guest
Поясню..

1. Oracle не использует понятия страницы
Смело.. ;) А дисковый обмен у него побайтно происходит?

3. Oracle не использует упреждающее чтение - это дело ОС
Дело ОС - вмешиваться в работу СУБД как можно меньше, особенно в вопросах кеширования и дискового обмена, потому как характер нагрузки у СУБД немного отличается от обычных приложений.
MSSQL умеет использовать внутренние страницы индекса для оптимизации путем предварительной выборки, техника называется readahead.
И реализации этого очень помогает ограничение записи размером страницы, поскольку в противном случае для чтения целой строки приходилось бы прыгать по цепочке страниц, составляющих одну строку - простые реализации таких цепочек не позволяют делать предварительную выборку..

4. Oracle при доступе index_ss (index skip scan) читает блоки в том порядке, в котором они логически связаны.
Не всегда. В виду отсутствия readahead, для чтения цепочки страниц индекса он должен читать страницы по одной. На относительно маленьких объемах он действительно сканирует диапазоны как есть, но начиная с какого-то момента это становится не выгодным - readahead нет, а это серьезная оптимизация - и он начинает читать страницы в их реальном физическом порядке с последующей сортировкой, но это все равно хуже, чем сканирование индексов с использованием упреждающего чтения.
19 май 04, 11:39    [686608]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Merle

И реализации этого очень помогает ограничение записи размером страницы, поскольку в противном случае для чтения целой строки приходилось бы прыгать по цепочке страниц, составляющих одну строку - простые реализации таких цепочек не позволяют делать предварительную выборку..
...
4. Oracle при доступе index_ss (index skip scan) читает блоки в том порядке, в котором они логически связаны.
Не всегда. В виду отсутствия readahead, для чтения цепочки страниц индекса он должен читать страницы по одной.

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

Прымер:
SQL> show parameter db_block_size;

NAME                                 TYPE    VALUE
------------------------------------ ------- ------------------------------

db_block_size integer 8192 SQL> create table test( c1 char(2000), c2 char(2000) ,c3 char(2000), c4 char(2000), c5 char(2000) ); SQL> create index test_i on test( c1,c2,c3,c4,c5,c6); create index test_i on test( c1,c2,c3,c4,c5,c6) * ERROR at line 1: ORA-01450: maximum key length (3218) exceeded

P.S. и про "не удачная оптимизация откатов при RC..." хотелось бы всё таки пояснение.
19 май 04, 14:17    [687265]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Drema
Member

Откуда: Москва
Сообщений: 249
автор
не знаю на счет конкретных программистов, но автор выглядит ламером :)

SQL> create global temporary table tst(f1 varchar2(100)) on commit delete rows ;


Ну, вы америку то не открыли :) Это и остается только в качестве примеров, а на деле большинство предпочитают курсоры.
В MSSQL есть declare @table (pole int null), такая таблица вообще в памяти хранится, а не в tempdb.

Кстати, создавать клиента БД + серверную часть - это не равно просто администрированию того или иного сервера. Безотносительно задачи можно сделать любой запрос и разницы то особой не видно. С простыми админами вообще бесполезно о чем либо говорить... А вот когда начинаешь строить все вместе, то накладываются определенные ограничения - то можно, то нельзя.. Мне, например, хотелось сделать одного клиента и для MSSQL и для Oracle, но после ознакомления с Oracle, я к глубочайшему сожалению обнаружил, что мне придется переписывать всего клиента, потому как подходы разные.. например, мне надо в одном батче выполнить и процедуру сервера и использовать переменнные из нее и в нее, еще выполнить select и еще кучу всего.. на MSSQL все получается на ура (и клиент получается абстрагированный от бизнес-логики), а в Oracle надо заморачиваться с вызовом каждой части, что принципиально не подходит.
19 май 04, 18:22    [688326]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Drema
Member

Откуда: Москва
Сообщений: 249
автор
Одно это действие (необходимость явного создания) уже портит картину.

это не необходимость, а признак ума. если ума нет - можно использовать конструкцию create as select


Как часто вы используете временные таблицы? И вообще, используете ли?
19 май 04, 18:27    [688343]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2Drema
Я временные таблицы (или SPID - разделенные их заменители) использую постоянно.
Во многих случаях алгоритмы итеративны, их нельзя заменить одним эквивалентным запросом. В некоторых случаях подобная замена возможна, но является слишком неоптимальной, приходится бить один запрос на несколько с промежуточными результатами, которые приходится где-то хранить. А где? Во временных таблицах.
19 май 04, 18:48    [688404]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 26   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить