 TechNet Magazine March 2007
TechNet Magazine March 2007
MARCH 2007
SQL Server

НАСТРОЙКА SQL SERVER

Этот выпуск журнала TechNet Magazine посвящен SQL Server. Из него вы лучше узнаете о том, как настроить SQL Server самым лучшим образом. Вы научитесь создавать оптимальные указатели, чтобы SQL Server быстро выполнял запросы и предоставлял вам всю необходимую информацию.

Также вы увидите, как кластеризация SQL Server обеспечивает избыточность и минимизирует время простоев. Кроме этого, вы узнаете, что означает высокий уровень доступности для вашей среды, и как его добиться. И наконец, вы увидите, как можно раз и навсегда решить дилемму секционирования таблиц.

Администрирование Windows

И не забудьте, в этом месяце Марк Руссинович (Mark Russinovich) еще раз поделится своими знаниями о ядре Windows Vista.
СТАТЬИ
SQL Server Новые инструменты для диагностики состояния указателей

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

Рэнди Дайэсс (Randy Dyess) Как добиться высокого уровня доступности SQL Server

Приложение SQL Server 2005 обеспечивает ряд возможностей для повышения уровня доступности баз данных, от репликации до кластеризации и доставки журналов. В данной статье подробно рассматриваются различные возможности настройки сервера SQL Server и приводятся указания по выбору оптимальных для существующей среды вариантов.

Зак Нихтер (Zach Nichter) Упрощение обслуживания баз данных с помощью секционированных таблиц

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

Ноа Гомес (Noah Gomez) Советы по кластеризации серверов SQL Server

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

Том Моро (Tom Moreau) Администрирование Windows Внутреннее устройство ядра Windows Vista. Часть 2

В этом месяце мы продолжим детальное обсуждение новых возможностей ядра ОС Windows Vista. Мы рассмотрим некоторые усовершенствования в области управления памятью в ОС Windows Vista, а также познакомимся с особенностями запуска системы, завершения ее работы и управления электропитанием.

Марк Руссинович (Mark Russinovich)
РАЗДЕЛЫ
От редактора

Полка трофеев

Джошуа Трупин (Joshua Trupin) Инструментарий

Новые продукты для специалистов по информационным технологиям

Грэг Стин (Greg Steen) Обзор служебных программ

SyncToy

Джей Мунро (Jay Munro) SQL Q&A

Переход на летнее время, память сервера и многое другое

Под редакцией Нэнси Митчелл (Nancy Michell) Кабельщик

Протокол DHCPv6

Джозеф Дэвис (Joseph Davies) Windows Powershell

Возможности переменных

Дон Джонс (Don Jones) 		Эй, программист!

Отвечаем на ваши вопросы по OU...всего за 5 центов

Программисты корпорации Майкрософт Exchange Queue – Очередь за ответами

Журналы транзакций, командлеты, удаленное управление и многое другое

Кей Си Лемсон (KC Lemson) и Нино Билич (Nino Bilic) В поисках безопасности

Развертывание файловой системы EFS: Часть 2

Джон Морелло (John Morello) Файлы рабочего стола

PsTools Primer

Вес Миллер (Wes Miller) Внутри Microsoft.com

Знакомство с функцией зеркального отображения баз данных

Салим Хакани (Saleem Hakani) Заметки на полях

Доктор пришел!

Мэтт Хестер (Matt Hester) Конфиденциальная информация Windows

Интеллектуальный вид и простецкая сущность

Рэймонд Чен (Raymond Chen)


 SQL Server: Новые средства для проверки работоспособности индексов
SQL Server Рэнди Дайесс (Randy Dyess)

Новые средства для проверки работоспособности индексов
Краткий обзор:
  • Фрагментация индексов
  • Использование индексов
  • Активность операций индексов
Загрузить исходный код для этой статьи: DyessSQLIndex2007_03.exe (151KB)

Одну из первых строк в списке способов настройки производительности любого сервера SQL Server занимает оптимизация индексов базы данных. Способность оптимизатора запросов сервера SQL Server правильно использовать индексы при выполнении запроса зависит не только от создания эффективных индексов, но
и от того, насколько эти индексы работоспособны. Ряд динамических административных представлений (DMV) и функций (DMF), вошедших в состав SQL Server™ 2005, может помочь администраторам баз данных оценить эффективность своих индексов и определить проблемы с производительностью.
Эти представления и функции позволяют взглянуть на работу сервера изнутри и получить сведения о состоянии сервера, с помощью которых можно отслеживать работоспособность и производительность экземпляра сервера и определять проблемы. Администраторы баз данных, знакомые с предыдущими версиями SQL Server, обнаружат, что эти представления и функции заменяют использование команд DBCC, выполнение системных хранимых процедур, запросы данных многих системных таблиц, а также сбор событий с помощью приложения SQL Profiler.
Три основные функции и представления, а именно: sys.dm_db_index_physical_stats, sys.dm_db_index_usage_stats и sys.dm_db_index_operational_stats, позволяют понять, работают ли индексы так, как планировалось. С их помощью можно посмотреть, как ведут себя индексы в ходе операций ввода-вывода и при блокировках, а также определить, действительно ли оптимизатор запросов применяет индексы так, что это не приводит к ненужному состязанию в базе данных.

Фрагментация индексов
Функция DMF sys.dm_db_index_physical_stats предназначалась для замены команды DBCC SHOWCONTIG. Она показывает фрагментацию индекса. Однако, в отличие от команды DBCC SHOWCONTIG, которой требуется общая блокировка (S) таблицы, содержащей индекс, функция sys.dm_db_index_physical_stats устанавливает только намеренную общую блокировку (IS), что позволяет значительно уменьшить блокирование таблицы во время выполнения функции.
Чтобы определить уровень фрагментации индекса с помощью функции sys.dm_db_index_physical_stats, нужно изучить сочетание трех столбцов результатов выполнения функции. Логическую фрагментацию индексов (фрагментацию экстентов куч) можно определить по значению в столбце avg_fragmentation_in_percent. Логическая фрагментация £ это процент неупорядоченных страниц на конечном уровне индекса, а фрагментация экстентов £ это процент неупорядоченных экстентов на конечном уровне индекса. Фрагментация обоих указанных типов может влиять на производительность индекса, требуя дополнительных операций ввода-вывода и лишнего движения считывающей головки диска, поскольку головка, чтобы прочитать страницы по порядку, не может перемещаться последовательно. Нужно стараться, чтобы уровень как логической фрагментации, так и фрагментации экстентов был настолько близок к нулю, насколько это возможно.
Внутренняя фрагментация индекса £ это процент заполненности страниц. Конечно, хотелось бы, чтобы страница индекса была заполнена настолько, насколько возможно, но нужно еще и соблюдать баланс между заполненностью и числом вставок в страницы индекса, чтобы число разбиений страниц было минимальным.
Узнать заполненность страниц индекса можно с помощью аргумента avg_page_space_used_in_percent функции sys.dm_db_index_physical_stats. Чтобы правильно определить, насколько близко это число должно быть к 100 процентам, нужно настроить коэффициент заполнения индекса, одновременно наблюдая за числом происходящих разбиений страниц. Начиная с некоторого момента число разбиений страниц начнет расти очень быстро. Это означает, что для коэффициента заполнения индекса было задано слишком высокое значение. Настройка коэффициента заполнения индекса требует времени и тестирования, и выполняться она должна только после тщательного планирования. (Для индексов, в которые не выполняются случайные вставки, можно задать коэффициент заполнения равным 100 и не волноваться об увеличении числа разбиений страниц.)
Чтобы определить уровень фрагментации всех индексов таблицы AdventureWorks.HumanResources.Employee, можно воспользоваться примерно такой инструкцией:
SELECT *
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,OBJECT_ID('HumanResources.Employee')
,NULL
-- NULL to view all indexes;
-- otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') -- We want all information
С помощью данной функции DMF можно автоматически определить, какие индексы должны быть перестроены, какие нуждаются в реорганизации, а какие можно не трогать. Выявление значений столбцов avg_page_space_used_in_percent и avg_fragmentation_in_percent этой функции DMF (которые показывают фрагментацию индекса), превышающих некоторый логический порог и порог плотности, поможет определить, какие операции необходимо выполнить с этим индексом.
В зависимости от состояния индексов пример, показанный на рис. 1, может не возвращать данные в конкретной копии образца базы данных AdventureWorks, но его легко можно адаптировать к другим базам данных.
Figure 1 Определение заполненности страниц и фрагментации (Close Figure 1)
--Reorganize the following indexes in the AdventureWorks database
USE AdventureWorks
GO

SELECT OBJECT_NAME([object_id]) AS 'Table Name',
index_id AS 'Index ID'
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 10
AND avg_fragmentation_in_percent < 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 75
AND avg_page_space_used_in_percent > 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes

--Rebuild the following indexes in the AdventureWorks database
USE AdventureWorks
GO

SELECT OBJECT_NAME([object_id]) AS 'Table Name',
index_id AS 'Index ID'
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes
Результаты запросов можно было бы записать в табличную переменную, а затем просмотреть эту переменную, чтобы построить динамическую строку для правильной инструкции ALTER INDEX (см.рис. 2).
Figure 2 Создание динамической строки ALTER INDEX (Close Figure 2)
--Rebuild the following indexes in the AdventureWorks database
USE AdventureWorks
GO

--Table to hold results
DECLARE @tablevar TABLE(lngid INT IDENTITY(1,1), objectid INT,
index_id INT)

INSERT INTO @tablevar (objectid, index_id)
SELECT [object_id],index_id
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes

SELECT 'ALTER INDEX ' + ind.[name] + ' ON ' + sc.[name] + '.'
+ OBJECT_NAME(objectid) + ' REBUILD'
FROM @tablevar tv
INNER JOIN sys.indexes ind
ON tv.objectid = ind.[object_id]
AND tv.index_id = ind.index_id
INNER JOIN sys.objects ob
ON tv.objectid = ob.[object_id]
INNER JOIN sys.schemas sc
ON sc.schema_id = ob.schema_id

Использование индексов
Хотя функция sys.dm_db_index_physical_stats является мощной заменой команды DBCC SHOWCONTIG и может помочь оценить работоспособность индекса, на практике часто возникает более сложная задача: определить, какие индексы действительно используются при выполнении запросов данных таблицы. Часто разработчики или администраторы баз данных создают для таблицы индексы, которые, как они думают, оптимизатор запросов будет использовать при выполнении запроса. В предыдущих выпусках сервера SQL Server понять, используются ли на самом деле эти индексы, было значительно сложнее. Для этого нужно было либо удалить индекс и посмотреть, как это повлияет на производительность запросов, либо собрать планы выполнения запросов и изучить их на предмет использования индекса.
Новое динамическое административное представление, sys.dm_db_index_usage_stats, £ это более простой способ определить, как индексы используются оптимизатором запросов и запросами данных из таблицы. Достаточно изучить это представление, чтобы оценить полезность индексов, что позволит удалить те из них, которые оптимизатор запросов не использует. Теперь можно больше не волноваться о том, что индекс только зря занимает место или что обслуживание неиспользуемых индексов приводит к снижению производительности базы данных.
Изучив результаты этого представления DMV на предмет индексов с нулевым числом операций поиска и просмотра, можно определить, использовался ли индекс с момента последнего запуска сервера SQL Server. Впрочем, необходимо помнить, что результаты многих динамических административных представлений и функций не сохраняются и сбрасываются обратно в ноль после перезапуска сервера SQL Server. Не следует забывать об этом, применяя представление DMV или функцию DMF для оценки использования индекса. Возможно, индекс просто ни разу не понадобился с момента последнего перезапуска службы, но он потребуется для запросов при составлении недельных, месячных или квартальных отчетов.
Чтобы просмотреть все индексы, которые не использовались на данном сервере с момента последнего перезапуска службы сервера SQL Server, можно воспользоваться следующей инструкцией:
SELECT DB_NAME(database_id),OBJECT_NAME([object_id])
FROM sys.dm_db_index_usage_stats
WHERE user_seeks = 0
AND user_scans = 0
AND user_lookups = 0
AND system_seeks = 0
AND system_scans = 0
AND system_lookups = 0

Активность операций индексов
Для определения активности операций индексов очень полезной может оказаться функция DMF sys.dm_db_index_operational_stats. Ее можно использовать для просмотра активности операций ввода-вывода, блокировок, кратковременных блокировок и метода доступа для каждого индекса в базе данных. Такая информация помогает понять, как используются индексы, и отметить случаи блокировки индексов из-за высокой активности операций ввода-вывода или из-за существования в индексе проблемной области.
С помощью столбцов latch wait данной функции DMF можно определить, сколько времени требуется операциям READ и WRITE для получения доступа к ресурсам индекса. Это позволяет понять, соответствует ли дисковая подсистема, которая используется для хранения индекса, активности его операций ввода-вывода. Кроме того, если неудачная структура или неправильное использование индекса привели к появлению проблемной области, в которой высокая активность на одной или нескольких страницах индекса вызывает состязание для данных этих страниц, это тоже будет видно из полученных результатов. Такое состязание часто приводит к избыточному блокированию операций READ или WRITE для данной области.
На Рис. 3 показано, как определить шаблоны поведения блокировок и операций ввода-вывода для всех индексов таблицы AdventureWorks.HumanResources.Employee.
Figure 3 Определение шаблонов поведения блокировок и операций ввода-вывода (Close Figure 3)
SELECT page_latch_wait_count --page latch counts
,page_latch_wait_in_ms --page latch wait times
,row_lock_wait_in_ms --row lock wait times
,page_lock_wait_in_ms --page lock wait times
,row_lock_count --row lock counts
,page_lock_count --page lock counts
,page_io_latch_wait_count --I/O wait counts
,page_io_latch_wait_in_ms --I/O wait times
FROM sys.dm_db_index_operational_stats (DB_ID('AdventureWorks')
,OBJECT_ID('HumanResources.Employee')
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
)

Дополнительные сведения
Представления DMV и функции DMF, рассмотренные в этой статье, можно использовать не только так, как рассказывается здесь. На боковой панели «Дополнительные ресурсы» приведены ссылки на статьи электронной документации по SQL Server, которые описывают эти функции и представления и показывают, какой широкий спектр данных можно получить и изучить с их помощью.
Сведения о некоторых дополнительных имеющих отношение к индексам функциях DMF и представлениях DMV, которые не обсуждались в этой статье, можно найти в публикации группы оптимизации запросов сервера SQL Server по адресу: blogs.msdn.com/queryoptteam/570176.aspx.
Дополнительные ресурсы
  • sys.dm_db_index_physical_stats
  • sys.dm_db_index_usage_stats
  • sys.dm_db_index_operational_stats

Рэнди Дайесс (Randy Dyess) является преподавателем компании Solid Quality Learning, где он специализируется на системах OLTP сервера SQL Server. Рэнди £ автор многочисленных книг и статей, посвященных этому продукту. Он является основателем и ведущим автором веб-узлов www.TransactSQL.Com и www.Database-Security.Info.
© 2007 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.


 SQL Server: Как добиться высокого уровня доступности сервера SQL Server
SQL Server Зак Нихтер (Zach Nichter)

Как добиться высокого уровня доступности сервера SQL Server
Краткий обзор:
  • Зеркальное отображение
  • Моментальные снимки баз данных
  • Доставка журналов
  • Кластеризация
  • Репликация
Загрузить исходный код для этой статьи: NichterHA2007_03.exe (151KB)

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

долях секунды. Однажды я консультировал компанию, веб-серверы которой должны были успевать отправить SQL-запрос и получить на него ответ в течение нескольких миллисекунд. Если время отклика превышало указанную величину, база данных считалась недоступной, а веб-сервер пытался подключиться к следующему по списку серверу баз данных.
Поскольку пользователям требуются все более быстрые приложения, понимание того, как добиться высокого уровня доступности и небольшого времени отклика, поможет более грамотно планировать работу зависящих от данных приложений.
К счастью, приложение SQL Server™ 2005 обладает рядом возможностей, позволяющих повысить уровень доступности, включая репликацию и кластеризацию, а также зеркальное отображение баз данных, моментальные снимки баз данных и доставку журналов баз данных. Давайте рассмотрим эти возможности более подробно и попытаемся понять, как выбрать оптимальный для имеющейся среды вариант. Начнем с рис. 1, на котором показаны возможности повышения уровня доступности, предоставляемые приложением SQL Server 2005.
Figure 1 Возможности повышения уровня доступности (Close Figure 1)

Свойства технологии | Репликация | Зеркальное отображение баз данных | Кластеризация | Моментальные снимки баз данных | Доставка журналов
Возможность повышения уровня доступности |  |  |  |  |
Можно использовать при высокой интенсивности транзакций |  |  |  |  |
Данные доступны в режиме реального времени |  |  |  |  |
Образ данных доступен только для чтения |  |  |  |  |
Уникальная конфигурация оборудования |  |  |  |  |
Низкие затраты |  |  |  |  |
Обеспечение восстановления данных |  |  |  |  |
Автоматический переход на другой ресурс при сбое |  |  |  |  |
Потенциально сложные реализация и управление |  |  |  |  |
Возможное влияние на производительность |  |  |  |  |

Определение высокого уровня доступности
При планировании работы приложения с высоким уровнем доступности прежде всего необходимо определиться, что под этим понимается в данной конкретной среде. Для некоторых организаций высокий уровень доступности означает наличие избыточного оборудования, аналогичного рабочему, причем как данные, так и оборудование должны быть в работоспособном состоянии и доступны в течение не менее 99,995 процентов времени. Другим организациям может требоваться только высокий уровень доступности самих данных, а возможности переключения на другой ресурс при сбое уделяется меньше внимания. Чтобы выбрать правильное решение в конкретной ситуации, очень важно определиться, что именно подразумевается под высоким уровнем доступности.
Необходимо также понять, какие типы простоев могут возникать, и проанализировать, как они могут сказаться на соглашениях об условиях обслуживания (SLA). Простои, которые могут повлиять на уровень доступности, делятся на плановые, внеплановые и периоды пониженной производительности.
Обычно плановый простой £ это время, отведенное для запланированного обслуживания, о котором пользователи систем предупреждаются заранее. Внеплановый простой чаще всего является результатом отказа оборудования или сбоя программного обеспечения, из-за которого данные становятся недоступными. Период пониженной производительности тоже может служить причиной простоев и часто определяется по времени отклика для конечных пользователей, которое обычно заранее согласовывается предприятием и ИТ-организацией и включается в соглашение об условиях обслуживания того или иного вида.
Необходимо не только определить возможные причины простоев, но и оценить, насколько интенсивно используются данные, должны ли они всегда быть доступны или иногда допустимы периоды меньшей доступности либо недоступности данных. Нужно также решить, будут ли обеспечивающие повышение уровня доступности средства географически располагаться в том же месте или в удаленном месте. При принятии решения, вероятно, придется учитывать и ограничения бюджета. Давайте теперь рассмотрим каждую возможность повышения уровня доступности.

Зеркальное отображение баз данных
Прежде чем начать подробное рассмотрение зеркального отображения баз данных, необходимо определиться с терминологией.
Основной сервер £ рабочий сервер-источник, на котором размещается база данных, постоянно отправляющая свои журналы транзакций зеркальному серверу и его базе данных.
Зеркальный сервер £ сервер-получатель, на котором размещается резервная копия базы данных. Зеркальная копия постоянно синхронизируется с базой данных основного сервера.
Роль показывает, служит конкретный сервер основным или зеркальным.
Следящий сервер £ сервер, который наблюдает за работой основного и зеркального серверов и может запустить процесс автоматического перехода на другой ресурс при сбое.
Партнер £ основной или зеркальный сервер.
В обычной среде на основном сервере выполняется резервная копия базы данных основного сервера, которая затем восстанавливается на зеркальном сервере (см. рис. 2). После этого на основном сервере необходимо настроить зеркальное отображение: либо в окне свойств базы данных основного сервера в среде SQL Server Management Studio (SMSS), либо с помощью сценариев языка T-SQL.
Figure 2 Database mirroring architecture
Figure 2 Database mirroring architecture (Щелкните изображение, чтобы уменьшить его)
Figure 2 Database mirroring architecture
Figure 2 Database mirroring architecture (Щелкните изображение, чтобы увеличить его)
После того как зеркальное отображение настроено и сеанс зеркального отображения установлен, базы данных основного и зеркального серверов начинают синхронизироваться. База данных основного сервера отправляет свой журнал транзакций с записью событий, которые произошли после развертывания последней резервной копии базы данных на зеркальном сервере. Зеркальный сервер получает журнал и пытается как можно скорее применить его. При использовании приложения SQL Server 2005 Enterprise Edition этот процесс является многопоточным, в противном случае он представляет собой однопоточную операцию. После применения журналов на зеркальном сервере базы данных считаются синхронизированными и будут оставаться таковыми до разрыва сеанса зеркального отображения.
Когда клиенты выполняют новые транзакции, основной сервер проводит их в своей базе данных и при этом доставляет записи журнала транзакций своей базы данных в журнал повторяемых операций базы данных зеркального сервера или в очереди журналов, где они подхватываются и применяются к зеркальной базе данных. Как только транзакция выполнена и зафиксирована в базе данных зеркального сервера, основному серверу отправляется ответ, сообщающий о фиксации транзакции на зеркальном сервере. До получения подтверждения от зеркального сервера никакие новые транзакции, поступающие в систему, основным сервером не подтверждаются.
В случае сбоя зеркальный сервер может начать процедуру автоматического переключения ресурсов, причем следящий сервер поддерживает этот процесс, определяя, доступна ли база данных основного сервера. Если произошел сбой, необходимо устранить проблему на том сервере, который теперь является зеркальным партнером, прежде чем он снова сможет стать основным. Как только неполадки на зеркальном партнере устранены, начинается перемещение обратно на сервер зеркального партнера, и базы данных вновь синхронизируются. После завершения синхронизации сеанс зеркального отображения может быть вновь начат.
Описанный режим зеркального отображения является режимом высокого уровня безопасности, который обеспечивает синхронные транзакционные операции посредством включения транзакционной безопасности. Для этого режима не требуется следящий сервер, поскольку преимущества автоматического перехода на другой ресурс при сбое не используются. Все переходы на другой ресурс запускаются вручную. Существует и другой режим зеркального отображения, который обеспечивает выполнение синхронных транзакционных операций. Это режим высокого уровня доступности. Для него требуется не только включение транзакционной безопасности, но и использование для автоматического перехода на другой ресурс при сбое следящего сервера.
Третий, и последний, режим зеркального отображения £ это режим высокой производительности. В этом режиме транзакционная безопасность должна быть отключена, что позволяет обеспечить поддержку асинхронных операций. Последняя, в свою очередь, дает возможность основному партнеру фиксировать транзакции, не дожидаясь, пока запись транзакции будет внесена в базу данных зеркального сервера. Режим высокой производительности не требует наличия в конфигурации следящего сервера.
Обратите внимание, что при использовании зеркального отображения на основном и зеркальном серверах должен быть установлен одинаковый выпуск сервера SQL Server. Это не относится к следящему серверу, на котором может быть установлен выпуск SQL Server Express Edition. Кроме того, важно, чтобы база данных основного сервера находилась в режиме полного восстановления.
Технология ADO.NET 2.0 интегрирована в приложение SQL Server 2005 и включает возможность поддержки зеркального отображения баз данных и обеспечения для этого приложения прозрачного переключения при сбое на среду зеркального отображения. Это позволяет приложению ADO.NET автоматически переходить на другой ресурс, если подключение к базе данных основного сервера невозможно. Для этого не требуется дополнительной настройки или написания добавочного кода. Для настройки достаточно указать в строке подключения общего пользователя для обоих серверов и партнера по переходу на другой ресурс. Ниже приведен пример строки подключения ADO.NET, в которой указан партнер по переходу на другой ресурс для среды базы данных с зеркальным отображением:
"Provider=SQLNCLI.1;Data Source=MirrorDB;Failover Partner=SQL03;
 Initial Catalog=AdventureWorks;
Persist Security Info=True;User ID=TestUser; Password=TestPswd; Pooling=True;
Connect Timeout=5;Application Name=ADOMirrorTest"
Зеркальное отображение баз данных может оказаться удачным вариантом для компании, что зависит от требований, предъявляемых к приложениям и данным. Впрочем, чтобы добиться оптимальной производительности, необходимо принять во внимание несколько факторов. Например, насколько велики интенсивность транзакций системы или объем изменяемых данных? При принятии решения о зеркальном отображении баз данных очень важно определить, достаточно ли пропускной способности и скорости сети для передачи нужного объема данных и обработки имеющегося числа транзакций. Кроме того, необходимо учитывать повышенную нагрузку на подключение. Это особенно важно, если зеркальный сервер географически расположен в другом месте. При определении наличия налагаемых средой ограничений, которые могли бы помешать эффективной работе зеркального отображения, ключевую роль играет предварительное наблюдение за системой.
Зеркальное отображение баз данных может оказаться особенно удачным вариантом, если необходимо сократить издержки. Действительно, чтобы реализовать архитектуру зеркального отображения баз данных, не требуются ни общие диски, ни углубленные или специальные навыки. В отличие от кластеризации, для зеркального отображения баз данных не требуется, чтобы оборудование обоих партнеров было одинаковым. К тому же реализовать зеркальное отображение достаточно просто. Это делается с помощью мастера настройки, который можно найти на вкладке Mirroring (зеркальное отображение) окна свойств базы данных (см. рис. 3). Для получения дополнительных сведений я также рекомендую прочитать технический документ «Database Mirroring Best Practices and Performance Considerations» (Лучшие методы работы с зеркальными отображениями баз данных и вопросы производительности), расположенный по адресу go.microsoft.com/fwlink/?LinkId=80897 (на английском языке).
Figure 3 Mirroring setup wizard
Figure 3 Mirroring setup wizard (Щелкните изображение, чтобы уменьшить его)
Figure 3 Mirroring setup wizard
Figure 3 Mirroring setup wizard (Щелкните изображение, чтобы увеличить его)

Моментальные снимки баз данных
Моментальные снимки баз данных £ это новая технология, представленная в продукте SQL Server 2005 Enterprise Edition, но она не предназначена для повышения уровня доступности. Такие снимки должны использоваться в сочетании с другими технологиями в качестве варианта, предназначенного для восстановления баз данных или для создания надежных отчетов. Моментальный снимок £ это просто представление базы данных на конкретный момент времени, доступное только для чтения.
Его можно создать с помощью команды CREATE DATABASE, например:
CREATE DATABASE SnapDB_20061028_2030 ON
(NAME = SnapDB_Data, FILENAME =
    'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SnapDB_20061028_2030.snp')
AS SNAPSHOT OF SnapDB;
GO
При создании моментального снимка базы данных используются один или несколько так называемых разреженных файлов, а не файлы данных, которые применяются обычной базой данных. Эти разреженные файлы, в сущности, представляют собой места виртуального хранения, изначально не содержащие никаких данных. Они задействуются для хранения данных только при изменении или удалении последних в исходной базе данных. Данные записываются в разреженные файлы по одной странице данных за раз, и моментальный снимок реальной базы данных показывает только данные, которые были изменены с момента создания снимка. Остальные данные берутся со страниц данных исходной базы данных.
Для файлов моментального снимка базы данных выделяется пространство, соответствующее размеру базы данных на момент создания снимка. По размеру этих файлов нельзя определить, какой объем данных они реально содержат. Получить эту информацию можно с помощью инструкции языка T-SQL, например:
SELECT *
FROM fn_virtualfilestats(DB_ID(N'SnapDB_20061028_
    2030'), 1);
GO

В соответствии со способом хранения данных в разреженных файлах и в исходной базе при запросе моментального снимка базы данных страницы данных извлекаются как из файлов исходной базы данных, так и из разреженных файлов моментального снимка. Из-за потребности в общем доступе к страницам данных моментальные снимки могут существовать только на одном сервере с исходной базой данных, с которой они были сделаны. Поскольку такая архитектура не уменьшает числа операций ввода-вывода для исходной базы данных, в этом случае моментальные снимки не должны рассматриваться как вариант для составления отчетов, так как они не отражают реального состояния базы данных.
Теперь рассмотрим ситуацию, когда зеркальное отображение баз данных используется вместе с моментальными снимками. Это позволяет физически отделить базу данных отчетов, зеркальную базу данных и базу данных моментальных снимков от базы данных основного сервера. Подготовка моментальных снимков базы данных планируется с помощью агента SQL Server и пользовательского сценария. Это позволяет создавать обновленные снимки через регулярные интервалы времени. В примере сценария, приведенном на рис. 4, показана хранимая процедура, используемая для решения этой задачи. Она разработана для применения внутри задания и позволяет управлять созданием и удалением моментальных снимков конкретной базы данных в имеющейся среде. Таким способом можно было бы создать приемлемое решение для составления отчетов, поскольку данные отчетов были бы отделены от рабочих данных.
Figure 4 Хранимая процедура для создания моментальных снимков по расписанию (Close Figure 4)
use msdb;
GO
set nocount on
GO

CREATE PROCEDURE usp_snaprefresh
     @database    sysname = NULL    --name of the database to snapshot
    ,@keepsnap    int        = 24   --# of hours to keep a snapshot
                                    --after it was created
                                    --use a value of '0' to keep all
                                    --existing snapshots
    ,@fileloc    sysname            --location for snapshot
        = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\'
AS

DECLARE
     @dt            datetime        ,@cnt          int
    ,@databaseid    int             ,@snap         sysname
    ,@sql           nvarchar(1000)  ,@yy           varchar(4)
    ,@mm            varchar(2)      ,@dd           varchar(2)
    ,@h             varchar(2)      ,@m            varchar(2)
    ,@lname         sysname         ,@pname        sysname
    ,@file          sysname         ,@pos1         int
    ,@pos2          int

-- initialize variables
SELECT
     @dt = getdate()
    ,@cnt = 0, @pos1 = 0, @pos2 = 0
    ,@databaseid = db_id(@database)

-- check if valid database was provided
IF @databaseid IS NULL
BEGIN
    RAISERROR ('Missing database name. Rerun the procedure specifying a
       valid database name.',16,1)
    RETURN (0)
END

--determine if snapshots should be kept
IF @keepsnap <> 0
BEGIN
    -- determine if other snapshots exist for this server older than @
    -- keepsnap value hrs
    SELECT ROW_NUMBER() OVER(ORDER BY name DESC) AS [RowNum],
        name INTO #t1
    FROM master.sys.databases
    WHERE source_database_id = @databaseid
        AND create_date < dateadd(hh,-(@keepsnap),getdate())

    IF (SELECT max(RowNum) FROM #t1 where name is not null) > 0
    BEGIN
        WHILE @cnt <= (SELECT max(RowNum) FROM #t1)
        BEGIN
            SELECT @snap = name FROM #t1 WHERE RowNum = @cnt

            PRINT 'Dropping snapshot ''' + @snap + ''''

            SET @sql = 'DROP DATABASE ' + @snap

            EXEC(@sql)
            SELECT @cnt = @cnt + 1
        END
    END
END

-- break apart point in time date time information for file name
SELECT @yy = convert(varchar(4),year(@dt)),@mm = convert(varchar(2),
   month(@dt))
    ,@dd = convert(varchar(2), day(@dt)),@h = convert(varchar(2),
         datepart(hh,@dt))
    ,@m = convert(varchar(2), datepart(mi,@dt))

-- piece together the database snapshot name and the file name
SELECT @file = @database + '_' + @yy + @mm + @dd + '_' + @h + @m

-- identify logical file name of primary data file
SET @sql = 'SELECT name INTO tempdb..t1
FROM ' + @database + '.sys.database_files
WHERE file_id = 1'

EXEC(@sql)

--setting logical filename for the snap
SELECT @lname = name FROM tempdb..t1

-- making sure the file location ends with '\'
IF substring(@fileloc, len(@fileloc), 1) <> '\'
BEGIN
    SET @fileloc = @fileloc + '\'
END

-- build sql statement to be run
SET @sql = N'CREATE DATABASE ' + @file + ' ON
(NAME = ' + @lname + ', FILENAME = ''' + @fileloc + @file + '.snp'')
AS SNAPSHOT OF ' + @database

EXEC(@sql)

-- cleanup
DROP TABLE tempdb..t1;
GO
Впрочем, необходимо помнить, что моментальные снимки базы данных следует рассматривать как временные, поскольку нет возможности выполнять их резервное копирование и они не могут существовать без исходной базы данных. Если для разреженных файлов не хватает места, снимок будет считаться поврежденным и подлежать удалению.
Кроме того, если используются моментальные снимки базы данных, в ходе выполнения операций по изменению данных в исходной базе данных производительность системы может снижаться, поскольку страницы данных из файлов данных исходной базы записываются в разреженный файл каждого снимка. Таким образом, число записей возрастает во столько раз, сколько моментальных снимков имеет база данных.
Права чтения определяются исходной базой данных в момент создания снимка и не могут быть изменены. Моментальный снимок должен находиться на том же сервере, что и исходная база данных, поскольку они совместно используют как страницы данных, так и буферный кэш.
Использование моментальных снимков должно рассматриваться как решение для составления отчетов только в том случае, если оно используется совместно с зеркальным отображением. В противном случае это не даст для среды никакого выигрыша в производительности. Моментальные снимки баз данных, вероятно, являются самым быстрым способом сохранить данные перед запуском в системе сомнительной операции. Можно вернуть базу данных в состояние, соответствующее моменту создания снимка, или извлечь данные из снимка и заменить ими данные в исходной базе.
Необходимо определить для баз данных моментальных снимков стандарт именования. Я обычно использую следующий стандарт: originaldatabasename_date_time.snp. Согласно этому стандарту сначала указывается имя исходной базы данных, а затем дата и время (в 24-часовом формате) создания снимка.

Доставка журналов
Доставка журналов £ это вариант повышения уровня доступности с некоторыми ограничениями. При реализации доставки журналов используется резервное копирование и восстановление, что обеспечивает очень экономичное решение. При доставке журналов используются преимущества резервного копирования журналов транзакций через заданные интервалы времени, что позволяет своевременно обновлять базу данных-получателя.
При задании доставки журналов в приложении SQL Server 2005 используются мастера, с помощью которых можно выполнить настройку, планирование, инициализацию и наблюдение (см. рис. 5). Эта процедура очень проста и занимает всего несколько минут.
Figure 5 Log shipping setup wizard
Figure 5 Log shipping setup wizard (Щелкните изображение, чтобы уменьшить его)
Figure 5 Log shipping setup wizard
Figure 5 Log shipping setup wizard (Щелкните изображение, чтобы увеличить его)

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

Кластеризация серверов SQL Server
Кластеризация серверов работает на уровне операционной системы и включает в себя дублирующее оборудование и доступные кластеру общие дисковые ресурсы. Кластеризация, вероятно, наименее заметна для конечных пользователей, но она же требует максимальных затрат. Для этой технологии нужно минимум вдвое больше оборудования, чем для работы некластерного сервера.
Тема кластеризации является достаточно сложной, поэтому в данной статье будет рассматриваться не подробно, а только в виде краткого обзора. Для создания кластера требуются два или более серверов, на каждом из которых должна быть установлена одна и та же версия операционной системы Windows Server® 2000 выпусков Advanced или Datacenter либо системы Windows Server® 2003 выпусков Enterprise или Datacenter. Кроме того, потребуется установка служб MSCS (Microsoft® Cluster Services £ службы кластеров корпорации Майкрософт), которые распределяют права владения общими ресурсами между серверами и управляют IP-адресами, общими дисками и сетевыми именами. Еще для создания кластера необходим общий дисковый ресурс. Обычно эту роль выполняет сеть SAN (Storage Area Network £ сеть областей хранения) или подключенное запоминающее устройство SCSI.
Экземпляр сервера SQL Server также считается ресурсом. В конфигурации кластера можно установить как выпуск Standard, так и Enterprise продукта SQL Server 2005. Список возможностей, которые поддерживаются каждым из выпусков приложения SQL Server 2005, можно найти в документе «Feature Comparison Chart for SQL Server 2005» (Сравнительная таблица характеристик выпусков приложения SQL Server 2005), расположенном по адресу microsoft.com/sql/prodinfo/features/compare-features.mspx (на английском языке).
После того как ресурсы на кластере определены, дополнительный узел кластера регулярно связывается с основным узлом, используя периодический сигнал, передаваемый по частной сети между двумя узлами кластера. Этот сигнал представляет собой последовательность контрольных точек, которые фиксируются через равные интервалы времени и позволяют определить, что на основном узле произошел сбой.
В случае выхода из строя основного узла ресурсы перемещаются на дополнительный узел, причем состояние логического сервера не меняется. Клиенты могут продолжать работать с сервером после небольшой паузы. Весь процесс перехода на другой ресурс при сбое может занять от приблизительно 5 секунд и меньше до 30 секунд и больше (в некоторых случаях), что зависит от оборудования, программного обеспечения и сети кластера.
Кластеризация может представлять собой дорогую, сложную технологию, которая требует специальных навыков для устранения сбоев системы, но она обеспечивает наименее заметный для конечных пользователей переход на другой ресурс при сбое из всех вариантов автоматического перехода на другой ресурс. Каждое приложение имеет свои особенности, и некоторые из них могут быть не предназначены для работы с кластерами или не совместимы с ними. В худшем случае приложению придется повторно подключаться к серверу.

Репликация
Обеспечиваемую приложением SQL Server 2005 репликацию тоже можно использовать в архитектурах с высоким уровнем доступности. Данный продукт поддерживает четыре типа репликации: репликация моментальных снимков, транзакционная репликация, одноранговая репликация и репликация слиянием. Одноранговая репликация фактически является вариантом транзакционной репликации, поэтому здесь она рассматриваться не будет.
Репликация позволяет использовать для повышения уровня доступности дополнительный узел и базу данных-получатель, причем база данных-получатель настолько же работоспособна, насколько и база данных-источник. Это достигается путем использования репликации слиянием, в ходе которой берутся транзакции как с базы данных-источника, так и с базы данных-получателя. Затем обобщенные изменения применяются к обеим базам. Как нетрудно догадаться, такая конфигурация требует процедуры разрешения конфликтов.
Транзакционная репликация по своей логической структуре очень близка к зеркальному отображению баз данных. Транзакции, выполняемые в базе данных-источнике, доставляются в базу данных-получатель, чтобы гарантировать согласованность среды. Затем эти транзакции применяются к базе данных-получателю, которая потом ожидает выполнения в системе следующей транзакции.
Репликация моментальных снимков очень похожа на доставку журналов, поскольку и та, и другая проводятся через запланированные интервалы времени, а обновление базы данных-получателя выполняется посредством общего изменения, а не путем применения каждой транзакции к обеим системам сразу после их фиксации. Способы реализации обеих технологий во многом похожи.
Репликация требует специальных знаний, что может оказаться проблемой в организациях, не имеющих выделенного администратора баз данных. Репликация может быть достаточно сложной задачей в плане отладки и действительно требует более сложной структуры, если ее планируется использовать для повышения уровня доступности.
Репликация может вполне соответствовать требованиям, предъявляемым к решению, целью которого является повышение уровня доступности. Транзакционная репликация исполняет те же функции, которые зеркальное отображение баз данных может выполнять на уровне записей, но без возможности автоматического перехода на другой ресурс при сбое. Впрочем, при наличии достаточных ресурсов и возможности посвятить некоторое время написанию сценариев, создание решения для автоматического перехода на другой ресурс при сбое не должно стать большой проблемой.
В отличие от зеркального отображения баз данных, при репликации как исходная, так и конечная базы данных полностью доступны для клиентских приложений. Репликация моментальных снимков обеспечивает те же возможности, что и доставка журналов.
Нужно учитывать, что репликация £ это проверенная и хорошо документированная технология. Использование репликации в качестве решения для повышения уровня доступности может иметь некоторые недостатки и приводить к снижению производительности, впрочем, не в большей степени, чем при применении зеркального отображения. Вероятнее всего, любое решение для повышения уровня доступности, построенное на основе репликации, будет иметь более сложную для управления архитектуру: не обязательно усовершенствованную, но точно более сложную. Кроме того, одна из наиболее значительных трудностей, которую нужно учитывать, состоит в следующем: если изменяется структура таблиц базы данных или необходимо настроить репликацию еще одной таблицы, придется удалить и заново определить публикацию, чтобы внести изменения в обе базы данных.

Заключение
Из приведенного материала понятно, что к созданию решения для повышения уровня доступности в имеющейся среде надо подходить творчески. Каждая предоставляемая приложением SQL Server 2005 технология для повышения уровня доступности имеет свои сильные и слабые стороны, и в различных ситуациях нужно применять разные решения.
Доставка журналов, репликация моментальных снимков и даже зеркальное отображение баз данных в режиме высокой производительности могут стать хорошим выбором в том случае, если веб-база данных-источник географически отделена от базы данных-получателя (особенно, если не требуется, чтобы вспомогательные данные были доступны в режиме реального времени).
С другой стороны, если база данных-получатель должна быть доступна в режиме реального времени, транзакционная репликация или зеркальное отображение могут помочь в распределении нагрузки, если интенсивность транзакций на сервере-источнике не очень велика, а соединение между двумя узлами среды является быстрым и не перегружено.
Кроме того, надо учитывать, насколько удобным будет применение этих технологий. Если вы уже работали с некоторыми из них, то, вероятно, сможете чувствовать себя комфортно. Если вы руководитель и не имеете в своем подчинении выделенного администратора баз данных, старайтесь избегать более сложных технологий, таких как репликация, для которых нужно настраивать множество компонентов и отладка которых может оказаться трудной. Кроме того, рассмотрите вариант заключения договора с опытным консультантом по продукту SQL Server, который поможет вам разработать и реализовать оптимальное для имеющейся среды новое решение для повышения уровня доступности, а также, возможно, обучить сотрудников управлению этим решением.
Если высокий уровень доступности в вашей организации означает, что данные должны быть доступны в течение высокого процента времени, а периоды недоступности данных считаются недопустимыми, вероятно, стоит отдать предпочтение кластеризации.
В заключение напомню, что приложение SQL Server 2005 предоставляет ряд новых возможностей для реализации высокого уровня доступности, которые предназначены для использования в средах различных типов. Существует возможность применить только одну технологию повышения уровня доступности или воспользоваться преимуществами сочетания нескольких вариантов, но, как уже было отмечено, в любом случае есть несколько возможных вариантов.

Зак Нихтер (Zach Nichter) £ специалист по продукту SQL Server с более чем 10-летним опытом. Занимаясь поддержкой серверов SQL Server, выступал в роли администратора баз данных, ведущего сотрудника группы, менеджера и консультанта. В настоящее время Зак работает архитектором баз данных в компании Levi Strauss & Co. Он отвечает за производительность и архитектуру серверов SQL Server, а также занимается наблюдением за этими серверами и решает другие связанные с ними стратегические задачи.


 SQL Server: Упрощение обслуживания баз данных с помощью секционированных таблиц
SQL Server Ноа Гомес (Noah Gomez)

Упрощение обслуживания баз данных с помощью секционированных таблиц
Краткий обзор:
  • Создание секционированных таблиц
  • Добавление и слияние секций
  • Создание секционированных индексов и управление ими
Загрузить исходный код для этой статьи: GomezPartitioning2007_03.exe (156KB)

В прошлом администраторам баз данных, управляющим таблицами с миллионами строк данных, приходилось создавать множественные таблицы. Произведя секционирование таблиц, администратору приходилось привязывать
эти таблицы друг к другу во время выполнения многих запросов. Привязывание секций друг к другу требовало создания секционированного представления или хранимой процедуры-оболочки, определявшей местонахождение данных и выполнявшей другую хранимую процедуру, которая работала только с секциями, нужными для возвращения набора данных.
Хотя эти методы позволяли достичь требуемого результата, они были весьма обременительны. Операции администрирования нескольких таблиц и их индексов, а также методы, используемые для обратного привязывания таблиц, зачастую становились источником затруднений при администрировании и обслуживании. Кроме того, создание нескольких таблиц для секционирования данных приводило к отсутствию гибкости, так как в хранимых процедурах, заданиях обслуживания, заданиях служб преобразования данных (DTS), коде приложения и других процессах приходилось учитывать характер секционирования. Поэтому для обеспечения возможности добавления или сброса этих квазисекций без изменения кода такие элементы обычно создавались нединамическими способами и, следовательно, имели низкую эффективность.
Выпуски SQL Server™ 2005 Enterprise Edition и Developer Edition позволяют секционировать большое количество данных, хранимых в единой таблице, на несколько секций меньшего размера, поддающихся более эффективному управлению и обслуживанию. Возможность создания сегментов данных, доступ к которым осуществляется через единую точку входа, устраняет многие проблемы администрирования, которые возникали при прежнем способе работы. Благодаря использованию единой точки входа (имени таблицы или имена индекса) множественность сегментов данных становится скрытой от кода приложения, и администратор или разработчик может выполнять нужные изменения секций без необходимости изменения кодовой базы.
Таким образом, можно создавать множественные секции, перемещать их, сбрасывать старые секции и даже изменять способ секционирования данных, не внося каких-либо изменений в код приложения. Код приложения просто продолжает обращаться к той же самой базовой таблице или имени индекса. Это позволяет также уменьшить количество данных, хранимых в отдельных индексах, что, в свою очередь, снижает время обслуживания этих индексов. Кроме того, можно загружать данные в пустые секции, что позволяет увеличить скорость загрузки данных.
Технически каждая таблица в сервере SQL Server 2005 секционирована, т. е. имеет по крайней мере одну секцию. Кроме того, сервер SQL Server 2005 позволяет администраторам баз данных создавать дополнительные секции в каждой таблице. Секционирование таблиц и индексов задается жестко на уровне строк (секционирование по столбцам не допускается) и позволяет осуществлять доступ через единую точку входа (имя таблицы или имя индекса) таким образом, что в коде приложения не требуется знать число секций, находящихся за точкой входа. Секционирование может осуществляться на базовой таблице, а также на связанных с ней индексах.

Создание секционированных таблиц
Для создания таблицы, которая способна вырастать в размерах и задействовать дополнительные секции помимо исходной, применяются функции секционирования и схемы секционирования. Именно эти объекты позволяют разделять данные на конкретные сегменты и управлять их местоположением в рамках конструкции хранилища. Например, можно распределить данные по нескольким дисковым массивам в зависимости от возраста данных или других отличительных признаков. Следует отметить, что таблицу можно секционировать по одному из ее столбцов, и каждая секция должна содержать данные, которые не могут быть помещены в другие секции.
Функции секционирования. При секционировании таблицы в первую очередь нужно определить принцип, по которому данные будут разделяться на сегменты. Для сопоставления отдельных строк данных с разными сегментами служит функция секционирования. Строки данных могут сопоставляться по столбцу любого типа, кроме следующих: text, ntext, image, xml, timestamp, varchar(max), nvarchar(max), varbinary(max), псевдонимы типов данных и пользовательские типы данных среды CLR. Однако функция секционирования должна помещать строку данных только в одну секцию таблицы; иными словами, в результате применения функции одна и та же строка не может принадлежать нескольким секциям одновременно.
Чтобы секционировать таблицу, в ней необходимо создать столбец секционирования. Этот столбец секционирования можно создать в схеме таблицы в момент создания таблицы, либо добавить позднее путем модификации таблицы. Столбец может принимать значения NULL, но все строки, содержащие значения NULL, будут по умолчанию помещаться в самую левую секцию таблицы. Этого можно избежать, указав при создании функции секционирования, что значения NULL должны помещаться в самую правую секцию таблицы. Выбор левой или правой секций – важное решение проектирования, проявляющееся при изменении схемы секционирования, добавлении дополнительных секций или удалении существующих.
При создании функции секционирования можно выбрать функции LEFT или RIGHT. Разница между секциями LEFT и RIGHT состоит в том, где в схеме секционирования будут размещаться граничные значения. При использовании секций LEFT (этот вариант выбирается по умолчанию) граничное значение включается в секцию, тогда как при использовании секций RIGHT граничное значение размещается в следующей секции.
Чтобы лучше понять этот принцип, рассмотрим следующие примеры секций LEFT и RIGHT:
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

CREATE PARTITION FUNCTION Right_Partition (int) AS RANGE RIGHT
FOR VALUES (1,10,100)
В первой функции (Left_Partition) значения 1, 10 и 100 размещаются соответственно в первой, второй и третьей секциях. Во второй функции (Right_Partition) эти значения размещаются во второй, третьей и четвертой секциях.
При создании секционированной таблицы важно, чтобы секции получились как можно более равными. Это поможет понять, сколько места потребуется для каждой секции. Использование параметров LEFT и RIGHT определяет, куда будут размещаться данные, что, в свою очередь, задает размер секции и размеры индексов, созданных на ней.
Определить номер секции, в которую попадет то или иное значение, можно с помощью функции $PARTITION, как показано ниже:
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Right_Partition (10)
Первая инструкция SELECT возвращает значение 2, вторая – значение 3.
Схемы секционирования. После создания функции и выбора способа разделения данных между секциями следует решить, где будут создаваться отдельные секции в дисковой подсистеме. Для создания этой дисковой структуры используются схемы секционирования. Схемы секционирования управляют тем, как отдельные секции хранятся на диске, путем использования файловых групп для размещения каждой секции на дисковой подсистеме. Схемы секционирования можно настроить таким образом, чтобы все секции располагались в единой файловой группе, чтобы каждая секция располагалась в своей файловой группе или чтобы несколько секций использовали общие файловые группы. Последний способ дает администратору базы данных широкие возможности рассредоточения операций ввода-вывода на диске.
На рис. 1 показаны некоторые из способов, позволяющих присвоить схеме секционирования одну или несколько файловых групп. Следует помнить, что файловые группы, используемые схемой секционирования, должны существовать в базе данных перед созданием схемы.
Figure 1 Присвоение файловых групп схеме секционирования (Close Figure 1)
--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the different filegroups
CREATE PARTITION SCHEME Different_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      TO (Filegroup1, Filegroup2, Filegroup3, Filegroup4)
--Filegroups must currently exist in database

--Place multiple partitions into the different filegroups
CREATE PARTITION SCHEME Multiple_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      TO (Filegroup1, Filegroup2, Filegroup1, Filegroup2)
--Filegroups must currently exist in database
Если создать шаблоны функций секционирования, показанные на рис. 1, и использовать эту схему секционирования для создания таблицы, то впоследствии можно будет определить, где будут размещаться отдельные строки данных в секционированных таблицах. Это позволит впоследствии просматривать распределение строк данных, вставленных в секционированную таблицу. Обеспечивающий это программный код будет выглядеть, как показано на рис. 2.
Figure 2 Размещение строк данных и просмотр распределения (Close Figure 2)
--Prepare database
IF OBJECT_ID('Partitioned_Table') IS NOT NULL
DROP TABLE Partitioned_Table
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
      ALL TO ([PRIMARY])

CREATE TABLE Partitioned_Table
(
col1 INT
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

--Determine where values will be placed (this is not required)
--You should try to do this before executing the code
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (2)
SELECT $PARTITION.Left_Partition (3)
SELECT $PARTITION.Left_Partition (4)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (11)
SELECT $PARTITION.Left_Partition (12)
SELECT $PARTITION.Left_Partition (13)
SELECT $PARTITION.Left_Partition (14)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)
SELECT $PARTITION.Left_Partition (102)
SELECT $PARTITION.Left_Partition (103)
SELECT $PARTITION.Left_Partition (104)

--Insert data into partitioned table
INSERT INTO Partitioned_Table VALUES (1,'Description')
INSERT INTO Partitioned_Table VALUES (2,'Description')
INSERT INTO Partitioned_Table VALUES (3,'Description')
INSERT INTO Partitioned_Table VALUES (4,'Description')
INSERT INTO Partitioned_Table VALUES (10,'Description')
INSERT INTO Partitioned_Table VALUES (11,'Description')
INSERT INTO Partitioned_Table VALUES (12,'Description')
INSERT INTO Partitioned_Table VALUES (13,'Description')
INSERT INTO Partitioned_Table VALUES (14,'Description')
INSERT INTO Partitioned_Table VALUES (100,'Description')
INSERT INTO Partitioned_Table VALUES (101,'Description')
INSERT INTO Partitioned_Table VALUES (102,'Description')
INSERT INTO Partitioned_Table VALUES (103,'Description')
INSERT INTO Partitioned_Table VALUES (104,'Description')

--View the distribution of data in the partitions
SELECT ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('Partitioned_Table')

Изменение секционированных таблиц
Несмотря на тщательное планирование, иногда приходится вносить изменения в секционированные таблицы после того, как они созданы и наполнены данными. Схема секционирования может работать, как задумано, но администратору базы данных может, например, понадобиться добавить новые секции при накоплении новых данных, или же может потребоваться за один раз сбросить большое количество секционированных данных. К счастью, секционированные таблицы и базовые структуры секционирования позволяют вносить изменения после того, как таблица введена в эксплуатацию и наполнена данными.
Добавление секций. Многие планы секционирования включают возможность добавления новых секций в будущем. Этот момент времени может задаваться определенной датой или зависеть от значения, находящегося в столбце инкрементальных идентификаторов. Однако если добавление новых секций в секционированную таблицу не было запланировано заранее, это можно сделать в любой момент. Рассмотрим таблицу, создание которой показано на рис. 2. Добавить в нее новую секцию, которая будет содержать значения больше 500, можно следующим образом:
--Determine where values live before new partition
SELECT $PARTITION.Left_Partition (501)  --should return a value of 4

--Create new partition
ALTER PARTITION FUNCTION Left_Partition ()
SPLIT RANGE(500)

--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (501)  --should return a value of 5
Возможность добавления новых секций обеспечивает высокую гибкость. На рис. 3 показано, как добавить секцию слева от функции. В данном случае необходимо определить в схеме секционирования, где будет размещаться новая секция, так как уже исчерпаны все файловые группы, созданные при первом построении схемы секционирования. Хотя для всех секций используется файловая группа PRIMARY, в схеме секционирования необходимо явно определить, что эта файловая группа должна использоваться и для новой секции.
Figure 3 Добавление секции слева от функции (Close Figure 3)
--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (5)   --should return a value of 2
SELECT $PARTITION.Left_Partition (1)   --should return a value of 1
SELECT $PARTITION.Left_Partition (10)  --should return a value of 2

--Add new filegroups to the partitioning scheme
ALTER PARTITION SCHEME Primary_Left_Scheme
NEXT USED [PRIMARY]

--Create new partition
ALTER PARTITION FUNCTION Left_Partition ()
SPLIT RANGE(5)

--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (5)   --should return a value of 2
SELECT $PARTITION.Left_Partition (1)   --should return a value of 1
SELECT $PARTITION.Left_Partition (10)  --should return a value of 3
Слияние двух секций. Сервер SQL Server позволяет сбрасывать отдельные секции из таблицы, при этом сохраняя данные. Таким способом можно выполнить слияние старых активных данных с архивированными данными или уменьшить количество имеющихся секций для упрощения администрирования секционированной таблицы. С помощью слияния секций можно также перемещать данные из одной файловой группы в другую для освобождения дискового пространства на определенных дисковых массивах. В программном коде на рис. 4 показано, как можно переместить данные из одной секции в другую на одной и той же файловой группе.
Figure 4 Перемещение данных из одной секции в другую (Close Figure 4)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

INSERT INTO multiple_partition VALUES (1,'Description')
INSERT INTO multiple_partition VALUES (2,'Description')
INSERT INTO multiple_partition VALUES (3,'Description')
INSERT INTO multiple_partition VALUES (4,'Description')
INSERT INTO multiple_partition VALUES (10,'Description')
INSERT INTO multiple_partition VALUES (11,'Description')
INSERT INTO multiple_partition VALUES (12,'Description')
INSERT INTO multiple_partition VALUES (13,'Description')
INSERT INTO multiple_partition VALUES (14,'Description')
INSERT INTO multiple_partition VALUES (100,'Description')
INSERT INTO multiple_partition VALUES (101,'Description')
INSERT INTO multiple_partition VALUES (102,'Description')
INSERT INTO multiple_partition VALUES (103,'Description')
INSERT INTO multiple_partition VALUES (104,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Check where data would be placed
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)

--Merge two partitions
ALTER PARTITION FUNCTION Left_Partition()
MERGE RANGE (10)

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Check where data would be placed
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)
Перемещение таблицы с одной секцией в секционированную таблицу. Во время выполнения процедур загрузки часто требуется загружать большие партии данных в базу данных, а затем изменять или агрегировать эти данные, прежде чем переместить их в результирующую таблицу. Механизмы секционирования в сервере SQL Server 2005 позволяют перемещать таблицу с одной секцией в таблицу с несколькими секциями. Это означает, что можно загрузить данные в одну загрузочную таблицу, внести необходимые изменения в эти данные, а затем переместить таблицу целиком в другую существующую таблицу, избегая при этом необходимости перемещать строки данных по одной. На этом уровне секционирования не происходит изменения базовых структур секционирования. В данном случае происходит изменение секционированной таблицы. На рис. 5 показан пример программного кода, выполняющего описанные действия.
Figure 5 Перемещение целой таблицы в существующую таблицу (Close Figure 5)
--Prepare database
IF OBJECT_ID(‘multiple_partition’) IS NOT NULL
DROP TABLE multiple_partition
GO

IF OBJECT_ID(‘single_partition’) IS NOT NULL
DROP TABLE single_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = ‘Primary_Left_Scheme’)
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = ‘Left_Partition’)
DROP PARTITION FUNCTION Left_Partition
GO

--Create single partition table
CREATE TABLE single_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
)

--Table must have a CHECK Constraint
ALTER TABLE single_partition
WITH CHECK
ADD CONSTRAINT CK_single_partition
    CHECK (col1 > 100)

INSERT INTO single_partition VALUES (101,’Description’)
INSERT INTO single_partition VALUES (102,’Description’)
INSERT INTO single_partition VALUES (103,’Description’)
INSERT INTO single_partition VALUES (104,’Description’)

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

INSERT INTO multiple_partition VALUES (1,’Description’)
INSERT INTO multiple_partition VALUES (2,’Description’)
INSERT INTO multiple_partition VALUES (3,’Description’)
INSERT INTO multiple_partition VALUES (4,’Description’)
INSERT INTO multiple_partition VALUES (10,’Description’)
INSERT INTO multiple_partition VALUES (11,’Description’)
INSERT INTO multiple_partition VALUES (12,’Description’)
INSERT INTO multiple_partition VALUES (13,’Description’)
INSERT INTO multiple_partition VALUES (14,’Description’)
INSERT INTO multiple_partition VALUES (100,’Description’)

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID(‘multiple_partition’), OBJECT_
      ID(‘single_partition’))

--Move the single table into the partitioned table
ALTER TABLE single_partition SWITCH TO multiple_partition PARTITION 4

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID(‘multiple_partition’), OBJECT_ID(‘single_partition’))
Перемещение секции из одной таблицы в другую. Одной из типичных задач администрирования является перемещение старых данных в отдельные архивные таблицы. Процесс архивации обычно требует серии инструкций, которые приводят к дополнительному потреблению ресурсов в журналах транзакций. Чтобы легко архивировать большое количество данных без лишних издержек, связанных с журналом транзакций, можно воспользоваться переводом принадлежности секции с одной таблицы на другую. Эта возможность позволяет администратору базы данных перемещать сегменты старых данных из активных таблиц в архивные. Поскольку сами данные при этом в действительности не перемещаются, этот способ требует значительно меньше времени, чем при перемещении строк данных по одной. На рис. 6 показано, как можно это сделать.
Figure 6 Перемещение старых данных в архивные таблицы (Close Figure 6)
--Prepare database
IF OBJECT_ID('active_data') IS NOT NULL
DROP TABLE active_data
GO

IF OBJECT_ID('archive_data') IS NOT NULL
DROP TABLE archive_data
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Active_Scheme')
DROP PARTITION SCHEME Active_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Active_Partition')
DROP PARTITION FUNCTION Active_Partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Archive_Scheme')
DROP PARTITION SCHEME Archive_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Archive_Partition')
DROP PARTITION FUNCTION Archive_Partition
GO

--Create active function
CREATE PARTITION FUNCTION Active_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Create archive function
CREATE PARTITION FUNCTION Archive_Partition (int) AS RANGE LEFT
FOR VALUES (100,200,300)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Active_Scheme
AS PARTITION Active_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Archive_Scheme
AS PARTITION Archive_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE active_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Active_Scheme (col1)

CREATE TABLE archive_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Archive_Scheme (col1)

INSERT INTO active_data VALUES (1,'Description')
INSERT INTO active_data VALUES (2,'Description')
INSERT INTO active_data VALUES (3,'Description')
INSERT INTO active_data VALUES (4,'Description')
INSERT INTO active_data VALUES (10,'Description')
INSERT INTO active_data VALUES (11,'Description')
INSERT INTO active_data VALUES (12,'Description')
INSERT INTO active_data VALUES (13,'Description')
INSERT INTO active_data VALUES (14,'Description')
INSERT INTO active_data VALUES (100,'Description')

INSERT INTO archive_data VALUES (200,'Description')
INSERT INTO archive_data VALUES (300,'Description')
INSERT INTO archive_data VALUES (400,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Switch ownership of partition to another table
ALTER TABLE active_data SWITCH PARTITION 3 TO archive_data PARTITION 1

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))
Использование единичной секции для создания новой таблицы. Единичную секцию можно переместить из существующей секционированной таблицы в пустую несекционированную таблицу. В результате этого администратор базы данных получает возможность выполнить обслуживание индексов на этой единичной секции или легко сбросить большое количество данных без необходимости регистрировать процесс удаления в журнале. На рис. 7 показано, как переместить секцию в пустую таблицу и затем сбросить данные с помощью этой новой таблицы.
Figure 7 Перемещение и сброс данных (Close Figure 7)
--Prepare database
IF OBJECT_ID('active_data') IS NOT NULL
DROP TABLE active_data
GO

IF OBJECT_ID('archive_data') IS NOT NULL
DROP TABLE archive_data
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Active_Scheme')
DROP PARTITION SCHEME Active_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Active_Partition')
DROP PARTITION FUNCTION Active_Partition
GO

--Create active function
CREATE PARTITION FUNCTION Active_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Active_Scheme
AS PARTITION Active_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE active_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Active_Scheme (col1)

CREATE TABLE archive_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
)

INSERT INTO active_data VALUES (1,'Description')
INSERT INTO active_data VALUES (2,'Description')
INSERT INTO active_data VALUES (3,'Description')
INSERT INTO active_data VALUES (4,'Description')
INSERT INTO active_data VALUES (10,'Description')
INSERT INTO active_data VALUES (11,'Description')
INSERT INTO active_data VALUES (12,'Description')
INSERT INTO active_data VALUES (13,'Description')
INSERT INTO active_data VALUES (14,'Description')
INSERT INTO active_data VALUES (100,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Switch ownership of partition to another table
ALTER TABLE active_data SWITCH PARTITION 3 TO archive_data

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Drop all archive data without logging
DROP TABLE archive_data
GO

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

Секционированные индексы
Вместе с возможностью секционирования данных таблицы появляется и возможность создавать секционированные индексы. Это позволяет администратору базы данных проектировать структуру индекса на основе разделенных данных, а не на основе всех данных таблицы. Создание секционированных индексов влечет за собой создание отдельных сбалансированных деревьев на секционированных индексах. В результате разделения индексов создаются индексы меньшего размера, и обработчику хранилища становится проще их обслуживать во время изменения, добавления и удаления данных. Администратор базы данных также может обслуживать эти уменьшенные индексы по отдельности, что дает возможность более эффективно обслуживать индексы на больших наборах данных.
Создание секционированных индексов. При создании секционированных индексов можно создавать выровненные или невыровненные индексы. Выровненные индексы подразумевают прямую связь с секционированными данными. (В случае с невыровненными индексами выбирается другая схема секционирования.)
Из этих двух методов предпочтителен выровненный индекс, который выбирается автоматически, если после создания секционированной таблицы индексы создаются без указания другой схемы секционирования. Использование выровненных индексов предоставляет необходимую гибкость для создания дополнительных секций в таблице, а также позволяет переводить принадлежность той или иной секции на другую таблицу. Наличие этих возможностей – основная причина, по которой администраторы баз данных сразу создают секционированные таблицы. Для решения большинства задач, связанных с секционированием, достаточно использовать для индексов схему секционирования таблицы.
Индексы на таблицах можно создавать таким образом, чтобы данные в индексе не были выровнены с данными в таблице. Если данные хранятся в секционированной таблице, это позволяет соединять данные различными способами (секционированные данные могут эффективно соединяться с другими секционированными данными при помощи оптимизатора запросов). Как вариант, можно сделать это с несекционированной таблицей, что позволит создать секционированный индекс (на таблице с единичной секцией) для упрощения обслуживания индекса.
Программный код на рис. 8 создает секционированный некластеризованный индекс на секционированной таблице. Некластеризованный индекс выравнивается с таблицей; в качестве некластеризованного ключа индекса используется столбец секционирования таблицы.
Figure 8 Секционированный некластеризованный индекс на секционированной таблице. (Close Figure 8)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
    ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

--Create partitioned non-clustered index
CREATE NONCLUSTERED INDEX cl_multiple_partition ON multiple_
      partition(col1)

INSERT INTO multiple_partition VALUES (1,'Description')
INSERT INTO multiple_partition VALUES (2,'Description')
INSERT INTO multiple_partition VALUES (3,'Description')
INSERT INTO multiple_partition VALUES (4,'Description')
INSERT INTO multiple_partition VALUES (10,'Description')
INSERT INTO multiple_partition VALUES (11,'Description')
INSERT INTO multiple_partition VALUES (12,'Description')
INSERT INTO multiple_partition VALUES (13,'Description')
INSERT INTO multiple_partition VALUES (14,'Description')
INSERT INTO multiple_partition VALUES (100,'Description')
INSERT INTO multiple_partition VALUES (101,'Description')
INSERT INTO multiple_partition VALUES (102,'Description')
INSERT INTO multiple_partition VALUES (103,'Description')
INSERT INTO multiple_partition VALUES (104,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Verify index partitions
SELECT partition_id, index_id FROM sys.partitions pt
WHERE pt.[object_id] = OBJECT_ID('multiple_partition')
Программный код на рис. 9 создает невыровненный некластеризованный индекс на секционированной таблице. В этом некластеризованном индексе в качестве ключа индекса используются разные столбцы; этот ключ может использоваться в упорядоченных объединениях с другими секционированными таблицами.
Figure 9 Невыровненный некластеризованный индекс на секционированной таблице (Close Figure 9)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Index_primary_Left_Scheme')
DROP PARTITION SCHEME Index_primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Index_Left_Partition')
DROP PARTITION FUNCTION Index_Left_Partition
GO

--Create partitioned index function
CREATE PARTITION FUNCTION Index_Left_Partition (int) AS RANGE LEFT
FOR VALUES (10,50,100)

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all index partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Index_primary_Left_Scheme
AS PARTITION Index_Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT
,col2 INT
) ON Primary_Left_Scheme (col1)

--Create non-aligned partitioned nonclustered index
CREATE NONCLUSTERED INDEX cl_multiple_partition ON multiple_
     partition(col2)
ON Index_primary_Left_Scheme (col2)

INSERT INTO multiple_partition VALUES (1,10)
INSERT INTO multiple_partition VALUES (2,10)
INSERT INTO multiple_partition VALUES (3,10)
INSERT INTO multiple_partition VALUES (4,10)
INSERT INTO multiple_partition VALUES (10,50)
INSERT INTO multiple_partition VALUES (11,50)
INSERT INTO multiple_partition VALUES (12,50)
INSERT INTO multiple_partition VALUES (13,50)
INSERT INTO multiple_partition VALUES (14,50)
INSERT INTO multiple_partition VALUES (100,100)
INSERT INTO multiple_partition VALUES (101,100)
INSERT INTO multiple_partition VALUES (102,100)
INSERT INTO multiple_partition VALUES (103,100)
INSERT INTO multiple_partition VALUES (104,100)

--Verify row count on partitioned data
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')
AND p.index_id = 0

--Verify row count on partitioned index
--Row counts will not match those found in the data partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')
AND p.index_id <> 0
Обслуживание секционированных индексов. В прошлом обслуживание индексов для больших таблиц, содержавших миллионы или даже миллиарды строк данных, часто занимало у администраторов баз данных непозволительно много времени. Обслуживание зачастую оставалось невыполненным вследствие того, что во время перестроения индекса данные блокировались. Используя сервер SQL Server 2005, администратор базы данных может выполнить обслуживание индекса в оперативном режиме, не блокируя базовую таблицу на длительный период времени. Но даже этот подход, позволяющий пользователям работать с данными во время обслуживания индекса, все равно может замедлить работу системы, поскольку подразумевает использование определенного количества ресурсов. Более эффективный подход – секционировать индексы на меньшие сегменты и выполнять обслуживание индексов на этих уменьшенных секциях. Например, чтобы выполнить обслуживание индекса для секции с одним индексом, можно просто добавить нижеприведенный отрывок кода к концу кода, приведенного на рис. 8.
ALTER INDEX cl_multiple_partition
ON multiple_partition
REBUILD Partition = 2
Следует учесть, что обслуживание индекса для секций с одним индексом должно выполняться в автономном режиме, поэтому оно может послужить причиной блокировки таблицы во время обслуживания индекса. Во избежание этого следует переместить единичную секцию в отдельную секцию, выполнить обслуживание индекса, а затем переместить секцию обратно в главную таблицу. Этот процесс вызовет некоторое снижение производительности во время обратного перемещения секции в таблицу и обновления кластеризованного индекса, но это приводит к меньшим затруднениям, чем блокировка всей таблицы, и требует меньше системных ресурсов.

Заключение
Итак, секционирование таблиц в сервере SQL Server 2005 обеспечивает значительно более высокую гибкость хранения и обслуживания данных в больших таблицах, не требуя доработки кода приложения или процессов сервера SQL Server. Благодаря этим возможностям сервер SQL Server зарекомендовал себя как платформа, отвечающая задачам критически важных баз данных на уровне предприятий.

Ноа Гомес (Noah Gomez) – ведущий администратор баз данных отдела разработки для сервера SQL Server в компании Verizon, специализирующийся на сверхбольших базах данных и крупномасштабных приложениях. Он состоит в Профессиональной ассоциации по SQL Server (PASS), и был членом команды администраторов баз данных Verizon, работавшей над многотерабайтными сверхбольшими базами данных, которые в 2003 г. были отмечены несколькими наградами «TopTen Grand Prize» от корпорации Winter Corp.


 SQL Server: Советы по кластеризации серверов SQL Server
SQL Server Том Моро (Tom Moreau)

Советы по кластеризации серверов SQL Server
Краткий обзор:
  • Работа с SQL Server на кластере
  • Требования к оборудованию и программам
  • Кластер с одним узлом
  • Экономичные варианты

Кластер серверов позволяет соединить несколько физических серверов (узлов), которые служат друг для друга партнерами в процедуре перехода на резервный ресурс. Избыточность, предоставляемая кластером, обеспечивает существенно более высокую продолжительность бесперебойной работы, необходимую для критических
операций. За 13 лет работы с SQL Server™ я внедрил множество кластеров, и в каждом случае были свои особенности. Этот опыт позволил мне сформулировать ряд советов и рекомендаций, которые помогут сделать работу с кластерами проще и успешнее.
Кластеры серверов позволяют выгодно применить встроенные возможности кластеризации программных продуктов семейства Windows Server® (выпуски Enterprise Edition). Нужно отметить, что операционная система Windows Server 2003 больше подходит для целей кластеризации, чем операционная система Windows 2000 Advanced Server. Чтобы воспользоваться всеми преимуществами кластеризации, необходимо соответствующее оборудование, и это требует определенных затрат. Недостаточно просто «слепить» пару серверов и общий диск; нельзя также полагаться на тот факт, что отдельные компоненты оборудования входят в Каталог Windows® (в прошлом – список совместимого оборудования HCL). В Каталоге Windows должна присутствовать вся система. Однако это не повод для разочарования: существуют одобренные экономичные решения для кластеризации. На рис. 1 показана типичная конфигурация кластера.
Figure 1 A typical cluster
Figure 1 A typical cluster (Щелкните изображение, чтобы уменьшить его)
Figure 1 A typical cluster
Figure 1 A typical cluster (Щелкните изображение, чтобы увеличить его)
Разумеется, перечень вещей, которые нужно учитывать при кластеризации, не ограничивается оборудованием; необходимо также выбрать правильный выпуск сервера SQL Server 2005. Выпуск Enterprise Edition предоставляет возможности кластеризации, а также другие полезные возможности, такие как использование большего количества процессоров, распределенные и обновляемые секционированные представления, встроенная доставка журналов, автоматическое использование индексированных представлений. В случае наличия лицензии для выпуска Enterprise Edition следует подумать о кластеризации независимо от того, есть ли в организации от двух до восьми серверов, необходимых для формирования традиционного кластера (о кластерах с одним узлом речь пойдет чуть позже). Если используется выпуск SQL Server 2005 Standard Edition, можно установить кластер из двух узлов.
Операционная система Windows Server 2003 выпусков Enterprise Edition и Enterprise Datacenter Edition поставляется со встроенной кластеризацией. Достаточно просто запустить Администратор кластера и настроить кластер. Узлы можно добавлять по одному или все сразу. Аналогичным образом при установке сервера SQL Server можно выбрать установку на отдельный некластеризованный сервер или установку виртуального экземпляра на кластер. При выборе установки виртуального экземпляра можно выполнить установку на все узлы кластера, на избранные узлы или даже на один узел кластера.
Наконец, чтобы достичь истинной цели кластеризации – высокого уровня доступности,– необходимы квалифицированные специалисты и отрепетированные процедуры на случай возникновения неполадок. Хотя кластеризация является хорошей страховкой против сбоев оборудования, она не предотвращает ошибок пользователей, таких, например, как сброс важной таблицы невыспавшимся администратором базы данных посреди ночи.

Кластеры с одним узлом
Даже если в данный момент необходим только один сервер, все равно имеет смысл подумать о создании кластера с одним узлом. Это даст возможность впоследствии усовершенствовать конфигурацию до кластера без необходимости переделывать систему. Нужно только удостовериться, что выбранное оборудование присутствует в разделе кластеров Каталога Windows.
Возможность последующего добавления узла полезна не только ради повышения уровня доступности. Рассмотрим ситуацию, когда в какой-то момент обнаруживается, что мощность сервера недостаточна. Это означает необходимость миграции, то есть затраты времени и сил. При наличии кластера с одним узлом миграцию можно будет выполнить намного легче и с меньшим временем простоя. В кластер добавляется новый узел; на новый узел устанавливаются двоичные файлы и пакеты обновлений сервера SQL Server, а затем с помощью процедуры перехода на резервный ресурс выполняется перенос сервера на новый узел. После этого нужно установить дополнительные исправления, выпущенные после пакета обновлений, и, наконец, исключить старый узел. Время простоя ограничивается временем перехода на резервный ресурс и установки обновлений (если необходимо).

Добавление узлов
Поскольку все узлы в кластере должны быть одинаковыми, то чем раньше предприняты действия по приобретению дополнительного узла, тем лучше. Если прождать слишком долго, производство нужного оборудования может быть прекращено. На одном проекте мне нужно было перестроить узел в кластере серверов SQL Server 2000. Я переложил ответственность за базовое построение компьютера на администратора сети и операционных систем, а затем пришел, чтобы добавить компьютер обратно в кластер и подготовить его к работе в качестве узла SQL Server. Все шло хорошо, пока я не выполнил переход на резервный ресурс на новый узел. К моему великому сожалению, сразу же случился обратный переход. В двух словах, произошло следующее: несмотря на то, что я подготовил подробный документ по построению нового кластера, включавший добавление на оба узла служебных учетных записей кластера и сервера SQL Server, эти указания были выполнены неточно. Администратор не добавил эти служебные учетные записи на перестроенный узел, поэтому права, имевшиеся у этих учетных записей до перестроения, больше не существовали.
На обнаружение причины у меня ушло много времени. Однажды мне пришло в голову посмотреть на состав локальных групп. Как только я добавил эти две учетные записи, переход на резервный ресурс прошел благополучно. Это навело меня на размышления. Перестроение узла делается нечасто, а если делается, то в экстренной ситуации. Хотя я и подготовил документацию, мои указания не были исполнены. Мы могли бы автоматизировать часть, ответственную за безопасность, написав небольшой сценарий, который бы добавлял эти две учетные записи и выполнял бы другую необходимую настройку. Однако в сервере SQL Server 2005 эта процедура усовершенствована. Установщик требует, чтобы для служебных учетных записей SQL Server задавались группы на уровне домена.
Разумеется, это заставило меня задуматься еще. Ведь можно создать сценарии, которые бы вызывали программу CLUSTER.EXE для добавления узла в сервер кластеров Microsoft® (MSCS). Все, что нужно сделать, – это передать сценарию имя узла, а остальное он сделает сам. В экстренной ситуации автоматизация – настоящий друг.

Кластеры «N+1»
Иногда узел добавляется в кластер не для замены другого узла. Возможно, в кластер требуется добавить дополнительные экземпляры сервера SQL Server, и каждому экземпляру требуются отдельные дисковые ресурсы. Хотя на одном узле может быть запущено несколько экземпляров сервера, в такой ситуации им приходится делить между собой процессор и ОЗУ, что приводит к снижению производительности. В идеальной ситуации на одном узле должен быть запущен только один экземпляр. Как гарантировать это при переходе на резервный ресурс? Очень просто! На одном из узлов не должно выполняться ни одной службы, а на каждом из остальных узлов должно быть запущено по одному экземпляру сервера SQL Server. Это и есть определение кластера «N+1»: N экземпляров, запущенных на N+1 узлах. Лишний узел является запасным.

Обновление сервера SQL Server
Обновление кластеризованного экземпляра SQL Server – ответственное мероприятие. Экземпляры кластеризуются не просто так, а ради повышения продолжительности бесперебойной работы. Сервер SQL Server 2005 содержит большое количество полезных улучшений, позволяющих сократить время простоя в случае необходимости обновления сервера.
Какие имеются варианты? Сначала рассмотрим самое дорогостоящее решение: создание совершенно нового кластера, которое потребует новых серверов и, возможно, новой сети области хранения данных (SAN). Вероятно, удастся сохранить существующие сетевые коммутаторы, но этим исчерпываются возможности использования старого оборудования. Очевидно, это недешевый подход, но у него есть преимущества. Новое оборудование, как правило, работает намного лучше старого; скорость и емкость дисков непрерывно увеличиваются. Следовательно, производительность увеличится уже благодаря обновлению оборудования. Чтобы всегда иметь современное оборудование, возможно даже имеет смысл брать его в аренду.
Когда оборудование установлено, можно создать новый виртуальный сервер SQL Server и скопировать на него производственные базы данных, а затем подвергнуть новую систему всестороннему испытанию, чтобы устранить возможные неполадки до наступления срока переброски сервера. При этом следует обязательно создать сценарии для переноса учетных записей пользователей с существующего сервера на новый. (См. статью support.microsoft.com/kb/246133 (на английском языке). Также имеет смысл обновить сценарий построения учетных записей на случай внезапного полного отказа.)
Для сведения к минимуму времени простоя скорее всего потребуется использовать доставку журналов, за исключением случаев, когда базы данных очень маленькие и есть период времени, когда ни один пользователь не подключен. Доставку журналов можно выполнить непосредственно перед переброской. Затем следует отсоединить пользователей, вырезать и доставить окончательный журнал и указать приложению на новый экземпляр. (Ниже, в разделе о зеркальном отражении баз данных, рассказывается об интересной альтернативе доставке журналов.) Если используются DNS-псевдонимы, то, скорее всего, даже не придется указывать приложениям на новый экземпляр. Вместо этого нужно будет просто обновить DNS-псевдоним. Такой подход имеет следующее преимущество: в случае необходимости остановки процесса миграции на полпути и возвращения в исходное состояние это исходное состояние, по крайней мере, будет в наличии.
Можно выбрать менее дорогостоящий вариант, но он потребует более сложного предварительного планирования. Кластер может поддерживать более одного экземпляра сервера SQL Server, но каждый экземпляр должен иметь собственные дисковые ресурсы. Поэтому при организации сети области хранения данных (SAN) следует зарезервировать один номер логического устройства (LUN) для будущих обновлений. Чтобы выполнить обновление, следует установить двоичные файлы сервера SQL Server на этом дисковом ресурсе. Далее следует провести испытания системы и, когда все будет готово, завершить работу текущего сервера SQL Server, переместить дисковые ресурсы из старой группы SQL Server, обновить зависимости и перевести новый экземпляр сервера SQL Server в оперативный режим. Далее нужно присоединить базы данных из старого экземпляра, и можно считать операцию выполненной. (Вы же создали резервные копии заранее, не так ли?)
Этот подход требует меньших затрат, но и несет с собой долю риска. Если что-то пойдет не так, отсоединить базы данных от нового экземпляра и вернуть их на прежнее место будет уже невозможно. В этом случае восстановление возможно только из резервных копий, а это может привести к длительному простою.
Как вариант, можно поместить два экземпляра сервера SQL Server в сеть области хранения, если в ней достаточно места. Далее следует восстановить производственные резервные копии (и доставить журналы) на новый экземпляр сервера и продолжить приблизительно так же, как описано выше. Однако теперь есть пути для отступления. По окончании миграции можно освободить ресурсы сети области хранения от старого экземпляра. Стоимость этого действия будет равна только цене новых дисков.

Балансировка нагрузки
Для начала опровергнем одно распространенное заблуждение. Кластеризация MSCS используется для повышения уровня доступности, а не для балансировки нагрузки. Кроме того, сервер SQL Server не имеет встроенной возможности автоматической балансировки нагрузки. Балансировать нагрузку необходимо посредством физического проектирования приложения. Что это значит?
С ростом размеров таблицы следует ожидать ухудшения быстродействия, в частности, при сканировании таблицы. Когда количество строк достигает миллионов и миллиардов, обычным решением до сих пор являлось использование секционированных представлений. Эти секционированные представления состоят из таблиц с одинаковыми схемами, объединенных с помощью инструкций UNION ALL. Кроме того, для различения таблиц-компонентов устанавливаются проверочные ограничения (инструкция CHECK), что предотвращает дупликацию данных в секционированном представлении. Если столбец, используемый в проверочном ограничении, является частью первичного ключа, то представление является обновляемым.
Если таблицы-компоненты расположены на отдельных файловых группах, то для повышения быстродействия дисковой подсистемы можно распределить файлы этих файловых групп по разным физическим дискам. Можно даже размещать таблицы в разных базах данных. Однако размещение всех данных в одной базе данных позволяет использовать возможности секционирования таблиц, предоставляемые сервером SQL Server 2005. Реализовать такое секционирование значительно проще.
Но допустим, что уже испробованы все возможности секционирования таблиц или создания (локальных) секционированных представлений, а быстродействие все равно не на высоте. Если вы пользуетесь сервером SQL Server 2000 или SQL Server 2005, можно воспользоваться распределенными секционированными представлениями. Основное их отличие заключается в том, что таблицы-компоненты могут располагаться на разных экземплярах сервера SQL Server, и эти экземпляры могут быть установлены на кластере с конфигурацией «N+1». В чем же смысл такого решения? Если таблица-компонент в секционированном представлении становится недоступной, недоступным становится и всё представление. Если же сделать эти таблицы-компоненты частью кластера, это предоставит стабильность, необходимую для обеспечения быстродействия и балансировки нагрузки.

А так ли нужен кластер?
Возможно, у вас есть несколько лишних серверов, но они отсутствуют в разделе кластеров Каталога Windows. Не хотелось бы покупать новые серверы только для поддержки кластера, когда есть свободные серверы.
Заманчивой альтернативой кластеризации является зеркальное отражение баз данных. Для зеркального отражения необходимо три компонента: экземпляр, в котором размещена отражаемая база данных (основной сервер), резервный (зеркальный) сервер и, если требуется автоматический переход на резервный ресурс, третий (следящий) сервер. В двух словах, при зеркальном отражении базы данных происходит следующее: транзакция в базе данных на основном сервере запускается также и на зеркале. Если на основном сервере происходит сбой, возможен переход базы данных на резервный ресурс – зеркальный сервер. При наличии следящего сервера это произойдет автоматически. Зеркальное отражение необходимо настраивать для каждой базы данных вашего приложения; для системных баз данных зеркальное отражение недоступно.
В отличие от кластера, зеркальный сервер – это отдельный экземпляр SQL Server; он может быть расположен на расстоянии тысяч километров от основного сервера. Его кэши наполняются посредством действий по обновлению, которые происходят в результате транзакций, дуплицируемых с основного сервера. Разумеется, предполагается, что на зеркальном сервере не происходит никаких действий кроме получения зеркально отраженных транзакций с основного сервера. Переход на резервный ресурс в этом случае, как правило, происходит быстрее, чем в кластере, так как на зеркальном сервере SQL Server уже запущен. Поскольку кэши уже заполнены (по крайней мере, частично), начальное быстродействие не такое низкое, как в сценарии с кластером. Также следует иметь в виду, что когда на отраженной базе данных происходит переход на резервный ресурс, основной и зеркальный серверы меняются ролями.
Недостатком зеркального отражения баз данных является потребность в удвоенной емкости дисков по сравнению с кластером. Также необходимо больше вычислительных мощностей, если нужен синхронный режим без потери данных. Как уже говорилось, высокая доступность не бывает дешевой.

Комбинированный подход
Так как зеркальный сервер может быть расположен на большом расстоянии от основного, зеркальное отражение имеет смысл использовать в планах аварийного восстановления (DR – Disaster Recovery). Кластер может служить первой линией обороны, но что случится, если применить одновременно и кластеризацию, и зеркальное отражение? Когда происходит переход на резервный ресурс в кластере, то при наличии в конфигурации зеркального отражения следящего сервера последний становится основным на то время, пока кластеризованный сервер SQL Server возвращается в оперативный режим. Однако следует иметь в виду, что переход на резервный ресурс с нового основного сервера обратно на (кластеризованный) новый зеркальный сервер не происходит автоматически. Следовательно, лучше не включать автоматический переход на резервный ресурс для зеркально отражаемых баз данных при использовании совместно с кластером.
Аварийное восстановление – не единственная цель использования зеркального отражения. Это также полезно в ситуации, когда необходимо применить пакет обновлений или исправление на основном сервере; в этом случае можно вручную выполнить переход на резервный ресурс на зеркальный сервер. При применении пакета обновлений или исправления бывший основной сервер временно переводится в автономный режим, а завершенные транзакции, выполненные на новом основном сервере, становятся в очередь, ожидая отправления назад на новый зеркальный (бывший основной) сервер. По окончании установки пакета обновлений или исправления происходит синхронизация, в результате которой два сервера приводятся в полное соответствие. Теперь можно поменять основной и зеркальный серверы ролями. Время простоя составляет несколько секунд, потраченных на переход на резервный ресурс и обратно. Этот подход можно также использовать для миграции сервера SQL Server на другой физический сервер. Отличие только в том, что не нужно переходить обратно.

Повышение гибкости с помощью виртуального сервера
Виртуализация позволяет одновременно запускать одну или более операционных систем на одном физическом сервере. Программное обеспечение виртуализации вносит в концепцию кластеризации дополнительный уровень возможностей, позволяя кластеризовать программы. Если происходит сбой на сервере, на котором запущена ведущая операционная система, этот сервер вместе с гостевыми операционными системами переходит на резервный узел. Таким способом можно легко мигрировать гостевой сервер. Кроме того, гостевая операционная система может не поддерживать кластеризацию. Следовательно, можно запустить сервер SQL Server выпуска Workgroup Edition на гостевой операционной системе Windows Server 2003, запущенной на сервере Microsoft Virtual Server 2005 в кластере. Таким образом, фактически происходит опосредованная кластеризация сервера SQL Server выпуска Workgroup Edition (см. рис. 2).
Figure 2 Using a virtual server
Figure 2 Using a virtual server (Щелкните изображение, чтобы уменьшить его)
Figure 2 Using a virtual server
Figure 2 Using a virtual server (Щелкните изображение, чтобы увеличить его)

Владение ситуацией
Администратору, отвечающему за внедрение сервера SQL Server, нужно быть уверенным в непрерывной доступности сервера. Достичь этой цели помогает применение кластеризации сервера. В этой статье предложены проверенные опытом рекомендации, помогающие начать работу. Дополнительные полезные сведения можно найти на врезке «Ресурсы по кластеризации».
Ресурсы по кластеризации
Подробнее об описанных здесь методах и различных продуктах, необходимых для настройки кластера серверов SQL Server, см. статьи по следующим ссылкам:
  • Кластеризация для обеспечения отказоустойчивости серверов SQL Server 2005(на англ. языке)
  • Кластеризация для обеспечения отказоустойчивости серверов SQL Server 2000(на англ. языке)
  • Выпуск Windows Server 2003 R2 Enterprise Edition – сервер кластеров(на англ. языке)
  • Руководство администратора сервера кластеров Microsoft(на англ. языке)
  • Сервер Microsoft Virtual Server 2005 R2(на англ. языке)

Том Моро (Tom Moreau), обладатель ученых степеней BSc, PhD и сертификатов MCSE и MCDBA – независимый консультант, специализирующийся на администрировании, проектировании и реализации баз данных SQL Server, проживающий вблизи Торонто. Том Моро использует SQL Server с 1993 года, а с 2001 года имеет статус MVP. Он – автор более 100 статей и соавтор книги по SQL Server. Автор выражает благодарность Джеффу Хитену (Geoff Hiten), обладателю статуса SQL Server MVP, за ценный вклад в написание этой статьи.


 Администрирование Windows: Внутреннее устройство ядра Windows Vista: часть 2
Администрирование Windows Марк Руссинович

Внутреннее устройство ядра Windows Vista: часть 2
Краткий обзор:
  • Управление памятью
  • Запуск и завершение работы
  • Управление электропитанием

Месяц назад, в первом из трех выпусков, были рассмотрены усовершенствования ядра ОС Windows Vista в области управления процессами и в подсистеме ввода-вывода.
В этом выпуске мы познакомимся с нововведениями ОС Windows Vista в области управления памятью, а также с главными усовершенствованиями в области запуска системы, завершения работы и управления электропитанием (часть 1).
С каждым новым выпуском ОС Windows® повышается масштабируемость и производительность системы. ОС Windows Vista ™ не является исключением. Диспетчер памяти ОС Windows Vista содержит множество нововведений, в том числе более широкое использование методов синхронизации без блокировок, улучшенная гранулярность блокировки, более плотная упаковка структур данных, увеличенный размер страниц операций ввода-вывода, поддержка архитектур памяти современных графических процессоров и более эффективное использование аппаратного буфера ассоциативной трансляции (TLB). Помимо этого диспетчер памяти в Windows Vista поддерживает динамическое выделение адресного пространства для меняющейся рабочей нагрузки.
В ОС Windows Vista впервые представлены четыре новые технологии увеличения производительности: SuperFetch, ReadyBoost, ReadyBoot и ReadyDrive. Они будут подробно рассмотрены далее в этой статье.

Динамическое адресное пространство ядра
ОС Windows и приложения, выполняемые под ее управлением, сталкиваются с ограничениями адресного пространства 32-разрядных процессоров. Размер адресного пространства ядра ОС Windows по умолчанию ограничен значением 2 Гбайт (половина 32-разрядного виртуального адресного пространства). Вторая половина зарезервирована для использования процессом, выполняющимся в текущий момент на ЦП. На свою половину памяти ядро должно отобразить себя, драйверы устройств, кэш файловой системы, стеки ядра, структуры данных кода для каждого сеанса, а также невыгружаемые (заблокированные в физической памяти) и выгружаемые буферы, выделенные драйверами устройств. В операционных системах, предшествовавших ОС Windows Vista, диспетчер памяти распределял адресные пространства для перечисленных нужд в момент загрузки системы. Этот негибкий механизм приводил иногда к ситуациям, когда некоторые области адресного пространства оказывались исчерпанными, в то время как в других еще оставалось много свободного места. Нехватка адресного пространства в одной из областей может привести к сбоям в работе приложений и нарушить операции ввода-вывода, выполняемые драйверами устройств.
В 32-разрядной версии ОС Windows Vista диспетчер памяти динамически распределяет адресное пространство ядра, выделяя и освобождая адресное пространство с учетом потребностей текущей рабочей нагрузки. Таким образом, количество виртуальной памяти, используемое для хранения выгружаемых буферов, может увеличиваться, когда этого требуют драйверы устройств, и уменьшаться, когда драйверы устройств освобождают память. Это позволяет ОС Windows Vista поддерживать более широкий диапазон рабочих нагрузок, а 32-разрядная версия следующего выпуска ОС Windows Server® (кодовое название «Longhorn») сможет поддерживать больше одновременно работающих пользователей сервера терминалов.
Конечно, в 64-разрядной версии ОС Windows Vista пределы адресных пространств не представляют практических ограничений, поэтому они не требуют каких-либо особых мер и установлены на максимальные значения.

Приоритеты памяти
Помимо приоритетов ввода-вывода (которые обсуждались в предыдущем выпуске), в ОС Windows Vista появились также и приоритеты памяти. Чтобы понять, как система использует приоритеты памяти, нужно разобраться, как в диспетчере памяти реализован кэш памяти, называемый списком ожидания (Standby List). Во всех версиях ОС Windows, предшествовавших Windows Vista, физическая страница, затребованная системой у приложения (размер страницы обычно составляет 4 Кбайт), помещалась диспетчером памяти в конец списка ожидания. Если процессу снова требовался доступ к этой странице, диспетчер памяти извлекал ее из списка ожидания и вновь назначал процессу. Если процессу требовалась новая страница физической памяти, но свободной памяти не было, диспетчер памяти отдавал процессу страницу из начала списка ожидания. В такой схеме все страницы в списке ожидания были равнозначны, и порядок страниц определялся только временем их помещения в список.
В ОС Windows Vista каждая страница памяти имеет приоритет от 0 до 7, и диспетчер памяти разделяет список ожидания на 8 списков, в каждом из которых хранятся страницы с соответствующим приоритетом. Если диспетчеру памяти нужно забрать страницу из списка ожидания, первыми будут извлекаться страницы из списков с более низким приоритетом. Приоритет страницы обычно совпадает с приоритетом потока, который первым вызвал выделение этой страницы. (Приоритет страницы с совместным доступом соответствует наивысшему приоритету памяти среди потоков, совместно использующих эту страницу). Поток наследует значение приоритета памяти от процесса, которому он принадлежит. Диспетчер памяти назначает низкий приоритет для страниц, которые он считывает с диска, когда предвидится обращение процесса к памяти.
По умолчанию значение приоритета памяти процессов равняется 5, но приложения и система могут менять значения приоритетов памяти для процессов и потоков. Реальная выгода от использования приоритетов памяти становится понятной, если рассматривать систему относительных приоритетов страниц на более высоком уровне, а именно на уровне функции SuperFetch.

Функция SuperFetch
Среди существенных изменений в работе диспетчера памяти – изменение способа управления физической памятью. У способа управления на основе списка ожидания, который использовался в предыдущих версиях ОС Windows, есть два ограничения. Во-первых, приоритет страниц определяется только на основании предшествующего поведения процессов без предсказания возможных будущих требований процессов к памяти. Во-вторых, определение приоритета осуществляется только на основании списка страниц памяти, которыми процесс владеет в конкретный момент времени. Эти недостатки могут привести к таким последствиям, как «послеобеденный синдром», когда пользователь оставляет на некоторое время свое рабочее место, и на компьютере запускается системное приложение, интенсивно работающее с памятью (например, выполняется сканирование диска антивирусом или производится дефрагментация диска). Работа такого приложения приводит к тому, что данные пользовательских приложений, которые находились в кэше, оказываются перезаписанными. Вернувшись на рабочее место, пользователь в течение некоторого времени страдает от низкой производительности, поскольку приложения запрашивают свои данные и код с диска.
В ОС Windows XP была реализована поддержка упреждающего чтения, благодаря которой происходила более быстрая загрузка системы и запуск приложений. В память заранее загружались данные, к которым предположительно будет требоваться доступ. Такое решение принималось на основании истории предыдущих загрузок системы и запусков приложений. Функция SuperFetch в ОС Windows Vista является существенным развитием схемы управления памятью, поскольку, помимо статистики недавнего доступа, она учитывает историю обращений к памяти за длительный период и проактивное управление памятью.
Функция SuperFetch реализована в библиотеке %SystemRoot%\System32\Sysmain.dll; она выполняется в качестве службы Windows внутри процесса Service Host (%SystemRoot%\System32\Svchost.exe). Благодаря поддержке со стороны диспетчера памяти эта схема позволяет службе получать историю обращений к страницам памяти и отдавать диспетчеру памяти указания по предварительной загрузке данных или кода из файлов на диске или из файла подкачки в список ожидания, а также присваивать приоритет страницам памяти. Служба SuperFetch существенно расширяет отслеживание страниц памяти, учитывая страницы, которые были ранее загружены в память, но впоследствии освобождены диспетчером памяти для других данных и кода. Эта информация хранится в папке %SystemRoot%\Prefetch в виде файлов сценариев с расширением «.db» вместе со стандартными файлами упреждающего чтения, используемыми для оптимизации запуска приложений. Располагая подробной информацией об использовании памяти, служба SuperFetch может осуществлять предварительную загрузку данных и кода при освобождении физической памяти.
Когда освобождается память (например, при завершении работы приложения или когда приложение освобождает выделенную память), служба SuperFetch дает диспетчеру памяти инструкцию загрузить недавно выгруженные данные и код. Эта процедура осуществляется со скоростью в несколько страниц в секунду с приоритетом ввода-вывода «Very Low» (очень низкий), поэтому предварительная загрузка не мешает работе пользовательских и других активных приложений. Благодаря этому, когда пользователь оставляет свое рабочее место на время обеденного перерыва, и фоновые задачи, интенсивно работающие с памятью, приводят к выгрузке страниц памяти активных пользовательских приложений, службе SuperFetch зачастую удается вернуть большинство страниц в память еще до того, как пользователь вернется на рабочее место. У службы SuperFetch есть также специальные сценарии поддержки гибернации, ждущего режима, быстрого переключения пользователей (FUS) и запуска приложений. Например, когда система переходит в режим гибернации, служба SuperFetch сохраняет в файле гибернации данные и код, доступ к которым вероятнее всего потребуется после загрузки системы, с учетом истории предыдущих переходов в режим гибернации. В случае возобновления работы ОС Windows XP из режима гибернации при обращении к данным, находившимся в кэше до перехода в режим гибернации, необходимо было заново считывать эти данные с диска.
На врезке «Наблюдение за службой SuperFetch» представлены краткие результаты влияния службы SuperFetch на объем доступной памяти.
Наблюдение за службой SuperFetch
После работы в течение некоторого времени в ОС Windows Vista пользователь может заметить, что на вкладке «Быстродействие» диспетчера задач показатель свободной физической памяти становится невысоким. Это объясняется тем, что служба SuperFetch и стандартное кэширование Windows используют всю доступную физическую память для кэширования данных с диска. Например, если сразу после загрузки системы открыть диспетчер задач, можно заметить, что показатель свободной памяти уменьшается, в то время как показатель кэшированной памяти увеличивается. Если запустить приложение, использующее для работы большой объем памяти, а затем завершить его работу (подойдет любой бесплатный «оптимизатор памяти», который выделяет большое количество памяти и затем освобождает ее), или просто скопировать очень большой файл, показатель свободной памяти возрастет, и на графике использования физической памяти будет наблюдаться падение по мере того, как в систему возвращается освобожденная память. Однако через некоторое время служба SuperFetch снова заполнит кэш данными, которые были вытеснены из памяти, и показатель кэшированной памяти возрастет, а показатель свободной памяти уменьшится.
Watching memory
Watching memory (Щелкните изображение, чтобы уменьшить его)
Watching memory
Watching memory (Щелкните изображение, чтобы увеличить его)

Функция ReadyBoost
Скорость работы ЦП и памяти гораздо выше скорости работы жесткого диска, из-за чего жесткие диски часто являются узким местом для производительности системы. Операции произвольного дискового ввода-вывода особенно сильно влияют на производительность, потому что время позиционирования головок жестких дисков (порядка 10 мс) – это вечность для современных процессоров с тактовой частотой 3 ГГц. Хотя оперативная память идеально подходит для кэширования дисковых данных, ее стоимость сравнительно высока. Флэш-память обычно дешевле оперативной памяти, при этом время произвольного доступа у флэш-памяти может быть на порядок меньше, чем у жесткого диска. Поэтому в ОС Windows Vista добавлена функция под названием ReadyBoost, которая позволяет воспользоваться преимуществами запоминающих устройств на основе флэш-памяти, создавая на них промежуточный уровень кэширования, логически расположенный между оперативной памятью и жесткими дисками.
Функция ReadyBoost состоит из службы, реализованной в файле %SystemRoot%\System32\Emdmgmt.dll, которая выполняется в процессе Service Host, и драйвера фильтра томов %SystemRoot%\System32\Drivers\Ecache.sys (EMD – это сокращение от рабочего названия функции ReadyBoost «External Memory Device» (внешнее устройство памяти), которое использовалось в процессе ее разработки). При подключении запоминающего устройства флэш-памяти к компьютеру служба ReadyBoost определяет производительность этого устройства и записывает результат в раздел реестра HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt, как показано на рис. 1.
Figure 1 ReadyBoost device test results in the registry
Figure 1 ReadyBoost device test results in the registry (Щелкните изображение, чтобы уменьшить его)
Figure 1 ReadyBoost device test results in the registry
Figure 1 ReadyBoost device test results in the registry (Щелкните изображение, чтобы увеличить его)
Если объем памяти устройства от 256 МБ до 32 ГБ, скорость передачи для произвольных операций чтения блоками по 4 КБ превышает 2,5 МБ/с, скорость передачи для произвольных операций записи блоками по 512 КБ превышает 1,75 МБ/с, и это устройство еще не используется для кэширования, служба ReadyBoost предложит выделить до 4 ГБайт памяти этого устройства для кэширования дисков. (Хотя служба ReadyBoost может работать с разделами NTFS, максимальный объем кэша ограничен 4 ГБ для совместимости с файловой системой FAT32). Если пользователь соглашается, служба создает в корневой папке устройства файл кэша с именем ReadyBoost.sfcache и отдает службе SuperFetch указание заполнить кэш в фоновом режиме.
После инициализации кэширования службой ReadyBoost драйвер устройства Ecache.sys перехватывает все обращения чтения и записи к локальным жестким дискам (например, диску C:\) и копирует записываемые данные в созданный службой файл кэширования. Драйвер Ecache.sys осуществляет сжатие данных, достигая обычно степени сжатия 2:1, поэтому кэш объемом 4 ГБ, как правило, содержит около 8 ГБ данных. Драйвер шифрует каждый записываемый блок с помощью ключа сеанса, генерируемого случайным образом при каждой загрузке системы; при этом используется алгоритм AES. Шифрование обеспечивает конфиденциальность данных, содержащихся в кэше, на случай извлечения устройства.
Если служба ReadyBoost определяет, что осуществляется произвольное чтение данных, и эти данные есть в кэше, данные извлекаются из кэша. Но ввиду того, что у жестких дисков скорость последовательного чтения выше, чем у флэш-памяти, операции последовательного чтения осуществляются непосредственно с диска, даже если эти данные есть в кэше.

Функция ReadyBoot
Если в системе установлено менее 512 МБ оперативной памяти, механизм упреждающего чтения при загрузке ОС Windows Vista не отличается от механизма, использовавшегося при загрузке ОС Windows XP. Если же размер оперативной памяти превышает 700 МБ, то для оптимизации процесса загрузки используется кэш в ОЗУ. Размер этого кэша зависит от общего объема доступной памяти; он достаточно велик, чтобы обеспечить эффективное кэширование, но оставляет при этом достаточно свободной памяти для нормального выполнения процедуры загрузки системы.
После каждой загрузки системы служба ReadyBoost (та же самая служба, которая реализует описанную выше функцию ReadyBoost) в моменты простоя ЦП планирует кэширование для следующей загрузки системы. Она анализирует информацию об обращениях к файлам за пять предыдущих загрузок и определяет, к каким файлам производились обращения, и где эти файлы расположены на диске. Обработанная информация об обращениях сохраняется в папке %SystemRoot%\Prefetch\Readyboot в виде файлов с расширением «.fx», а план кэширования сохраняется в разделе реестра HKLM\System\CurrentControlSet\Services\Ecache\Parameters в виде значений типа REG_BINARY с именами, соответствующими именам внутренних дисков.
Кэширование реализуется с помощью того же драйвера, что и в функции ReadyBoost (драйвер Ecache.sys), но управление заполнением кэша во время загрузки осуществляется службой ReadyBoost. Хотя кэш загрузки сжимается так же, как и кэш ReadyBoost, есть еще одно отличие между управлением кэшем в функциях ReadyBoost и ReadyBoot. В отличие от функции ReadyBoost, в режиме ReadyBoot содержимое кэша не изменяется при операциях чтения и записи, а определяется только обновлениями, вносимыми службой ReadyBoost. Служба ReadyBoost удаляет кэш через 90 секунд после начала загрузки или в случае, если требуется дополнительная оперативная память. Статистика использования кэша записывается в раздел реестра HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats, как показано на рис. 2. Измерение производительности, проведенное в корпорации Майкрософт, показало, что при использовании функции ReadyBoot производительность увеличивается примерно на 20 процентов по сравнению с технологией упреждающего чтения, используемой при загрузке ОС Windows XP.
Figure 2 ReadyBoot Performance statistics
Figure 2 ReadyBoot Performance statistics (Щелкните изображение, чтобы уменьшить его)
Figure 2 ReadyBoot Performance statistics
Figure 2 ReadyBoot Performance statistics (Щелкните изображение, чтобы увеличить его)

Функция ReadyDrive
ReadyDrive – это функция ОС Windows Vista, использующая возможности новых гибридных жестких дисков (дисков H-HDD). Гибридный жесткий диск представляет собой жесткий диск со встроенной энергонезависимой флэш-памятью (известной также под названием NVRAM). Как правило, гибридные жесткие диски содержат от 50 МБ до 512 МБ кэш-памяти, но ОС Windows Vista поддерживает кэши размером до 2 ТБ.
Чтобы определить, какие данные следует поместить во флэш-память, ОС Windows Vista использует команды ATA-8. Например, при завершении работы система сохраняет в этом кэше данные для загрузки, что позволяет ускорить следующий запуск системы. При переходе в режим гибернации в кэше сохраняются некоторые части файла гибернации, что ускоряет возобновление работы. Поскольку кэш активен даже когда диск остановлен, система может использовать флэш-память для кэширования записи на диск, что позволяет не раскручивать диск, если компьютер питается от аккумулятора. Остановка диска позволяет существенно снизить энергопотребление по сравнению с обычным режимом работы.

База данных конфигурации загрузки
В ОС Windows Vista усовершенствовано несколько аспектов процедур загрузки и завершения работы. Улучшение процедуры загрузки достигается благодаря следующим нововведениям: использование базы данных конфигурации загрузки (BCD), в которой хранится конфигурация запуска системы и ОС; новая последовательность и организация процесса загрузки системы; новая архитектура входа в систему, а также поддержка служб с отложенным автозапуском. Усовершенствования процесса завершения работы в ОС Windows Vista включают уведомление служб Windows перед завершением работы, упорядочение завершения работы служб и существенно переработанное управление переходами между режимами энергопотребления в операционной системе.
Одним из самых заметных изменений процесса загрузки системы является отсутствие файла Boot.ini в корневой папке системного тома. Это объясняется тем, что конфигурация загрузки, которая раньше хранилась в этом файле, теперь хранится в базе данных BCD. Одной из причин использования базы данных BCD в ОС Windows Vista является объединение двух поддерживаемых в ОС Windows архитектур загрузки: основной загрузочной записи (MBR) и расширяемого интерфейса микропрограмм (EFI). Загрузочная запись MBR обычно используется на компьютерах с архитектурами x86 и x64, а интерфейс EFI – в системах Itanium (хотя в ближайшем будущем, вероятно, будут поставляться и рабочие станции с поддержкой EFI). Использование базы данных BCD позволяет абстрагироваться от микропрограмм и обеспечивает ряд дополнительных преимуществ по сравнению с использованием файла Boot.ini, например поддержку строк в формате Юникод и поддержку исполнения альтернативных предзагрузочных программ.
Фактически база данных BCD хранится на диске в кусте реестра, загружаемом в реестр ОС Windows для доступа с помощью программных интерфейсов реестра. На платформах PC она хранится в файле \Boot\Bcd на системном томе. На системах EFI база данных хранится в системном разделе EFI. После загрузки куста он появляется в разделе реестра HKLM\Bcd00000000. Внутренний формат этой базы данных не документируется, поэтому для ее редактирования используются специальные инструменты, например программа %SystemRoot%\System32\Bcdedit.exe. Для поддержки сценариев и специализированных редакторов доступны интерфейсы для управления базой данных BCD с помощью инструментария WMI. Изменять и добавлять основные параметры, такие как команды отладки ядра, можно также с помощью программы настройки системы (%SystemRoot%\System32\Msconfig.exe).
Параметры загрузки, относящиеся ко всей платформе, например выбор ОС по умолчанию и время задержки меню загрузки, отделены в базе данных BCD от параметров, относящихся к конкретным операционным системам, таких как параметры загрузки ОС и путь к системному загрузчику. Если запустить программу Bcdedit без параметров командной строки, сперва в разделе «Windows Boot Manager» будут выведены параметры, относящиеся к платформе, а затем в разделе «Windows Boot Loader» – параметры для конкретной ОС, как показано на рис. 3.
Figure 3 Settings displayed in BCDEdit
Figure 3 Settings displayed in BCDEdit (Щелкните изображение, чтобы уменьшить его)
Figure 3 Settings displayed in BCDEdit
Figure 3 Settings displayed in BCDEdit (Щелкните изображение, чтобы увеличить его)
Во время загрузки установленной ОС Windows Vista новая схема загрузки разделяет задачи, выполнявшиеся в более ранних версиях ОС Windows одним системным загрузчиком Ntldr, между двумя программами – \BootMgr и %SystemRoot%\System32\Winload.exe. Программа BootMgr считывает базу данных BCD и отображает меню загрузки операционной системы, а программа Winload.exe осуществляет загрузку операционной системы. При «чистой» загрузке системы программа Winload.exe загружает драйверы устройств, необходимые для запуска системы, и основные файлы операционной системы, включая ядро Ntoskrnl.exe, а затем передает управление операционной системе. В случае возобновления работы из режима гибернации программа Winload.exe запускает программу %SystemRoot%\System32\Winresume.exe для загрузки данных из файла гибернации в оперативную память и возобновления работы ОС.
Загрузчик Bootmgr также поддерживает исполнение дополнительных предзагрузочных программ. В составе ОС Windows Vista поставляется программа диагностики оперативной памяти (\Boot\Memtest.exe), которая уже включена в меню загрузки. Сторонние разработчики могут добавлять собственные предзагрузочные программы, которые будут отображаться в меню загрузки Bootmgr.

Процесс загрузки системы
В предыдущих версиях ОС Windows взаимосвязь между различными системными процессами не была очевидной. Например, в процессе загрузки системы диспетчер интерактивного входа в систему (%SystemRoot%\System32\Winlogon.exe) запускал службу подсистемы локального администратора безопасности (Lsass.exe) и диспетчер управления службами (Services.exe). Далее система использовала контейнер пространств имен (сеанс) для изоляции процессов, запущенных в различных сеансах входа в систему. Однако в операционных системах, предшествовавших ОС Windows Vista пользователь, вошедший в консоль, использовал сеанс 0, в котором работают и системные процессы. Это создавало потенциальную угрозу для безопасности. Примером такой угрозы стала одна плохо написанная служба Windows, работавшая в сеансе 0 и отображавшая пользовательский интерфейс в интерактивной консоли, позволяя вредоносным программам атаковать окно этой службы методом «подрывной атаки» (shatter attack), получая административные привилегии.
Для устранения подобных проблем в ОС Windows Vista было реструктурировано несколько системных процессов. Диспетчер сеансов (Smss.exe) – это первый процесс пользовательского режима, запускаемый во время загрузки, как и в предыдущих версиях ОС Windows. Однако в ОС Windows Vista диспетчер сеансов запускает еще одну свою копию для настройки сеанса 0, который выделен исключительно для системных процессов. Процесс диспетчера сеансов для сеанса 0 запускает приложение инициализации Windows (Wininit.exe), процесс подсистемы Windows (Csrss.exe) для сеанса 0, а затем завершает свою работу. Далее приложение инициализации Windows запускает диспетчер управления службами, подсистему локального администратора безопасности и новый процесс – диспетчер локальных сеансов (Lsm.exe), который управляет сеансами терминального сервера на этом компьютере.
Когда пользователь входит в систему, первоначально запущенный диспетчер сеансов запускает еще одну свою копию для настройки нового сеанса. Вновь запущенный процесс Smss.exe запускает процесс подсистемы Windows и процесс Winlogon для нового сеанса. На рабочей станции запуск диспетчером сеансов собственных копий для инициализации каждого нового сеанса не дает никаких преимуществ. Но в случае работы на сервере Windows Server «Longhorn», выступающем в роли терминального сервера, копии диспетчера будут работать одновременно, обеспечивая более быстрый вход в систему нескольких пользователей.
В новой архитектуре все системные процессы, включая службы Windows, изолированы в сеансе 0. Если служба Windows, запущенная в сеансе 0, отображает пользовательский интерфейс, служба обнаружения интерактивных служб (%SystemRoot%\System32\UI0Detect.exe) запускает собственную копию в контексте безопасности любого выполнившего вход администратора и выводит сообщение, показанное на рис. 4. Если администратор принимает предложение просмотреть сообщение, служба выполняет переключение рабочего стола на рабочий стол служб Windows, где администратор получает доступ к пользовательскому интерфейсу службы, а затем переключается назад на свой рабочий стол. На врезке «Просмотр отношений между процессами загрузки» можно более подробно ознакомиться с тем, что происходит во время загрузки системы.
Figure 4 Service has displayed a window
Figure 4 Service has displayed a window (Щелкните изображение, чтобы уменьшить его)
Figure 4 Service has displayed a window
Figure 4 Service has displayed a window (Щелкните изображение, чтобы увеличить его)
Просмотр отношений между процессами загрузки
Для просмотра дерева загрузки процессов ОС Windows Vista можно воспользоваться программой Process Explorer от компании Sysinternals (microsoft.com/technet/sysinternals).
На снимке экрана присутствует столбец Session (Сеанс), который можно добавить с помощью диалогового окна выбора столбцов в программе Process Explorer. Выделен первоначальный процесс Smss.exe. Ниже него в сеансе 0 находятся процессы Csrss.exe и Wininit.exe, выровненные по левому краю, потому что их родительский процесс, экземпляр процесса Smss.exe, выполнивший настройку сеанса 0, завершил свою работу. Три дочерних процесса, порожденные процессом Wininit.exe – Services.exe, Lsass.exe и Lsm.exe.
Также в программе Process Explorer виден ряд процессов, запущенных в сеансе 1. Это сеанс, вход в который выполнен пользователем с помощью подключения к удаленному рабочему столу. Процессы, запущенные в рамках одной учетной записи с программой Process Explorer, выделены синим цветом. Наконец, сеанс 2 был инициализирован для подготовки к консольному входу пользователя в систему и созданию нового сеанса входа. Именно в этом сеансе запущен процесс Winlogon, использующий процесс LogonUI, чтобы предложить пользователю нажать сочетание клавиш Ctrl+Alt+Delete для входа в систему, и в которой процесс Logonui.exe затем попросит пользователя ввести свои учетные данные.
Startup process and session information
Startup process and session information (Щелкните изображение, чтобы уменьшить его)
Startup process and session information
Startup process and session information (Щелкните изображение, чтобы увеличить его)

Поставщики учетных данных
Архитектура процесса входа в систему также поменялась в ОС Windows Vista. В предыдущих версиях ОС Windows процесс Winlogon загружал указанную в реестре динамическую библиотеку GINA, которая отображала пользовательский интерфейс для входа в систему, запрашивающий у пользователей ввод учетных данных. К сожалению, в модели GINA есть ряд ограничений: может быть использована только одна библиотека GINA; разработка полнофункциональной библиотеки GINA сложна для сторонних разработчиков; сторонние библиотеки GINA с нестандартным пользовательским интерфейсом меняют привычное взаимодействие с пользователем.
Вместо модели GINA в ОС Windows Vista используется архитектура поставщиков учетных данных. Процесс Winlogon запускает отдельный процесс – сервер пользовательского интерфейса входа в систему (Logonui.exe), который выполняет загрузку поставщиков учетных данных, настроенных в разделе реестра HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers. Процесс Logonui может работать с несколькими поставщиками учетных данных одновременно. ОС Windows Vista поставляется с двумя поставщиками учетных данных: интерактивным поставщиком (Authui.dll) и поставщиком смарт-карт (Smart-cardcredentialprovider.dll). Для унификации взаимодействия с пользователем процесс LogonUI управляет пользовательским интерфейсом, который видят конечные пользователи. Он также позволяет поставщикам учетных данных добавлять собственные отображаемые элементы, такие как текст, значки и поля ввода.

Службы с отложенным автозапуском
Пользователь, выполнивший вход в систему сразу после ее запуска, как правило, сталкивается с некоторой задержкой, прежде чем завершится настройка рабочего стола и можно будет свободно взаимодействовать с оболочкой системы и запускаемыми приложениями. Это происходит из-за того, что во время входа пользователя в систему диспетчер управления службами запускает множество служб Windows, настроенных как службы с автоматическим запуском и активируемые в процессе загрузки системы. Многие службы при инициализации выполняют операции, интенсивно потребляющие вычислительные и дисковые ресурсы, что приводит к замедлению процессу входа пользователя в систему. Для борьбы с этой проблемой в ОС Windows Vista введен новый тип запуска служб – отложенный автоматический запуск. Этот режим могут использовать службы, которые не обязаны быть активными сразу после загрузки системы.
Диспетчер управления службами запускает службы, настроенные на отложенный автоматический запуск, только после завершения запуска всех служб, настроенных на автоматический запуск. Диспетчер устанавливает первоначальному потоку таких служб приоритет THREAD_PRIORITY_LOWEST (наинизший приоритет потока). Установка такого приоритета приводит к тому, что все операции ввода-вывода, выполняемые потоком, выполняются с приоритетом «Very Low» (очень низкий). Когда служба завершает инициализацию, диспетчер управления службами устанавливает ей приоритет «Normal» (обычный). Сочетание отложенного запуска, низкого приоритета использования ЦП и памяти, а также фонового приоритета дисковых операций приводит к существенному снижению воздействия запуска таких служб на процесс входа пользователя в систему. Многие службы Windows, включая фоновую интеллектуальную службу передачи (BITS), клиент Windows Update и службу Windows Media® Center, используют этот метод запуска для увеличения производительности процесса входа в систему сразу после загрузки.

Завершение работы
Одна из проблем, с которыми сталкивались разработчики служб Windows, состоит в том, что по умолчанию у службы есть не более 20 секунд на завершение работы. В операционных системах Windows, предшествовавших ОС Windows Vista, не поддерживалось «чистое» завершение работы, при котором система дожидалась бы полного завершения работы всех служб, потому что в этом случае ошибка в службе могла бы полностью воспрепятствовать завершению работы системы. Некоторым службам, которым при завершении работы необходимо выполнить определенные сетевые операции или сохранить большой объем данных на диск, может потребоваться более продолжительное время для завершения работы, поэтому ОС Windows Vista позволяет службам запросить у системы уведомление о завершении работы.
Когда ОС Windows Vista завершает работу, диспетчер управления службами сперва уведомляет о завершении работы все службы, запросившие такое уведомление. Диспетчер будет ждать завершения работы таких служб бесконечно долго, но если в службе есть ошибка и она не отвечает на запросы в течение трех минут, диспетчер перестает ждать завершения работы этой службы. После того, как все службы, запросившие уведомление, завершили работу или истекло время ожидания, диспетчер управления службами выполняет завершение работы остальных служб так, как это было реализовано в предыдущих версиях. Служба управления групповыми политиками и служба Windows Update регистрируют запрос уведомления о завершении работы при установке ОС Windows Vista.
Служба управления групповыми политиками и служба Windows Update используют еще одну возможность управления службами в ОС Windows Vista – упорядочение завершения работы. В предыдущих версиях ОС Windows можно было указать зависимости служб при запуске, и диспетчер управления службами придерживался указанного порядка запуска служб, но только в ОС Windows Vista появилась возможность указать зависимость служб при завершении работы. В ОС Windows Vista службы, которые регистрируют запрос уведомления о завершении работы, могут также включить себя в список, хранящийся в разделе реестра HKLM\System\CurrentControlSet\Control\PreshutdownOrder, и при завершении работы служб диспетчер управления службами будет завершать их работу в указанном порядке. Подробнее об этих возможностях см. врезку «Определение службы с отложенным автозапуском и службы с уведомлением о завершении работы».

Управление электропитанием
Режимы сна и гибернации также являются способами завершения работы, и ошибки в управлении электропитанием в драйверах и приложениях часто становились причиной серьезных проблем для работающих в дороге людей с тех пор, как в ОС Windows 2000 впервые в линейке ОС на базе Windows NT® появилось управление электропитанием. Закрывая крышку ноутбука перед поездкой, пользователи ожидают, что система перейдет в ждущий режим или в режим гибернации. Однако, прибыв на место, многие из них обнаруживали вместо этого горячий чемодан, севший аккумулятор и потерянные данные. Это происходило потому, что ОС Windows всегда запрашивала у приложений и драйверов устройств согласие на переход в другой режим энергопотребления, и одного драйвера или приложения, не отвечающего на запросы, было достаточно, чтобы воспрепятствовать этому переходу.
В ОС Windows Vista диспетчер управления электропитанием, входящий в ядро системы, по прежнему уведомляет драйверы и приложения о смене режима энергопотребления, позволяя им подготовиться к переходу в другой режим. Однако теперь ядро не спрашивает у них разрешения. Более того, диспетчер управления электропитанием ждет ответа приложений не более 20 секунд, а не 2 минуты, как это было в предыдущих версиях ОС Windows. В результате пользователи ОС Windows Vista могут быть уверены в том, что система действительно перейдет в ждущий режим или режим гибернации.

Что дальше
Как было упомянуто ранее, это второй из трех выпусков. Первый выпуск был посвящен усовершенствованиям ядра ОС Windows Vista в области ввода-вывода и процессов. В этом выпуске рассмотрены улучшения в таких областях как управление памятью, загрузка и завершение работы системы. В завершающем выпуске будут описаны нововведения ядра системы в области надежности и безопасности.
Определение службы с отложенным автозапуском и службы с уведомлением о завершении работы
Обновленная встроенная команда SC в ОС Windows Vista показывает службы, настроенные для отложенного автозапуска:
Using SC to display start type
Using SC to display start type (Щелкните изображение, чтобы уменьшить его)
Using SC to display start type
Using SC to display start type (Щелкните изображение, чтобы увеличить его)
К сожалению, команда SC не выводит список служб, запросивших уведомление о завершении работы. Чтобы узнать, запросила ли служба уведомление о завершении работы, можно воспользоваться программой PsService от компании Sysinternals:
Viewing pre-shutdown status
Viewing pre-shutdown status (Щелкните изображение, чтобы уменьшить его)
Viewing pre-shutdown status
Viewing pre-shutdown status (Щелкните изображение, чтобы увеличить его)

Марк Руссинович – член технического совета (Technical Fellow) подразделения платформ и служб (Platform and Services Division) корпорации Майкрософт. Он является одним из авторов книги «Microsoft Windows Internals» («Внутренняя структура ОС Microsoft Windows»), вышедшей в издательстве Microsoft Press в 2004 г., и часто выступает на конференциях для IT-специалистов и разработчиков. Марк Руссинович пришел в корпорацию Майкрософт после недавнего приобретения корпорацией компании Winternals Software, одним из основателей которой он являлся. Он также создал веб-ресурс Sysinternals, на котором опубликовал программы Process Explorer, Filemon и Regmon.


 От редактора: Полка с призами
От редактора
Полка с призами
Джошуа Трупин (Joshua Trupin)

ЗА ТРИДЦАТЬ ЛЕТ своей жизни я ничего не выигрывал. На моих лотерейных билетах всегда оказывались две вишенки и хмурое лицо. На пробках было написано: «Попробуй еще раз». В футбольном тотализаторе в качестве финалиста я всегда выбирал московское Динамо.
Неудивительно, что при такой «везучести» я страшно обрадовался, когда узнал, что наконец-то выиграл. Журнал TechNet Magazine недавно получил четыре награды от Общества технических средств связи (STC). Мы вкладываем всю душу в каждый номер, и так приятно, когда наши усилия оказываются оценены по достоинству. Здесь я хочу познакомить наших сотрудников с их достижениями.
В номере за март-апрель 2006 г. мы опубликовали наглядное и доступное руководство по работе со службой каталогов Active Directory в виде составной головоломки-постера. Руководство оказалось настолько популярным, что нас каждый день просят прислать копии. Общество технических средств связи присудило нашему постеру награду «За лучшее руководство по программному обеспечению» («Excellence for Software Guides»).
Две наши статьи также получили высокую оценку. Статья, вышедшая в августе 2006 г. «Игра с системами Exchange» («Playing with Exchange in a Sandbox») Грега Тейлора (Greg Taylor) и Саймона Шеферда (Simon Shepherd) и статья в номере за май-июнь 2006 г. «Разрушая мифы о безопасности» («Deconstructing Common Security Myths») Джеспера Джохансона (Jesper Johansson) и Стива Райли (Steve Riley) были удостоены почетных грамот Общества.
Журнал TechNet Magazine был признан лучшим среди научных и профессиональных журналов. Мне трудно представить более высокую оценку своей работы, и все работники журнала со мной согласны.
Нет, конечно, мы не собираемся почивать на лаврах. В этом номере Марк Русинович (Mark Russinovich) подробно расскажет об изменениях в ядре Windows Vista. Ценность этой информации для специалистов, участвующих в развертывании настольных систем или работающих в службах поддержки, сложно переоценить. В этом месяце мы детально рассматриваем весь спектр аспектов работы с SQL Server: от метаданных индекса до секционирования таблиц и от возможностей повышения уровня доступности до советов по кластеризации.
Мы практически безвылазно работаем в редакции £ сроки сдачи материалов всегда поджимают, £ но, к счастью, иногда нам все же удается сменить обстановку. В июне мы поедем на ежегодную конференцию Microsoft TechoEd, которая будет проходить с 4-го по 8-е число в Орландо. Подробная информация представлена на веб-узле microsoft.com/teched (на английском языке). Приходите. У вас будет возможность встретиться с редакторами и авторами журнала TechNet Magazine, получившими призы. Кроме того, мы планируем разные мероприятия, в том числе и с раздачей призов, так что £ кто знает? £ может, и вы что-нибудь выиграете. £ ДЖОШУА ТРУПИН (JOSHUA TRUPIN)

Мы хотели бы поблагодарить следующих технических специалистов по продуктам корпорации Майкрософт: Виджея Бхарадвая (Vijay Bharadwaj), Пола Боудена (Paul Bowden), Элден Кристенсен (Elden Christensen), Майкла Мурголо (Michael Murgolo), Раджива Нагара (Rajeev Nagar), Джона Пэнга (John Peng), Марка Русиновича (Mark Russinovich), Абрахама Сэмюеля (Abraham Samuel), Марка Скерелла (Mark Scurrell), Джима Трухера (Jim Truher), Джорджа Уолтерса (George Walters) и Бака Вуди (Buck Woody).

Джошуа Трупин (Joshua Trupin)


 Инструментарий: Новые продукты для специалистов по информационным технологиям
Инструментарий
Новые продукты для специалистов по информационным технологиям
Грег Стин (Greg Steen)

Управление синхронизацией сети
ViceVersa Pro
www.tgrmn.com

Если инфраструктура состоит более чем из одного компьютера, то обычно возникает необходимость в постоянном переносе файлов между средами. Начиная с файлов журналов регистрации и заканчивая выпусками приложений и резервными копиями баз данных, различные данные постоянно перемещаются по сети. При этом важно знать, что необходимо копировать для обеспечения синхронности различных сред. Для большинства ИТ-специалистов перенос файлов между средами вручную не является приемлемым вариантом, не говоря уже о том, что это вообще плохой метод, так как он может приводить к нарушению синхронности данных.
Программный продукт ViceVersa Pro компании TGRMN Software позволяет с легкостью автоматизировать и планировать выполнение этих задач. Данное приложение позволяет реализовать четыре различных режима копирования. Базовый режим синхронизации обеспечивает синхронизацию данных от источника к конечной системе, а расширенный режим синхронизации позволяет реализовать двунаправленную синхронизацию файлов и каталогов с отслеживанием файлов. Двумя другими режимами синхронизации являются резервное копирование (при котором создается зеркальная копия источника) и консолидация.
В то время как при использовании режима резервного копирования выполняется зеркальное копирование данных с источника на конечную систему путем добавления и удаления файлов в этой конечной системе, существует также возможность выбрать репликацию файлов, при которой файлы будут только копироваться на конечную систему. Это может быть очень полезно в том случае, когда существуют пользователи, которые могут неожиданно удалять файлы. Двунаправленная синхронизация выполняется в соответствии с названием этого режима, а также включает отслеживание конфликтов и удалений. Если до выполнения следующей синхронизации файл изменяется и в источнике, и в конечной системе, то возникший конфликт отмечается и данная проблема разрешается вручную. Метод консолидации аналогичен двунаправленной синхронизации, но в этом случае конфликты и удаления не отслеживаются.
Protect against copy errors and data loss
Protect against copy errors and data loss (Щелкните изображение, чтобы уменьшить его)
Protect against copy errors and data loss
Protect against copy errors and data loss (Щелкните изображение, чтобы увеличить его)
Программа ViceVersa Pro помогает выполнять задачи доставки журналов регистрации с использованием в режиме резервного копирования функций интегрированного сжатия и шифрования файлов. Данный продукт выполняет сжатие файлов исходной системы в стандартные файлы формата gzip, которые затем могут быть защищены с помощью пароля.
Эта программа включает также хорошую интегрированную функцию сравнения файлов, но существует возможность при желании установить использование внешней программы сравнения файлов приложением ViceVersa Pro. Для поддержки глобальной среды программа ViceVersa может работать с символами в формате Юникод и путям, длина которых превышает 256 символов. Это приложение также обладает встроенной поддержкой синхронизации времени через Интернет, так что его можно настроить на использование локального или внешнего NTP-сервера, если в среде, в которой используется данная программа, разрешена отправка запросов во внешнюю сеть.
Иногда сложности могут возникать из-за использования пропускной способности сети, особенно если трафик передается через виртуальную частную сеть (VPN) или глобальную сеть (WAN). В этом случае программа ViceVersa позволяет ограничить пропускную способность, используемую приложением сети для каждого задания по синхронизации. Это также может способствовать обеспечению производственного уровня обслуживания серверами, с которых или на которые осуществляется копирование. Или при желании можно задать максимальное пороговое значение использования ЦП, чтобы обеспечить доступность сервера во время работы данного приложения.
Программа ViceVersa Pro обеспечивает защиту от ошибок копирования и потери данных с помощью алгоритма безопасного копирования. Кроме того, для обеспечения целостности данных это приложение выполняет контроль с использованием циклического избыточного кода. Существует возможность запланировать выполнение заданий по синхронизации с практически любым интервалом, включая режим реального времени (в этом случае синхронизация файлов будет осуществляться в момент добавления или удаления файлов из синхронизированных папок).
Еще одной полезной особенностью приложения ViceVersa Pro является возможность с помощью интерфейса пользователя выполнять предварительный просмотр всех операций до их выполнения. Это позволяет обеспечить копирование нужных данных и избежать таких ситуаций, как наличие в системном каталоге нескольких гигабайт файлов журналов регистрации.
В общем, если нужно недорогое, полнофункциональное средство для выполнения синхронизации, то приложение ViceVersa Pro может удовлетворить эту потребность.
Цена: 59,95 долларов США за однопользовательскую лицензию.

Выполняйте администрирование дисков своей системы
Partition Manager 8.0 Professional Edition
www.partition-manager.com/corporate/professional
Если возникла необходимость в приложении, которое может облегчить выполнение администрирования дисков системы, то определенно стоит рассмотреть программу Partition Manager 8.0 Professional Edition компании Paragon Software Group.
В качестве основной функциональной возможности это приложение для операционной системы Windows® предоставляет интуитивный интерфейс с использованием мастеров, позволяющий с легкостью создавать, удалять, изменять видимость и форматировать разделы жесткого диска, имеющие формат FAT16/32, NTFS, Ext2/3 или HPFS. Кроме того, существует возможность изменять размер существующих разделов или перемещать разделы с одного диска на другой.
Более того, с помощью этого средства можно преобразовывать различные типы файловых систем, например FAT16/32 в NTFS или Ext2 в Ext3 и обратно. При копировании разделов с одного диска на другой их размер будет автоматически изменяться до размера диска, что может быть удобно при расширении диска данных системы без выполнения копирования всех файлов вручную. Одной из полезных функций версии 8.0 является возможность выполнять изменение размера без отключения диска, что позволяет увеличивать размер активного раздела с файловой системой NTFS без перезагрузки операционной системы Windows.
Increase the size of an active NTFS partition £ without rebooting
Increase the size of an active NTFS partition £ without rebooting (Щелкните изображение, чтобы уменьшить его)
Increase the size of an active NTFS partition £ without rebooting
Increase the size of an active NTFS partition £ without rebooting (Щелкните изображение, чтобы увеличить его)
Еще одна удобная функция выпуска Pro Edition этой программы заключается в возможности преобразования динамических дисков в базовые диски на клиентских компьютерах под управлением операционных систем Windows 2000, Windows XP и Windows Server® 2003. Приложение Partition Manager поддерживает диски размером до, как минимум, 500 ГБ (максимальный размер, протестированный компанией Paragon, а не реальный физический предел), а также диски, подключаемые к портам FireWire и USB. Приложение Partition Manager будет поддерживать жесткие диски с интерфейсами PATA (IDE), SATA и SCSI.
Приложение Partition Manager позволяет создавать компакт-диск (или DVD-диск либо даже дискету) для выполнения восстановления, с помощью которого можно восстановить систему после разрушительного сбоя в работе диска. А в случае ошибочного удаления раздела, если система все еще находится в активном состоянии, существует возможность через интерфейс отменить удаление этого раздела. Для дополнительной настройки производительности можно даже изменить размер кластеров на диске. Это приложение также позволяет выполнить виртуальный просмотр диска до фактического выполнения операций с ним, что позволяет оценить изменения диска до физического их осуществления.
Кроме того, с помощью приложения Partition Manager 8.0 можно выполнить обновление жесткого диска системы. Это приложение позволяет копировать образ раздела или всего жесткого диска на новый диск, изменяя его размер до размера конечного раздела.
И, наконец, средство Partition manager также содержит встроенное средство дефрагментации, которое позволяет выполнять дефрагментацию дисков, до 99 процентов пространства которых уже заполнено, хотя мы надеемся, что необходимые меры будут предприняты прежде, чем диск достигнет такого состояния.
Цена: 99,95 долларов США за выпуск Professional Edition.

Добавьте в свой редактор языка SQL функцию автоматического завершения
SQL Prompt: IntelliSense для SQL
www.red-gate.com/products/SQL_Prompt/index.htm

Заманчиво думать, что все базы данных создаются и структурируются с применением общепринятого логичного именования в нормализованной форме, но, к сожалению, все мы знаем, что это не так. Я заметил, что, выступая в роли системного администратора или администратора базы данных, при создании или выполнении запросов часто вынужден обращаться к структуре таблиц, а в случае работы в качестве разработчика такая потребность у меня возникает еще чаще.
Хотя среда SQL Server™ Management Studio для приложения SQL Server 2005 и значительно облегчила жизнь, так как в ней в область просмотра древовидной структуры интерфейса интегрирован обозреватель объектов, мне все равно хочется иметь функцию, к которой я слишком привык, пользуясь интегрированной средой разработки средой Visual Studio®: IntelliSense®. К счастью, компания Red-Gate Software предлагает продукт SQL Prompt, который обеспечивает функцию автоматического завершения для редакторов приложения Microsoft SQL Server.
Это приложение работает на панели задач и обнаруживает запуск редактора. Сначала приложение SQL Prompt запросит данные для подключения к этой базе данных, чтобы иметь возможность обратиться и кэшировать все данные об объектах. Это повышает производительность и сокращает непроизводительные затраты времени, но в случае постоянного внесения изменений в объекты экземпляра базы данных необходимо не забывать очищать кэш (что является простым действием, которое выполняется в два щелчка мышью), чтобы изменения были отражены в списке подсказок.
Кроме интегрированных сред разработки Visual Studio, Enterprise Manager, Query Analyzer и SQL Server Management Studio, приложение SQL Prompt также непосредственно интегрируется с приложениями UltraEdit и EditPlus 2. На вкладке Options (параметры) пользовательского интерфейса Settings (настройка) можно указать, какие ключевые слова языка SQL должны запускать вывод списка возможных вариантов (например FROM, JOIN, EXEC и т.д.). Запуск приложения SQL Prompt при вводе ключевого слова JOIN языка SQL даже приведет к вводу инструкции ON (при наличии эталонного множества или при одинаково названных полях). Эта программа также позволяет настроить для вставления фрагментов кода текстовые комбинации быстрого ввода. Например, в этом приложении задано, что строка «ssf» с последующим нажатием клавиши табуляции заменяется конструкцией «SELECT * FROM». Программа SQL Prompt также может автоматически менять регистр ввода ключевых слов языка SQL на верхний. Эта функция и фрагменты кода гарантированно позволяют экономить время.
На вкладке Candidates (возможные варианты) пользовательского интерфейса settings (настройка) можно определить, должна ли программа SQL Prompt использовать полные имена столбцов, приставку, содержащую информацию о владельце или схеме, заключать имена в квадратные скобки, и даже задать типы функций языка SQL, которые должны отображаться в списке возможных вариантов. При использовании языка SQL стоит добавить это средство в набор своих хитростей.
Приложение SQL Prompt будет оставаться бесплатным до выхода версии 3.0, которая на момент написания этой статьи была на стадии окончательного бета-тестирования. Цена версии 3.0 еще не объявлена
Цена: бесплатно.

Вычисляйте размер страниц
Atomic Page Size Calculator
www.info-pack.com/pagesize
Пропускная способность каналов связи конечных пользователей увеличивается, и новые технологии помогают быстрее доставлять веб-содержимое этим конечным пользователям, но размер страниц все еще имеет большое значение. Все эти байты могут привести к большим затратам на обеспечение необходимой пропускной способности для узлов с большими потоками данных.
Распространяемая через узел Info-pack.com служебная программа Atomic Page Size Calculator (элементарное средство вычисления размера веб-страниц) является недорогим и простым средством проверки объема страниц веб-узла. Все, что нужно сделать £ это ввести URL-адрес страницы, размер которой нужно определить, и программа выполнит захват этой страницы, вычисление размера всех ее элементов, включая загружаемые по ссылкам на другие узлы изображения, т.е. элементы, которые могут не отражаться в журналах регистрации веб-узла основного домена.
Keep an eye on bandwidth cost
Keep an eye on bandwidth cost (Щелкните изображение, чтобы уменьшить его)
Keep an eye on bandwidth cost
Keep an eye on bandwidth cost (Щелкните изображение, чтобы увеличить его)
Это средство расчета поддерживает файлы страниц, изображений и программ на языке JavaScript, так что позволяет получать данные по большей части ресурсов страницы. Это приложение также уведомляет, если встречает «неисправный» ресурс, приводящий к выдаче ошибки 404. Получив информацию об объеме страницы, расположенной по URL-адресу, нажмите кнопку Report (отчет), чтобы просмотреть сведения о размере каждого из элементов и оценку времени, необходимого для загрузки размещенной по этому URL-адресу страницы при различных скоростях соединения.
Было бы очень хорошо, если бы это приложение могло обрабатывать несколько URL-адресов одновременно, но, вероятно, такая возможность появится в будущем выпуске. Если необходим быстрый способ проверить размер создаваемых группой разработчиков страниц, это приложение может быть подходящим решением.
Цена: 19,95 долларов США, оплата непосредственно на сайте.

Пишите в раздел «Инструментарий»
Если хотите увидеть здесь обзор любимого средства или служебной программы, свяжитесь с автором по адресу tntools@microsoft.com.
Грег Стин (Greg Steen) £ специалист по информационным технологиям, предприниматель и энтузиаст. Он находится в постоянном поиске новых инструментов и методов для облегчения работы специалистов по информационным технологиям и процесса разработки.


 Обзор служебных программ: SyncToy
Обзор служебных программ
SyncToy
Джей Мунро (Jay Munro)
Загрузить исходный код для этой статьи: SynctToy (971KB)

КОШМАР , преследующий ИТ-специалистов, сетевых администраторов и работников службы поддержки £ звонок пользователя, чей компьютер сгорел, а данные, хранившиеся на нем, пропали. Даже самых продвинутых пользователей порой сложно заставить сохранять свои труды не только на локальном диске, но и вне собственного компьютера. SyncToy может облегчить жизнь всем.
По замыслу разработчиков программа предназначалась для синхронизации фотографий на фотоаппарате, компьютере и внешних носителях. Однако SyncToy оказалась гибким и надежным инструментом для резервного копирования практически любых файлов. В ОС Windows Vista™, а также в Windows® XP и Windows Server® 2003, SyncToy синхронизирует данные, хранящиеся на локальных и внешних дисках, USB-устройствах и в общих папках.
SyncToy работает с парами папок. Пара состоит из левой и правой папки Можно создать неограниченное количество пар папок. Для синхронизации каждой пары или всех пар одновременно достаточно нажать всего одну кнопку. Создание пары осуществляется с помощью мастера (его работа состоит из четырех шагов), в котором можно ввести или вставить из буфера обмена путь или перейти к месту размещения левой и правой папки. В SyncToy используется как UNC-формат (например, \\MyServer\Joe_smith\backup\), так и локальный формат (т.е. E:\doc_backup) имен файлов. После выбора папок необходимо указать одно из пяти действий, которое будет производиться при сравнении папок.
Sync («Синхронизация»): копирование новых и обновленных файлов в обоих направлениях. При переименовании или удалении файла в одной паке, точно такое же действие автоматически выполняется в другой папке.
Echo («Эхо»): дублирование операций (копирование новых и обновленных файлов, удаление и переименование), производимых в левой папке, в правой.
Subscribe («Подписка»): копирование обновленных файлов из правой папки в левую, причем только в том случае, если файл уже существует в левой папке. Изменения в левой папке не отображаются в правой.
Contribute («Вклад»): копирование новых и обновленных файлов из левой папки в правую, игнорируя удаления.
Combine («Объединение»): копирование файлов, имеющихся на одном компьютере, на другие компьютеры (на которых эти файлы отсутствуют). Удаление и переименование файлов на одном компьютере не приводит к аналогичным операциям на других компьютерах.
Выбрав необходимое действие, придумайте понятное имя для пары папок. Вот, собственно, и все. SyncToy пока не позволяет изменять пути к папкам и имена пар. Если вы допустили ошибку, необходимо выделить пару, удалить ее и создать заново. Вы можете настроить работу программы, в том числе выбрать файлы и вложенные папки, а также указать, сохранять ли замененные файлы в Корзине (включено по умолчанию).
Synchronizing files with SyncToy
Synchronizing files with SyncToy (Щелкните изображение, чтобы уменьшить его)
Synchronizing files with SyncToy
Synchronizing files with SyncToy (Щелкните изображение, чтобы увеличить его)

В главном диалоговом окне программы слева отображаются пары папок, а также пути, настройки и действия для выбранной пары. С помощью функции All Folder Pairs («Все пары папок») отображаются все созданные вами пары, и теперь вы можете выбрать предварительный просмотр (функция Preview) или синхронизацию (функция Run All) всех выбранные пар. Очевидно, функция Preview демонстрирует все действия, которые будут происходить при синхронизации, не производя никаких изменений. Это очень полезная функция при планировании автоматической синхронизации. После выполнения этой команды создается отчет, содержащий все операции, которые будут произведены. Если вас все устраивает, нажимайте кнопку Run («Выполнить»).
В программе нет собственного планировщика, но в файле справки приводится вполне понятная инструкция, как воспользоваться планировщиками заданий Windows Vista и Windows XP. Обычным пользователям, возможно, понадобится помощь в настройке планировщика, но это нужно сделать всего один раз, а все изменения в парах папок, действия и настройка будут проведены автоматически.
Как и остальные программы семейства PowerToys, SyncToy создана в соответствии с требованиями, применяемыми к стандартному ПО. Тем не менее, поддержка программы корпорацией Майкрософт не осуществляется. В вашем распоряжении форумы и документация. Файл справки достаточно подробный и написан для пользователей всех уровней. Интерфейс пользователя интуитивно понятен, поэтому с основными функциями вы разберетесь при первом же запуске программы.
Итак, загрузите SyncToy и научите ваших пользователей копировать файлы. Одним кошмаром меньше.

Джей Мунро (Jay Munro) £ писатель в группе поддержки пользователей Windows корпорации Майкрософт, специализирующийся на обозревателе Internet Explorer. До этого он возглавлял проект в тестовых лабораториях журнала PC Magazine.


 SQL: вопросы и ответы: Переход на летнее время, память сервера и другие темы
SQL: вопросы и ответы
Переход на летнее время, память сервера и другие темы
Под редакцией Нэнси Митчелл (Nancy Michell)

Летнее время
В. Принимая во внимание предстоящее изменение графика перехода на летнее время в США, нужно ли мне обновить приложение SQL Server™ для выполнения требований Закона об энергетической политике (Energy Policy Act) 2005 года?
О. Нет. На данный момент для поддержки изменений графика перехода на летнее время никаких обновлений, относящихся конкретно к приложению SQL Server, не существует. Приложение SQL Server получает данные о времени от операционной системы; иными словами, если операционная система сообщает правильные дату и время, приложение SQL Server просто воспроизводит и использует эти значения. С учетом предстоящих изменений вы должны обновить свой экземпляр системы Windows® согласно инструкциям, изложенным в статье support.microsoft.com/kb/928388 (на английском языке). Это обязательное обновление для всех операционных систем Windows, вышедших до системы Windows Vista™ (в ней изменения уже учтены), необходимое для соответствия измененному графику перехода на летнее время, в том числе и для операционных систем на компьютерах, под управлением которых работает приложение SQL Server. (В Австралии также планируются внесение некоторых изменений. См. статью support.microsoft.com/kb/912475 (на английском языке).)

Соединение с Windows Vista
В. После установки ОС Windows Vista мне не удается установить соединение с приложением SQL Server 2005. У меня есть права локального администратора, и раньше никаких проблем с соединением не возникало. Что случилось?
О. При взаимодействии ОС Windows Vista и сервера SQL Server 2005 без пакета обновления 2 (SP2) такое поведение считается нормальным. В ОС Windows Vista реализована новая модель безопасности (контроль учетных записей), которая фактически блокирует членство в группе локальных администраторов и требует подтверждать операции, для проведения которых требуются административные полномочия. После нажатия кнопки «Разрешить» соответствующие учетные данные, в том числе маркер администратора, передаются приложению. В случае работы со средой SQL Server Management Studio (SSMS) соответствующее диалоговое окно не выводится, так как для ее запуска права администратора не нужны. Проблема в том, что по умолчанию роль «системный администратор» приложения SQL Server 2005 включает в себя группу локальных администраторов операционной системы, и именно это ваша учетная запись использовала в прошлом для доступа к приложению SQL Server. Так как в системе Windows Vista соответствующее разрешение не отправляется, доступ к приложению SQL Server не предоставляется.
Следует заметить, что запуск приложения SQL Server 2005 без пакета обновления 2 (SP2) в системе Windows Vista невозможен, а в указанном пакете есть средство, которое добавит соответствующую учетную запись. Если пакета обновления 2 (SP2) у вас еще нет, ничего страшного £ есть обходной путь. Необходимо добавить индивидуальную учетную запись системы Windows в приложение SQL Server, то есть в данном случае связать с ролью «системный администратор». Для этого щелкните правой кнопкой мыши элемент «SQL Server Management Studio» и выберите в контекстном меню пункт «Запуск от имени администратора». Установите соединение с приложением SQL Server и свяжите свою учетную запись Windows с ролью «системный администратор». Дополнительные сведения по этому вопросу см. в разделе документации SQL Server Books Online (Электронные книги по SQL Server) (на английском языке).

Транзакционная репликация с представлениями
В. При обновлении опубликованного представления я могу быть уверен в том, что транзакция будет реплицирована. Будет ли выполнена репликация транзакции, если обновить базовую таблицу этого представления? Если создать представление на основе опубликованной таблицы, а затем вместо таблицы обновить представление, будет ли такая транзакция реплицирована?
О. Если базовая таблица настроена как статья в рамках публикации (иными словами, если выполненные вами настройки предусматривают репликацию базовой таблицы), то реплицироваться будут все обновления этой таблицы.
По умолчанию при репликации представления реплицируется только его схема или соответствующий ему код; таким образом, если речь не идет об индексированном представлении, сами данные репликации не подлежат. Затем, даже если репликация не выполняется, при каждом обновлении представления (которое в данном случае приравнивается к исполнению инструкции на языке DML (Data Manipulation Language £ язык манипулирования данными), где в качестве целевого объекта указано представление), фактически обновляется не представление, а данные соответствующей таблицы. Представление £ это просто логическое хранилище инструкции запроса, не связанное с физическим хранилищем (такое определение, опять же, справедливо лишь в том случае, если речь не идет об индексированном представлении).

Максимальный объем памяти сервера
В. У меня есть система, работающая под управлением системы Windows Server® 2003; на ней установлен сервер SQL Server 2000, а объем ОЗУ составляет 5 ГБ. Предположим, я установил параметры /3GB, чтобы увеличить область виртуальной памяти в пользовательском режиме, и /PAE, чтобы загрузить версию ядра ОС Windows с расширением физических адресов, а также установил значение активирующего расширения AWE параметра равным 1 (и включил блокировку страниц в памяти). Если расширения AWE включены, устанавливающий максимальный объем памяти сервера параметр регулирует размер кэша данных или всех буферных кэшей вместе взятых (то есть кэшей данных, процессов, сеансов и т.д.)? Предположим также, что максимальная память сервера установлена равной 4 ГБ. Если учесть, что доступ к отображаемой расширениями AWE памяти имеет только кэш данных, будет размер этого кэша ограничен 1 ГБ (т.е. областью, находящейся под управлением AWE) или он сможет, используя этот 1 ГБ памяти как дополнительный ресурс, по-прежнему обращаться к стандартному адресному пространству и конкурировать со всеми остальными потребителями памяти за доступ к нему?
О. Параметр, отвечающий за максимальный объем памяти сервера, действует в отношении всего пула буферов, однако единственным потребителем, который получает возможность обращаться к памяти, отображаемой расширениями AWE, остается кэш данных.
Таким образом, что касается первого вопроса, даже при включенных расширениях AWE параметр, отвечающий за максимальный объем памяти сервера, применяется к пулу буферов в целом, а все потребители, за исключением кэша данных, ни при каких обстоятельствах не могут использовать память, отображаемую расширениями AWE.
Что касается второго вопроса, для кэша данных доступна память, отображаемая расширениями AWE, а также другие пространства памяти в пуле буферов, которые приложение SQL Server сочтет нужным ему выделить; таким образом, кэш данных отнюдь не ограничивается ресурсами AWE, однако является единственным потребителем, у которого есть возможность их использовать. О том, как действует параметр /3GB, можно прочитать в блоге Рэймонда Чена (Raymond Chen).

Профилирование и производительность
В. В рабочей среде имеется зеркальный сервер SQL Server 2005. При запуске профайлера SQL Server в системе с базой данных и записи в файл данных отслеживания наблюдается резкий спад производительности. Почему так происходит?
О. Чтобы определить причину спада производительности, нужно знать, в какой системе запускается профайлер. Если он исполняется на сервере в интерактивном режиме, то быстродействие сокращается за счет потребления пользовательским интерфейсом профайлера ресурсов памяти и ЦП.
Если профайлер работает в интерактивном режиме на рабочей станции, то по сети передаются сведения о событиях. Это влияет на пропускную способность. Если в той же сети выполняется зеркальное отображение, на данный процесс это тоже влияет. Кроме того, если выходные данные профайлера сохраняются на общем сетевом ресурсе, на производительности сказывается их передача по сети.
Чтобы минимизировать снижение производительности, лучше всего запускать профайлер в неинтерактивном режиме на сервере с экземпляром, который предполагается профилировать, а выходные данные записывать в локальный файл. Потребления ресурсов сервера не избежать в любом случае, но указанная схема снижает производительность в наименьшей степени. По сравнению с файлами трассировки профайлера (размещаемыми в памяти) это значительно более удачное решение. Отслеживание посредством файлов характеризуется сокращенным потреблением ресурсов памяти, кроме того, в этом случае увеличивается размер буферов, содержимое которых более эффективно сбрасывается на диск. Наконец, этот метод не зависит от внешних процессов (в частности, от профайлера SQL Server).
Данные трассировки записываются в файл на диске в тот момент, когда профайлер продолжает работу. Файл трассировки является общим, что позволяет сторонним пользователям знакомиться с данными профилирования в реальном времени с удаленных компьютеров. При вызове файла трассировки в интерактивном режиме запуск профайлера осуществляется вручную, а просмотр выходных данных осуществляется на экране. Трассировку можно выполнять программным способом, не прибегая к выводу данных на экран; по этой причине стоит избегать работы в интерактивном режиме.
Можно создать общий ресурс на основе локального каталога; из него к файлам трассировки смогут обращаться другие пользователи, что обычно является хорошим решением. Как уже отмечалось, отправлять выходные данные трассировки на удаленный общий ресурс не стоит; это особенно актуально для общих ресурсов, относящихся к тому же сетевому каналу, через который осуществляется зеркальное отображение.
Кроме того, следует определить минимальный набор событий, необходимых для анализа. Выбирая местоположение файла трассировки, предпочтение следует отдать диску с наивысшим быстродействием (при этом лучше исключить из списка вариантов диски, на которых располагаются база данных и журнал транзакций приложения SQL Server). Если выполнение вышеизложенных рекомендаций не помогло устранить заметный спад производительности, распределите события между двумя или несколькими процессами трассировки, направив их выходные данные на разные жесткие диски. Даже если во всех случаях выходные данные записываются на один жесткий диск, эффективность удастся повысить за счет того, что каждому процессу трассировки выделяется отдельный набор буферов. Дополнительные сведения о хранимых процедурах, в том числе sp_trace_create, можно почерпнуть из раздела документации SQL Server Books Online (Электронные книги по SQL Server).

Вопросы по кластеризации
В. Я пытаюсь установить приложение SQL Server на кластер под управлением операционной системы Windows Server 2003, но каждый раз получаю сообщение об ошибке «Setup failed to perform required operations on the cluster nodes» (программе установки не удалось выполнить необходимые операции с узлами кластера). В журнале sqlstp.log появляется запись следующего вида:
Script file copied to '\\SERVER01\ADMIN$\SERVER01_MSSQLSERVER.iss' successfully.
Installing remote service (SERVER01)...
An error occured in the service create (SERVER01): 1069...
Что бы это значило?
О. Этот сбой может быть обусловлен разными факторами. Для удаленного управления процессом установки на отдельных системах программа установки осуществляет на всех выбранных узлах установку службы Windows NT®. По этой причине нужно иметь представление о ряде препятствий, с которыми в данном случае можно столкнуться.
Во-первых, на пользователей учетной записи домена может распространяться групповая политика, отзывающая разрешение «вход в качестве службы» (как известно, политика домена имеет более высокий по сравнению с локальной политикой компьютера приоритет). Выбирайте учетную запись без подобных ограничений.
Во-вторых, действующая учетная запись в системе, с которой запускается программа установки, должна предусматривать доступ ко всем узлам с правами администратора. Дело в том, что главному процессу установки требуются права удаленного доступа к реестру всех участвующих систем; программа установки копирует файл cnvsvc.exe в каталог Windows удаленной машины; кроме того, программа установки может обратиться к стандартным интерфейсам API ОС Windows, которые для доступа к удаленным системам задействуют только разрешения действующей учетной записи. В свете всего вышеизложенного во всех режимах по умолчанию нужно входить в систему с учетной записью администратора.

Составление плана аварийного восстановления
В. Я собираюсь реализовать стратегию восстановления DR (disaster recovery £ аварийное восстановление) для баз данных SAP, но не могу сделать выбор из зеркального отображения баз данных (в асинхронном режиме) и доставки журналов. Между рабочим узлом и узлом восстановления DR будет установлено высокоскоростное (100 Мб) соединение, которое не будет являться выделенным для сеанса зеркального отображения. Предполагается разделить ресурс соединения между несколькими сеансами зеркального отображения или даже предоставить доступ к нему другим серверам восстановления DR.
Не возникнет ли проблем с передачей записей журнала в зеркальную базу данных; если проблемы возможны, будут ли выполняться повторные попытки?
Предусмотрен ли период хранения транзакций на тот случай, если сеанс зеркального отображения придется приостановить? На основе каких данных, помимо системных представлений, можно отслеживать трафик зеркального отображения и процесс передачи записей журнала?
О. Начнем с вопроса о логике повторных попыток при зеркальном отображении баз данных. Рассмотрим две ситуации. При кратковременном сбое сети сеанс зеркального отображения переходит в отключенное состояние. Существует стандартное значение интервала ожидания сети, составляющее 10 секунд; если он истекает, подразумевается, что передача записи журнала от основной базы данных к зеркальной невозможна. В таких случаях основной сервер продолжает работать в «открытом» режиме, и транзакция будет фиксироваться на стороне клиента. После устранения сбоя сети повторная попытка проведения сеанса зеркального отображения предпринимается автоматически, без участия пользователя. На основании записей журнала партнеры выполняют синхронизацию, после чего их состояние становится синхронизированным.
Если сбой происходит при попытке повтора, сеанс зеркального отображения переходит в приостановленное состояние. Трудности при повторе свидетельствуют о том, что зеркальной базе данных не удается зафиксировать записи журнала. Как правило, подобные проблемы бывают вызваны отсутствием искомого файла или недостатком дискового пространства. В таких случаях основной сервер продолжает работать в открытом режиме и транзакция фиксируется на стороне клиента. После того как сбой, связанный с повтором, будет вручную устранен на зеркальном сервере, сеанс зеркального отображения потребует вмешательства:
ALTER DATABASE <db> SET PARTNER RESUME;
Что касается периодов хранения, то вне зависимости от состояния сеанса отображения (которое, как мы выяснили, может быть отключенным или приостановленным) записи журнала сохраняются вплоть до того момента, пока он не будет восстановлен, а все записи, выполненные в период с приостановки до восстановления, записаны на зеркальном сервере. Когда сеанс зеркального отображения находится в отключенном или приостановленном состоянии, урезать журнал основного сервера становится невозможно, так как в противном случае цепочка повтора будет утрачена. Следовательно, пока сеанс не удастся восстановить, журнал основной базы данных будет постоянно увеличиваться в размере. Следовательно, период хранения состояния сеанса зеркального отображения не ограничивается ничем, кроме дискового пространства на основном сервере, выделенного под размещение журнала, так как журнал не может быть урезан.
Наконец, отдельного журнала для наблюдения за процессом зеркального отображения не существует. В приложении SQL Server 2005 для этой цели предусмотрена служебная программа с графическим интерфейсом, называемая монитором зеркального отображения базы данных. Она позволяет системным администраторам просматривать и обновлять состояние, а также устанавливать пороги предупреждения по нескольким базовым метрикам производительности. От этой программы можно получать предупреждения о нештатных ситуациях в процессе зеркального отображения. Основной проблемой в отношении производительности является несвоевременная обработка записей журнала. Дополнительные сведения о контроле зеркального отображения баз данных приведены в статье Monitoring Mirroring Status (Наблюдение за состоянием зеркального отображения), расположенной по адресу msdn2.microsoft.com/fr-fr/library/ms365781.aspx (на английском языке).

Благодарим за технические консультации следующих ИТ-специалистов корпорации Майкрософт: Чэда Бойда (Chad Boyd), Санду Чирика (Sandu Chirica), Алана Доби (Alan Doby), Калояна Манассиева (Kaloian Manassiev), Лучано Морейра (Luciano Moreira), Ивана Пенкова (Ivan Penkov), Сивагаминатана Раджаретинама (Sivagaminathan Rajarethinam), Дебору То (Deborah To), Патрика Вудварда (Patrick Woodward), Бака Вуди (Buck Woody), Стэнли Яу (Stanley Yau) и Уоррена Янга (Warren Young).


 Кабельщик: Протокол DHCPv6
Кабельщик
Протокол DHCPv6
Джозеф Дэвис (Joseph Davies)

Протокол DHCP (Dynamic Host Configuration Protocol £ протокол динамической настройки хостов) предназначен для назначения компьютерам IP-адресов и других сетевых данных, которые обеспечивают возможность их автоматического взаимодействия в сети. По сути, в сети IPv6 настройку адресов можно проводить и без DHCP, однако наличие этого протокола предоставляет ряд преимуществ. Протокол DHCP для протокола IPv6 (DHCPv6) может
предоставлять узлам IPv6 настройки адресов с сохранением или без сохранения состояния. На узлах IPv6 для настройки адресов применяется несколько методов:
автоматическая настройка адресов без сохранения состояния применяется для настройки локальных адресов канала и нелокальных адресов путем обмена сообщениями Router Solicitation (обращение к маршрутизатору) и Router Advertisement (объявление маршрутизатора) с соседними маршрутизаторами;
автоматическая настройка адресов с сохранением состояния применяется для настройки нелокальных адресов с помощью протокола настройки, например DHCP.
Настройку адресов без сохранения состояния узел IPv6 выполняет автоматически. При этом он задействует протокол настройки (например DHCPv6), основываясь на следующих флагах из сообщения Router Advertisement (объявление маршрутизатора), полученного от соседнего маршрутизатора:
флаг управляемой настройки адресов (флаг M). Если данный флаг имеет значение 1, это указывает на то, что узел должен получить адреса с сохранением состояния посредством протокола настройки;
флаг других параметров настройки с сохранением состояния (флаг O). Если данный флаг имеет значение 1, это указывает на то, что узел должен обратиться к услугам протокола настройки для получения других параметров.
Ниже приводятся возможные варианты сочетания флагов M и O:
флаги M и O имеют значение 0. Это сочетание соответствует сети без инфраструктуры DHCPv6. При настройке нелокальных адресов хосты основываются на объявлениях маршрутизатора; остальные параметры настраиваются другими методами (например вручную);
флаги M и O имеют значение 1. Адреса и другие параметры настраиваются при помощи протокола DHCPv6. Это сочетание называется «DHCPv6 с сохранением состояния»; при этом протокол DHCPv6 назначает узлам IPv6 адреса с сохранением состояния;
флаг M имеет значение 0, а флаг O £ значение 1. Протокол DHCPv6 не участвует в назначении адресов, но применяется для присвоения других параметров настройки. Соседние маршрутизаторы объявляют префиксы нелокальных адресов, на основании которых узлы IPv6 формируют адреса без сохранения состояния. Это сочетание называется «DHCPv6 без сохранения состояния». Протокол DHCPv6 распределяет между узлами IPv6 не адреса с сохранением состояния, а параметры настройки без сохранения состояния;
флаг M имеет значение 1, а флаг O £ значение 0. В этом сочетании протокол DHCPv6 задействуется для настройки адресов, но не участвует в определении других параметров. Так как необходимость в настройке других параметров (например IPv6-адресов DNS-серверов) на узлах IPv6 возникает в большинстве случаев, подобное сочетание встречается редко.
Подобно тому, как это было с протоколом DHCP для сетей IPv4, инфраструктура DHCPv6 состоит из клиентов DHCPv6, запрашивающих настройки, серверов DHCPv6, предоставляющих настройки, и агентов ретрансляции DHCPv6, которые выступают посредниками при обмене сообщениями между серверами и клиентами, когда последние располагаются в подсетях без сервера DHCPv6.

Сообщения протокола DHCPv6
Как и протокол DHCP для IPv4, протокол DHCPv6 использует сообщения протокола UDP (User Datagram Protocol £ протокол пользовательских датаграмм). Клиенты DHCPv6 прослушивают на предмет сообщений DHCP порт 546 протокола UDP. Серверы и агенты ретрансляции DHCPv6 прослушивают в ожидании сообщений DHCPv6 порт 547 протокола UDP. По структуре сообщения DHCPv6 значительно проще своих аналогов протокола DHCP для IPv4, который в целях обеспечения поддержки бездисковых рабочих станций был основан на протоколе BOOTP. Структура сообщений протокола DHCPv6, которыми обмениваются клиент и сервер, показана на рис. 1.
Figure 1 DHCPv6 messages between client and server
Figure 1 DHCPv6 messages between client and server (Щелкните изображение, чтобы уменьшить его)
Figure 1 DHCPv6 messages between client and server
Figure 1 DHCPv6 messages between client and server (Щелкните изображение, чтобы увеличить его)
В поле Msg-Type размером 1 байт указывается тип сообщения DHCPv6. Поле Transaction-ID (3 байта), определяется клиентом и предназначено для группировки сообщений протокола DHCPv6, которыми обмениваются стороны. После поля Transaction-ID следуют параметры протокола DHCPv6, содержащие идентификационные данные клиента и сервера, адреса и другие настройки. Перечень стандартных параметров DHCPv6 содержится в документе RFC 3315, ссылка на который приведена на боковой панели «Ресурсы RFC, касающиеся протокола DHCPv6».
Параметры протокола DHCPv6 имеют формат TLV (type-length-value £ тип-длина-значение). Структура параметров DHCPv6 показана на рис. 2.
Поле Option-Code (2 байта) предназначено для идентификации параметра. В поле Option-Len (2 байта) указывается длина поля Option-Data в байтах. Поле Option-Data содержит данные параметра.
Сообщения, которыми агенты ретрансляции и серверы обмениваются для записи дополнительных сведений, отличаются по своей структуре. Структура подобных сообщений показана на рис. 3.
Figure 2 Structure of DHCPv6 options
Figure 2 Structure of DHCPv6 options (Щелкните изображение, чтобы уменьшить его)
Figure 2 Structure of DHCPv6 options
Figure 2 Structure of DHCPv6 options (Щелкните изображение, чтобы увеличить его)
В поле Hop-Count (1 байт) указывается число агентов ретрансляции, получивших данное сообщение. Если число прыжков, указанное в сообщении, превышает максимально допустимую величину, принимающий агент ретрансляции может отказаться от него. В поле Link-Address (16 байт) содержится нелокальный адрес, назначаемый интерфейсу, подключенному к подсети клиента. Значение поля Link-Address позволяет серверу правильно определить область, из которой следует назначить адрес. Поле Peer-Address (16 байт) содержит IPv6-адрес клиента, являющегося исходным отправителем сообщения, или предыдущего агента ретрансляции. За полем Peer-Address следуют параметры протокола DHCPv6, в том числе параметр Relay Message, содержащий ретранслируемое сообщение, и другие. Параметр Relay Message обеспечивает инкапсуляцию сообщений, которыми обмениваются клиент и сервер.
В протоколе IPv6 не предусмотрены широковещательные адреса. По этой причине ограниченный широковещательный адрес, применявшийся при передаче некоторых сообщений протокола DHCPv4, в DHCPv6 заменен адресом All_DHCP_Relay_Agents_and_Servers (все агенты ретрансляции и серверы протокола DHCP), имеющим значение FF02::1:2. К примеру, клиент DHCPv6, пытающийся определить местонахождение сервера DHCPv6 в сети, должен отправить со своего локального адреса канала по адресу FF02::1:2 сообщение Solicit (обращение). Если в подсети узла есть сервер DHCPv6, он получает это сообщение и отправляет соответствующий ответ. Впрочем, как правило, сообщение Solicit (обращение) получает агент ретрансляции протокола DHCPv6, находящийся в подсети узла, после чего оно передается на сервер DHCPv6.
Figure 3 Structure of messages between relay and server
Figure 3 Structure of messages between relay and server (Щелкните изображение, чтобы уменьшить его)
Figure 3 Structure of messages between relay and server
Figure 3 Structure of messages between relay and server (Щелкните изображение, чтобы увеличить его)

Обмен сообщениями с сохранением состояния
Обмен сообщениями протокола DHCPv6 с сохранением состояния, предназначенный для получения IPv6-адресов и параметров настройки (когда флаги M и O в полученном объявлении маршрутизатора имеют значение 1), обычно выглядит следующим образом:
  • для обнаружения серверов клиент отправляет сообщение Solicit (обращение);
  • сервер отправляет сообщение Advertise (объявление), подтверждая этим возможность предоставления адресов и параметров настройки;
  • клиент запрашивает адреса и параметры настройки у конкретного сервера путем отправки сообщения Request (запрос);
  • сервер в ответ отправляет сообщение Reply (ответ) с запрошенными адресами и параметрами настройки.
Если в качестве посредника между клиентом и сервером выступает агент ретрансляции, он передает серверу сообщения Relay-Forward (ретрансляция-пересылка) с инкапсулированными сообщениями Solicit (обращение) и Request (запрос), поступающими от клиента. Сервер передает агенту ретрансляции сообщения Relay-Reply (ретрансляция-ответ) с инкапсулированными сообщениями Advertise (объявление) и Reply (ответ), предназначенными для клиента. Полный перечень сообщений протокола DHCPv6 см. на рис. 4.
Figure 4 Сообщения протокола DHCPv6 (Close Figure 4)

Сообщение DHCPv6 | Описание | Эквивалент в DHCP для IPv4
Solicit (обращение) | Отравляется клиентом локальным серверам. | DHCPDiscover
Advertise (объявление) | Отправляется сервером в ответ на сообщение Solicit (обращение) в качестве свидетельства доступности. | DHCPOffer
Request (запрос) | Отправляется клиентом с целью запросить у конкретного сервера адреса или параметры настройки. | DHCPRequest
Confirm (подтверждение) | Отправляется клиентом всем серверам с целью проверки соответствия конфигурации клиента требованиям установленного канала связи. | DHCPRequest
Renew (обновление) | Отравляется клиентом определенному серверу для продления срока аренды выделенных адресов и получения обновленных параметров настройки. | DHCPRequest
Rebind (повторная привязка) | Отправляется клиентом любому серверу, если ответ на ранее отправленное сообщение Renew (обновление) не получен. | DHCPRequest
Reply (ответ) | Отправляется сервером конкретному клиенту в ответ на сообщения Solicit (обращение), Request (запрос), Renew (обновление), Rebind (повторная привязка), Information-Request (запрос данных), Confirm (подтверждение), Release (освобождение) и Decline (отклонение). | DHCPAck
Release (освобождение) | Отправляется клиентом в связи с отказом от применения ранее назначенного адреса. | DHCPRelease
Decline (отклонение) | Отправляется клиентом конкретному серверу в качестве оповещения о том, что выделенный адрес уже используется. | DHCPDecline
Reconfigure (перенастройка) | Отправляется сервером клиенту в качестве оповещения о том, что на сервере появились новые или обновленные параметры настройки. После этого клиент отправляет одно из двух сообщений: Renew (обновление) или Information-Request (запрос данных). | £
Information-Request (запрос данных) | Отправляется клиентом для запроса параметров настройки (без адреса). | DHCPInform
Relay-Forward (ретрансляция-пересылка) | Отправляется агентом ретрансляции с целью пересылки клиентского сообщения серверу. Внутри сообщения Relay-Forward (ретрансляция-пересылка) в качестве параметра Relay-Message протокола DHCPv6 размещается инкапсулированное сообщение клиента. | £
Relay-Reply (ретрансляция-ответ) | Отправляется сервером для передачи клиенту сообщения через агента ретрансляции. Внутри сообщения Relay-Reply (ретрансляция-ответ) в качестве параметра Relay-Message протокола DHCPv6 содержится инкапсулированное сообщение сервера. | £

Обмен сообщениями без сохранения состояния
Обмен сообщениями протокола DHCPv6 без сохранения состояния, предназначенный для получения исключительно параметров настройки (когда флаг M в полученном объявлении маршрутизатора имеет значение 0, а флаг O £ значение 1), обычно выглядит следующим образом: клиент DHCPv6 отправляет сообщение Information-Request (запрос данных), запрашивая у сервера параметры настройки, а тот передает сообщение Reply (ответ) с запрошенными параметрами.
В сети IPv6 с маршрутизаторами, настройки которых позволяют назначать узлам IPv6 префиксы адресов без сохранения состояния, подобная схема обмена протокола DHCPv6, состоящая из двух сообщений, позволяет назначать DNS-серверы, доменные имена службы DNS и другие параметры настройки, которые не указываются в объявлении маршрутизатора.

Поддержка протокола DHCPv6 в системе Windows
В операционную систему Windows Vista™, а также в следующую версию системы Windows Server® с кодовым названием «Longhorn» включен клиент протокола DHCPv6. В зависимости от значений флагов M и O, содержащихся в полученных объявлениях маршрутизатора, клиент пытается использовать настройки на основе протокола DHCPv6. Следовательно, для работы с протоколом DHCPv6 нужно выполнить настройку серверов и агентов ретрансляции таким образом, чтобы они могли обслуживать все подсети IPv6, а затем настроить маршрутизаторы IPv6, чтобы они присваивали двум вышеупомянутым флагам соответствующие значения. Если в отдельно взятой подсети присутствует несколько передающих объявления маршрутизаторов, их нужно настроить так, чтобы они объявляли одни и те же префиксы адресов без сохранения состояния и одинаковые значения флагов M и O. Узлы IPv6, работающие под управлением операционной системы Windows® XP или Windows Server 2003, не имеют клиентов DHCPv6 и по этой причине не учитывают значения флагов M и O в получаемых объявлениях маршрутизаторов.
Чтобы настроить маршрутизатор IPv6 под управлением операционной системы Windows Vista или Windows Server «Longhorn» на присвоение в объявлениях маршрутизатора флагу M значения 1, выполните команду «netsh interface ipv6 set interface InterfaceName managedaddress=enabled». Аналогично, чтобы в объявлениях маршрутизатора присваивать флагу O значение 1, запустите команду «netsh interface ipv6 set interface InterfaceName otherstateful=enabled».
В бета-версии 2 операционной системы Windows Server «Longhorn» реализована поддержка агента ретрансляции DHCPv6 и настройка с помощью службы DHCP-сервера протокола DHCPv6 без сохранения состояния. Службу DHCP-сервера можно настроить таким образом, чтобы параметры протокола DHCPv6 распространялись всем клиентам DHCPv6 с помощью описанной выше процедуры обмена из двух сообщений. Корпорация Майкрософт планирует в бета-версии 3 операционной системы Windows Server «Longhorn» реализовать поддержку режима DHCPv6 с сохранением состояния, в том числе возможность создания областей адресов IPv6 с помощью оснастки DHCP.
Ресурсы RFC, касающиеся протокола DHCPv6
Документы RFC, имеющие отношение к протоколу DHCPv6:
  • RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Протокол динамической настройки хостов для IPv6 (DHCPv6)) (на английском языке)
  • RFC 2462 IPv6 Stateless Address Autoconfiguration (Автоматическая настройка IPv6-адресов без сохранения состояния) (на английском языке)
  • RFC 3633 IPv6 Prefix Options for DHCP version 6 (Параметры префиксов IPv6 для протокола DHCP версии 6) (на английском языке)
  • RFC 3646 DNS Configuration Options for DHCPv6 (Варианты настройки службы DNS для DHCPv6)
  • RFC 3736 Stateless DHCP Service for IPv6 (Работа службы DHCP без сохранения состояния в среде IPv6) (на английском языке)

Джозеф Дэвис (Joseph Davies) работает техническим писателем в корпорации Майкрософт. С 1992 года занимается преподаванием и пишет о сетях ОС Windows. Джозеф Дэвис написал пять книг, опубликованных издательством Microsoft Press, и ведет ежемесячную рубрику «Кабельщик» в журнале TechNet Magazine.


 Windows Powershell: Возможности переменных
Windows Powershell
Возможности переменных
Дон Джонс (Don Jones)

Если вы работаете с языками сценариев на основе Windows, такими как VBScript или KiXtart, вы знаете, что переменная это просто удобное «приспособление» для хранения данных. В языке Windows PowerShell тоже есть переменные, но они, в отличие от переменных в более старых языках сценариев, предоставляют разработчикам куда больше возможностей.
Переменные PowerShell фактически сопоставимы с основными классами платформы Microsoft® .NET Framework. А в .NET Framework переменные являются объектами, а это значит, что с данными, хранящимися в переменных, можно производить различные операции. Именно благодаря огромным функциональным возможностям переменных, в языке сценариев Windows PowerShell™ отсутствуют встроенные функции обработки данных; в них не нужды £ необходимая функциональность обеспечивается самими переменными.

Объявление переменных
Для объявления переменной и присвоения ей значения можно использовать командлет New-Variable, но можно поступить проще £ создать переменную и присвоить ей значение:
$var = "Hello"

Имена переменных в PowerShell всегда начинаются со знака доллара ($) и могут содержать цифры, буквы, символы и даже пробелы (при использовании пробелов необходимо заключить переменную в фигурные скобки таким образом: ${My Variable} = "Hello"). В этом примере мы создали переменную с именем $var и присвоили ей значение «Hello». Поскольку в данном случае значение переменной это строка, состоящая из символов, PowerShell присвоит переменной тип String (Строковый). В терминах .NET Framework это класс System.String, обладающий, возможно, из всех типов переменных наибольшим количеством встроенных функций. Допустим, мы хотим, чтобы значение переменной $var выводилось только символами в нижнем регистре. Это можно сделать следующим образом:
PS C:\> $var.ToLower()
hello
PS C:\>
Метод ToLower встроен в класс System.String class и результатом его применения будет представление значения строковой переменной символами в нижнем регистре. При этом значение переменной $var остается неизменным. Чтобы увидеть полный список возможностей класса System.String, передайте строковую переменную командлету Get-Member:
$var | get-member
На рис. 1 показан результат этой операции £ пара десятков методов для обработки строковых переменных. Практически все возможности функций обработки строковых данных VBScript присутствуют в методах строковых переменных Windows PowerShell.
Figure 1 A look at the System.String class output
Figure 1 A look at the System.String class output (Щелкните изображение, чтобы уменьшить его)
Figure 1 A look at the System.String class output
Figure 1 A look at the System.String class output (Щелкните изображение, чтобы увеличить его)

При администрировании многие возможности строковых переменных оказываются более полезными, нежели функции обработки строк в языках типа VBScript. Предположим, вы написали сценарий, считывающий из файла пути с универсальными именами (UNC) и производящий над ними какие-либо действия. Прежде чем использовать считанный путь для своих целей, необходимо убедиться, что каждый он действительно имеет универсальное имя. Метод StartsWith позволяет убедиться, что строка начинается с двойной обратной косой черты, являющейся необходимым атрибутом стандарта UNC:
PS C:\> $path = "\\Server\Share"
PS C:\> $path.StartsWith("\\")
True
PS C:\>
Поскольку метод StartsWith возвращает значения True («Истина») или False («Ложь»), он применяется в логических построениях:
if ($path.StartsWith("\\")) {
 # code goes here
}
В Windows PowerShell имеется функция автозаполнения в методах переменных, что позволяет сэкономить время, затрачиваемое на ввод с клавиатуры. Если переменная $var имеет строковое значение, введите следующее:
$var.
и затем нажмите клавишу Tab. Появится первое имя метода переменной $var. При повторном нажатии клавиши Tab появится следующий метод, а при нажатии клавиш Shift+Tab £ предыдущий. Таким образом можно просмотреть все доступные методы и выбрать нужный.

Путаница
В примерах, приведенных выше, тип переменных определялся автоматически. Присваивание переменной строкового значения приводит к тому, что переменная будет принадлежать к классу System.String. Присваивание переменной численного значения, как правило, приводит к тому, что переменная будет принадлежать к классу Integer (Цело число), а точнее £ Int32, классу с определенным диапазоном значений. Рассмотрим следующий пример:
PS C:\> $int = 5
PS C:\> $int | get-member

  TypeName: System.Int32
Одинокая строка на выходе £ результат того, что Windows PowerShell воспринимает переменную $int как переменную класса Int32, который имеет собственный набор методов и свойств, которых, кстати, значительно меньше, чем у типа String.
Переменной $int стала переменной класса Int32, поскольку ее значение не было заключено в кавычки и состояло только из цифр. Если бы значение было заключено в кавычки, переменная была бы воспринята как переменная класса System.String.
Автоматическое определение типа переменных не всегда приводит к желаемым результатам. Допустим, вы при считывании значений из файла необходимо, чтобы они обрабатывались как строковые данные. Но некоторые значения могут состоять только из цифр, а это значит, что Windows PowerShell может обрабатывать их как переменные типа Int32 или другого численного типа. Это может привести к нежелательным последствиям, а именно: если PowerShell не распознает значение переменной как строковое, методы класса System.String недоступны (соответственно в сценарии будет использоваться один из недоступных методов).
Чтобы избежать этого, можно объявить тип переменной при ее создании. В этом случае Windows PowerShell будет обрабатывать ее как переменную объявленного типа. Приведем пример:
[string]$var = 5
Переменная $var была бы переменной типа Int32, если бы мы не объявили ее переменной типа String, что позволяет применять к ней все методы класса System.String. Кроме того, объявление типа переменной придает сценарию большую наглядность, поскольку теперь у нас не возникает сомнений относительно типа данных, хранящихся в переменной $var. Я вообще взял за правило самостоятельно объявлять тип каждой переменной, отобрав право выбора у Windows PowerShell. Благодаря этому поведение моих сценариев более предсказуемо. Кроме того, я несколько раз сэкономил время при отладке
Как вы догадываетесь, принудительное объявление переменных влечет за собой различные последствия, причем не всегда плачевные. Рассмотрим пример, в котором тип переменной не объявляется:
PS C:\> $me = 5
PS C:\> $me = "Don"
Сначала переменная $me была переменной типа Int32, но Windows PowerShell изменил ее тип на String, когда было присвоено значение "Don". Windows PowerShell может изменять тип переменной по мере необходимости, в случае если тип переменной не был предварительно объявлен.
В следующем примере мы объявляем переменную $me переменной типа Int32 с помощью имени типа [int]:
PS C:\> [int]$me = 5
PS C:\> $me = "Don"
Cannot convert value "Don" to type
"System.Int32". Error: "Input string
was not in a correct format."
At line:1 char:4
+ $me <<<< = "Don"
Затем мы присваиваем ей строковое значение, в результате чего появляется сообщение об ошибке. Поскольку тип переменной $me был принудительно задан (Int32), Windows PowerShell попытался преобразовать строку "Don" в целое число. Это не удалось; также не удалось поменять тип переменной $me на String.

Типы переменных
В Windows PowerShell существует множество типов переменных. Более того, допустимо использование всех типов .NET Framework (количество таких типов исчисляется сотнями). Тем не менее, в Windows PowerShell имеются сокращенные имена для наиболее распространенных типов данных. На Рис. 2 приведен неполный список из 10-ти наиболее часто используемых сокращенных имен типов переменных. Полный список приведен в документации Windows PowerShell.
Figure 2 Сокращенные имена типов переменных (Close Figure 2)

Сокращенное имя | Тип данных
[datetime] | Время или дата
[string] | Строка символов
[char] | Один символ
[double] | Число с плавающей запятой двойной точности
[single] | Число с плавающей запятой одинарной точности
[int] | Целое число, 32 бита
[wmi] | Экземпляр или коллекция WMI
[adsi] | объект служб Active Directory
[wmiclass] | класс WMI
[Boolean] | значения «Истина» или «Ложь»
Кроме того, вы можете объявлять тип переменных, используя полное имя класса .NET Framework, например:
[System.Int32]$int = 5
Такой метод позволяет использовать типы .NET Framework, не имеющие сокращенных имен в Windows PowerShell.

Расширение типов
Расширение функций типов переменных £ возможно, самая потрясающая особенность Windows PowerShell. В папке установки Windows PowerShell (как правило, расположенной в %systemroot\system32\windowspowershell\v1.0, но 64-битных системах ее расположение будет несколько иным) находится файл types.ps1xml. Этот файл можно редактировать в Блокноте или в XML-редакторе, например в PrimalScript. По умолчанию класса System.String в файле нет, несмотря на присутствие множества других типов переменных. Тем не менее, мы можем добавить новую функцию типу System.String, внеся его в файл types.ps1xml.
Чтобы изменения вступили в силу, необходимо закрыть и заново открыть Windows PowerShell. Также необходимо убедиться, что локальная политика выполнения сценариев допускает выполнение сценариев без подписи, поскольку мы не подписали файл types.ps1xml:
Set-executionpolicy remotesigned
Теперь, перезапустив Windows PowerShell, мы можем воспользоваться новыми функциями, например:
PS C:\> [string]$comp = "localhost"
PS C:\> $comp.canping
True
PS C:\>
Как видите, мы добавили свойство CanPing в класс System.String. На выходе мы получим True («Истина») или False («Ложь»), т.е. может ли локальный компьютер установить связь по адресу, содержащемуся в строке. На Рис. 3 мы видим, что в запросе WMI используется специальная переменная $this. В этой переменной содержится текущее значение строки и способ передачи содержимого строки в запрос WMI.
Figure 3 Расширение типа System.String (Close Figure 3)
<Type>
  <Name>System.String</Name>
  <Members>
    <ScriptProperty>
      <Name>CanPing</Name>
      <GetScriptBlock>
      $wmi = get-wmiobject -query "SELECT *
FROM Win32_PingStatus WHERE Address = '$this'"
      if ($wmi.StatusCode -eq 0) {
        $true
      } else {
        $false
      }
      </GetScriptBlock>
    </ScriptProperty>
  </Members>
</Type>

Заключение
Windows PowerShell содержит универсальные и многофункциональные типы переменных, а также предлагает гибкую систему расширения их функций. Это позволяет с легкостью создавать сценарии с очень широкими возможностями. Переменные могут стать основными блоками в составных сценариях, выполняя работу гораздо более сложных по написанию функций.
И это еще не все
Смотрите наши веб-трансляции, которые проходят каждый второй вторник месяца, где вы сможете продолжить погружение в мир богатых возможностей сценариев Windows PowerShell. Посетите веб-узел microsoft.com/events/series/donjonesscripting.mspx (на английском языке), где вы можете зарегистрироваться прямо сейчас.

20-е февраля 2007г. Windows PowerShell: Интенсивный курс программирования
На этой часовой веб-трансляции вы узнаете о переменных, конструкциях, сценариях и функциях Windows PowerShell. Мы продемонстрируем, как просто, но эффективно ускорить автоматизацию администрирования Windows ® средствами языка сценариев Windows PowerShell. Мы также расскажем о средствах сторонних разработчиков, максимально облегчающих написание сценариев в Windows PowerShell.

20-е марта 2007г. Windows PowerShell: Функции, фильтры и эффективность.
Мы расскажем, как создать эффективный модульный код с помощью функций и фильтров Windows PowerShell. Мы познакомим вас с надежными правилами обзора данных в Windows PowerShell, позволяющим объединять функции и фильтры, и объясним, как вы можете легко заново использовать их в разных проектах. Кроме того, мы покажем, как добавлять пользовательские функции в глобальный контекст Windows PowerShell, что позволит вам создать библиотеку необходимых функций, которые будут всегда под рукой.

17-е апреля 2007г. Windows PowerShell и Инструментарий управления Windows (WMI)
Windows PowerShell дает возможность доступа ко всем мощным средствам WMI. Мы расскажем не только о том, как осуществляется доступ к средствам WMI посредством Windows PowerShell, но и о том, как передавать объекты и коллекции WMI по конвейеру Windows PowerShell. Мы продемонстрируем, как использовать методы и свойства WMI в сценариях Windows PowerShell, а также расскажем об основных функциях настройки и обеспечения безопасности WMI.

22-е мая 2007г. Windows PowerShell: Переход с VBScript на PowerShell
Хотите переписать ваши сценарии, или полностью перейти с VBScript на Windows PowerShell? В этой веб-трансляции мы расскажем, как это сделать. Мы покажем, что Windows PowerShell содержит все основные конструкции и возможности VBScript, благодаря чему вы с легкостью сможете применить ваши знания VBScript в новой среде управления. Мы продемонстрируем, как записать функции VBScript на языке сценариев Windows PowerShell. Мы познакомим вас с уникальной структурой Windows PowerShell и покажем, как язык Windows PowerShell может сделать вашу работу более продуктивной и эффективной.

June 19, 2007 Windows PowerShell: Расширенеие возможностей
Из этой трансляции вы узнаете, как с помощью Windows PowerShell воспользоваться мощными и универсальными средствами среды .NET Framework для управления данными £ сотнями встроенных функций для обработки строк, дат и других типов данных. А знаете ли вы, что эти функции можно расширить с помощью сценариев Windows PowerShell? Мы расскажем, как создать строковую переменную, которая будет содержать данные не только об имени компьютера, но и о том, включен ли он в данный момент. Вы узнаете об автоматическом форматировании переменных времени и даты без применения внешних функций. Хотите узнать, как, встраивая самые различные новые функции в Windows PowerShell в течение нескольких минут, сделать администрирование Windows быстрее и проще? Смотрите нашу веб-трансляцию.

Дон Джонс (Don Jones) £ директор по проектам и услугам компании SAPIEN Technologies и соавтор книги "Windows PowerShell: TFM" (изд. SAPIEN Press, 2006).trusted facility manual C ним можно связаться через веб-узел www.ScriptingAnswers.com.


 Эй, программист!: Отвечаем на ваши вопросы о подразделениях... всего за 5 центов
Эй, программист!
Отвечаем на ваши вопросы о подразделениях... всего за 5 центов
Группа Microsoft Scripting Guys
Загрузить исходный код для этой статьи: HeyScriptingGuy2007_03.exe (151KB)

Вопрос: Как вызвать диалоговое окно для выбора подразделения из службы каталогов Active Directory?

ЗНАЕТЕ, если бы наша группа получала по 10 центов каждый раз, когда нам задают этот вопрос, у нас бы было... на самом деле, получилось бы только 37 долларов и 15 центов, да? Но вот если бы нам заплатили по 10 центов за каждого, кто хочет задать этот вопрос, но так и не задал, вот тогда, у нас бы сейчас... впрочем, сумма не важна. В конце концов, мы здесь работаем не из-за денег. Мы здесь работаем, потому что нам нравится помогать людям проще и быстрее решать задачи системного администрирования.
Примечание. Ну ладно. Строго говоря, пришли мы сюда работать, конечно, из-за денег. Но когда наш начальник нам сказал: «Ребята, вы можете хорошо жить и много зарабатывать, только если вы готовы много работать и выдавать только самый высококлассный продукт». Вот тут мы подумали, что деньги £ это далеко не все.
Неважно. Важно то, что очень многие хотят узнать, как вызвать диалоговое окно, в котором можно выбрать подразделение, а затем подключиться к этому подразделению посредством сценария. Недавно нам написал один пользователей: «Вы рассказали, как вызывать диалоговое окно для выбора папок. Вы рассказали, как вызывать диалоговое окно для выбора файлов. Почему же вы не рассказали о том, как вызвать диалоговое окно, в котором можно выбрать подразделение из Active Directory®?».
Да, правда. В этой статье (на английском языке) мы рассказали, как вызывать диалоговое окно, в котором можно выбрать нужную папку. Кроме того, мы рассказали, как вызывать диалоговое окно для выбора файлов. Если не верите, зайдите вот сюда: microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx (статья на английском языке). Обе статьи были приняты доброжелательно. И мы точно знаем, что читатели используют эти методы в своих сценариях. Почему же тогда мы не рассказали, как вызывать диалоговое окно для выбора подразделений из Active Directory? Это что, тайный сговор сотрудников корпорации Майкрософт?
Конечно, нет. (Стоп. Именно так и ответил бы участник тайного сговора, правда?) На самом деле, существует вполне уважительная причина, по которой мы не рассказали никому о том, как вызвать такое окно £ его просто не существует. В бейсболе говорят, нельзя отбить то, чего не видишь. Перефразируем это утверждение применительно к сценариям: нельзя вызвать то, чего нет.
Ну, значит, на этом и закончим. До встречи через месяц.
Увы! Наш редактор в журнале TechNet Magazine нам сказал, что нет, на этом мы не закончим. «Ну и что, что такого окна не существует», £ говорит он нам. «Вы же Scripting Guys! Создайте его. Я думал, что когда дело касается сценариев, вы может все».
Разумеется, редакторов журнала TechNet Magazine кто-то жестоко обманул. Можем все, когда дело касается сценариев? Не совсем. По правде говоря, что касается сценариев, мы умеем делать только одну вещь.
К счастью, «одна вещь» £ это создание диалогового окна для выбора подразделения из Active Directory. Взгляните на Рис. 1.
Довольно длинный сценарий, правда? Но знаете, как говорят: нельзя приготовить омлет, не разбив яиц. Ну вот, создать диалоговое окно, не разбив нескольких яиц, тоже не получается (к этому моменту мы очень проголодались и нам пришлось прерваться, чтобы перекусить). Итак, утолив голод, попробуем объяснить, как все это работает.
В нашем сценарии объектная модель обозревателя Internet Explorer® используется для создания псевдо-диалогового окна. Мы создадим экземпляр Internet Explorer, возьмем коллекцию подразделений из Active Directory, а затем выведем список подразделений в окне Internet Explorer. Теперь дождемся, когда пользователь выберет подразделение, получим путь выбранного объекта в Active Directory и закроем «диалоговое окно».
Примечание. А ведь правда это будет очень красивое и стильное окошко? Конечно, если считать красивым минималистический шедевр, у которого даже нет кнопок «OK» или «Отмена». В свою защиту скажем, что нашей задачей было объяснить главное. А наводить красоту £ это уж вы сами.
(Эх, если бы нам платили по 10 центов каждый раз, когда мы говорим «это уж вы сами», мы были бы богаты. Пожертвования для группы Scripting Guys принимаются в журнале TechNet Magazine.)
Ради того, чтобы объяснения основного метода поместились на пространстве, выделяемом нам в журнале, приходится многим жертвовать. Например, в следующем фрагменте кода создается экземпляр Internet Explorer размерами 350 на 400 пикселей, из-за этого строка состояния и адресная строка не видны:
Set objExplorer = CreateObject( _
    "InternetExplorer.Application")

objExplorer.Navigate "about:blank"
objExplorer.ToolBar = 0
objExplorer.StatusBar = 0
objExplorer.Width= 350
objExplorer.Height = 400
objExplorer.Left = 400
objExplorer.Top = 400
objExplorer.Visible = 1
Естественно, это всего лишь пустое окно Internet Explorer. Для получения списка подразделений в домене необходимо провести поиск в Active Directory. Мы не будем углубляться в тонкости поиска в Active Directory Подробная информация об этом представлена в статье на веб-узле Script Center по адресу: microsoft.com/technet/scriptcenter/resources/tales/sg0405.mspx (на английском языке). Здесь мы лишь приведем фрагмент кода, который получает имя (Name) и путь в Active Directory (ADsPath) для каждого подразделения в домене fabrikam.com:
objCommand.CommandText = _
    "SELECT Name, ADsPath FROM 'LDAP://DC=fabrikam,DC=com' WHERE objectCategory=
    'organizationalUnit' ORDER BY Name"
Для удобства мы добавили оператор ORDER BY Name, который сортирует подразделения по имени в алфавитном порядке. (Все для вас.)
При вызове метода Execute возвращается список всех подразделений домена fabrikam.com. Следующий шаг £ вывести все подразделения в окне списка.
Как это сделать? Сначала нужно создать полный список в памяти. Для новичков: это значит сохранить тэг <SELECT> в переменной strHTML следующим образом:
strHTML = "<select size = '20' name='OUList' style='width:300px'>"
Что делает эта строка? Мы просто создаем стандартное окно списка HTML (то, что обычно делается с помощью тэга <SELECT>). Попутно мы присваиваем списку имя OUList и указываем количество одновременно отображаемых записей (20) и ширину 300 пикселей (300px). Если вы хоть немного знакомы HTML, приведенная выше строка не вызовет у вас затруднений.
Далее нам нужно добавить в наш список элементы (т.е. подразделения). По совершенно невероятному стечению обстоятельств наш список записей содержит данные обо всех подразделениях домена. Поэтому мы используем цикл Do Until, который будет перебирать все записи списка, получать данные и добавлять каждое подразделение в окно списка. Добавление подразделений в цикле происходит следующим образом (для добавления элементов в окно списка используется стандартный код HTML): элементы настраиваются таким образом, чтобы их имена (свойтво Name) отображались в списке, а при выборе определенного подразделения его путь (свойство ADsPath ) передается в сценарий.
strHTML = strHTML & "<option value= " & _
    Chr(34) & objRecordSet.Fields
    ("AdsPath").Value & Chr(34)
strHTML = strHTML & ">" & objRecordSet.
    Fields("Name").Value
Зачем передавать путь к подразделению в сценарий? Это просто: Предположим, мы передаем не путь, а имя подразделения. Если имя, например, Finance, будет трудно осуществить привязку к этому подразделению. Прежде всего, «Finance» не является строкой привязки в интерфейсе служб каталогов Active Directory (ADSI). А если использовать путь (LDAP://ou=Finance,dc=fabrikam,dc=com), привязка осуществляется элементарно. Потому что путь £ это именно то, что нужно для того, чтобы найти и подключиться к объекту в Active Directory.
Между прочим, нужно заметить, в окне списка мы выводим имена подразделений, предполагая, что они уникальны. Может статься, что это не так. Например, подразделения North America\Research и Europe\Research имеют одно имя (Research). В таком случае, возможно, придется отображать другое свойство, скажем, ADsPath или еще какое-нибудь. Решайте сами. (Дзынь! Еще 10 центов!)
Обратите внимание, мы продолжаем создавать список в памяти: каждый элемент, добавленный в окно, добавляется в переменную strHTML. Так и задумано: мы сохраняем весь код окна списка в переменную strHTML, а затем используем значение этой переменной для добавления списка в экземпляр Internet Explorer.
После добавления всех подразделений для обозначения конца списка мы пишем следующую строку:
strHTML = strHTML & "</select>"
Теперь переменная strHTML содержит все тэги, необходимые для создания окна списка, и £ самое главное £ окно списка, каждый элемент которого представляет подразделение в Active Directory. Это значит, что теперь мы можем присвоить значение strHTML свойству нашего документа Internet Explorer £ InnerHTML:
objExplorer.Document.Body.InnerHTML = strHTML
Это, в свою очередь, дает нам окно списка всех подразделений в домене.
Стойте, не уходите. Мы еще не закончили. Во-первых, нам необходимо остановить работу нашего сценария, чтобы пользователь имел возможность выбрать нужное подразделение. Если этого не сделать, список будет отображаться, но сценарий будет продолжать работать, не реагируя на выбор пользователя. Ужасно. Чтобы этого избежать, добавьте следующий блок:
Do While objExplorer.Document.Body.All.OUList.Value = ""
    Wscript.Sleep 300
Loop
Здесь постоянно проверяется значение свойства Value нашего списка (который, если помните, мы назвали OUList £ так зовут дочь одного из наших сотрудников). Если значение Value £ пустая строка (что означает, что элемент не выбран), работа сценария приостанавливается на 300 миллисекунд, и затем все повторяется снова. Это будет продолжаться: а) вечно; б) до тех пор, пока пользователь не выберет элемент из списка; в) пока пользователь не закроет окно Internet Explorer.
Предположим, пользователь все же выбрал подразделение из списка. В этом случае мы берем свойство Value (если вы помните, это путь к подразделению £ свойство ADsPath ) и присваиваем его значение переменной strTargetOU:
strTargetOU = objExplorer.Document.Body.All.OUList.Value
Затем мы закрываем экземпляр Internet Explorer с помощью метода Quit:
objExplorer.Quit
Итак, мы почти закончили. Сначала мы выясняем, является ли значение strTargetOU пустой строкой:
If strTargetOU = "" Then
    Wscript.Quit
End If
Если является, значит, пользователь закрыл Internet Explorer, не выбрав подразделение. Тогда мы используем метод Wscript.Quit для выхода из сценария. (Предполагается, что если пользователь не выбирает подразделение, он или она не испытывают потребности в работе сценария в данный момент.) Если же значение strTargetOU не пустая строка, тогда мы выводим на экран ее значение:
Wscript.Echo strTargetOU
Конечно, в реальной жизни вы скорее всего осуществите привязку к этому подразделению вместо того, чтобы просто выводить на экран его путь. Но... знаете что? Это уж вы сами.
Как говорилось выше и как можно видеть на Рис. 2, это далеко не самое красивое диалоговое окно. Но оно работает. Согласитесь, что это гораздо проще, чем вводить путь подразделения (для этого его еще нужно знать). Кроме того, вы можете изменить код и диалоговое окно соответственно вашим потребностям.
Figure 2 A simple script dialog
Figure 2 A simple script dialog

Эх, если бы нам платили по 10 центов за каждую статью, в которой рассказывалось, как вызвать диалоговое окно для выбора подразделения из службы каталогов Active Directory... В любом случае, это было бы на 5 центов больше, чем нам обычно платят в журнале TechNet Magazine.
Учтите, мы не жалуемся.

Группа Microsoft Scripting Guys работают... ну хорошо, числятся в корпорации Майкрософт. Когда они не играют в бейсбол, не тренируют бейсбольную команду, не смотрят бейсбол и не занимаются другими делами, они ведут проект Script Center в журнале TechNet. Веб-узел проекта: www.scriptingguys.com.


 Exchange Queue £ очередь за ответами: Журналы транзакций, командлеты, удаленное управление и многое другое
Exchange Queue £ очередь за ответами
Журналы транзакций, командлеты, удаленное управление и многое другое
Кей Си Лемсон (KC Lemson) and Нино Билич (Nino Bilic)

Вопрос. Зачем в Microsoft® Exchange Server 2007 вы уменьшили размер журнала транзакций до 1 МБ?
Ответ. В Exchange 2007 есть такая отличная штука, которая называется «доставка журналов», £ метод, лежащий в основе ряда новых функций, в частности, локальной непрерывной репликации (LCR) и кластерной непрерывной репликации (CCR). Когда доставка журналов включена на уровне группы хранения (SG), журналы транзакций SG копируются из работающей производственной SG в SG-копию. Транзакции из журналов SG-копии записываются в базу данных для ее обновления. Это, конечно, упрощенное объяснение того, что там происходит, но картина, надеемся, в целом ясна.
Все дело в том, что журналы транзакций не могут быть отправлены в SG-копию, пока журнал не будет закрыт в производственной SG. Иными словами, журнал e00 (текущий журнал первой группы хранения) нельзя отправить до тех пор, пока он не будет заполнен, закрыт и переименован. Кроме того, специальные параметры определяют, сколько журналов может быть задействовано в этом процессе, так как должен поддерживаться баланс между доступностью и производительностью. (Доступ к этим параметрам осуществляется с помощью запуска командлета Set-MailboxServer в среде управления Exchange. Сведения о необходимых параметрах можно получить в справочном файле.)
Короче говоря, мы уменьшили размер журнала транзакций, чтобы сократить до минимума объем данных, которые могут остаться несинхронизированными между двумя копиями группы хранения. Это важно, например, когда после сбоя жесткого диска производственной базы данных приходится запускать SG из копии. Чем меньше журналы транзакций, тем меньше потери данных.
Однако гарантии, что будет потерян только 1 мегабайт данных, нет. Нельзя, например, исключить возможность, что потерянный 1-мегабайтный журнал транзакций будет содержать операцию COMMIT для 5 МБ данных. В этом случае в копии будут потеряны все 5 МБ данных, даже если будут скопированы пять 1-мегабайтных журналов с самими данными, последний журнал с небольшим количеством данных и операцией COMMIT £ самый главный.
В конечном счете, вам самим решать, приемлем ли такой риск для вашего бизнеса. Небольшая потеря данных и минутное их восстановление £ это все же лучше многих часов восстановительной работы. Эту тему мы будем освещать и в дальнейшем.

Вопрос. Теперь, когда журналы транзакций стали короче, они будут быстрее «расходоваться»?
Ответ. В Exchange темп «расходования» журналов транзакций связан с их именами. В Exchange Server 2003 имена журналов транзакций выглядят следующим образом:
E nn fffff.log
Здесь nn £ префикс, уникальный для каждой SG. Так как префикс nn остается неизменным на протяжении всего периода существования SG, число журналов транзакций с уникальными именами, которое может быть создано для группы хранения £ по существу, определяется значением FFFFF и может доходить примерно до миллиона (каково!). Некоторые из наших клиентов, однако, сообщали, что на загруженных почтовых серверах удавалось достичь этого предела.
В Exchange Server 2000 и более поздних версиях мы добавили исправление для записи в журнал приложений события в случае приближения к этому пределу. Дополнительную информацию об этом см. в статье по адресу http://support.microsoft.com/kb/896001 (на английском языке).
Ну хорошо, а что происходит в Exchange 2007? Мы говорили о том, что размер журналов транзакций, который раньше был 5 МБ (в предыдущих версиях Exchange), теперь стал 1 МБ (в Exchange 2007). Означает ли это, что уникальные имена журналов транзакций будут исчерпаны после «прокачки» всего одной пятой части данных?
Ответ: нет. В Exchange 2007 имя журнала транзакций имеет следующий формат:
E nn ffffffff.log
Обратите внимание, что теперь в нашем распоряжении FFFFFFFF журналов, в отличие от всего лишь FFFFF в предыдущих версиях Exchange. Внутренний математический алгоритм расширенного обработчика хранилищ (ESE) Exchange 2007 не позволяет создать все FFFFFFFF журналов. Вместо этого Exchange 2007 создает 7FFFFFEC журналов, что все равно является огромным числом (не верите £ преобразуйте его из шестнадцатеричного в десятичный вид!)
Что это означает на практике? На самом деле это означает, что в Exchange 2007 можно создать примерно в 2048 раз больше журналов, чем в предыдущих версиях Exchange. Разделим этот коэффициент числа журналов с учетом теперешней одной пятой их размера:
2048 / 5 = 409.6
Как видите, новая схема именования журналов позволяет обрабатывать в 409 раз больше данных, чем старая. И это при том, что речь идет только об одной группе хранения, а не о сервере, поскольку каждая группа хранения будет иметь свой префикс журналов (такой как e00, e01 и так далее). А если вспомнить, что на одном сервере Exchange 2007 версии Enterprise можно создать 50 SG? Нам трудно себе представить, что кто-то в обозримом будущем сможет исчерпать такое количество журналов транзакций!

Вопрос. Как управлять сервером Exchange 2007 дистанционно?
Ответ. Для удаленного управления серверами Exchange 2007 есть несколько способов. Во-первых, можно установить средства управления Exchange 2007 на отдельную от сервера Exchange машину, если эта машина работает под управлением 32-разрядной или 64-разрядной версии Windows Server® 2003 с пакетом обновления 1 (SP1) или более поздней версии, Windows Server 2003 R2 или Windows XP с пакетом обновления 2 (SP2) или более поздней версии. Следует иметь в виду, что установка любой роли сервера (клиентский доступ, почтовый ящик, пограничный сервер и так далее) на 32-разрядном оборудовании в производственных средах не поддерживается, но установка на 32-разрядной машине средств управления £ поддерживается. Также обратите внимание, что для начального выпуска сервера Exchange Server 2007 установка средств управления не поддерживается на компьютере с Windows Vista™.
В некоторых организациях ИТ-подразделения создают отдельный сервер как сервер управления, установив на нем все необходимые средства управления для различных продуктов. После этого администраторы, которым нужны эти средства, обращаются к серверу управления через сервер терминалов, получая таким образом возможность выполнять удаленное администрирование. В других случаях пользователи устанавливают средства управления в своих локальных настольных системах.
С помощью консоли или оболочки можно выполнять операции на серверах организации. В консоли серверы видны и доступны, поэтому на любом из них можно выполнять удаленные операции. В оболочке для многих задач поддерживаются флаг фильтрации -server, который можно применять, если требуется ограничить область действия операция отдельным сервером. Есть, однако, несколько исключений для команд, которые должны выполняться локально, например команда Get-NetworkConnectionInfo.

Вопрос. В своей последней статье вы говорили, сколько оперативной памяти рекомендуется для сервера Exchange 2007. А как насчет размера файла подкачки?
Ответ. Чтобы исключить на серверах Exchange 2007 потенциальные ошибки нехватки виртуальной памяти, мы рекомендуем при определении размера системного файла подкачки придерживаться следующих правил.
Если на сервере размер ОЗУ меньше 8 ГБ, минимальный размер файла подкачки должен равняться объему ОЗУ плюс 10 МБ. Таким образом, если размер ОЗУ на сервере £ 4 ГБ, минимальный размер файла подкачки должен быть 4 ГБ плюс 10 МБ. Рекомендуемый размер файла подкачки, однако, равен полуторному объему ОЗУ. Поэтому для сервера с объемом ОЗУ, равным 4 ГБ, размер файла подкачки должен быть 6 ГБ.
Далее, минимальный размер файл подкачки для сервера с ОЗУ более чем 8 ГБ рассчитывается аналогично, то есть, объем ОЗУ плюс 10 МБ. Однако рекомендуемый размер определяется иначе. На сервере с более чем 8 ГБ ОЗУ нужно сразу переходить к файлу подкачки, равному полуторному объему ОЗУ, если при меньших файлах подкачки возникают ошибки нехватки виртуальной памяти.
Следует помнить, что ошибки, о которых здесь идет речь, не имеют никакого отношения к фрагментации виртуальной памяти (проблема, характерная для серверов Exchange 2000 и Exchange 2003). Это фактические, регистрируемые системой ошибки, которые говорят о том, что размер файла подкачки увеличивается или файл подкачки слишком мал.

Вопрос. Я бы хотел научиться работать в среде управления Exchange, но никогда раньше не использовал командную строку для управления моими системами. С чего мне начать?
Ответ. Давайте начнем с основ. Каждый командлет в среде управления Exchange состоит из одного глагола-команды и одного существительного-объекта. В среде управления Exchange используется всего несколько команд: Get £ для получения свойств объектов, Set £ для изменения свойств объекта, New £ для создания новых объектов и так далее. Существительные среды управления Exchange представляют различные концепции, хорошо знакомые всем администраторам Exchange (например, Mailbox, Contact, Queue и OWAVirtualDirectory). Есть также новые концепции, введенные в Exchange Server 2007 (такие как TransportRule, StorageGroupCopy и UMAutoAttendant). Таким образом, простой командлет будет выглядеть примерно как New-Mailbox (создание почтового ящика) или Get-Mailbox (получение списка почтовых ящиков организации).
Для большинства командлетов, однако, потребуются дополнительные уточнения того, чего конкретно вы пытаетесь достичь. Чтобы, например, изменить свойство почтового ящика, нужно указать почтовый ящик и свойство. Это делается с помощью параметров. Если бы командлетом было New-Sandwich (создать бутерброд), то в качестве параметров можно было бы указать -NumberOfTomatoSlices 4 (4 ломтика помидора), -Bread Wheat (белый хлеб) и множество других подобных параметров, которые более подробно описывают ваш бутерброд, вплоть до того, какой он вкусный (-FlufferNutter (ореховое масло с алтеем) £ да-да! Мммм... пальчики оближешь!).
Теперь, когда вы поняли суть конструкции «команда-объект», можно воспользоваться командной строкой мастера консоли управления Exchange (EMC) и посмотреть, какие операции выполняют командлеты. В EMC выполните инструкции мастера для создания нового пользователя. В конце работы мастера, после завершения операции вы увидите копию команды, которую мастер выполнил «за кулисами» (см. рис. 1). Нажав Ctrl+C, вы можете скопировать содержимое этого диалогового окна и затем вставить командлет в программу Блокнот, чтобы объединить свои простые пакетные файлы.
Figure 1 Command-line exposure for creating a new user
Figure 1 Command-line exposure for creating a new user (Щелкните изображение, чтобы уменьшить его)
Figure 1 Command-line exposure for creating a new user
Figure 1 Command-line exposure for creating a new user (Щелкните изображение, чтобы увеличить его)
Хороший способ попрактиковаться в использовании командлетов (не вызвав этим каких-либо повреждений в системе) £ поместить в конце команды параметр -WhatIf. При этом система сообщит, что произойдет при выполнении данной команды, без фактического внесения каких-либо изменений в систему.
Ознакомившись с простыми командлетами типа *-Mailbox, вы, вероятно, захотите попробовать и другие. Чтобы найти другие командлеты, воспользуйтесь командлетом Get-ExCommand. Эта команда распечатывает список всех командлетов для управления Exchange. (Для этого среда управления Exchange должна быть запущена. Простого открытия командной оболочки Microsoft Command Shell или Windows PowerShell™ для выполнения этой и любых других задач управления Exchange недостаточно.) Список огромен, поэтому, чтобы найти нужный командлет, используйте соответствующие подстановочные знаки. Например, Get-ExCommand *database* вернет список всех командлетов Exchange, в именах которых имеется элемент «database», £ такие как Dismount-Database, Move-DatabasePath или New-MailboxDatabase.
Если вы знаете часть искомого существительного, можно методом перебора просмотреть все возможные варианты. Например, можно ввести «Get-Mailbox» и затем, нажимая клавишу TAB, просмотреть все командлеты с элементом «mailbox» в существительном названия задачи. Можно даже объединить подстановочные знаки и просмотр клавишей TAB. Например, можно ввести Get-*Mailbox* и просмотреть все возможные варианты.
Еще один простой метод £ использовать подсказку. Каждый командлет имеет ряд параметров, требуемых по умолчанию, £ это основные параметры, необходимые для выполнения операции. Командлеты Get, такие как Get-Mailbox, не требуют каких-либо параметров. По умолчанию Get-Mailbox возвращает список всех почтовых ящиков во всей организации. (По умолчанию в списке возвращается не более 1000 элементов. Чтобы изменить этот максимум, можно, например, ввести Get-Mailbox -ResultSize 2000.) Командлеты, которые создают или изменяют объекты (как Set или New), запрашивают необходимую информацию, например, объект, который нужно создать или изменить. Если выполнить команду New-Mailbox, оболочка последовательно запросит пароль, базу данных, название и так далее.
Для получения дополнительных сведений о возможных параметрах определенного командлета используйте справочную систему: например, введите команду Help Move-DatabasePath. (Можно также ввести только Move-DatabasePath, Move-DatabasePath -? и так далее £ вариантов множество, здесь мы пытаемся охватить лишь основы.) Справка содержит описание командлета, список параметров и назначение каждого из них. Справку можно также открыть с помощью командлета Get-Help. (Нам все же кажется, что добывать сведения о командлете, введя просто Get-Help, не очень удобно. Обычно эту команду используют редко.)
Другой способ узнать возможные параметры командлета £ использовать клавишу TAB для названий параметров. Введите, например, Get-Mailbox -S, нажмите TAB и просмотрите все возможные параметры, которые начинаются с «S».
Ну и есть еще, конечно, обширная справочная система. Если не находите чего-либо в автономной справке, не забывайте проверять регулярно обновляемые справочные материалы на веб-узле go.microsoft.com/fwlink/?linkid=79421 и краткий справочник go.microsoft.com/fwlink/?linkid=64647 (на английском языке).
Все это поможет вам начать осваивать консоль управления Exchange, но дает лишь начальное представление об универсальных возможностях командной строки. В следующих статьях мы продолжим знакомить вас с этой темой.

Вопрос. В диспетчере Exchange Server 2003 (ESM) мы могли легко просмотреть размеры почтовых ящиков всех пользователей. Похоже, что в Exchange 2007 этой функции нет. Есть ли такая возможность в Exchange 2007?
Ответ. С помощью новой консоли Exchange 2007 размер почтового ящика можно получить на общей странице свойств данного почтового ящика. Чтобы просмотреть эти данные для нескольких пользователей, следует воспользоваться средой управления Exchange.
Выполнив командлет Get-MailboxStatistics, вы получите данные по всему серверу (а не только по определенной базе данных). По умолчанию размер почтового ящика не показывается. Чтобы получить эту информацию, нужно выполнить командлет с параметром Format-List:
get-mailboxstatistics | format-list
Еще удобнее может быть возможность выбирать элементы для просмотра и распечатки в таблице. В следующем примере мы получаем отображаемое название почтового ящика, общий размер элементов, общий размер удаленных элементов и базу данных, к которой относится почтовый ящик:
Get-MailboxStatistics | Select-Object
displayname,totalitemsize,
totaldeleteditemsize,databasename
| Format-Table
В зависимости от искомой информации, можно использовать разное форматирование вывода. В этом примере параметр Format-Table предпочтительнее параметра Format-List.

Кей Си Лемсон (KC Lemson) £ главный менеджер программы в группе разработчиков Exchange Server. Ее ПИН-код в банкомате £ 0000 (только не забирайте все в одном месте).
Нино Билич (Nino Bilic), ведущий технолог, проводит свое свободное время, коллекционируя 1000-долларовые чеки от Билла за разбор и пересылку его электронной почты.


 В поисках безопасности: Развертывание файловой системы EFS. Часть 2
В поисках безопасности
Развертывание файловой системы EFS. Часть 2
Джон Морелло (John Morello)

Развертывание любой файловой системы EFS (Encrypting File System £ шифрованная файловая система) всегда сосредоточено вокруг двух элементов: серверной части, с упором на управление сертификатами и агентами восстановления, и пользовательской части файловой системы EFS. В прошлом месяце мы рассматривали серверную часть, обсуждали варианты восстановления данных и ключей,
а также способы предоставления сертификатов клиентам. Теперь мы поговорим об аспектах развертывания, видимых для пользователя, например об усовершенствовании проводника Windows®, выборе элементов файловой системы для шифрования и управлении параметрами шифрования посредством групповой политики.

Как определить, внедрена ли система EFS
После того как решение о развертывании файловой системы EFS принято, нужно в первую очередь определить текущее состояние использования системы EFS в организации. Напомним, что система EFS может работать в автономном режиме, при котором ответственность за создание и резервное копирование ключей шифрования ложится исключительно на конечного пользователя. В организации могут быть опытные пользователи, которые уже применяют систему EFS в таком режиме, так что для беспрепятственного перехода к более управляемому развертыванию данной системы нужно выявить этих пользователей.
При первом использовании системы EFS на компьютере операционная система Windows создает в разделе реестра HKEY_CURRENT_USER элемент следующего содержания.
HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash
Для проверки наличия этого элемента в реестрах компьютеров по всему предприятию можно воспользоваться средствами сервера SMS (Microsoft® Systems Management Server £ сервер управления системами корпорации Майкрософт), сценариями входа службы Active Directory или иными средствами. Обнаружение указанного элемента в реестре свидетельствует о том, что один из пользователей компьютера в какой-то момент применял систему EFS. Однако наличие этого элемента не обязательно означает, что кто-то пользуется системой EFS в настоящее время и что часть данных этого пользователя зашифрована. Поэтому при обнаружении системы с таким элементом реестра нужно провести более подробный анализ и выяснить, имеются ли в ней зашифрованные файлы.
Если запустить на компьютере служебную программу cipher.exe с параметрами /U и /N, она составит отчет о состоянии шифрования файлов и каталогов на этой машине. К примеру, чтобы определить, есть ли в системе зашифрованные данные, можно запустить такую команду:
cipher /U /N
Проверку реестра и отчет о шифровании (выполняемый в случае обнаружения определенного элемента реестра) можно объединить в одном сценарии. Составление таких отчетов позволяет узнать, у кого из пользователей какие файлы зашифрованы, и подготовиться к их переносу в централизованно управляемую схему шифрования.
Для контроля применения групповой политики во время развертывания имеет смысл создать в домене две группы безопасности, чтобы отделить компьютеры, на которых используется система EFS, от тех, на которых она не применялась. К примеру, группа SG-ComputersUsingEFS может содержать учетные записи компьютеров, на которых система EFS используется, а в группу SG-ComputersNotUsingEFS можно включить учетные записи всех остальных машин, на которых эта файловая система в данный момент не применяется.

Контроль использования системы EFS с помощью групповой политики
Определив, на каких компьютерах система EFS используется, а на каких не используется, нужно отключить автономный режим системы EFS на всех компьютерах, где эта система в настоящее время не применяется. Этот этап процесса развертывания весьма важен, поскольку проще активировать и правильно настроить систему EFS впервые, чем проводить миграцию пользователей, работающих с самозаверяющими сертификатами. Приступать к его осуществлению нужно только тогда, когда перечень лиц, использующих систему EFS, станет точно известен; дело в том, что при отключении системы EFS посредством группой политики пользователи не смогут осуществлять доступ к зашифрованным на этот момент файлам. Нужную групповую политику можно найти, открыв при помощи редактора объектов групповой политики раздел Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Encrypting File System (Конфигурация компьютера\Параметры Windows\Параметры безопасности\Политики работы с открытым ключом/Файловая система EFS).
Как мы уже говорили, этот параметр следует вводить в действие только на тех компьютерах, где система EFS в данный момент не используется, чтобы не нарушить работу лиц, которые уже пользуются этой файловой системой. В связи с этим в нашем примере список управления доступом (ACL) в объекте групповой политики (GPO), отключающем EFS, ограничивает действие групповой политики группой SG-ComputersNotUsingEFS.

Шифровать или не шифровать?
Определившись с тем, на каких компьютерах в данный момент используется система EFS, и отключив ее на всех остальных машинах до осуществления управляемого развертывания, в качестве следующего этапа нужно определить, что будет шифроваться в рамках этого управляемого развертывания. В зависимости от особенностей механизма управления клиентскими системами этот процесс может оказаться как простым, так и весьма запутанным.
Отбирая файлы для шифрования, в первую очередь нужно исходить из того, являются пользователи администраторами своих систем или нет. Если пользователи наделены правами локальных администраторов, то им можно только разъяснить важность шифрования конфиденциальных данных, а возможность фактически управлять этим процессом в централизованном порядке отсутствует. Дело в том, что локальный администратор может создавать файлы и каталоги в любой части файловой системы. Так, можно зашифровать стандартные каталоги (например папку «Мои документы»), но если пользователь создаст новый каталог в другом месте и сохранит конфиденциальные данные в нем, обеспечить защищенность этих данных будет весьма проблематично. Схема, при которой конечные пользователи не являются локальными администраторами, помимо прочих преимуществ в плане безопасности значительно повышает управляемость и безопасность системы EFS.
Далее нужно принять во внимание то обстоятельство, что система EFS выполняет шифрование для отдельных пользователей. Иными словами, все данные, зашифрованные определенным лицом, могут быть расшифрованы только им же и никем другим, включая учетную запись SYSTEM (агент DRA (Data Recovery Agent £ агент восстановления данных), конечно же, является исключением). Следовательно, если один пользователь зашифрует своим ключом исполняемый файл или библиотеку DLL, а другой участник системы впоследствии попытается обратиться к такому файлу, произойдет ошибка доступа. По этой причине файлы и каталоги с исполняемым кодом, доступ к которому может потребоваться нескольким участникам системы, как правило, шифровать не следует. ОС Windows не позволяет шифровать файлы, расположенные в каталоге %SystemRoot% или имеющие атрибут SYSTEM, однако поставщики программных продуктов нередко размещают двоичные файлы служб, которые могут исполняться учетной записью SYSTEM, в каталоге %ProgramFiles%. В частности, этот прием популярен среди производителей портативных компьютеров применительно к программному обеспечению для управления электропитанием и работой устройств, которое исполняется в виде служб.
Учитывая эти обстоятельства, попробуем сформулировать рекомендации по выбору объектов шифрования системой EFS. Здесь нужно учитывать стандартные настройки пользовательских систем. В четко управляемой среде со стандартизированным образом операционной системы процесс шифрования пользовательских данных, скорее всего, можно автоматизировать на основе предварительно определенных в образе мест хранения данных. К примеру, если пользователям разрешено сохранять данные только в папке %userprofile%\Мои документы, то может потребоваться шифрование только этого каталога. (Примечание. В случае использования перенаправления папок будьте внимательны при шифровании каталога «Мои документы». Если каталог «Мои документы» перенаправляется на сервер, то этот сервер должен относиться к категории доверенных для делегирования и иметь доступ к профилю пользователя. В таких случаях проще ограничиться шифрованием кэша автономных файлов, о чем мы поговорим чуть позже.)
В среде с менее жестким управлением (где пользователи имеют право записи во многих местах файловой системы) можно автоматизировать шифрование нескольких стандартных каталогов и обучить пользователей самостоятельному шифрованию других папок. Вне зависимости от характеристик среды, шифрование следует проводить на уровне каталогов, а не файлов. При этом все создаваемые в том или ином каталоге файлы (даже временные) в любом случае будут шифроваться.

Рекомендуемые для шифрования папки
Как правило, следует шифровать несколько основных каталогов: %userprofile%\Мои документы, %userprofile%\Application Data\Microsoft\Outlook (в том случае, если в качестве почтового клиента на компьютере установлено приложение Microsoft Office Outlook®) и %userprofile%\Рабочий стол. Шифрование каталога «Мои документы» позволяет защитить установленное по умолчанию место сохранения файлов операционной системы Windows XP. Защита каталога Outlook обеспечивает шифрование всех конфиденциальных сообщений электронной почты, которые локально кэшируются, что особенно актуально для пользователей, работающих в установленном по умолчанию для диспетчера электронной почты Outlook 2003 режиме кэширования. Наконец, рабочий стол зачастую используется в качестве временной папки, куда пользователи помещают документы, над которыми они в данный момент работают, или презентации, которые они часто представляют. Естественно, в конкретной организации стандартное местоположение этих каталогов может быть иным, и шифрование средствами системы EFS должно быть настроено соответствующим образом.
Помимо исполнения вышеизложенных рекомендаций, необходимо определить наличие приложений, которые могут сохранять конфиденциальные данные в другие каталоги. К примеру, некоторые приложения сохраняют сведения о пользователях не в их профили, а в каталог %ProgramFiles%\ИмяПриложения. Важно установить наличие подобных приложений в клиентских системах, чтобы правильно организовать защиту используемых ими данных. Оптимальный вариант £ настроить приложение таким образом, чтобы изменения сохранялись в другом, расположенном в профиле соответствующего пользователя каталоге (например «Мои документы»); в таком случае внесение дополнительных изменений в настройки файловой системы EFS не потребуется. В менее благоприятных случаях, когда приложению необходимо сохранять данные в свою папку в каталоге Program Files, имеет смысл настроить систему EFS для шифрования только этого конкретного подкаталога папки Program Files.
Наконец, будьте внимательны, настраивая шифрование временного каталога (%TMP% и %TEMP%). Многие программы установки приложений распаковывают в этом каталоге содержимое пакетов установки, после чего перемещают извлеченные файлы в соответствующие подкаталоги папки %ProgramFiles%. Так как переносимый в пределах одного тома файл сохраняет изначальные атрибуты, при перемещении в папку %ProgramFiles% он остается зашифрованным. Любой участник системы, за исключением пользователя, запустившего программу установки, в таком случае не сможет получить доступ к этому файлу. По сообщениям приложений об ошибках выявить первоначальную причину подобных проблем зачастую не представляется возможным. По этой причине мы рекомендуем шифровать каталог %TMP% только в средах с жестким управлением, где пользователи не могут устанавливать приложения самостоятельно.

Защита автономных файлов
Автономные файлы £ это функция, впервые появившаяся в ОС Windows 2000, которая позволяет создавать локальные копии данных, размещенных на файловом сервере. Автономные файлы позволяют пользователю работать с этими данными в автономном режиме, а при следующем подключении к серверу проводить синхронизацию внесенных изменений. В то же время автономные файлы £ это не просто каталог, содержащий копии файлов с сервера. Это общая для всей системы база данных, которая работает в контексте учетной записи SYSTEM. В операционной системе Windows XP эту базу данных можно защитить с помощью файловой системы EFS. Занятное обстоятельство в контексте ориентированности системы EFS на индивидуальных пользователей, что обсуждалось ранее. Как с помощью системы EFS, которая обслуживает отдельных пользователей, можно зашифровать базу данных, к которой обращаются самые разные участники системы безопасности?
Когда пользователь, работающий в системе Windows XP, запускает в проводнике Windows команду шифрования автономных файлов, применяется специальная процедура шифрования, отличная от других доступных пользователю операций подобного рода. Вместо личной пары ключей системы EFS пользователя, применение которой не позволило бы учетной записи SYSTEM обращаться к файлам, эта учетная запись самостоятельно генерирует пару ключей файловой системы EFS и выполняет с ее помощью шифрование клиентского кэша. С точки зрения безопасности это означает, что если какому-либо лицу удастся получить код, позволяющий работать с учетной записью SYSTEM, он сможет расшифровать данные, хранящиеся в этом кэше. Например, после кражи портативного компьютера похититель может сбросить пароль администратора и войти в систему с административными правами. В таких условиях запуск кода с учетной записью SYSTEM и последующий доступ к кэшу практически не представляет сложности. (Следует иметь в виду, что в ОС Windows Vista™ эта схема претерпела изменения. В системе Windows Vista для шифрования автономных файлов отдельного пользователя система задействует его индивидуальный ключ.)
Для защиты от таких злонамеренных действий портативный компьютер можно настроить на автономное хранение ключа шифрования базы данных диспетчера SAM (Security Accounts Management £ диспетчер учетных записей безопасности) в виде пароля, вводимого при загрузке компьютера (режим 2), или на дискете, используемой в процессе загрузки (режим 3). Оба эти подхода могут быть обременительными, так как требуют в процессе загрузки осуществления не подлежащего автоматизации взаимодействия с компьютером, что создает потенциальные проблемы для автоматизированного управления системами. Тем не менее, если предполагается использование файловой системы EFS на компьютере, на котором используются автономные файлы, то применение одного из двух вышеуказанных режимов в целях защиты данных кэша становится совершенно необходимым. Мы обычно рекомендуем отдавать предпочтение вводу пароля во время загрузки (см. рис. 1). Это связано с тем, что в случае записи ключа шифрования на дискету похититель портативного компьютера имеет все шансы найти ее непосредственно в дисководе, но даже если ее там не окажется, почти наверняка злоумышленник обнаружит ее в сумке.
Figure 1 Automate EFS operations
Figure 1 Automate EFS operations

Включение системы EFS
Определившись с тем, какие файлы и каталоги клиентской машины требуют шифрования, самое время выполнить фактическое шифрование. Эту процедуру можно выполнить с помощью сценария входа или другого процесса, который сможет запустить на клиентской системе сценарий, вызывающий для выполнения операции шифрования программу cipher.exe. Если в среде есть системы, пользователи которых используют файловую систему EFS в автономном режиме, как показано в приведенном выше примере, их миграцию следует провести в первую очередь.
Для выполнения миграции этих автономных пользователей сначала предоставьте данным клиентским системам управляемые сертификаты, как описано в предыдущей части этой статьи, опубликованной в номере за февраль 2007 г. (microsoft.com/technet/technetmag/issues/2007/02/SecurityWatch). После того как ото всех систем будут поданы заявки на получение управляемых сертификатов, нужно запустить программу cipher с параметром /U, чтобы обновить все существующие файлы с использованием новых ключей шифрования и агентов восстановления. В результате все системы, входящие в группу SG-ComputersUsingEFS, будут использовать файловую систему EFS в управляемом режиме, что, помимо прочего, подразумевает централизованную выдачу (и, возможно, архивирование) ключей и координацию агентов восстановления.
Перед тем как провести развертывание файловой системы EFS для пользователей, которые в настоящее время ее не применяют, нужно сначала удалить групповую политику, блокирующую использование системы EFS. Выполнив это действие и убедившись в том, что от всех пользователей поданы заявки на получение управляемых сертификатов, запустите сценарий входа и зашифруйте основные каталоги, которые обсуждались выше. Вот простой пример такого сценария.
cipher /e /s /a "%userprofile%\My Documents"

cipher /e /s /a "%userprofile%\Application Data\Microsoft\Outlook"

cipher /e /s /a "%userprofile%\Desktop"
Распространив действие системы EFS на выбранные каталоги, следует рассмотреть возможность настройки двух дополнительных элементов, которые позволяют повысить безопасность развертываемой системы EFS. Оба эти элемента связаны со страничной выгрузкой данных из памяти на диск. Имейте в виду, что в каждом из этих случаев злоумышленник потенциально может восстановить только те данные, которые были загружены в память или выгружены на диск полномочным пользователем. Иными словами, если в компьютере есть защищенные с помощью системы EFS конфиденциальные данные, которые пользователь не просматривал (и, следовательно, не загружал в память), они недоступны для подобных атак.
Файл подкачки используется операционной системой Windows в качестве виртуальной памяти (в других операционных системах часто называется пространством подкачки) и содержит необработанные блоки данных, извлеченные из памяти и записанные на жесткий диск в незашифрованном виде. В связи с этим защищенные с помощью системы EFS конфиденциальные данные системы могут быть подвержены риску, потому что, если инициатору атаки удастся восстановить файл подкачки, то с помощью аналитических инструментов он потенциально может извлечь из него пригодные к использованию данные. Так как возможность шифрования файла подкачки в ОС Windows XP не предусмотрена (обратите внимание, что в операционной системе Windows Vista этот файл может быть зашифрован), лучше всего заставить операционную систему очищать его содержимое перед выключением компьютера. Сделать это можно с помощью групповой политики, как показано на рис. 2.
Figure 2 Setting group policy
Figure 2 Setting group policy (Щелкните изображение, чтобы уменьшить его)
Figure 2 Setting group policy
Figure 2 Setting group policy (Щелкните изображение, чтобы увеличить его)
Недостаток такого решения заключается в значительном увеличении времени выключения компьютера, особенно при наличии на нем большого объема памяти (по умолчанию размер файла подкачки напрямую зависит от объема физической памяти компьютера). Дело в том, что для очистки файла подкачки перед выключением компьютера система Windows должна физически выполнить запись на каждую страницу диска.
Если режим управления питанием предусматривает переход в спящей режим, то файл спящего режима системы Windows содержит дамп физической памяти компьютера. При переходе в спящий режим операционная система Windows записывает на диск в файл спящего режима все содержимое физической памяти, что позволяет при возобновлении работы восстановить состояние компьютера без потерь. Подобно файлу подкачки, файл спящего режима в системе Windows XP не шифруется. В то же время, запретить переход в спящий режим непосредственно в объекте групповой политики нельзя. Вместо этого для отключения (и повторного включения) спящего режима следует использовать сценарий, вызывающий служебную программу powercfg.exe с параметром /HIBERNATE.
Справившись с первоначальным шифрованием и настройкой, можно заняться очисткой потерянного дискового пространства в среде. Невзирая на возможную большую длительность этого процесса, который также может нарушать работу пользователей, он весьма полезен в плане обеспечения безопасности для сред с высоким уровнем безопасности. Потерянное пространство £ это область диска, в которой отсутствуют активные данные, но в которой в силу особенностей функционирования жестких дисков могут оставаться блоки конфиденциальных данных из ранее использовавшихся файлов. Иными словами, так как операция удаления файла не приводит к перезаписи всех секторов, которые файл занимает на диске (удаляется только указатель в таблице файлов), данные, которые считаются удаленными, на самом деле могут сохраняться на диске. В таких случаях данные можно восстановить с помощью аналитических средств, способных считывать данные из потерянного пространства и восстанавливать ранее удаленные файлы. Для безопасной очистки остаточных данных запустите команду cipher с параметром /W. В результате все секторы, отмеченные как доступные на диске, будут многократно перезаписаны. Если все последующие файловые операции с конфиденциальными данными будут проводиться в каталогах, защищенных системой EFS, запускать указанную команду регулярно не потребуется.

Настройка проводника Windows для работы с файловой системой EFS
По умолчанию параметры шифрования и расшифровки файлов и каталогов в какой-то степени скрыты в меню дополнительных свойств проводника Windows. Чтобы упростить взаимодействие конечных пользователей с системой EFS, команды «Зашифровать» и «Расшифровать» можно разместить в контекстном меню проводника (которое выводится щелчком правой кнопки мыши). Кроме того, проводник Windows можно настроить так, чтобы защищенные посредством системы EFS файлы и каталоги выделялись другим цветом (зеленым). В результате пользователь будет сразу знать, зашифрован ли определенный файл или каталог, не заходя в меню дополнительных свойств. Наконец, можно реализовать контроль доступа к тому или иному файлу или каталогу со стороны различных пользователей. Для этого с помощью сценария, вызывающего служебную программу reg.exe, внесите в реестр следующие изменения:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"EncryptionContextMenu"=dword:00000001

"ShowCompColor"=dword:00000001

[HKEY_CLASSES_ROOT\*\Shell\Encrypt To User...\Command]
@="rundll32 efsadu.dll,AddUserToObject %1"

Система EFS в ОС Windows Vista
В ОС Windows Vista система EFS претерпела ряд важных усовершенствований, которые не только упростили развертывание и управление ею, но и повысили ее безопасность. Основным усовершенствованием стала полноценная поддержка хранения ключей EFS на смарт-картах. Эта возможность особенно ценна для организаций, которые уже применяют вход в системы с использованием смарт-карт, потому что те же самые карты можно задействовать для хранения пользователями ключей системы EFS. Поддержка смарт-карт также распространяется и на сертификаты агентов восстановления, так что теперь высоко конфиденциальные сертификаты агентов DRA можно тоже хранить на картах.
Кроме того, в ОС Windows Vista поддерживается шифрование таких элементов, в отношении которых применение шифрования в операционной системе Windows XP было невозможным или трудноосуществимым. В частности, в системе Windows Vista существует возможность шифрования файла подкачки, что делает ненужной настройку очистки файла виртуальной памяти. В системе Windows Vista полностью переработаны автономные файлы. Кроме значительно более высоких производительности и стабильности (а также более удобного для пользователей интерфейса), в новой системе кэширование на стороне клиента осуществляется для отдельных пользователей; т.е. теперь возможно безопасное шифрование кэша без использования режимов 2 и 3 SYSKEY. Эти два усовершенствования устраняют основные проблемы развертывания системы EFS, возникающие в сегодняшних средах на основе системы Windows XP.
Наконец, ОС Windows Vista позволяет администраторам настраивать шифрование папки «Документы» непосредственно через групповую политику без использования отдельного сценария. Новые свойства системы EFS, доступные в ОС Windows Vista через объект групповой политики, показаны на рис. 3.
Figure 3 EFS properties in Windows Vista
Figure 3 EFS properties in Windows Vista (Щелкните изображение, чтобы уменьшить его)
Figure 3 EFS properties in Windows Vista
Figure 3 EFS properties in Windows Vista (Щелкните изображение, чтобы увеличить его)

Заключение
Система EFS предоставляет в распоряжение администраторов Windows метод защиты мобильных данных, характеризуемый высоким уровнем безопасности. Система EFS отличается масштабируемостью, управляемостью и обеспечивает гибкие механизмы восстановления данных. В ОС Windows Vista система EFS дополнительно усовершенствована путем включения расширенных возможностей управления и развертывания, а также поддержки хранения ключей на смарт-картах. Организациям, стремящимся защитить свои данные даже в случае хищения вычислительной техники, предоставляется мощное решение в виде системы EPS, входящее в комплект существующей платформы Windows.
Где узнать больше?
Дополнительную информацию по темам, рассмотренным в этой статье, см. в следующих документах:
  • Рубрика «В поисках безопасности» в выпуске за февраль 2007 г.
  • Encrypting File System in Windows XP and Windows Server 2003 (Шифрованная файловая система в операционных системах Windows XP и Windows Server 2003) (на английском языке)
  • How to Use the SysKey Utility to Secure the Windows Security Accounts Manager Database (Как защитить базу данных диспетчера учетных записей безопасности системы Windows с помощью служебной программы SysKey) (на английском языке)

Джон Морелло (John Morello) с отличием окончил Университет штата Луизиана и в течение шести лет работает на различных должностях в корпорации Майкрософт. Работая в должности старшего консультанта, он разрабатывал решения в сфере безопасности для предприятий, входящих в рейтинг Fortune 100, а также для клиентов из гражданских и оборонных федеральных ведомств. В настоящее время является руководителем программы в группе по разработке операционной системы (ОС) Windows Server, занимающейся вопросами обеспечения безопасности и технологиями удаленного доступа.


 Файлы рабочего стола: PsTools Primer
Файлы рабочего стола
PsTools Primer
Уес Миллер (Wes Miller)
Загрузить исходный код для этой статьи: MillerTheDesktopFiles2007_03.exe (150KB)

До прошлого года я работал в компании Winternals Software, которая в июле 2006 г. была приобретена корпорацией Майкрософт. Winternals продавала коммерческое программное обеспечение, но основатели компании, Марк Руссинович (Mark Russinovich) и Брайс Когсвелл (Bryce Cogswell) являлись также владельцами еще одной компании, Sysinternals, которая многие программы распространяла бесплатно. Некоторые из этих бесплатных приложений
даже стали компонентами пакета Winternals Administrator's Pak. Марк и Брайс также продавали лицензии на эти средства компаниям, которые хотели использовать их по истечении обычных сроков бесплатных лицензий.
Одно из моих любимых средств из библиотеки Sysinternals (точнее, это целая пачка программ) £ комплект PsTools £ сейчас можно найти по адресу microsoft.com/technet/sysinternals/utilities/pstools.mspx. Марк назвал эти средства в честь служебной программы ps, используемой в UNIX для перечисления процессов. На веб-узле загрузки этих средств упоминается, что в Windows® имеется встроенная служебная программа, работающая в режиме командной строки, которая может выполнять некоторые из функций этих средств. Однако, не говоря уже о замечательных, уникальных функциональных возможностях, главное различие между этими программами в том, что комплект PsTools может использоваться локально или дистанционно (если, конечно, удаленные системы правильно настроены). Более того, работать с этими средствами дистанционно почти так же просто, как и локально.
Комплект PsTools содержит несколько отдельных приложений, приведенных на рис. 1. Как и остальные служебные программы, разработанные Sysinternals, данный комплект не содержит установщиков, а только приложения. Достаточно поместить их в нужную папку и £ вперед!
Figure 1 Служебные программы PsTools (Close Figure 1)

Средство | Описание
PsExec | Исполнение процессов в контексте любого пользователя.
PsFile | Получение сведений о файлах, открытых на удаленном компьютере.
PsGetSid | Получение кода безопасности (SID) компьютера или пользователя.
PsInfo | Получение сведений об операционной системе Windows.
PsKill | Ликвидация процессов по имени или коду процесса.
PsList | Получение подробных сведений о запущенных процессах.
PsLoggedOn | Получение сведений обо всех локально подключенных пользователях, а также всех пользователях, подключенных к общим ресурсам.
PsLogList | Создание дампа журнала событий Windows.
PsPasswd | Изменение паролей учетных записей пользователей.
PsService | Просмотр и управление службами Windows.
PsShutdown | Выключение, перезапуск, перевод в спящий режим или приостановка работы компьютера.
PsSuspend | Приостановка запущенных процессов.
Вы можете заметить, что некоторые из функций (особенно PsLogList) могут быть реализованы средствами инструментария управления Windows (WMI) и некоторых сложных сценариев. Но изюминка комплекта PsTools состоит в том, что каждая его программа предназначена для выполнения определенной задачи, причем наиболее просто и легко.
Я расскажу вам о каждом из средств и приведу простой пример, для чего и как его можно использовать. Но сначала я предлагаю кратко ознакомиться с тем, как работают эти средства и какие требования должны быть выполнены, чтобы они работали.

Как работают эти средства?
Все средства в основном работают одинаково. Вы запускаете средство PsTool на основном компьютере. Хотя многие средства можно запускать локально, вы обнаружите, что большинство из них имеет служебную программу для запуска в удаленной системе или нескольких системах сразу. (PsExec £ это особое исключение, которое мне вспоминается; вы убедитесь в этом далее из примера.) Используя аргументы командной строки, служебная программа создает свою копию на административном общем ресурсе удаленной системы, что то же самое, что %SystemRoot% (каталог Windows) в удаленной системе.
После копирования в удаленный каталог приложение запускается и устанавливается как служба Windows. Данная служба Windows выполняет требуемую задачу, используя учетные данные, предоставленные при запуске. Если на клиентском компьютере для определенного средства требуется интерфейс конечного пользователя, эта служба запускает дополнительный двоичный файл в контексте пользователя. (Не забывайте о том, что службы не могут передавать прямые интерактивные интерфейсы пользователя.) Служба возвращает необходимую информацию в консоль, из которой она была запущена. Наконец, служба сама отменяет свою установку.
Как видите, эти средства мощные и самодостаточные. И хотя они включают много двоичных модулей и множество процессов, вам, как пользователю, не следует беспокоиться об этом £ достаточно запустить требуемое средство, и оно будет работать.
Требования, необходимые для работы этих средств: Операционная система Windows NT®, Windows 2000, Windows XP или Windows Server® 2003 (поддерживаются 32-разрядные (x86) или 64-разрядные (x64) версии Windows, кроме версий Itanium); в удаленной системе, в которой запускаются средства, доступен используемый по умолчанию общий сетевой ресурс (admin$) и открыт общий доступ к файлам и принтерам в удаленной системе (при использовании брандмауэра Windows, брандмауэра подключения к Интернету или другого брандмауэра).

PsExec
PsExec £ одно из моих любимых средств, но причина этого может показаться вам неожиданной. В течение двух лет я большую часть времени работал в своих системах не как администратор, а как пользователь. У меня есть коротенький сценарий, run.vbs, который я использую для запуска приложений от имени локального администратора (запуск происходит так же просто, как и от имени любого другого пользователя). На рис. 2 приведен код этого сценария (его также можно загрузить на веб-узле TechNet Magazine technetmagazine.com/code07.aspx). В сценарии предполагается, что путь к программе PsTools задан системной переменной Path.
Figure 2 Run.vbs (Close Figure 2)
SET WshShell = WScript.CreateObject("WScript.Shell")
SET WshSysEnv = WshShell.Environment("SYSTEM")
SET FSO = CreateObject("Scripting.FileSystemObject")
IF WScript.Arguments.Count <> 0 Then
    FOR EACH arg IN WScript.Arguments
        iArgCount = iArgCount + 1
        strCmdArg = (arg)
        strCmdArray = Split(strCmdArg, " ", 2, 1)
        IF iArgCount = 1 THEN
        strExe = strCmdArray(0)
        ELSEIF iArgCount = 2 THEN
        strRun = strCmdArray(0)
        ELSE
        strParams = strParams&" "&strCmdArray(0)
        END IF
    NEXT
END IF
'/t:0A && title ***** Admin *****
        strExt = LCase(Right(strExe, 3))

IF strExt <> "exe" AND strExt <> "bat" AND strExt <> "cmd" THEN
WshShell.Run "psexec.exe -d -i -e -u COMPUTERNAME\USER -p PASSWORD  cmd /c start "&strExe&"
    "&strRun&" "&strParams, 0, FALSE
ELSE
WshShell.Run "psexec.exe -d -i -e -u COMPUTERNAME\USER -p PASSWORD "&strExe&" "&strRun&"
    "&strParams, 0, FALSE
END IF

    SET WshShell = NOTHING
    SET WshSysEnv = NOTHING
    SET FSO = NOTHING
Этот простой сценарий является примером использования функциональных возможностей PsExec, которые добавил Марк, когда мы работали над нашим продуктом Protection Manager в Winternals: возможность для пользователя с ограниченными правами получить расширенные права для локального запуска PsExec. Наиболее часто PsExec, конечно, запускается дистанционно, например для запуска служебной программы, которая не предполагает удаленное использование, поддержки сценариев или автоматизации рабочей среды. К ключевым особенностям PsExec относятся возможность копирования двоичного файла для исполнения в удаленной системе, а также возможность требовать привязку к процессору. Другая удобная функция PsExec £ это возможность задавать файл сценария для выполнения одновременно на нескольких машинах.
Вот вариант упрощенного использования PsExec:
PsExec \\computer -u username -p password command
Эту командную строку можно расширить при помощи ключей, приведенных на рис. 3.
Figure 3 Параметры PsExec (Close Figure 3)

Параметр | Описание
-a | Задает привязку к процессору.
-c | Указывает, следует ли копировать приложение на удаленный компьютер.
-d | Указывает, что до выхода не следует ожидать окончания процесса (не ожидать сообщения о завершении или об ошибке).
-e | Загружает с использованием указанного профиля учетной записи.
-f | Копирует приложение на удаленный компьютер, даже если оно уже существует. Гарантирует запуск текущей (или указанной) версии.
-i | Интерактивный запуск приложения на удаленном компьютере (используется, если нужно, чтобы конечный пользователь видел интерфейс пользователя приложения).
-l | Запускает приложение от имени пользователя с ограниченными правами. Удаляет маркер группы администраторов и понижает привилегии для процесса до уровня члена группы пользователей. Удобно для запуска опасных приложений для работы в Интернет с минимальными привилегиями.
-n | Указывает время ожидания при неудачной попытке подключения к удаленным компьютерам.
-priority | Запускает процесс с указанным приоритетом. Устанавливает приоритет, назначаемый Windows для указанной задачи: -low (низкий), -belownormal (ниже среднего), -abovenormal (выше среднего), -high (высокий) или –realtime(реального времени).
-s | Запускает процесс, используя системную учетную запись (удобно для запуска программы Regedit для доступа к разделам реестра, защищенным привилегиями).
-v | Копирует приложение только в случае, если копируемое приложение имеет более новую версию.
-x | Отображает интерфейс пользователя на защищенном рабочем столе Winlogon £ работает только в локальной системе.
@file | Запускает команду на всех компьютерах, указанных в текстовом файле.

PsFile
PsFile £ это более узконаправленное средство, чем PsExec. В частности, оно используется для проверки того, какие файлы открываются и кем они открываются в удаленной системе. Это может быть полезно в случае, когда перед перезагрузкой сервера нужно выяснить, какие файлы открыты. Чтобы узнать, какой пользователь заблокировал файл, например для предотвращения редактирования или удаления, можно вручную отправить пользователю уведомление или закрыть файл с помощью PsFile. PsFile используется следующим образом:
PsFile \\computer -u username -p password
Эта строка возвращает список дескрипторов файлов, открытых в удаленной системе. Кроме того, к инструкции можно также добавить параметр Id, определяющий имя файла, информацию о котором вы хотите получить или который нужно закрыть. Можно также добавить ключ -c, который закрывает файл, определенный с помощью параметра Id.

PsGetSid
Средство PsGetSid также является узконаправленным. Программа сообщает код безопасности (SID) компьютера, пользователя или группы. Это может быть полезным, если вы хотите убедиться, что системы в вашем домене не имеют одинаковых SID, или просто проверить SID всех пользователей или групп в системе. PsGetSid используется следующим образом:
PsGetSid \\computer -u username -p password account
Обратите внимание, что учетная запись может обозначать пользователя, компьютер или группу. Хотя синтаксис PSGetSid прост, возможны также дополнительные параметры. Параметр SID указывает учетную запись (группы или компьютера), а @file запускает команду на всех компьютерах, перечисленных в указанном текстовом файле.

PsInfo
PsInfo используется для получения подробных сведений о системе. Это, очевидно, будет весьма полезно при запуске сценария в нескольких удаленных систем с записью результата в файл (например, в CSV-файл для чтения в Excel® и сохранения в базе данных). Обратите внимание, что, в отличие от большинства других средств, в данной служебной программе используется следующий важный алгоритм: если не указать имя компьютера, PsInfo по умолчанию попытается опросить все компьютеры домена. PsInfo используется следующим образом:
PsInfo  \\computer -u username -p password
Хотя синтаксис команды прост, допускается использование дополнительных ключей и параметров, приведенных на рис. 4
Figure 4 Параметры PsInfo (Close Figure 4)

Параметр | Описание
-h | Отображает все обновления Windows.
-s | Отображает все приложения, установленные в системе.
-d | Отображает сведения о дисках и томах системы.
-c | Выводит результаты в формате CSV.
-t | Задает другой разделитель для CSV-файлов вместо используемого по умолчанию \t.
Filter | Отображает только данные, соответствующие данному фильтру.
@file | Запускает команду на всех компьютерах, указанных в текстовом файле.

PsKill
PsKill £ это удобная служебная программа для завершения процессов в локальной или удаленной системе. Использовать ее очень просто. Она позволяет быстро ликвидировать процесс вместе с дочерними процессами. Используются PsKill аналогично другим средствам, которые я уже описывал:
PsKill -t \\computer -u username -p password process id | process name
Обратите внимание, что вы можете указать либо код процесса, либо имя процесса, который хотите ликвидировать.

PsList
Я нечасто использую PsList, потому что я поклонник программы Process Explorer. Подробные сведения приведены на узле microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx (на английском языке). Но поскольку дистанционной версии Process Explorer не существует, PsList становится разумной заменой для использования ее ключевых возможностей. На самом деле PsList £ это список из одного или нескольких процессов, которые запущены в удаленной системе.
Использовать PsList очень просто:
PsList \\computer -u username -p password account
Как и в других средствах, параметр учетной записи может задавать пользователя, компьютер или группу. Дополнительные параметры приведены на рис. 5.
Figure 5 Параметры PsList (Close Figure 5)

Параметр | Описание
-t | Отображает сведения на уровне потока.
-m | Предоставляет подробную информацию по каждому процессу.
-x | Отображает сведения о процессе, памяти и потоке.
-t | Отображает информацию в виде дерева процессов (вспомните древовидную структуру в программе Process Explorer).
-s [n] | Запускает режим диспетчера задач на указанное количество секунд. Это позволяет практически в реальном времени просмотреть сведения об удаленном процессе.
-r [n] | Задает частоту (в секундах) обновления при работе в режиме диспетчера задач.
name | Отображает сведения о процессах, имя которых начинается с заданной строки.
-e | Ищет процесс с точно соответствующим именем.
pid | Отображает сведения об указанном процессе.
PsList £ мощное и в то же время простое в использовании средство, с помощью которого можно во всех подробностях наблюдать за удаленными процессами, не прибегая к использованию удаленного рабочего стола. Используя эти сведения, вы можете перейти к PsKill или PsSuspend, если, например, необходимо остановить какой-либо процесс.

PsLoggedOn
Назначение данного средства понятно из его названия. Данная служебная программа показывает, кто из пользователей вошел в систему. Это могут быть локальные (интерактивные) входы в систему или общесетевые входы. Подобно PsFile, это средство может быть полезным для определения, кто использует сервер, на котором вы собираетесь проводить обслуживание. Использовать программу очень просто:
PsLoggedOn \\computer
PsLoggedOn имеет только два дополнительных параметра: -l показывает только локальные (несетевые) входы в систему, а -x подавляет вывод времени входа.
Ценность PsLoggedOn в том, что эта программа позволяет легко видеть сведения, для получения которых вам бы пришлось побывать в нескольких местах Windows.

PsLogList
PsLogList £ одно из наиболее часто используемых средств. Эта программа создает журналы событий Windows в текстовом формате, который потом может быть использован средствами чтения журналов, базами данных и вообще чем угодно. Главное преимущество этого средства £ преобразование записи событий из двоичного формата в формат, который легко можно преобразовать или автоматизировать. (Конечно, в Windows Vista™ журналы событий изначально создаются в XML, но это уже другой разговор.)
Использование PsLogList:
PsLogList \\computer -u username -p password
Имеется также несколько дополнительных ключей и параметров (см. рис. 6).
Figure 6 Параметры PsLogList (Close Figure 6)

Параметр | Описание
-a | Создает дамп событий только после указанной даты.
-b | Создает дамп событий только до указанной даты.
-c | Окончательно очищает журнал событий после создания дампа требуемого события.
-d | Отображает сведения только за указанное число дней.
-e | Исключает события с указанным кодом (можно указать до 10 событий).
-f | Производит фильтрацию типов событий (предупреждение, ошибка и так далее).
-g | Экспортирует журнал событий в виде EVT-файла £ требуется параметр -c.
-h | Отображает сведения только за указанное число часов.
-l | Создает дамп указанного EVT-файла.
-m | Отображает сведения только за указанное число минут.
-n | Отображает сведения только для определенного количества последних событий.
-o | Показывает только события из заданного источника (например, -o SRService для службы восстановления Windows).
-q | Исключает события из заданного источника (в противоположность -o).
-r | Меняет порядок £ создается дамп журнала событий от самого раннего до самого последнего события.
-s | Создает список записей с разделением полей в каждой строке.
-t | Указывает другой, вместо запятой, разделитель для вывода с параметром -s.
-w | Ожидает новых событий для заполнения и создания дампа в реальном времени. Этот параметр применим только на локальном компьютере.
-x | Создает расширенный дамп журналов событий.
eventlog | Указывает, для какого журнала событий нужно создать дамп. По умолчанию £ системный журнал.
@file | Запускает команду на всех компьютерах, указанных в текстовом файле.
Журналы событий Windows могут быть невероятно мощным средством диагностики, но вся соль в том, как получить такие данные, которыми можно управлять или объединять их. PsLogList как раз и выполняет данную операцию.

PsPasswd
PsPasswd £ простая, но мощная служебная программа, выполняющая те же функции, что и Net.exe, но с возможностью дистанционного использования и автоматизации.
PsPasswd  \\computer -u username -p password Username Newpassword
Вы можете указать компьютер, не указывать компьютер (тогда это будет локальная система) или, если укажете компьютер как \\*, служебная программа обработает все компьютеры в текущем домене. PsPasswd имеет только один дополнительный параметр: @file запускает команду на всех компьютерах, указанных в текстовом файле. Это действительно одна из самых необходимых служебных программ, которая предоставляет огромные возможности.

PsService
PsService позволяет просматривать и редактировать сведения диспетчера управления службами (SCM) в одной или нескольких системах сети; можно даже искать имя заданной службы на компьютерах в сети.
PsService \\computer -u username -p password command options
Команда запуска PsService представляет собой одну из команд, перечисленных на рис. 7, а параметры определяют атрибуты, применяемые к данной команде. Если дополнительные ключи к командам не используются, PsService создаст полный дамп данных SCM.
Figure 7 Команды PsService (Close Figure 7)

Команда | Описание
query | Запрашивает указанную службу.
config | Запрашивает сведения о настройке для указанной службы.
setconfig | Задает сведения о настройке для указанной службы.
start | Запускает службу.
stop | Останавливает службу.
restart | Перезапускает (останавливает и снова запускает) службу.
pause | Приостанавливает службу.
cont | Возобновляет приостановленную службу.
depend | Показывает, какие службы зависят от данной службы.
find | Производит поиск в сети экземпляра данной службы.
security | Предоставляет сведения о безопасности для данной службы.
PsService можно рассматривать как мощную, дистанционную версию Services.msc с поддержкой командной строки, которая также позволяет просматривать службы сети (возможно, потенциально опасные) и собирать сведения о настройке.

PsShutdown
PsShutdown £ это еще одно мое любимое средство. Хотя кое-кто скажет, что среди продуктов корпорации Майкрософт есть средство для выполнения этой задачи (shutdown.exe), эти средства все-таки не одно и то же. Ключевое отличие заключается в возможностях PsShutdown: а именно, данное средство может завершать работу и перезапускать удаленную систему. Кроме того, существует возможность переводить систему в ждущий или спящий режим (не только завершать работу и перезапускать), блокировать систему и перезапускать систему после вывода на экран сообщения для пользователя через заданный промежуток времени.
PsShutdown \\computer -u username -p password
При использовании PsShutdown доступен ряд дополнительных параметров, приведенных на рис. 8.
Figure 8 Параметры PsShutdown (Close Figure 8)

(на английском языке).
Параметр | Описание
-a | Прерывает выполняемое завершение работы, инициированное программой PsShutdown.
-c | Позволяет текущему пользователю прервать завершение работы.
-d | Приостанавливает работу компьютера (ждущий режим).
-e | Коды причин выключения. Я рекомендую ознакомиться с материалами, содержащими информацию об этих параметрах, на веб-узле корпорации Майкрософт, так как при их использовании со средством PsShutdown и встроенным средством shutdown.exe могут возникать затруднения. Дополнительные сведения приведены в статье по адресу: msdn2.microsoft.com/en-us/library/aa376885.aspx
-f | Принудительно завершает работу всех приложений.
-h | Переводит компьютер в спящий режим.
-k | Выключает компьютер (перезагружает, если отключение питания не поддерживается).
-l | Блокирует компьютер.
-m | Задает сообщение для всех текущих пользователей.
-n | Задает время ожидания при неудачной попытке подключения к удаленным компьютерам.
-o | Выполняет выход из системы пользователя консоли.
-r | Перезагружает компьютер.
-s | Завершает работу компьютера, но не отключает питание.
-t | Время, которое должно пройти перед выполнением команды выключения, или время отключения питания.
-v | Отображает сообщение для пользователей перед выключением.
@file | Выполняет команду на всех компьютерах, указанных в текстовом файле.
Вы можете убедиться, что PsShutdown £ очень мощная, легко настраиваемая служебная программа для управления электропитанием системы, которая при этом относительно проста в использовании.

PsSuspend
PsSuspend £ это удобная служебная программа для случаев, когда нужно временно взять на себя управление поврежденным процессом или временно приостановить процесс, потребляющий слишком много ресурсов процессора, без потери данных или контекста приложения.
PsSuspend \\computer -u username -p password process ID
С помощью PsList можно получить код процесса. Процесс, который был приостановлен, можно возобновить при помощи ключа -r. Следует отметить, что приостановка и возобновление процесса реализуется также с помощью программы Process Explorer, но только в локальном режиме. Как раз то, что PsSuspend может приостанавливать и возобновлять процессы дистанционно и локально, и дает ей преимущество перед функцией программы Process Explorer.

Заключение
На мой взгляд, комплект PsTools £ бесценен. Вместе с остальными служебными программами Sysinternals (а именно Regmon, Filemon, Process Explorer, а теперь и Process Monitor) PsTools £ первые программы, которые я заношу в строку пути при переустановке Windows в любой из моих систем. Я надеюсь, что эта статья помогла вам познакомиться с комплектом PsTools, если вы не были ранее с ним знакомы, а если были, то вы приобрели дополнительные знания об этих средствах. И, конечно, я очень благодарен Марку Руссиновичу за помощь в написании этой статьи и за то, что все эти годы я мог бесплатно пользоваться этими программами.

Уес Миллер (Wes Miller) работает менеджером по развитию в компании Pluck (www.pluck.com) в Остине, штат Техас. Ранее Уэс Миллер работал в компании Winternals Software в г. Остине, а также в должности руководителя программы и менеджера по продуктам Windows в корпорации Майкрософт. Связаться с Уэсом Миллером можно по адресу technet@getwired.com.


 Microsoft.com изнутри: Знакомство с функцией зеркального отображения баз данных
Microsoft.com изнутри
Знакомство с функцией зеркального отображения баз данных
Салим Хакани (Saleem Hakani)

Когда база данных становится недоступной, ничего хорошего ждать не приходится. С другой стороны, на этот случай в распоряжении пользователей приложения SQL Server 2005 с пакетом обновления 1 (SP1) есть функция зеркального отображения базы данных, способная предотвратить большие неприятности. Эта новая методика обеспечения высокой доступности позволяет поддерживать дополнительный экземпляр баз данных в режиме «горячей готовности», чтобы его можно было ввести в действие, если по той или иной причине рабочий сервер баз данных
выйдет из строя. Действие функции зеркального отображения базы данных сводится к переносу записей журнала транзакций базы данных с сервера-источника на сервер-получатель, который работает в режиме «горячей готовности». При зеркальном отображении баз данных все изменения записываются в журнал транзакций, прежде чем будут внесены в фактические страницы данных, как это всегда было с обновлениями в приложении SQL Server™. Сначала записи журнала размещаются в выделенном в памяти буфере журнала базы данных основного сервера и только после этого сохраняются на диске. Журналы транзакций копируются и воспроизводятся в базе данных зеркального сервера. В результате внесенные в базу данных основного сервера изменения дублируются в базу данных зеркального сервера. При этом клиенты могут устанавливать соединения только с базой данных основного сервера. Когда к базе данных основного сервера от клиента поступает запрос на изменение, основной сервер передает сведения о подобных активных изменениях на зеркальный сервер, не уполномоченный принимать решения такого рода. Если зеркальное отображение базы данных включено и база данных основного сервера становится недоступной, в действие вводится зеркальная база данных.

Механизм зеркального отображения баз данных
Функция зеркального отображения баз данных совместима со всем стандартным оборудованием, поддерживающим приложение SQL Server 2005, и предотвращает потерю данных в случае сбоев базы данных. Зеркальная база данных постоянно обновляется текущими транзакциями, обрабатываемыми на сервере-источнике баз данных. На рис. 1 приводится схема перемещения данных.
Если на основном сервере произошел сбой, не о чем беспокоиться £ на зеркальном сервере есть точная, актуальная копия баз данных основного сервера со всеми данными вплоть до последней зафиксированной транзакции. Итак, зеркальный сервер всегда готов стать основным.
Figure 1 Data replication to the mirror
Figure 1 Data replication to the mirror (Щелкните изображение, чтобы уменьшить его)
Figure 1 Data replication to the mirror
Figure 1 Data replication to the mirror (Щелкните изображение, чтобы увеличить его)
Чтобы организовать в рамках топологии зеркального отображения баз данных автоматический переход с основного сервера на зеркальный и наоборот, нужен третий, так называемый следящий сервер. В таком качестве может выступать любой компьютер, удовлетворяющий требованиям приложения SQL Server 2005.

Режимы работы
Подлежащая использованию топология зеркального отображения базы данных зависит от выбранных режимов работы и защиты транзакций. Зеркальным отображением баз данных поддерживаются такие режимы работы, как «высокий уровень безопасности» (с автоматическим переходом на новый ресурс или без такового) и «высокое быстродействие».
Высокий уровень безопасности (с автоматическим переходом на новый ресурс). Этот режим обеспечивает максимальную доступность базы данных за счет синхронной передачи данных и автоматического перехода на базу данных зеркального сервера. Он оптимален при наличии быстрого и высоконадежного соединения между основным и зеркальным серверами, когда принципиальной становится возможность автоматического перехода на альтернативный ресурс применительно к одной базе данных. В рамках этой схемы база данных основного сервера фиксирует транзакцию лишь по получении от зеркального сервера уведомления о том, что последний сохранил журнал с записью этой транзакции на диск.
Высокий уровень безопасности (без автоматического перехода на новый ресурс). Этот режим позволяет достичь максимальной доступности базы данных за счет синхронной передачи данных, однако автоматический переход на базу данных зеркального сервера в нем не предусмотрен. Таким образом, если зеркальный экземпляр сервера станет недоступным, основной экземпляр сервера продолжит работу, но утратит возможность зеркального отображения данных. В случае сбоя основного сервера зеркальное отображение базы данных приостанавливается, однако переход на другой ресурс можно осуществить вручную.
Высокое быстродействие. В этом режиме работы данные передаются в асинхронном режиме. В отличие от двух вышеупомянутых режимов, в данном случае основной сервер не дожидается подтверждения от зеркального сервера. Зеркальный сервер старается не отставать от основного, однако регистрация в журнале транзакций зеркального сервера записей обо всех последних транзакциях, выполненных на основном сервере, в любой отдельно взятый момент времени не гарантируется. В случае сбоя основного сервера зеркальное отображение базы данных приостанавливается, однако переход на другой ресурс можно осуществить вручную.

Подготовительные операции
При условии выполнения некоторых рекомендаций по предварительной подготовке настройка зеркального отображения БД не составит труда:
Выпуск сервера Убедитесь в том, что основной и зеркальный серверы управляются одним и тем же выпуском продукта SQL Server 2005; возможно использование как выпуска Standard Edition, так и Enterprise Edition.
Доступность следящего сервера Если вы планируете реализовать высокий уровень безопасности с автоматическим переходом на новый ресурс, убедитесь в наличии следящего сервера и в том, что нем установлен любой из выпусков продукта SQL Server 2005. Следящий сервер может работать на любой надежной вычислительной системе, поддерживающей приложение SQL Server 2005.
Отражение Основной и зеркальный экземпляры сервера должны иметь идентичные задания, регистрационные данные, пакеты служб SSIS (SQL Server Integration Services £ службы интеграции SQL Server), разделы дисков, размещение файлов и настройки сервера. Настройка зеркального сервера в точном соответствии с основным сервером обеспечивает их одинаковое функционирование.
Полное восстановление Все базы данных, подлежащие зеркальному отображению, должны обрабатываться по модели полного восстановления.
Master и TempDB Все экземпляры сервера в топологии зеркального отображения должны использовать для баз данных Master и TempDB одинаковые параметры сортировки и кодовую страницу. Различные параметры сортировки и кодовые страницы могут вызвать проблемы при настройке зеркального отображения баз данных.
Резервное копирование Если размер базы данных, подлежащей зеркальному отображению, значителен, нужно в первую очередь создать ее полную резервную копию, а затем выполнить восстановление на зеркальном сервере с параметром NORECOVERY.
Перспективное планирование Определите все имена серверов, номера портов, учетные записи безопасности и места расположения баз данных и оформите эту информацию в виде документа. Контрольный список элементов, подлежащих документированию, приводится на боковой панели «Рекомендации по реализации зеркального отображения баз данных».
Справившись с подготовительными операциями, можно переходить к настройке зеркального отображения баз данных в конкретной среде.
Рекомендации по реализации зеркального отображения баз данных
  1. Используйте серверы-партнеры с одинаковыми ЦП, памятью, устройствами хранения и сетевыми подключениями.
  2. На серверах-партнерах должны быть установлены одинаковые выпуски приложения SQL Server и операционной системы, пакеты обновления и отдельные обновления.
  3. На основном и зеркальном экземплярах сервера приложение SQL Server должно быть установлено в одинаковой структуре папок и дисков.
  4. В случае снижения быстродействия распределить нагрузку можно за счет установки выделенной сетевой интерфейсной платы.
  5. Подобно серверам-партнерам, основной и зеркальный экземпляры сервера должны иметь одинаковые ЦП, модули памяти, системы хранения и сетевые устройства. Единообразие структур каталогов, схем разбивки дисков на разделы и настроек приложения SQL Server позволяет не возвращаться к этим вопросам во время и после перехода на зеркальный сервер.
  6. Убедитесь в том, что все приложения способны устанавливать соединение и выполнять необходимые операции, а все активные имена входа (и связанные с ними разрешения) приложения SQL Server на основном и зеркальном экземплярах сервера совпадают. Для выполнения этого можно воспользоваться задачей «Передача имен входа» служб интеграции SQL Server 2005.
  7. Скопируйте с основного сервера на зеркальный задания агента SQL Server, предупреждения, пакеты служб SSIS, вспомогательные базы данных, определения связанных серверов, устройства резервного копирования, планы обслуживания, почтовые профили баз данных и другие необходимые элементы.
  8. Введите процедуру, согласно которой любые изменения на основном сервере (например связанные с аппаратными и программными средствами, настройками приложения SQL Server и объектами баз данных) подлежат автоматическому воспроизведению или репликации и передаче на зеркальный экземпляр сервера.
  9. Перед началом эксплуатации в рабочей среде выполните несколько тестовых переходов на новый ресурс.

Настройка
Попробуем настроить зеркальное отображение базы данных в режиме работы «высокий уровень безопасности» с автоматическим переходом на новый ресурс (как уже отмечалось, для реализации этого режима требуется следящий сервер). В приведенном примере используются имена серверов и баз данных, показанные на рис. 2; на этой иллюстрации также отмечены роли каждого из серверов.
Имейте в виду: первоначальную настройку зеркального отображения баз данных имеет смысл проводить в часы наименьшей нагрузки, так как осуществление настройки может повлиять на быстродействие из-за копирования журнала ожидающих выполнения транзакций с основного сервера на зеркальный.
Процесс настройки зеркального отображения состоит из трех этапов: сначала на серверах-участниках создаются конечные точки, затем выполняется резервное копирование и восстановление базы данных основного сервера, после чего на всех серверах-участниках включаются сеансы отображения.
Перед установлением сеанса зеркального отображения необходимо установить механизм связи между всеми участвующими в этом процессе серверами. Для этого создайте на всех серверах контрольные точки, выполнив на серверах ServerA и ServerB следующую инструкцию:
Create Endpoint Mirroring_Endpoint
State= Started as TCP (Listener_Port=5001)
For Database_Mirroring (Role=Partner);
На сервере ServerC (который будет работать в качестве следящего сервера) эту инструкцию нужно выполнить, предварительно заменив (Role=Partner) на (Role=Witness). В результате будет указан TCP-порт, на котором каждый из экземпляров сервера должен вести прослушивание.
На следующем этапе нужно создать полную резервную копию базы данных DBM_Demo (сопроводив ее резервной копией журналов этой базы данных) с основного сервера, а затем выполнить на зеркальном сервере ее восстановление с параметром NORECOVERY (использование параметра NORECOVERY гарантирует, что база данных зеркального сервера будет в состоянии восстановления, в котором к ней можно применять журналы транзакций).
Приведенная ниже инструкция языка T-SQL предназначена для создания полной резервной копии базы данных DBM_Demo с сервера ServerA (исполняющего роль основного экземпляра сервера).
Backup Database DBM_Demo to DISK='E:\MSSQL\Bak\DBM_Demo_FULL.bak';
Если после создания полной резервной копии в базу данных были внесены изменения, вероятно, придется резервировать ее журналы; в противном случае эта операция не является обязательной.
При необходимости создать резервную копию журналов базы данных DBM_Demo с сервера ServerA позволяет следующая инструкция языка T-SQL:
Backup Log DBM_Demo to Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak';
Создав все резервные копии, переместите соответствующие файлы на сервер ServerB или разместите на общем ресурсе, с которого их можно будет восстановить на сервере ServerB. После этого выполните восстановление всех резервных копий журнала транзакций, созданных с момента последнего полного резервирования базы данных на сервере ServerA.
Для восстановления резервной копии журналов и полной резервной копии базы данных на сервере ServerB с параметром NORECOVERY выполните приведенную ниже инструкцию языка T-SQL:
--Restore full database backup on the mirror --server instance
Restore Database DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_FULL.bak' with NORECOVERY;
Наконец, чтобы восстановить резервную копию журналов на зеркальном сервере с параметром NORECOVERY, запустите следующую инструкцию языка T-SQL:
Restore Log DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak' with NORECOVERY;
После восстановления всех резервных копий можно приступать к последнему этапу £ включению на всех серверах-участниках сеанса отображения.
Для настройки сеанса зеркального отображения баз данных у всех экземпляров сервера должны быть сетевые адреса. Каждый из этих адресов должен идентифицировать экземпляр по системному адресу и номеру порта, на котором этим экземпляром ведется прослушивание. Синтаксис сетевого адреса сервера выглядит следующим образом:
TCP://<System-address>:<port>
Параметр <System-address> (адрес системы) £ это полное доменное имя или IP-адрес. Эту информацию можно получить, выполнив в командной строке локальной системы команду IPCONFIG.
Параметр <Port> (порт) должен быть определен при создании конечных точек.
Запустить сеанс зеркального отображения базы данных на сервере ServerB можно следующим образом:
Alter Database DBM_Demo
Set Partner= 'TCP://ServerA.com:5001';
Далее для запуска сеанса на сервере ServerA выполните нижеприведенную инструкцию языка T-SQL:
Alter Database DBM_Demo
Set Partner='TCP://ServerB.com:5001';
Наконец, организовать сеанс зеркального отображения на следящем сервере ServerC можно следующим образом:
Alter Database DBM_Demo
Set Witness='TCP://ServerC.com:5001';
На этом подготовку к зеркальному отображению базы данных в среде можно считать завершенной. Теперь все добавленные или измененные в базе данных DBM_Demo объекты будут передаваться в экземпляр, установленный на сервере ServerB. В то же время, если база данных сервера ServerA окажется недоступной, то будет выполнен переход на новый ресурс, в ходе которого зеркальная база данных превратится в основную.
Итак, задействованная функция зеркального отображения базы данных обеспечивает наличие находящегося в режиме «горячей готовности» экземпляра базы данных на случай, если в рабочей базе данных случится сбой.

Салим Хакани (Saleem Hakani) работает в корпорации Майкрософт старшим инженером по базам данных, имеет за плечами 14-летний опыт работы с системами баз данных. Является основателем и главой сообщества Microsoft SQL, а также отвечает за распространение стандартов SQL Server и автоматизацию работы во всей организации Windows Live. Салим является специалистом, сертифицированным по программам MCTS, MCDBA и MCSA. Связаться с ним можно по адресу Saleem@sqlcommunity.net.


 Заметки на полях: Доктор пришел!
Заметки на полях
Доктор пришел!
Мэтт Хестер (Matt Hester)

НЕ ТАК ДАВНО меня посетила мысль, что быть ИТ-специалистом £ это почти то же самое, что быть врачом. Это открытие пришло ко мне, когда я впервые запустил Windows Vista™. В то время у меня были проблемы с сетевыми подключениями. После нескольких часов игры с ping, ipconfig и даже нескольких перезагрузок я увидел слово, которое вызвало у меня естественную ассоциацию, что мы, ИТ-специалисты, £ те же доктора: «диагностика». Обычно, работая с операционной системой, я вижу такие слова и фразы, как «исправить», «состояние», «диспетчер задач» и «отправить отчет об ошибках», которые помогают мне путешествовать по проселкам операционной системы. Но слово «диагностика» заставило меня задуматься о схожести этих двух профессий.
Во-первых, и врачи, и ИТ-специалисты сдают экзамены и проходят сертификацию, что дает нам право добавлять после наших имен определенные буквы. Эти буквы указывают на нашу специализацию и, как нам кажется, выглядят внушительно на двери и визитке.
Как и врачи, ИТ-специалисты при решении проблем используют очень много ресурсов. Врачи консультируются со своими коллегами и ищут информацию в профессиональных журналах и Интернете. Мы, ИТ-специалисты, также обращаемся к нашим коллегам и роемся в Интернете и технических публикациях (в первую очередь, конечно, в TechNet Magazine), которые помогают нам разрешать проблемы.
Кроме того, как врачи, так и ИТ-специалисты полагаются на испытанные средства. Врачи имеют такие проверенные жизнью приборы, как стетоскоп; у нас есть ping. С помощью обоих этих средств мы слушаем, что и как происходит.
Еще одна общая черта имеет социальную природу. Когда врачи и ИТ-специалисты попадают на общественные мероприятия, они часто стараются скрыть свою профессиональную принадлежность. Например, на одной вечеринке люди как-то узнали о том, что мне удалось сделать в этой жизни, и я вдруг стал чрезвычайно популярен. Но за эту популярность пришлось заплатить: я потерял свой имидж очаровательного молодого человека. Я стал просто «компьютерщиком» и, поневоле, бесплатным специалистом поддержки для всех гостей вечеринки: «Эй, компьютерщик, почему мой компьютер завис сегодня утром?», «Эй, компьютерщик, где какая-то там клавиша?», «Эй, компьютерщик, ты может починить мой Макинтош?». Хуже всего было то, что при этом мой знакомый врач продолжал танцевать, улыбаясь широкой, понимающей улыбкой.
Но вернемся к моей проблеме подключения: примерно после трех часов неудачных попыток подключиться я нажал недавно обнаруженную мной кнопку «Диагностика и восстановление». Представьте себе мой шок и замешательство, когда я увидел на экране вот этот ответ:

(Щелкните изображение, чтобы уменьшить его)
Красный, с раскрытым ртом, я озирался, боясь, что кто-нибудь увидит мою драму. Затем я обошел ПК и подключил кабель. С того счастливого дня я продолжал работать с Windows Vista, широко используя возможности диагностики. Это помогло мне сэкономить кучу времени при поиске причин многих проблем. Эта функция также очень хорошо интегрируется с панелью управления «Отчеты о проблемах и решения», с помощью которой можно искать дополнительные сведения в сети. Прежде чем рвать на себе волосы, попробуйте провести диагностику.
Последней мыслью, которая посетила меня той ночью, когда я уже отходил в царство Морфея, счастливый, что так успешно выявил и исправил мою сетевую проблему, было: так я же теперь смогу больше играть в гольф и кататься на своем новом спортивном авто!

Мэтт Хестер (Matt Hester) £ ведущий презентаций TechNet группы Microsoft Across America. О его презентациях можно узнать на веб-узле technetevents.com/mhester (на английском языке). Можно также посетить его блог GJ FLHTCE blogs.technet.com/matthewms.


 Конфиденциальная информация Windows: Интеллектуальный вид и простецкая сущность
Конфиденциальная информация Windows
Интеллектуальный вид и простецкая сущность
Рэймонд Чен (Raymond Chen)

При вставлении компакт-диска в компьютер система Windows® иногда выводит запрос о последующей операции, даже если в прошлый раз порядок действий указывался. Почему система Windows забывает параметры автозапуска? Вообще-то система не забывает, а просто перепроверяет.
С обработкой автозапуска компакт-дисков в системе Windows XP были связаны две проблемы. Во-первых, многие пользователи, установив программу с поддержкой автозапуска компакт-дисков, не знают, как установить ее в качестве новой программы автозапуска, используемой по умолчанию. Если ранее при выборе программы был установлен флажок «Всегда выполнять выбранное действие», то легко обнаруживаемого способа отменить установку флажка постоянного выполнения, чтобы вновь появилось диалоговое окно автозапуска компакт-дисков и пользователь получил возможность выбрать новую программу по умолчанию, не существовало.
Во-вторых, некоторые недобросовестные программы во время установки тайком изменяли недокументированные параметры автозапуска компакт-дисков, назначая средством автозапуска по умолчанию самих себя, в результате чего замещался выбор пользователя.
Проще говоря, с точки зрения пользователей эти две проблемы можно представить так: «Я только что установил эту программу и хочу назначить ее средством автозапуска компакт-дисков по умолчанию, £ и, наоборот: £ Я только что установил эту программу и не хочу назначать ее средством автозапуска компакт-дисков по умолчанию».
Windows Vista treats autoplay settings globally
Windows Vista treats autoplay settings globally (Щелкните изображение, чтобы уменьшить его)
Windows Vista treats autoplay settings globally
Windows Vista treats autoplay settings globally (Щелкните изображение, чтобы увеличить его)
В попытке решения этих проблем в операционной системе Windows XP с пакетом обновления 2 (SP2) был реализован новый порядок действия автозапуска компакт-дисков. Обнаружив наличие нового обработчика автозапуска компакт-дисков, система Windows стала выводить диалоговое окно автозапуска повторно. В результате пользователь может выбрать только что установленную программу в качестве средства воспроизведения по умолчанию или, если эта программа бесцеремонно назначила себя таковым самостоятельно, отменить эту настройку.
Кроме того, диалоговое окно автозапуска компакт-дисков отображается при первой загрузке компакт-диска после обновления системы до Windows XP с пакетом обновления 2 (SP2). Оно действует по принципу «лучше поздно, чем никогда», позволяя разобраться с обработчиками, появившимися в системе до обновления системы до Windows XP с пакетом обновления 2 (SP2).
Раньше перед операционной системой ставилась одна задача £ помочь разработчикам в их взаимодействии с той или иной функцией. В сегодняшних условиях очевидна другая задача: помешать программистам, пытающимся злоупотреблять интерфейсом, который предоставляется в их распоряжение.
Существует еще одна ситуация, при которой кажется, что система Windows забывает ранее установленные параметры автозапуска. Диалоговое окно автозапуска может появиться при подключении съемного носителя, например USB-диска, даже если ранее был выбран один из вариантов и установлен флажок «Всегда выполнять выбранное действие». Дело не в том, что операционная система забыла ваши параметры, а в том, что она слишком хорошо их помнит.
Операционная система Windows запоминает настройки, устанавливаемые для каждого съемного носителя. При подключении нового устройства на экран выводится новое диалоговое окно, так как ранее поведение системы применительно к этому устройству определено не было. Замысел заключает в том, чтобы при подключении, например, цифровой фотокамеры в качестве действия по умолчанию использовался вариант «Просмотр изображений», а при подключении проигрывателя музыки £ «Воспроизведение музыки». Стоит отметить, что если у съемного носителя нет серийного номера, то при подключении к другому USB-порту он идентифицируется как новое устройство.
С учетом путаницы, созданной механизмом управления параметрами автозагрузки системы Windows XP, в системе Windows Vista™ действие этой функции было изменено. Теперь параметры автозапуска обрабатываются как глобальные, а не устанавливаются для каждого устройства отдельно. Так, если выбрать вариант «Не выполнять никаких действий», система Windows Vista не будет их выполнять вне зависимости от того, какое устройство подключается и к какому порту. Парадокс, но иногда, чтобы операционная система казалась «умнее», ее приходится упростить.

Рэймонд Чен (Raymond Chen) на своем веб-узле «The Old New Thing» (Хорошо забытое старое) blogs.msdn.com/oldnewthing) и в опубликованной в 2007 г. издательством Addison-Wesley одноименной книге (на английском языке) рассказывает об истории развития ОС Windows и рассматривает программирование для Win32. В свободное время он проверяет сочинения учеников 7-го класса.