Synchronous serial replication has two serious problems:

    It must use two-phase-commit protocol (2PC) to ensure all involved system commit the data changes at the same time or the change must be rolled back. The overall system availability is the single system's availability divided by N+1 times, where N is the number of replication targets.
It must force the primary system to operate at the same speed as the serial processing of the target system -- a large waste of resources.
    As a result, synchronous serial replication is known to work only within 5 mile radius using fiber optic networks.

    Asynchronous serial replication is the only practical solution for the vast majority computer applications today.

    However, asynchronous serial replication necessarily requires a replication queue between the primary and secondary systems. The primary processes everything in parallel while the replication is strictly serial causing an unavoidable replication queue overflow problem. Rebuilding the replication queue requires rebuilding the entire target dataset. The larger the dataset the longer the service downtime.

    These weaknesses undermine every IT infrastructure today. And the prospect of steadily increasing transaction (think about micro-payments from cell phones) is only making the matter worse.

    ICX-UDS is the first parallel synchronous transaction replication engine. It does not require total serialization nor 2PC. Therefore it promises to deliver higher performance and higher availability at the same time when used for database clusters (U.S. PAT: #6,421,668).

    A: ICX-UDS is situated in the strategically important network path of database services. It exerts its control from that location, similar to a firewall or content management network switch.

    On the surface ICX-UDS will increase transaction processing latency. However, it compensates the performance loss by massive performance gains via distributing read-only queries to multiple synchronously replication database engines. Further, this is the only transaction replication system that does not drain primary server's power for replication.

    Theoretically, this is also the ONLY universal database replication architecture that can eliminate all single-point-of-failures without altering user API (Application programming interface).

    Moreover, this truly shared-nothing architecture with full redundancy is capable of delivering extreme fail over performance that was only possible by proprietary fully redundant fault tolerant hardware systems -- fully redundant synchronous concurrent processes.

    All these result in the most scalable multi-processor architecture -- need more power, add more server.

    One way to see the asynchronous serial replication (log shipping and others) problem is to try to rebuild the replication queue without interrupting service. A careful look into this reveals a critical dependency -- the "known good point" between the primary and the backup servers. For asynchronous methods, without this point, all primary log contents are meaningless. The nature of asynchronous replication methods mandate the waiting for the complete building of the backup server to the "known good point" or void all saved log contents on the primary. The parallel synchronous replication architecture eliminates this problem entirely (see www.pcticorp.com/onlinebook/3.1 for details).

    Disk mirror systems also have a detrimental weakness: if the primary disk is corrupted due to a server crash, hard disk mirroring systems will automatically replicate the corrupted data to the backup servers -- resulting in unnecessary losses. In fact, all replication systems working on database file level have the same problem.

    Saved journal files can be used to manually recover some lost transactions after a primary crash. Time dependent transactions, such as bidding results, are not recoverable. More seriously, there is no simple way to rebuild the replication queue without shutting down service. This is because correct replication depends on the fact that both servers holds exactly the same data after all queued logs are applied and before the new transaction begins.

    It is a good idea to separate the client traffic from the server traffic by giving them separate NICs. You can speedup operations by giving one NIC to each clustered SQL Server. You can also further distribute the client traffic onto multiple NICs.

    The hardware configuration may vary amongst servers. This variation will come with a cost -- since your update performance is determined by the slowest server in the cluster. Therefore, unless your updates are very light, the hardware configurations should be very similar.

    ICX-UDS will work even if the servers are of different configuration. If your application contains mostly read queries and infrequent updates, then the use of diversified hardware is permissible and encouraged.

    There are two resync utilities: Delta Resync Tool (DRT) and Power Resync Tool (PRT).

    DRT takes advantage of ICX-UDS' strategic position on the network to save a transaction log difference (delta) while some servers are out of sync. This log can be re-applied at a later time to re-synchronize the servers for service.

    PRT is activated via ICX-UDS Control Center. It can be configured to: a) re-synchronize out-of-sync database servers; and b) generate backup scripts to help reduce future resync time for remote servers via slow networks. PRT uses SQL Server's native backup and restore functions coordinated by PCTI's proprietary resync algorithm to provide a true seamless resync process without interrupting production cluster. (see http://www.pcticorp.com/onlinebook, follow Administration, Non-Stop Server Resynchronization).

    Since ICX-UDS replicates at the SQL Server level, if you are an ISP or ASP, this feature will save you hours of log shipping work for the multiple databases hosted on your server.

    An ICX-UDS replication gateway allows the user to set default serialization method for each critical database operation, such as select, insert, delete, update and stored procedure. If the stored procedure(s) can update data, setting it to use exclusive locks will provide data consistency. Otherwise, using shared lock will improve performance.

    If the application uses stored procedures to update database and if it is possible for multiple stored procedures update multiple dependent tables concurrently, then in the current releases (v.3.1), it is necessary to manually insert the concurrent dependencies via the Critical Information dialog interface. This interface will generate two files: Critical1.ini and Critical2.ini. These two files record the concurrent dependencies between stored procedures and updated tables, ICX-UDS can use this information to maintain data consistency even for the most complex dependencies. See http://www.pcticorp.com/onlinebook/3.1 for details.

    Finally, if the application demands very high performance using data altering stored procedures, then the use ICX-UDS embedded control statements should be used to minimize the serialization overhead delivering the best possible performance.