(Возврат на основную страницу)

Содержание номера за Май 2003 

Editorial

MSDE и SQL Server

Microsoft SQL Server Desktop Engine (MSDE) представляет собой локальную СУБД, построенную на том же ядре обработки данных, что и SQL Server. Процесс разработки приложений для MSDE не отличается от разработки приложений для SQL Server, и это сходство может стать причиной путаницы, особенно когда речь идет о различиях между MSDE и SQL Server 2000 Personal Edition.

Вот семь самых важных различий между MSDE и SQL Server 2000 Personal Edition.

1. MSDE не поставляется отдельно

Microsoft поставляет MSDE в составе следующих продуктов: все редакции SQL Server 2000, Visual Studio .NET, ASP.NET Web Matrix, Microsoft Office XP Developer Edition и Microsoft Developer Network (MSDN) редакций Universal и Enterprise.

2. MSDE свободна от лицензионных платежей

MSDE бесплатна, хотя приходится платить за продукт, с которым она поставляется. Вам не нужно приобретать клиентские лицензии (CAL, Client Access License) для приложений, использующих БД под управлением MSDE, если MSDE не подключена к другой системе SQL Server в качестве клиента.

3. Для баз данных MSDE существуют ограничения

Размер БД MSDE не может превышать 2 Гб. Однако это не накладывает ограничений на максимальный объем хранимых данных, поддерживаемых механизмом MSDE, поскольку он может поддерживать несколько БД, при условии, что каждая из них меньше 2 Гб.

4. Для MSDE существуют аппаратные ограничения

Как и SQL Server 2000 Personal Edition, MSDE поддерживает системы, имеющие не более двух процессоров. Кроме того, MSDE может получать доступ только к 2 Гб оперативной памяти.

5. MSDE не имеет графических инструментов управления

Единственным инструментом, предоставляемым Microsoft для управления MSDE, является консольная утилита osql. В MSDE нет Query Analyzer, Data Transformation Services (DTS) Designer, Analysis Services. Нет даже справочной системы Books Online. Однако вы можете бесплатно загрузить ее со страницы http://www.microsoft.com/sql. Также вы можете управлять MSDE при помощи существующего комплекта инструментов SQL Server, как и любой другой системой SQL Server.

6. MSDE работает на 32-разрядных версиях Windows

Подобно SQL Server, MSDE поддерживает операционные системы Windows NT/2000/XP. Кроме того (как и SQL Server Personal Edition), MSDE работает на системах с Windows 9x/Me. Ограничения, с которыми вам придется столкнуться, когда вы запускаете MSDE на системах с Windows 9x/Me, — это отсутствие интегрированной модели безопасности, асинхронных I/O, упреждающего чтения и счетчиков Performance Monitor.

7. MSDE оптимизирована для одновременной работы пяти пользователей

Для обеспечения высокой производительности MSDE имеет управляемый регулятор (governor) параллельной загруженности, ограничивающий нагрузку пятью одновременно выполняемыми пакетами команд. Если вы создаете большую нагрузку, то регулятор параллельной загруженности постепенно снижает скорость системы. MSDE не отбрасывает эти избыточные пакеты, но обрабатывает их со значительно меньшей производительностью.

Грегори А. Ларсен (Gregory A. Larsen)

Несколько месяцев назад я запускал хранимую процедуру, выполняющую перекрестное соединение БД на компьютере с установленным SQL Server 2000. Эта специфическая процедура обрабатывала записи таблицы из БД А, первоначально созданной на нашем SQL Server 2000, а также записи таблицы из БД В, также находящейся на нашем SQL Server 2000, но созданной в ходе восстановления резервной копии БД SQL Server 7.0. На компьютере с SQL Server 7.0 был установлен отличающийся от нашей БД SQL Server 2000 набор символов и порядок сортировки. Оператор SELECT хранимой процедуры соединял записи таблицы в БД А с таблицей в БД В на ключевом поле с типом данных varchar. Как вы думаете, что случилось? Хранимая процедура не была выполнена и возвратила "collation error" (ошибка режима сопоставления).

В конце концов SQL Server 2000 разрешил проблему получения резервных копий с серверов с другими наборами символов/порядком сортировки и последующего их восстановления без возникновения ошибок режима сопоставления. До появления SQL Server 2000 резервные копии с одного сервера могли быть восстановлены на другом, только если на обоих серверах использовался одинаковый набор символов и порядок сортировки. В SQL Server 2000 вы можете задавать порядок сопоставления на уровне сервера, БД и даже на уровне столбца. Теперь, когда у вас может быть несколько порядков сопоставления на одном и том же сервере БД, стоит разобраться в некоторых вещах, касающихся смешения режимов сопоставления.

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

Рон Тэлмэйдж (Ron Talmage)

В Enterprise Manager SQL Server 2000 включен инструмент создания сценариев, который можно использовать для получения основных команд удаления и создания индексов. Однако для создания подобных сценариев потребуется выполнить немало операций CUT и PASTE, и результат не имеет никаких средств проверки ошибок. В этой статье рассказывается, как можно создать хранимую процедуру в SQL Server, генерирующую сценарии для индексов более простым и гибким способом.

Добавление индексов к таблицам является наиболее эффективным способом оптимизации производительности выполнения запросов SQL Server. Чтобы обрабатывать различные пересылаемые вами аргументы поиска, в запрашиваемых таблицах часто может потребоваться создать нескольких индексов. Хотя есть одна исключительная ситуация, когда индексы на больших таблицах являются помехой. Когда вы выполняете массированное копирование данных в таблицу, наилучшим решением является полное отсутствие в ней индексов или наличие только кластерного индекса. В подобной ситуации лучшим решением является использование сценария на языке Transact-SQL для удаления и последующего добавления этих индексов. В этой статье описано, как использовать хранимые процедуры Transact-SQL для создания подобного индексного сценария Transact-SQL, более сильного и менее трудоемкого, чем инструмент создания сценариев из Enterprise Manager.

Недавно я принимал участие в проекте, целью которого было перемещение некоторого числа больших таблиц с одного сервера на другой. Мы решили использовать утилиту командной строки bcp.exe для экспорта данных и оператор BULK INSERT для импорта их в новую БД. Чтобы оптимизировать процесс импорта данных, на новых таблицах нам не были нужны никакие индексы (за исключением, разве что, кластерного).

Сначала мы использовали инструмент создания сценариев из Enterprise Manager, но столкнулись с рядом проблем, большая часть которых была связана с тем фактом, что нам пришлось выполнять множество операций вырезать/вставить для создания сценария, включающего только ограничения PRIMARY KEY и UNIQUE, индексы и ничего больше. То, что требовалось нам на самом деле, это сценарий, создающий таблицы без индексов, а затем добавляющий все индексы (в первую очередь кластерный), после того как таблица будет заполнена данными.

Нам нужен был такой инструмент создания сценариев, который мы могли бы усовершенствовать, чтобы обеспечить именно тот порядок индексов, что нам требовался. Я мог бы воспользоваться объектной моделью SQL-DMO для прохода по иерархии и вызывать сценарии оттуда, как это делает Enterprise Manager, но при этом мы рисковали наступить на те же грабли (степень гибкости). Вместо этого я создал собственный инструмент при помощи Transact-SQL, с которым вы и познакомитесь, хотя в значительно улучшенной и проверенной форме.

Джон Пол Кук (John Paul Cook)

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

Перед тем как описывать Visual Studio .NET T-SQL Debugger, давайте начнем с описания его предшественника — SQL Server T-SQL Debugger. Несмотря на то, что разработчики приучены использовать SQL Server T-SQL Debugger для отладки хранимых процедур, большинство из них не осознает, что его можно использовать также для отладки пользовательских функций. Однако, если вы выберите пользовательскую функцию в Object Browser и затем щелкните ее правой кнопкой мыши, опция Debug окажется недоступной.

Ключ для решения этой проблемы прост: вспомните, что SQL Server T-SQL Debugger отлаживает хранимые процедуры. Поэтому достаточно создать простую «оборачивающую» хранимую процедуру, вызывающую пользовательскую функцию, которую вы хотите отладить. Отлаживая хранимую процедуру, вы можете проникнуть в код пользовательской функции T-SQL. Если необходимо отладить функцию, то создание процедуры-оболочки — не слишком большая для этого цена.

Visual Studio .NET предлагает прямой интерфейс для отладки пользовательских функций. Нет необходимости создавать хранимую процедуру-оболочку для использования T-SQL Debugger из интегрированной среды разработки Visual Studio .NET. Многие задачи, прежде требовавшие использования инструментов SQL Server, могут быть выполнены прямо в среде разработки .NET. Для этой статьи использовался локальный компьютер под управлением Windows XP с SQL Server 2000 Developer Edition, service pack 1 и Visual Studio .NET Enterprise Architect, service pack 1. Когда SQL Server и Visual Studio .NET установлены локально на одну машину, не возникает никаких особых конфигурационных проблем. Однако в случае удаленной отладки все обстоит иначе, о чем мы поговорим позднее. Удаленным сервером для этой демонстрации служил Windows 2000 с SQL Server 2000 Developer Edition без установленных пакетов обновлений.

некоторые ограничения SQL Server 2000 и Oracle 9i перечислены в табл. 9.

Заключение

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

Преимущества SQL Server 2000:

·       SQL Server 2000 дешевле Oracle 9i.

·       SQL Server 2000 имеет лучший результат по производительности и соотношению цена/производительность (согласно тесту TPC-C).

·       Общепризнанно, что SQL Server 2000 проще устанавливать, использовать и управлять.

Преимущества Oracle 9i:

Oracle 9i поддерживает все известные платформы (а не только на базе Windows).

·       Язык PL/SQL мощнее T-SQL.

·       С помощью пусковых параметров может быть выполнена более точная настройка конфигурации.

Список литературы

1. SQL Server 2000 Books Online

2. Oracle documentation (http://docs.oracle.com/)

3. Oracle and SQL Server 2000 Price Comparison  (http://www.microsoft.com/sql/evaluation/compare/pricecomparison.asp)

4. Why is SQL Server better/worse than Oracle? (http://www.mssqlserver.com/faq/general-sqlvsoracle.asp)

5. Top Ten TPC-C by Performance Version 5 Results (http://www.tpc.org/tpcc/results/tpcc_perf_results.asp)

6. Top Ten TPC-C by Price/Performance Version 5 Results (http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp)

(Возврат на основную страницу)