vadiminfoavduТут важна не скорость, а стабильность работы, т.е. отсутствие зависаний и входов-выходов. В данном случае существенно лучше - настолько, насколько версионник лучше блокировочника.

Все же в плане блокировки пишущим пишущего Оракл блокировочник, и зависания таки встречаются на практике. То парни коммит на апдэйт забыли поставить, то индекс на внешнии ключи установить. Во втором случае, к примеру, некоторые операции блокируют изменение структуры таблы. Эти же операции при наличии индекса ничке не блокируют. Ну по крайней мере на 9 с таким сталкивался. Конечно, у Оракла моно быстро найти и исправить.
Кроме того, к зависанию могут приводить и клиентские проги.
Т.е. сказать, что Оракл совсем свободет от этого нельзя: не часто но бывает.

В нашей теперешней системе на Oracle года 4 все было Ок, потом после смены очередной версии
стало вдруг зависать на блокировках записей. Все мозги свернул вместе с разработчиками - ничего найти не можем. Ситуацию долго держать нельзя - система производственная, поэтому и поймать не удается. Единственно написал запрос, который ловит главного виновника - он выходит или нажимает commit и все Ок. Вот это уже конкретно - кривые руки разработчиков.

Dimitry Sibiryakov
avdu
стало вдруг зависать на блокировках записей. Все мозги свернул вместе с разработчиками -
ничего найти не можем.

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


Есть, только для deadlock. А это обычная штатная блокировка строки ...

VolochkovaavduГде-то на заре 1997 года в недрах налоговой службы зародился проект единой системы автоматизации, который позже получил название Система ЭОД. В 2000 году я имел "счастье" лицезреть сей продукт в неком городе на Волге. С какого-то перепугу для реализации проекта выбрали MS SQL 6.5, хотя в то время уже был Oracle 8. Это оказалось фатальным для системы. Внедрение этого продукта стало одной из причин моего покидания сего ведомства. Масштабное внедрение началось в 2001-2002 годах, уже на MSSQL2000. С тех пор и поныне, при посещении своей бывшей работы, я постоянно натыкаюсь на зависание системы. Было поменено несколько серверов, каждый раз покупался все более мощный, сейчас стоит самый мощный из того, что можно найти на Win. В течение времени, пока находишься там, постоянно раздаются возгласы - система зависла, выйдите все и т.п. С интересом ждал момента перевода ее на MSSQL2005/2008, не знаю перевели или нет, но проблема зависаний осталась.
Хороший пример неудачного выбора СУБД и неудачной реализации проекта. И неудачного выбора разработчика.

Вот это куда серьезнее..
SQL 6.5 - 2000 вполне нормальные СУБд для своего времени..
Конечно если написали на теме Акссес и прилинковали таблички, то и оракл бы уронили...
Вопрос не в субд, а в способе применения..
По ходу провалился разработчик - проектировщик..
Причем серьезно..
400 пользователей.. это не торговая тема.. где накладные по 100 - 2000 строк.
Тут куда все легче..

avduПричин неудачи я вижу три

1. Неудачный выбор СУБД (MSSQL тогда - блокировочник)
2. Неудачная структура данных, изначально написанная под блокировочник
3. Неудачный разработчик, что, впрочем, породило и пп.1 и 2.

p.s. Одновременно работающих пользователей > 400

3. надо ставить на 1 и тогда любую субд можно по Ваше описание подвести.

VolochkovaavduГде-то на заре 1997 года в недрах налоговой службы зародился проект единой системы автоматизации, который позже получил название Система ЭОД. В 2000 году я имел "счастье" лицезреть сей продукт в неком городе на Волге. С какого-то перепугу для реализации проекта выбрали MS SQL 6.5, хотя в то время уже был Oracle 8. Это оказалось фатальным для системы. Внедрение этого продукта стало одной из причин моего покидания сего ведомства. Масштабное внедрение началось в 2001-2002 годах, уже на MSSQL2000. С тех пор и поныне, при посещении своей бывшей работы, я постоянно натыкаюсь на зависание системы. Было поменено несколько серверов, каждый раз покупался все более мощный, сейчас стоит самый мощный из того, что можно найти на Win. В течение времени, пока находишься там, постоянно раздаются возгласы - система зависла, выйдите все и т.п. С интересом ждал момента перевода ее на MSSQL2005/2008, не знаю перевели или нет, но проблема зависаний осталась.
Хороший пример неудачного выбора СУБД и неудачной реализации проекта. И неудачного выбора разработчика.

Вот это куда серьезнее..
SQL 6.5 - 2000 вполне нормальные СУБд для своего времени..
Конечно если написали на теме Акссес и прилинковали таблички, то и оракл бы уронили...
Вопрос не в субд, а в способе применения..
По ходу провалился разработчик - проектировщик..
Причем серьезно..
400 пользователей.. это не торговая тема.. где накладные по 100 - 2000 строк.
Тут куда все легче..

avduПричин неудачи я вижу три

1. Неудачный выбор СУБД (MSSQL тогда - блокировочник)
2. Неудачная структура данных, изначально написанная под блокировочник
3. Неудачный разработчик, что, впрочем, породило и пп.1 и 2.

p.s. Одновременно работающих пользователей > 400

3. надо ставить на 1 и тогда любую субд можно по Ваше описание подвести.

Нет, не согласен. Для такой задачи (автоматизация налоговой) 2000 и тем более 6.5,
с которой все начиналось - СУБД откровенно слабые. Недаром ни одной серьезной банковской
системы, для крупных банков, особенно для работы с розницей, вы не найдете на MSSQL, даже
на 2005/2008. На Oracle - сколько угодно. Чтобы не спорить, назовите крупные банковские системы
на MSSQL.

andy stavdu...
На Oracle - сколько угодно. Чтобы не спорить, назовите крупные банковские системы
на MSSQL.
Извините за нескромный вопрос, но неужели Вас на www.google.com забанили ?
Изучаем

А я имел ввиду АБС российской разработки. Итак ...

andy stavdu...
На Oracle - сколько угодно. Чтобы не спорить, назовите крупные банковские системы
на MSSQL.
Извините за нескромный вопрос, но неужели Вас на www.google.com забанили ?
Изучаем

К тому же, помещать рекламу от Microsoft - моветон ...

andy stavdu[quot andy st]К тому же, помещать рекламу от Microsoft - моветон ...
зато открыто рекламировать Oracle - рулез форева? :)

Может мне попросить у Oracle денег за рекламу ?

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

andy stavduandy stavdu...
На Oracle - сколько угодно. Чтобы не спорить, назовите крупные банковские системы
на MSSQL.
Извините за нескромный вопрос, но неужели Вас на www.google.com забанили ?
Изучаем

А я имел ввиду АБС российской разработки. Итак ...
Типа руки российских разработчиков банковского софта лучше заточнены под оракул, чем сиквелсервер?


Мозги ...

Volochkovaavdu
Нет, не согласен. Для такой задачи (автоматизация налоговой) 2000 и тем более 6.5,
с которой все начиналось - СУБД откровенно слабые. Недаром ни одной серьезной банковской
системы, для крупных банков, особенно для работы с розницей, вы не найдете на MSSQL, даже
на 2005/2008. На Oracle - сколько угодно. Чтобы не спорить, назовите крупные банковские системы
на MSSQL.

А Вас никто в чужую веру обращать не собирается.
В мире происходят вещи вне зависимости, верите Вы в них или нет..
Банки до недавнего, а то и по сей день сидят на самописках C# + MSSQL
А есть система RS Balance - Знаете такую? Вообще под новелом крутится на btrieve..
И работает как надо.
Если Вы не пробовали устриц, не факт что оно не полезно, а испортить продукт дело не хитрое..
А так же есть тела, которые свято верят что Filemaker круче гор и оврагов :)
А сбер вообще на каких дос окошках работает
Ношу надо брать по себе, чтобы не падать при ходьбе..
По чесноку был переход с MS SQL 7 на 8 оракл.. фигня получилась...
Оракл, в данном случае, плохая субд? Это по Вашей логике.

Система RS-Bank, а не RS-Balance. Знаю, сам на ней работал в банке, именно на btrieve. А Сбер, как Вы, мадам, изволили выразится, по крайней мере нашего ФО, уже давно перешел с RS-Bank на ЦФТ, именно на Oracle, поскольку ЦФТ не на Oracle нет. Еще в 2004 году. А веру я менять не собираюсь, поскольку от рождения православный, им и помру. Впрочем, с женщинами спорить себе дороже.

MazoHistКогда-то я варился в этой кастрюле...
1. TCO. Сколько стоит купить ораклу на все ИФНС РФ? а настроить? а админить? и где в каком-нибудь Усть-Перепендюйске найти народ на это дело? А зарплаты у айтишников в ФНС чуть больше чем у уборщицы (не шучу). Да он свалит сразу.
2. Лоббирование M$. Сколько разговоров было про альтернативные системы? Нет. Никаких альтернатив, M$ only. Главное хранилище в те времена M$ не тянуло - поэтому там Oracle. на HPшном железе и HP-UX.

1. С тех пор многое изменилось. Теперь в налоговой, кроме зарплаты, платят еще и премию, которая бывает с зарплату размером. Судя по количеству машин на приколе у конторы, никто уходить не собирается. Сейчас увольнение из налоговой именно IT - явление редкое.
2. Речь идет о крупных нагруженных системах, а не о неких ООО, тут и MS SQL нужно настраивать и
админить, а вот это уже дело будет посложнее, чем Oracle, да и стоящей литературы поменее. К тому же налоговая давно имеет каналы связи, по которым все админится удаленно. Достаточно иметь 2-х достойных IT шников на регион.
3. МВД, ФМС, таможня, юстиция, Росреестр (права и кадастр), МЧС (!) - Oracle, и только налоговая на MS. Где тут лоббирование ?

iv_an_ruavduХороший пример неудачного выбора СУБД и неудачной реализации проекта. И неудачного выбора разработчика. Из дальнейшего описания вырисовывается некрупная "бюрократическая" системка без каких-либо нетривиальных кусков, которую можно слабать на любой "толстой" СУБД, равно как и на многих поделках попроще. 400 немудрячих пользователей и налоговая ерунда масштаба города --- при современном-то оборудовании не вопрос совершенно, были бы квалифицированные разработчики.

Налоговая системка, сама по себе вещь нетривиальная, как и наша налоговая система.

VolochkovaavduMazoHistКогда-то я варился в этой кастрюле...
1. TCO. Сколько стоит купить ораклу на все ИФНС РФ? а настроить? а админить? и где в каком-нибудь Усть-Перепендюйске найти народ на это дело? А зарплаты у айтишников в ФНС чуть больше чем у уборщицы (не шучу). Да он свалит сразу.
2. Лоббирование M$. Сколько разговоров было про альтернативные системы? Нет. Никаких альтернатив, M$ only. Главное хранилище в те времена M$ не тянуло - поэтому там Oracle. на HPшном железе и HP-UX.

1. С тех пор многое изменилось. Теперь в налоговой, кроме зарплаты, платят еще и премию, которая бывает с зарплату размером. Судя по количеству машин на приколе у конторы, никто уходить не собирается. Сейчас увольнение из налоговой именно IT - явление редкое.
2. Речь идет о крупных нагруженных системах, а не о неких ООО, тут и MS SQL нужно настраивать и
админить, а вот это уже дело будет посложнее, чем Oracle, да и стоящей литературы поменее. К тому же налоговая давно имеет каналы связи, по которым все админится удаленно. Достаточно иметь 2-х достойных IT шников на регион.
3. МВД, ФМС, таможня, юстиция, Росреестр (права и кадастр), МЧС (!) - Oracle, и только налоговая на MS. Где тут лоббирование ?

А пожары тушат так до революции.

Сложилось у плебса странное мнение, что до революции все было плохо. Отнюдь нет. Кстати, борьба с пожарами, особенно на селе, была организована не в пример лучше теперешних.
Даже при том уровне техники нынешние сгоревшие деревни вряд ли бы сгорели.