Понимаю, что тема довольно изъезжена. Но всё-таки вот по моему мнению некоторые важные аспекты с точки зрения DBA. Хотелось бы послушать замечания и дополнения.

Oracle 11G MsSQLОперационная система *nix (возможность гибкой настройки ядра; hugepage); Windows WindowsВозможность в хранилище уйти от файловой системы на "сырые" устройства или ASM; что влечёт увеличение производительности есть нетT-SQL уступает PL/SQL по возможностям PL/SQL (отслеживание зависимостей [Valid-Invalid]; пакеты; встроенные пакеты [DBMS_*; UTL_*]) T-SQLАвтономные транзакции есть нетРазмер блока данных 4;8;16;32K 8KВозможность восстанавливать удалённые таблицы (FlashBack) есть нетВозможность просматривать версии данных в пределах времени удержания (Undo Retention). Возможность отмены ошибочной транзакции в прошлом. есть нетВозможность восстанавления сбойных блоков; файлов данных; пространств в работающей базе. есть Надо восстанавливать всю базу в "рядом" на нужный момент времени и оттуда уже извлекать данные в действующую. Если размер базы сотни гектар то это будет весьма непросто.Упреждающий сбор статистик AutomaticWorkload Repository (AWR) которая упреждающе производит сбор статистики производительности и загруженности SQL Такая функция устраняет необходимость выполнения ручной настройки конфигурации что требуется для диагностирования производительности Визуальный анализ файлов трассировки с помощью своего инструмента SQL Profiler. Громоздко и неудобно. Самодиагностика проблем производительности Механизм самодиагностики Automatic Database Diagnostic Monitor (ADDM упреждающе анализирует собранную AWR информацию с целью выявления проблем производительности и дает рекомендации по их устранению. ADDM является общим решением позволяющим выявить все типы проблем с производительностью Только проблемы SQL-операторов Большое количество "советчиков" администратору ADDM (громадный перечень советов от модернизации железа до SQL-операторов); по настройке пространства отмены; по настройке памяти; по настройке времени аварийного восстановления; по настройке индексов; по оптимизации свободного места и дефрагментации...и много-много чего ещё Только по оптимизации SQLWEB-интерфейс управления сервером OEM Grid Control. Поднят на независимой машине и позволяет управлять даже выключенной базой. Управляет хостом; апдейтами и т.п. Сводит много оракловых машин в одну систему управления. Общие джобы. Включает не только БД но и другие оракловые сервисы (например Web Application; WEB Logic; BI Enterprise Edition…) нетКластер RAC. Все ноды работают на одно хранилище. Потеря ноды не влечёт потерю данных. В 11G с помощью RAC можно распределять нагрузку что делает базу неограниченно масштабируемой. Mirosoft для распределения нагрузки кластера может предложить лишь "размазать" таблицы по нескольким нодам кластера. Т.е. потеря ноды влечёт потерю части данныхStandby В 11G cтэндбай можно не только использовать в режиме чтения но и накатывать на него изменения для тестирования приложений (с последующей отменой) "Зеркало" нельзя использовать т.к. оно постоянно в режиме восстановления.Тесты на производительность SAP-SD При идентичном железе выигрыш в производительности по всем параметрам.

lockyДядя Жора,

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

Хотелось бы более предметные опровержения, а не просто "этого не может быть, потому что этого не может быть никогда." Для того я тут и вывесил эту таблицу. И не только мне это будет интересно, а ещё многим "глубоко не ознакомленным".

lockyНапример, про Raw device. Или про DMV.
Незнание этих вещей ставит под сомнение Ваше знание скуля.
А вывешивание сравнения двух систем, одну из которых Вы не знаете, ставит под сомнение и Ваше знание Оракла.
Я, например, Оракл знаю так себе, и не могу сказать, где вы правы или не правы в оракловой части. Но то, что я не буду учитывать Вашу таблицу - уже однозначно, т.к. доверия к Вашим знаниям пока нет.

Уважаемый. Ваша агрессия меня только забавляет. Я конечно польщён столь бурным проявлением эмоций к моей персоне, однако Вы бы лучше переключились на предмет обсуждения, а не на меня лично. А то слов много и всё не по делу. Опровергните если можете. Будем рады послушать. А оценку моих деловых качеств отавьте мои работодателям.

lockyА фигли, пардон, опровергать, да и что, собственно?
Утверждение "Возможность в хранилище уйти от файловой системы на "сырые" устройства"? брать бол еще для 2000 скуля и тыкать туда носом?
Брать "Упреждающий сбор статистик" и тыкать носом в DMV? Собственно, даже с "визуальный" - вы не то что дали маху, а нечто большее.
Брать "Возможность восстанавления сбойных блоков; файлов данных; пространств в работающей базе." и тыкать опять таки в БОЛ?

Вы что, будете оный БОЛ читать? Сомневаюсь. Если бы хотели - прочитали бы до того, как публиковать таблицу.

А Вы не сомневайтесь. Тыкните, а мы почитаем, конструктивно обсудим упреждающий сбор статистик mssql и oracle. Да и про сырые устройства сиквела уж тоже очень хочется поглумиться. Пока, к сожалению, опять-таки одни только эмоции. Сдаётся нам, мил человек, что своей неадекватной реакцией Вы прячете свои сомнения. И кстати, не забудьте "тыкнуть" ещё по остальным 11 пунктам.

lockyДруг мой. насколько я помню - именно Вы опубликовали таблицу.
Следовательно, на вас лежит бремя доказательства её истинности.
Вам уже указали на 3 пункта, которые являются даже не спорными, а (я не побоюсь этого слова) - ложными.


К сожалению, товарищ, Вы заблуждаетесь. Посмелюсь Вам возразить, что те "3 пункта", что Вы своим царственным жестом нам указали, Вы забыли подкрепить доказательствами. А доказывать должен тот кто опровергает (обвиняет), а не опровергаемый (обвиняемый). Таковы правила "презумпции невиновности". Вы опять всё спутали.


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

Да я и не просил Вас обсуждать со мной технические детали. Судя по Вашим аргументам Вы просто некомпетентны в этом вопросе. Вы перепутали эху. Возвращайтесь на свой любимый "трёп" и там блещите своими "глубокими познаниями" в пустой болтологии

lockyИдите, копайте.
Раскопаете - побеседуем.

даже по 4-м пунктам. Если так подумать.

No comment

pkarklin,

Вот это конструктивный ответ, а не просто трёп ни о чём.
Насчёт Standby, то хочется заметить, что в данном случае я как раз ничего не спутал. В Oracle тоже есть и физический стэндбай и логический. И до версии 11G так оно и было как Вы описал и как сейчас в сиквеле. Однако

авторв Oracle 11g реализовано 2 новых типа standby базы: Phisical Standby with Real-Time Query и Snapshot Standby. Phisical Standby with Real-Time Query похож на старый Физический standby, однако в то время, когда standby база открыта на чтение, она продолжает догонять основную БД (восстанавливается на физическом уровне). Т е одна и та же база может использоваться как для защиты от катастрофических сбоев, так и для разгрузки основной базы и для тестирования read only приложений. Так на ней можно печатать отчеты, выполнять бэкапы, заниматься аналитикой и Data Mining.

Snapshot Standby позволяет использовать резервную базу для тестирования новых приложений и настройки старых приложений. В то время, как snapshot standby база догоняет основную базу, на ней можно тестировать приложения, которые читают и меняют данные в БД. После возврата из режима Snapshot Standby в режим Phisical Standby, все изменения, сделанные тестируемым приложением, будут аннулированы.

alexeyvg4. непонятен смысл сравнения по фичам.


Сравнение по фичам идёт потому, что принципиального различия в этих СУБД нету. Если бы речь шла о сравнении к примеру Oracle и FireBird, то тут углубляться в фичи не надо - столь радикально различие. Это как сравнивать БМВ и Жигули. Но в данном случае идёт сравнение БМВ и Мерседеса (если такое сравнение приемлемо) и выехать можно только на фичах. Или нет? К сожалению в критике очень мало конструктива. Хотелось бы услышать более обоснованные высказывания как например у pkarklin-а. Судя по всему, здесь в основном защитники MsSQL крутятся. То, что эту эху не посещают ораклисты наводит на размышления, что они альтернатив не ищут :)