SQL_post_29x21_2010_PerfmonFinal.pdf (265,49 kb)

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

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

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

Транзакции указывают уровень изоляции, который определяет степень, до которой одна транзакция должна быть изолирована от изменений ресурса или данных, произведенных другими транзакциями. Уровни изоляции описаны с точки зрения того, какие из побочных эффектов параллелизма разрешены (например, «грязные» чтения или фантомные чтения).
Более подробно о всех уровянх изоляции можно прочитать в любой книге по 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