• Список выбора инструкции SELECT (вложенный или внешний запрос).


• Предложение COMPUTE или COMPUTE BY.


• Предложение HAVING.

• AVG


• CHECKSUM_AGG


• COUNT


• COUNT_BIG


• GROUPING


• MAX


• MIN


• SUM


• STDEV


• STDEVP


• VAR


• VARP

Совсем недавно в общем доступе появился SQL Server 2011 Denali CTP (Community Technology Preview) 3. Пора подводить небольшие итоги, т.к. релиз уже не за горами. О том, что нового нас ждёт, уже сейчас можно найти, в том числе и на просторах Рунета.
В CTP 3 появились 14 новых функций и 1 была изменена, именно о них я хочу рассказать.

[Ещё]

SQL_post_29x21_2010_PerfmonFinal.pdf (265,49 kb)

Рано или поздно, но у многих возникает вопрос, как определить список дисков, их общий объём и объём свободного пространства на них, при этом используя t-sql. На первый взгляд кажется, что задача должна решаться на раз, два, три. Но не все так просто.

Для решения этой задачи можно использовать несколько сценариев. Во первых хотелось бы вспомнить о недокументированной хранимой процедуре xp_fixedrives. Это очень полезная расширенная хранимая процедура, которая возвращает список всех установленных жестких дисков и размер в МБ свободного пространства для каждого жесткого диска.

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

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

Восстановления базы из Backup`a или перенос её на другой сервер, "сбраcывает" значение "даты создания" этой базы данных (в таблицах sys.databases, msdb..backupset и т.д.).

Встаёт вопрос: как найти оригинальную дату создания!?
Гарантированный способ - это чтение данных из boot-страниц, а именно страница №9, с помощью команды DBCC PAGE.

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

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

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

[Ещё]