Best Practices for DSS-SAM Database Maintenance

Usage and Config BFI
1

(imported topic written by SY57_Jim_Montgomery)

I don’t

think

there are any built-in maintenance activities that DSS-SAM performs on itself (pls correct me if I’m wrong).

Is there a recommended set of maintenance routines we can run (like the BigFix database has), or is it safe to set up just a regular index rebuild job weekly on my DSS-SAM database?

Thanks,

Jim

2

(imported comment written by SystemAdmin)

Here are some things you probably want to set up for your DSS SAM deployment:

  1. Periodically back up your BFInventory database.

  2. Keep up with the latest releases of DSS SAM and the software catalog. Back up BFInventory before starting an upgrade.

  3. As disk space requires, purge or rotate the development.log and production.log files in DSS\rails\log.

  4. If you are running DSS SAM 1.0.x or 1.1.x, or have upgraded from one of those versions, consider switching the logging of the BFInventory database from Full to Simple logging. You may also chose to reduce the size of the BFInventory.ldf file. Customers who originally installed version 1.2.x have simple DB logging by default.

3

(imported comment written by Shembop91)

Jeff,

What could I use to gauge the size of my BFInventory Database to know if it is out of control, or if the log file is too large?

I am currently at 17+ Gigs, with a log file 1/10th of the BFInventory Db.

I have Simple logging set up.

4

(imported comment written by dgies91)

The BFInventory database generally does not become “out of control” because it overwrites data from previous data imports. The main determinants of database size are the number of computers, the amount of software installed on those computers, and the number of analysis properties which have been selected for import. We have seen databases larger than that at big customers, but even a mid-size deployment could consume 17GB if you start importing lots of computer properties.

As for log size, Simple logging will cause it to grow fairly slowly, but the total size will be determined by what you have configured on the SQL Server. If you have a limit, SQL Server will start overwriting older log entries once it is reached. If you have no limit, the log can grow without bound. If you don’t have requirements for traceability in your database, a log limit in the tens of MB may be sufficient.