Вопросы и ответы про SQLКластеризация изнутри, таинственные зависания, учетная запись SA и прочее

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

В. Мне необходимо разобраться с тем, как работает кластеризация. В нашей вычислительной среде будет использоваться 64-разрядный Windows Server® 2003, под управлением которого будет работать SQL Server™ 2005, веб-ферма служб отчетов сервера SQL (SSRS) (развертывание горизонтального масштабирования сервера отчетов), сервер каталогов SSRS TempDB и сервер SQLServer, получающий данные из базы данных сторонней компании через связанный сервер и предназначенный для хранения данных для SSRS.

Нам требуется состоящий из 3 узлов кластер типа активный/активный/пассивный. Узел 1 будет активным, и на нем будут храниться данные, полученные из базы данных сторонней компании. Узел 2 будет активным, и на нем будет храниться каталог SSRS. Узел 3 будет пассивным и станет выполнять роль резервного для узла 1 или узла 2. Не могли бы вы помочь?

О. К сожалению, когда речь идет о кластеризации SQL Server, слишком многих вводят в заблуждение термины активный/активный и активный/пассивный. Они полагают, что кластеризация SQL может поддерживать «горизонтальное масштабирование» одной базы данных или экземпляра SQL на нескольких серверах. Это совсем не так. Для SQL Server не существует такого понятия, как активная/активная база данных или экземпляр. «Экземпляр» представляет собой установку SQL Server с соответствующими базами данных. Наша кластеризация для экземпляра SQL Server всегда определяется взаимоотношением активный (1) к пассивному (n) (отметим, что значение n лежит в интервале от 1 до 7, в зависимости от версии SQL Server). По этой причине она называется отказоустойчивой кластеризацией.

Поняв это, можно начинать обдумывать установку нескольких экземпляров в отказоустойчивом кластере на наборе узлов. Например, три физических сервера, использующие вместе общие диски, могут иметь один экземпляр, являющийся активным по умолчанию на узле 1, и второй экземпляр, активный по умолчанию на узле 2, и оба могут при сбое переходить на узел 3. Эти экземпляры полностью самостоятельные, они не используют совместно данные и не являются парой активный/активный. Они оба используют схему активный/пассивный и оба совместно используют один и тот же резервный экземпляр. Если оба экземпляра переходят при сбое на узел 3, тогда со временем возникает задача, состоящая в определении того, выдержит ли он нагрузку. Предполагается, что при переходе на другой ресурс будет использоваться резервный ресурс, равный по вычислительной мощности исходному. Если при пиковой нагрузке в нормальных рабочих условиях для обработки требуются два узла, маловероятно, что узел 3 выдержит пиковую нагрузку, обычно назначаемую двум узлам.

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

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

Средство Microsoft® Cluster Configuration Validation Wizard (ClusPrep), которое теперь доступно для загрузки, заменяет предыдущее средство тестирования HCL (Hardware Certification List — список сертифицированного оборудования), использование которого для проверки полной конфигурации, гарантирующей поддержку ею кластеризации, могло бы занять месяцы. Теперь в руках администратора базы данных имеется средство проверки оборудования, дополнительно снижающее затраты (как финансовые, так и временные), требуемые для установки сертифицированного оборудования. Это средство дает возможность проверять и развертывать в пределах одного набора узлов кластера даже разнородное оборудование.

В. После 12 часов на одном из моих компьютеров оказывается зависшей процедура удаления. Она не заблокирована. При просмотре плана самого медленного запроса выясняется, что некоторый триггер выполняется в течение 87 327 секунд, из чего я делаю вывод, что зависание данной процедуры вызывается этим триггером. Как можно выяснить, на каком именно операторе происходит зависание?

О. Очень вероятно, что цикл в триггере не завершается по целому ряду причин. Если зависание длится долго, и требуется выяснить, какой оператор выполняется, запустите код, приведенный на рис. 1. С его помощью вы узнаете, какой оператор выполняется в текущий момент, и это будет тот оператор, который приводит к зависанию компьютера.

Figure 1 Поиск оператора, выполняющегося в текущий момент

-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20), 
        @start int, 
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle, 
        @start = stmt_start, 
        @end = stmt_end 
FROM Master..sysProcesses(NOLOCK) 
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

В. Требуется поддерживать транзакционную репликацию через брандмауэр. Издатель и распространитель находятся с внешней стороны брандмауэра, а подписчик — с внутренней. Подписчик настроен на прослушивание 1433, а компьютеры имеют следующие имена: Издатель: PUBMACHINE, распределитель: DISTMACHINE, подписчик: SUBMACHINE. Какие требуется открыть порты, чтобы успешно выполнить исходный моментальный снимок и доставку публикации?

О. Если используется подписка на доставку, открытия порта SQL Server (в вашем случае порта 1433) должно быть достаточно, поскольку агент распространения будет выполняться на компьютере распространителя (со внешней стороны брандмауэра), и у него скорее всего будет локальный доступ к файлам моментальных снимков, созданных агентом моментальных снимков. Но если используется подписка на извлечение, агенту распределителя, выполняющемуся на компьютере подписчика, потребуется каким-нибудь образом получить доступ к файлам моментальных снимков через брандмауэр. Ниже приведен список возможных вариантов для рассмотрения.

Исходя из предположения, что файлы моментальных снимков уже доступны из общего файлового ресурса с внешней стороны брандмауэра, можно открыть порты Windows® для использования общего файлового ресурса через брандмауэр, чтобы агент распространителя, выполняющийся с внутренней стороны брандмауэра, мог получать доступ к файлам моментальных снимков, находящимся с внешней стороны (однако следует учитывать возможные влияния на безопасность прочих компонентов вашей инфраструктуры). Отметим, что если местоположение по умолчанию для моментальных снимков (умолчание SSMS) настроено в виде локального пути, может потребоваться использование параметра /AltSnapshotFolder агента распространителя, чтобы переопределить место извлечения файлов моментальных снимков.

Можно также с помощью FTP настроить репликацию для передачи файлов моментальных снимков (и для этого потребовалось бы открыть порт 21).

В. Существуют ли какие-нибудь недостатки отключения учетной записи SA в SQL Server 2005, и повышает ли в действительности безопасность отключение учетной записи SA? Существуют ли документы по этому вопросу?

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

Для защиты от попыток взлома учетной записи SA ее можно также переименовать. Но следует помнить, что при включении отключенной учетной записи необходимо установить для нее новый пароль.

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

В. Файл журнала одной из моих больших сетевых баз данных обработки транзакций (OLTP) в два раза превышает размер файла данных. Была выполнена попытка снизить размер файла журнала до разумных размеров с помощью следующих команд, но есть необходимость в дальнейшем его сокращении:

backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

О. Вам необходимо заменить команду backup database командой backup log. В качестве альтернативы базу данных можно перевести в простой режим восстановления и выполнить команду shrinkfile. По окончании сжатия журнала верните базу данных к предыдущей модели восстановления и восстановите базу данных. Если сжатие все еще недостаточно, убедитесь в том, что нет открытых транзакций (воспользуйтесь инструкцией dbcc opentran). Дополнительную информацию по этому вопросу можно найти в следующей статье базы знаний support.microsoft.com/kb/907511.

В. Если переход на другой ресурс происходит во время выполнения планового задания агента SQL Server, что будет с этим заданием после перехода на другой ресурс? Требуется ли перезапустить его вручную?

О. Да, если не предусмотрена другая процедура, необходимо запустить его вручную. Если хочется избежать перезапуска заданий вручную, можно написать сценарий, обновляющий таблицу после завершения задания. Если значение = 1, задание было выполнено; любые другие значения указывают на то, что задание не было завершено, и через некоторое время поступит второе задание и выдаст команду запуска. Поэтому, хотя задание необходимо перезапустить, если переход на другой ресурс происходит во время его выполнения, можно, написав сценарий, частично сократить заботы, связанные с этими важными ночными заданиями, которые обязательно должны быть завершены к началу следующего рабочего дня.

Совет: Обновление и DBCC UPDATEUSAGE

Вы выполняете обновление SQL Server 2000 до SQL Server 2005?

Если да, обязательно выполните DBCC UPDATEUSAGE сразу же после обновления баз данных.

DBCC UPDATEUSAGE формирует отчеты и исправляет неточности в страницах и счетчиках строк в представлениях каталога. Эти неточности необходимо исправлять, поскольку они могут привести к неправильным отчетам об использовании пространства, возвращаемым системной хранимой процедурой sp_spaceused. В SQL Server 2005 эти значения всегда поддерживаются правильно, поэтому такие базы данных никогда не сталкиваются с неправильными данными счетчиков. Однако, в базе данных, обновленной до уровня SQL Server 2005, могут содержаться неверные данные счетчиков, поэтому после обновления необходимо выполнить DBCC UPDATEUSAGE.

Команда DBCC UPDATEUSAGE работает следующим образом. Выполняется исправление строк, использованных страниц, зарезервированных страниц, конечных страниц и счетчиков страниц данных для каждого раздела в таблице или индексе. Если в системных таблицах нет неточностей, DBCC UPDATEUSAGE не возвращает данных. Если неточности обнаруживаются и исправляются и не используется выражение WITH NO_INFOMSGS, DBCC UPDATEUSAGE возвращает строки и столбцы, обновленные в системных таблицах.

DBCC UPDATEUSAGE можно также использовать для синхронизации счетчиков использования пространства. Поскольку для работы инструкции DBCC UPDATEUSAGE с большими таблицами или базами данных может потребоваться заметное время, ее следует, как правило, использовать только в тех случаях, когда возникает подозрение, что процедура sp_spaceused возвратила неправильные значения. Отметим, что процедура sp_spaceused принимает необязательный параметр для запуска DBCC UPDATEUSAGE до возвращения информации о пространстве для таблицы или индекса.

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

В качестве примера рассмотрим, как обновляются счетчики страниц или строк, или оба, для всех объектов в текущей базе данных. В следующей команде в качестве имени базы данных указано значение 0, и DBCC UPDATEUSAGE выдает отчет с информацией о текущей базе данных:

DBCC UPDATEUSAGE (0);
GO

Для обновления счетчиков страниц или строк, или обоих, допустим для AdventureWorks, а также для подавления информационных сообщений, запускается команда, аналогичная следующей, в которой в качестве имени базы данных указывается AdventureWorks, а затем подавляются все информационные сообщения:

USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO

Для получения дополнительных сведений осуществите поиск DBCC UpdateUsage в электронной документации по SQL Server.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.

© 2008 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.