12 Kasım 2014 Çarşamba

Idera: Another awful experience with Compliance Manager

Hi folks!

For more than a year I have been using Idera's Compliance Manager (CM) tool which is as its name refers, a compliance tool. I actually have created lots of tickets because of lots of problems with this tool during this period of time. I guess some of you may find this comment enough to keep away from this tool, especially for a production environment, but for the others let me tell you a fresh story I have just experienced this morning.

Last night I enabled Before/After feature for a specific table's some specific fields to collect detailed information about the modifications and as I thought its agent sends the records from the source to the target I observed for any change in the repository database, but I saw nothing spectacular in the row size of the tables. However this morning, clients began screaming with the following kind of errors:

ErrorQuery: SELECT 'Error.  Table: dbo.xxx, Error: Invalid object name ''SQLcompliance_Data_Change.SQLcompliance_Changed_Data_Table''.' Message FROM [SQLcompliance_Data_Change].[SQLcompliance_Changed_Data_Table] WHERE 1 = 0An error occurred sending error message query: Invalid object name 'SQLcompliance_Data_Change.SQLcompliance_Changed_Data_Table'.Invalid object name 'SQLcompliance_Data_Change.SQLcompliance_Changed_Data_Table'.The statement has been terminated.

The name of the table, which I replaced with "xxx" in the error message, was the one I enabled for Before/After data collection. As soon as I saw this error message, I thought CM might had created some DML Triggers on this critical table and this was the case indeed! I immediately shutdown CM's agent service, dropped the trigger and cleared this configuration from the properties of the related database from the CM's console.

Then according to the feedbacks from the end users the problem was solved, then I dug into the problem to understand more about the "SQLcompliance_Data_Change" schema, as it's in front of the table name, I assumed it's a schema. However, neither the schema nor the table were there! The database that I had this problem did not contain them. So it turned out that CM would keep these records in the production database itself, like a CDC configuration. But it skipped or failed to create the schema and table, it only created the trigger and our most critical production database went down!

For those who consider using this tool in their production environment, god bless you my friends...

Ekrem Önsoy

Hiç yorum yok: