(Возврат на основную страницу)
Editorial
Стюарт Дж. Джонстон
SQL Server 2008 Delivery Delayed
Programming
Стив Бориотти
Пересылка данных из SQL Server в Exchange
Эрланд Зоммарског
Предоставление разрешений посредством хранимых процедур. Часть 2
DB Design & Warehousing
Кален Делани
Управление пространством данных
Винс Якобони
Перемещение системных баз данных SQL 2005
SQL Server 2008 Delivery Delayed
Подобно тому, как уже взрослый человек отправляется в институт и выходит с пустым дипломом, ведущая СУБД Microsoft будет представлена на большом празднике, запланированном на следующий месяц, но сам продукт выйдет только через несколько месяцев.
25 января Microsoft объявила, что SQL Server 2008 будет включен в список продуктов, по поводу которых состоится празднество 27 февраля (в это число также включены Windows Server 2008 и Visual Studio 2008), однако продукт выйдет не раньше третьего квартала текущего года.
Вместо этого, то, что будет показано на мероприятии «Heroes Happen Here» в ЛосАнджелесе в следующем месяце, называется «функционально полной» версией для технологического ознакомления информационного сообщества («feature complete» community technology preview), как следует из сообщения в блоге «The Data Platform Insider» (http://blogs.technet.com/dataplatforminsider/archive/2008/01/25/microsoftsqlserver2008roadmapclarification.aspx).
«Microsoft очень довольна возможностью представить функционально полную версию на мероприятии Heroes Happen Here и release candidate (RC) во втором квартале календарного 2008 года, тогда как финальная версия ожидается в третьем квартале текущего года», — гласит сообщение в блоге от Франсуа Айенстата (Franois Ajenstat), директора по маркетингу SQL Server.
Нельзя сказать, что это такая уж неожиданность: еще прошлым летом Microsoft заявляла, что целевым сроком выпуска сервера является второй квартал 2008 года, но на фоне сроков выпуска двух других продуктов SQL Server выглядит не лучшим образом.
Работа над Visual Studio 2008 закончена и продукт выпущен в середине ноября.
Точно также, Windows Server 2008, возможно, наиболее ожидаемый из трех, находится в стадии release candidate с начала декабря и, скорее всего, будет выпущен, как запланировано, в сроки проведения самих праздничных мероприятий.
По заявлению Microsoft, дополнительное время на разработку поможет повысить качество SQL Server 2008, как следует из сообщения в блоге.
«Наша цель — выпустить продукт высочайшего качества, и мы просто хотим потратить предоставленное время на достижение высоких целей, как ожидают от нас потребители ПО, — продолжает рассказывать в своем блоге Айенстат. — Это ни в какой мере не влияет на наши планы участия в мероприятии 27 февраля и мы ждем многих из вас в ЛосАнджелесе и на других подобных мероприятиях по всему миру».
От редакции-Нужно сказать, что подобная задержка с выпуском — скорее всего вынужденная мера, связанная с тем, что функционально и на уровне интерфейсов SQL Server очень сильно завязан на работе Visual Studio и Windows Server. Соответственно, приходится ждать выхода продуктов, чтобы внести последние штрихи по интеграции с финальными версиями.
Пересылка данных из SQL Server в Exchange
Вам когда-нибудь хотелось разместить данные вашей организации, которые хранятся в БД под управлением SQL Server на сервере Exchange так, чтобы каждый работающий с Outlook мог получить к ним доступ? Но, наверное, у вас не хватало то времени, то желания узнать, как можно использовать Microsoft MAPI. Далее объясняется, как с помощью набора хранимых процедур вы можете создавать и сохранять в Outlook контакты, встречи, задачи и записи журнала в общих папках Exchange (или Outlook PST). Эти процедуры можно добавить в триггеры таблиц баз данных SQL, таким образом легко переместив ваши корпоративные данные из SQL для размещения в Outlook, если ваша организация использует Exchange Server; изменения, внесенные в таблицы баз данных, могут быть немедленно отображены в общей папке на Exchange. Расширенные хранимые процедуры можно загрузить бесплатно (доступен вариант с базовой функциональностью) с примерами сценариев для реализации триггеров таблиц, загрузки и выгрузки расширенных хранимых процедур.
Расширенные хранимые процедуры: что это такое?
Расширенная хранимая процедура — это откомпилированная программа, которая может быть выполнена SQL Server с использованием тех же правил вызова, что и при вызове хранимой процедуры SQL. По правилам имена расширенных хранимых процедур начинаются с префикса «xp_...». В настоящий момент, с выходом SQL Server 2000 Service Pack 3, расширенные сохраненные процедуры могут быть загружены в базу данных «master» сервера Microsoft SQL Server.
Цель расширенных хранимых процедур — использование дополнительных возможностей программного обеспечения, не являющегося частью стандартных библиотек коллекций SQLфункций. Например, в SQL Server нет встроенной возможности отправки электронной почты, но, используя популярную расширенную процедуру под названием «xp_sendmail», можно отправлять сообщения почты SMTP. Чтобы узнать больше о написании расширенных хранимых процедур, ознакомьтесь с Microsoft SQL Server Platform SDK, являющейся частью Back Office SDK.
Что такое xp_sql2exchange?
xp_sql2exchange — это коллекция расширенных хранимых процедур, с помощью которых вы можете создавать и/или обновлять в Outlook контакты, встречи, задачи и записи журнала в общих папках Exchange (также вы сами можете создавать Exchangeобъекты в папках изолированного файла Outlook PST, но об этом позже). В подпрограммы входят xp_contact, xp_calendar, xp_task, и xp_journal для создания, как вы верно могли предположить, Outlookконтактов, встреч, задач и записей журнала, соответственно в указанном порядке. Не владея глубокими познаниями о CDO или MAPI программировании, разработчик SQL может быстро и эффективно добавить элементы в общие папки на Exchange.
Предоставление разрешений посредством хранимых процедур. Часть 2*
* См. Эрланд Зоммарског. Предоставление разрешений посредством хранимых процедур // SQL Server для профессионалов. 2008. № 2.
Управление пространством данных
Воспользуйтесь преимуществом новых опций для хранения LOB и секционированных данных
DOWNLOAD
Чтобы эффективно управлять хранилищем ваших баз данных, вам необходимо понимать, какие объекты занимают место на диске и как SQL Server хранит эти объекты. В SQL Server 2000, например, использование пространства определяет одна простая системная таблица, только два объекта занимают дисковое пространство, и только три типа страниц существует для хранения пользовательских данных.Такой структурой сравнительно легко управлять, но у нее также есть свои ограничения, особенно касающиеся того, как SQL Server хранит и извлекает данные большиx объектов (LOB). Улучшенная модель хранения SQL Server 2005 расширяет количество и типы данных объектов, которые занимают пространство, предоставляет вам более гибкие настройки для хранения объектов данных LOB разной длины и добавляет функциональности хранению данных в нескольких различных разделах. Давайте рассмотрим основную модель хранения SQL Server 2000, а затем обсудим, как SQL Server 2005 управляет данными в дисковом пространстве.
Пространство хранилища в SQL Server 2000
В релизах SQL Server, предшествующих SQL Server 2005, только две вещи в базе данных реально использовали пространство хранилища: таблицы и индексы. Вдобавок, количество способов сохранения информации в индексах и таблицах невелико.
SQL Server 2000 обеспечивает три типа страниц для хранения информации приложения: страницы индексов, страницы данных и третий тип данных страниц для хранения LOBданных. LOBданные определяются как данные одного из трех типов: text, ntext, или image.
Этой относительно простой модели хранения требуется только одна системная таблица, sysindexes, для отслеживания всех объектов SQL Server, требующих выделения пространства. В sysindexes содержится по одной строке для каждой таблицы и по одной строке для каждого индекса таблицы. В ней также дополнительно хранится по одной строке для каждой таблицы для отслеживания LOBданных, содержащихся в таблице. Каждая строка из sysindexes содержит информацию о том, сколько дискового пространства занимает таблица, индекс или LOBданные и где вы можете найти страницы для данных структур.
Если у таблицы есть кластеризованный индекс, данные таблицы считаются частью индекса, так что строки данных на самом деле указываются как строки индекса в sysindexes. Для таблицы с кластеризованным индексом в sysindexes есть строка с индексом ID (indid), значение которого равно 1. Если у таблицы нет кластеризованного индекса, то нет и организации данных таблицы; такую таблицу мы называем кучей (heap). У кучи в sysindexes значение indid равно 0. Каждому дополнительному индексу соответствует строка в sysindexes, в которой содержится значение indid от 2 до 250.
В sysindexes столбец, который содержит значение indid имеет тип tinyint, это значит, что он не может принимать значение более 255.Максимальное значение indid для индекса равно 250, потому что значения 251254 зарезервированы, и SQL Server 2000 использует специальное значение indid, равное 255, чтобы следить за страницами, содержащими LOBданные. SQL Server использует те же столбцы в sysindexes для отслеживания пространства таблиц или индексов, занимаемого всеми LOBданными в любой строке или столбце таблицы.
Простота таблица sysindexes является одной из ее сильных сторон. Однако SQL Server 2005 решает некоторые проблемы структуры таблицы sysindexes.
Первая проблема состоит в том, что в таблице sysindexes хранятся строки для статистики по столбцам, не связанной с индексом, а это значит, что эти статистические данные должны иметь indid с уникальным значением. Если для таблицы у вас много статистических данных, у вас могут закончиться значения indid, до того как вы построите все необходимые вам для таблицы индексы.
Sysindexes также нельзя использовать для других типов страниц или перепроектировать, если отношения между страницами изменятся. Наконец, так как SQL Server 2000 считает LOBданные особым видом данных, связанным с таблицей, индексы не могут содержать LOBданные. В SQL Server 2000 и более ранних нельзя создать индекс для столбцов типа text, image или ntext, так чтобы в структура sysindexes оставалась работоспособной. Но положение вещей изменилось с приходом SQL Server 2005.
Новые способы хранения данных
В SQL Server 2005 все еще требуется хранить обычные строки для данных и индексов. Но в SQL Server 2005 появился новый тип данных varchar(max), который позволяет вам задать столбец, в котором будут содержаться и данные обычной строки, и LOBданные. Кроме того, для индексов вы можете задать для столбца тип varchar(max), это означает, что индекс может содержать LOBданные.
Еще один новый механизм позволяет вам задавать многочисленные большие varchar поля, но вместо использования MAX в качестве максимальной длины, вы можете указать целое число; для SQL Server 2000 максимальная длина 8000.Эта техника позволяет вам заполнять многочисленные большие varchar столбцы в строке, когда общая длина строки превышает максимальную длину, которую SQL Server может хранить на странице. SQL Server просто хранит любые varchar поля, которые не подходят строке, в специальных страницах, которые называются ROW_OVERFLOWстраницы, о которых я немного рассказываю в статье «Систематизация разных типов фрагментации», опубликованной в номере журнала за август 2006 года. SQL Server также может хранить строки индексов на ROW_OVERFLOWстраницах.
SQL Server 2005 также позволяет разбивать таблицы или индексы на разделы (partition) и хранить их строки в разных местах. В sysindexes нет возможности показать, что одна структура размещается в нескольких областях хранения.
Таким образом, в SQL Server 2005 вместо использования индексов как вспомогательной структуры хранения для таблиц, таблицы и индексы находятся на одном уровне. И таблицам и индексам необходимо хранить регулярные строки, LOBданные и ROW_OVERFLOWданные. И индексы и таблицы могут быть разбиты на разделы.
Перемещение системных баз данных SQL 2005
DOWNLOAD
Обычная установка Microsoft SQL 2005 заканчивается захоронением системных баз данных с глубиной вложения равной пяти в директории C:\Program Files. Большинство системных администраторов баз данных предпочитают, чтобы системные базы данных не находились на одном диске с остальными рабочими. Но перенос системных баз данных, включая master и новую скрытую базу mssqlsystemresource является делом нетривиальным и даже пугающим. Проделав эту операцию несколько раз вручную, я написал сценарий для выполнения этой задачи.
Системные базы данных
К системным базам данных, согласно Microsoft (System Databases), относятся:
• Master — содержит описание других баз данных, логины и систему таблиц только для master;
• Model — снимок новых создаваемых баз данных;
• Msdb — содержит код и данные для SQL Server Agent и SQL Server Management Studio;
• Tempdb — здесь создаются временные таблицы (локальные и глобальные) и выделяется место для внутренних сортировок при выполнении запросов;
• Mssqlresourcedb — внутренняя, скрытая, доступная только для чтения база данных, содержащая системные объекты.
В зависимости от вашей конфигурации сюда могут быть включены другие базы, такие как distribution. В это статье я рассматриваю только эти пять баз данных.
Почему вам может понадобится перемещать эти базы данных? Причин может быть несколько. Лично мне не нравится идея работы с важными базами данных гдето в глубинах директории Program Files. Я предпочитаю знать, что все мои базы легко найти в структуре каталогов. Еще более важным является тот факт, что хранилище баз данных обычно находится на RAID массиве или в сети устройств хранения данных отдельно от загрузочного диска C:. Почему бы не обеспечить этим дискам работу с ними и защиту, соответствующую содержащимся на них критически важным системным данным? Если вы теряете ваш загрузочный диск, вы можете переустановить ОС и SQL, и после указания точного расположения быстро восстановить данные без потерь.
(Возврат на основную страницу)