December 12, 2008 at 12:22 am
Comments posted to this topic are about the item ETL Auditing
December 12, 2008 at 2:53 am
Great article. I use almost the exact same architecture and it works a treat!
The main benefit that I have found it being able to identify exactly what data in the data warehouse has been affected by a particular process and when.
The main difference in my implementation is that the Audit entity is more generic and leveraged by related audit subtypes. For example, I have an SSIS audit subtype as well as a TSQL subtype as these each have a separate set of attributes associated to them that I want to store.
This is invaluable when loading and consolidating data into a third normal form data warehouse from numerous sources. Several data marts can then be subsequently populated from this consolidated warehouse. The ability to quickly identify new and/or changed data in the warehouse when deciding what should move into the data mart(s) becomes extremely easy.
Lastly, even when Kimball Type-1 changes are implemented in the warehouse we move the original row off into an audit database which mean that if you need to roll back a load, even partially, it's possible to return data to it's original state prior to that process even if that included Type-1 updates!
December 12, 2008 at 4:06 am
Nice article. well written...
December 12, 2008 at 4:46 am
This is a great article and a much needed idea.:)
In my opinion something like this should have been built into SSIS as part of standard logging.
December 12, 2008 at 5:35 am
Very useful article. Easy 2 understand.
December 13, 2008 at 6:39 pm
Nice article. I would go for extending an existing solution than re-inventing the wheel, which is - project real. ETL auditing is provided as code samples and well documented. Not exactly the perfect solution, but one can always extend on these solutions and make an SSIS template package and embed the custom auditing in that, so that any new package created will benefit from it.
December 17, 2008 at 2:01 pm
great article, thanks. This is exactly what I am looking to do. I have several jobs here, and would like to be able to audit them. Is there some sample sql that can show me how to query this out of the audit table?
April 7, 2009 at 5:42 am
In my opinion you should replace auditing by logging...
Logging is what you wrote about, and auditing is usuall refered to each row in the pipeline and is incorporated in the datamart... audit a row represent information from each row imported from source and not about package. (Check Kimball sub-systems)
Regards,
Pedro
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply