(Возврат на основную страницу)
Алексей Шуленин
Доступ к счетчикам Perfmon из SQL Server. Способы 1 и 2
Программно сгенерить трассу профайлера. Часть 2
А. Гладченко
Основы репликации SQL Server 2008. Часть 1
Доступ к счетчикам Perfmon из SQL Server. Способы 1 и 2
Способ 1
Последовательность действий
1. Все определенные на машине счетчики экспортируются в текстовый файл при помощи typeperf.
2. Текстовый файл редактируется, остаются только интересующие счетчики.
3. Собираются значения счетчиков на интервале при помощи logman.
4. Файл с результатами замеров грузится на SQL Server через создание ODBC DSN и команду relog.
5. На SQL Server появляются таблички DisplayToID, CounterDetails, CounterData, содержащие информацию по счетчикам и их кардиограммы.
Описан здесь: http://www.mssqltips.com/tip.asp?tip=1722.
Это очень хороший способ, и нет сомнения, что администраторы будут его пользовать. Но разработчики обладают более независимым и свободным суждением. Разработчика угнетают все эти непонятные typeperf, logman, relog и пр. Что это такое вообще? Очевидно, что эти инструменты тоже писаны разработчиками, которых когдато давно достали админы своими унылыми хотелками видеть счетчики в базе. Настоящий разработчик не будет пользоваться приблудой, написанной другим разработчиком. Вместо этого он потратит час или два или сколько не жалко, но напишет свою собственную приблуду, хотя бы ему пришлось к ней прибегнуть всего один раз. Она, по определению, будет лучше всех остальных аналогичных приблуд хотя бы потому, что писана лично им. Настоящий разработчик не оформляет свою приблуду в виде exeфайла, потому что тогда ей смогут пользоваться администраторы. Администраторы подпишут у начальства инструкцию, по которой все на предприятии должны будут пользоваться этой тулой вместо того, чтобы развивать творческую мысль, изобретая новый невиданный велосипед. Настоящий разработчик распространяет приблуду в виде исходников. Тогда другие разработчики, вдоволь раскритиковав и поглумившись над собратом, возьмут исходник за основу и примутся развивать его дальше. И так до тех пор, пока какойнибудь ушлый администратор не настоит на exeшнике, что остановит процесс эволюции, приведет со временем к утрате исходника, нагнетет революционную ситуацию и вызовет очередной виток диалектической спирали. Go to начало абзаца.
Способ 2
Я написал утилиту, которая делает сбор счетчиков. Сначала думал UDF, потом решил UDT, чтобы не передавать всякий раз имя счетчика, когда один и тот же счетчик дергается много раз. А UDF туда вошла как статический метод.
Счетчик задается в формате Машина\Категория(Инстанс)\Имя_счетчика, например, localhost\Processor(_Total)\% Processor Time, как они значатся в Perfmone (рис. 1).
Имя машины может быть пустым, тогда это предполагается локальный компьютер. Экземпляр тоже может быть пустым. Тогда, если категория, по определению, многоэкземплярная, он полагается _Total.
Программно сгенерить трассу профайлера. Часть 2*
*См. Алексей Шуленин. Программно сгенерить трассу профайлера. Часть 1 // SQL Server для администраторов. 2009. № 11.
Основы репликации SQL Server 2008. Часть 1
Репликация — это одна из разновидностей систем, поддерживающих распределенную обработку данных. В последнее десятилетие направление распределенной обработки данных бурно развивалось, и на сегодняшний день это одно из наиболее динамично растущих направлений. В докладе об изменении профиля корпоративных данных, который был озвучен на саммите APAC, посвященном хранилищам данных и состоявшемся в 2007 г. в Хошимине, Рик Вилларс (Rick Villars, Head of Investment Technical Services HSBC) показал, что объем тиражируемых данных увеличивается ежегодно на 43.9% и к 2009 г. сравняется с объемом традиционных данных, размещаемых в хранилищах. Назначение этой книги состоит в том, чтобы предоставить читателям набор апробированных в течение нескольких лет рецептов по использованию и настройке репликации в SQL Server.
В этой статье я рассмотрю наиболее значимые для репликации концептуальные моменты, и сделаю небольшой обзор основных направлений администрирования и мониторинга внутренних подсистем репликации SQL Server.
Назначение репликации состоит в управляемом тиражировании данных между несколькими СУБД. Задача эта не нова, и поэтому в репликации используется давно всем известная метафора издательского дела: издатель, публикация, статья, распространитель и подписчик. Для SQL Server характерно также наличие специализированных программных модулей, с помощью которых организуется взаимодействие задействованных в репликации баз данных, и которые в документации принято называть агентами репликации.
Вот определение репликации, которое было представлено в учебном пособии Microsoft: «Репликация — это процесс автоматического распределения копий данных и объектов БД между экземплярами SQL Server с одновременной синхронизацией всей распространяемой информации». Известный теоретик реляционной теории баз данных Крис Дейт дал репликации такое определение: «Система поддерживает репликацию данных, если данная таблица или ее фрагмент может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах». Однако ни одно из приведенных тут определений мне не кажется полным. В профессиональных интернетфорумах очень часто можно встретить вопрос, как организовать репликацию без прямого подключения серверов друг к другу, например, посредством электронной почты? Мне видится неверной даже сама постановка вопроса таким образом. Дело в том, что нужно четко отделять репликацию от простого тиражирования данных. По моему мнению, распределенная система может называться системой с репликацией, если она не только автоматически синхронизирует данные по заданным правилам, но и умеет гарантировать их синхронность. Например, если для доставки изменений в данных используется протокол без какойлибо гарантии доставки, такую систему уже нельзя назвать репликацией, хотя это еще не означает, что данные в такой системе будут не синхронны. С другой стороны, репликация также является очень эффективным способом тиражирования данных, но она не является единственной стратегией тиражирования данных. Давайте кратко рассмотрим несколько стратегий тиражирования данных, которые также доступны на платформе Microsoft.
В первую очередь стоит упомянуть распределенные транзакции, которые могут передаваться по сети с довольно низкой задержкой. Для успешного функционирования распределенных транзакций необходимо иметь возможность транспортировки их между узлами, координации этих транзакций и все узлы и участники транспортной системы распределенных транзакций в момент прохождения такой транзакции должны быть активны. Разумеется, такая сложная цепочка не гарантирует автономности узлов, и отслеживание передачи изменений на все узлы возлагается на разработчика приложения. Подобные проблемы присущи и распределенным запросам, механизм которых схож с распределенными транзакциями, и отличается только отсутствием компонент координатора распределенных транзакций.
(Возврат на основную страницу)