(Возврат на основную страницу)
Применение типа данных XML в SQL Server 2005
В SQL Server 2005 XML становится первоклассным типом данных. Разработчики могут с легкостью вносить в хранящиеся документы XML незначительные изменения удаленно, используя новые преимущества поддержки типизации, основанной на схемах XML, и проверки XML данных на стороне сервера.
Многим разработчикам баз данных приходилось погружать свои стопы в широкий океан XML.
Хорошей новостью станет то, что в SQL Server 2005 вы можете хранить XML в базе данных в новом типе XML. Однако разработчики делали это и прежде. Даже без внутренней поддержки XML они заносили документы XML в текстовые поля со времени его изобретения.
SQL Server 2000 включал в себя некоторые готовые возможности по работе с XML. Ключевой из них была возможность возвращать результаты в виде XML при помощи предиката FOR XML. Функциональность SQL Server 2005 значительно отличается. Здесь XML является встроенным типом данных, следовательно, вы можете использовать его как поле в таблицах и представлениях, в выражениях TSQL или в качестве параметров хранимых процедур. Вы можете теперь хранить, запрашивать документы XML и работать с ними прямо в базе данных.
Что еще более важно, вы можете также указать схему, к которой будет относиться наш XML. Кроме предоставления механизма для проверки XML в базе данных, это также позволяет вам описывать сложные типы хранимых данных и вводит механизм для обеспечения этих правил.
Простота веб-служб с SQL Server 2005 HTTP Endpoints
Конечные точки HTTP/SOAP в SQL Server 2005 предоставляют разработчикам под SQL Server новые возможности для использования веб-служб внутри SQL Server. Стоит сказать об этом, несмотря на то что веб-службы для SQL Server 2005 не являются новинкой. В SQL Server 2000 SQLXML предоставлял набор дополнительных инструментов, которые расширяли существующую поддержку получения и хранения данных XML. SQLXML 3.0 поддерживал шаблоны и веб-службы, которые позволяли выполнять хранимые процедуры, пользовательские функции. Однако одним из изменений в SQLXML стал комплексный процесс развертывания, который требовал IIS для работы с запросами HTTP и разрешения вызова веб-служб.
В SQL Server 2005 возможность использования конечных точек HTTP/SOAP позволяет вам применять вебслужбы, связанные с объектами в SQL Server. В отличие от более ранних версий IIS больше не требуется. Процесс режима ядра Windows Server 2003, HTTP.sys, позволяет SQL Server слушать запросы HTTP и обрабатывать их напрямую. Это упрощает разработку и развертывание приложений, требует меньшего количества инфраструктурных компонентов, поскольку установка IIS на основном экземпляре SQL Server — это не лучшая практика. Из статьи вы узнаете, что требуется для создания и открытия конечных точек HTTP/SOAP для использования в вашем приложении. Будут сделаны выводы, которые помогут вам выяснить, когда данная технология подходит, а когда ее лучше избегать.
SQL Server 2005: построение модели безопасности на триггерах DDL
В прошлом месяце я пытался создать для заказчика нечто вроде нестандартной модели безопасности. Ему требовались следующие функции:
• управление на уровне сервера только для системных администраторов;
• управление на уровне БД только для dbo (в каждой базе данных это могут быть один или несколько человек), отвечающего за управление пользователями на уровне БД, модификацию схемы БД, но не имеющего прав на изменение самой БД (ALTER DATABASE);
• dbo и любые другие пользователи уровня БД не должны иметь права создавать резервную копию базы данных (или копию журнала транзакций). Это важно, так как резервное копирование выполняется средствами ПО Veritas и незапланированное резервирование иными средствами может затормозить процесс восстановления (recovery) БД;
• защита от dbo, пожелавшего назначить себе права уровня sa.
SQL в вопросах и ответах
Архивация данных, связанные серверы, измерение пропускной способности и не только…
Скрипт поддержки Relog
Я годами перерабатывал (relog.exe) папки файлов счетчиков perfmon, используя старый запылившийся скрипт, когда проводил мероприятия по настройке производительности. Сегодня я подумал, что пора его улучшить.
Когда вы занимаетесь настройкой производительности SQL Server, требуется решить, какие данные и в каком количестве вы хотите собрать. Если данных недостаточно или они неверны, то в какойто момент на пути к цели вам может потребоваться повторить упражнение. Поэтому я обычно советую собрать большее количество счетчиков производительности, чем вы предполагали изначально, однако с ними трудно обходиться, если у вас нет под рукой подходящих скриптов для выделения данных, которые понадобятся позже при проведении анализа.
Разбор csvскриптов perfmon иногда мудрен, поскольку многие текстовые редакторы имеют ограниченные возможности, и даже инструменты вроде DTS порой бывают слишком капризными.
Временами я использую скрипт, который применяет RELOG.EXE из Windows для автоматизации процесса отделения счетчика perfmon от целой папки csvфайлов журнала perfmon. Например, я часто настраиваю журнал perfmon для сбора всех счетчиков дисков Physical / Logical, затем выделяю некоторые из них (например, Avg Read Queue Length или Disk % Idle Time) для дисков или разделов при помощи данного скрипта, чтобы сосредоточиться на определенных проблемах (например, запросы ввода/вывода для раздела TempDB TLOG или Data).
Еще немного тренировки — и вы сможете расширить автоматизицию, создав плановое задание SQL Agent для опроса папки, где хранятся счетчики perfmon, и обновления базы счетчиков производительности. Если вы чрезвычайно ловки, можете даже оформить данные в виде графика Reporting Services и опубликовать его в локальной сети. Удачи!