(Возврат на основную страницу)
Пример рекурсивного CTE
Нейл Брайан (Neil Bryan)
Сортировка букв в предложении средствами T-SQL
Саеди Хасани (Saeid Hasani)
Автоматизация проверки данных на чистоту
Ричард Фрайр (Richard Fryar)
Монитор долго исполняющихся заданий
Грегори Фердинандсен (Gregory Ferdinandsen)
Заполнение данными реплицированной таблицы с вертикальной фильтрацией
Джейсон Банн (Jason Bunn)
Пример рекурсивного CTE
Нейл Брайан (Neil Bryan)
Идея этого сценария- демонстрация возможностей рекурсивных CTE (common table
expression) для получения иерархических данных. Приведенный пример использует
таблицу с перечнем сотрудников, в которой каждая запись имеет ссылку на запись
менеджера в той же таблице. Использование этой техники гораздо более эффективно,
чем использование курсоров. В коде создается табличная переменная для хранения
данных.
Сортировка букв в предложении средствами T-SQL
Саеди Хасани (Saeid Hasani)
Описание проблемы
Предлагаемый код появился, когда я прочитал сообщение на форуме MSDN. Автор
сообщения спрашивал, как можно отсортировать буквы в предложении только
средствами T-SQL? Например, если в слове CHICAGO после сортировки нужно получить
ACCGHIO.
Введение
Так как SQL - декларативный язык, он не манипулирует массивами (array). Таблица
- это набор, не имеющий упорядоченности. Но если нам нужно выполнить сортировку
и сравнение, как подойти к решению такой проблемы?
Решение
Используя T-SQL, мы можем применить дополнительные возможности, которыми
обладает этот язык. Первая проблема - назначение каждой букве предложения
собственного индекса.
Одним из решений является использование таблицы spt_values.
Автоматизация проверки данных на чистоту
Ричард Фрайр (Richard Fryar)
Некоторое время назад я написал статью
www.sqlcopilot.com/dbcc-checkdb-with-data_purity.html о настройке DATA_PURITY,
которую можно использовать при запуске DBCC CHECKDB и как можно определить поля,
в которых обнаружились сбои.
(Из документации) DATA_PURITY - Указание значения аргумента приводит к
выполнению инструкцией DBCC CHECKDB проверки базы данных на недействительность
или выход из допустимого диапазона значений столбцов. Например, инструкция DBCC
CHECKDB будет обнаруживать столбцы со значениями даты и времени, выходящими за
допустимый диапазон значений типа данных datetime; или столбцы типа данных
decimal или приблизительных числовых типов данных с недопустимыми значениями
масштаба или точности. http://technet.microsoft.com/ru-ru/library/ms176064.aspx
Один из способов поиска - запуск команды SELECT с предложением WHERE для
возврата данных, не соответствующих объявленному типу. Но это не всегда
работает. Данные могут находится в рамках диапазона, определенного типом, но
проверку на чистоту не выдерживают. Кроме того, возможно, что данные в поле
совершенно не годятся и при попытке выполнить выбору возвращается ошибка
арифметического переполнения.
В своей статье я показывал как можно найти данные средствами DBCC PAGE. Это если
выборка не работает. Но если таких данных много, такой подход оказывается очень
трудоемким. Недавно я мигрировал базу данных из SQL Server 2000 в среду 2008 R2,
исполнение CHECKDB показало наличие 540,000 ошибок чистоты данных!
Монитор долго исполняющихся заданий
Грегори Фердинандсен (Gregory Ferdinandsen)
Этот скрипт следует выполнять в виде задания SQL Server на постоянной основе (я
запускаю его ежечасно). Сценарий будет контролировать работу и предупреждать о
тех заданиях, которые выполняются дольше заданного порогового значения (по
умолчанию - 24 часа).
По умолчанию, я исключил два задания среды Management Datawarehouse, которые
начинают работу после старта сервера /MDW начинает собирать данные. Вы можете
исключить до 5 других заданий, про которые вы знаете, что их длительность
исполнения превышает порог.
Заполнение данными реплицированной таблицы с вертикальной
фильтрацией
Джейсон Банн (Jason Bunn)
Введение
Если в репликации транзакции таблица фильтруется по вертикали, и в статью
добавляется новый столбец, у подписчика может появиться зафиксированная
транзакция, обновляющая этот новый столбец, даже если тот еще не был
реплицирован, когда транзакция уже была зафиксирована. В этой статье я буду
рассматривать механизм такого функционального поведения и предоставлю один
обходной маневр с использованием трассировочных маркеров репликации.
Как правило, когда вертикальное секционирование используется для того, чтобы
реплицировать лишь несколько столбцов таблицы, в том случае, если в статью
таблицы необходимо добавить столбец, «включается» (turned on) параметр
репликации replicate_ddl. Однако, этот параметр может оставаться «выключенным»
(turned off), если, например, таблица публикации велика, а вам надо добавить в
нее несколько столбцов, – какие-то из них будут реплицированы, какие-то не
будут, – и сделать это вы хотите с помощью одной команды. В таком случае можно
было бы добавить столбцы у издателя, настроить все значения по умолчанию, а
потом добавить соответствующие столбцы у подписчика, используя для них свои
значения по умолчанию. В итоге, вы добавляете столбец в саму публикацию, и
изменения в новых данных успешно реплицируются подписчику.
Однако, если обновление значений по умолчанию требует некоторого времени,
затрачиваемого на прочтение обновления распространителем, и если соответствующий
журнал транзакций у издателя имеет большой размер, встречаются сценарии, в
которых такое большое количество команд у издателя можно реплицировать
подписчику, даже если обновление было зафиксировано до того, как столбец(ы)
был(и) добавлен(ы) в репликацию.