В процессе работы System Center Operation Manager собирается масса различной информации от объектов мониторинга. Это могут быть данные полученные от счетчиков производительности, системные события, история изменения состояний и многое другое. Бесконтрольный рост объема информации, хранимой в базах данных (OperationsManager и OperationsManagerDW), может вызвать потери в производительности и увеличение времени резервного копирования. В связи с этим, важно определить необходимое время хранения информации от различных типов источников и настроить автоматическое удаление устаревших данных. В статье приведено описание процесса настройки, механизмов контроля и алгоритма очистки БД для System Center Operation Manager 2007 R2.
За хранение данных, полученных в результате мониторинга, отвечают две базы данных OperationsManager и OperationsManagerDW. В последней хранятся долгосрочные данные необходимые для отчетов.
Для OperationsManager всё относительно просто. В консоли управления (Administration -> Settings -> General -> Database Grooming) есть раздел в котором можно задать сроки хранения информации из различных источников (рис. 1).
За хранение данных, полученных в результате мониторинга, отвечают две базы данных OperationsManager и OperationsManagerDW. В последней хранятся долгосрочные данные необходимые для отчетов.
Для OperationsManager всё относительно просто. В консоли управления (Administration -> Settings -> General -> Database Grooming) есть раздел в котором можно задать сроки хранения информации из различных источников (рис. 1).
Рис. 1. Окно настройки сроков хранения данныхУдаление устаревшей информации происходит автоматически каждую полночь. Для ручного выполнения очистки базы данных необходимо самостоятельно выполнить процедуру p_partitioningandgrooming.
Через командную оболочку Operations Manager посмотреть насколько точно соблюдаются сроки хранения данных:
Через командную оболочку Operations Manager посмотреть насколько точно соблюдаются сроки хранения данных:
$Threshold = (Get-Date).ToUniversalTime().AddDays(-(get-defaultsetting)[42].Value).Date;Get-Alert Where {$_.TimeResolved -and $_.TimeResolved.Date -lt $Threshold} Measure-Object
Если результат отличен от нуля, то это свидетельствует о том, что сроки не соблюдаются (Рис. 2).
Рис. 2. Результаты проверки автоматического удаления В моем случае это оказались алерты, которые хранились 8 дней вместо 7. Вероятнее всего, что они удалились бы при следующем автоматическом запуске процедуры очистки. Чтобы проверить это, сократил срок хранения алертов на один день и запустил процедуру вручную и получил желаемый ноль в числе объектов.
С OperationsManagerDW все гораздо интереснее. Для неё нет графического интерфейса по настройке через консоль управления. Просмотр сроков хранения возможен через SQL-запрос:
use OperationsManagerDW;
SELECT AggregationIntervalDurationMinutes, BuildAggregationStoredProcedureName,
GroomStoredProcedureName, MaxDataAgeDays, GroomingIntervalMinutes, MaxRowsToGroom
FROM StandardDatasetAggregation
Результат выполнения запроса представлен на рис.3.
Рис. 3. Таблица сроков хранения различных наборов данных в OperationsManagerDW AggregationIntervalDurationMinutes - интервал в течении которого собираются данные, MaxDataAgeDays - сколько дней хранится информация, GroomingInterval Minutes - интервал между запусками процедуры удаления.
Скрипт для изменения сроков хранения:
USE OperationsManagerDW
UPDATE StandardDatasetAggregation
SET MaxDataAgeDays =
WHERE GroomStoredProcedureName = '
AggregationIntervalDurationMinutes = '
Go
Кроме того, существует утилита dwdatarp.exe. Описание её работы и файл программы можно найти здесь:
http://blogs.technet.com/momteam/archive/2008/05/14/data-warehouse-data-retention-policy-dwdatarp-exe.aspx
С помощью данной утилиты можно просмотреть и изменить сроки хранения данных в OperationsManagerDW.
Например, вывод текущей конфигурации осуществляется командой:
dwdatarp.exe –s “dw servername” –d “dw databasename”
У меня получились результаты представленные на рис. 4.
Рис. 4. Просмотр информации с помощью утилиты dwdatarp.exe В отличие от предыдущего метода, здесь показан объем хранимых данных и их процентное соотношение.
Проверить историю выполнения процедуры очистки можно с помощью запроса:
use operationsmanager;
SELECT * FROM InternalJobHistory Order By InternalJobHistoryId DESC
С помощью запроса можно вручную запустить процедуру удаления из OperationsManagerDW:
USE OperationsManagerDW
Exec standarddatasetgroom
Процедура запускается отдельно для каждого набора данных (необходимо указать id). Узнать id можно из таблицы, содержащей информацию о dataset. Например, в моем случае это будет выглядеть так:
USE OperationsManagerDW
SELECT [BaseManagedEntityId] ,[DisplayName_55270A70_AC47_C853_C617_236B0CFF9B4C]
FROM [OperationsManager].[dbo].[MTV_DataSet]
Соответственно скрипт для запуска процедуры по всем наборам данных:
USE OperationsManagerDW
Exec standarddatasetgroom '160230E3-E315-9350-4108-392A28F60AF5'
Exec standarddatasetgroom '216D2ABC-6FF9-1CCA-47EC-47A87703DFF0'
Exec standarddatasetgroom '53593936-DE62-E265-3764-5F78AF06DE69'
Exec standarddatasetgroom '57FEFB45-A835-4787-6092-D43BA2471EF8'
Exec standarddatasetgroom '0619FC49-ADAF-F064-554E-E99B4817682A'
В заключении приведу обзор ресурсов в интернете, которые использовались при написании этой статьи.
Настройка сроков хранения информации:
http://ops-mgr.spaces.live.com/Blog/cns!3D3B8489FCAA9B51!176.entry
Проверка работы механизмов очистки:
http://blogs.technet.com/jonathanalmquist/archive/2008/11/25/alert-grooming-is-it-working-or-not.aspx
Описание процесса удаления устаревших данных:
http://blogs.msdn.com/steverac/archive/2007/12/13/scom-2007-operational-and-datawarehouse-grooming.aspx
http://blogs.technet.com/kevinholman/archive/2007/12/13/how-grooming-and-auto-resolution-work-in-the-opsmgr-2007-operational-database.aspx
http://blogs.technet.com/kevinholman/archive/2008/02/13/grooming-process-in-the-operations-database.aspx
Комментариев нет:
Отправить комментарий