Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 13   вперед  Ctrl
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
To Oracle-адепты:
Народ, а чем вы будете крыть, когда Yukon выйдет, где версионность "похитрее", чем версионность в Oracle ;)
У уважаемого Yo! в кормане всегда останется N-ое количество "фичей", которых не будет в MSSQL, которыми он будет пугать доверчивых форумян
Зато MSSQL станет сильно .NET-интегрированным. Sybase тоже чего-нибудь придумает. DB2 тоже подтянется.

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

Вот за что мы-то все здесь бьемся, когда на пятки наступают "Фаил-Мейкеры"?

P.S. Навеяно борьбой с "Файл-мейкерством" в соседнем форуме.
23 сен 04, 19:43    [983741]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2Leonid
А вот нефиг! Выйдет Юкон - тогда и поглядим, чо там езь, а чего там нету. А то вот уже бывало - наобещано куча полезных фич, токо юзать их тяжко.

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

Posted via ActualForum NNTP Server 1.0

23 сен 04, 19:53    [983753]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
автор
А если подумать: можно же эту сумму постоянно пересчитывать при вводе каждого выигрыша - и не надо постоянно муллионы складывать и спокойно без версионности можно.


похоже вы не поняли. смысл в том что когда ты эту сумму пересчитываешь то ее нужно куда-то записать, но тебе это сделать может помешать длинный отчет который читает этот баланс и кучу других таблиц. а задерживать писателя никак нельзя. тогда что делает ASCRUS - выносит этот баланс в другую таблицу, но проблемы это не решает транзакция то одна. тогда он делает ход "конем" выносит запись суммы баланса в другую транзакцию, раз в одной не получается - делает некую очередь, которая уже в отдельной транзакции. если очередь с новым балансом натыкается на длинный отчет, то не беда - она может и подождать хоть весь "банковский день".
т.е. ASCRUS добился того что делает оракл, но гораздо дешевле, работает небось хоть на 486 с 16мб. в принципе чем не решение ... еслиб не "банковский день"
23 сен 04, 20:13    [983781]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
Народ, а чем вы будете крыть, когда Yukon выйдет, где версионность "похитрее", чем версионность в Oracle ;)[/quot]

когда в юконе будет версионость вместе с блокировками, вместо оракловой жавы дотнет, t-sql дотянет до pl/sql и встрят профайл и автономные транзакции и т.д, Yo! нажмет next в чудо визарде и с помпой смигрирует на mssql (если нет разницы зачем платить больше ? (C) не мое ... ), заберет себе разницу в лицензиях и на эти деньги нажрется, и сядет нетрезвый за руль и ... глупо умрет :) и знаете кто будет в этом виноват ? я по глазам вижу - знаете :)
23 сен 04, 20:22    [983796]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Давайте рассмотрим в общем случае как обрабатываются транзакции, чтобы всем стало понятно что "доморощенный" механизм предложенный уважаемым ASCRUS есть ничто иное как самодельный монитор транзакций. Я не говорю что он работать не будет - будет он работать, только плохо и вызывать будет немерянную головную боль у разработчиков.

Предположим что есть "поток транзакций", то есть с течением времени происходят запросы некоторых данных и запросы на их изменение. Требуется создать у клиентов порождающих эти запросы иллюзию того что они монопольно имеют доступ к данным. Иначе они будут друг другу "мешаться". Любому мало-мальски грамотному специалисту по СУБД известны такие понятия как "грязное чтение", "фантомы" итп. Эта "иллюзия" в случае чтения называется "согласованное чтение" (consistent read).

В случае если мы испольщуем СУБД как обработчик транзакций, то СУБД нам гарантирует некоторую семантику их выполнения. Семантика зависит от уровня изоляции транзакций. Более низкие уровни изоляции, например read commited, допускают некоторые виды несогласованности данных. Более высокий уровень serializable этого не допускают. В любом случае, СУБД нам гарантирует некое поведение, зависящее от уронвня изоляции. Например в случае serializable СУБД нам гарантирует что все данные которые мы читаем, будут "по состоянию на время начала читающей транзакции". Что это значит? Это значит что они во-первых commited до начала читающей транзакции, во-вторых любые изменения этих данных произошедшие после начала нашей транзакции нам не видны.

Что же мы видим в решении предложенном ASCRUS ? Есть ли там гарантия согласованности данных даваемая нам СУБД? Нет её. Есть некие таблицы, где мы помечаем данные timestamp'ом который потом вручную проверяем. То есть забота о согласованности данных на момент времени возложена на приложение а не на СУБД. Чтобы получить согласованные данные мне нужно в запросе указать этот самый timestamp.

Теперь разберемся с писателями. В решении предложенном ASCRUS мы попросту
- выстроили всех писателей в очередь
- завели один-единственный теневой (background) процесс который эти запросы выполняет.
Чем не MQ "в миниатюре"? Идея та же, выполнять транзакции по отной. Сериализовать то бишь. К чему приведет такое решение? Чем больше объем транзакций в еденицу времени (чем плотнее поток) тем больше время отклика. Ибо процесс один, а транзакций много. Будет масштабироваться такое решение? Не будет.

Современные СУБД имеют гораздо более совершенные механизмы обработки транзакций чем постановка оных в очередь и последовательое выполнение. По сути, физическая сериализация аналогична блокировке "на всю базу целиком". СУБД же умеют блокировать только те ресурсы которые нужны данной транзакции, да еще и выполняют их параллельно. Некотороые, "особо продвинутые" СУБД даже поддерживают механизм версий. СУБД - гораздо более прогрессивный механизм обработки транзакций чем очередь. К сожалению у СУБД-блокировщиков есть недостаток: они не позволяют одновременно читать данные на уровне serializable и писать эти данные. Как с этим бороться:
- Выстроить транзакции в очередь и выполнять последовательно
- Придумать собственный механизм "версий" данных, например добавив во все таблицы timestamp.

Как уже было сказано выше, производительность такой системы будет ерундовая. Во-первых из-за выполнения транзакций "по очереди" во-вторых объемы данных будут расти не по дням а по часам. Версии-то надо где-то хранить. Мы храним их в таблицах. Можно, конечно, убивать все записи где timestamp'у отроду день и больше. Это начинает очень сильно напоминать PostGreSQL где бедным администраторам приходится постоянно биться со сборкой мусора. Там тоже старые версии храняться в таблицах вместе с новыми, только timestamp там неявный.

В общем, производительность решения предложенного ASCRUS ИМХО будет крайне низкой, а головная боль связанная с поддержкой - постоянной.

А теперь отвечу на вопрос "разработчик я или администратор". Я разработчик с опытом администрирования. Поэтому я понимаю, что системы которые я разрабатываю, потом придется кому-то поддерживать. Я дорожу своей репутацией в компании где я работаю. Команда DBA меня уважает, поскольку мы с ними "говорим на одном языке" и системы которые я разрабатываю поддерживаются достаточно спокойно, и без головных болей. Потому, что все продумано и протестировано заранее. Поэтому если мне что-то от DBA надо, я все получаю сразу, без задержек и волокиты. А другие разработчики жалуются на DBA. Ну а в development environment я сам себе DBA. Раньше я сам был production DBA, просто надоело с пейджером ходить. Хочется покоя.
23 сен 04, 21:08    [983848]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Зл0й

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

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

Зл0й

Соответсвенно вопрос, если Оракл - не версионник, тогда кто тогда версионник?


Интербаза. И файерберд пророк его.

Зл0й

А что будет в Юконе - мы поглядим когда его сделают. Помнится Сайбэйс тоже когда-то обещал блокировку на уровне записи. Обещанного три года ждут. В случае с Сайбэйсом даже дольше.


Че за поклепы ? Есть в Sybase -е row level locking , уже года три как.
(с версии 11.9)
23 сен 04, 21:56    [983895]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
автор
Я бы сказал - нашлепка сверху. Изначально же в Oracle не было этой фичи с получением данных из сегмента отката. Потом добавили. Кстати, что они при этом физическую структуру этого сегмента отката переделали, чтобы оптимизировать для чтения - это еще вопрос. Конечно, он мог быть изначально оптимизированным и для чтения.


Сможешь вспомнить, когда, в каком году эта "нашлепка" была сделана?
24 сен 04, 00:56    [983997]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Насчет изоляций спорить прекращаю. Хочу только сказать, что указанные опонентами проблемы на блокировочниках для serializable решаются:
1. С помощью временных локальных и глобальных таблиц
2. С помощью автоматически пересчитываемых аггрегатных постоянных таблиц
3. С помощью специального значения timestamp
4. Проектирование входящих таблиц так, чтобы в них только добавлялась, но редко изменялась и тем более удалялась информация
5. С помощью анти-фантомной блокировки, сужающей круг блокирующихся записей, если СУБД это умеет делать и присутствует подходящий уникальный индекс
6. Тщательным продумыванием применения наиболее подходящих для разных задач уровней транзакций
7. Проектированием "коротких" транзакций
8. Созданием таблиц-буферов
9. Созданием параллейных потоков с помощью событий и агентов расписаний.

SergSuper
Кстати, правильно ли я понял что эта версионность спасает только если данные "для посмотреть"? Что-то менять на основании этих данных я не могу - хоть они и закоммиченные, но всё равно могут быть устаревшие.

Хотелось бы услышать комментарии специалистов - неужели это правда ? Тогда какой толк в версионности Оракла, если согласованость данных у меня будет только внутри транзакции и не будет совпадать с реальными данными в БД ? Как вообще тогда решать задачи и реализовывать бизнес-логику обработки и расчета информации на хранимых процедурах PLSQL ? Я честно говоря в таком случае даже не представляю себе, как с этим можно жить. Наверное действительно кто что знает, тот так и думает :)
24 сен 04, 02:19    [984020]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
ASCRUS
Насчет изоляций спорить прекращаю. Хочу только сказать, что указанные опонентами проблемы на блокировочниках для serializable решаются:
1. С помощью временных локальных и глобальных таблиц
2. С помощью автоматически пересчитываемых аггрегатных постоянных таблиц
3. С помощью специального значения timestamp
4. Проектирование входящих таблиц так, чтобы в них только добавлялась, но редко изменялась и тем более удалялась информация
5. С помощью анти-фантомной блокировки, сужающей круг блокирующихся записей, если СУБД это умеет делать и присутствует подходящий уникальный индекс
6. Тщательным продумыванием применения наиболее подходящих для разных задач уровней транзакций
7. Проектированием "коротких" транзакций
8. Созданием таблиц-буферов
9. Созданием параллейных потоков с помощью событий и агентов расписаний.


как все сложно то

ASCRUS

SergSuper
Кстати, правильно ли я понял что эта версионность спасает только если данные "для посмотреть"? Что-то менять на основании этих данных я не могу - хоть они и закоммиченные, но всё равно могут быть устаревшие.

Хотелось бы услышать комментарии специалистов - неужели это правда ? Тогда какой толк в версионности Оракла, если согласованость данных у меня будет только внутри транзакции и не будет совпадать с реальными данными в БД ? Как вообще тогда решать задачи и реализовывать бизнес-логику обработки и расчета информации на хранимых процедурах PLSQL ? Я честно говоря в таком случае даже не представляю себе, как с этим можно жить. Наверное действительно кто что знает, тот так и думает :)


В чем проблема то? Программист пишет код, реализует бизнес-логику и в 90% случаев не забивает себе голову всякой чепухой из вышеотквоченного списка.
24 сен 04, 09:04    [984174]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
to Leonid

Народная мудрость гласит, что если бы у бабушки были я.....а,
то она бы была дедушкой.
24 сен 04, 10:11    [984365]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
killed
автор
Я бы сказал - нашлепка сверху. Изначально же в Oracle не было этой фичи с получением данных из сегмента отката. Потом добавили. Кстати, что они при этом физическую структуру этого сегмента отката переделали, чтобы оптимизировать для чтения - это еще вопрос. Конечно, он мог быть изначально оптимизированным и для чтения.


Сможешь вспомнить, когда, в каком году эта "нашлепка" была сделана?


Я лично помню, что отдельный сегмент отката ( назывался before image)
был еще в версии Oracle 5 это район где-то 82-85 годов.

Слышал, что были люди которые работали с 4 версией.
24 сен 04, 10:19    [984394]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
killed
[quot ASCRUS]Насчет изоляций спорить прекращаю. Хочу только сказать, что указанные опонентами проблемы на блокировочниках для serializable решаются:
1. С помощью временных локальных и глобальных таблиц
2. С помощью автоматически пересчитываемых аггрегатных постоянных таблиц
3. С помощью специального значения timestamp
4. Проектирование входящих таблиц так, чтобы в них только добавлялась, но редко изменялась и тем более удалялась информация
5. С помощью анти-фантомной блокировки, сужающей круг блокирующихся записей, если СУБД это умеет делать и присутствует подходящий уникальный индекс
6. Тщательным продумыванием применения наиболее подходящих для разных задач уровней транзакций
7. Проектированием "коротких" транзакций
8. Созданием таблиц-буферов
9. Созданием параллейных потоков с помощью событий и агентов расписаний.


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


А знаете что будет потом, если у вас более или менее серьезная контора?
После IT Аудита компании аудиторы найдут у вас рисков на пару лимонов зеленых денег и в результате руководсво почувствовав как зашаталось кресло, напомнит вам про велосипед и все что оно про вас думает.
Хорошо если вас не уволят.

Потому как с вами никто не будет считаться , если стоимость акций компании из-за непрохождения аудита упадет.
Просто произведут "зачистку" и все.
Таковы реалии сегодняшнего дня.
24 сен 04, 10:29    [984431]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
killed

В чем проблема то? Программист пишет код, реализует бизнес-логику и в 90% случаев не забивает себе голову всякой чепухой из вышеотквоченного списка.

Ничего себе чепуха. Вот обьясните мне непонимающему что будет в следующей ситуации:
1. Есть Table1 и связанная с ней по FOREIGN KEY Table2.
2. Транзакция A начала добавлять записи в Table2, ссылаясь на родителей, уже существующих в Table1
3. Чуть позжее транзакция B начала выполнять запрос:
DELETE FROM Table
WHERE Table1_id NOT IN (SELECT Table1_id FROM Table2);
4. Пока транзакция A продолжала возиться, транзакция B выполнила COMMIT -ведь Оракл ничего не блокирует и подзапрос читатель B не будет ждать писателя A, а просто успешно удалит записи из таблицы Table1, на которые ссылаются добавляемые в этот момент из транзакции A, ведь правда ?
5. Транзакция A выполняет наконец таки COMMIT, делает CHECK ON COMMIT (кстати проверки всегда только на коммите выполняются ?), получает ошибку FOREIGN KEY на несуществующих родителей и откатывается.

Я все правильно понял или у Оракла есть механизм регулирования таких ситуаций ?
24 сен 04, 10:39    [984469]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
EugeneS
Вас послушать, так у нас в странах СНГ только и работают проекты, обслуживающие огромные хранилища и тысячи конкурирующих сессий. Все Вами сказано применимо в России настолько к малой части проектов, что Ваш пример с электродрелью мягко говоря не удачен. Наоборот, я как раз все больше встречаю примеров несоответствующего задаче выбора платформы Оракл, там где и работает не спеша всего сотня пользователей и база данных размером даже до сотни гигабайт не дотягивает. Переворачивая Ваш пример в таком случае такое использование Оракла сильно смахивает на попытку насадить электродрель в качестве привода стеклоочистителя, где как раз был бы более уместен маленький компактный моторчик. Мой например круг задач вообще не требует ничего, что приводилось выше в качестве преимущества версионной модели перед блокировочной. Наоборот, для моих проектов в качестве важнейших требований выдвигаются встраиваемость в приложение (тиражность), низкие требования к аппаратной части, нулевое администрирование, быстрая и эффективная работа, надежность и расширенная функциональность, позволяющая реализовывать средствами ХП сложную бизнес-логику расчетов. В данном случае для таких задач главное быстро и правильно посчитать, в них существуют понятия расчетный и закрытый период, отчеты делаются не в реалтайме и участвует в них уже посчитанная и уже неизменяемая информация. Скажите с чего это мне друг по этим требованиям вдруг менять платформу и с Sybase ASA, у которого купив Platinum Disk я могу встраивать ее бесплатно в свое приложения, платя Sybase только за пользовательские лицензии , уходить на Оракл, отказываясь от минимальных аппаратных требований (P1-166 32RAM), нулевого администрирования, офф-лайн репликации и заметно поднимая цену продукта для клиента ? Зачем пихать Оракл в те дырки, где ему не место ? И зачем необоснованно в общем смысле обвинять блокировочники ? Как я уже и говорил, в базах данных существуют ниши, где блокировочники гораздо уместнее и эффективнее. Например на PocketPC и PalmOS версия UltraLite ASA весит всего 64 кб и имеет довольно таки неплохие возможности, близкие к ее полной версии. Было бы забавно посмотреть на версионный Оракл на КПК, на БД которого работает всего один пользователь, а Оракл делает сегменты отката :)
24 сен 04, 10:59    [984556]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
aston
Member

Откуда:
Сообщений: 227
автор
Ничего себе чепуха. Вот обьясните мне непонимающему что будет в следующей ситуации:
1. Есть Table1 и связанная с ней по FOREIGN KEY Table2.
2. Транзакция A начала добавлять записи в Table2, ссылаясь на родителей, уже существующих в Table1

На записи(-ях) в Table1 Oracle в блоках данных поставил блокировку.


3. Чуть позжее транзакция B начала выполнять запрос:
DELETE FROM Table
WHERE Table1_id NOT IN (SELECT Table1_id FROM Table2);

Лезет в блок данных, наталкивается на блокировку и ждет на блокировке.


4. Пока транзакция A продолжала возиться, транзакция B выполнила COMMIT -ведь Оракл ничего не блокирует и подзапрос читатель B не будет ждать писателя A, а просто успешно удалит записи из таблицы Table1, на которые ссылаются добавляемые в этот момент из транзакции A, ведь правда ?

Oracle блокирует. Будет ждать. Команда DELETE - это не читатель.


. Транзакция A выполняет наконец таки COMMIT, делает CHECK ON COMMIT (кстати проверки всегда только на коммите выполняются ?), получает ошибку FOREIGN KEY на несуществующих родителей и откатывается.

Нет никакого CHECK ON COMMIT. Никогда проверки не выполняются при COMMIT'е. Все проверки выполняются по факту. Не получит ошибку.
24 сен 04, 11:03    [984570]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Guest_2
Guest
автор
В результате имеет увеличение стоимости проекта,
то есть деньги которые можно было бы заплатить за нормальный продукт, и не страдать, вы просто получите сами.

А без словоблудия, обосновать свои умозаключения получится?

PS. К сожалению обоснованной критики ASCRUS'a у Yo!, Зл0го и Вас не получается.
24 сен 04, 11:19    [984653]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
onstat
Guest
ASCRUS
killed

В чем проблема то? Программист пишет код, реализует бизнес-логику и в 90% случаев не забивает себе голову всякой чепухой из вышеотквоченного списка.

Ничего себе чепуха. Вот обьясните мне непонимающему что будет в следующей ситуации:
1. Есть Table1 и связанная с ней по FOREIGN KEY Table2.
2. Транзакция A начала добавлять записи в Table2, ссылаясь на родителей, уже существующих в Table1
3. Чуть позжее транзакция B начала выполнять запрос:
DELETE FROM Table
WHERE Table1_id NOT IN (SELECT Table1_id FROM Table2);
4. Пока транзакция A продолжала возиться, транзакция B выполнила COMMIT -ведь Оракл ничего не блокирует и подзапрос читатель B не будет ждать писателя A, а просто успешно удалит записи из таблицы Table1, на которые ссылаются добавляемые в этот момент из транзакции A, ведь правда ?
5. Транзакция A выполняет наконец таки COMMIT, делает CHECK ON COMMIT (кстати проверки всегда только на коммите выполняются ?), получает ошибку FOREIGN KEY на несуществующих родителей и откатывается.

Я все правильно понял или у Оракла есть механизм регулирования таких ситуаций ?


Да есть назвывается
ORA-01555 snapshot too old: rollback segment number string with name "string" too small. И кто то покатится назад.
Для разруливания ситуации придется все делать в serializable.
И таблица будет заблокирована.
Потом вы идеолог проекта пойдет на http://asktom.oracle.com/pls/ask/f?p=4950:8:7028778449259009053::NO::F4950_P8_DISPLAYID,F4950_P8_B:839412906735,Y
Научится искать блокирующие сессии, напишет монитор для их отслкживания,
в код понаставляет commit-ов через строку.
И самое главное что все это будет проиходить после того как проект здан заказчику. И получение дополнительных денег на исправление ситуации не предвидится.

ASCRUS respect!!!!

С уважением, onstat
24 сен 04, 11:25    [984691]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
PL99
Member

Откуда: Moscow
Сообщений: 1367
aston
Нет никакого CHECK ON COMMIT. Никогда проверки не выполняются при COMMIT'е. Все проверки выполняются по факту. Не получит ошибку.
Вы преувеличиваете, не все так плохо в Oracle по сравнению c ASA :-)
Oracle8 Enterprise Edition Documentation Library
DEFERRABLE Constraints
You can specify table and column constraints as DEFERRABLE or NOT DEFERRABLE. DEFERRABLE means that the constraint will not be checked until the transaction is committed. The default is NOT DEFERRABLE.

If you specify DEFERRABLE, you can also specify the constraint's initial state as INITIALLY DEFERRED and thereby start the transaction in DEFERRED mode. Or you can specify a DEFERRABLE constraint's initial state as INITIALLY IMMEDIATE and start the transaction in NOT DEFERRED mode.


Oracle8 Enterprise Edition Documentation Library
To define a unique constraint on a column as INITIALLY DEFERRED DEFERRABLE, issue the following statement:

CREATE TABLE orders
(ord_num NUMBER CONSTRAINT unq_num UNIQUE (ord_num)
INITIALLY DEFERRED DEFERRABLE);


Oracle8 Enterprise Edition Documentation Library
See Oracle8 Administrator's Guide and Oracle8 Concepts for more information about deferred constraints.
24 сен 04, 11:35    [984751]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Зл0й
Например в случае serializable СУБД нам гарантирует что все данные которые мы читаем, будут "по состоянию на время начала читающей транзакции".

Это не так, в случае serializable СУБД нам гарантирует, что в результате выполнения некоторого набора транзакций мы получим результат который соответствует некоторому последовательному выполнению этих транзакций.
В случае чисто-блокировочного механизма реализации менеджера транзакций, все данные которые мы читаем в Serializable будут скорее "по состоянию на момент КОНЦА читающей транзакции".

MasterZiv
Интербаза. И файерберд пророк его.

Это всего лишь один из вариантов реализации менеджера транзакций с версионным механизмом ("Менеджер транзакций на основе упорядочевания по временным меткам с механизмом контроля версий"), но далеко не единственно возможный, я про это уже писал здесь.

автор
Хотелось бы услышать комментарии специалистов - неужели это правда ? Тогда какой толк в версионности Оракла, если согласованость данных у меня будет только внутри транзакции и не будет совпадать с реальными данными в БД ?

1) Неправда, можно я не буду излагать теорию сериализации и механизмы шедулеров с версионным контролем? Желающие всегда это могут найти в сети или в книгах.Concurrency Control & Recovery in Database Systems, By Ph. Bernstein .
2) Что такое "реальные данные в БД"? Предположим у нас блокировочный шедулер, сессия чего то согласовано читает, другае изменяет, но висит на блокировке (выствленной нашей читающей). Первая закончила и показала данные на экран ( в отчет, или запихнула в какую то таблицу), блокировка освобожденя , изменяющая транзакция тут же изменила данные. Мы смотрим на наш экран и видим одни данные, а в базе они уже другие. Таким образом мы в любом случае получаем данные на какой то момент.
Согласованность данных внутри транзакции должна быть "по умолчанию" (это то самое свойство атомарности), а согласованность данных между транзакциями ( изолированность) как раз и обеспечивают менеджеры транзакций всевозможных типов, в том числе и с версионными механизмами, и обеспечит они её могут ( для Oracle например за счет невозможности изменить данные которые были изменены после начала serializable транзакции).
Тут стоит сделать заметку о том, что Oracle уровень Serializable, не совсем настоящий, в теории такой уровень обычно называют Snapshot, поскольку в нем возможны некоторые сценарии нарушающие критерий сериализации.

killed
Программист пишет код, реализует бизнес-логику и в 90% случаев не забивает себе голову всякой чепухой из вышеотквоченного списка.

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

2 All
По поводу преимущества того или иного механизма управления паралельными заданиями, я думаю всегда можно найти задачи которые будут лучше выполнятся на том или другом механизме и если бы был однозначно лучший, другие бы давно вымерли. Реальные же задачи, наверное, всегда лежат где то между этими крайними случаями. Поэтому и интересны планировщики использующие разные механизмы или их комбинации. И Oracle был тут первым, за что ему наверное честь и хвала, но на мой взгляд он остановился в развитии этой модели, особенно в блокировочной части ( во многи наверное потому , что модель получилась очень удачной, но может пора проснутся?).
MS-SQL пытается выйти на эту же тропу, посмотрим, что получится.
24 сен 04, 11:44    [984799]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
ASCRUS
EugeneS
отказываясь от минимальных аппаратных требований (P1-166 32RAM), нулевого администрирования, офф-лайн репликации и заметно поднимая цену продукта для клиента ? Зачем пихать Оракл в те дырки, где ему не место ? И зачем необоснованно в общем смысле обвинять блокировочники ? Как я уже и говорил, в базах данных существуют ниши, где блокировочники гораздо уместнее и эффективнее. Например на PocketPC и PalmOS версия UltraLite ASA весит всего 64 кб и имеет довольно таки неплохие возможности, близкие к ее полной версии. Было бы забавно посмотреть на версионный Оракл на КПК, на БД которого работает всего один пользователь, а Оракл делает сегменты отката :)


Ну если мы разговариваем о P1-166, мне просто нечего сказать.
У меня рабочая станция не первой свежести с P3-700 и 512МБ RAM и что теперь?

Просто если вы уж такой борец за ресурсы, может вам просто перейти на терминальную модель( символьные терминалы ). Она очень дешева, и проще как в управлении, и для своей работы требует всего 9600 но может работать и на 4800.


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


Только не надо про 0 администрирование.
Я все это уже слышал и то Sybase и то что MSSQL не требует админа , и чем это обычно заканчивается, тоже знаю.

Я ничего не буду говорить про КПК это нескольку другая область.

Если бы у меня стояла задача что-то сделать не на Oracle, я бы все же обратил внимание на SAP DB и уж точно не на SYBASE.
В версии SAP DB которая поставляется с SAP есть механизм неблокирующего чтения.


http://]|>http://help.sap.com/saphelp_erp2004/helpdata/en/9b/bbd7fdf55511d6b2f700508b6b8a93/content.htm

автор
Consistent View

liveCache uses consistent views to guarantee read access to an object, independently of any changes being made to the data by other transactions.
A consistent view can extend across one or more transactions (OMS version).
When a user starts a transaction, it is kept until the end of that user’s data view. Any later changes made to the data by other users do not change the data view of the first user.
When an object within a consistent view is accessed for the first time, this object data is copied to the OMS heap. If multiple consistent views want to access the same data, the appropriate data is copied to a separate area of the OMS heap for each consistent view. Ending the consistent view deletes the corresponding data in the OMD heap.


А вот то что касается стоимости.


автор
MySQL AB offers MaxDB under the MySQL AB "dual licensing" model. The complete MaxDB offering is provided free of charge under the Free Software/Open Source GNU General Public License (GPL) and also a commercial license with no open source restrictions.

MaxDB is priced at $49 per named user on single-CPU systems with a minimum of five users. Alternatively, customers may choose to pay $1,490 per CPU, without user limitations. A "named user" is an actual end user who connects to the database directly or indirectly.

MySQL AB provides support to commercial licensees of MaxDB, both for SAP and non-SAP use. Please contact our sales team for more information.


В двух словах это значит, если вы распространяете свой код под GPL ничего не платите.


Согласитесть это выглядит намного привлекательней чем тот "гемор" на которые вы себя обрекли, из-за банального упорства.
24 сен 04, 11:44    [984800]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
PL99
Member

Откуда: Moscow
Сообщений: 1367
EugeneS
Только не надо про 0 администрирование.
Я все это уже слышал и то Sybase и то что MSSQL не требует админа , и чем это обычно заканчивается, тоже знаю.
Поясните,какую именно СУБД от Sybase вы имеете ввиду? ASCRUS, насколько я понимаю, ведет речь об Adaptive SQL Anywhere, которая действительно не требует администрирования.
24 сен 04, 11:54    [984857]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Guest_2
автор
В результате имеет увеличение стоимости проекта,
то есть деньги которые можно было бы заплатить за нормальный продукт, и не страдать, вы просто получите сами.

А без словоблудия, обосновать свои умозаключения получится?
PS. К сожалению обоснованной критики ASCRUS'a у Yo!, Зл0го и Вас не получается.


К хорошему быстро привыкаешь, потому вы и не понимаете то о чем они говорят.

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

Вместо
- просто разработать софт который требует заказчик.

Мы здесь наверно не будет обсуждать, то факт, что мол де у нас "дешевые программеры" или "наберем кучу студентов" , это только ухудшит ситуацию.

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

Скорей всего никто, потому как этоб большие затраты на сопровождение со стороны компании разработчика. Скорей всего вас проигнорируют.
24 сен 04, 11:58    [984869]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
aston
Member

Откуда:
Сообщений: 227
PL99
Вы преувеличиваете, не все так плохо в Oracle по сравнению c ASA :-)

Конечно. DEFERRABLE появилось в 8-ке и, наверное, кто-то ее использует.
24 сен 04, 12:11    [984936]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Guest_2
Guest
автор
Хорошо по-русски.
Вместо того чтобы сосредоточится на разработки бизне-логики проекта, вы вдобавок сосредотачиваетесь на логике самописного монитора транзакций.
Итого имеет
- разработать свой монитор транзакций
- разработать софт который требует заказчик.
Вместо
- просто разработать софт который требует заказчик.

А где Вы увидели в примере ASCRUS'a монитор транзакций?
То что он написал не выходит за рамки, говорю в Ваших же терминах, разработки бизне-логики проекта.
24 сен 04, 12:59    [985134]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
К хорошему быстро привыкаешь, потому вы и не понимаете то о чем они говорят.

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

Вместо
- просто разработать софт который требует заказчик.

Да не делаем мы мониторы транзакций, ну что Вы к ним пристали ? :) Все как то предпочитаем пользоваться существующим механизмом блокировок, который гарантирует нормальную работу уровней изоляций и с помощью блокировок разруливает различные ситуации между читателями и писателями при работе конкурирующих сессий. Так что мы именно разрабатываем софт. Тот пример, что я тут приводил удачный он или нет в проектах я своих не использую, меня спросили как это можно на блокировочнике реализовать, я подал идею. Не надо нас обвинять в том, что мы никогда не делаем. Так как сама постановка примера с точки зрения архитектуры блокировочника не удачная, то соотвествующе и предложенные способы реализации были не самые красивые. И это не говорит о том, что блокировочник ничего не может. Это всего лишь говорит о том, что постановка задачи должна быть изменена на другую, более подходящую под архитектуру блокировочника, но с такой же смысловой нагрузкой. Стоит помнить, что на одну задачу всегда может быть множество решений и как раз важна не СУБД, а специалист, который может для своей СУБД выбрать правильное решение. Вот например, SQL.RU крутиться на MSSQL, и ничего же - вроде как не висим по 2 часа и не ждем при чтении форумов, пока писатели нам блокировки снимут ? :)

автор
Мы здесь наверно не будет обсуждать, то факт, что мол де у нас "дешевые программеры" или "наберем кучу студентов" , это только ухудшит ситуацию.

Нет не будем. Но тот факт, что у Sybase ASA дешевые администраторы, вернее их отсутствие, ставит мои продукты на более конкуретноспособную ступень для распостранения тиражного ПО по сравнению с Ораклом. Все администрирование этой СУБД закладывается проектировщиком на момент проектирования базы данных, ее ядро автоматически балансирует нагрузки в зависимости от кол-ва подключений, исполняющихся запросов, уровней изоляций сессий и даже наполнения содержания БД (статистика). Функциональность WatcomSQL позволяет полностью прописать ответ на любое происходящее событие в базе данных и СУБД, и предпринять нужные действия предупреждающего или управляющего характера. Так же выполнить действия может опытный пользователь через соотвествующие визарды утилит ASA или же можно вынести функциональность администрирования в собственное приложение, осуществляемое опять же с помощью обычных операторов WatcomSQL. В дополнение для администрирования удаленных СУБД есть специальные сервисы, позволяющие производить мониторинг состояния и администрирование СУБД даже когда они в оффлайн, то есть отложенное, что важно и критично для контор, у которых сотрудникик имеют КПК с установленной на них ASA и базой, реплицирующейся с центральным сервером.

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

У меня друг вот с Украины на ASA и PB накатал программу, на которой работают удаленные филиалы их газпрома. Он сейчас в Москве, программа продолжает работать там. По репликациям данные ежесуточно приходят в центр для дальнейшей их обработки. Самое забавное, что их команда ни разу в жизни за 4 года не выехала на какой нибудь удаленный филиал Украины - просто рассылались инсталяции и обновления, этого было вполне достаточно. Причем включить в инсталяцию ASA очень просто как ручками (просто скопировав меньше десятка DLL размером 8 мб и прописав пару строчек в реестре), так и через InstallShield, для которого ASA имеет Merge-пакеты. Думаю этот пример - лучшая рекомендация для СУБД, которая должна работать удаленно или иметь сотни тиражных копий без дополнительного сопровождения.

автор
Согласитесть это выглядит намного привлекательней чем тот "гемор" на которые вы себя обрекли, из-за банального упорства.

Ну Вы еще начните нас как Антон Леонидович убеждать, что мы сами не понимаем, как мучаемся бедные, не видим своего счастья в лице Оракла из за своего банального упорства :) Всего то просто - переходим на Оракл и ни о чем думать больше не надо, как ни спроектируй БД, все равно она поедет, важен администратор, а не проектировщик, поэтому он больше и денег получает, поэтому все дружно при переходе будем менять свою квалификацию :)
24 сен 04, 13:41    [985333]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить