SCS Header
DexPro
Segmentation Manager
Data Centralisation Manager
The De-duplicator

DexPro

;

Dynamic Seg-  mentation

Data Centrali-
sation Manager

De-
duplicator

DexPro Campaign Manager
EMM
System Integration Server
The Replicator

DexPro
Plan Manager

Email
Marketing

System Integra-
tion Server

The
Replicator

Collaboration

Deal with Confidence

Case Studies


MMM Logo

Built to Order

Process Diagrams| Demo | Download Demo | View White Paper | Download White Paper

Distributed Database Availability (DDA) and WAN Traffic Reduction

FEATURES

Send and Receive Will send and receive data and database schema changes to participating databases
SQL Server 2005 compatible Will run on SQL Server 2005
SQL Server 2008 compatible Will run on SQL Server 2008
No Structural changes to tables Does not involve forcible addition of new table columns to accommodate Replication ID
No database size constraints No maximum number of columns or rows size in replicated tables
Data and Schema Replication Replication of all changes in data and database schema as they occur
Low latency No waiting time between reading from principal and writing to replica
Corruption Replication Protection Error log entries are not replicated thus eliminating possibility of passing application corruptions
Conflicting URN Protection Eliminates possibility that the same URN is allocated to different records from different systems
Unlimited databases and sites There is no limit to the number of servers and databases that can be replicated by MMM
No distance limitations Servers involved in replication can be any distance apart
Site failure protection Provides protection from database, disc, server, connection or any other site failure
False fail over protection Allows administrator to configure when to treat interruption as fail over event
Automatic Fail over Switches users to alternative server in the event of failure (subject to connection availability
Automatic Fail back Switches users back to failed server when recovered
Automatic Redo Automatic rewind to last backup recovered and redo ensuring no loss of data
Front-end independent No need to modify front-end applications for automatic Fail over and Fail back
No need for fail over witness Does not require witness to cover exposed mirror during fail over
No need for Distributor Does not require Publisher, Distributor, Subscriber(s) to perform Replication
Asynchronous Mirroring mode Does not wait for commit from replica thus saving 5-10% overhead in LAN and more in WAN
Mode independent fail over No need to be in synchronous mode for fail over
No naming constraints No need for replicated databases to have the same name
Replicas are in read/write state Replicated databases are in normal state and can be used for SELECT statements
Bulk-logged record replication Replication of bulk-logged operations
No Recovery Model constraints Principal database does not have to be in Full Recovery Model to replicate
No need for manual monitoring No need for DBA to monitor transaction log and log file synchronization
HCL Independent Does nor require use of components from Microsoft Hardware Compatibility List
No silent data corruption Logical groupings of database columns or rows remain intact during replication

:: : TOP ::

Multi-directional Mirroring and Replication - Step 1: Multi-Directional Updates

:: TOP ::

Step 2: Auto-Switching

:: TOP ::

Step 3: When DB Server 3 is up again

:: TOP ::



Home | Who We Are | Products | Technology | Collaboration | Guides | Knowledge Base | White Papers | Articles | Sitemap
Copyright  2005 - 2011 - Single Click Solutions Ltd