What is our primary use case?
Auditing. We mainly use it to follow up on changes to the individual databases. We audit exactly what the database administrators are doing. Those are the main two points. In some situations, we have the need to really audit everything that happens on a certain table, if there is any highly critical information there.
We follow no particular regulation criteria. We have an individual catalog of potential issues, and we have a template that we are using. We did a risk assessment, and we identified several points that have to be checked by Compliance Manager and several other tools. We also use SQL Secure from IDERA. We established some custom counters in Diagnostic Manager, for example, to check certain parameters, just to make sure that everything is working as intended by us.
How has it helped my organization?
Using it was just a security process that had to be done. We didn't change the way we were working or the way things are working. It's just an additional process that makes sure everything is secured. It didn't change anything in our environment. It was just a need, and the product does exactly what we needed.
What is most valuable?
We had to use auditing. It was a demand that came from our security group. We had no choice.
What needs improvement?
What would really be nice is if it were a bit more flexible, in several ways. The assistant for creating rules is nice, as it looks like Microsoft Outlook, but it's not flexible enough. What would really a good thing is if you could refer to an external list or table for filtering on, say, certain applications, IP addresses, or host names; or perhaps even combinations of host name and application name. Because in our environment, we're suffering from the fact that we have a huge amount of login events. A really huge amount of login events. We have gigabytes of login and logout from the same application; sometimes, several thousand times within one second. These are very badly coded applications for sure, but we have a lot of that. We didn't code them ourselves. It's bought software. We need filter rules for certain combinations as I mentioned above. These rules have to be maintained and have to be audited by the people that take care of the applications that cause the login events.
It's difficult for us because we don't want to give them access to Compliance Manager. What would very much easier for us is to give them some kind of self-service to take care of a list of a combination of host, account, and application name, because only they know whether this combination is valid or not. They know how their application service is named and what services they're using. They have to maintain this list. It would be much easier if there was a table that we would maintain, or they would maintain via self-service, and we could use this table to establish these filter rules.
At the moment, we have to check all the rules after this table is maintained by our colleagues who maintain or run the applications.
After that, I wrote a stored procedure that creates, depending on the table, new rules in Compliance Manager, but that's a workaround. It's not a really nice solution, so it would be much better if Compliance Manager would have functionality like that built in. That's one thing.
Another nice feature would be concerning GDPR: some kind of base-lining of database access or some kind of inventory for tables or certain columns or types of columns. IDERA already has several other tools, free tools, to search for certain criteria of columns holding things like credit card numbers, for example. It would be nice if that would be a feature within Compliance Manager, as it's very a very similar thing, it goes hand in hand.
For how long have I used the solution?
Three to five years.
What do I think about the stability of the solution?
It is stable. We haven't noticed. It works fine.
We had a few performance problems in the past reading the trace files. We had a bit of a bottleneck on the server side where all the trace files would come together. Although the server should be fast enough, and we didn't experience any bottlenecks on CPU or IOPS; everything was looking fine; CPU was at about 30 percent, and the disks were far from being busy. But the trace files were not being processed fast enough or there were more coming in than processed.
It became more and more of an issue and, at a certain point, we had no other choice than to delete trace files. We lost of a lot of information because the more trace files we had in the folder, the worse the speed, or the performance for processing trace files, became. It got slower and slower. That was a real problem we experienced a lot of times. That improved since the release of a certain version number. It isn't an issue anymore.
We're running it on a machine with eight logical CPU cores, no physical CPU cores. We are auditing about 60 SQL service instances, and it works fine. We are absolutely pleased by the performance at the moment.
What do I think about the scalability of the solution?
Scalability, was a bit tricky because we care very much about security and we have a lot of firewalls, a lot of different networks separated by firewalls. It was a bit tricky to get all the communication done in the right way. Meanwhile, it works fine, and I'm really glad about that. We didn't have to split into several separate Compliance Manager servers. We can do everything with just one monitoring cluster. The monitoring cluster is running all the IDERA products.
We are using SQL Diagnostic Manager, SQL Defrag, Compliance Manager, SQL Safe - nearly everything that IDERA has in its portfolio. All of this is run on this cluster with those cores and about 92 gigabytes of RAM. We are far from what is possible with these machines. We have a CPU usage of about 30 - 35 percent, and everything is running really fine.
How are customer service and technical support?
To be honest, technical support has gotten worse. It was really fine in the beginning, but it's not what it used to be. The time until we get feedback is increasing. Perhaps it's because we have a lot of open tickets at the moment. We have a lot of different network zones and firewalls, and it's quite tricky to get all this running in our environment. We are using support, perhaps, in a really excessive way.
We have a lot of problems that have existed for a very long time. We have a lot of feature requests and several bugs that haven't been fixed for more than a year now. That's a bit annoying. In the past, this all went a bit faster, but it since IDERA started to release the dashboard, you can see that there is a really big focus on the dashboard. Developers are trying to get it running and to get it to run faster, improve the performance. The other features have suffered as a result.
For example, in SQL Safe we have been waiting for so long to use striping versus IBM TSM in the SQL Safe console. You can use it in the dashboard but you can't use it in the console. The feature isn't there. They just forgot to implement it. Also, the command line interface of SQL Safe is missing it. We have been waiting for something like one and a half years now to get this feature in the command line interface, in the console, because the dashboard isn't fast enough for us.
There's a different set of features in the dashboard and in the console: for certain things you have to use the console, for other things you have to use the dashboard, and that's a bit annoying as well.
Which solution did I use previously and why did I switch?
We used another solution but it was built by us. We did some Visual Basic scripts and collected the performance counters, but the performance was bad and it was difficult to maintain. We were looking for a professional tool to do our monitoring, and later auditing as well. The IDERA tools performed best.
How was the initial setup?
It got more complex with the dashboard. We have a lot of problems with the dashboard. Sometimes registration via the dashboard doesn't work, so have to do it several times manually. We have often been in contact with support because of that.
Thinking back to when there was no dashboard, setup was very easy: just click, click, click, and finished. Everything was working as intended. What we're experiencing now is, on the one hand, difficulties with the dashboard and, on the other hand, sometimes settings get lost when installing an update, so they are set back to default. That's also a bit annoying but not really a big problem.
What's my experience with pricing, setup cost, and licensing?
It's a good price value. Pricing is absolutely okay for us at the moment. The other tools weren't cheaper.
Which other solutions did I evaluate?
We tested a lot of individual tools, and Compliance Manager was, at that point, the only one that was really working on SQL Server. Strange as it may sound, it was really true. We tested Database Activity Monitoring, SQL Sentry and Quest, and several other things but we experienced individual problems with each product.
For example, the Database Activity Monitoring from McAfee wasn't able to recognize what objects were accessed when executing a stored procedure. That was something that was absolutely astonishing to us. Compliance Manager really was the only product, at that point, that was exactly doing what it was promising.
What other advice do I have?
What I like most among all IDERA products is Diagnostic Manager. It's really easy to use, it's very stable. It comes out of the box with a good threshold for certain counters. After that comes Compliance Manager. It's a nice tool as well, with some restrictions as I already mentioned. But on the whole, a very good product as well.
I would rate IDERA SQL Compliance Manager at seven out of 10. I like the product, I like the features, but not everything is working as intended and development isn't as fast as I would expect. Also the bug-fixing takes too much time, in my opinion. That's why I wouldn't give it a 10.