3 ms·
Show HN: DBHistory.com Simplified Monitoring for SQL Server
- BrentOzar 10y agoThis solves a tough problem. In a team with lots of sysadmins who need to do patches and tweaks, DBAs who need to do index tuning, and developers who need to do object deployments, it's hard to get everyone to log their changes the same way. Nice job.
- adyus 10y agoLooks like a nice tool for a DBA's arsenal. It would be more valuable if it also showed the impact of each change, where possible, in terms of performance, security, etc. In other words, it would add more value if it could translate the actual events into human concepts of impact.
- rusanu 10y agoThanks for the feedback. Entering more into performance monitoring dimension is something I hear often. Corroborate observed perf changes with logged configuration changes is something I do not see well covered in the traditional perf monitoring toolset in this space (SQL Server tools), so is definitely an opportunity I'm considering. It's just not a trivial change and will take some time to get it out.
- sixstringmonk 10y agoLooks great, but I wonder if it being SAAS / off prem is going to be a problem for some folks. I know for example, we would not want the names of our domain accounts, table names, proc names, etc... being stored in an external service.
- rusanu 10y agoThanks for feedback. I hear the same from some potential customers, and my response is that I'm not opposed to an on-premise deployment (technically the code is prepared for this, eg. how the configuration wizard finds the 'service' endpoint address and so on), but that would be a completely different ball game (deployment, maintenace, servicing, branding etc and ultimately a very different price point).