В. Принимая во внимание предстоящее изменение графика перехода на летнее время в США, нужно ли мне обновить приложение 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 мне не удается установить соединение с приложением 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 с ролью «системный администратор». Дополнительные сведения по этому вопросу см. в разделе документации (на английском языке).
В. При обновлении опубликованного представления я могу быть уверен в том, что транзакция будет реплицирована. Будет ли выполнена репликация транзакции, если обновить базовую таблицу этого представления? Если создать представление на основе опубликованной таблицы, а затем вместо таблицы обновить представление, будет ли такая транзакция реплицирована?
О. Если базовая таблица настроена как статья в рамках публикации (иными словами, если выполненные вами настройки предусматривают репликацию базовой таблицы), то реплицироваться будут все обновления этой таблицы.
По умолчанию при репликации представления реплицируется только его схема или соответствующий ему код; таким образом, если речь не идет об индексированном представлении, сами данные репликации не подлежат. Затем, даже если репликация не выполняется, при каждом обновлении представления (которое в данном случае приравнивается к исполнению инструкции на языке 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)... Аn 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 SET PARTNER RESUME;
Что касается периодов хранения, то вне зависимости от состояния сеанса отображения (которое, как мы выяснили, может быть отключенным или приостановленным) записи журнала сохраняются вплоть до того момента, пока он не будет восстановлен, а все записи, выполненные в период с приостановки до восстановления, записаны на зеркальном сервере. Когда сеанс зеркального отображения находится в отключенном или приостановленном состоянии, урезать журнал основного сервера становится невозможно, так как в противном случае цепочка повтора будет утрачена. Следовательно, пока сеанс не удастся восстановить, журнал основной базы данных будет постоянно увеличиваться в размере. Следовательно, период хранения состояния сеанса зеркального отображения не ограничивается ничем, кроме дискового пространства на основном сервере, выделенного под размещение журнала, так как журнал не может быть урезан.
Наконец, отдельного журнала для наблюдения за процессом зеркального отображения не существует. В приложении SQL Server 2005 для этой цели предусмотрена служебная программа с графическим интерфейсом, называемая монитором зеркального отображения базы данных. Она позволяет системным администраторам просматривать и обновлять состояние, а также устанавливать пороги предупреждения по нескольким базовым метрикам производительности. От этой программы можно получать предупреждения о нештатных ситуациях в процессе зеркального отображения. Основной проблемой в отношении производительности является несвоевременная обработка записей журнала. Дополнительные сведения о контроле зеркального отображения баз данных приведены в статье Monitoring Mirroring Status (Наблюдение за состоянием зеркального отображения), расположенной по адресу msdn2.microsoft.com/fr-fr/library/ms365781.aspx (на английском языке).
Иcточник: TechNet Magazine
Tags: monitoring, SQL, SQL Server, Windows Vista