March 29, 2017 at 3:48 pm
Was wondering if anyone here is using DML Dashboard and might be able to provide some insight into something... I've asked this question at the Red Gate website and so far nobody has really responded with anything useful.
I've been using it for about a year now to track DML changes on our production servers. It works fairly well, especially considering it's free. Kinda slow if you use the web interface, but still usable.
My problem is concerning the RavenDB file it creates on the C:\ drive where it's installed. Apparently, it stores the DML changes that it tracks in the Redgate database that gets created when you install the application, but it only keeps them there for a short time. After some period of time it migrates them to this RavenDB file. Why they don't just leave them in the SQL database is a mystery, but whatever.
My issue is that this RavenDB file is growing really large. And when I've asked about trimming it down, the only response I've been able to get from Red Gate is basically stop the service, delete the file, and start it up again. So basically lose my entire history and start over again. This seems like an awfully lame implementation, to be perfectly blunt.
It wouldn't be the end of the world. I already capture the contents of the SQL table every hour and dump them into my own table, so I have essentually everything since we started using it in there. But the RavenDB is what the web interface uses, and we'd like to be able to use that.
So basically, does anyone know of a way to trim the data rather than just nuking the whole file? Or better yet, setting some upper limit to the file? Again, I get that it's a free program and therefore expectations can't be super high, but it just seems really sloppy that your only options are "unlimited growth" and "completely wipe" and nothing in between.
March 30, 2017 at 2:02 am
I'm checking with the developers.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 30, 2017 at 4:47 am
So, right now I only have a bad answer.
The core issue is that RavenDB is, and I'm paraphrasing a little to make this more of a family friendly post, a pile. We need to rip it out of the product and replace it. However, currently we don't have the resources available to spend time on this free tool. So, the solution to the problem really is back to losing the history of your changes or dealing with RavenDB's size.
Sorry about that.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 30, 2017 at 8:34 am
Grant Fritchey - Thursday, March 30, 2017 4:47 AMSo, right now I only have a bad answer.The core issue is that RavenDB is, and I'm paraphrasing a little to make this more of a family friendly post, a pile. We need to rip it out of the product and replace it. However, currently we don't have the resources available to spend time on this free tool. So, the solution to the problem really is back to losing the history of your changes or dealing with RavenDB's size.
Sorry about that.
Grant -
Thanks for at least replying - that's more than I've gotten from the support forum 😀
March 31, 2017 at 2:42 am
cphite - Thursday, March 30, 2017 8:34 AMGrant -Thanks for at least replying - that's more than I've gotten from the support forum 😀
Doing what I can about this too. Sorry.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply