Section 7.3. MOM 2005 Reporting Databases


7.3. MOM 2005 Reporting Databases

The last two databases that need to be included in your MOM backup and restore plans are the SystemCenterReporting database and the ReportServer database. As mentioned in the previous section, the SystemCenterReporting database is the actual data warehouse where alert, performance, and event data reside for long-term storage. The ReportServer database stores the report definitions, metadata, and any cached reports. In SQL Server Enterprise Manager you will also see the ReportServerTempDB, which is used during the reporting process but does not store any relevant data long term.

7.3.1. SystemCenterReporting Database

This database houses three primary types of data: dimension data, fact data, and snapshot fact data. Each data type is groomed differently

Dimension records are never groomed out of the database, so this data will always exist. Think of this data type as tracking every type of record that has ever existed in its management group. For example, there is a dimension table in the database called SC_AlertResolutionStateDimension_Table. This table contains information about the available alert resolution states. If you create a new alert resolution state, a record (a row in the table) is created here. If you later delete that custom alert resolution state, that change would be reflected in the OnePoint database, but not in the SystemCenterReporting database. This is necessary because even after the custom resolution state is removed from OnePoint, there will still be historical records in the SystemCenterReporting database that were set to that custom resolution state.

All of the events, alerts, and performance monitor data fall into the fact data type. By default it is retained in the SystemCenterReporting database for 395 days (13 months). This can be altered on a per-table basis through the use of a stored procedure called p_updategroomdays. To change the retention interval, run the following query in the SQL Query Analyzer:

     exec p_updateagroomdays 'TableName', DaysToRetainData 

TableName is the name of the targeted table and DaysToRetainData is the number of days for which to retain the data. The tables are:

  • AC_AlertFact_Table

  • SC_AlertHistoryFact_Table

  • SC_AlertToEventFact_Table

  • SC_EventFact_Table

  • SC_EventParameterFact_Table

  • SC_SampledNumericDataFact_Table

Only the most current information is placed in the snapshot fact data tables, since the existing data is overwritten with every DTS cycle. If it is not overwritten, the data is groomed out after three days.

Since the SystemCenterReporting database is expected to grow quite large, be sure to allow sufficient time for backups to complete when creating your backup schedule. While the database is small, the backup to device-on-disk method will be usable. But as the database grows larger it may not be practical to maintain local disk space that is sufficient for the backups. You will be forced to go to multiple tapes or to a storage area network (SAN) that does have sufficient space.

Because both the SystemCenterReporting and ReportServer databases hold primarily unchanging historical data or report definition data, it is appropriate to perform a set of differential backups after you have obtained a good full backup of each, and then a full backup on the weekends. In this way, only changes in the databases since the last backup are captured, resulting in a smaller volume of data and quicker backups. Also, since these databases are not very dynamic, backing them up on a less than daily frequency is a good idea.

7.3.2. ReportServer Database

Report definitions can be imported at the same time that the management pack definitions are imported into the management group. Therefore, you can restore the default report definitions at any time. Like the management packs, you can customize the available reports (see Chapter 8). Therefore, you will need a method to protect those changes from SQL or server failures.

There are two ways to protect the data that is contained in this database. You can easily include it in your standard SQL database backup routine, but just as all of the management packs are contained in the OnePoint definition, so too are all the reports contained in the ReportServer backup. To recover a single report, you would have to restore the entire ReportServer database , which may not be the most practical thing to do.

Instead, there is a reporting equivalent of the ManagementModuleUtility called the Report Utility (rptutil.exe ). It is installed on the MOM reporting server in the <installdrive>\Program Files\Microsoft System Center Reporting\Reporting directory. With this tool you can import and export reports in groups or individually from the ReportServer database.

This is a command-line tool that, when run without any parameters, will export all the report definitions in the database and save them to a single file (MOMReports.xml) on the root of the computer that it is run from. This tool gives more granular control over imports and exports by specifiying the path to an individual report or report folder.

For example, to back up the report definitions for Microsoft Operations Manager Management Alert Tuning reports you would specify the following command line:

     Rptutil /file:c:\MOMAlertTuningReports.xml /reportpath:"Microsoft Operations Manager     Reporting/Alert Tuning Reports" 

This would capture all reports in the Alert Tuning reports folder to the MOMAlert TuningReports.xml file.

The easiest way to find the path to an individual report or report folder is to open the reporting console (http://<reportservername>/Reports). Navigate to the report folder of interestthe path to the folder is tracked in the header of the page and updated as you navigate through the console. For example, in Figure 7-23 the path to the Alert Tuning Reports folder is circled.

In the command-line example, it is not necessary to include the top-level Home folder in the path. If you want to target an individual report at the command line, simply continue the path with the report name.

Figure 7-23. Path to the Alert Tuning Reports folder





Essential Microsoft Operations Manager
Essential Microsoft Operations Manager
ISBN: 0596009534
EAN: 2147483647
Year: N/A
Pages: 107
Authors: Chris Fox voc

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net