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. 

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.

The product could improve its pricing.

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.

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.

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.

They may need to include the monitoring and the alerting part in Data Guard. In case there is a delay in the sync from the primary to the DR site, it is going against more than the expected RTO or the RPO, we should be able to get an alert or see it in the dashboard.

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.

The usage of block storage devices in the cloud or migration of a type of storage from one site to another site can be improved. Currently, we have to use multi-node to single node because of the lack of storage support on the Azure side. It did not really work. Our DBA had to spend a lot of time tweaking the Data Guard tools, or the underlying Oracle VMs, to make sure that Data Guard would run on top of different types of storage. So, if it can support transporting or getting from one type of storage to another type of storage in a different site or a different technology, it would be very helpful.

Its support should also be improved.

There is always room for improvement. This product needs some improvement in administration. I would love to see something that makes monitoring much easier. 

The product needs some of the GUI tools so there is no need for all the long process.

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.

The database administration needs improvement. With Oracle, we have a lot of features for administrating data, but it might be too many. It needs to be simplified. It should be automated. Looking at Enterprise Manager, there are too many KPIs in place. Directly on-site, we do not need to choose all of them. Administration, generally speaking, needs to be improved.

Oracle should also continue to simplify the upgrade using Data Guard. We have already seen reduced outage timing any time we are doing upgrade, so maybe they are heading in that direction, but it can always be improved.

Recently we had a P1 case that we needed to raise. There were so many other problems that cropped out of it when we were trying to execute a fix. 

Overall, there are some operational issues that need to be dealt with. 

The solution should be more secure from a protection perspective. 

There may be some bugs in the solution right now. 

The deployment cost is expensive. 

Sometimes, the technical support team takes time to respond.

I think it would be great to have a graphical interface assistant (like DBCA, ASMCA, NETCA, etc.) for initial configuration, monitoring, configuring Oracle Data Guard Broker and all the Data Guard Broker commands, without needing Oracle Enterprise Manager Cloud Control installed.

I would like to see better failover.

Oracle could be improved by the ability to manage it on the cloud. This on-premises version is secure and reliable, but I'm sure that they will soon provide a cloud solution that will be even better. In one to two years, we will probably move to the cloud—we have already moved to the cloud with Microsoft Exchange, but our databases are still on-premises. I would prefer managing a cloud version of Oracle.

I'm not really sure about what needs improvement because we use all Data Guard's features successfully.

Pricing is expensive and can use improvement. 

It is a rather complex solution, so it could be more user-friendly.

I would like to see replication/fail-over sites.

Oracle Data Guard is part of the Oracle Database Enterprise Edition. Oracle Corporation has provided features in Data Guard for its new Database version Oracle 12c.

Once you get used to it, you get to know what to do when certain things happen. However, for a person who's just jumping into it, the management of it and how to implement it probably would be something that could be improved upon. The GUI could be better.

One thing that can be improved is the GUI. It would be good to have a very nice GUI to easily configure and administer, providing different presentations to the database administrator. 

The feature that can be included is the integration with third-party monitoring systems, that is, monitoring systems from other vendors, not only from Oracle.

When the data replicates into the standby database there is a possibility of having a microsecond amount of data loss. 

The data loss occurs when there is a network disconnection between the primary and secondary standby database located in the data centers or if there is a crash in the primary database.

The data is generated on the primary database which is configured to the standby database to duplicate it on a real-time basis. So if there is a system crash or disconnection and in the time it takes to get it back up, you can lose a microsecond amount of data.

When I experienced a small crash, I compared the data between the primary database and the standby database and found that there was a small difference in the amount of data. Not all of it was replicated or backed up.

It creates issues with synchronizing the data.

Because the focus in Data Guard is in the backup and restore, there hasn't been much with the interface. 

In the next release, if there could be more focus on the interface to include add-on features that would be an added advantage going forward.

A disadvantage is that the available disk space must be doubled. This is because Data Guard is made of two databases, one primary and one as a standby running permanently. We must pay the Oracle license on the second server. For every standby server you have, you must pay a licensing fee, which is the main disadvantage.

Oracle is not easy to implement, and you cannot find clear documentation on the internet or, unfortunately, on the Oracle website. You have to do a lot of research yourself and spend a lot of time seeking out all of the best documents that are related to Oracle on other websites. If they could create more documentation and improve their library of resources, it would be very helpful.

The IP implementation and maintenance are a little bit hard to manage across Oracle solutions, including Oracle Data Guard.

Limited functionality to exclude any schema/table from replication would be helpful.

Currently Data Guard replicates whatever DML operation is performed on primary database is replicated to standby database as it is. To improve it bit further, if Oracle can provide some kind of feature in which user can select any schema or 5-10 collection to tables in some schema that user doesn't want to replicate. Because this kind of feature is available in Oracle Golden Gate which a separate licensed product with a lot of features like that one that I mentioned for limited replication, heterogeneous replication, cross database replication.

The pricing of the solution is quite high. They should do what they can to bring it down so that it is more reasonable for customers like us.

The response times for technical support can be quite slow. They should work to lower these wait times so there are fewer delays in assistance.

Data Guard has been around for a very long time and a lot of big companies are using it. I don't see that it needs any improvement or anything like that. I think it's pretty solid.