Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6   вперед  Ctrl      все
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
OYM
Member

Откуда:
Сообщений: 236
ДохтаР
OYM
Мне кажется эти домыслы насчет нестабильности винды есть просто домыслы.
Вот, например, "сервер заразится вирусней с ПК", ну скажите на милость как туда попадет вирус? По стандартном порту SQL Server что ли?? Как ему туда добраться?


Попробуй виндосервере административно закрыть 135 138 139 443 итд порты от
других серверов и рабочих станций пользователей AD .

Максимум через час позвонит главный ИТшник в очень плохом расположении духа Картинка с другого сайта.

Это инфраструктурные порты, их не надо закрывать
1 мар 13, 16:53    [14000215]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
londinium
Member

Откуда: Киев
Сообщений: 1202
Да ладно, Бог с теми вирусами.
Мне кажется, дело в другом - процессинги и АБС часто крутят на "большом" железе (HP,IBM), куда Windows или добрался относительно недавно, или не добрался вообще. Поэтому, зачем делать процессинг на MS SQL SERVER, который просто не встанет на заботливоприпасенный p-сервер IBM
1 мар 13, 17:26    [14000372]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
OYM
ДохтаР
пропущено...


Попробуй виндосервере административно закрыть 135 138 139 443 итд порты от
других серверов и рабочих станций пользователей AD .

Максимум через час позвонит главный ИТшник в очень плохом расположении духа Картинка с другого сайта.

Это инфраструктурные порты, их не надо закрывать


Это дыры , через которые с рабочих станций на сервера в AD
залазит основная масса вирусов .
1 мар 13, 17:27    [14000375]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11463
Никто не запрещает остановить и запретить к запуску службу сервера.
Параноики могут проделать тоже самое и со службой рабочей станции.

P.S. Да, я в курсе, что администрировать систему будет "не так привычно".
1 мар 13, 19:37    [14000876]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
OYM
Member

Откуда:
Сообщений: 236
Таким образом, "малопригодность" SQL Server в этом топике сугубо описывается "небезопасностью" винды, но все же хотелось бы услышать, чего в нем не хватает для реалтаймовой работы процесс. центра (допустим "надуманные" проблемы с вирусами, перезагрузками, накатыванием обновлений и прочей нестабильности винды побороли)?
1 мар 13, 20:36    [14001043]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
OYM
Member

Откуда:
Сообщений: 236
londinium
Да ладно, Бог с теми вирусами.
Мне кажется, дело в другом - процессинги и АБС часто крутят на "большом" железе (HP,IBM), куда Windows или добрался относительно недавно, или не добрался вообще. Поэтому, зачем делать процессинг на MS SQL SERVER, который просто не встанет на заботливоприпасенный p-сервер IBM


Ну а что мешает делать это на интеловском железе?
1 мар 13, 20:37    [14001048]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
OYM
Таким образом, "малопригодность" SQL Server в этом топике сугубо описывается "небезопасностью" винды, но все же хотелось бы услышать, чего в нем не хватает для реалтаймовой работы процесс. центра (допустим "надуманные" проблемы с вирусами, перезагрузками, накатыванием обновлений и прочей нестабильности винды побороли)?


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

Не знаю побороли эту лажу или нет, давно было,
но несколько раз приходилось сталкиваться с распуханием регулярно бекапируемого
журнала транзакций, лечилось рестартом базы вместе с подписчиками.
Сразу после рестарта, журнал шринкается на 90% за 4 клика
Подзрение падало на служебные распределенные транзакции мастер-подписчик.
Квалификации победить не хватило, да и особого желания глубоко ковыряться небыло,
избавились от системы в целом.
1 мар 13, 21:22    [14001196]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Yo.!
Guest
ДохтаР
Теоретически и архитектурно у блокировчкика с версионным механизмом
больше возможносей для маневра

было бы интересно услышать чего больше, кроме того, что блокировочные транзакции получают минусы версионных в виде необходимости писанины в tempdb версий, а версионные получают минусы блокировочных в виде огромных локлистов и дедлогов ?
1 мар 13, 22:43    [14001512]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
OYM
Member

Откуда:
Сообщений: 236
Yo.!
ДохтаР
Теоретически и архитектурно у блокировчкика с версионным механизмом
больше возможносей для маневра

было бы интересно услышать чего больше, кроме того, что блокировочные транзакции получают минусы версионных в виде необходимости писанины в tempdb версий, а версионные получают минусы блокировочных в виде огромных локлистов и дедлогов ?

А Оракл хранит версии в космосе....
1 мар 13, 22:59    [14001631]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Yo.!
Guest
OYM
А Оракл хранит версии в космосе....

оракл хранит версии в UNDO, но не плодит миллиарды блокировок при чтении. а вот блокировочная транзацкия в мсскл будет и версии хранить и блокировки плодить. отсюда вопрос, где тут больше возможностей ?
1 мар 13, 23:03    [14001658]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
Yo.!
ДохтаР
Теоретически и архитектурно у блокировчкика с версионным механизмом
больше возможносей для маневра

было бы интересно услышать чего больше,


Не претендуя на истину в первой инстанции попробую.

Yo.!
кроме того, что блокировочные транзакции получают минусы версионных в виде необходимости писанины в tempdb версий,


ТемпДБ не логируется, а УНДО логируется, ниже журнальный трансфер.

Yo.!
а версионные получают минусы блокировочных в виде огромных локлистов и дедлогов ?


Не более и неменее чем select for update.
Если достаточно глубоко смотреть то оракл возвращает
первый фетч только после полного прохода по курсору и установки блокировок ,
по другому никак.
MSSQL в зависимости от TIL,
досконально я механизма не знаю, возможно гуру раскажут детальнее.

Из чистых плюсов, чесный RR и грязное чтение для всяких хаков.
1 мар 13, 23:16    [14001715]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
OYM
Member

Откуда:
Сообщений: 236
Yo.!
OYM
А Оракл хранит версии в космосе....

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


автор
SNAPSHOT
Указывает на то, что данные, считанные любой инструкцией транзакции, будут согласованы на уровне транзакции с версией данных, существовавших в ее начале.Транзакция распознает только те изменения, которые были зафиксированы до ее начала.Инструкции, выполняемые текущей транзакцией, не видят изменений данных, произведенных другими транзакциями после запуска текущей транзакции.Таким образом достигается эффект получения инструкциями в транзакции моментального снимка зафиксированных данных на момент запуска транзакции.
Транзакции моментальных снимков не требуют блокировки при считывании данных, за исключением случаев восстановления базы данных.Считывание данных транзакциями моментальных снимков не блокирует запись данных другими транзакциями.Транзакции, осуществляющие запись данных, не блокируют считывание данных транзакциями моментальных снимков.
1 мар 13, 23:26    [14001747]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
londinium
Member

Откуда: Киев
Сообщений: 1202
автор
Ну а что мешает делать это на интеловском железе?

Не знаю. Подозреваю, что когда строят большой процессинг, то предпочитают купить "большой шкаф" от IBM
1 мар 13, 23:45    [14001851]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
OYM
Member

Откуда:
Сообщений: 236
londinium
автор
Ну а что мешает делать это на интеловском железе?

Не знаю. Подозреваю, что когда строят большой процессинг, то предпочитают купить "большой шкаф" от IBM

Как-то Сбербанк России, имея большой шкаф и Оракл на нем встал колом....
1 мар 13, 23:55    [14001903]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
londinium
автор
Ну а что мешает делать это на интеловском железе?

Не знаю. Подозреваю, что когда строят большой процессинг, то предпочитают купить "большой шкаф" от IBM


Обычно процессинг растет, и когда вырастает до состояния когда
его рентабельнее держать в шкафу в одном флаконе на 100+ ядрах,
приходит осознание того что правильную платформу лучше брать сразу.
1 мар 13, 23:55    [14001904]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
OYM
londinium
пропущено...

Не знаю. Подозреваю, что когда строят большой процессинг, то предпочитают купить "большой шкаф" от IBM

Как-то Сбербанк России, имея большой шкаф и Оракл на нем встал колом....


Там не оракл стал колом, а SAN том отсох ( hdisk170),
и веритас и сторадж начали наперегонки оптимизировать друг дружку.
Обычный бардак в большой канторе.
Ни Оракл ни IBM ни HP повесивщий свою лейбу на хитаческий сторадж ,
там не причем.

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

приблизительно так.
2 мар 13, 00:08    [14001979]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Yo.!
Guest
ДохтаР
ТемпДБ не логируется, а УНДО логируется, ниже журнальный трансфер.

если ниже, почему оракл c UNDO так уверенно уделывает мсскл даже без версионности в тестах tpc-c ?

ДохтаР
Не более и неменее чем select for update.

на блокировочных TIL на порядки больше.

2OYM

вы потеряли нить обсуждения ? единственно что имеет блокировочник с включенным версионным механизмом это блокировочные TIL. вот они, блокировочные TIL и будут и писать версии в темпдб и плодить блокировки.
2 мар 13, 00:13    [14001995]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
OYM
Member

Откуда:
Сообщений: 236
Yo.!
2OYM

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


А зачем нужны блокировки, читай себе версии из темпдб, что блокировать то?
2 мар 13, 00:21    [14002032]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Yo.!
Guest
OYM
А зачем нужны блокировки, читай себе версии из темпдб, что блокировать то?

не зачем. о том и речь, что блокировочная часть нахрен не нужна.
2 мар 13, 00:31    [14002077]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
Yo.!
вы потеряли нить обсуждения ?



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

Я Сиквел сервер три года как в глаза не видел,
и альтернатив ораклу в сабже не вижу.

Yo.!
единственно что имеет блокировочник с включенным версионным механизмом это блокировочные TIL. вот они, блокировочные TIL и будут и писать версии в темпдб и плодить блокировки.


Сравнивать размножение блокировок и
рестарты( смещение SCN) в миксе разрывом конситентности
переклчения конекстов SQL - PL/SQL
тема без возможности
найти истину, что все таки лучше теплое или мягкое.
2 мар 13, 00:33    [14002090]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
londinium
Member

Откуда: Киев
Сообщений: 1202
автор
Как-то Сбербанк России, имея большой шкаф и Оракл на нем встал колом

Было, спорить бесполезно. Но полагаю, что обычная интел-инфраструктура умерла бы еще раньше
2 мар 13, 00:34    [14002091]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
OYM
Member

Откуда:
Сообщений: 236
Yo.!
OYM
А зачем нужны блокировки, читай себе версии из темпдб, что блокировать то?

не зачем. о том и речь, что блокировочная часть нахрен не нужна.

Я совсем не гуру MS, но действительно зачем накладывать блокировки и на какие ресурсы? Хотелось бы услышать мнение таких гуру как pkarklin
2 мар 13, 00:38    [14002107]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
OYM
Member

Откуда:
Сообщений: 236
londinium
автор
Как-то Сбербанк России, имея большой шкаф и Оракл на нем встал колом

Было, спорить бесполезно. Но полагаю, что обычная интел-инфраструктура умерла бы еще раньше

А всякие RAC и Mirroring на что?
Используя это можно и на интеловском железе жить.
2 мар 13, 00:51    [14002145]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
OYM
Yo.!
2OYM

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


А зачем нужны блокировки, читай себе версии из темпдб, что блокировать то?


пока вы не соберете на одном счете возмещения мерчанта все терминалы
какого нибудь ашана , в принципе не нужны.
Но если соберете, получете перманетноно воспаленный
геморой с разывом баланса.
2 мар 13, 02:35    [14002392]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
OYM
Member

Откуда:
Сообщений: 236
ДохтаР,
Можете пояснить отчего будет разрыв баланса в SQL Server и не будет разрыва баланса в Оракле?
2 мар 13, 10:34    [14002594]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить