Oracle Data Guard Reviews

I work primarily with Oracle databases and Oracle Linux infrastructure. I also work with Oracle WebLogic middleware.

I am working on Oracle Database 19c, 12c, and 11g, and I have upgraded 11g and 12c to 19c. Most of my work is with 19c.

I am not working with Database Vault, Database AWS, or backup services. I support on-premises solutions and Oracle FCCM applications.

I work with Oracle FCCM and OFSAA.

For the last six months, I have been working with Oracle FCCM, primarily on the database side, including database migrations, database creations, vulnerabilities, and patching.

Oracle FCCM refers to Financial Crime and Compliance Management.

I do not have much functional knowledge about Oracle FCCM, but I support the database side. I have an understanding of AML, Anti-Money Laundering, KYC, and different modules, and the application works on that side.

Another department works with that product, while we support the database layer and infrastructure layer.

Regarding support for the database layer and infrastructure, I work on Data Guard, and I have created multiple Data Guard solutions.

I work with WebLogic, not with Oracle WebCenter.

I am an Oracle partner. Our clients are mostly buying the solution directly from Oracle, especially in the banking sectors where Oracle FCCM and Oracle Database 19c are used and hosted on Oracle WebLogic.

In my opinion, Active Data Guard is the most valuable feature. We use the secondary side for reporting purposes, which reduces the load on the primary side.

Oracle Data Guard includes functions such as automatic failover, but we use manual managed failover. After some months, we converted our primary to secondary and secondary to primary.

Oracle Data Guard is effective in minimizing data loss and provides a good solution for that.

The main benefits of Oracle Data Guard include minimizing data loss during a production failure. It is used for maximum availability when paired with Oracle RAC, so if any disruption occurs, we have an alternative Data Guard to convert our load to the disaster recovery site.

Oracle Data Guard maintains a high level of data integrity by using archive logs. When a transaction happens, redo logs create archive logs, which are then applied on the disaster recovery side, ensuring that both databases are synchronized.

Oracle Data Guard could improve by simplifying their processes, as it currently requires a lot of knowledge and technical experience. It could benefit from more automated features that notify via email if the disaster recovery or primary side fails.

I would like to see more automation features in the product.

I have been working with Oracle Data Guard for two years.

For the stability of Oracle Data Guard, I would rate it as the best.

From one to ten, I would say scaling is very easy.

I have had great experiences with Oracle's technical support. Oracle has the best support and a great knowledge center with a lot of accessible material for users and administrators.

Positive

I think MS SQL Server is a general competitor used on the relational database side.

The initial setup for Data Guard is not that complex if you have an understanding of Oracle databases, initial installation, and management.

I do not have much experience with pricing and licensing, but I think it is available at an enterprise level. The simple Data Guard is free, and Oracle charges additional fees for Oracle Active Data Guard.

I do not have experience with MS SQL Server. In my opinion, the key competitor for Oracle Data Guard in the market would be GoldenGate.

I am not currently working on BMC solutions. I have been working on the Oracle side for two years, supporting Oracle products. I do not have real experience with Oracle FCCM. We work with Data Guard for high availability. If the application requires it, we switch over from one side to another and convert our primary to secondary databases. The main purpose is for high availability and disaster recovery. I currently work in Technologics, supporting Oracle solutions. My overall rating for this solution is eight out of ten.

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 only difficult part is the cost factor, licensing.

Another area of improvement is support. 

Morever, Oracle's partner is not also doing good. For that, they should improve. Such enterprise features need a good partner. That is where Oracle Data Guard failed. They never had a good partner. I never found a good partner in India. 

My company has been using it for more than ten years. We are a reference customer for this Data Guard in Windows and Oracle. At that time, most of those were using Linux, whereas our company uses Windows. So, we were a reference customer for Oracle. 

The product has been pretty stable. Because we can't afford to have technical issues with production databases. In 20 years of my Oracle DBA experience, I have not encountered any big technical issues that have impacted production. 

We faced challenges in migrating to major versions, especially with respect to changing execution plans. That is a one-down thing about Oracle. The execution plan is to host a multi-tenant architecture. Use the same application code, but SQL will be the same, and the data size will vary. 

So, at that time, we had the concept of our execution plan in Oracle. So that sometimes gives you a problem. So whenever we do a major upgrade, we have some challenges. It is the risk here. We need to do a lot of testing before moving to the new version. So, we became a bit reluctant to readily upgrade. 

I'm not a big fan of Oracle technical support because the first and second levels of technical support are very, very basic. 

So, in fact, I get irritated a lot of times till it goes to the third level. Once it goes to the third level, it is good. But then finding a time until that time, we can't wait to have a production issue. 

So, in most cases, we just work on the alternate only instead of relying on Oracle technical support. For example, when something like corruption happens in 50 terabyte, the level one guy, technical support, will say, "We have a backup; can you restore it?"  Is it possible to restore 50 terabyte? The time it will take to do it. So, without that practical knowledge, these guys will just work on the standard FAQ documentation. So, I'm not a big fan of Oracle support when it comes to levels one and two. Of course, the third level is good.

Neutral

My company wanted to move out of Oracle Data Guard for cloud readiness because Oracle was not ready to move to other clouds at that point in time.

So, we did look at Postgres for our peripheral application, EDB. The normal open-source EDB did not support enterprise features like real-time replication and transparent data encryption. So, just for that, and also as a policy, we wanted to use only the supported version. So we went for Oracle Data Guard. So, I was looking at the project, and we have used EDB for two to or three years now.

I have used Oracle only, but then recently, we looked at other databases like Postgres and MongoDB. We can compare it with that. Oracle is the best for transactional databases in enterprise organizations. Maybe smaller organizations can take MySQL or Postgres. But then, for a company like an enterprise organization having high concurrent transactions and, more importantly, the security aspect, Oracle is the best product.

We had an unlimited license agreement with Oracle. 

We evaluated and we did a kind of POC with MongoDB. But then the price of MongoDB was costlier, and then we realized that MongoDB is apt for a concurrent request, and mainly, it's a unique streaming kind of thing. Maybe for fraudulent systems, but not for code transaction processes. 

So we did a POC with MongoDB, and then the pricing was costly on MongoDB, especially on the Guard. They call it a shard, and the cost is based on a shard. And Oracle has a lot of our DB servers, so they are so large. So, I never used MongoDB in production, but we evaluated it.

It is a good DB solution. It has good availability. Overall, I would rate the solution a nine out of ten. It is a good transactional database. 

Oracle do the upgrade. They are too good at introducing new features. So whatever the user base is, get that done in other releases, new releases for Oracle Data Guard. They are very reactive.

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.

In large enterprise-level organizations, key features such as data integrity, reliability, and security are paramount. Oracle Data Guard offers robust capabilities in these areas, making it a recommended solution.

I have been working with it for approximately eighteen years.

Oracle provides robust security measures and reliability.

In addition to Oracle products, we also utilize Microsoft SQL Server within our IT infrastructure. One of our security measures involves capturing images during specific user interactions, such as when someone enters their password or performs other sensitive actions, like activating their card. We capture images at three key steps: when the password is entered, when the action is confirmed, and when the transaction is completed. By capturing these images, we create a comprehensive record of user interactions. This record can be invaluable in scenarios where card theft is claimed, as we can provide visual evidence of the actions taken by the user. These images are stored in our secondary data repositories, such as SQL servers. However, it's important to note that our primary transactional data remains stored in Oracle databases, ensuring robustness and reliability for our critical banking operations. While other databases like Microsoft SQL Server, IBM products, and MySQL are suitable for smaller-scale operations, they lack the advanced algorithms and performance capabilities of Oracle.

Configuring Oracle Data Guard can be a complex process compared to other tasks within Oracle or Microsoft environments. It involves several steps. First, compatibility needs to be ensured by configuring the operating system, which could be Linux, Unix, Solaris, or Windows. We tend to rely on Unix-based systems for our data protection needs due to their security features. Following this, the database itself must be configured, setting it up in production mode and enabling data archiving. Then, standby databases are prepared based on the organization's requirements, whether it's one, two, or more. Afterward, Data Guard is configured using the command-line utility, requiring careful attention to detail. Finally, the Data Guard broker, an advanced tool enhancing Data Guard's capabilities, is set up. While these steps may seem daunting, they become more manageable with experience and proper preparation. With our team's extensive experience and dedicated servers, we've been able to navigate these processes smoothly.

In our organization, we have a dedicated team of DBAs, comprising two individuals focused on documentation and two others actively involved in practical implementation. These DBAs handle all aspects of Data Guard, ensuring effective server management and data protection.

The pricing is on the higher side. In Pakistan, for instance, while Oracle might charge ten billion rupees for a license, Microsoft could offer a license for a significantly lower amount, such as one point five million rupees. However, the investment in Oracle database technology is justified by the peace of mind it brings in terms of data security and reliability, making it the preferred choice for organizations operating in sensitive sectors like banking.

The pricing structure for Oracle products varies depending on the organization's profile. Oracle Corporation offers discounts for educational institutions such as universities, teaching institutes, and schools. Similarly, organizations with significant profits or large networks may receive preferential pricing. The cost is determined based on specific features utilized, such as Data Guard, compression, number of CPUs, and concurrent sessions. Pricing considerations also take into account the nature of the application, whether it's a web-based application accessed globally or a desktop application restricted to internal use within the organization.

We operate on a unified platform, utilizing Oracle hardware, Oracle Linux operating system, and Oracle database, along with Oracle forms and reports. This cohesive setup streamlines our management processes, as we can easily specify our hardware requirements, including the latest operating system versions and support duration. Our commitment to a single platform ensures seamless integration and minimizes compatibility issues. For instance, in the past, when we briefly experimented with IBM servers, we encountered difficulties when attempting to replace a faulty hard disk with one from a different manufacturer. This experience reinforced our decision to remain on a consistent hardware platform, thereby avoiding potential compatibility challenges.

My suggestion is to consider utilizing Oracle because it's user-friendly and easily configurable. There's an abundance of resources available online to help with configuration and troubleshooting. We often recommend Oracle to newcomers, friends, and students because it's reliable and straightforward to use. Overall, I would rate it ten out of ten.

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.

The most valuable aspect for me is undoubtedly the failover capability and the assurance of data safety provided by Oracle Data Guard.

For Italian medium-sized companies, the main challenge lies in the cost associated with licenses.

In certain situations, we cannot utilize Data Guard swiftly for executing specific queries or statements that require temporary data manipulation. This is because opening the Data Guard system involves serving the changes and rolling back, even though snapshot features are available. In such scenarios, when customers need to test new application features or in the event of system vulnerabilities, it might be preferable to operate Data Guard without resorting to snapshot or flashback functionalities, thereby avoiding the need to recreate the system or start from a backup. These challenges were encountered within a high-traffic environment.

We have been working with it for approximately ten years now.

It is an exceptionally stable system.

Beginning from version twelve, scalability has significantly improved for the Data Guard system. In versions prior to twelve, scalability was not a strong feature, especially when configuring a rack cluster system where the primary database had multiple instances, while the Data Guard system had only one. However, since version twelve, it has become possible to configure more than one standby system, enhancing scalability.

In the past, I found technical support to be more efficient compared to the present. Now, when submitting service requests on the support portal, I often encounter support personnel from India, which sometimes requires escalation to shift the support center's ownership and ensure assistance from European support teams. This process has resulted in a significant loss of time in obtaining prompt support. I would rate it seven out of ten.

Neutral

I typically work with the standard Oracle tool for managing backup, recovery, and related tasks. However, some customers have recently adopted storage disaster recovery systems. While these systems can replicate data between sites, they come with limitations. For instance, a controller attack on the primary side can automatically propagate to the secondary side, which isn't protected unless using an Oracle Data Guard system.

Setting up an Oracle database isn't straightforward, though it's comparatively simpler than other systems. Personally, initiating and configuring an Oracle Data Guard wasn't a significant challenge. However, the complexity arises when considering the sizing of the primary database. Managing a few gigabytes for Data Guard is manageable, but scaling up to terabytes poses a substantial effort.

The deployment process involves configuring the server and Data Guard, recreating the environment, and setting up the standby database, potentially from a backup or using the duplicate command. The primary challenge lies in seamlessly managing the application server connections to intelligently switch from the primary to the Data Guard system in case of crashes. A single individual can effectively manage and establish the Data Guard system. The deployment timeline may vary depending on factors such as the size and complexity of the primary database. However, I believe that within two days, it is possible to set up the Data Guard system. Following this, an additional two days may be necessary to review the environment and assess any potential issues, such as unusual application behavior or direct server connections from directors.

Maintaining the Data Guard system isn't as straightforward as maintaining a primary system. Although I typically utilize the Oracle Enterprise Manager monitoring system to manage and monitor the Data Guard, there may be instances where patches or updates are missed over time.

The licensing cost is significantly high.

I highly recommend implementing a Data Guard disaster recovery system. Overall, I would rate it eight out of ten.

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.

Oracle Data Guard makes data protection and network management much easier. It reduces the risk of data loss and stress associated with managing Data Guard. Therefore, Data Guard ensures good performance.

Implementing Oracle Data Guard properly is crucial. Transitioning applications between different operating systems may take a lot of work, but it becomes easier with the proper knowledge. Therefore, there's a need for awareness sessions to enhance people's understanding of Data Guard and its implementation.

There is an issue with their application on ODG. There were a lot of edits in the logs. Sometimes, we only get a little cue from the Data Guard Broker logs if there's an issue.

I have been using Oracle Data Guard for over seven years.

The solution is very scalable.

Golden Gate was a highly cost-effective solution.

The initial setup is straightforward, provided you know the source, target, data version and format. You need to consider all those things.

First and foremost, when deploying Oracle Data Guard, the number one priority is to ensure all parameters are correctly set. Two primary methods exist: using backups or recovering from services if the network is reliable. If the network is robust, backups from the source to the target may not be necessary. You must ensure that NIS names are correctly configured on both sides and that the failover and switchover processes are tested successfully from both production and standby environments. Once these steps are completed, the deployment process becomes straightforward.

There's no need to copy the entire parameter file; only specific configurations, such as the SID or file structure, must be adjusted if necessary. Ensuring proper DNS name resolution, SID configurations, parameter settings, and understanding whether to convert the Data Guard are essential. Once these aspects are identified, the deployment process becomes more straightforward. I have implemented numerous Data Guard setups.

Setting up Oracle Data Guard is performed within the Oracle CRS. Challenges may arise in establishing connectivity between the standby and production databases, necessitating troubleshooting. Apart from that, once configured within CRS, the setup is complete.

The challenge with Oracle Data Guard is that it often takes some time for us to identify whether the issues stem from the disk or the network. If we report issues to the network or storage teams from the database end, we may not perceive any apparent problems, which can lead to confusion. We can convince the storage teams to investigate further until we delve into the disk I/O Guard and determine if specific disks operate at total capacity. When disks are operating at total capacity, it can significantly impact application processes. These difficulties in pinpointing the source of issues contribute to the challenges of maintaining and managing Oracle Data Guard. 

The product is expensive.

I understand what is required for a fault switchover or failover to the DR site on Oracle Data Guard. The first thing I check is to ensure that their application is current. If the application is not current, that'll be an issue. Even if the application is up to date, they still need someone to validate the DUR if it's suitable to be caught up to the primary. If not, we need to start looking at why switching over to production is unsuitable. Many things can lead to that. There may be a network issue or sometimes storage issues that can impact data integrity. Sometimes, the storage or network has an issue. Sometimes, it's between storage and the network that impacts a cutover. If it is properly implemented, no other issues can arise.

In a situation where you have a production environment and a power outage, the application or business will be impacted in an environment with power redundancy. However, if you have configured a feature that enables failover within five minutes, the service will automatically switch to the DLP and designate it as the primary.

Everything about the data guard is quite complex.

I advise you to move from automated practices to manual ones. It makes a difference. Get your hands dirty internally before implementing it for the organization. If you can do it locally, on your own internal server, then you'll have the confidence with the data to implement it for the organization or anywhere else.

Overall, I rate the solution a ten out of ten.

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.

The predominant issue lies in the communication link between the secondary and primary databases. Improving communication in this aspect should prevent any potential data discrepancies or account-related issues.

I have been using it for almost two years.

I would rate the stability capabilities five out of ten. It's not about the system; rather, they are leaning towards adopting a cloud solution.

I would rate its scalability abilities nine out of ten.

I am satisfied with its customer support services. I would rate it eight out of ten.

Positive

I have been working with Hitachi previously.

The initial setup is somewhat complex. I would rate it five out of ten.

The deployment process depends on the capacity of the database, making it potentially challenging, especially when dealing with large datasets. A full backup is required to initiate the porting process to the secondary site. The website setup, approximately, may take approximately a day to complete. Subsequently, when performing log application, it could extend to around half a day or a similar timeframe.

It's a cost-effective solution.

Overall, I would rate it eight out of ten.

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.

The most valuable thing about Oracle Data Guard is the active data guard feature, which allows us to have an active site rather than just a standby one. This is particularly handy during failover situations, keeping things running smoothly and reducing downtime.

A significant improvement for Oracle Data Guard would be enabling the disaster recovery site to handle read and write operations, not just data storage. Currently, the DR site is read-only. If we could make both the primary and DR sites read and write capable, it would be a game-changer. This means the DR site could actively contribute to data management, not just save it. This enhancement would make Data Guard more versatile and impactful for database operations.

I have been using Oracle Data Guard for 25 years.

It is incredibly stable. I would rate the stability as an eleven out of ten.

I would rate the scalability of the solution as a ten out of ten. We have approximately 30,000 end users.

The technical support is a ten out of ten.

Positive

Setting up Oracle Data Guard is a bit challenging. It is not very easy, and you will likely need an expert to guide you through it. But if you follow the steps and get the right help, you can get it done. How fast you can set up Oracle Data Guard depends on things like how big your database is and the quality of your internet connection. Smaller databases and good internet make it quicker to set up, while larger databases or slower connections may take more time. Setting up Oracle Data Guard varies a lot. It could take anywhere from a minute to a day. It depends on factors like your database size, bandwidth, and other technical considerations.

The solution is on the expensive side, but it is not too costly. I would give it a five out of ten in terms of affordability. The cost of Oracle Data Guard is approximately $450,000 per year for my company.

Overall, I would rate Oracle Data Guard as a perfect ten out of ten.

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.

The product could improve its pricing.

I have been using the solution for eight years.

The tool’s stability is very good. We can rely upon it. I rate the stability a ten out of ten.

The product’s scalability is good. We can have 32 replicas of the same database working in tandem. It is a very good solution. We can also cascade the database replica to replica. Around 120 customers use the solution. I rate the scalability a ten out of ten.

The initial setup is easy and straightforward. The time taken for deployment depends on the size of the database and the network bandwidth. We can deploy the solution on-premises and on the cloud.

The DBAs in the company deploy the solution. We do not require any additional staff because all the processes are streamlined.

The product is included in the Enterprise Edition license. If we have Enterprise Edition, no additional licensing is required. I rate the pricing a seven out of ten.

The improvements in deployment depend on the homegrown scripts that each customer uses. I recommend the solution for disaster recovery and high availability solutions. Oracle Data Guard and Data Guard Manager are very intelligent tools. It can be easily integrated with Oracle Enterprise Manager. The security features in Oracle Database are available in Oracle Data Guard. It is just a disaster recovery solution. Whatever integration is done on the primary center, the same can be done on the disaster center too.

Overall, I rate the product a ten out of ten.

The product is used for disaster recovery as well as being able to put in read only mode and run queries or reports on DR site. 

You can run reports or test scripts on standby and tune them without having to worry about affecting anything going on in productions. That way, you know exactly how the reports and queries will perform in production before installing it. 

You have the exact data and environment provided your standby is set up the same as your production database and server.  This also help gives you a better ROI on the DR site to.

We had some very intensive reports we used to run on prod and switched to using the standby site for the reports, which really helped our production run better for our loads. Developers can test their code thoroughly before installing it into production and know precisely how it will perform. It eliminates a lot of guesswork and issues. You can tune and ensure the result set is exactly what they expect and install the code one time instead of having to fix code on the fly or back out the code.

It is excellent as a data guard broker. You can see how the logs are applied, check the apply time, and how far behind the standby is at any given time. It can help you make sure all the parameters are set up correctly, much easier to switch over to the standby side and back to production without data loss. Also, you can put into snapshots a clone to do a quasi-DR test to make sure standby is set up with the application and everyone can connect. The app performs as expected before a DR happens.

Running reports and scripts from the standby side to tune in advance.

We would like to be able to see the date time stamp when you execute DGMGRL commands. In our recovery test, we have to include the timestamp when we start and end the switchover or snapshot tests, and it is difficult to do when the timestamp is not there when you run the commands. It is a very manual process to try to include the start and end time of each along with the screenshot of the DGMGRL screens.

We need to be able to run more SQL commands in DGMGRL.

We need to be able to automate commands and scripts better in DGMGRL.

I've used the solution for over ten years.

The solution has been very stable since version 11.2.

The solution is very scalable.

Check with Oracle to make sure you are using your products effectively.

We did look at other options. However, those we saw did not have as many features as Oracle ADG.

Oracle Data Guard is a critical part of our business applications. The solution helps protect our data from accidental or unauthorized changes.

The solution can be deployed on-prem and on the cloud.

The solution has helped improve our organization by making the data more accessible quicker.

The most valuable feature is the flashback standby, which allows us to test without scrapping the database.

I would like the ability to use the read-only format from other sites for more reporting not only for disasters but also to offload the workloads on our production site. This will require some investment.

I have been using the solution for 15 years.

I give the stability a nine out of ten.

The solution is scalable.

I previously used Dell EMC RecoverPoint. Oracle Data Guard is more native to the database, so it will have better features, better flexibility, and be easy to operate or activate in terms of disaster. The solution has also reduced the traffic of the network. EMC RecoverPoint used too much data to be transferred, but with Oracle Data Guard less data will be transferred.

The initial setup is complex. I give the setup a two out of ten.

We tested internally and then configured the Oracle Data Guard according to the procedures we found from the published Oracle site. We then deployed the solution. The deployment takes around four months and requires three people.

We use the experts who are there for the provisioning of the Cloud infrastructure, but most of the implementation is completed by our technical team.

We have seen a return on investment because the solution is available almost instantly, making it a worthwhile investment.

There is no set cost for the solution. The cost of the Oracle license will depend on the negotiations with Oracle. The license is costly compared with other database systems.

The license includes primary support, patches, and technical support.

We evaluated CloudEndure but it did not meet our requirements.

I give the solution a nine out of ten.

The maintenance is completed in-house but is rarely required. We monitor the solution with the help of our operation team.

Oracle Data Guard can allow us to enhance our system by making each of our databases, primary and standby, usable at the same time.