O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
Fase 1 Steps Shutdown the production database Enable client connections to a progress database we call replication database (RDB) Back-up the production database as soon as possible to reduce the down time Then we re-start the production database so the users can re-start to use it normally. As this process is completed, the copy of the production database is dumped and loaded; it doesn’t matter how long does this process take as long as there are disk space to hold all the transactions that will be generated during the Dump and Load When it is completed, we start to apply data from the replication database (RDB) to the new production database; this is illustrated by the arrow from the replication database to the new database When the apply process is caught-up, we can focus on the second shutdown of the production database; what we call Fase 2
Fase 2 More complex, consists of the following steps: Shutdown the production database, finishing applying any remaining transactions to the new dump and load database Perform a few house keeping activities, like dumping database sequences from the old production database and loading them into the new database Then we will validate the old and the new databases to make sure they are identical, we don’t want to loose any data in this process And finally we will replace the old production database with the new database, start it up and make it available to the users.
Captures changes in the source Flexibility on how to expose data; table that is exposed to the web and you don’t want to expose the data, you can exclude Source and destination do not need to be the same You may be willing to change the destination database and the replication keeps going You can set up alarms for that You can add columns at the target databases If the report is going slowing, you add a new index Does not affect Progress, you can tune the reporting users not the database users, a distinguish difference Target side only fields: sometimes we replicate to staging database and people extract data
Net change: Data is live; batch loads are not; good to BI initiatives, Pro 2 only relocate the changes Also helps with long replications and hiccups Customer reactions: this thing works, we should have had this a long time ago Supports transaction integrity; that is near real time Scenarios: multinationals that have old ERPs
Diminuindo custos e aumentando a produtividade em tempos de crise economica
Diminuindo custos e aumentando a
produtividade em tempos de crise
Professional Services Director