OYMДохтаРпропущено...


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

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

Это дыры , через которые с рабочих станций на сервера в AD
залазит основная масса вирусов .

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

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

Не знаю побороли эту лажу или нет, давно было,
но несколько раз приходилось сталкиваться с распуханием регулярно бекапируемого
журнала транзакций, лечилось рестартом базы вместе с подписчиками.
Сразу после рестарта, журнал шринкается на 90% за 4 клика
Подзрение падало на служебные распределенные транзакции мастер-подписчик.
Квалификации победить не хватило, да и особого желания глубоко ковыряться небыло,
избавились от системы в целом.

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

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


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

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


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

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

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

Из чистых плюсов, чесный RR и грязное чтение для всяких хаков.

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

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

OYMlondiniumпропущено...

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

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

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

приблизительно так.

Yo.!вы потеряли нить обсуждения ?



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

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

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

Сравнивать размножение блокировок и
рестарты( смещение SCN) в миксе разрывом конситентности
переклчения конекстов SQL - PL/SQL
тема без возможности
найти истину, что все таки лучше теплое или мягкое.

OYMYo.! 2OYM

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

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

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