Oracle DBA at Broadridge Financial Solutions, Inc.
Real User
2022-06-29T18:17:00Z
Jun 29, 2022
We use SharePlex to migrate and update from one data center to another. It's helpful for DR and broadcasting solutions. The main use case is to minimize downtime for migration or upgrade. The second objective is real-time replication. The main SharePlex users are database administrators. We're the replication administrators in the company, and that's the primary user base. We've used it to upgrade from Oracle 12.1 to 12.2 and Oracle 12.2 to 19c. We've also done cross-platform upgrades and migrations from on-premises to the cloud.
Our application is hosted in multiple data centers and we primarily use SharePlex for keeping the data replicated from one data center to the other. We use it for business continuity, so that if we run into any issues in the primary data center where the application is currently hosted, with SharePlex we are in a position to switch over to the secondary data center, to do a failover, pretty much in real time. We have Cisco UCS servers where we have our Oracle Databases running with Linux version 7. These are standalone databases, but I've been a part of a different business unit in our company where we had real application clusters. Right now, it's standalone Oracle 12c and we are migrating to 19c. We have SharePlex replicating Oracle data. It is IoT data so the number of transactions happening is huge. SharePlex keeps the data in sync with the other data center, which has almost the same configuration of the bare-metal servers, Linux, Oracle and SharePlex. We primarily use SharePlex for the IDBMS, but we have also used SharePlex for Postgres and for Kafka. Our implementation of SharePlex is entirely on-premises.
We use Quest SharePlex for a specific reason. We are migrating from on-premise to cloud. SharePlex is a replication service. We are using it to do the migration of our databases to AWS Cloud. Once everything is migrated, then we won't be using the solution. We have small to very large databases in terms of size. We were looking at a solution where we could cut down the migration window. We wanted to cut down the outage window and reduce the overall cost of migration to the cloud. For example, if there was a very large amount of data, e.g., five or 10 terabytes, and we were trying to migrate that database over a weekend, then that it is a risky proposition. We were looking for a solution where we could do a migration before the cutover time, then keep it in sync. So, when we were at a point when we were ready to switch, then we could just stop the replication and bring everything up in the cloud. That was our main use case for using SharePlex. We started on version 9.2. Now, we are on version 10.
SharePlex database replication empowers your organization to achieve its database goals now and into the future. Make use of built-in monitoring, conflict resolution, data comparison and synchronization capabilities backed by award-winning support.
We use SharePlex to migrate and update from one data center to another. It's helpful for DR and broadcasting solutions. The main use case is to minimize downtime for migration or upgrade. The second objective is real-time replication. The main SharePlex users are database administrators. We're the replication administrators in the company, and that's the primary user base. We've used it to upgrade from Oracle 12.1 to 12.2 and Oracle 12.2 to 19c. We've also done cross-platform upgrades and migrations from on-premises to the cloud.
Our application is hosted in multiple data centers and we primarily use SharePlex for keeping the data replicated from one data center to the other. We use it for business continuity, so that if we run into any issues in the primary data center where the application is currently hosted, with SharePlex we are in a position to switch over to the secondary data center, to do a failover, pretty much in real time. We have Cisco UCS servers where we have our Oracle Databases running with Linux version 7. These are standalone databases, but I've been a part of a different business unit in our company where we had real application clusters. Right now, it's standalone Oracle 12c and we are migrating to 19c. We have SharePlex replicating Oracle data. It is IoT data so the number of transactions happening is huge. SharePlex keeps the data in sync with the other data center, which has almost the same configuration of the bare-metal servers, Linux, Oracle and SharePlex. We primarily use SharePlex for the IDBMS, but we have also used SharePlex for Postgres and for Kafka. Our implementation of SharePlex is entirely on-premises.
We use Quest SharePlex for a specific reason. We are migrating from on-premise to cloud. SharePlex is a replication service. We are using it to do the migration of our databases to AWS Cloud. Once everything is migrated, then we won't be using the solution. We have small to very large databases in terms of size. We were looking at a solution where we could cut down the migration window. We wanted to cut down the outage window and reduce the overall cost of migration to the cloud. For example, if there was a very large amount of data, e.g., five or 10 terabytes, and we were trying to migrate that database over a weekend, then that it is a risky proposition. We were looking for a solution where we could do a migration before the cutover time, then keep it in sync. So, when we were at a point when we were ready to switch, then we could just stop the replication and bring everything up in the cloud. That was our main use case for using SharePlex. We started on version 9.2. Now, we are on version 10.
database replicating reporting migration consolidation high availability distributing data