Продолжается подписка на наши издания! Вы не забыли подписаться?

Возможности, достоинства и слабости СУБД MS SQL Server 2005 (Yukon) и Oracle 10g

Авторы: Давид Горнштейн
WisdomForce Technologies, Inc.,
Борис Тамаркин
WisdomForce Technologies, Inc.,
Опубликовано: 17.04.2007

Введение

Цель данного материала – предоставить сравнение возможностей MSSQL 2005 and Oracle 10g. Мы сравним возможности, связанные с VLDB/OLTP и обсудим вопросы производительности, утилиты и репликацию данных. Будут также рассмотрены несколько новых возможностей, введенных Microsoft для того, чтобы обеспечить функциональность, конкурирующую с соперничающей СУБД Oracle. Кроме того, мы рассмотрим с точки зрения администратора БД (АБД) изменения, появившиеся в MSSQL 2005, в сравнении с предыдущими версиями Microsoft SQL Server. Поскольку эта тема в основном затрагивает АБД, сведения о минимальных требованиях, поддерживаемых платформах и максимальном числе колонок здесь опущены как избыточные. Нам никогда не встречались люди, при выборе СУБД руководствующиеся тем, что одна СУБД поддерживает до 32К колонок в таблице, а другая – только 1024.

Microsoft опубликовала "Top 10 Features for Database Administration" (на самом деле, все они весьма хороши). Практически все эти возможности имеются в Oracle с версии 8i или ранее. "Snapshot Isolation" – это всего лишь расширение, обеспечивающее половину функциональности версионности строк Oracle, но с большими накладными расходами. Однако MS SQL Server был и остается на несколько шагов впереди Oracle в простоте установки, конфигурирования, выполнения базовой настройки и использования средств разработки.

При сравнении Oracle 8i/9i с MSSQL 2000 в областях VLDB/OLTP и корпоративных приложений на высокопроизводительных машинах существенным ограничением Oracle всегда была необходимость в высококвалифицированном АБД, тогда как роль администратора MSSQL может выполнять практически любой опытный разработчик.

Ранние выводы: новая версия MS SQL Server демонстрирует существенный прогресс. Однако если вы используете сложное приложение или систему, работающую на высокопроизводительных машинах, вы, возможно, сохраните верность Oracle. А для серверов уровня подразделения, или для мелких и средних приложений лучше выбрать MS SQL Server.

Возможности MSSQL 2005 описываются по версии beta 2.

Основные ограничения MSSQL до Yukon (например, MSSQL 2000)

Стратегия блокировок

Основной проблемой MSSQL 2000 в сравнении с Oracle 8i/9i в области VLDB/OLTP и корпоративных приложений на high-end оборудовании была хорошо известная стратегия блокировок. Она могла вызывать конфликты блокировок с очень высокой вероятностью взаимоблокировки в корректных потоках транзакций, прекрасно работающих на любых СУБД, предоставляющих версионность строк. Вдобавок механизм эскалации блокировок в MSSQL 2000 вызывал эскалацию блокировок до уровня блоков или даже таблиц в случаях высокого параллелизма, характерного для SMP-машин.

Вот какое воздействие оказывает эта стратегия блокировок с точки зрения автора как АБД.

В конце 2001 года у одного из наших клиентов был установлен MSSQL 2000 EE на двухпроцессорном сервере IBM. Самой большой таблицей в системе (большой сервер ISP с широким применением аутентификации и авторизации) была таблица истории учета. Эта таблица содержала информацию о подключениях/отключениях клиентов ISP. Таблица постепенно росла, и достигла среднего размера (с точки зрения Oracle), примерно 100 GB. Однако система использовала не Oracle, а MSSQL 2000. Как вы, возможно, знаете, таблица в 100 GB с параллельной вставкой довольно велика для MSSQL. Клиент решил нарастить свой главный сервер до 4 процессоров. Они переключились на резервный сервер с пустой таблицей учета и проработали в этой конфигурации дня два. За это время в таблице накопилось около 750К строк. Клиент попытался скопировать эти 750К строк в основную таблицу, содержавшую около 60x10^6 строк (100GB), используя DTS. Мы выполнили тестовое копирование 750K строк через DTS в пустую таблицу, что заняло около 12 минут, и затем скопировали данные в реальную, большую таблицу. Сам процесс занял те же 12 минут, но сразу после этого MSSQL начал перебалансировку 20-гигабайтного индекса этой таблицы, что остановило усовершенствованный сервер с 4 процессорами XEON на 5 часов.

ПРИМЕЧАНИЕ

Даже в MSSQL Server 7 и/или 2000 можно отключить эскалацию блокировок, используя недокументированные (в этих версиях) флаги трассировки 1211 или 1224, где 1211 полностью отключает эскалацию блокировок, а 1224 отключает эскалацию блокировок до момента, когда структуры блокировки займут более 40% памяти, используемой MSSQL в нижних 2 GB (т.е. исключая AWE-память в случае Windows 2000 advanced). Чтобы задействовать один из этих флагов (например, 1211) в конкретной сессии, выполните DBCC TRACEON (1211, -1). Чтобы постоянно использовать его, откройте сервис MSSQL в менеджере сервисов Windows и добавьте -t1211.

Например, определение сервиса может выглядеть так:

%SQL_SERVER_HOME%\mssql\binn\sqlservr.exe -t1211

Если включены оба флага, преимущество имеет 1224.

Подробнее см. http://support.microsoft.com/default.aspx? scid=kb;en-us;323630&sd=tech

У таблицы не было кластерных индексов, то есть, она была организована как куча, а не как B-Tree.

Можно предположить, что из-за большого объема вставки SQL Server расширил блокировку до уровня эксклюзивной блокировки таблицы.

Онлайн-реорганизация и разбиение таблиц/индексов

Начиная с версии 8.1.x и до текущей 10g в Oracle постоянно повышается число DDL-операций, выполняемых онлайн. В Oracle 10g можно перестроить и переместить индекс или даже таблицу без эксклюзивной блокировки на время перестройки. Однако для завершения операции требуется кратковременная блокировка. В процессе перестройки таблица сохраняет работоспособность, может обновляться, можно создавать новые индексы и т.д. Oracle 9.2 до набора патчей 9.2.0.5 содержал ряд ошибок, связанных с онлайн-реорганизацией таблиц и индексов, особенно в RAC-средах, но, вроде бы, в 9.2.0.5 и 10.1.0.3 большинство проблем удалось решить.

В MSSQL 2000 была доступна только частичная онлайн-реорганизация/сжатие индексов через DBCC INDEXDEFRAG, но эта операция пропускала блоки, которые не могла эксклюзивно блокировать. В MSSQL 2005 появилось несколько дополнительных опций онлайн-реорганизации, которые будут подробнее разобраны ниже.

Попробую объяснить.

  1. Select из таблицы без кластерного индекса не возвращает строки в том порядке, в котором они были вставлены. Порядок вставки оказывает следующее влияние на не параллельную выборку:
ПРИМЕЧАНИЕ

Примечание: Такое поведение не документировано, но наши тесты показали, что MSSQL 2000 работает именно так.

  1. Рассмотрим 2 широких таблицы, по 30 колонок в каждой. Обе таблицы содержат по несколько колонок переменной длины, так что длина строки превышает 1000 байт. У первой таблицы есть кластерный индекс. У второй – нет, но вместо этого она содержит трехколоночный обычный, уникальный индекс. Заполнение первой таблицы с кластерным индексом 10 миллионами строк займет существенно больше времени, чем заполнение второй.

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

Статистика

В MSSQL 2000 было куда меньше временной числовой статистики, чем в сравнимых v$-представлениях Oracle.

В MSSQL 2000 (как и в 2005) очень мало связанной с настройкой повременной статистики. Однако MSSQL выдает богатый набор онлайн-статистики через очень привлекательный визуально Windows Performance monitor. Единственная проблема в том, что постоянно накапливаемая статистика занимает очень много места на диске. Эта статистика очень полезна и практически эквивалентна статистике, предоставляемой Oracle 10g.

С момента «запуска экземпляра» или другой «точки отсчета» для БД MSSQL доступно очень немного кумулятивной статистики через DBCC PSS, DBCC PROCCACHE, DBCC OPENTRAN, и немного повременной статистики через системные хранимые процедуры sp_whp, sp_lock и т.д.

Кроме этого, начиная с MSSQL 7, Microsoft поставляет MSSQL Profiler и Server-Side Trace, предоставляющие функциональность, сходную с Oracle event 10046 или sql_trace. В MSSQL 2005 эти возможности расширены динамическими представлениями в стиле Oracle. Пользователь по умолчанию “dbo” теперь владеет всеми таблицами БД master, которые раньше начинались с “sys”. В MSSQL 2005 master.dbo.sysdatabases стало динамическим представлением, принадлежащим пользователю “sys”: master.sys.sysdatabases (ничего не напоминает?). Детальное сравнение будет приведено ниже.

Кластеризация и высокая доступность

Начиная с версий MSSQL 6.5 и 7, Microsoft предоставляет кластерную конфигурацию с быстрым восстановлением после сбоев. Это эквивалентно DataGuard в Oracle. Но восстановление после сбоев в MSSQL работает очень быстро даже по сравнению с Oracle 9i RAC Transparent Application Failover, который рекламируется как превосходное высокодоступное решение по сравнению с DataGuard. Это возможно благодаря тому факту, что все узлы RAC проходят «реконфигурацию» при отказе узла, например, Sun Cluster 3.1 останавливается на 10-30 секунд. Точное время «реконфигурации» зависит от количества блокировок, существовавших на отказавшем узле, и общего числа транзакций. В то же время хорошо сконфигурированный MSSQL 2000, работающий на Microsoft Cluster, передаст управление другому серверу примерно за 15 секунд.

Однако ни MSSQL 2000, ни MSSQL 2005 не позволяют создать основанное на кластерах масштабируемое решение с совместным использованием дисков, аналогичное концепции Data Grid в Oracle 10g.

В действительности “data grid” Oracle 10g – это ни что большее, чем очередная шумиха, поскольку на большинстве платформ Oracle 10g поддерживает сети в 4-8 узлов. Кроме того, большинство производителей устройств хранения данных не вполне понимают, что означает термин «сети хранения». Однако сама идея выглядит многообещающе. Нужно также помнить, что до стабильной версии MSSQL 2005 еще далеко. Возможно, к тому времени Oracle покажет работающие сети.

MSSQL использует «кластер без совместного использования» (shared nothing cluster). Идея в том, чтобы иметь несколько серверов и разделять данные между ними ВРУЧНУЮ. Другими словами, выполнять РУЧНОЕ горизонтальное разбиение всех таблиц. Одновременно приходится создавать специальный тип разделенных представлений (partitioned views), где каждое представление – это объединение таблиц, идентифицируемых связанными серверными определениями в стиле name.database_name.owner_name.table_name. Например, это может быть history_server_1999.sells.dbo.order_lines, где таблица order_lines, которая находится на сервере "history_server_1999", имеет ограничение по колонке разбиения. Диапазоны ограничений во всех таблицах, участвующих в объединении, не должны перекрываться.

Это неплохо звучит, но это не так хорошо, как кластерные конфигурации с разделяемыми дисками у Oracle. Для масштабирования Oracle RAC нужно просто установить ПО Oracle еще на одну машину, создать несколько конфигурационных файлов и добавить логи отката. После этого можно запустить дополнительные экземпляры без единого изменения в схеме базы данных приложения. Нужно произвести только несколько изменений на уровне экземпляра, таких, как добавление табличного пространства отката и групп redo-логов к каждому новому экземпляру. Однако эти изменения не требуют остановки работающей БД. Теперь рассмотрим случай масштабирования системы под MSSQL. MSSQL с его архитектурой без совместного использования после добавления нового сервера требует создать дополнительные таблицы для каждого кластерного разделяемого представления, переместить часть данных, перестроить все существующие таблицы и представления. Такая операция требует существенных усилий, и ее никак нельзя назвать “легким добавлением узла по требованию", а вот в Oracle 10g RAC это занимает минуты. Кроме того, Oracle RAC в версиях до 10g (7/8/8i OPS и 9i RAC) работал поверх таких специализированных кластерных ОС, как Veritas cluster, HP MC Service Guard, Sun Cluster и т. д. (хотя начиная с OPS 8i в Oracle имеются собственные службы кластеризации для Windows, т.е. OSD, а начиная с RAC 9i – также и для Linux), что требовало дополнительных инсталляций, лицензий и расходов. Oracle 10g поставляется со встроенным кластерным решением “Cluster Ready Services (CRS)”.

Кроме собственного бесплатного ПО для организации кластеров, Oracle 10g предоставляет автоматизированное решение для управления хранением данных, “Automatic Storage Management (ASM)”. ASM должно упростить управление хранением в 10g RAC по сравнению с «сырыми» устройствами. Нужно помнить, что все эти возможности пока что нестабильны. Даже текущая версия называется «релиз-версией с несколькими наборами исправлений». Такова жизнь.

Несколько АБД Oracle одного большого поставщика биллинговых решений пытались установить 10g Cluster Ready Services на HPUX 11i. Документации по этому вопросу нет. Даже техподдержка Oracle не смогла найти инженера или BDE (инженера поддержки Oracle, имеющего прямую связь с командой разработчиков), хорошо разбирающегося в кластерном ПО Oracle, поскольку этот вопрос ближе к системному администрированию, чем к базам данных. Даже команда Oracle RAC PAC, всегда служившая лучшим источником решений проблем, связанных с RAC, в основном специализируется на Linux CRS.

Эти АБД поняли, что для установки 10g RAC на HPUX им потребуется MC Service Guard с HP Serviceguard Extension для RAC, так же, как это было при установке Oracle 9i RAC. И это вопреки маркетинговой информации Oracle о собственном кластерном ПО Oracle для 10g RAC.

Тогда мужики установили MC Service Guard, HP Serviceguard Extension, Oracle 10g CRS для HPUX, установили Oracle, прогнали несколько тестов, и все было прекрасно. После завершения тестов они захотели удалить CRS с HPUX-серверов. Тут-то и начались проблемы. Есть руководство по установке CRS (которая производится под учетной записью root), но нет ни единого документа по удалению CRS, а это несколько процессов, работающие от root-а. Системные администраторы решили "kill -9" все эти процессы, удалить CRS из всех скриптов и покончить с этим. Однако после "kill -9" оба сервера перезапустились, потом еще раз перезапустились... и так до переустановки ОС HPUX...

Так что, несмотря на то, что идея сети в 10g куда лучше, чем реализация не разделяющего ресурсов кластера от Microsoft, она все еще далека от простоты в установке и эксплуатации.

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

Кстати, кластер без разделения ресурсов можно реализовать гораздо эффективнее, чем это сделано в SQL Server. Вот, например, кластер без разделения дисков IBM EEE DBi2 v8. IBM позволяет легко создавать экземпляр DB2 на новом компьютере, создав раздел и определив его конфигурацию, с помощью одной команды "redistribute nodegroup GLOBAL uniform" можно перераспределить все таблицы. Нужно только удостовериться, что ключ разбиения (уникальный или нет) определен для всех таблиц в этой группе узлов.

Администрирование

Администрирование MSSQL 2005 так же просто, как и администрирование любого продукта Microsoft с хорошим GUI и всего несколькими параметрами, требующими ручной настройки.

Кроме того, на случай не такого уж редкого зависания SQL Server-а (который чаще всего виснет вместе с Windows) имеется специальный Dedicated Administrator Connection.

Блокировки

Возможно, наиболее заметная новинка MSSQL 2005 – новый уровень изоляции транзакций Snapshot Isolation (SI). Идея состояла во введении в SQL Server версионности строк, чтобы:

Единственная причина использовать режим SI, возможно, состоит в возможности создания отчета, представляющего непротиворечивый снимок целой системы на некоторый момент времени. Прямого эквивалента режиму SI в Oracle нет. Но его можно симулировать, например, с помощью режима Oracle Flashback Query, в определенный момент времени переключающегося в режим «стоп-кадра» и создающего отчет, используя снимок системы.

Между реализациями версионности строк в Oracle и MSSQL есть три главных различия:

Таблица 1.

MSSQL Oracle
Dedicated Administrator Connection производится только из командной строки утилиты SQLCMD для тех АБД MS SQL Server, кто никогда не использовал командную строку. Ожидаемый синтаксис: SQLCMD -S davidg01\COMP01 -U system -P manager –A, где system – любой пользователь, имеющий фиксированную серверную роль sysadmin, а manager – пароль экземпляра сервера davidg01\COMP01. -А означает, что это Dedicated Administrator Connection. К сожалению, в MSSQL 2005 beta 2 эта опция не работала. sqlplus "/ as sysdba"
Подключившийся пользователь ОС станет членом группы dba.
Еще одна связанная с администрированием возможность – разрешение принудительной политики в отношении паролей SQL Server и разрешение разделения пользователей и схем. К сожалению, в MSSQL 2005 beta 2 эта опция не реализована. Oracle предоставляет правило обеспечения сложности пароля начиная с версии 7. Оно реализовано в функции sys.verify_function, $ORACLE_HOME/rdbms/admin/utlpwdmg.sql, где функция демодулятора определена в файле $ORACLE_HOME/rdbms/admin/utlpwdmg.sql. Начиная с версии 8i Oracle предоставляет возможность подключится от имени некоторого пользователя и затем изменить схему на другого пользователя. Например, можно подключиться как пользователь "scott", но захотеть работать в схеме "apps". Это можно сделать так: ALTER SESSION SET CURRENT_SCHEMA = apps;
  1. Oracle использует сегменты отката, а Microsoft использует в тех же целях TempDB.
  2. Метаданные Oracle управляются так же, как табличные данные. Поэтому при запросе данных одновременно можно выполнить большинство DDL-операций (добавлении/сброс индексов, добавление разделов и даже реорганизацию пространства). Это же верно и для сессий, использующих Flashback Query. В SQL Server сейчас все DDL-операции над таблицами в режиме "Snapshot Isolation" запрещены.

После чтения заметок о SQL Server 2005 Beta 2 Snapshot Isolation на Microsoft TechNet, хотелось бы упомянуть еще несколько моментов.

Мы по-прежнему полны скепсиса в отношении оптимистического/пессимистического контроля параллелизма. Есть много причин работать в неблокирующем, а не в блокирующем режиме. При работе в неблокирующем режиме производительность Oracle сравнима с MS SQL в блокирующем режиме при учете всех аспектов: масштабируемости, управляемости, простоты дизайна и кодирования.

В нескольких статьях по SQL Server (например, http://www.microsoft.com/technet/prodtechnol/sql/2005/SQL05B.mspx) говорится, что рекомендуется работать с использованием пессимистического режима блокировок для достижения лучшей производительности.

Однако Oracle, который всегда работает в оптимистическом режиме блокировок, достигает на том же железе той же производительности, что и SQL Server в пессимистическом режиме. Похоже, что код SQL Server стоило бы еще немного оптимизировать. Например, посмотрите на результаты TPC-C, полученные на Unisys ES7000 Aries 420 Enterprise Server.

ПРИМЕЧАНИЕ

Примечание: поскольку лицензии Oracle дороже, чем SQL Server, аппаратное обеспечение, используемое при тестах MSSQL 2000, несколько лучше.

Таблица 2.

СУБД tpcc/m $/tpcc
Oracle Database 10g EE 291413 4.98 US$
Microsoft SQL 2000 EE 309036 4.49 US$

Результаты, приведенные в таблице, показывают, что производительность SQL Server на 6% выше. Но Oracle лучше работает под Unix, а не под Windows. СУБД Oracle показывает примерно ту же производительность, что и SQL Server в пессимистическом режиме, но Oracle работает в оптимистическом режиме блокировок.

Кроме того, статьи по SQL Server кое-где сравнивают MSSQL 2005 с ранними версиями Oracle, 8i и ниже. Это похоже на сравнение последнего StarOffice7 с Microsoft Word 2.0. Например, в одной из статей обсуждается ручное управление сегментами отката.

Приведенная ниже таблица содержит анализ документа “SQL Server 2005 Beta 2 Snapshot Isolation”, опубликованного 13 июля 2004 года. Мы обнаружили четыре факта, по которым наше мнение не совпадает с мнением авторов этой статьи, критикующих СУБД Oracle в пользу SQL Server. Наше мнение основано на нашем опыте и знаниях.

Онлайн-реорганизация данных

Исторически SQL Server предоставлял крайне ограниченный набор реорганизаций данных и индексов по сравнению с такими конкурентами, как Oracle или DB2. До MS SQL Server 2005 существовала только операция DBCC INDEXDEFRAG, сравнимая с "alter index coalesce" в Oracle, которая может быть выполнена без эксклюзивной блокировки нижележащей таблицы. Такие выражения, как "DBCC DBREINDEX" или "CREATE INDEX ... WITH DROP_EXISTING" вызывали эксклюзивную блокировку. Начиная с MSSQL 2005, при онлайн-работе с индексами возможна параллельная модификация (обновление, удаление и вставка записей) данных нижележащей таблицы или кластерного индекса, а также любых ассоциированных индексов при исполнении DDL-операций над индексами. Например, во время перестройки кластерного индекса можно продолжать вносить изменения в нижележащие данные и выполнять запросы к данным.

Что ж, в Oracle есть возможность перестройки большинства видов индексов и даже целых таблиц без эксклюзивной блокировки на время этой операции. Однако для завершения операции необходима кратковременная блокировка. Мы надеемся, что Microsoft предоставит возможность онлайн-реорганизации таблицы и перемещения в другую файловую группу.

Таблица 3.

Мнение авторов SQL Server 2005 Beta 2 Snapshot Isolation Наше мнение
Требует сложного конфигурирования ROLLBACK SEGMENTS (определения и онлайн/офлайн) и выражений уровня транзакции USE ROLLBACK SEGMENT для исключения ORA-01555: "Snapshot too old.", вызываемого «длинными» транзакциями, перезаписывающими свои версии страниц в сегменте отката.Замечание: У Oracle нет определения «длинных» транзакций. 1. Начиная с Oracle 9i конфигурирование ROLLBACK SEGMENTS автоматизировано. 2. В Oracle10g новый параметр UNDO_RETENTION_PERIOD указывает минимальный период хранения undo-информации. Это гарантирует, что ORA-01555 не будет выдано столько, сколько нужно транзакции.Oracle не нуждается в определении «длинных транзакций»
ROLLBACK SEGMENTS не поддерживают PCTINCREASE и, следовательно, не увеличиваются автоматически, так что приходится задавать правильный размер при их создании. Undo-сегменты увеличиваются автоматически до заполнения табличного пространства undo. После этого файлы данных табличного пространства undo автоматически увеличиваются (если это определено).
MSSQL Server 2005 Oracle READ COMMITTED (блокирующая) нет эквивалентаREPEATABLE READ нет эквивалентаSERIALIZABLE нет эквивалента Пессимистические режимы блокировок не нужны, так как та же производительность достигается Oracle с оптимистическими режимами блокировок.
Требуется разрешать конфликты (ORA-08177: data page updated outside of the transaction) и повторять неудавшиеся транзакции.Требуется использование INITRANS >= 3 & MAXTRANS для CREATE/ALTER TABLE DDL, чтобы выделить пространство для размещаемой на странице транзакционной информации до использования SERIALIZABLE.Страничная версионность данных – Oracle должен перестраивать целую страницу. Использование другими транзакциями SERIALIZABLE-доступа к другим строкам обновленной страницы вызывает ORA-08177: "Can't serialize access for this transaction." (не могу сериализовать доступ для этой транзакции). Пессимистические режимы блокировок не нужны, так как та же производительность достигается Oracle с оптимистическими режимами блокировок.Если вы АБД Oracle, вы, скорее всего, никогда не использовали (и не видели, как другие используют) SERIALIZABLE.
Приложения всегда видят потенциально устаревшие данные, поскольку нет выбора режима параллелизма. Если нужны свежие, неизмененные данные, используйте "select for update".

ПРИМЕЧАНИЕ

Примечание:

Все эти опции описаны в руководстве по SQL Server. Мы приводим только некоторые примеры для каждой опции. Есть два основных случая, требующих перестройки индексов в Oracle и MSSQL:

Случай А.

Индекс становится сильно искаженным или фрагментированным из-за множества удалений. Поскольку B-Tree-индексы в MSSQL сбалансированы, случай искажения индекса не является существенным, но фрагментированным он может быть – особенно в случае кластерного индекса и высокого DML-параллелизма.

Для выявления таких случаев нужно использовать "DBCC SHOWCONTIG", и смотреть на Level в MSSQL, и на колонку BLEVEL в user_indexes / dba_ind_partitions в Oracle (чтобы гарантировать, что индексы анализируются). В дополнение, в случае Oracle можно сделать дамп из нескольких блоков индекса на разных уровнях, чтобы проверить, что он не перекошен и не фрагментирован.

Для этого в Oracle нужно выполнить:

ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME TREEDUMP LEVEL XXXXX';

Здесь ХХХХХ – это id объекта для указанного индекса. В Oracle в этом случае нужно выполнить выражение "alter index index_name rebuild” или “alter index index_name coalesce”, чтобы удалить пустые блоки из структуры индекса и изменить верхнюю точку сегмента. В Oracle 10g эквивалентное выражение – "ALTER INDEX ... SHRINK SPACE COMPACT”, сжимающее индекс и освобождающее блоки для повторного использования.

Случай В.

Вы ожидаете большого числа вставок и нуждаетесь во времени отклика, близком к реальному. В этом случае можно перестроить индекс, чтобы установить pctfree в Oracle или fillfactor и pad_index в MSSQL во избежание частого разбиения индексных страниц в MSSQL и блоков в Oracle, вызывающего серьезное снижение производительности, особенно в случае больших и глубоких B-Tree-индексов.

Более глубокие сведения по индексам MSSQL, разбиению блоков и многму другому можно почерпнуть из http://www.microsoft.com/resources/documentation/msa/idc/all/solution/en-us/rag/ragc06.mspx или книги Kalen Delaney “Inside Microsoft SQL Server 2000”. Это, без сомнения, лучшая книга по MS SQL Server. Kalen, мы ждем “Inside Microsoft SQL Server 2005” :-)

Разбиение

Физическое разбиение таблиц и индексов – новинка MSSQL 2005. В MSSQL 2000 при кластеризации применялось только изменяемое представление, содержащее объединение (union).

Oracle предоставляет несколько фиксированных типов разбиения. АБД может выбрать, должна ли таблица быть разделена по интервалам, хешу или списку. Однако эти схемы разбиения покрывают большинство возможных ситуаций. В Oracle АБД определяет разбиение, используя DDL-выражение "create table”. В дополнение, для облегчения поддержки Oracle предоставляет возможность двухуровневого разбиения. Например, таблица может быть разбита по интервалам, а каждый из разделов может быть разделен по хешу. Такая возможность имеет смысл в случае таблиц со многими миллиардами строк и не поддерживается в MSSQL.

Однако эту возможность можно симулировать, используя сложные функции разбиения.

MSSQL 2005 предоставляет более гибкие возможности разбиения, чем Oracle. В MSSQL 2005 разбиение реализовано с помощью пользовательских функций на Transact-SQL или любом из .NET-языков.

Для определения разбиения таблицы нужно выполнить три шага, описанных в разделе “Creating Partitioned Tables and Indexes” в MSSQL 2005 Books Online:

Одну схему разбиения могут использовать несколько таблиц. Разбиение как таблиц, так и индексов прекрасно работает в MSSQL 2005 beta 2.

Индексы

В Oracle возможности индексирования богаче, чем в MSSQL 2005. В то время как в MSSQL по-прежнему используются только BTree-индексы, сравнимые с обычными индексами Oracle, и кластерные индексы, подобные Oracle IOT, в Oracle используются битовые индексы, лучше всего подходящие для колонок с низкой селективностью. Вдобавок в Oracle используются обратные BTree-индексы, хорошо подходящие для уменьшения числа конфликтов при вставке последовательных значений. Последняя из связанных с индексами возможностей Oracle – основанный на ключах кластер, дающий лучшую производительность при выборке из нескольких связанных таблиц по совпадающим ключевым колонкам, включенным в кластер.

Кластеризация

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

В Oracle 10g появились RAC/Grid-кластеры, легко масштабируемые даже в стандартной версии Oracle. Это одно из существенных преимуществ Oracle 10g перед MSSQL 2005.

Oracle содержит ASM (Automatic Storage Management), новое встроенное программное решения для управления хранением данных, помогающее в развертывании RAC/Grid-кластеров. Кроме того, Oracle предоставляет собственную бесплатную (!) кластерную файловую систему для платформ Linux и Windows, помогающее избежать использования «сырых» устройств.

Настройка

Индексы, основанные на функциях,

Oracle предоставляет возможность создания индекса по функции, примененной к указанной колонке. В MSSQL есть возможность создания так называемой «вычисляемой колонки» и возможность создания индекса для этой колонки. Эти возможности, в сущности, эквивалентны. В Yukon введено ключевое слово PERSISTED для выражений CREATE TABLE и ALTER TABLE для физического сохранения вычисляемых колонок в таблице. Их значения обновляются, когда изменяются любые колонки, участвующие в вычислениях. Пометка вычисляемой колонки словом PERSISTED позволяет создавать индексы для вычисляемой колонки, которая является детерминированной, но не обязательно точной.

Индексированные представления MSSQL 2005 vs. материализованных представлений Oracle

Начиная с MSSQL 2000 и Oracle 8i, обе СУБД поддерживают материализованные представления. Эти представления помогают избежать дорогих и тяжелых соединений различных таблиц, особенно в Data Warehouse-окружениях. Результат SQL-выражения, создающего представление, материализуется на диске в форме, сходной с таблицей. В MSSQL 2000 материализованные представления были ограничены в отношении доступных типов данных и функций.

MSSQL 2005 также содержит существенный список ограничений для функций и агрегаций. Indexed View в MSSQL все еще имеет ряд ограничений по сравнению с Oracle. Например, определение индексированного представления не может содержать следующих крайне полезных агрегаций, функций и опций: производных таблиц (подзапросов во FROM), ссылок на другие представления, DISTINCT, EXISTS, NOT EXISTS, self-join, выражений с результатами агрегаций (например, SUM(x)+SUM(x)), STDEV, STDEVP, VAR, VARP, AVG, Subquery, SUM для выражений, допускающих null, и UNION.

В MSSQL достаточно создать кластерный индекс для представления, чтобы создать "Indexed View" из обычного определения представления:

CREATE UNIQUE CLUSTERED INDEX index_name on pre_defined_view(column_list)    

Чтобы создать "Materialized View" в Oracle, представление нужно создавать как материализованное:

CREATE MATERIALIZED VIEW view_name view_definition (вместо просто CREATE VIEW)

Импорт/экспорт данных

Oracle 10g содержит новую утилиту для экспорта данных, "data pump". К сожалению, она выдает данные в очередном проприетарном бинарном формате Oracle. В Oracle есть две опции экспорта и две – импорта, exp/data pump и imp/data pump, соответственно. Кроме того, в Oracle есть утилита sqlldr для импорта текстовых данных и так называемых внешних таблиц, которая позволяет применять SQL-выражения к структурированным текстовым файлам, как если бы это были таблицы РСУБД.

В MSSQL 2005 есть две возможности импорта/экспорта, а именно bcp и DTS. Bcp может экспортировать и импортировать данные, используя текстовый формат, который может быть легко импортирован в РСУБД другого производителя. DTS – это высокопроизводительное, программируемое ETL-средство, не имеющее опций, совместимых с Oracle.

Кроме того, MSSQL 2005 DTS дает возможность создавать рабочие процессы, аналогичные создаваемым Oracle Workflow Builder. Однако в основном DTS используется для наполнения данными хранилищ, а не для создания бизнес-процессов. Углубленное сравнение возможностей DTS и Workflow по построению бизнес-логики не относится к предмету этой статьи.

Репликация

Транзакционная репликация «точка-точка»

В MSSQL 2005 содержится новая возможность транзакционной репликации «точка-точка», улучшающая поддержку масштабирования данных с использованием репликации. Однако у этой возможности есть следующие ограничения:

Транзакционная репликация может быть полезна при масштабировании. Однако ограничения, описанные выше, делают эту возможность не столь подходящей для BI-задач реального времени, как репликация реального времени с трансформацией.

Потоки репликации Oracle и MSSQL очень похожи. Но правила потоков репликации Oracle 9i были в Oracle 10g дополнены новой возможностью – «движком правил». Эта возможность позволяет применять онлайн-трансформацию реплицируемых данных. Кроме того, Oracle 10g поддерживает фильтрацию строк и колонок, процедуры ручного разрешения конфликтов, отображение колонок и таблиц и т.д.

Зеркалирование БД

В SQL Server 2005 существенно улучшены возможности log shipping посредством возможности «зеркалирования» (mirroring) БД. Зеркалирование БД позволяет выполнять постоянную передачу лога транзакций с сервера-источника на одиночный сервер назначения. В случае отказа системы-источника приложения могут подключиться ко вторичному серверу практически мгновенно, не ожидая окончания восстановления. Вторичный экземпляр БД обнаруживает отказ первичного сервера в течение нескольких секунд и начинает принимать подключения к БД практически сразу после обнаружения отказа. В отличие от отказоустойчивых кластеров, зеркальный сервер кэширован и готов принять рабочую нагрузку благодаря своему синхронизованному состоянию. На самом деле это означает, что вам нужны три экземпляра MS SQL Server. Однако активным при этом будет только один экземпляр, и должна быть доступна резервная БД (недоступная пользователям до момента сбоя).

В Oracle используется очень похожее на применяемое в MSSQL зеркалирование, с помощью физического резервирования при помощи Dataguard. Единственное различие в том, что в Oracle нужны только два экземпляра: активный и пассивный.

ПРИМЕЧАНИЕ

Не факт, что так оно и есть. Эту возможность авторы рассматривают на примере MS SQL Server 2005 Beta 2, но, по имеющимся сведениям, она так и не была до конца доработана вплоть до выхода окончательной версии. – прим. ред.

Резервное копирование и восстановление

Подключение/восстановление БД

С помощью Online Restore в SQL Server 2005 АБД могут выполнять операции восстановления во время работы экземпляра SQL Server. Online Restore повышает доступность SQL Server, так как при этом недоступными являются только восстанавливаемые данные; остальная часть БД остается доступной.

В Oracle есть аналогичные возможности, реализуемые с помощью табличных пространств (tablespace). Так, например, сброс и импорт табличного пространства, могут выполняться во время работы Oracle. Однако нельзя взять старое (например, с SCN до текущего) не переносимое табличное пространство и восстановить его на работающем экземпляре. Такая операция может нарушить целостность данных. Кроме того, табличные пространства Oracle не являются законченной сущностью, так как для описания структур объектов, содержащихся в каждом табличном пространстве, используются словарные метаданные

С нашей точки зрения, структура БД MSSQL проще и лучше спроектирована, чем табличные пространства Oracle. С другой стороны, у Oracle больше возможностей восстановления поврежденных БД, redo-логов или файлов данных, чем у SQL Server.

По нашему опыту: однажды, в начале 2000 года, мы наблюдали отказ носителей на БД SQL Server (одновременно вышли из строя три диска из пяти в RAID 5 на сервере IBM eSeries), причем на этом RAID 5 находился лог транзакций для рабочей БД. Несмотря на то, что все файлы данных находились на другом диске и были доступны, нам не удалось открыть БД в каком-либо виде для того, чтобы экспортировать данные через bcp или dts.

Здесь нужно отметить, что поскольку у MS SQL Server нет отдельной структуры для поддержки информации об откате, и она хранится вместе с redo-информацией в логе транзакций, такая ситуация сравнима с потерей текущего redo-лога одновременно с повреждением сегмента отката, что и в Oracle является крайне тяжелой ситуацией. Восстановление осложняется, и даже не всегда возможно, если БД нельзя восстанавливать или хотя бы открыть в неопределенном (inconsistent) состоянии. Мы не нашли способа (а может быть, такого способа и вовсе нет) открыть БД SQL Server в неопределенном состоянии (в том числе и сейчас, используя MSSQL 2005). Oracle позволяет это, и мы делали так в нескольких крайне тяжелых ситуациях, изменяя два параметра init.ora: _allow_resetlogs_corruption и _corrupted_rollback_segments. Кстати, оба эти параметра не поддерживаются Oracle Support. :)

Microsoft также предоставляет несколько недокументированных флагов (унаследованных от Sybase SQL Server), которые можно использовать в случае повреждения или потери логов транзакций. Например, флаг трассировки (trace flag) 3608. Если он установлен, MSSQL пропускает автоматическое восстановление (при запуске) для всех БД кроме БД master. Используя этот флаг (3608), можно заставить MSSQL сгенерировать новый пустой лог транзакций вместо потерянного. Однако в приведенной выше ситуации этот флаг не помог. Чтобы установить этот флаг, нужно просто открыть сервис MSSQL в менеджере сервисов Windows и добавить -t3608. Например: %MSSQL2000_HOME%\mssql\binn\sqlservr.exe -t3608.

Если утерян лог транзакций не для БД master, будет создан новый лог транзакций с именем %YOUR_DB_NAME%_log.LDF. В случае проблем с БД master, ее можно легко пересоздать с помощью утилиты rebuildm.exe. Наличие такой утилиты сильно упрощает жизнь по сравнению с Oracle в случае потери системного табличного пространства.

В Oracle есть богатый набор логических дампов, которые могут помочь выявить проблему, которая привела к необходимости восстановления, временных меток для онлайн- и резервных файлов, и т.д. MS SQL Server предоставляет несколько дампов, основанных на DBCC PAGE и DBCC LOG. DBCC PAGE хорошо описана в Inside Microsoft SQL Server 2000, а DBCC LOG документирован в материалах Sybase (поскольку большую часть DBCC Microsoft унаследовал от Sybase). В MSSQL практически невозможно выполнить сколько-нибудь необычное восстановление из-за очень ограниченного числа доступных параметров, даже если АБД хорошо понимает суть проблемы.

Горячее резервное копирование

Начиная с MSSQL 2000 существует VDI С API, позволяющее выполнять горячее резервное копирование через зеркальное разбиение. Это позволило таким сторонним разработчикам, как NetApp или EMC, и производителям менеджеров хранения (как Veritas) использовать свои Mirror/Split-решения для выполнения резервного копирования онлайн.

В Oracle режим горячего резервного копирования дает возможность расщепления зеркал без нарушения целостности данных. Это лучше, чем VDI в смысле 24/7, поскольку в режиме горячего резервного копирования экземпляр Oracle остается полностью функциональным. С другой стороны, VDI вызывает полную приостановку всех БД на экземпляре SQL Server (включая выражения выборки) на все время разделения зеркала. Время, затрачиваемое на такое разделение, зависит от используемого решения.

Несмотря на то, что Oracle позволяет не приостанавливать операции на время разделения зеркала для целей резервного копирования, наш опыт показывает, что это не всегда хорошо работает. Например, мы пытались выполнить онлайн-резервирование с помощью разделения BCV-тома на тяжело загруженном экземпляре Oracle, работавшем на высокопроизводительном сервере HP SuperDome, подключенном к хранилищу EMC DMX. Нам несколько раз не удавалось восстановить работоспособность отделенной части зеркала.

Проблемы с тяжело загруженными высокопроизводительными машинами не так уж редки, и для разрешения подобных ситуаций Oracle добавил два выражения “alter system“:

alter system QUIESCE RESTRICTED
alter system suspend  

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

Быстрое восстановление

Новые возможности быстрого восстановления повысят доступность баз данных SQL Server. Администраторы смогут подключаться к восстанавливаемым БД после «наката» лога транзакций.

В Oracle так делается, начиная с версии 8 (а возможно, и с 7.4.3). Это просто значит, что раньше Microsoft SQL Server использовал очень неоптимальный алгоритм.

Пример из реальной жизни. Несколько месяцев назад одна из компаний, с которой мы работали, выполняла тестирование высокой доступности MSSQL на высокопроизводительном сервере Unisys под Windows. После сбоя при запуске мы обнаружили странную ошибку: все выглядело так, будто завершено восстановление БД. Затем сервер начинал работать, но данные были повреждены. Когда мы увидели лог, возникла мысль, что это могло бы случиться в процессе отката, хотя БД пока что не открывалась. После длительных исследований мы не нашли, почему выполнялось восстановление (roll-forward), но БД по-прежнему не открывалась. АБД Oracle мог бы предположить, что БД откроется после окончания наката. В любом случае, начиная с MSSQL 2005 это должно работать именно так.

RMAN с Legato и Oracle Job Scheduler vs. планов поддержки MSSQL

В Oracle имеется богатый скриптовый интерфейс для автоматического резервного копирования, позволяющий выполнение инкрементального резервирования, сжатия, автоматического сохранения резервных копий и т.д.

Кроме того, в дистрибутив Oracle EE входит менеджер резервного копирования Legato, поддерживающий большинство типов стримеров и каталогизацию.

В Oracle 10g PL/SQL-пакет DBMS_JOB был расширен и получил название DBMS_SCHEDULER. Этот пакет позволяет запускать такие фоновые задания, как сбор статистики, или реорганизовывать объекты БД, или взаимодействовать с менеджером ресурсов и отслеживать выполнение этих заданий.

В MSSQL есть такая возможность, как «планы поддержки», чья функциональность сравнима с Oracle Job Scheduler. Кроме того, планы поддержки позволяют создавать точные определения для автоматического резервного копирования.

Приложения

Обработка исключений

Конструкция TRY/CATCH в Transact-SQL имеет функциональность, сравнимую с исключениями в Oracle PL/SQL.

Функции онлайн-аналитики

Улучшения Transact-SQL в SQL Server 2005 предоставляют новые возможности языка для разработки масштабирующих приложений, работающих с базами данных. Эти усовершенствования включают обработку ошибок, возможность рекурсивных запросов, реляционные операторы PIVOT, APPLY, ROW_NUMBER и другие функции ранжирования строк, а также многое другое. Начиная с Oracle 8i и по 10g Oracle постоянно увеличивает число доступных функций онлайн-аналитики. В Oracle 10g можно использовать почти сотню аналитических функций в различных комбинациях. Однако оператор PIVOT, используемый преимущественно в Online Analytical Functions для интеграции с Excel или другими электронными таблицами, не имеет аналогов в Oracle. Чтобы получить функциональность PIVOT, используйте один из bean-ов из набора BI в Oracle OLAP.

Запросы

MSSQL 2005 Service Broker предоставляет надежную, масштабируемую, распределенную, асинхронную функциональность для приложений, работающих с БД. Эта возможность в целом сравнима с Oracle Advanced Queuing, но функциональность Oracle Advanced Queue гораздо шире, так как имеет больше вариантов активации, может быть синхронной/асинхронной, персистентной/не персистентной, и т.д.

Главная идея состоит в том, что некое приложение (или управляемый код БД) помещает сообщения в очередь или очереди, а другие приложения (или управляемый код БД) получают оповещения: в MSSQL через триггер или обычный SEND/RECEIVE, а в Oracle через триггер типа "Asynchronous Notifications".

"Asynchronous Notifications" реализуются в Oracle через PL/SQL или Java-сервлеты (используя следующие API-функции: sys.aq$_reg_info для создания регистрационных объектов, sys.aq$_reg_info_list для создания списков этих объектов и sys.dbms_aq.register для регистрации списков).

В MSSQL каждая очередь может иметь триггер оповещения на Transact SQL или .NET-языках, выполняемый после прихода сообщения в очередь. И в MSSQL, и в Oracle по причинам производительности реализованы функции массовой постановки/вывода из очереди.

С нашей точки зрения, использование БД в качестве очереди сообщений весьма накладно. Если действительно нужна персистентная очередь, более удачным способом было бы использование MSMQ под Windows или очередей Sleepy Cat на BerklyDB. По нашему опыту использования Oracle AQ, очереди, использующие БД, редко показывают хорошую производительность, но тратят ресурсы CPU, дисковое пространство и пр.

Возможно, после выпуска релиза MSSQL 2005 мы сможем предоставить данные тестирования производительности запросов в Oracle и SQL Server.

Поддержка XML

Начиная с MSSQL 2005, SQL Server предоставляет возможность хранить, индексировать и выполнять запросы к XML-документам, хранящимся в реляционной БД, включая интеграцию реляционных и XML-данных. В Oracle есть похожая возможность, XML DB.

Асинхронный массив обработанных выражений

Множественные активные наборы результатов (Multiple active result sets, MARS) реализованы в MSSQL 2005 с помощью множественных асинхронных массивов обработанных выражений

Oracle может предоставить аналогичную функциональность с помощью нескольких SQL-выражений на одном подключении, выполняемых в асинхронном режиме, т.е. через OCI.

.NET в MSSQL vs. Java в Oracle

Похоже, что у MSSQL 2005 есть серьезное преимущество перед Oracle. Java в СУБД Oracle может быть вызвана косвенно, то есть либо должна быть обернута PL/SQL, либо использоваться через CORBA или EJB-интерфейсы, тогда как .NET в MSSQL используется так же прозрачно, как Transact-SQL.

Кроме того, загрузка и поддержка Java-объектов в Oracle – это то же самое, что поддержка целого сервера Java-приложений. С другой стороны, MSSQL предоставляет простой интерфейс для разработки, отладки и использования .NET-триггеров, хранимых процедур и пакетов в MSSQL 2005.

Полезные возможности Oracle, не имеющие аналогов в MSSQL 2005

Oracle Logminer

Oracle Logminer дает возможность извлечь историю DML/DDL-операций, выполняемых над БД. Это значит, что можно взять старый redo-лог и увидеть полный протокол транзакций. Это используется для аудита, репликации или создания скриптов отката.

В MSSQL 2005 эквивалентной функциональности нет, хотя инструменты сторонних разработчиков, такие, как Lumigent Log Explorer, могут выполнить это. Однако одно из новшеств MSSQL 2005, а именно DDL Event Notifications, позволяет создавать события для DDL-операций и других системных событий, и обрабатывать данные этих событий как сообщения.

Flashback-запросы

Еще одна полезная возможность в области безопасности и восстановления после сбоев, порожденных человеческим фактором – Flashback Query в объединении с появившимся в 10g "Dropped Objects Recycle Bin". Идея в том, чтобы получить снимок объекта БД, например, увидеть таблицу на какой-то момент времени в прошлом. Единственное ограничение состоит в том, что требуется undo-пространство для хранения записей, необходимых для отката блоков данных в памяти до нужного момента времени.

В MSSQL 2005 похожих возможностей нет, хотя для некоторых моментов времени Flashback Query можно симулировать, например, запуская транзакции с уровнем изоляции «Snapshot». При этом все запросы select, выполняемые в контексте данной транзакции, будут возвращать данные на момент первого выражения этой транзакции.

"Dropped Objects Recycle Bin" из Oracle 10g все еще нельзя симулировать в MSSQL 2005, так как версионности строк для метаданных в MSSQL 2005 нет, и DDL-операции над всеми таблицами, на которые наложена хотя бы разделяемая блокировка, означают, что выборка запрещена.

Аудит

Благодаря новому параметру init.ora audit_trail = db_extended возможен аудит всех SQL-запросов вместе со значениями переменных связывания.

В MSSQL единственный способ аудита – использование MSSQL trace, не имеющего возможности вывода переменных связывания, и порождающего значительные накладные расходы.

История статистики

Поскольку статистика в Oracle на самом деле является блоками данных в словарных таблицах, flashback-опция позволяет АБД восстановить статистику на какой-то момент в прошлом. Если планы исполнения запросов update меняются к худшему, из-за какого-то анализа, или из-за повторов в статистике, можно «откатить» статистику и повторить разбор запроса со старой статистикой.

Статистика отката

Если у вас не удалась и откатывается тяжелая транзакция, как оценить, сколько времени займет откат, и насколько это замедлит экземпляр СУБД? Да, в MSSQL – никак.

До версии 10g в Oracle это можно было прикинуть с помощью скрипта, например, приведенного по адресу http://www.wisdomforce.com/dweb/resources/docs/complete_rollback_script.pdf

В Oracle 9i и10g можно легко проверить расчеты Oracle с помощью запроса к новому фиксированному представлению V$FAST_START_TRANSACTIONS.

Automatic Workload Repository

Oracle 10g предоставляет новый набор фиксированных представлений V$SOME_STATISTIC_HISTORY, где SOME_STATISTIC – имя одного из представлений общего назначения. Эти представления содержат автоматически собираемую информацию по исторической статистике.

Примерами таких представлений являются:

Идея в том, что если вы знаете, что в какой-то момент, но менее чем 24 часа назад, ваша РСУБД была крайне загружена, или время отклика было очень большим, или какое-то приложение дало сбой по причинам производительности БД, вы можете немедленно исследовать проблему. Однако для этого не нужно запускать никакой онлайн-механизм сбора статистики.

Поскольку Automatic Workload Repository – это внутренний механизм Oracle, его влияние на производительность несущественно. До Oracle 10g таких же результатов можно было добиться при помощи дорогостоящих инструментов сторонних разработчиков, типа Precise (Veritas) Indepth или Quest SQLab Vision

Такие объектно-ориентированные возможности, как объекты и vararray

Oracle содержит несколько базовых объектно-ориентированных возможностей. Эти возможности позволяют Oracle называть свой продукт ОРСУБД, или «объектно-реляционным». Однако эти возможности на самом деле относительно элементарны, и схожи с возможностью хранения в строках данных таких структур, как данные, массивы переменной длины и вложенные таблицы. С чисто теоретической точки зрения у вложенных таблиц нет преимуществ перед двумя коррелированными таблицами, которые могут быть соединены по PK -> FK (первичный ключ -> внешний ключ). Однако такие возможности есть, и это хорошо. Заметьте, что при использовании этих возможностей производительность несколько падает.

Опциональная компиляция PL/SQL в native-код (библиотеку) с помощью компилятора С

Сегодня большая часть усилий разработчиков направлена на все большее использование таких виртуальных машин, как Java, CLR и т.д. Однако native-код все еще обеспечивает лучшую производительность. Начиная с Oracle 9i, Oracle позволяет скомпилировать PL/SQL-код в native-библиотеку. В большинстве случаев, если PL/SQL-код включает сложные вычисления, такая компиляция увеличивает производительность на десятки процентов. Однако поддержка этой возможности для RAC в Oracle 9i не выглядела такой уж «родной». Разделяемые библиотеки не распределялись по узлам автоматически. Кроме того, эта возможность влекла за собой некоторое излишнее администрирование. В Oracle 10g поддержка компиляции PL/SQL в native-код упростилась. Все скомпилированные библиотеки теперь хранятся в БД, так что поддержка RAC улучшилась, а административная нагрузка снизилась.

Полезные возможности Microsoft SQL Server, не имеющие аналогов в Oracle 10g

Идентичность (identity)

Одна из наиболее полезных возможностей, отсутствующих в Oracle – идентичность. Практически любая СУБД предоставляет возможность автоматической генерации первичного ключа, но Oracle так и остановился на последовательностях. Последовательности Oracle – это полезный механизм, однако он порождает серьезные административные издержки. Реализация чего-то похожего на MSSQL Identity с помощью последовательностей Oracle потребует отражать имя последовательности в приложении или создавать триггер для каждой пары таблица-последовательность.

Вторая возможность – Rule, которую можно реализовать на триггерах Oracle. Но в MSSQL реализация Rule весьма легковесна и удобна.

Третья возможность – простые в использовании пользовательские типы данных.

Службы оповещения

Notification Services позволяет создавать приложения, доставляющие персонализированную и своевременную информацию на любое устройство. Эта информация может содержать биржевые сводки, рассылки новостей, сообщения о доставке пакетов или цены на авиабилеты. В MS SQL Server 2005 Notification Services теснее интегрированы с такими технологиями, как Analysis Services и SQL Server Management Studio.

Службы отчетов

Одна из действительно приятных и полезных возможностей MSSQL 2000/2005 – интегрированные службы отчетов, включающие поддержку создания PDF и хорошую IDE. MS SQL 2005 Reporting Services предоставляют меньше возможностей, чем, например, Oracle Reports c Oracle IAS, зато они интегрированы в РСУБД. Это очень экономичное решение, не требующее дополнительных лицензионных отчислений, а также простое в установке и использовании.

Репликация

MS SQL 2005 предоставляет встроенный механизм репликации из MSSQL в Oracle и даже репликации из Oracle в MSSQL. Однако в MSSQL 2005 Beta 2 этот механизм не работает. Хорошо то, что согласно документации репликация из MSSQL 2005 в Oracle работает через тот же Microsoft Log Reader Agent, что и транзакционная репликация Microsoft, так что есть все шансы, что это будет работать хорошо.

Согласно документации MSSQL репликация из Oracle в MS SQL Server 2005 основана на триггерах. Основанная на триггерах репликации замедляет источник данных, не поддерживает изменений метаданных и подвержена ошибкам. Например, для каждой операции вставки в Oracle будет реально выполнено три дополнительных операции (то есть общее число операций будет равно четырем):


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

Copyright © 1994-2016 ООО "К-Пресс"