Oracle Data Guard Reviews

We've implemented Oracle Data Guard for both types of databases within our private cloud environment, ensuring data protection and high availability.

Oracle Data Guard stands out by providing heavy-duty features that enable connecting multiple standby databases to a single production database. Oracle supports up to eight standby databases, offering a level of redundancy and scalability that other platforms cannot match. Implementing Oracle Data Guard ensures the protection and integrity of your data, even in the event of a disaster. With Data Guard, Oracle guarantees zero data loss, providing peace of mind for organizations relying on their data for critical operations.

Data Guard offers multiple protection modes, each serving different needs. One such mode is active-active, where both the production and standby databases are actively accessible. In the event of a failure, seamless switchover occurs without disrupting client sessions, as they remain unaware of the transition between databases.

Most customers use it for DR. In the event of a switchover or failover, if there's a patch applied to the environment, they use DPR to carry out the failover activity. Any disaster or power outage will prompt them to fail over to PR.

Data Guard also improved because customers with an active Data Guard license want to reduce the I/O in a production environment. Some application complaints to it for Oracle reporting purposes. It has a production environment that needs to be enhanced.

Some applications may need testing during a failover or switchover event in Oracle Data Guard. For example, applications hosted on the primary site may need to be verified on the DR environment. These applications need to remain up-to-date. Any delay in data replication can significantly impact business operations, particularly for specific purposes.

Our company is fully into Oracle. So, we use most of the enterprise things in Oracle, and our core application is in Oracle only.

The data reduction and Active Data Guard, all the stuff that's happening, is in Oracle only. Maybe we have a reactivation program trying to move into other purpose-built data, but that's in an early stage.

There are various advantages. First of all, easy to deploy. The only difficult part is the cost factor, licensing. In other ways, the implementation is very, very important. 

Like, we have not encountered any major challenges with replication. We were able to achieve near-real-time replication. Also, with the switchover failover, we were not getting any technical issues. It's a pretty stable product. 

Once you configure it, it goes through the rollback, and then Data Guard introduces this snapshot thing. So once the restoration happens, we can go back to the original thing, and we make that a standard.

It's a pretty decent and key function for Oracle. So, enterprise organizations go for Oracle only for features like these.

The product is used for high availability and disaster recovery.

Snapshot and Data Guard Manager are awesome features. Switchover and failover during disasters are also good. Oracle improves its products’ availability. It increases the number of features with each release and update. The product can be integrated with different platforms, but the platform must be homogenous.

I have utilized it as a backup system, with the disaster recovery aspect coming into play only when there was an actual disaster on the primary side.

Implementing Data Guard significantly enhanced my database disaster recovery process, making it a superb solution. I've adeptly managed the Data Guard system, ensuring its smooth operation.

Real-time data protection provided by Oracle Data Guard was indispensable for our operations. We encountered an Oracle-related attack, resulting in the loss of data at the primary data center. Consequently, we swiftly migrated to the disaster recovery site. Thankfully, the attack was prevented on the primary side.

Oracle Data Guard proved its effectiveness in handling real-world failure scenarios. In this critical situation, having Oracle Data Guard was an invaluable solution. It enabled my customers to continue working without experiencing data loss or downtime, which I consider crucial.

We and our customers view Oracle Data Support as an essential business unit, akin to a planning tool.

The primary advantages of Data Guard, compared to other backup and recovery solutions, include the assurance of data safety and the ability to recover lost data by opening the Data Guard system and synchronizing it from the primary database. On the downside, the main drawback may be the cost associated with licensing.

I use Oracle Data Guard to keep a backup copy of my database for quick recovery in case of a disaster and offload some tasks to a separate copy of the database. It has evolved a lot in the last ten years and is now really good at both. It ensures that if something goes wrong with the main database, you can smoothly switch to a backup without much downtime, keeping things running smoothly.

At work, Oracle Data Guard is a must-have for us. It ensures our databases stay in sync between the main and disaster recovery sites, acting as a solid backup. It is a top-notch product, super stable, making it our go-to for internal operations.

We moved from on-premises to a private cloud.

Only our ERP admins use this solution, so it's about five people.

The most important feature is that if I want to test the database at the disaster recovery site, I can take a snapshot, test it, and then revert it back to the original state without needing to restore the complete database from the primary data center to the disaster recovery.

Our current practice involves monitoring the continuous flow of data to ensure that the gap remains consistently at zero. If the gap increases, it is often due to issues such as a stalled work process or disruptions in the data shipping process. In such cases, our response has been to repeatedly restart the process to address the issue.

The most valuable feature is the application or promotional code used in the production protocol to transfer data to the secondary database, situated on the DR site.