SharePlex Q3FY20 - Zero impact database migration

re-established, SharePlex automatically begins passing the queued transaction over to the target server to be applied to the target database. Thus, no data is lost while the network is down, and no manual intervention is necessary to re-establish synchronous data. The same is true if the target database were to go down or if SharePlex were to be stopped on the source server while users were still applying transactions to the source database — no data is lost and users experience no downtime on the Oracle database side. • Distribution of data from an Oracle source to multiple SQL Server targets, where each SQL Server target can have all or different subsets of data • Data consolidation of multiple Oracle databases (all or a subset of data) to a single SQL Server database • Replication from an Oracle instance on-premises to a SQL Server instance in the cloud: AWS RDS, AWS EC2, Azure Marketplace or SQL Server — for database services only, all SharePlex processes would run on the Oracle database server Plus, SharePlex requires the lowest capital (CapEx) and operational (OpEx) expenditures of all industry-leading migration solutions. This architecture also enables replicated data to be seen more quickly on the target — in other words, lower latency. The “optimistic commit” in SharePlex means that operations of a transaction will be passed to the target database without waiting for a commit. Thus, the potential delay in the target database’s data availability is minimized because only the commit needs to be seen on the target for access to the replicated data. SHAREPLEX ARCHITECTURE The SharePlex architecture is composed of a series of queues and processes running on the database servers that move data rapidly from the source database to the target database, without using Oracle’s processes or memory structures. This architecture facilitates the fault tolerance capability in SharePlex, which avoids data loss if there is a break in the replication stream. For example, if the network goes down, transactions will queue in the SharePlex export queue on the Oracle server until the network issue is resolved. Once the network is This type of architecture is quite different from that found in native tools. Because SharePlex does not use Oracle’s processes and memory structures to replicate data, there is minimal overhead on the database and on the servers — just 1 percent to 3 percent CPU. Export Export queue Import Post queue SQL Read Post Redo/archive logs Capture Source 3 Capture queue Cloud target Post Target The SharePlex architecture enables replicated data to be seen more quickly on the target. SharePlex migration steps from Oracle to SQL Server 1. Install the SharePlex binaries on the source and target database servers. 2. Create the SharePlex database user and the config file that identifies all the tables to be replicated. Activating the config files starts the queues and process on both the source and target database servers with no need for manual configuration. 3. Because the post-process is stopped on the target server, transactions begin queuing up on disk in the post-queue on the SQL Server target. Activating the config files starts the queues and process on both the source and target database servers. 4. On an intermediate Oracle server, apply a backup from the Oracle production instance generated from a specific SCN or log number, depending on the method of creating the backup (Data Pump, BCV, RMAN, etc.). 5. The Oracle data on the intermediate server can then be moved to the SQL Server instance either using native SQL Server tools or SharePlex. The latter can be accomplished by replicating DDL and data to the target SQL Server database. 6. The SharePlex reconcile command on the post queue deletes the transactions that were already applied by the backup, thus only the new transactions will be applied to the target SQL Server database to synchronize the target data with that of the source. All of these steps are accomplished while users continue to work on the production Oracle database — thus, no downtime. 7. Users can then be moved from the Oracle database to the new SQL Server instance. Key benefits of using SharePlex to migrate from Oracle to SQL Server Business intelligence support Integrates directly into SQL Server environments to support your business intelligence initiatives Impact-free migrations Enable modernization of IT environments with nearly zero down-time during migrations User-defined data delivery Facilitates delivery of Oracle data to SQL Server databases for complete platform migrations, archiving, analytics, data distribution, distributed processing and centralized reporting SharePlex Manager Provides a GUI dashboard to easily monitor your SharePlex environment Superior total cost of ownership Reduces CapEx with a complete, low-cost solution that includes all the necessary tools for migrations, reporting, data warehousing and application integration without requiring any add-ons Reduces OpEx with a highly coupled solution that provides unrivaled operational and administrative efficiency 4 World-class support Provides rapid answers to questions and invaluable guidance from industry experts, consistently earning excellent approval ratings from more than 94 percent of customers; available 24x7 through multiple, localized — not outsourced — support centers Services Offers implementation, configuration and migration services from a highly qualified and experienced team with a significant track record of customer satisfaction and success Superior development Delivers new features to the marketplace when they’re needed, even outside of release cycles