Содержание номера за Апрель 2012 год

SQL Server

Февраль 2012 № 4 (22)

Использование табличных переменных для журналирования работы внутри транзакций
Аниш Соман (Aneesh Soman)
Замена системной процедуры sp_spaceused
Джейсон С Вонг (Jason S Wong )
Генерация команд MERGE по данным таблицы
Даниэль Нолан (Daniel Nolan )
Какой смысл использовать тип VARCHAR(n) в настоящее время?
Роб Гаррисон (Rob Garrison)
Работа с типом данных XML в SQL Server
Роберт Шелдон (Robert Sheldon)
Нешуточные споры вокруг SQL Server: Коэффициент обращений к буферному кэшу
Джонатан Кехайяс (Jonathan Kehayias)

Использование табличных переменных для журналирования работы внутри транзакций
Аниш Соман (Aneesh Soman)

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

Замена системной процедуры sp_spaceused
Джейсон С Вонг (Jason S Wong )

В документации описана системная хранимая процедура sp_spaceused

Если в процедуру передано в качестве параметра имя объекта, она возвращает следующую информацию.
Имя столбца - name
Тип данных - nvarchar(128)
Описание - Имя объекта, для которого были запрошены сведения об используемом пространстве.

Имя схемы объекта не возвращается. Если требуется имя схемы, для получения эквивалентных сведений о размере используется динамическое административное представление sys.dm_db_partition_stats или sys.dm_db_index_physical_stats.

Это странно, если немного поисследовать, то быстро находится функция PARSENAME, которая возвращает имя схемы. Причина, по которой мне необходимо знать имя схемы - я создаю код автоматического обследования размеров, занятых объектами для текущего экземпляра сервера без учета имени БД или таблицы. Как вам известно, S1.table - вовсе не то же самое, что S2.table.
В статье вы найдете код усовершенствованной процедуры.

Генерация команд MERGE по данным таблицы
Даниэль Нолан (Daniel Nolan )

Введение
Предлагаемая хранимая процедура выполняет генерацию команд MERGE для указанной таблицы. Создаваемая команда MERGE использует многострочный вариант предложения VALUES.

Как это работает?
Создаваемая команда MERGE пополняет целевую таблицу для приведения ее данных в соответствие с исходной. Если какая-то запись отсутствует в исходной таблице, она удаляется из целевой.

При выполнении созданной команды MERGE выполняется следующая логика (в зависимости от того, найдено ли соответствие):
• Если исходная запись не существует в целевой таблице, выполняется команда INSERT
• Если в целевой таблице запись присутствует, но отсутствует в исходной, выполняется команда DELETE
• Если исходная запись уже имеется в целевой таблице, но отличается от исходной, выполняется команда UPDATE
• Если запись присутствует в целевой и исходной таблицах и не отличаются, никаких операций не выполняется (поведение конфигурируется)

Какой смысл использовать тип VARCHAR(n) в настоящее время?
Роб Гаррисон (Rob Garrison)

Появившиеся в версии SQL Server 2005 типы данных больших значений (MAX) оказались одной из тех возможностей, которые пользуются наибольшей популярностью у разработчиков баз данных. В то время широко обсуждался вопрос о том, существует ли какая-то плата за такую свободу от обязательного указания длины строк. Роб пытается дать окончательный ответ о том, есть ли у этой возможности какие-то недостатки.
Если вы обеспечиваете хранение длинных строк, или данных любых других типов, которые хотелось бы хранить как данные типа VARCHAR или VARBINARY, есть факторы, влияющие на то, как и где эти данные хранятся внутри SQL Server. Что в свою очередь будет влиять на производительность операций вставки и обновления.

Работа с типом данных XML в SQL Server
Роберт Шелдон (Robert Sheldon)

Тип данных XML, появившийся в версии SQL Server 2005, является мощным конструктивным элементом. Если пользоваться им с умом, он может обеспечить полезные расширения для сервера SQL Server. В этой первой части серии публикаций Роберт Шелдон описывает, как можно создать и проиндексировать XML-столбец в таблице, а также рассматривает вопрос о том, когда следует подумать об использовании типа данных XML.
Не все типы данных сервера SQL Server созданы равными. Только посмотрите на тип данных XML. Внешне, могло бы показаться, что это вполне обычный тип, за исключением, конечно, его приспособленности для работы с XML-данными; но способы его использования, то, как запрашиваются данные этого типа, а также, когда и как следует индексировать XML-столбцы, быстро отделяют этот тип от остальной компании. И именно эти отличия важны при работе в расширяемом мире XML-данных.
По сути дела, тип данных XML лежит в основе понимания того, как хранятся и запрашиваются XML-данные в базе данных SQL Server. Отсюда не следует, что все XML-данные должны храниться как данные типа XML, но знание того, как работает этот тип, поможет определить, когда его следует использовать и как обеспечить эффективный доступ к данным этого типа.
В ряде случаев следует использовать не тип данных XML, но типы, предназначенные для хранения больших объектов, – VARCHAR(MAX), NVARCHAR(MAX) или VARBINARY(MAX). Например, если вы просто храните в базе данных свои XML-документы, которые извлекаются и обновляются как одно целое, – то есть, если вам никогда не требуется запрашивать или модифицировать отдельные XML-компоненты, – следует подумать об использовании одного из типов, предназначенных для хранения больших объектов данных. То же самое распространяется на XML-файлы, которые вы хотите хранить в их исходном виде, например, юридические документы. Если необходимо хранить точную текстуальную копию, используйте механизм хранения больших объектов.
Но во всех остальных случаях следует подумать об использовании типа данных XML. Этот тип гарантирует правильность формата данных в соответствии со стандартами ISO и поддерживает выполнение узкоцелевых (fine-grained) запросов, а также модификацию конкретных элементов и атрибутов внутри XML-данных. Можно также создать индекс на столбце типа XML и связать хранящиеся в этом столбце данные с коллекцией XML-схем, чтобы сохранить их содержимое и структуру. Кроме того, тип данных XML позволяет хранить данные, структура которых слишком изменчива и сложна, чтобы ее можно было легко вписать в реляционную модель.
Однако, рассматривая возможность использования типа данных XML, следует также знать об ограничениях этого типа. Например, XML-столбец нельзя использовать в качестве ключа в индексе, а размер значения данных, хранящегося в таком столбце, не может превышать 2 Гб. Кроме того, данные, для которых используется тип XML, нельзя сравнивать или сортировать, и также их нельзя использовать в предложении GROUP BY. Полное описание ограничений типа данных XML, а также другие подробности относительно работы с XML-данными ищите в разделе «Implementing XML in SQL Server» в документации «SQL Server Books Online».

Нешуточные споры вокруг SQL Server: Коэффициент обращений к буферному кэшу
Джонатан Кехайяс (Jonathan Kehayias)

Один из наиболее популярных счетчиков, которые администраторы БД используют для мониторинга производительности сервера SQL Server, коэффициент обращений к буферному кэшу (Buffer Cache Hit Ratio, BCHR), бесполезен в роли предсказателя надвигающихся проблем с производительностью. Хуже того, он может вводить в заблуждение. Джонатан Кехайяс убедительно демонстрирует это с помощью нескольких простых тестов.
Много лет тому назад, когда я впервые стал работать с SQL Server, было несколько счетчиков производительности, которые находились в поле зрения всех сознательных администраторов БД и использовались ими для того, чтобы следить за производительностью сервера SQL Server и оценивать его общее состояние. Одним из них был счетчик SQLServer:Buffer Manager\Buffer Cache Hit Ratio, который так описан в разделе SQL Server:Buffer Manager Object в документации Books Online:
"Percentage of pages found in the buffer cache without having to read from disk. The ratio is the total number of cache hits divided by the total number of cache lookups over the last few thousand page accesses. After a long period of time, the ratio moves very little. Because reading from the cache is much less expensive than reading from disk, you want this ratio to be high. Generally, you can increase the buffer cache hit ratio by increasing the amount of memory available to SQL Server."
Обычно, это определение интерпретируют так: если значение счетчика Buffer Cache Hit Ratio (BCHR) является «высоким», значит, SQL Server эффективно кэширует страницы данных в памяти, считывания с диска сравнительно редки и потому память не является узким местом. И наоборот, если значение счетчика BCHR является «низким», это – верный знак, что SQL Server испытывает нехватку памяти и выполняет массу физических операций считывания для извлечения затребованных данных. Господствовали здравые мнения, что «низкое» – это значение, не превышающее 95% для OLTP-систем или 90% для систем OLAP или хранилищ данных (data warehouse).
Эта статья, надеюсь, убедит вас в том, что такая интерпретация значения счетчика BCHR является совершенно неправильной и очень обманчивой. Фактически, я докажу, что для SQL Server вполне возможна ситуация, когда, испытывая существенную нехватку памяти, он вместе с тем демонстрирует BCHR-значение, которое, если взять его в отдельности, заставляло бы администратора БД сделать вывод, что сервер находится в хорошем состоянии. В то же время я продемонстрирую, что есть счетчики, которые позволяют гораздо лучше отслеживать особенности использования памяти на SQL Server и диагностировать потенциальные проблемы с памятью.
Счетчик BCHR – это такой счетчик производительности, который я, будучи консультантом, никогда не использовал в своей работе, а перестал я им пользоваться, как только точно выяснил, почему его значение может быть таким обманчивым, и насколько обманчивыми были господствующие представления о его значении.

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