In many systems today, significant read activity is isolated from write activity in the form of a data warehouse or separated system. There are numerous advantages to this approach; read-intensive applications tend to want more index structures, data redundancies, and even alternate views of data. Transaction processing systems want throughput, and only the most minimal overhead to allow the best write throughput. The access patterns of readers and writers typically differ; readers are more prone to larger analysis types of queries and writers are more prone to singleton inserts, updates and deletes. When these activities are separated the administrator can focus on recovery strategies for a smaller more manageable transaction processing system; OLTP databases tend to be only a fraction of their data redundant Decision Support/Analysis Database cousins. Having said this; however, it is not always possible to clearly make this distinction. Once data is copied/transformed/archived to an analysis-oriented database it must be maintained and/or rebuilt periodically. Users certainly benefit from looking at a transactionally consistent version of the database; however that version is no longer current data, may take many hours to build and index and might not be what the user really needs. Enter snapshot isolation.