Dragon EMS "dragon.db" files taking up space

[dtitzer]

A Dragon EMS server accumulates "dragon.db" files under the DB directory. What is the recommended practice for dealing with all these files? Is it worthwhile to archive them?

[Mullins__Keith]

Hi Dennis, In the upcoming Dragon v8.2 release, the Log Policy utility has been modified to perform a two-tier approach. This may be more inline in what you are looking for. The dragon.db files are compressed after one day automatically (this part cannot be changed by user configuration). The compressed files stay on the system until they are deleted after the user-defined retention period. Dragon v8.2 is scheduled to be released ~11/15.

[Mullins__Keith]

That is correct. The Log Policy can be configured to delete the files after 30-days (using your example), but the only items that will be deleted are the /opt/dragon/DB//dragon.db (or the dragon.log.xxx files if you configure those files to be deleted). Any files that are compressed would not be deleted in this manner by this utility. Using your example, you would have 2 copies of data for each day: one for the default location, and another of the days worth of events compressed by your script. This could compound your diskspace issue, especially if you have a day where a lare amount of events are generated. One thing you may want to consider is to have the Log Policy utility compress these database files if they are older than 30-days rather than delete. Than you can create your script to periodically check diskspace, and delete (or move to a different location/machine) these compressed files according to their age, size, age, etc.

[dtitzer]

Your old Knowledge Base article 13305 seems very relevant. Assuming I opt for deletion after 30 days, the daily directories will be deleted when they fall outside the 30-day sliding window. It doesn't sound like it matters whether the dragon.db file(s) inside are compressed or not. Take a look and tell me what you think. If I want to conserve space, I can compress the dragon.db files with a script, and let the Log Policy delete the aged-off directories and their contents.

[Tamera_Rousseau]

We will certainly keep this topic open for discussion David. Please feel free to update the community with what you discover. Thanks for the great question!