Hopefully you've read the introduction [https://www.rittmanmead.com/blog/2010/02/02/data-warehouse-fault-tolerance-an-introduction/], Part 1 [https://www.rittmanmead.com/blog/2010/02/08/data-warehouse-fault-tolerance-part-1-resuming/], and Part 2 [https://www.rittmanmead.com/blog/2010/02/10/data-warehouse-fault-tolerance-part-2-restarting/]. Those posts detailed methods for building fault-tolerant ETL code, with a

In my last post [https://www.rittmanmead.com/blog/2010/02/08/data-warehouse-fault-tolerance-part-1-resuming/], I described the First "R" in data warehouse fault tolerance: Resuming. As I mentioned in the introduction [https://www.rittmanmead.com/blog/2010/02/02/data-warehouse-fault-tolerance-an-introduction/] to this series, my goal is a triage approach

In the introduction [https://www.rittmanmead.com/blog/2010/02/02/data-warehouse-fault-tolerance-an-introduction/] to this series of posts, I spoke briefly about data warehouse fault tolerance and the unique challenges resulting from high data volumes combined the batch load window required to create them. I then defined the goal: a layered

With so much of the blog devoted to OBIEE, OWB and Essbase lately, I felt like it was time to do a few database-related postings. In the past, when I've posted database content to the blog, I usually gravitate toward ETL-related features: those that waffle between database administration

In the previous [https://www.rittmanmead.com/blog/2009/12/08/capturing-change-part-1/] part I outlined the business need for writing our own CDC routines and started to outline some of the issues we would need to resolve. Here I shall outline the approach we took and describe how to go

In this [https://www.rittmanmead.com/blog/2009/12/21/transcend-and-index-maintenance/] posting, I explained the Transcend product as a new offering here at Rittman Mead, and I went on to demonstrate it's use with index maintenance. Now, I'd like to demonstrate another staple of data warehouse