IMPORTANT: These routine tasks include SQL Server maintenance jobs that keep the data and the

engine performing at satisfactory levels, and also keep the data backed up to aid recovery if there is a
disaster. This information is intended for use by database administrators (DBA) and ePO administrators
only. Use the following procedure at your own risk. McAfee does not assume responsibility for any
damages as a result of following these instructions.

Background:
SQL Server uses the concept of Write Ahead Logging, where each data change operation is first written
to the Transaction log (.LDF) from memory (buffer pool) and periodically flushed to the disk data file
(.MDF) as part of the CheckPoint process. (Data change operations are Insert, Update, Delete, and other
operations such as index rebuild and reorganize.) Using a Transaction log ensures that if there is a
disaster, such as hardware failure or human error, you can restore the database to an earlier state with
minimal data loss.

Full Recovery Model:

After backing up the Transaction using the Full Recovery model, SQL Server flags backed-up records
as Inactive and truncates the log. In this way, any new operations that are logged to the Transaction log
can reuse that space by overwriting the inactive entries, which help to prevent the log size from
growing.

If no periodic backup of the Transaction log is done, the size of the Transaction log continues to grow
until it consumes all available disk space. So, if your ePO database is configured to use the Full Recovery
model, it is important to perform regular Transaction log backups to keep its size in check.

Simple Recovery Model:

In the Simple Recovery Model, after the CheckPoint occurs and the records are flushed to disk, SQL
Server truncates the Transaction log, which frees up the space internally in the Transaction log file. The
Transaction log does not grow in size as long as there is enough space available for the current open
transactions.

In the Simple Recovery Model, the concept of backing up the Transaction log is not used, because you
only take a regular full backup of the ePO database. If there is a disaster, you can recover only to the last
full backup. All changes that occurred after the last full backup are lost.

The Simple Recovery Model is an acceptable solution for most enterprise customers, because the data
lost in a disaster is usually event data since the last full backup. The Full Recovery Model includes the
administrative overhead of backing up the Transaction log for your ePO database periodically.

For this reason, the Simple Recovery Model for the ePO database is recommended. But, if you choose
to use the Full Recovery Model, ensure that you have a good backup plan for both your ePO database
and Transaction log. A discussion of the backup plan for SQL Server databases is beyond the scope of
this article. For more details, see SQL Server Books Online at: http://msdn.microsoft.com/en-
us/library/ms130214.aspx.
NOTE: If you have multiple databases with different recovery models, you can create separate database
maintenance plans for each recovery model. In this way, you can include a step to back up your
Transaction logs only on the databases that do not use the Simple Recovery Model.

Set the ePO database Recovery Model to Simple

To ensure that the recovery model is set to Simple, open SQL Server Management Studio and perform
the following steps:

1. Click All Programs, Microsoft SQL Server <version>, SQL Server Management Studio.

2. Select the Authentication type (Windows or SQL Server) and click Connect to log on to the SQL
Server instance hosting the ePO database.

3. In the Object Explorer window, expand the Databases node.

4. Right-click the ePO_<server name> entry.

5. Select Properties. The Database Properties window opens.

6. Click Options in the Select a Page area on the left pane.

7. Click the drop-down arrow on the right of the Recovery model and select Simple.

8. Click OK.

Shrink Database and why it is NOT recommended:

Avoid shrinking the ePO database as much as possible. Shrinking a production SQL Server database
would introduce logical fragmentation. (Physical order of the pages in the leaf level of an Index is not the
same as the logical order of the pages.) Effectively, the disk head must go back and forth in reading the
pages, which results in more I/O operations and degrades performance.

When you shrink the data file, pages at the end of the data file are moved to the beginning of the file,
disregarding any potential fragmentation that is introduced in this process.

If you find that after you delete events and shrink the database, the ePO database grows in size, space is
needed for events sent by the agent. Shrinking the data file after deleting the events would only cause
the file to grow back, in addition to causing fragmentation. If space usage is a concern, consider filtering
the non-essential events using ePO Event Filtering.

NOTE: You can consider shrinking the data file after performing many delete operations, such as purging
old events, if you know that you do not need that space again for storing new events. Otherwise, rebuild
the indexes periodically and filter the unnecessary events using ePO Event Filtering to avoid
capturing unwanted data in the first place.

IMPORTANT: Filtering events have a direct impact on what reports can be generated that use those
events. Ensure that you filter out only those events that you know are not needed for day-to-day
reports. Back up the ePO database before purging the older events. For future reference, you could
always restore this ePO database backup to a new name to generate reports for that period.

As long as proper database maintenance is performed, such as rebuilding and reorganizing indexes, the
size of the ePO database does not negatively affect query performance. If you regularly purge old
events, such as all events older than three months, using the ePO Purge Events Server Task, the
database size stabilizes. (The database size stabilizes assuming database growth rates are proportional
to deleted, older events.)

You must have a proper database maintenance plan configured to ensure that the ePO database
performance is healthy.

Create a maintenance plan for the ePO database in SQL Server:

1. Click All Programs, Microsoft SQL Server <version>, SQL Server Management Studio.

2. Select the Authentication type (Windows or SQL Server) and click Connect to log on to the SQL
Server instance hosting the ePO database.

3. Expand Management in the Server Object Explorer window.

4. Right-click Maintenance Plans and select Maintenance Plan Wizard.

5. Type a name for the Maintenance Plan (for example, ePO Database Maintenance Plans).

6. Change the schedule. Click Change and then click Next.

NOTE: Schedule the task to execute during nonpeak times, for example, a recurring task every Saturday
at 11 p.m.

7. Select the following options under Maintenance tasks and click Next:

o Check Database Integrity

o Rebuild Index

o Back Up Database (Full)

8. Define the order for the tasks to execute as follows and click Next:

o Check Database Integrity

o Back Up Database (Full)

o Rebuild Index
NOTE: These tasks can be interchangeable in terms of the order in which they execute. Create a
database backup before the index rebuild process to ensure that there is a working backup copy of the
database if there is an issue during the rebuild process.

9. Define a Check Database Integrity task:

a. Select the ePO database ePO_<servername>.

b. Select Include indexes.

c. Click Next.

10. Define a Back Up Database (Full) task:

. Select the ePO database ePO_<servername>.

a. Type the backup path location.

b. In the Set backup compression drop-down, select Compress backup.

c. Click Next.

11. Define a Rebuild Index task:

. Select the ePO database ePO_<servername>.

a. Select Object: Tables and Views.

b. Select Change free space per page percentage to: 10%.

c. Under Advanced options, select Keep index online while reindexing.

NOTE: All editions of SQL Server do not support online Index rebuild. For more details about which
editions support the Online Index rebuild, see SQL Server Books Online documentation.

d. For index types that do not support online index rebuilds, select the option Rebuild Indexes
offline.

e. Click Next.

NOTE: An Index Rebuild task would cause the statistics to be updated as part of the rebuild, effectively
with full scan, so an Update Statistics task is not needed after a Rebuild Index.

12. Define Select Report Options:

. Select Write a report to a text file and type the wanted folder location.

a. Click Next.
b. Click Finish.

NOTE: Monitor the maintenance task and avoid running the task during production hours for a large
ePO database.

Solution 2

If you have a large production database, use a custom index rebuild or reorganize script instead of
the Index Reorganize and Rebuild Maintenance plan tasks.

Custom tasks allow more flexibility about which objects need to be reorganized and which need to be
rebuilt, instead of rebuilding every object regardless of the fragmentation level.

According to SQL Server Books Online:

• If fragmentation is between 20% and 30%, reorganize the index.

• If fragmentation is > 30%, rebuild the index.

You can determine the fragmentation level of an index by querying

the sys.dm_db_index_physical_stats dynamic management view (DMV) entry. SQL Server Books Online
provides a sample SQL Script that provides a fragmentation ratio as listed above. See the topic
on sys.dm_db_index_physical_stats in the SQL Server Books Online documentation link below:

http://technet.microsoft.com/en-us/library/ms188917.aspx

NOTE: Example D in the online documentation provides the sample code.

It is important that you update the statistics after an Index Reorganize command. Unlike Index Rebuild,
statistics are not automatically updated as part of an Index Reorganize. An updated SQL script located
in RebuildReorganizeIndexes-V4.zip, based on the above SQL Server Books Online example, is located in
the Attachment section of this article. The attached script adds the step to update the statistics after an
Index Rebuild Operation.

You can further customize the script to include the option to perform an Online Rebuild of Indexes.
Online Rebuild provides more concurrency during the Index Rebuild and is resource-intensive. This
feature is not available in all editions of SQL Server. See the Books Online documentation on which
editions support the Online Rebuild of Indexes feature.