pkarklinbeginner_dbaOracle намного проще в плане администрирования чем тот же MS SQL. С выходом 11 версии еще все больше упростилось.

Аргументы - в студию!
Ок давайте, разберемся, что вкладывать в понятие администрирование.
Предлагаю рассмотреть 6 основных направлений работы АБД

1. Резервное копирование и восстановление.
2. Создание объектов БД.
3. Создание аккаунтов и раздача/отбор привилегий.
4. Уменьшение времени отработки запросов и инструкций DML.
5. Установка северного ПО, клиентского ПО, настройка сетевого доступа
6. Контроль дискового пространства и выделение места для структур хранения.

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


Аргументы - в студию!
Ок давайте, разберемся, что вкладывать в понятие администрирование.
Предлагаю рассмотреть 6 основных направлений работы АБД

1. Резервное копирование и восстановление.
2. Создание объектов БД.
3. Создание аккаунтов и раздача/отбор привилегий.
4. Уменьшение времени отработки запросов и инструкций DML.
5. Установка северного ПО, клиентского ПО, настройка сетевого доступа
6. Контроль дискового пространства и выделение места для структур хранения.


Существенное преимущество Оракла -это разделение журнала оперативных журналов повтора и сегмента отката.
В МС все свалено в кучу. Например Вам нужно перестроить все индексы всей БД. В МС у вас журнал вырастет до огромных размеров, при чем есть риск того, что ему просто не хватит места на диске для роста. Резервное копирование журнала (сиречь "опустошение" места для записи новых транзакций) будет невозможно из-за того, что журнал содержит активную незакомиченную часть). В Оракле же у Вас такой проблемы не будет.

pkarklinbeginner_dbaОк давайте, разберемся, что вкладывать в понятие администрирование.
Предлагаю рассмотреть 6 основных направлений работы АБД

1. Резервное копирование и восстановление.
2. Создание объектов БД.
3. Создание аккаунтов и раздача/отбор привилегий.
4. Уменьшение времени отработки запросов и инструкций DML.
5. Установка северного ПО, клиентского ПО, настройка сетевого доступа
6. Контроль дискового пространства и выделение места для структур хранения.

Прекрасно! Полагаю, Вы теперь по каждому из этих 6ти пунктов расскажите, чем администрирование Oracle проще, чем MS SQL.

По пункту 1
Мультиплексирование оперативных журналов в Оракле, в случае использования Unix подобных систем, вы например можете положить членов группы журналов на разные серверы, связанных FC. В случае МС при потере журнала транзакций, вы теряете "хвостовые транзакции" (разность по времени между последней транзакцией и последней копией журнала).
Оракл восстанавливает рухнувшие транзакции в фоне при старте, при чем база доступна при этом, МС же не открывает базу до тех пока не будут восстановлены все транзакции.
Раздельная жизнь журнала повторов и структур отката. Дает преимущество в разноске на разные диски

авторpkarklinавторМультиплексирование оперативных журналов в Оракле, в случае использования Unix подобных систем, вы например можете положить членов группы журналов на разные серверы, связанных FC. В случае МС при потере журнала транзакций, вы теряете "хвостовые транзакции" (разность по времени между последней транзакцией и последней копией журнала).

А Вас умоляю... Для обеспечения HADR есть более простые и дешевые решения, зеркалирование , например. А уж "потерять журнал" на EVA 8100 - это надо еще суметь.
зеркалирование (или доставка журналов) - это дополнительные лицензии SQL Server (или я не прав?), дополнительная серверная ОС и самое главное дополнительный физический сервер. Усложняется работа АБД, нужно теперь 2 сервера обновлять сервис- паки, баг-фиксы, кумулятивные пакаджи. В Оракле -это может обычный NAS без самого Оракла и с бесплатной ОС.
Давайте приземлимся с небес, сколько предприятий могут себе позволить EVA8100. Подавляющее большинство сидит на пролиантах, да пауэрэджах.

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

Да что Вы говорите?! Начиная с 2005 версии есть fast recovery: During a crash recovery or a database mirroring failover, SQL Server 2005 Enterprise Edition and later versions let users access the database during the undo phase. This is known as fast recovery.

В Оракле это доступно в самой младшей версии за 5400 долл. за сокет.

pkarklin,
По пункту 1.
Для удобства и простоты резервирования и восстановления есть язык RMAN (очень гибкий инструмент) в противовес цепочке BACKUP или RESTORE.
Модель существования нескольких циклических групп, позволяет Вам забыть о проблеме роста лога транзакций. Когда журнал будет заполнен он заботливо будет заархивирован, сохранен и транзакции пойдут в другую зеркальную группу оперативных журналов. Например на другом диске. То есть у АДБ не болит голова с полным логом. Этой проблемы просто нет. На ваш резонный вопрос, о том, что делать с архивлогами, которых много. Вам ответ- Вам в помощь гибкий и простой инструмент RMAN, который Вам будет вычищать устаревшие архивлоги.
Архивлоги Вам позволяют строить ретроспективные запросы просто указав временную метку. И Вы имеет какие были данные час назад. В МС же Вам нужно развернуть БД из полной копии, затем же накатить цепочку trn файлов. Например прибегает к Вам пользователь и кричит вот данные были такие, а стали такие-то. Вы тут же и проверили. Плюс можно включить аудит.

pkarklinbeginner_dba,

А зеркалирование Вы зачем отболдили?

Давайте определимся с понятиями.
Зеркалирование на уровне ОС ?
или зеркалирование как фича SQL Server (Mirroring). Я имел ввиду второе понятие

pkarklinbeginner_dba,

Если мы хотим сравнивать "простоту администрирования", то давайте не будем про "младшие редакции" (которые, порой, вообще без администрирования работают) и цены на редакции. Берем все по максимуму.

Ок тогда восстановление в фоне выбрасываем как преимущество.

lockybeginner_dbaВ Оракле это доступно в самой младшей версии за 5400 долл. за сокет.
"... и существует еще с 1997 года" (С)

Это наверное из творчества Yo!!

pkarklinbeginner_dbaНапример Вам нужно перестроить все индексы всей БД. В МС у вас журнал вырастет до огромных размеров, при чем есть риск того, что ему просто не хватит места на диске для роста. Резервное копирование журнала (сиречь "опустошение" места для записи новых транзакций) будет невозможно из-за того, что журнал содержит активную незакомиченную часть).

Эээ... Такое может произойти только у DBA, уровень которого ниже плинтуса, и он запихал все ALTER INDEX ... REBUILD в одну транзакцию, вместо того, чтобы после обработки каждого индекса (одна транзакция) дергать джоб по бэкапу лога, освобождая место от неактивной части лога.

Это говорит о том, что для работы с SQL Server нужно иметь высокую квалификацию. К сожалению у нас люди часто пишут в резюме знание SQL Server. А на поверку оказывается что человек может написать запрос select * from table и в СУБД MySQL. При чем человек неподдельно удивляется, что это два разных продукта.