BC remote Oracle DBA - Call (800) 766-1884  
Oracle Consulting Oracle Training Development

Remote DBA

Remote DBA Plans  

Remote DBA Service

Remote DBA RAC

   
Remote DBA Oracle Home
Remote DBA Oracle Training
Remote DBA SQL Tuning Consulting
Remote DBA Oracle Tuning Consulting
Remote DBA Data Warehouse Consulting
Remote DBA Oracle Project Management
Remote DBA Oracle Security Assessment
Remote DBA Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Links
Remote DBA Oracle Monitoring
Remote DBA Support Benefits
Remote DBA Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





   

 

 

 

Remote DBA services

Remote DBA Support

Remote DBA RAC

Remote DBA Reasons

Remote Oracle Tuning

Remote DBA Links

Oracle DBA Support

Oracle DBA Forum

Oracle Disaster

Oracle Training

Oracle Tuning

Oracle Training

 Remote DBA SQL Server

Remote MSSQL Consulting

Oracle DBA Hosting

Oracle License Negotiation

 

 


 

 

 

 

 

 
 

Oracle Tips 

by Burleson Consulting

The Data Warehouse Development Life Cycle

Distributed Oracle Data Warehouses Master-Slave Oracle Replication

When using Oracle snapshots, developers also have to face the issue of what to do when a slave database becomes unavailable. Should the update proceed to update only the available slave databases, or should the update wait until all slave databases are online and available for updating? If the developer chooses the simpler of the two methods--waiting for all slave databases to be available--then the developer takes the risk that a major failure of one slave database will affect the currency of the other slave databases. The developer will also have to account for the possibility that a transaction may abort due to some shortage of database resources (i.e., shortage in storage area, shortage of available tablespace, and so forth) and the previously made changes to the slave databases will have to be rolled back.

On the other hand, if developers choose to propagate changes regardless of availability, the change propagation subsystem must be able to track the changes to each slave database. The most common approach for slave tracking is to have the propagator task reference a change table that keeps a list of all changes and a set of flags to indicate which slave databases have been updated. Only after all of the slave databases are successfully updated will a row be deleted from the change database.

Another popular approach for warehouse replication is to avoid the use of Oracle snapshots and simply copy the tables using the Oracle export/import utility. Updates are achieved by rerunning nightly warehouse population jobs once for each replicated table.


This is an excerpt from "High Performance Data Warehousing", copyright 1997.

If you like Oracle tuning, you may enjoy the book Oracle Tuning: The Definitive Reference , with over 900 pages of BC's favorite tuning tips & scripts. 

You can buy it directly from the publisher and save 30%, and get instant access to the code depot of Oracle tuning scripts.

 


Expert Remote DBA

BC is America's oldest and largest Remote DBA Oracle support provider.  Get real Remote DBA experts, call
BC Remote DBA today.

 

 

Remote DBA Service
 

Oracle Tuning Book

 

Advance SQL Tuning Book 

BC Oracle support

Oracle books by Rampant

Oracle monitoring software

 

 

 

 

 

 

BC Remote Oracle Support

Remote DBA

Remote DBA Services

Copyright © 1996 -  2013 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.



Hit Counter