Минимальное протоколирование. Индексы.

by Alexey Knyazev 30. сентября 2012 00:23
Минимальное протоколирование — это протоколирование только информации, необходимой для восстановления транзакции без поддержки восстановления на момент времени.
Эта особенность может быть очень полезна, когда необходимо сократить время на выполнение некоторых операций. Сегодня я хочу поговорить о минимальном протоколировании некоторых DDL-операции с индексом.

Минимально протоколируются следующие операции с индексами:
  • Операции CREATE INDEX (включая индексированные представления)
  • Операции ALTER INDEX REBUILD или DBCC DBREINDEX
  • Перестроение новой кучи DROP INDEX (если применимо)
[Ещё]

Tags: , , , , ,

SQL Server

READPAST и эскалация блокировок

by Alexey Knyazev 5. июня 2012 02:45
Сегодня я хочу поговорить о табличной подсказке READPAST, которая появилась впервые в SQL Server 2005. Эта подсказка указывает, что компонент Database Engine не считывает строки и страницы, заблокированные другими транзакциями. Если указан аргумент READPAST, то блокировки уровня строк будут пропускаться. Компонент Database Engine будет пропускать строки вместо блокировки текущей транзакции до тех пор, пока блокировки не будут сняты.

Например, предположим, что в таблице T1 есть один целочисленный столбец со значениями 1, 2, 3, 4, 5. Если транзакция A изменит значение 3 на 8, но еще не будет зафиксирована, то инструкция SELECT * FROM T1 (READPAST) возвратит значения 1, 2, 4, 5. Параметр READPAST главным образом используется для устранения конфликта блокировок при реализации рабочей очереди, использующей таблицу SQL Server. Средство чтения очереди, использующее аргумент READPAST, пропускает прошлые записи очереди, заблокированные другими транзакциями, до следующей доступной записи очереди, не дожидаясь, пока другие транзакции снимут свои блокировки.

Аргумент READPAST можно задать для любой таблицы, к которой обращается инструкция UPDATE или DELETE, и к любой таблице, на которую ссылается предложение FROM. Если аргумент READPAST задан в инструкции UPDATE, он применяется только при считывании данных для идентификации подлежащих обновлению записей вне зависимости от того, где он указан в инструкции. Аргумент READPAST для таблиц из предложения INTO инструкции INSERT задать нельзя. Операции чтения, в которых используется аргумент READPAST, не блокируются. Операции обновления или удаления, использующие аргумент READPAST, могут блокироваться либо при считывании внешних ключей или индексированных представлений, либо при изменении вторичных индексов.

Аргумент READPAST можно указывать только в транзакциях, выполняемых на уровнях изоляции READ COMMITTED или REPEATABLE READ. При указании подсказки READPAST в транзакциях, выполняемых с уровнем изоляции SNAPSHOT, она должна использоваться в сочетании с другими табличными подсказками, требующими блокировки, например UPDLOCK или HOLDLOCK.

Табличная подсказка READPAST не может быть указана, если параметр базы данных READ_COMMITTED_SNAPSHOT установлен в ON и выполняется одно из следующих условий.
  • Уровень изоляции транзакций сеанса имеет значение READ COMMITTED.
  • В запросе также указана табличная подсказка READCOMMITTED.
Чтобы в этих случаях указать подсказку READPAST, удалите табличную подсказку READCOMMITTED (если существует) и включите в запрос табличную подсказку READCOMMITTEDLOCK.


Всё, что написано выше является выдержкой из BOL, при этом хотелось бы особо подчеркнуть фразу, которую я выделил жирным:
Операции чтения, в которых используется аргумент READPAST, не блокируются.

Но так ли всё на самом деле? Или возможны исключения? Об этом чуть ниже.

[Ещё]

Tags: , , , ,

SQL Server

Секционирование и влияние RANGE RIGHT/LEFT на разбиение и слияние

by Alexey Knyazev 14. февраля 2012 22:20
Секционирование делает большие таблицы и индексы более управляемыми, так как позволяет быстро и эффективно получать доступ к поднаборам данных и управлять ими, при этом сохраняя целостность всей коллекции. При использовании секционирования такие операции, как загрузка данных из системы OLTP в систему OLAP, занимают всего несколько секунд вместо минут и часов, затрачивавшихся на это в предыдущих версиях SQL Server. Операции обслуживания, выполняемые на поднаборах данных, также выполняются значительно эффективнее, так как нацелены только на те данные, которые действительно необходимы, а не на всю таблицу.
В SQL Server все таблицы и индексы в базе данных считаются секционированными, даже если они состоят всего лишь из одной секции. Фактически, секции представляют собой базовую организационную единицу в физической архитектуре таблиц и индексов. Это означает, что логическая и физическая архитектура таблиц и индексов, включающая несколько секций, полностью отражает архитектуру таблиц и индексов, состоящих из одной секции. Дополнительные сведения см. на MSDN.
При создании секционированной функции, мы указываем, к какой области интервала значений принадлежит аргумент boundary_value [ ,...n ] (к левой или правой). Сегодня я расcкажу, как выбор RANGE [ LEFT | RIGHT ] влияет на операции SPLIT/MERGE RANGE.
[Ещё]

Tags: , , , ,

SQL Server

Параметризованная процедура и гарантированный план запроса

by Alexey Knyazev 30. января 2012 00:07
- Процедура стала работать медленнее, чем обычно?
- Запрос выполняется быстро, а процедура, в которой подобный запрос, работает очень долго?
- У процедуры неоптимальный план запроса?

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

Тема не нова, но если вы это читаете, то моё время потрачено не зря.

[Ещё]

Tags: , , , , ,

SQL Server

Грязное чтение и несогласованные данные

by Alexey Knyazev 14. января 2012 23:48
В одной из предыдущих заметок в своём блоге я писал о ряде сюрпризов, к которым нужно быть готовым при использовании "грязного чтения" (уровень изоляции READ UNCOMMITTED) - http://www.t-sql.ru/post/nolock.aspx.

А именно:
  • "Фантомные" записи, которых нет в БД
  • Чтение не всех записей из таблицы
  • Чтение одной и той же записи несколько раз
Сегодня я покажу ещё один неприятный момент - это чтение промежуточного состояния изменяемой строки, т.е. при изменении записи в одной атомарной операции:
update MyTable 
set a = b
  , b = a
В другой транзакции с уровнем изоляции READ UNCOMMITTED можно прочитать запись, когда значение поля a уже равно b, а поле b ещё не изменено.
[Ещё]

Tags: , , , ,

SQL Server

Временные таблицы и проблемы, связанные с их использованием

by Alexey Knyazev 25. сентября 2011 00:32
Temp Table Прежде, чем я расскажу о проблемах с которыми вы можете столкнуться при использовании временных таблиц, немного теории.
Временные таблицы отличаются от постоянных только тем, что хранятся в базе данных tempdb и автоматически удаляются, когда необходимость в них отпадает.

Существует два вида временных таблиц: локальные и глобальные. Они отличаются друг от друга именами, видимостью и доступностью. Имена локальных временных таблиц начинаются с одного символа (#); они видны только текущему соединению пользователя и удаляются, когда пользователь отключается от экземпляра SQL Server. Имена глобальных таблиц начинаются с двух символов номера (##); они видны любому пользователю и удаляются, когда все пользователи, которые на них ссылаются, отключаются от экземпляра SQL Server.

Например, если создать таблицу employees, она будет доступна любому пользователю, которому предоставлены разрешения на ее использование до тех пор, пока не будет удалена. Если во время сеанса базы данных создается локальная временная таблица #employees, с ней сможет работать только данный сеанс. Таблица будет удалена при завершении сеанса. Если создать глобальную временную таблицу ##employees, с ней сможет работать любой пользователь базы данных. Если другие пользователи не будут работать с этой таблицей, она будет удалена после отключения от нее. Если другой пользователь обратится к созданной таблице, SQL Server удалит ее, когда произойдет отключение и другие сеансы перестанут активно к ней обращаться.

[Ещё]

Tags: , , , , ,

SQL Server

Скрипт для переноса пользовательских сообщений

by Alexey Knyazev 18. февраля 2011 00:48

Пользовательские сообщения, как и системные, хранятся в системном представлении sys.messages (master..sysmessages для более ранних версий). Сообщения с идентификаторами, меньшими 50000, являются системными.
Для переноса пользовательских сообщения, написал скрипт, который динамически генерит скрипт для создания этих самых сообщений. Код работает, как для SQL Server 2000, так и выше:


... [Ещё]

Tags: , , , ,

SQL Server

Уровни изоляции и несогласованность данных

by Alexey Knyazev 17. февраля 2011 00:31

Транзакции указывают уровень изоляции, который определяет степень, до которой одна транзакция должна быть изолирована от изменений ресурса или данных, произведенных другими транзакциями. Уровни изоляции описаны с точки зрения того, какие из побочных эффектов параллелизма разрешены (например, «грязные» чтения или фантомные чтения).
Более подробно о всех уровянх изоляции можно прочитать в любой книге по SQL Server и на сайте Майкрософт - http://msdn.microsoft.com/ru-ru/library/ms189122.aspx


А в этой статье хочу поговорить об уровне изоляции READ UNCOMMITTED ( = подсказке NOLOCK ) и несогласованности данных, а так же о чудесах сиквела при уровне изоляции READ COMMITTED (уровень изоляции по умолчанию). [Ещё]

Tags: , , , ,

SQL Server

INSERT + ORDER BY

by Alexey Knyazev 26. января 2011 00:42

Order by


Существует очень раcпространенный миф, что конструкция insert into ... select ... from ... order by ... гарантирует последовательность вставки данных в таблицу согласно условию order by. Но это заблуждение, т.к. мы не можем гарантировать последовательность физической вставки данных. Сиквел сам (по своему, неведанному нам сценарию) определяет, как данные попадут в таблицу, последовательно или параллельно и какими кусками определяет оптимизатор. При этом кляуза (clause) просто игнорируется.
Но существует очень интересная особенность, когда в таблице, в которую осуществляется вставка, есть поле IDENTITY

[Ещё]

Tags: , , , , ,

SQL Server

Чудесный оператор CROSS APPLY

by Alexey Knyazev 22. декабря 2010 01:03

Сегодня я хочу рассказать более подробно об операторе APPLY, а конкретнее о его типе CROSS APPLY. Этот оператор появился впервые в SQL Server 2005, но к сожалению многие так и не научились им пользоваться, возможно это из-за того, что в BOL (SQL Server Books Online) этот оператор плохо описан и имеет очень "сухие" примеры его использования. В этой статье я покажу несколько интересных демонстраций, где этот оператор может пригодиться.

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

[Ещё]

Tags: , , ,

SQL Server