Subscribe

By RSS
By Email

Delivered by FeedBurner

Recent Comments

    • Formax - This post brings me back to the 'old days' when…This post
    • Raju - Hi Karthik, Thanks for your valuable information, actually I am new…Hi Karthik
    • srinivas o - This has been very practical and sensible blogging especially for…This has b
    • srinivas o - I have seen costly way of doing it, in which…I have see
    • Peter S - Excellent BI blog, and I would like to invite you…Excellent

Data Integration Challenge – Instantaneous Data Refresh, Bulk COMMIT

By Muneeswara C Pandian on June 30th, 2009 under Business Intelligence.

A ‘data load window’ is the time frame during which the changes to the data are applied in a BI system. A state of data inconsistency can exist during data load window if individual tables get refreshed independently.

In a typical data integration process we assume that the tables are not used for reporting during ‘data load window’. Within a ‘data load window’ the data across all tables are not in sync and keep varying until the end of the last ETL job, any user performing data analysis during this period can see strange actions on the data that he is analyzing. Generally different jobs load different tables across different time intervals.

Applying the data changes across all tables (that are used for reporting) in one-go without time gap is called ‘Instantaneous Data Refresh’.

One of the ways of ensuring instant reflection of data changes across multiple reporting tables is by using ‘Bulk Commit’. ‘Bulk Commit’, process leverages the concept that all DDL statements require a ‘COMMIT’ instruction to apply the changes on to the table data. Following are the steps involved in using ‘Bulk Commit’

Having one COMMIT statement after multiple inserts and updates ensures that the data changes are reflected across the tables instantaneously.

Please share other means of instantaneous data refresh.

Tags: , ,

Bookmark and Share

Comments:1;




One Response to “Data Integration Challenge – Instantaneous Data Refresh, Bulk COMMIT”

    srinivas o Says:

    I have seen costly way of doing it, in which each table has a clone table and all reports points views on to say Table A_Clone and ETL say is pointing to Table A, Once ETL Loads are done, Views are changed to point to A, and A_Clone is synced with A. Report views are pointed back to A_Clone once both tables are in sync. I guess Teradata has a way to sync two tables efficiently.

Pitch in with your comments